Введение в описание бизнес-процессов. Часть 4

21 Июля 2014

Описание бизнес-процессов верхнего уровня

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

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

Кажущаяся на первый взгляд сложность описания бизнес-процессов является раздутой. Классическая технология описания бизнес-процессов, которая была разработана на заре рождения процессных технологий управления, достаточно проста и состоит всего лишь из двух стандартов описания бизнес-процессов – DFD и WFD. Большинство других современных стандартов, не смотря на другие названия представляют небольшие разновидности и дополнения двух классических подходов DFD и WFD.

Согласно классическому подходу стандарт DFD, который расшифровывается как Data Flow Diagram представляет из себя диаграмму потоков данных, которая используется для описания бизнес-процессов верхнего уровня. В свою очередь стандарт WFD расшифровывается как Work Flow Diagram и представляет собой диаграмму потоков работ, которая используется для описания бизнес-процессов нижнего уровня. У диаграммы потоков работ имеются и другое название – диаграмма алгоритмов. Давайте рассмотрим два этих стандарта, составляющих классическую методологию описания бизнес-процессов.

Построение диаграмм потоков данных – DFD. Стандарт описания бизнес-процессов DFD - Data Flow Diagram переводится как диаграмма потоков данных и используется для описания процессов верхнего уровня.

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

Входы и выходы, которые были показаны при описании окружения бизнес-процесса являются внешними. Внешние входы на DFD-схеме поступают из вне от поставщика процесса, а внешние выходы уходят наружу к клиенту процесса. При построении DFD-схемы бизнес-процесса их нужно перенести со схемы окружения процесса DFD-диаграмму. Для окончательного описания бизнес-процесса остается описать только внутренние информационные и материальные потоки. Каждый из них является выходом одной из работ и в то же является входом для другой.

1
Рис. Диаграмм потоков данных - DFD

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

2
Рис. Пример несовпадения временной последовательности работ и направления движения документа

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

3
Рис. Пример бизнес-процесс верхнего уровня

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

При построении DFD-схемы бизнес-процесса также нужно показать подразделения и должности участвующие и отвечающие за выполнение работ, входящие в состав процесса. Рекомендуется каждой работе присвоить номер или идентификатор, а также использовать два правила при формулировке названия работ.

Правило 1. Названия работы нужно формулировать согласно следующее формуле.

Название работы = Действие + Объект
на которым действие осуществляется

Например, если эта работа связана с действием по продаже продукции, то ее нужно назвать «Продажа продукции», а еще лучше конкретизировать что это за продукция. В данном случае «Закупка» это действие, а «продукция» - объект над которым действие по продаже производится.

Правило 2. При формулировании названия работы нужно стараться использовать краткую и лаконичную формулировку, что повысит эффективность дальнейшей работы по оптимизации бизнес-процесса. Идеальным вариантом является случай когда название работы формулируется при помощи 2-3 слов. В крайнем случае нужно стремится использовать в названии не более 50 символов. В сложных случаях также рекомендуется для каждого краткого названия работы сделать ее подробное описание, которое поместить в глоссарий.

При формулировании названий материальных и информационных потоков также нужно использовать подобные правила. В данном случае второе правило используется без изменений, а первое правил формулируется следующей формулой:

Название потока =
Объект, представляющий поток + Статус объекта

Например, если речь идет о продукции, которую отгрузили клиенту, то данный поток нужно сформулировать следующим образом – «Продукция, отгруженная» или «Продукция, отгруженная клиенту». В данном случае «Продукция» это объект, представляющий поток, а <отгруженная клиенту> - статус объекта.

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

Другим наглядным представлением бизнес-процессов компании является сеть процессов, которая представляет DFD-схему, построенную на основе бизнес-процессов, составляющих дерево.

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

4
Рис. Разработка сети бизнес-процессов

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

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

5
Рис. Пример сети бизнес-процессов

Описание бизнес-процессов нижнего уровня

Декомпозиция бизнес-процесса. При построении DFD-схемы бизнес-процесса необходимо использовать правило «7», согласно которому нужно выбрать такой уровень абстрагирования и детализации, при котором схема бизнес-процесса будет состоять в среднем из семи работ. Использование большей детализации и соответственно количества работ приведет к сильному усложнению схемы и снижению возможности проведения качественного анализа бизнес-процесса. Это в свою очередь связано с тем, что человек может эффективно оперировать не более чем семью различными объектами. Использование небольшой детализации и меньшего количества работ на схеме бизнес-процесса приведет к тому, что работы будут достаточно укрупненными для того и это также уменьшит возможность проведения их качественного анализа и оптимизации.

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

