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

Регламент процесса - это инструмент управления 

А структура инструмента зависит от структуры управления. Конечно, можно просто принять содержание и структуру "по умолчанию", но тогда это будет уже из разряда:

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

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

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

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

Раздел 1 – Краткое описание 

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

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

Все пункты краткого описания обязательны для размещения. 

• Название процесса. Несмотря на то, что в регламенте указывается заранее определенное название процесса, все же еще раз напомню. Название процесса должно быть уникальным и отражать его суть. Быть уникальным – это значит, что второго такого названия процесса или функции не существует в вашей компании.
  
• Сквозной номер процесса. Если у вас используется нумерация процессов, то номер должен быть указан здесь. Если нумерации нет - просто пропустите этот пункт. Как правило, если вы используете информационную систему для управления регламентами, то потребность в нумерации отпадает.
  
• Тип процесса. К какому типу относится процесс: основной, вспомогательный или процесс управления.
  
• Цель / назначение процесса. Очень краткое описание того, зачем существует и какие цели преследует бизнес процесс. Описание должно быть таким, чтобы читателю сразу стало понятно, о чем речь.
  
• Владелец процесса. Имя, должность и структурная организационная единица, к которой относится владелец процесса. Можно сразу указать или дать ссылку на контакты владельца процесса. Информация о должности и принадлежности к организационной единице нужна для того, чтобы читателю было понятно - в чьей со структурной точки зрения зоне ответственности находится данный процесс.
  
• Основное событие начала. Основное событие, которое стартует выполнение процесса. Событий начала может быть множество, но всегда существует основное – это такое событие, которое инициирует выполнение процесса с наибольшей вероятностью.
  
• Основной вход. Входов также может быть несколько, но всегда есть что-то самое главное, с чем работает процесс. И да, это может быть целый набор.
  
• Основной поставщик. Название внутреннего процесса, который поставляет вход в рассматриваемый процесс. Если же вход поступает из внешнего источника, то указываем как есть. Например, Поставщик А или Поставщик конкретного продукта. Либо любое другое название, которое позволит однозначно понять, кто вне компании отвечает за поставку входа в процесс.
  
• Основное событие окончания. Событие или условие, при выполнении которого мы считаем процесс завершенным. Событий окончания может быть несколько, но, как правило, только одно является основным, потому что только при наступлении этого события, процесс достигает своей цели. Все остальные события окончания являются отклонениями от основного, желаемого сценария и в этом разделе не указываются.
  
• Основной продукт. Многие процессы производят несколько продуктов. Они могут быть основными (как правило, основной продукт один) и второстепенными. Основной продукт - это то, ради чего существует весь процесс. Ради этого продукта все выполняется.
  
• Основной клиент. У любого продукта есть клиент. Внутренний или внешний. В кратком описании обязательно указать – кто является клиентом рассматриваемого процесса. Под "кто" я понимаю внутренний процесс, конкретное лицо, организационную единицу или внешнего клиента.

Раздел 2 – Границы процесса 

Регламент процесса обязан содержать исчерпывающее описание границ. От того, насколько корректно определены границы бизнес процесса, зависит… ну в общем-то, все. Границы процесса определяют не только входы и продукты процесса, но и, что самое важное, зоны ответственности. За входы и их поставку, за получение продукта и его соответствие требованиям клиентов, за эффективность процесса, за переход права собственности входов и продуктов и так далее. Поэтому описание границ процесса – один из самых важных разделов регламента.

Входы 

Обязательно 

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

Желательно 

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

События начала 

Обязательно 

• Название события. Перечислите все события, стартующие выполнение процесса. Как я уже говорил выше, событий может быть несколько.
  
• Уведомление о событии. Крайне важно не только понимать, но и описать, как участники процесса узнают о том, что произошло событие, которое начинает процесс. Чтобы увидеть вспышку на солнце, нужно смотреть на солнце, не на землю)
  

Желательно 

• Инициатор события – если событие является следствием другого процесса, порождается одним из внутренних или внешних участников, то это необходимо указать. Например, если событием начала является «Получена заявка клиента», то инициатором будет сам клиент. Если мы говорим о процессе Обработка заявок клиентов. Если же заявка поступает в процесс Сборки заказа, то она может поступать из процесса Обработка заявок клиентов.
  
• Связанный вход – если вместе с событием поступает вход (а такое, как вы уже знаете, происходит далеко не всегда), то нужно указать, какой вход связан с событием начала. Из вышеуказанного примера: если событием начала является Получена заявки клиента, то связанным входом будет заявка. Этот пример прост и очевиден, но часто все не так просто.
  

