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