При классическом подходе описания бизнес-процессов для разработанной схемы второго уровня может использоваться как DFD, так и WFD формат описания в зависимости от уровня и глобальности работы. Если работа глобальна и ее невозможно представить в виде временной последовательности более мелких работ, то используют DFD-стандарт ее описания. В противном случае работу целесообразно описать посредством WFD - модели.

В случае необходимости работы на схеме процесса второго уровня могут быть декомпозированы на схемы бизнес-процессов третьего уровня и т.д. Декомпозиция бизнес-процесса должна продолжаться до тех пор, пока не будут достигнуты цели его описания. В данном случае удобно использовать понятия вложенный процесс или подпроцесс. На рисунке процессная схема работы 3 является вложенным процессом или подпроцессом процесса верхнего уровня. Аналогичным образом процессные схемы работ 3.1 и 3.4 являются вложенными процессами или подпроцессами процесса второго уровня.

Декомпозиция бизнес-процесса
Рис.  Декомпозиция бизнес-процесса

В итоге описание бизнес-процесса представляет собой иерархически упорядоченный набор DFD и WFD схем, в котором схемы верхнего уровня ссылаются на схемы нижнего уровня. При этом схемы DFD, используемые на более высоких уровнях декомпозируются или ссылаются на схемы DFD и WFD. Cхемы WFD, используемые на более низких уровнях декомпозируются или ссылаются только на схемы WFD

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

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

Диаграмма потоков работ - WFD
Рис. Диаграмма потоков работ - WFD

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

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

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

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

Итак с помощью двух классических схем DFD и WFD можно описать подробно все бизнес-процессы компании.

Вопросы, решаемые перед началом описания бизнес-процессов

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

1. Достижение заказчиком понимания создаваемого описания процессов. Наиболее часто встречающейся ошибкой является описание бизнес-процессов ради самого описания. В большинстве случаев такой подход часто приводит к негативной реакции бизнеса, который не получает значимых результатов после нескольких месяцев работы внутренних бизнес-аналитиков, ведь сама модель процесса для бизнеса значимым результатом не является. Это подрывает веру топ-менеджеров в процессный подход вообще и в описание бизнес-процессов в частности. Далее, как правило, следуют организационные решения, после которых аналитические подразделения, описывающие процессы, сильно теряют в численности. Этого можно избежать, если еще на этапе организации работ четко определить, кто является потребителем создаваемого описания и какой результат он ожидает. И лучше, если таких пользователей будет несколько. В первую очередь, это должны быть сами бизнес-подразделения, заинтересованные в регламентации и оптимизации процессов. Затем департаменты, отвечающие за внедрение системы менеджмента качества, поскольку без процессного управления настоящего качества не добиться. Еще одним заказчиком описания процессов является подразделение управления информационными технологиями, ведь модель процессов облегчает формализацию требований к внедряемым информационным системам. Определив потребности можно избавиться от множества лишней работы, что в свою очередь позволит намного быстрее получить значимый для бизнеса результат.

2. Избавление от неопределенности методологии описания процессов. Средний проект по описанию бизнес-процессов в крупной компании может привести к появлению не одной тысячи моделей. Если представить, что все они нарисованы по-разному – ведь их рисуют разные сотрудники – полученный результат скорее всего можно будет выкинуть в корзину. Именно поэтому важно не только определиться с заказчиками и зафиксировать их требования, но и определить четкие правила для прорисовки бизнес-процессов. Во многих компаниях документы, закрепляющие методологию описания бизнес-процессов, называются Соглашениями по моделированию. Без данного документа описание процессов не приведет к положительному результату. В нем необходимо закрепить используемые для моделирования нотации, глубину описания процессов, взаимосвязь моделей между собой, перечни заполняемых атрибутов, перечень получаемых на основании моделей документов, правила именования объектов и т.д. И после того как такой документ появился, необходимо контролировать его исполнение в проекте, что обеспечит унификацию создаваемых моделей и возможность их дальнейшего использования в различных проектах.

