Тарас Калита, директор Центра систем качества «Прирост-Система».
Одним из важных вопросов, которые возникают во время разработки документированных описаний процессов, является определение уровня их детализации. Этот вопрос особенно важен для организаций, которые не разрабатывают формальную систему управления качеством с единственной целью – получение сертификата (в этом случае как раз все понятно – разрабатывается минимальный объем документов, что устроит орган по сертификации), но которые стараются по-настоящему ввести процессный подход. Ведь речь идет не только о размерах документа (несколько страниц или несколько десятков), а о том, насколько жесткими будут рамки, в которых работают исполнители процессов.
Для того, чтобы проиллюстрировать эту проблему, рассмотрим несколько распространенных ситуаций, возникающих в организациях после разработки документированных описаний процессов (хотя эта деятельность в организациях чаще называется словами «разработка системы управления качеством по стандарту ISO 9001», в дальнейшем в статье акцент будет делаться не на требованиях стандарта, а на принципах процессного подхода).
Первая ситуация.
В организации разработаны документы с очень низкой детализацией, определяющие только ключевые этапы процесса, не углубляясь в его суть. Главная реакция персонала на эти документы такова: мы не понимаем, зачем они разработаны; они не несут никакой дополнительной пользы или информации; мы все это знали и делали и раньше; раньше мы это делали без них, а теперь с ними – больше ничего не поменялось. Исходя из этого, сотрудники делают вывод: процессный подход не имеет никакого отношения к реальной работе, все к чему он сводится – это разработка непонятных документов. Одно из главных «преимуществ» этой системы – то, что она практически не создает проблем для организации, существуя отдельно от реальных рабочих проблем.
Даже расход ресурсов на поддержание ее актуальности минимален, ведь такие мало детализированные документы практически не нуждаются в изменениях – на этом уровне деятельность организации довольно стабильна.
Вторая ситуация.
В организации разработана очень детальная документация, которая четко регламентирует каждый шаг выполнения процесса. Но ее внедрение привело к неожиданным результатам:
· Сотрудники жалуются, что они теперь выступают только в роли исполнителей инструкций, что уменьшилась возможность для творчества; как следствие – снижается мотивированность сотрудников и их ответственность за конечный результат работы;
· Потребители жалуются, что организация стала менее гибкой, хуже реагирует на их нестандартные запросы и особые ситуации, что проблемы, которые раньше решались оперативно и неформально теперь или не решаются совсем (они не отражены в описаниях процессов), или решаются через сложную и длинную процедуру;
· Руководство ощущает, что организация потеряла гибкость, хуже и медленнее реагирует на новые возможности, если они не задокументированы в описаниях процессов.
Третья ситуация.
Организация разработала большое количество очень детальных документов.
Исходя из разных причин, она рассматривает возможность ее сокращения (или из соображений, приведенных во второй ситуации, или просто потому, что поддерживать в рабочем состоянии такой объем документации слишком сложно).
Но любые попытки изъять какую-то информацию из документов, сократить или упростить их наталкиваются на контраргумент: эта информация является ценной, она отражает наш обобщенный опыт за много лет, уроки, извлеченные из наших ошибок, ее нельзя трогать.
Основные принципы решения
Главный вывод, который можно сделать из рассмотрения этих ситуаций: это то, что вопрос действительно существует, что организация должна сознавать его и искать на него ответ. Безусловно, худшим вариантом является тот, при котором никто не задает себе вопрос, какими должны быть эти документы: какие вышли, такие и будут. Детальность документов следует сознательно проектировать так же, как и все другие важные характеристики системы (структуру процессов, структуру документов, структуру планов и целей и т.п.).
Заметим, что вышесказанное не означает, что уровень детализации должен определяться на уровне системы и быть одинаковым для всех процессов. Соответствующее решение должны принимать владельцы процессов, ведь документированные описания – это их инструмент для реализации своей ответственности за результаты процессов. Но, во-первых, сами владельцы процессов должны сознательно проектировать уровень детализации документов; во-вторых, могут существовать общесистемные ограничения по этим вопросам (причем, как сверху, так и снизу).
Второй очевидный вывод из анализа приведенных ситуаций: это то, что мы имеем дело с дилеммой, когда у обоих вариантов есть как свои преимущества, так и недостатки. Как и для любой дилеммы, для ее решения можно использовать два подхода: или выбрать компромиссный вариант, который позволяет частично использовать преимущества обоих вариантов, частично нивелировав их недостатки, или искать «третье» нетрадиционное решение, которое позволит в полной мере сохранить сильные стороны обоих вариантов.
Возможный компромиссный вариант для дилеммы относительно детализации описаний процессов очевиден – разработать документы со «средним» уровнем детализации. Не будем останавливаться на нем, только укажем аспекты, которые нужно учесть при выборе этого оптимального среднего уровня:
· Сложность процесса, риски возникновения ошибок при его выполнении;
· Важность процесса, возможные следствия возникновения ошибок (как для самой организации, так и для ее заинтересованных сторон);
· Необходимость обеспечения гибкости при выполнении процесса, реагирование на непредусмотренные внешние возможности или риски;
· Стабильность процесса, частота внесения изменений в порядок его выполнения и важность этих изменений (этот вопрос будет детально рассмотрен ниже; чем чаще вносятся изменения, тем большей может быть потребность в детальном документе);
· Уровень квалификации исполнителей процесса (и возможность поддерживать его в будущем, в частности – уровень текучести среди исполнителей);
· Уровень мотивированности исполнителей процесса (насколько они будут использовать предоставленную им свободу действий для выбора оптимальных вариантов с точки зрения организации или простейших вариантов со своей точки зрения).
Что касается «более глубокого» оптимального решения, то оно должно сохранить и соединить преимущества обоих подходов: обеспечить возможность детального определения процесса (для управления им, сохранения знаний, обучения) и, в то же время, гибкость в его выполнении и заинтересованность персонала в поиске лучших путей выполнения. Должна быть обеспеченная «гибкая стандартизация» или «гибкая детализация» описаний процессов.
В традиции, принятой в отечественных организациях, понятие «стандартизация» и «гибкость» являются противоположными. Возможно, такое представление пошло еще от советских ГОСТов: дескать, стандарты являются очень негибкими, редко пересматриваются и могут устареть еще до пересмотра, и воспринимаются как внешняя данность, на которую организация не имеет никакого влияния.
Но существует и противоположный взгляд, при котором стандартизация не является противоположностью гибкости и усовершенствованию, а их обязательным условием. Ведь если процесс выполняется по неизменной схеме на протяжении продолжительного времени, потребность в детальном описании этой схемы минимальна: исполнители и так выучат эту схему, а все несогласования «притрутся» в процессе работы. Если же порядок выполнения процесса изменяется регулярно, то будет очень проблематично обеспечить его эффективность без стандартизации. Очевидно, что детальное описание процессов нужно для того, чтобы обеспечить оперативное внедрение изменений: возможность быстрого обучения персонала новой схеме работы и эффективного контроля за тем, чтобы его работа отвечала новым требованиям. При частых изменениях процесса организация просто не имеет возможности ждать, когда исполнители выучат новый порядок работы «на практике», за это время он сам может успеть устареть. Менее очевидным, но не менее важным фактором является то, что необходимость отражения изменений в документированном описании процесса требует глубокого анализа нового порядка работы, проверки его согласованности, обсуждения всех возможных проблем – еще на этапе подготовки к внедрению изменения. А принятие решения об изменениях без такого предварительного обсуждения – это необходимость тратить значительное время на выявление проблем и поиск путей их устранения уже после внедрения. Короче говоря, изменения в порядок выполнения процесса вносятся значительно легче, если есть конкретный документ, в который можно эти изменения записать.
Для того, чтобы документированные описания процессов действительно заработали в пользу гибкости и усовершенствования подходов, нужно изменить их восприятие персоналом и руководством. Они должны восприниматься не как ограничения, которые навязываются исполнителям процессов, а как отражение наилучшей существующей практики выполнения работ (определение, наиболее распространенное в Японии). Но очевидно, что представление о наилучших вариантах выполнения работ постоянно изменяется, по мере накопления нового опыта – именно в этом и заключается организационное обучение, – соответственно, должны изменяться и описания процессов. С этой точки зрения, если описание процесса остается неизменным на протяжении продолжительного времени, это свидетельствует о том, что владелец процесса не в полной мере выполняет свои функции: не анализирует накопленный опыт и не использует его для выделения лучшей практики, которую нужно стандартизировать, или возможных рисков, которые следует предотвращать. Можно сказать, что при таком подходе стандарты существуют не для того, чтобы их выполняли не задумываясь, а для того, чтобы их пересматривали.
Конечно, для того, чтобы описанные принципы работали на практике, нужно, чтобы внесение изменений в документ, содержащий описание процесса, было простым и оперативным. Иначе окажется, что исполнителям проще или вообще не стараться совершенствовать процесс (тогда описания процессов превратятся в тормоз для развития организации), или совершенствовать порядок работы, не отражая его в документах (тогда они превратятся на груду устаревших бумаг). Условий для простого внесения изменений в описание процессов есть два: простая и удобная процедура пересмотра документов, а также форма документов, которая упрощает внесение изменений.
Ниже приведены возможные решения для внедрения вышеописанных принципов в деятельность организации.
Многоуровневые процессы
Безусловно, одним из главных факторов, которые делают изменения в описаниях процессов осложненными и растянутыми во времени, является необходимость утверждать их на уровне высшего руководства организации (как правило – лично первого руководителя). При том, что далеко не всегда первый руководитель имеет возможность и желание действительно анализировать содержание документа, эффективность предложенной схемы выполнения процесса. Если же описание процесса является очень детальным, он может содержать такие детали, в которые первому руководителю действительно нет смысла вникать.
Альтернатива такому подходу понятна: должна существовать многоуровневая структура документов, которые утверждаются руководителями разных уровней самостоятельно. На первом этапе такая структура может быть хотя бы двухуровневой – более общее описание процесса, которое утверждается первым руководителем, и его детализированное описание, которое утверждается владельцем процесса. При этом в первом описании определяются требования относительно выполнения процесса, выдвигаемые первым руководителем и которые являются важными для него – их выполнение он готов контролировать лично. Во втором, детализированном описании, владелец процесса определяет, как именно он будет реализовывать требования высшего руководства, как он будет организовывать процесс, чтобы обеспечить достижение поставленных перед ним целей. Такой подход позволяет более гибко руководить порядком выполнения процесса и вносить изменения в документы, в которых он описан. Кроме того, он способствует более четкому определению роли владельца процесса, определению его полномочий и их размежеванию с полномочиями первого руководителя. Если детальнее рассмотреть соотношение этих документов, можно выделить такие ситуации:
· определенная деятельность вообще не регламентирована в общем описании процесса и описывается только в детализированном (например, первый руководитель не интересуется тем, как именно проводится изучение ожиданий потребителей, все что его интересует, это требования к выходу процесса – получение дважды в год отчета, содержащего определенный объем информации; схему сбора этой информации описывает владелец процесса в детализированном описании);
· определенная деятельность обозначена в общем описании и не раскрывается в детализированном (первый руководитель определил в общем описании, что дважды в год должно проводиться анкетирование 50 наибольших потребителей и перечень вопросов для него согласовывается на совещании по стратегическому развитию; владелец процесса решил, что этой информации достаточно для него и она не нуждается в дополнительной детализации);
· определенная деятельность обозначена в общем описании и раскрыта владельцем процесса в детальном (первый руководитель определил, что дважды в год должно проводиться анкетирование ключевых потребителей по согласованной анкете и подаваться отчет; владелец процесса решил, что для успешного выполнения этой работы ему нужно детально описать порядок разработки анкет, формирования выборки потребителей, распространение анкет и контроля их возвращения и т.п.);
· определенная деятельность обозначена в общем описании, оно же содержит требования относительно ее конкретизации и уточнения в дет
В дальнейшем, такая двухуровневая структура документов может развиваться до многоуровневой. Оптимальным путем для реализации этого является углубление процессного подхода: определение процессов низших уровней, их границ и владельцев. Конечно, можно создать систему, в которой детальные описания составляющих элементов процесса разрабатываются и пересматриваются руководителями отделов, цехов, участков. Но будет более эффективно, если эти работы будут выполнять те же люди, но с полномочиями владельцев процессов низших уровней. Принципиальная схема остается той же: владелец процесса высшего уровня определяет требования к порядку выполнения работ, которые он считает обязательными, а владельцы процессов низшего уровня развивают и уточняют их, определяют, как именно они будут их выполнять. В идеале, такая схема должна быть распространена на руководителей всех уровней. Конечно, она будет требовать существенного пересмотра роли руководителей низших уровней: они должны быть не только диспетчерами, которые доводят до подчиненных решения высшего руководства, и надзирателями, обеспечивающими и контролирующими выполнение этих решений, а настоящими руководителями, у которых есть понятные полномочия и которые отвечают за их эффективную реализацию.
Вспомним вышеприведенное определение процесса как наилучшей существующей практики выполнения определенных работ. Накопление знаний в процессе выполнения работы, поиск путей ее усовершенствования, выделение наиболее эффективных методов выполнения работы и обеспечение их применение – все это должно быть неотъемлемой функцией каждого руководителя. И наилучшим образом эти функции могут быть реализованы, если руководитель является «владельцем» документа, определяющего детальный порядок выполнения работы в области его ответственности и может самостоятельно вносить в него изменения (в рамках, определенных в документах, утвержденных руководителями высших уровней). А наилучшим путем для согласования таких документов, ведущихся многими руководителями на разных уровнях, является применения процессного подхода с четким определением и согласованием границ и целей процессов, их входов и выходов (а соответственно – внутренних потребителей и поставщиков, с которыми нужно согласовывать изменения).
При таком подходе постоянный пересмотр соответствующего документа становится не просто полномочием, а обязательной функцией руководителя (точнее, отражением того, что он выполняет свою функцию накопления и применения новых знаний о процессе). И здесь уже можно сказать, что если руководитель, который является владельцем процесса определенного уровня, на протяжении продолжительного времени не вносил изменений в документированное описание этого процесса, к нему должен возникать вопрос - выполняет ли он функцию владельца процесса.
Конечно, для эффективной работы описанной схемы, важно чтобы форма документов упрощала внесение изменений в них (включая обеспечение согласованности разных документов: как «по горизонтали» между документами одного уровня, которые описывают сопредельные процессы, так и «по вертикали» между документами разных уровней, которые описывают один процесс). Оптимальным кажется использование простой, графической структуры документов (в виде блок-схем, таблиц, возможно – рисунков).
Особенно удобным может быть представления документов в электронном виде. Это может позволить:
· упростить работу по отражению изменений в экземплярах действующих документов (использование классических методов управления изменениями в бумажных документах является довольно трудоемким и может отразить желание постоянно просматривать документы);
· при использовании соответствующих программных систем – автоматизировать выполнение рутинных работ, связанных с внесением изменений в процессы (проверка согласованности описаний процессов, определение влияния изменений на должностные инструкции и положение о структурных подразделениях и т.п.).
Обязательные требования и рекомендованная практика
Одной из возможных вариаций описанной системы являются включения в документированные описания процессов не только обязательных требований относительно их выполнения, но и лучшей практики, которая имеет не обязательный, а рекомендованный характер. Такой шаг является логическим развитием тезиса о том, что описания процессов отображают лучшую практику их выполнения. А такая практика может быть как желательной, так и обязательной к использованию. Причины того, что определенные требования относительно порядка выполнения процесса определяются именно как рекомендованные могут быть разными:
· Недостаточная проверенность и апробированность предложенных подходов;
· Недостаточная квалификация всего персонала, привлеченного к выполнению процесса, для того, чтобы определить подходы как универсальные;
· Необходимость сохранения гибкости при выполнении процесса, нецелесообразность его слишком жесткой регламентации.
Если по этим или другим причинам определенные подходы к выполнению процесса нецелесообразно определить как обязанности, но есть желание зафиксировать знание относительно этих подходов – помочь может статус рекомендованной практики.
Иногда организации вводят эти два подхода: выделение лучшей практики и процессный подход независимо друг от друга. Создается база лучших практик (как правило – во внутренней компьютерной сети), определяются пути ее пополнения, выполняются определенные шаги по ее пропаганде и распространению – но все это без связи с процессами и их документированными описаниями. В лучшем случае структура базы лучших практик строится на основе процессной структуры. Такое разделение может привести к проблемам как с пополнением базы, так и с ее использованием. Во-первых, с точки зрения соответствующих руководителей выделение новых лучших практик становится отдельной работой, наравне с усовершенствованием порядка выполнения процесса: а на две отдельных работы всегда сложнее найти время и ресурсы. Кроме того, возникает риск того, что обязательные требования и лучшая практика выполнения одной и той же работы могут или дублироваться, или противоречить друг другу. Но наиболее серьезная проблема при построении «отдельной» базы лучших практик – обеспечение ее реального применения производителями работ. Ведь не совсем понятно, в каких именно ситуациях исполнитель должен «заглянуть» в базу и поискать там рекомендации относительно лучших путей выполнения своей работы.
Поэтому более эффективным может быть вариант, когда и требования, и пожелания к выполнению процесса описываются совместно, в одном документе (как вариант: документ, который описывает требования, содержит ссылку на описания лучших практик). Это может быть особенно удобно, если эти документы представлены в виде информационной системы на электронных носителях с возможностью перекрестных ссылок между ними. Но главным является даже не их общее описание, а общая разработка, проектирование работ, общее определение того, что именно в работе является обязательным, а что - желательным, чем можно пожертвовать ради гибкости, а чем – нет. Введение в описания процессов рекомендованной практики облегчит дилемму, с которой сталкиваются владельцы процессов: включение определенных требований в описание процессов может уменьшить их гибкость, а «не включение» - приведет к потере ценного опыта.
Общее проектирование этих составляющих позволяет также лучше учитывать их взаимодействие при пересмотре процессов. В частности, могут выполняться такие действия:
· рекомендованная практика может получать статус обязательных требований (если она подтвердила свою высокую эффективность по сравнению с другими вариантами выполнения процесса, стала общеупотребительной);
· часть обязательных требований может переводиться в категорию рекомендованной практики (если стало важным обеспечить гибкость в выполнении процесса или если появилось желание попробовать другие варианты выполнения работ);
· рекомендованная практика может изыматься из документа (если она оказалась неэффективной или если появилась лучшая практика).
Обратим внимание на один широкоизвестный пример документа, который содержит как требования, так и рекомендации относительно выполнения работ – стандарт ISO 9004. Структура его известна: требования к определенной деятельности взяты из стандарта ISO 9001 и выделены рамочкой, а дальше идут комментарии относительно возможных путей реализации этих требований. Заодно этот пример может успокоить те организации, которые волнуются относительно реакции органа по сертификации на подобную структуру документов.
Вводя в документированные описания процессов «необязательные» элементы организация должна определить их статус, например:
· абсолютно необязательные рекомендации, информация к размышлению, решение о применении которой принимается исполнителем;
· рекомендованная схема, которая применяется в большинстве случаев, но исполнитель может отступать от нее по собственному решению (например, если потребитель предъявляет нестандартные требования, для удовлетворения которых нужны нестандартные действия);
· «почти обязательная» схема, когда отклонение от нее возможны, но они должны регистрироваться исполнителями или согласовываться с руководством (как вариант – руководство должны информировать о таких отклонениях постфактум).
Конечно, возможен вариант, когда организация включает в описания процессов, рядом с обязательными требованиями, еще и рекомендации нескольких разных уровней «необязательности», но на практике такая ситуация маловероятна. Такая система может быть слишком сложной как для ее проектирования владельцами процессов, так и для ее понимания исполнителями.
Для того, чтобы система документирования лучшей практики выполнения процессов успешно действовала, важно определить источник информации о такой практике и схему сбора этой информации. Ведь если обязательные требования и ограничения относительно выполнения процессов задаются сверху, от руководства, то лучшая практика может рождаться в разных местах, чаще всего – на уровне отдельных исполнителей. Поэтому ее выделение и сбор являются важной задачей, без решения которой соответствующие разделы в описаниях процессов могут просто оставаться пустыми.
Возможными источниками информации о лучшей практике могут быть такие:
· внутренние аудиты (их процедура может предусматривать выявление и фиксацию отклонений от стандартного уровня работы не только «вниз» – несоответствия, но и «вверх» – лучшие практики);
· отчетность о выполнении процессов или работе подразделений и ее анализ (особое внимание должно уделяться случаям значительного улучшения результатов и выделению причин такого улучшения);
· внутренний бенчмаркинг (может проводиться на основе сопоставления отчетности или в других формах – если одно подразделение, специалист и т.п. достигли значительно лучших результатов, чем другие – должны выделяться причины этого);
· предложения персонала относительно лучшей практики (в отличие от традиционных предложений по усовершенствованию, они могут быть подтверждены собственным опытом: не «я предлагаю делать», а «я сделал и получил положительные результаты»);
· внешнее обучение и внешний бенчмаркинг.
Заметим, что введение в описания процессов такого понятия, как рекомендованная лучшая практика позволяет распространить процессы на так называемые «мягкие» или «гибкие» составляющие системы управления (на английском языке - soft), т.е. на те, которые сложно или нецелесообразно алгоритмизировать и которые, соответственно, сложно описать в терминах обязательных требований к порядку их выполнения. Примерами такой деятельности могут быть:
· действия по развитию корпоративной культуры, распространение и применение системы ценностей и т.п.;
· мотивация персонала, его привлечение к процессам усовершенствования и т.п.;
· развитие партнерских отношений с потребителями, поставщиками и т.п.;
· глобальный анализ деятельности организации, определение стратегических направлений ее развития, управление стратегическими изменениями.
Разработать алгоритмы выполнения этих действий хотя бы с минимальным уровнем детализации (чтобы они несли содержательную нагрузку) может быть сложно. Поэтому, на первом этапе, можно ограничиться описанием основных принципов, рекомендаций, пожеланий относительно их выполнения. А уже в дальнейшем, накопив определенный опыт управления этой деятельностью в рамках процессного подхода, можно рассматривать целесообразность более глубокого документирования.
Внедрение в описания процессов рекомендованной практики является показательным и с точки зрения стиля отношений между руководством и персоналом организации. Речь идет о том, что руководство может не только предъявлять требования к сотрудникам и контролировать их выполнение, но и советовать их, предлагать, подсказывать. Руководство показывает, что оно доверяет сотрудникам самостоятельно принимать решение о том, как лучше действовать в конкретной ситуации, использовать ли эти рекомендации.
Завершая статью, следует сказать несколько слов о путях общего использования двух указанных подходов: создания многоуровневой структуры описаний процессов и выделения рекомендованной практики их выполнения. Конечно, если организация решила пойти по этому пути, соответствующие шаги должны быть четко спроектированы и согласованы. Например, возможным вариантом, который помог бы упростить внедрение новой системы, является такой: на первом этапе руководители низших уровней не описывают обязательные требования к выполнению процессов, а ограничиваются разработкой рекомендаций относительно выполнения требований, оформленных высшим руководством (но эти рекомендации сразу должны быть связаны с первоначальной структурой).