Продукты 

Обязательно 

• Название продукта – название продукта, который производит процесс.
  
• Тип продукта. Как я говорил ранее, есть основные и второстепенные продукты. Основной продукт – это то, ради чего существует процесс. Получение основного продукта - это основная задача процесса. Второстепенные продукты – все остальное, что появляется в результате выполнения процесса и используется где-то еще. С этой точки зрения первичная документация, которая появляется в результате процесса продаж, является второстепенным продуктом.
  
• Клиент – у каждого продукта, основного или второстепенного, должен быть клиент. Если клиента не существует, то процесс не нужен. В регламенте процесса обязательно нужно указать, кто является клиентом каждого продукта.
  
• Характеристики продукта – перечислите характеристики продуктов процесса, которыми они, продукты, обязательно должны обладать до передачи клиенту. Если вернуться к примеру с первичной документацией, то такими характеристиками могут быть: наличие печати и подписи поставщика, наличие подписи ответственного за прием продукции и так далее. Также к характеристикам можно отнести результат выполнения определенных операций. Например, документ проверен до передачи в бухгалтерию. Регламент процесса не может существовать без описания характеристик продуктов.
  
• Требования к продукту – требования к продукту задает его клиент. Требования обязательно вносить в регламент процесса. Это позволит в любой момент проверить, насколько процесс обеспечивает выполнение требований к продукту. Список требований также необходимо рассматривать в качестве соглашения между участниками процесса и его клиентами. Соглашение - это договоренность о том, что участники берут на себя обязательства выполнить требования через механизм реализации процесса.
  

Желательно 

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

События окончания 

Обязательно 

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

Желательно 

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

Это можно сделать с помощью правильного наименования. Если один процесс завершается событием "Отчет Х отправлен", то связанное событие начала должно называться "Отчет Х получен".

Раздел 3 – Выполнение процесса 

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

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

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

Процедуры, бизнес правила и скрипты 

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

Обязательно 

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

Желательно 

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

Время выполнения операций 

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

Обязательно 

• Наименование операции
  
• Минимальное время выполнения
  
• Среднее время выполнения
  
• Максимальное время выполнения
  

Участники процесса 

Здесь необходимо указать роли всех участников процесса.

Обязательно 

• Роль участника
  
• Количество единиц, необходимых для выполнения процесса. Обратите внимание, это не количество человек, которое участвует в выполнении процесса. Количество единиц - это количество каждой роли, которая нужна для выполнения процесса один раз. Если в процессе обслуживания клиентов есть роль «специалист по продажам», то количество будет 1, если только у вас не принято работать с клиентом сразу двум специалистам. При этом роль "кассир", которая также может быть в данном процессе, может выполняться тем же человеком, который выполняет роль специалиста по продажам. Если говорить о процессе монтажа оборудования, в котором задействована целая монтажная бригада, то в таком процессе количество единиц в роли «монтажник» будет явно не 1.
  

Желательно 

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

Ресурсы и инфраструктура 

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

Обязательно 

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

Желательно 

• Тип ресурса – намного лучше, когда ресурсы разбиты по типам. При этом типы ресурсов могут соотноситься с типами согласно управленческого и/или бухгалтерского учета. Это позволит упростить анализ. Наиболее распространенные типы ресурсов:
  

          - Сырье

          - Инструменты

          - Программное обеспечение

          - Запасные части и комплектующие

          - Расходные материалы

          - Информация / данные

          - Оборудование

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

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

          - Используется частично – некоторые ресурсы могут использоваться частично. Это значит, что после использования останется некоторое количество. Рассчитывается эквивалентно проценту расходования.

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

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

Документы процесса 

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

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

Обязательно 

• Наименование документа
  
• Дата выпуска документа – дата вступления в силу
  
• Ссылка на документ – как правило, нет смысла прикладывать все документы к регламенту и можно просто дать ссылку на документ в электронном виде или указать, где его можно найти.
  

Желательно 

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

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

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

Раздел 4 - Управление процессом 

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

Матрица ответственности 

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

Матрица ответственности управления процессом 

В такой матрице основным принципом построения является отношение участников процесса к управленческому циклу, а точнее, к его расширенному варианту:

• Планирование
  
• Организация
  
• Выполнение
  
• Контроль
  
• Улучшение / изменение
  