3. Уход от излишней подробности описания процессов. Многие бизнес-аналитики «закапываются» в детализацию бизнес-процессов, описывая отдельные действия сотрудников. Часто это приводит к росту числа создаваемых моделей, а значит и росту трудоемкости, фактически, без особой пользы, поскольку излишняя детализация часто не дает информации для дальнейшей оптимизации процессов, а ресурсы потребляет значительные. На практике доказано, что каждый новый уровень детализации процессов увеличивает объем моделей на порядок, и поэтому необходимо очень внимательно относиться к необходимости и достаточности детализации при их описании. Если необходимо лишь оптимизировать и закрепить ответственность между подразделениями, то следует описывать процессы только до уровня департаментов. Если их описание создается для целей автоматизации или регламентации на уровне отдельных исполнителей, то необходимо описывать до этого уровня. Более подробное описание должно быть в обязательном порядке обосновано со стороны заказчиков.

4. Повышение внимания к связным областям. Очень часто бизнес-процессы рисуются без понимания используемых информационных систем и документов. Нарисованные таким образом маршруты работ невозможно анализировать в дальнейшем, что делает созданные модели бесполезными для использования. Именно поэтому, начиная описание процессов, необходимо определить и закрепить какие элементы из их окружения необходимо описать. В первую очередь, это ролевая и организационная структура, еще одной необходимой предметной областью являются поддерживающие бизнес-процесс информационные системы, а также носители информации, используемые в нем. Для некоторых случаев описание процессов может быть расширено в части операционных рисков, ключевых показателей, требований к информационным системам и т.д. и т.п. Фактически модель процессов становится «связкой» между различными предметными областями, что повышает ее ценность в разы.

5. Масштабное описание процессов без автоматизации, анализа и оптимизации. Для бизнеса очень важно получить быстрый результат от сделанных в проект инвестиций. Совершенно логично, что под таким углом зрения многие топ-менеджеры рассматривают и проекты по описанию бизнес-процессов и внедрению процессного управления. И если запланировать сначала масштабное описание всех бизнес-процессов, что в крупной компании может занять не один год, а после этого начать автоматизацию ключевых процессов, что тоже не быстро, и лишь через несколько лет заняться анализом и оптимизацией процесса, есть большая вероятность, что подразделение, отвечающее за эту задачу, может прекратить свое существование раньше, чем сможет показать значимый для бизнеса результат. Для того чтобы показать результат как можно скорее, необходимо рассматривать бизнес-процессы последовательно, на каждом из них отрабатывая полный цикл управления процессом от описания к автоматизации, анализу и оптимизации. В таком случае уже через короткое время можно будет увидеть эффект от совершенствования бизнес-процессов, что докажет топ-менеджменту правильность выбранного пути.

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

7. Избежание попыток описания бизнес-процессов, там, где их не следует описывать. Многие российские компании управляют через назначение и контроль поручений. И если начать описание процессов в такой организации, то с большой вероятностью успешно закончить его не удастся, поскольку вариативность существующих маршрутов прохождения задач по компании не будет укладываться в формат процессных моделей. Особенно часто это проявляется на высших уровнях управления коммерческом и госсекторе. С учетом данного фактора нужно понимать, что процессный подход в целом, как и описание процессов в частности, наиболее эффективно в операционном ядре организации, поскольку именно там находятся массовые бизнес-процессы производства товаров или оказания услуг. Именно в операционном ядре описание бизнес-процессов можно выполнить намного проще, ведь деятельность в нем носит регулярный характер, что дает возможность ее дальнейшей автоматизации, анализа и оптимизации. Итак, всему свое место: BPM – для повторяющейся деятельности, поручения – для уникальных задач, а в широком промежутке между ними – кейс-менеджмент.

8. Отказ от неопределенности способа внедрения усовершенствованных процессов. Совершенно логично, что созданное описание процессов должно служить основой для их дальнейшей оптимизации. Если нарисовать процесс «как должно быть» и не закрепить его в организации, то он так и останется «на бумаге». Именно поэтому способ внедрения усовершенствованных процессов в компании должен определяться заранее и желательно еще до старта работ по описанию процессов. Наиболее простой и понятный способ внедрения процессов «как должно быть» – регламентация. В данном случае описание форматируется в виде регламента, который закрепляется приказом руководителя. Однако, несмотря на всю простоту создания регламента, контроль его исполнения может быть затруднен или экономически неэффективен. Именно поэтому одним из наиболее результативных способов закрепления процесса «как должно быть» является внедрение информационной системы, и в частности системы класса Business Process Management System (BPMs), что позволяет закрепить не только маршруты и правила в рамках бизнес-процесса, но и поддержать и структурировать основные информационные потоки в рамках процесса.

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

Принципы регламентации бизнес-процессов

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

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

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

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

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

