Определяем правила документирования процессов

Традиционно правила документирования процессов носят название «Соглашение об описании процессов». Не обязательно именно так называть документ, но обязательно письменно договориться внутри организации, как будут документироваться процессы.

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

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

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

– определение минимальных требований к документации;

– разработка эталонных документов;

– окончательное оформление правил.

Шаг 1. Согласуйте необходимый минимум требований к документации

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

Табл. 12 Минимальные общие требования к документированию процессов

Шаг 2. Разработайте эталонную документацию

Есть компании, которые создают стандарт по оформлению стандартов.

Он иногда так прямо и называется – СТП «Правила оформления СТП».

Мы категорически не рекомендуем так делать! Этот документ не способен выполнить возложенную на него задачу: разъяснить участникам проекта, в особенности тем, кто занимается разработкой и оформлением документов, что именно они должны сделать. Почему? Читая такой документ, никак нельзя отделаться от ощущения двойственности. На что же обращать внимание?

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

Шаг 3. Создайте правила документирования процессов

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

Рекомендуем следующую структуру стандарта процесса. Модифицируйте ее под себя:

Табл. 13. Примерная структура стандарта процесса

Особое внимание хочется обратить на пункт «Операционная карта». Графические объекты часто используются для отображения хода процесса – блок-схем процессов и подпроцессов. Что собой представляет такая блок-схема?

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

Рис. 13. Операционная карта процесса «Стимулирование продаж» (подпроцесс «Мерчандайзинг»)

Эта блок-схема представляет собой графическое изображение процесса с использованием простого набора символов и правил их применения.

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

Совокупность используемых символов и правил построения схем называется графическим языком, или графической нотацией. И хотя есть много разных графических нотаций, подчас довольно сложных, в собственной практике мы настоятельно рекомендуем клиентам пользоваться максимально простым графическим языком. Важно, чтобы блок-схемы можно было рисовать с помощью легкодоступных и относительно дешевых редакторов, например MS Visio или даже MS Word. Применение сложных графических нотаций, а также дорогостоящих специализированных программ для моделирования процессов способно из-за неизбежной смены персонала и прочих изменений в компаниях привести к ситуации, которую один из наших заказчиков метко описал так: «Процессы, конечно, описаны, но никто из нас не может понять нарисованные схемы, никто не может внести в них изменения, так как мы не владеем соответствующей компьютерной программой, хотя она у нас и есть. Как следствие – описания, на которые было потрачено много денег, времени и сил, оказались по факту никем не востребованными».

Почему графические объекты так популярны и какую пользу они приносят?

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

2. Блок-схема более однозначна. Разумеется, что графическое представление информации неизбежно ведет к тому, что часть сведений не отражается

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

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

4. Описание процессов в форме блок-схем упорядочивает мышление. Чаще негласное, а иногда и официальное правило гласит, что блок-схема должна отображаться на одном листе формата А4. Это означает, что в процессе может быть выделено максимум 20–25 операций или групп операций. Такое ограничение заставляет внимательно отнестись к выделению отдельных операций, их последовательности и комбинациям.

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

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

При изложении почти любого вопроса отталкиваются от отдельной операции. Например, при определении документооборота нужно обратить внимание не на документационное обеспечение процесса в целом, а на документы, используемые и создаваемые в ходе выполнения конкретной операции. Что это значит на практике? Все операции на блок-схеме нумеруются. Далее, когда мы описываем документооборот процесса и правила выполнения отдельных операций, мы придерживаемся той же нумерации, что и на блок-схеме. Получается, мы соотносим используемые и создаваемые в ходе процесса документы, а также конкретику его выполнения с операциями из блок-схемы (табл. 14). Такой подход делает регламент точнее и проще для восприятия и использования.

Табл. 14. Структура пояснительной таблицы из стандарта процесса (выкипировка)

Шаг 4. Определите правила создания блок-схем

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

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