Регламент бизнес-процесса – основной документ, содержащий необходимые для исполнителя требования. Как сделать его информативным? Какие разделы он должен содержать? В статье Владимира Репина приводится типовая структура регламента. Вы можете использовать ее для бенчмаркинга со структурой регламентов, используемых в вашей организации.
Одноуровневый регламент бизнес-процесса
Рассмотрим так называемый «одноуровневый» регламент выполнения бизнес-процессса. Я ввел этот термин в свой лексикон, когда стал активно работать со средой моделирования процессов. В каждом таком инструменте можно и нужно создавать иерархический справочник бизнес-процессов компании.
Находясь на определенном уровне справочника, вы можете запустить конкретный отчет, который выгрузит всю необходимую информацию о процессе соответствующего уровня. Вот пример фрагмента справочника процессов некоторой торговой компании:
5.1….
5.2. Приемка ткани
5.2.1. Разгрузка а/м.
5.2.2. Визуальный контроль и проверка ткани по количеству.
5.2.3. Формирование и подписание акта приемки ткани.
5.2.4. Печать этикеток со штрих кодами.
5.2.5. Приклеивание этикеток (для ткани от поставщиков).
5.2.6. Сканирование этикеток.
5.2.7. Сверка и перемещение в 1С на склад приемки.
5.3. Приемка возврата
5.3.1. Получение информации о возврате.
5.3.2. Доставка возврата со склада клиента (в Москве) или из ТК.
5.3.3. Доставка возврата клиентом (самостоятельно).
5.3.4. Разгрузка а/м.
5.3.5. Проверка правильности оформления документов и наличия ткани.
5.3.6. Перемещение возврата и документов в зону ОТК .
5.4….
Если мы, условно говоря, встанем на процесс 5.3. (выделен курсивом) и запустим отчет, то выгрузим регламент, которые будет содержать графическую схему и описание процесса «Приемка возврата». Это и есть одноуровневый регламент процесса.
Теперь давайте обсудим форму этого регламента. Рекомендую использовать следующие разделы.
| № | Название раздела | Содержание раздела |
| 1 | Титульный лист | Колонтитул с данными компании и кодом документа. Место для утверждающей подписи руководителя, дата, год. Название регламента. Код регламента. Год, город. |
| 2 | Паспорт регламента | Код документа. Дата ввода в действие. Введен (впервые/взамен регламента __________). Срок действия регламента. Должность сотрудника, ответственного за актуализацию регламента. Периодичность актуализации. Лист согласования. Перечень изменений и дополнений. |
| 3 | Содержание | Многоуровневое автоматически формируемое оглавление регламента. |
| 4 | Общие положения | Назначение и область действия регламента. Список должностей и ролей, которые должны знать и соблюдать требования регламента. Используемые сокращения. Термины и определения. Нормативные ссылки, в т.ч. — внешние документы (код, наименование, ссылка); — внутренние документы (код, наименование, ссылка). |
| 5 | Общее описание процесса | Владелец бизнес-процесса (название должности). Место процесса в архитектуре процессов компании. Инициирующие события (начало). Входы (документы, информация, материальные продукты, услуги). Описание процесса (краткое текстовое описание). Выходы (документы, информация, материальные продукты, услуги). Завершающие события (результат). Требования к срокам выполнения процесса (периодичность, нормативная длительность). |
| 6 | Графическая схема процесса | Графическая схема процесса в формате А4 (иногда – А3). |
| 7 | Описание операций процесса | Табличное или текстовое описание процесса. По каждой операции процесса: — №; — наименование; — должность или роль исполнителя; — инициирующие события (начало); — входы (документы, информация, материальные продукты, услуги); — особенности выполнения операции (краткий текст); — выходы (документы, информация, материальные продукты, услуги); — завершающие события (результат); — нормативный срок и длительность выполнения. |
| 8 | Действия в случае отклонений | Табличное описание действий в случае отклонений по каждой операции: — №; — наименование; — должность или роль исполнителя; — описание действий исполнителя в случае отклонений (краткий текст, ссылки на документы). |
| 9 | Ресурсы, необходимые для выполнения процесса | Табличное описание ресурсов, требуемых для выполнения процесса по разделам: — сырье и материалы; — оборудование; — среда; — информационные и телекоммуникационные системы; — инструмент (в т.ч. измерительный). |
| 10 | Контрольные процедуры (методы контроля) | Табличное описание методов контроля исполнения требований регламента исполнителями: — наименование метода; — наименование операции процесса («контрольная точка»); — описание метода контроля (текст); — источник исходных данных; — ответственный за контроль; — периодичность контроля; — учет результатов контроля. |
| 11 | Цели и показатели | Табличное или текстовое описание целей и показателей для управления процессом: — №; — наименование цели; — код цели; — код показателя; — наименование показателя; — ссылка на паспорт показателя (или некоторые данные из паспорта, например формула для расчета). |
| 12 | Приложения | Формы, справочники, перечни, критерии, примеры расчетов, схемы и прочее, например: — форма заявки; — перечень требований к продукту; — чертеж устройства; — прочие. |
Пройдемся по каждому разделу и обсудим нюансы их применения в регламенте.
Титульный лист
Было бы странно представить себе нормативный документ без титульного листа. Это всё равно, что книга без обложки или интеграл без дифференциала (физтехи меня поймут). Но мне встречались некоторые компании, которые не использовали титульный лист. Вместо этого вся информация о регламенте помещалась в большой колонтитул. Считаю, что титульный лист не на столько значительно увеличивает размер документа, чтобы его не использовать. Кроме того, для регламента в электронном виде (например, на web-портале) это вообще не важно.
Если используется среда моделирования, то на титульном листе можно поставить значок, показывающий, что документ был полностью автоматически сформирован в такой системе. Это, можно сказать, «продакт плейсмент» среды моделирования для сотрудников.
Паспорт регламента
Паспорт – важная часть документа. Он содержит всю необходимую информацию о статусе и истории регламента. Например, полезным является раздел описания внесенных изменений.
В паспорте регламента важно указать должность сотрудника, ответственного за актуализацию документа, а так же периодичность актуализации.
Содержание
Содержание документа или, другими словами, его оглавление является очень важной частью регламента. Пользователи документа должны иметь возможность быстро находить нужную информацию по разделам. Поэтому я рекомендую делать многоуровневое автоматическое оглавление. Причем заголовки разделов разного уровня должны существенно различаться. Ничего страшного, что оглавление может занять несколько страниц. Без него документ неудобен в использовании.
В некоторых компаниях оглавление формируют вручную, в том числе проставляя номера страниц. Такую практику можно назвать каменным веком в регламентации.
Некоторые компании вообще не используют оглавление. Это очень плохо, т.к. весьма неудобно для пользователей.
Общие положения
Общие положения – небольшой, но важный раздел. В первую очередь, в нем должна быть четко сформулирована цель (назначение) регламента и область его действия. Стоит потратить время на четкую формулировку цели создания документа. Это важно.
Целесообразно включать в этот раздел список должностей и ролей, которые должны знать и соблюдать требования документа (иногда такой список помещают в приложение к документу).
Важным является подраздел по используемым в регламенте сокращениям, терминам и определениям. Если в компании есть корпоративный глоссарий, то можно просто сделать ссылку на него. Но используемые в документе сокращения всё равно стоит показать. Это сократит время на поиск нужной информации пользователем.
Еще одним важным подразделом являются ссылки на нормативные документы: внешние и внутренние. В некоторых компания в соответствующей таблице приводят гиперссылки. Это позволяет пользователю быстро найти нужную информацию в базе НМД организации.
Общее описание процесса
Цель общего описания процесса состоит в том, чтобы определить владельца процесса. Если данный термин не принято использовать в компании, то указывается должностное лицо, ответственное за выполнение процесса.
Если у разработчиков регламента возникают трудности с определением владельца процесса, то это повод для беспокойства. Возможно, границы процесса определены неверно. Эта проблема проявляется особенно ярко в случае, если в компании не разработана и не используется многоуровневая архитектура бизнес-процессов.
К сожалению, крайне редко наблюдаю ситуацию, когда в разделе «Общее описание…» показывают место процесса в общей архитектуре бизнес-процессов компании. Почему? Дело в том, что архитектура процессов официально утверждена только в небольшом количестве компаний. Но при внедрении процессного управления создание процессной архитектуры является важнейшей задачей. Если вы используете среду моделирования, то архитектура (справочник) процессов у вас должен быть, так сказать, «по определению».
Для того, чтобы показать место процесса в архитектуре, можно включить фрагмент перечня с выделением в нем рассматриваемого в регламенте процесса. Пользователи сразу будут видеть контекст, а это очень важно для понимания назначения регламента и его роли в системе стандартизации.
В рамках рассматриваемого раздела необходимо четко описать границы процесса. Как вы помните, для этого необходимо определить:
• инициирующие и завершающие процесс события;
• входы и выходы процесса.
Можно даже представить в данном разделе процесс, как «чёрный ящик». Слева – входы и инициирующие события, справа – завершающие события и выходы, снизу – необходимые для выполнения ресурсы. Эта информация может быть представлена в виде таблицы (автоматически) или графической картинки (вручную, что плохо).
Ещё одним подразделом, который можно включить в «Общее описание процесса» является информация о сроках его выполнения.
Привязку ко времени (сроки) можно рассматривать в нескольких аспектах: а) периодичность выполнения; б) дата, время; в) нормативная длительность выполнения процесса (подразумевается – одного экземпляра процесса).
Вообще говоря, установление сроков – задача не такая простая, как кажется. Ее целесообразно рассматривать отдельно.
Графическая схема процесса
Графическая схема обычно занимает в регламенте один лист формата А4. Довольно редко компании используют формат А3, но это неудобно в случае использования регламента в бумажном виде.
Стоит использовать следующий критерий – при распечатке схема должна нормально восприниматься человеком с нормальным зрением (понятно, что без микроскопа). Если шагов процесса на схеме слишком много, то это указывает на проблемы моделирования. Часто бывает, что количество шагов можно существенно сократить без потери логики и информативности схемы. Если, тем не менее, это сделать невозможно, то стоит подумать о детальном описании подпроцессов и использовании шаблона 2-уровневого регламента.
Если на графической схеме процесса используются дорожки (должности, роли), то включать в регламент матрицу ответственности по процессу, на мой взгляд, нецелесообразно. Если, напротив, процесс не содержит дорожек, то возможно стоит подумать об использовании матрицы ответственности.
Описание операций процесса
Невозможно всю информацию о процессе показать на графической схеме – она станет слишком сложной и плохо воспринимаемой пользователем. Мне периодически попадаются схемы, нарисованные «на коленке» (без использования среды моделирования) и в нестандартной нотации. Как правило, понять такие схемы без интерпретатора (автора) почти невозможно. Поэтому я предполагаю, что вы будете использовать среду моделирования и какую-то стандартную нотацию (CFFC, eEPC, BPMN – выбор не такой уж широкий).
В связи с этим возникает необходимость в дополнительных разделах регламента, которые раскрывают необходимую для исполнителя информацию.
Прежде всего, это раздел по описанию операций процесса. Он может быть выполнен текстом или в виде таблицы. Структура, представленная в п. 7 таблицы является довольно сложной. В результате, получается длинная таблица с весьма узкими столбцами, что не только выглядит неэстетично, но и неудобно в использовании.
Как можно сделать по-другому? Например, разбить таблицу на две: а) собственно описание операций; б) описание инициирующих и завершающих событий и входов/выходов. Решение – за вами.
Что писать в текстовом описании каждой операции? На мой взгляд, необходимо кратко изложить ключевые особенности выполнения операции для исполнителя. Не нужно «разжевывать» ему всё. Мы предполагаем, что исполнитель является квалифицированным и опытным сотрудником, который знает свой процесс. Но на нюансы выполнения деятельности нужно обратить внимание! Очевидно, что если разработчик регламента сам никогда не выполнял процесс (причем результативно и за отведенное нормативное время), он не сможет написать что-то осмысленное и полезное в документ.
Периодически встречаются ситуации, когда в текстовом описании операции дублируют ее название. Ну, это просто халтура со стороны разработчика документа… Иногда приводят слишком подробное описание. В этом случае стоит критически его проанализировать и подумать об использовании формы 2-уровневого регламента.
Довольно мило, когда количество операций на схеме и в тексте не соответствует друг другу. Этот факт указывает на то, что: а) графическая схема не рассматривается разработчиком как реальный практический инструмент понимания и регламентации процесса; б) регламент представляет собой документ «ручной сборки» (что плохо).
В общем, создание текстовой части описания действий исполнителей в регламенте является важным, ответственным и творческим делом.
Действия в случае отклонений
Этот раздел встречается в регламентах довольно редко. О каких отклонениях идет речь? Строго говоря, после каждой операции процесса возможны отклонения и возвраты на переделку работы. Но если мы попытаемся отобразить это на графической схеме, она станет абсолютно нечитаемой.
Можно предложить следующие ситуации, когда можно и нужно моделировать возвраты на графической схеме (отмечу, что тип схемы в данном контексте – «аналитическая»):
- возврат после специализированной операции контроля (например, выполняемой контролером качества);
- возврат, возникающий из-за влияния внешних факторов (например, клиенты часто просят уточнить параметры заказа и т.п.);
- возврат в случае, если для коррекции результата (переделки) требуется выполнение других операций процесса (или вообще других процессов).
Стоит оценить вероятность возможных отклонений и соответствующих возвратов для каждой операции процесса. Если вероятность составляет, например, более 20-25%, то стоит рисовать возврат на схеме.
В любом случае, наличие возвратов на графической схеме процесса – это всегда повод задуматься над его реальной оптимизацией. Идеальный процесс работает вообще без возвратов, с первого раза (это, конечно, только теория).
Теперь вернемся собственно к таблице действий в случае отклонений. В ней нужно указывать действия исполнителей в случае наиболее вероятных событий, которые не показаны на графической схеме процесса.
Вероятность может быть небольшая, но последствия критические для компании. Конечно, не стоит чрезмерно усердствовать и описывать действия в случае, например, падения метеорита (хотя для колонии на Луне это было бы вполне уместно).
Ресурсы, необходимые для выполнения процесса
Если регламентировать процесс комплексно, то надо обязательно указывать требования к ресурсам, которые необходимы для его выполнения.
В данном разделе могут быть перечислены необходимые ресурсы, а так же приведены ссылки на нормативные документы, в которых определены требования к ним.
Контрольные процедуры (методы контроля)
Методы контроля или, другими словами, контрольные процедуры целесообразно продумать на стадии разработки регламента. Для чего они нужны? Это инструмент оперативного (час, день, неделя) контроля со стороны непосредственного руководителя.
В каждом процессе есть места, где у исполнителя есть:
• вероятность ошибиться и выполнить работы не так, как требуется;
• сделать работу с нарушением требований регламента (по разным причинам: тяжело физически, невыгодно с точки зрения личной выработки и дохода, «так будет лучше» и т.п.).
Именно в таких операциях процесса должны быть установлены контрольные точки – места сбора фактических данных о ходе и результатах выполнения процесса. Данные должны фиксироваться, по возможности, автоматически или независимыми сотрудниками.
Полученные данные периодически проверяются в рамках выполнения контрольной процедуры. Отклонения фиксируются в базе данных (журнале). При необходимости выполняется коррекция процесса. В случае повторяющихся несоответствий разрабатываются и выполняются корректирующие действия.
Безусловно, если при разработке процесса и его регламентации вы увидели места, где велика вероятность ошибки или сознательного неправильного выполнения процесса, то лучше сразу внести изменения, перепроектировать процесс, а не создавать контрольные процедуры.
Кроме линейных руководителей, методы контроля процесса (контрольные процедуры) могу быть полезными для вышестоящих руководителей, внутренних аудиторов и внутренних потребителей процесса.
Данный раздел встречается довольно редко и только у «продвинутых» в области процессного управления компаний.
Цели и показатели
Формулировка целей процесса является тяжким трудом для многих руководителей. Гораздо проще просто написать, например, что задачей процесса является получение маркетинговой информации или обслуживание оборудования. Но это «ни о чём». Нужно учиться формулировать четкие цели, причем увязанные с общей системой целей организации.
Я считаю раздел «Цели и показатели» обязательным для регламента. Процессом нужно управлять, а без показателей это невозможно делать целенаправленно. Нецеленаправленная деятельность – это хаос, имитация управленческой деятельности. Поэтому цели и показатели нужно включать в регламент обязательно.
Приложения
Приложения к регламенту – это раздел для информации, которая не может быть структурирована в виде графической схемы процесса или табличного описания. Например, это формы рабочих документов: заявки, письма, отчеты и прочее. Так же это могут быть различные перечни, таблицы критериев, формулы для расчета, чертежи и т.д.
«Редкие звери» или нечасто используемые разделы регламента
Кратко хочу сказать про разделы, которые встречаются в регламенте процесса редко. Например, это раздел «Ответственность исполнителей». Его оформляют в виде таблицы. Как правило, везде одна и та же фраза – «Несет ответственность в соответствии с УК РФ…» или «Устное/письменное замечание руководителя/ Дисциплинарное взыскание». Если вам нечего написать в таком разделе, кроме одной и той же общей фразы, то лучше вообще убрать раздел из регламента.
Кроме «Ответственности исполнителей» в регламенте могут показывать информацию по проведенным аудитам. Это удобно для электронной версии, но неудобно для бумажной.
Иногда в регламентах можно увидеть такие разделы, как «Документирование и архивирование» или «Порядок внесения изменений». Но в них чаще всего пишут общие фразы типа: «Порядок документирования и архивирования в рамках настоящего регламента определен внутренними нормативными документами компании «» и « Настоящий Регламент пересматривается на соответствие в установленные в компании «_» сроки. Порядок пересмотра настоящего регламента определен внутренними нормативными документами компании «___». Зачем включать такие пустые, формальные фразы в регламент?! Не понимаю…
Дополнительно к регламенту может быть приложен лист ознакомления сотрудников, если такая практика принята в компании (при отсутствии электронной формы согласования документов). В некоторых компаниях прикладывают еще лист рассылки регламента.
Совсем редко в регламентах попадается раздел «Ограничения». Это уже для гурманов, владеющих TOC. Не думаю, что этот раздел относится к обязательным. Хотя, если вы знаете, что в него написать, то вперед.
Иногда в регламент добавляют раздел «Справочная литература». Возможно, для того, чтобы исполнители могли, при желании, повысить свой уровень знаний по предмету. Тема полезная. Но я сомневаюсь, что кто-то из сотрудников будет что-то читать без дополнительной «энергетизации» со стороны руководителя.
Иногда в регламент добавляют требования к технике безопасности и охране окружающей среды. Но, как правило, это только для специфических производственных процессов.
Резюме
Итак, я рассмотрел структуру одноуровневого регламента выполнения бизнес-процесса.
В своей компании вы сможете сами определить структуру и содержание конкретных разделов. При этом важно помнить, что представляет собой процесс, как объект управления, и регламентировать всё его аспекты (не только алгоритм выполнения).
Важно, чтобы форма регламента соответствовала уровню сложности процесса. Не применяйте слишком сложные формы для простых процессов. Удачи!
В.В. Репин,
к.т.н., доцент, тренер, консультант.
Июль 2015 г.