Регламентация деятельности работников и подразделений. В данном случае разрабатывается документация, связывающая функциональное и процессное управление. Такими документами в основном являются положения о подразделениях и должностные инструкции. Для примера приведен алгоритм формирования должностной инструкции заведующего фермой для сельскохозяйственной компании. Данный вид регламентации является наиболее простым, так как представляет собой лишь сбор функций должностного лица в различных процессах (или сбор функций подразделения в различных процессах).

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

Принцип 1. Регламентировать только то, что действительно необходимо

Многие компании погрязли в куче ненужных бумаг, которые по большей части устарели и не имеют связи с реальностью. Часто пытаются описывать и регламентировать процессы, не разобравшись с существующей базой документов, что порождает в дальнейшем еще большие проблемы. Регламентировать нужно только то, что действительно необходимо, и лишь на том уровне, который действительно необходим. Понимание нужной степени регламентации является достаточно сложной задачей для руководителей организации. Но если они подходят к этому вопросу формально, то получают формальный (т.е. фактически ненужный) результат.

Следует подчеркнуть, что как разработка, так и контроль исполнения регламентов стоят весьма существенных денег. Плохие регламенты не только не работают, они приводят к потерям ресурсов предприятия.

Пример. В компанию на должность начальника структурного подразделения численностью более 50 человек был принят новый руководитель. Входя в курс дел, он ознакомился с нормативной базой компании и обнаружил около 40 документов, которые имели какое-либо отношение к деятельности, выполняемой его подразделением. Более пристальный анализ этих документов показал, что сформулированные в них требования устарели и давно не выполняются. В самом подразделении было около 20 документов, из них работало только 4, которые, по сути, представляли собой формы, с помощью которых осуществлялось взаимодействие с другими подразделениями. Руководителю пришлось выстраивать нормативную базу подразделения заново.

Принцип 2. Стремиться к простоте

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

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

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

Принцип 3. «Лучше толще, но меньше»

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

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

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

Специально следует отметить, что в настоящее время практически все организации имеют возможность хранить и использовать НМД только в электронном виде. В этом случае вопрос увязки документов между собой и внесения изменений упрощается.

Пример. Компания разработала стандарт для описания бизнес-процессов. На его основе было описано несколько процессов верхнего уровня. Часть стандартов на процессы верхнего уровня оказались «ссылочными» документами, поскольку они содержали только ссылки на описания соответствующих подпроцессов (7-8). Описание подпроцесса занимало около 6-7 листов, причем содержательная часть размещалась на 1-2 из них. Получалось, например, что 8 регламентов на подпроцессы в совокупности включали около 40 страниц, не содержащих информацию о выполнении процессов. Если бы реальные описания подпроцессов были включены в один регламент, то удалось бы сократить общий объем документации на эти 40 страниц, причем только по одному документу. Безусловно, такая ситуация раздражает пользователей, так как чтобы понять суть изложенного, приходится читать несколько разных документов, получая большой объем ненужной информации.

Принцип 4. Учет квалификации персонала и культуры компании

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

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

Принцип 5. Перенесение акцента при детализации процессов с описания управления на детальное описание технологии выполнения процесса

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

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

Что же нужно описывать в регламентах процессов верхнего уровня (т.е. для крупных, масштабных процессов)? В первую очередь – деятельность руководителей по управлению процессом. Такое описание должно включать:

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

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

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

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

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

Почему не работают регламенты процессов?

При выполнении проектов внедрения процессного подхода от руководителей компаний часто можно услышать слова: «У нас в компании регламенты процессов не работают». Как это понимать? Что представляет собой ситуация, когда «регламенты работают?» При попытке идентифицировать проблему, которая у всех на слуху, она как-то ускользает из рассмотрения. Как может «работать» бумажный документ?! Работают люди, механизмы и т.п. Попытаемся сформулировать проблему более точно. Можно предложить следующую формулировку: «выполняемый в компании процесс только в некоторой степени соответствует (или вообще не соответствует) требованиям регламента». То есть процесс выполняется, но не так, как написано в регламенте. Следует отметить, что в данном контексте регламенты понимаются в широком смысле – как любые документы нормативно-методического характера каким-либо образом устанавливающие требования к процессам. Итак, формулировка «неработающий регламент», представляет собой, по сути, констатацию того факта, что требования этого регламента не соответствуют реально выполняемому в компании процессу.

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

Этап 1. Разработка регламента

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