Один и тот же участник не может выполнять операцию и контролировать ее выполнение!

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

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

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

Матрица ответственности выполнения подпроцессов / этапов процесса. 

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

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

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

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

Осуществление управления 

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

Ключевые требования 

Существует 2 основных типа требований: требования к продуктам процесса и к ходу его выполнения. В некоторых отраслях имеет смысл дополнительно выделять тип требований, исходящих от регулирующих и контролирующих органов.

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

Все поля обязательно указывать

• Требование – краткое наименование требования
  
• Тип требования – к чему относится требование: продукт, ход процесса и т.д.
  
• Описание – описание требования, достаточное для понимания того, что имеется в виду и как это выражается в процессе
  
• Источник требования – внешний или внутренний источник требования. Внутренним источником, как правило, является или какой-то документ (например, приказ), или некое заинтересованное лицо. Чаще всего таким лицом является владелец другого процесса. Внешние требования тоже часто закреплены в документах, однако некоторые требования могут существовать в виде договоренностей с внешними сторонами. Это ни в коем случае не исключает требование из списка. Более того, порой соблюдение таких договоренностей может иметь даже большее значение.
  
• Механизм обеспечения – поле, которое не всегда используется, но может иметь существенное значение. Каждое требование должно выполняться через сам процесс. Это значит, что процесс должен быть выстроен таким образом, чтобы требование гарантированно выполнялось. Иногда имеет смысл дополнительно объяснить, через какие действия в процессе обеспечивается выполнение требования.
  

Показатели бизнес-процесса 

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

Обязательно 

• Показатель – наименование показателя
  
• Формула расчета – формула, по которой рассчитывается данный показатель
  
• Где фиксируется – необходимо указать, в какой системе или документе происходит запись показателя.
  
• Способ фиксации – существует два способа: вручную или автоматически. Да, если показатели не фиксируются автоматически в некой системе, это вовсе не повод отказываться от его фиксации и дальнейшего анализа. Просто это придется делать руками.
  
• Стандартный диапазон значений – диапазон значений, который принят в качестве стандартного для данного показателя. Можно указывать диапазон в виде «от… до …», но я бы рекомендовал использовать 3 варианта значений: минимальное, среднее и максимальное.
  

Желательно 

• Краткое описание показателя – наименование показателя не всегда отражает его суть, поэтому может быть полезным объяснить, что отражает показатель.
  
• Тип показателя. Есть 3 основных типа показателя процесса:
  

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

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

          - Клиентские показатели. Фактически это показатели удовлетворенности клиентов процесса. Например, количество не принятых клиентом изделий.

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

Приложения 

• Связанные документы и нормативные ссылки. Когда регламент выполняет в том числе формальную функцию, может быть, необходимо указать связь регламента с внутренними и внешними документами, а также дать нормативные ссылки. Необязательный пункт.
  
• Ревизия процесса. Указывается дата ревизии, кто провел и что в итоге: были внесены изменения или нет. Под ревизией имеется в виду, что кто-то посмотрел, как работает процесс и соответствует ли реальная жизнь тому, что написано в регламенте.
  
• Перечень изменений. Перечень внесенных в регламент изменений с указанием даты и лица, внесшего изменение.
  
• Словарь терминов и сокращений – думаю, тут все понятно.
  
• Условные обозначения. Перечень значений элементов нотации, в которой выполнены модели процессов.
  
• Формы и образцы документов. Если вы решили, что регламент должен включать в себя образцы и формы документов, то лучше всего это сделать в виде приложения.
  

Общие положения 

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

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

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

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

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

1. Регламент процесса должен быть понятен. Это значит, что если понятия и термины, которые используются в регламенте, могут быть непонятны в вашей компании, используйте свои. Упрощайте язык. Пусть будут не входы, а "то, что нужно для начала процесса". Пусть будет не продукт процесса, а "результат". Пусть будет не событие начала, а "старт" или "условие начала". А так далее.
   
2. Вводите термины и определения постепенно. Нужно время, чтобы новые термины прижились.
   
3. Согласовывайте регламент по мере его разработки. Вовлекайте заинтересованные стороны в его создание. Сопричастность позволяет снизить уровень сопротивления.
   
4. Используйте информационные системы! Уходите от бумажных регламентов!
   

Я постарался максимально подробно объяснить состав и структуру регламента. 

О том, как заставить регламент работать, можно прочитать здесь.

Подписывайтесь на нашу новостную рассылку, чтобы не пропустить новые статьи.

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