Страница
1

Детализация документированных описаний процессов: как совместить управляемость и гибкость

Детализация документированных описаний процессов: как совместить управляемость и гибкость

Одним из важных вопросов, которые возникают во время разработки документированных описаний процессов, является определение уровня их детализации. Этот вопрос особенно важен для организаций, которые не разрабатывают формальную систему управления качеством с единственной целью – получение сертификата (в этом случае как раз все понятно – разрабатывается минимальный объем документов, что устроит орган по сертификации), но которые стараются по-настоящему ввести процессный подход. Ведь речь идет не только о размерах документа (несколько страниц или несколько десятков), а о том, насколько жесткими будут рамки, в которых работают исполнители процессов.

Для того, чтобы проиллюстрировать эту проблему, рассмотрим несколько распространенных ситуаций, возникающих в организациях после разработки документированных описаний процессов (хотя эта деятельность в организациях чаще называется словами «разработка системы управления качеством по стандарту ISO 9001», в дальнейшем в статье акцент будет делаться не на требованиях стандарта, а на принципах процессного подхода).

Первая ситуация. В организации разработаны документы с очень низкой детализацией, определяющие только ключевые этапы процесса, не углубляясь в его суть. Главная реакция персонала на эти документы такова: мы не понимаем, зачем они разработаны; они не несут никакой дополнительной пользы или информации; мы все это знали и делали и раньше; раньше мы это делали без них, а теперь с ними – больше ничего не поменялось. Исходя из этого, сотрудники делают вывод: процессный подход не имеет никакого отношения к реальной работе, все к чему он сводится – это разработка непонятных документов. Одно из главных «преимуществ» этой системы – то, что она практически не создает проблем для организации, существуя отдельно от реальных рабочих проблем.

Даже расход ресурсов на поддержание ее актуальности минимален, ведь такие мало детализированные документы практически не нуждаются в изменениях – на этом уровне деятельность организации довольно стабильна.

Вторая ситуация. В организации разработана очень детальная документация, которая четко регламентирует каждый шаг выполнения процесса. Но ее внедрение привело к неожиданным результатам:

· Сотрудники жалуются, что они теперь выступают только в роли исполнителей инструкций, что уменьшилась возможность для творчества; как следствие – снижается мотивированность сотрудников и их ответственность за конечный результат работы;

· Потребители жалуются, что организация стала менее гибкой, хуже реагирует на их нестандартные запросы и особые ситуации, что проблемы, которые раньше решались оперативно и неформально теперь или не решаются совсем (они не отражены в описаниях процессов), или решаются через сложную и длинную процедуру;

· Руководство ощущает, что организация потеряла гибкость, хуже и медленнее реагирует на новые возможности, если они не задокументированы в описаниях процессов.

Третья ситуация. Организация разработала большое количество очень детальных документов.

Исходя из разных причин, она рассматривает возможность ее сокращения (или из соображений, приведенных во второй ситуации, или просто потому, что поддерживать в рабочем состоянии такой объем документации слишком сложно).

Но любые попытки изъять какую-то информацию из документов, сократить или упростить их наталкиваются на контраргумент: эта информация является ценной, она отражает наш обобщенный опыт за много лет, уроки, извлеченные из наших ошибок, ее нельзя трогать.

Основные принципы решения

Главный вывод, который можно сделать из рассмотрения этих ситуаций: это то, что вопрос действительно существует, что организация должна сознавать его и искать на него ответ. Безусловно, худшим вариантом является тот, при котором никто не задает себе вопрос, какими должны быть эти документы: какие вышли, такие и будут. Детальность документов следует сознательно проектировать так же, как и все другие важные характеристики системы (структуру процессов, структуру документов, структуру планов и целей и т.п.).

Заметим, что вышесказанное не означает, что уровень детализации должен определяться на уровне системы и быть одинаковым для всех процессов. Соответствующее решение должны принимать владельцы процессов, ведь документированные описания – это их инструмент для реализации своей ответственности за результаты процессов. Но, во-первых, сами владельцы процессов должны сознательно проектировать уровень детализации документов; во-вторых, могут существовать общесистемные ограничения по этим вопросам (причем, как сверху, так и снизу).

Второй очевидный вывод из анализа приведенных ситуаций: это то, что мы имеем дело с дилеммой, когда у обоих вариантов есть как свои преимущества, так и недостатки. Как и для любой дилеммы, для ее решения можно использовать два подхода: или выбрать компромиссный вариант, который позволяет частично использовать преимущества обоих вариантов, частично нивелировав их недостатки, или искать «третье» нетрадиционное решение, которое позволит в полной мере сохранить сильные стороны обоих вариантов.

Возможный компромиссный вариант для дилеммы относительно детализации описаний процессов очевиден – разработать документы со «средним» уровнем детализации. Не будем останавливаться на нем, только укажем аспекты, которые нужно учесть при выборе этого оптимального среднего уровня:

· Сложность процесса, риски возникновения ошибок при его выполнении;

· Важность процесса, возможные следствия возникновения ошибок (как для самой организации, так и для ее заинтересованных сторон);

· Необходимость обеспечения гибкости при выполнении процесса, реагирование на непредусмотренные внешние возможности или риски;

· Стабильность процесса, частота внесения изменений в порядок его выполнения и важность этих изменений (этот вопрос будет детально рассмотрен ниже; чем чаще вносятся изменения, тем большей может быть потребность в детальном документе);

· Уровень квалификации исполнителей процесса (и возможность поддерживать его в будущем, в частности – уровень текучести среди исполнителей);

· Уровень мотивированности исполнителей процесса (насколько они будут использовать предоставленную им свободу действий для выбора оптимальных вариантов с точки зрения организации или простейших вариантов со своей точки зрения).

Что касается «более глубокого» оптимального решения, то оно должно сохранить и соединить преимущества обоих подходов: обеспечить возможность детального определения процесса (для управления им, сохранения знаний, обучения) и, в то же время, гибкость в его выполнении и заинтересованность персонала в поиске лучших путей выполнения. Должна быть обеспеченная «гибкая стандартизация» или «гибкая детализация» описаний процессов.

В традиции, принятой в отечественных организациях, понятие «стандартизация» и «гибкость» являются противоположными. Возможно, такое представление пошло еще от советских ГОСТов: дескать, стандарты являются очень негибкими, редко пересматриваются и могут устареть еще до пересмотра, и воспринимаются как внешняя данность, на которую организация не имеет никакого влияния.

Перейти на страницу номер:
 1  2  3  4