Работа по регламентации процессов может инициироваться в компаниях в различных ситуациях. Как правило, отдельная проектная группа или команда разрабатывает и согласовывает регламенты. Часто эту работу поручают специалистам из отдела развития, менеджмента качества и т.п. Иногда в компанию привлекают внешних консультантов. Общим для всех этих случаев является то, что руководители не выполняют работу по регламентации сами, а поручают ее кому-то из специалистов или консультантов. Фактически, это означает, что руководство не принимает участия в работе по анализу процессов и поиску путей повышения его эффективности!

По итогам работы получается проект регламента процесса, но при этом часто бывает, что:

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

Представленная ситуация схематично показана на рисунке.. Видно, что разработанный проект регламента нельзя использовать для практической реорганизации процесса, если мы хотим что-то реально изменить.

8
Рис. Проблемы при создании регламента процесса

В чем же состоят причины, приводящие к получению неадекватных результатов на этапе разработки регламента? Следует отметить следующие из них:

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

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

Этап 2. Внедрение регламента или «оптимизация» процесса

Границы этапа: с момента начала практической реорганизации процесса на основе требований регламента до момента прекращения этой работы (т.е. до момента, когда регламент кладут «на полку»).

Как правило, регламенты процессов в компаниях утверждают по мере их готовности (согласования), а не практического внедрения. Хотя некоторые руководители все-таки находят силы и время «внедрять» разработанные регламенты. Само словосочетание «внедрение регламента» вызывает вопросы – что и куда мы собираемся внедрять?! Речь должна идти о реальных изменениях в процессах. Но, к сожалению, часто работа по «внедрению регламентов» заканчивается тем, что:

  • регламенты вводятся в действие приказом генерального директора;
  • сотрудников знакомят с регламентами под роспись;
  • запускаются новые (или несколько измененные) формы документов, которые необходимы в соответствии с новыми требованиями регламентов.
  • Иногда даже начинает казаться, что у директора компании есть волшебное слово «Утверждаю», и он всерьез полагает, что с его помощью можно что-то изменить в процессе, написав это слово на титульном листе регламента.

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

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

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

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

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

В целом, для этапа «внедрения регламентов» характерны следующие проблемы:

  • не происходят реальные изменения в процессах;
  • требования, сформулированные в регламентах, выполняются частично или вообще не выполняются.
  • Можно назвать следующие причины проблем на этапе «внедрения регламентов»:
  • по разработанным регламентам нельзя изменять процессы (регламенты не полны, противоречивы и т.п.);
  • руководители не предпринимают усилий для изменения процессов (не организуют процесс, не выделяют ресурсы, не обучают сотрудников, не контролируют соблюдение требований регламентов при выполнении процесса и т.д.);
  • для работы по новым регламентам не хватает необходимых ресурсов;
  • сотрудников не обучают работе по новым регламентам;
  • прочее.

9
Рис. Проблемы при «внедрении регламента»

Основной причиной проблем на данном этапе можно все-таки назвать то, что руководители не меняют процессы на практике, а полагаются только на формальное «утверждение» регламентов.

Выводы

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

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

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

«Минусы» от регламентации бизнес-процессов

Рассмотрим «минусы» от регламентации бизнес-процессов. Как правило, к их числу относят следующее:

  • значительные затраты на регламентацию;
  • снижение творчества, инициативы сотрудников;
  • разрушение сложившейся команды руководителей и специалистов;
  • снижение гибкости в принятии решений, осуществлении изменений; как следствие – уход клиентов;
  • дополнительная нагрузка на персонал, снижение производительности;
  • увеличение сроков выполнения процессов из-за необходимости соблюдения регламентов;
  • появление слишком сложных, «забюрократизированных» регламентов, что приведёт к снижению удовлетворенности клиентов;
  • возможность т.н. «итальянской» забастовки;
  • возможности утечки информации о стандартах работы в другие организации;
  • прочее.

Каждый из этих «минусов» может рассматриваться в качестве риска неэффективного внедрения системы регламентации (стандартизации) бизнес-процессов. Рассмотрим последовательно каждый такой «минус».

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

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

Снижение творчества, инициативы сотрудников. Творчество и инициатива нужны не всегда и не везде. Многие процессы должны выполняться только по установленному стандарту. Любая инициатива, ведущая к нарушению стандарта, может обернуться потерями (или более серьезными проблемами). Да, работа будет выполнена, но эффективность этой работы может существенно снизиться. Творчество и инициативу, очевидно, надо приветствовать в области анализа и разработки предложений по совершенствованию деятельности: изменению технологии, применению новых методов и инструментов и т.п. Поэтому внедряя систему жесткого контроля исполнения стандартов, нужно одновременно создавать и использовать систему подачи, анализа, обсуждения и внедрения предложений по улучшению процессов (элементы цикла PDCA профессора Э. Деминга).

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

Проблема творчества и развития, скорее, заключается в другом. Если руководители, устанавливающие регламенты, консервативны и не готовы менять модель деятельности организации с нужной скоростью, то тормозом развития (творчества, инициативы) будут именно они, а не сотрудники, которые по этим стандартам работают. Рядовой сотрудник с «погашенной» инициативой, нанесет этим гораздо меньший вред организации, чем топ-менеджер, последовательно транслирующий в регламентную базу свои устаревшие взгляды на модель ведения бизнеса.

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

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

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

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

Снижение гибкости в принятии решений, осуществлении изменений; как следствие – уход клиентов

Своевременно принятое, грамотное управленческое решение – это здорово! Но на практике неподготовленные, несогласованные, нигде не зафиксированные управленческие решения приводят впоследствии к проблемам различного масштаба. Например, клиент просит нестандартную скидку. Коммерческий директор «гибко» и неформально идет ему навстречу. В итоге, компания теряет деньги, а у собственников возникают сомнения в искренности этого коммерческого директора. С другой стороны, если коммерческий директор по формальным критериям откажет и потеряет контракт с крупным клиентом, собственники будут очень недовольны и т.п. Как же гибкость в принятии решений и осуществлении изменений связана с регламентацией? Для 90% процентов ситуаций регламент является очень полезным инструментом. Он дает возможность принимать обоснованные (по определенной методике) управленческие решения, фиксировать их, и в последующем оценивать эффективность. Остальные 10% исключительных ситуаций должны быть четко обозначены (без детальной регламентации действий сотрудника). При их наступлении управление сразу же должно передаваться на вышестоящий уровень. Таким образом, «гибкость» не будет сведена к безответственности. Руководители четко будут понимать пределы своих полномочий.

Дополнительная нагрузка на персонал, снижение производительности. Предполагается, что сотрудники компании будут тратить часть своего времени на написание регламентов, что снизит производительность труда. Кроме того, по ходу деятельности придется периодически обращаться к регламентам, проверяя соответствие выполняемой работы установленным требованиям.

По первому аргументу можно сказать, что работа по созданию и актуализации регламентов действительно занимает определенное время. Только не рядовых сотрудников, а руководителей. Но для руководителей работа по стандартизации деятельности является одной из важнейших составляющих деятельности по управлению. Они получают зарплату за эту работу. Руководитель обязан организовать свой рабочий день так, чтобы хватило времени на работу с регламентами. Во многом, дефицит времени руководителя связан с неупорядоченностью управляемой деятельности, когда «правила игры» не определены (например, полномочия не делегированы), и сотрудники постоянно обращаются к руководителю с мелкими вопросами, «съедая» его рабочее время.

Что касается второго аргумента, то он является надуманным. Если действительно сотрудники будут периодически сверяться с регламентами при выполнении деятельности, то менеджеры компании должны ликовать – в культуре организации появился новый, важный элемент – «работа по стандартам». Однако в реальности, к сожалению, наблюдается обратная картина (регламенты «не работают»).

Увеличение сроков выполнения процессов из-за необходимости соблюдения регламентов. Этот аргумент аналогичен предыдущему. Предполагается, что после регламентации процессы будет сложнее и дольше выполнять. Если раньше можно было быстро и гибко выполнять работу, достигая нужного результата, то после регламентации придется делать все «по стандарту».

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

Появление слишком сложных, «забюрократизированных» регламентов. Такой риск действительно есть. Он связан с несколькими факторами, в том числе:

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

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

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

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

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

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

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

  • организационную структуру и численность персонала;
  • квалификацию и опыт сотрудников;
  • критерии и алгоритмы принятия управленческих решений;
  • культуру организации;
  • прочее.

Для того чтобы скопировать бизнес компании одного только комплекта нормативно-методических документов явно недостаточно. (Как нельзя, например, стать спортсменом за один день просто повторяя систему тренировок чемпиона).

Отметим, что в настоящее время существуют целые системы информационной безопасности, задача которых в том числе предотвращаться утечку информации из компании.

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

Окончание:   Введение в описание бизнес-процессов. Часть 5

 

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