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

Одноуровневый регламент бизнес-процесса

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

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. (выделен курсивом) и запустим отчет, то выгрузим регламент, которые будет содержать графическую схему и описание процесса «Приемка возврата». Это и есть одноуровневый регламент процесса.

Теперь давайте обсудим форму этого регламента. Рекомендую использовать следующие разделы.

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

Титульный лист

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

Паспорт регламента

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

Содержание

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

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

Общие положения – небольшой, но важный раздел. В первую очередь, в нем должна быть четко сформулирована цель (назначение) регламента и область его действия. Стоит потратить время на четкую формулировку цели создания документа. Это важно.
Целесообразно включать в этот раздел список должностей и ролей, которые должны знать и соблюдать требования документа (иногда такой список помещают в приложение к документу).
Важным является подраздел по используемым в регламенте сокращениям, терминам и определениям. Если в компании есть корпоративный глоссарий, то можно просто сделать ссылку на него. Но используемые в документе сокращения всё равно стоит показать. Это сократит время на поиск нужной информации пользователем.
Еще одним важным подразделом являются ссылки на нормативные документы: внешние и внутренние. В некоторых компания в соответствующей таблице приводят гиперссылки. Это позволяет пользователю быстро найти нужную информацию в базе НМД организации.

Общее описание процесса

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

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

В рамках рассматриваемого раздела необходимо четко описать границы процесса. Как вы помните, для этого необходимо определить:

• инициирующие и завершающие процесс события;
• входы и выходы процесса.

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

Графическая схема процесса

Графическая схема обычно занимает в регламенте один лист формата А4. Довольно редко компании используют формат А3, но это неудобно в случае использования регламента в бумажном виде.

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

Описание операций процесса

Невозможно всю информацию о процессе показать на графической схеме – она станет слишком сложной и плохо воспринимаемой пользователем. Мне периодически попадаются схемы, нарисованные «на коленке» (без использования среды моделирования) и в нестандартной нотации. Как правило, понять такие схемы без интерпретатора (автора) почти невозможно. Поэтому я предполагаю, что вы будете использовать среду моделирования и какую-то стандартную нотацию (CFFC, eEPC, BPMN – выбор не такой уж широкий).
В связи с этим возникает необходимость в дополнительных разделах регламента, которые раскрывают необходимую для исполнителя информацию.
Прежде всего, это раздел по описанию операций процесса. Он может быть выполнен текстом или в виде таблицы. Структура, представленная в п. 7 таблицы является довольно сложной. В результате, получается длинная таблица с весьма узкими столбцами, что не только выглядит неэстетично, но и неудобно в использовании.

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

Действия в случае отклонений

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

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

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

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

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

Вероятность может быть небольшая, но последствия критические для компании. Конечно, не стоит чрезмерно усердствовать и описывать действия в случае, например, падения метеорита (хотя для колонии на Луне это было бы вполне уместно).

Ресурсы, необходимые для выполнения процесса

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

Контрольные процедуры (методы контроля)

Методы контроля или, другими словами, контрольные процедуры целесообразно продумать на стадии разработки регламента. Для чего они нужны? Это инструмент оперативного (час, день, неделя) контроля со стороны непосредственного руководителя.
В каждом процессе есть места, где у исполнителя есть:

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

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

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

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

Цели и показатели

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

Приложения

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

«Редкие звери» или нечасто используемые разделы регламента

Кратко хочу сказать про разделы, которые встречаются в регламенте процесса редко. Например, это раздел «Ответственность исполнителей». Его оформляют в виде таблицы. Как правило, везде одна и та же фраза – «Несет ответственность в соответствии с УК РФ…» или «Устное/письменное замечание руководителя/ Дисциплинарное взыскание». Если вам нечего написать в таком разделе, кроме одной и той же общей фразы, то лучше вообще убрать раздел из регламента.
Кроме «Ответственности исполнителей» в регламенте могут показывать информацию по проведенным аудитам. Это удобно для электронной версии, но неудобно для бумажной.
Иногда в регламентах можно увидеть такие разделы, как «Документирование и архивирование» или «Порядок внесения изменений». Но в них чаще всего пишут общие фразы типа: «Порядок документирования и архивирования в рамках настоящего регламента определен внутренними нормативными документами компании «» и « Настоящий Регламент пересматривается на соответствие в установленные в компании «_» сроки. Порядок пересмотра настоящего регламента определен внутренними нормативными документами компании «___». Зачем включать такие пустые, формальные фразы в регламент?! Не понимаю…

Дополнительно к регламенту может быть приложен лист ознакомления сотрудников, если такая практика принята в компании (при отсутствии электронной формы согласования документов). В некоторых компаниях прикладывают еще лист рассылки регламента.
Совсем редко в регламентах попадается раздел «Ограничения». Это уже для гурманов, владеющих TOC. Не думаю, что этот раздел относится к обязательным. Хотя, если вы знаете, что в него написать, то вперед.
Иногда в регламент добавляют раздел «Справочная литература». Возможно, для того, чтобы исполнители могли, при желании, повысить свой уровень знаний по предмету. Тема полезная. Но я сомневаюсь, что кто-то из сотрудников будет что-то читать без дополнительной «энергетизации» со стороны руководителя.
Иногда в регламент добавляют требования к технике безопасности и охране окружающей среды. Но, как правило, это только для специфических производственных процессов.

Резюме

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

В.В. Репин,
к.т.н., доцент, тренер, консультант.

Июль 2015 г.

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

Структура чек-листа

Качественная графическая схема бизнес-процесса является основой для:
• выполнения анализа процесса и разработки мероприятий по его оптимизации;
• формирования понятного и практически полезного регламента (стандарта).

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

Ниже представлены название разделов чек-листа и их краткие характеристики.

Тип модели процесса

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

Соответствие стандартной нотации моделирования

Необходимо проверить соответствие схемы общепринятым нотациям моделирования. Вариантов не много: IDEF0, eECP, CFFC, BPMN.

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

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

Корректность формулировок названий объектов на схеме

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

Следует обратить внимание на соответствие названий Стандарту моделирования. Если в нем нет требований в части названий объектов, то стоит их внести.

Пример некорректной формулировки процесса: «Разработка и утверждение плана работ в случае согласования руководителем не позднее второй недели третьего месяца квартала». (Думаю, не нужно объяснять, что здесь не так).

Корректность описания входов/выходов

Входы/выходы могут быть информационные и материальные.

Важно, чтобы входы/выходы были описаны корректно и не «повисали» в воздухе. Это означает, например, что для любого входящего документа был указан процесс (в виде какой-либо ссылки), который является поставщиком входа и т.п.

Корректность описания событий

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

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

Отсутствие логических и содержательных ошибок

Это самый важный раздел в чек-листе.

В первую очередь, здесь нужно указать логические ошибки. Например, некорректное использование в паре логических операторов «И» и «ИЛИ».

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

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

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

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

Отсутствие физической нереализуемости

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

Отсутствие возвратов (переделок работы)

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

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

Поэтому надо определить правила, когда рисовать возвраты, а когда – нет.

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

В любом случае, чем меньше возвратов, тем эффективнее бизнес-процесс.

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

Как это ни странно, иногда на схеме процесса можно увидеть дублирование операций.

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

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

Отсутствуют пропущенные важные операции

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

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

Отсутствует чрезмерный контроль

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

Отсутствуют узкие места («бутылочные горлышки»)

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

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

Иногда визуально выявить узкое место сложно. Нужен содержательный анализ на основе конкретных данных.

Отсутствуют возвраты в прошлое

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

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

Отсутствие смешения единичного потока и накопления (объектов обработки)

Это довольно тонкая, но очень распространенная ошибка.

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

Отсутствие «процессной грыжи»

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

Например, в процессе получения информации об оплате счета, возникает операция «Ведение бухгалтерского учета».

Отсутствие неоднородности масштаба операций

Довольно просто выявляется. Например, на одной схеме процесс представлены операции под названиями: «Получить сменное задание у начальника» и «Изготовить продукцию». Первую делает мастер, а вторую выполняет весь цех численностью 30 человек.

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

Стоит подчеркнуть, что я рассматриваю в данном случае только графическую схему, а не бизнес-процесс в целом. (Тем, кто не видит разницы, рекомендую почитать мои предыдущие публикации, а лучше книгу «Бизнес-процессы. Моделирование, внедрение, управление»).

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

Графическая схема процесса для тестирования чек-листа

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

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

Заполненный чек-лист

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

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

После данной тренировки попробуйте проверить качество моделей процессов Вашей компании.

В.В. Репин,
к.т.н., доцент, тренер, консультант.

Март 2015 г.

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

Введение

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

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

Введем следующее определение:

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

Можно сформулировать несколько целей создания и поддержания ССБП в компании:

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

Философской основой ССБП является парадигма стабилизации и постоянного совершенствования процессов, обеспечивающая устранение потерь и повышение эффективности бизнеса компании в целом.
С точки зрения автора, целесообразно рассматривать следующие аспекты ССБП:

1. Методы.
2. Инструменты.
3. Ресурсы.
4. Процессы.

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

Структура процессов системы

На следующем рис. 1. представлена структура процессов ССБП – первый, верхний уровень.

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

1. единого методического подхода к процессному управлению (автор развивает его с 2004 года);
2. анализа лучших практик передовых российских компаний;
3. анализа практики некоторых западных компаний, моделей управления (например, TPS), взглядов признанных авторитетов в области менеджмента;
4. анализа и систематизации результатов проектов описания и регламентации бизнес-процессов, выполненных под руководством (с участием автора) за последние 17 лет.

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

Уровни развития системы стандартизации бизнес-процессов

В таблице 1 представлена характеристика каждого уровня развития ССБП. Цветом показано состояние процессов системы. Оранжевый цвет – процесса нет, цифра «0». Желтый цвет – процесс есть, но работает недостаточно эффективно, оценка «0,5». Зеленый цвет – процесс есть, эффективная работа, оценка «1».
Красным цветом выделены процессы, на которые стоит обратить особое внимание. Именно они позволяют замкнуть контуры управления и делают систему управляемой.
Читатель статьи может зарегистрироваться на портале www.finexpert.ru, войти под своим логином и скачать файл MS Excel, в котором представлена данная таблица. В ней можно оценить состояние системы стандартизации бизнес-процессов вашей компании.

Таблица. 1. Уровни развития системы стандартизации бизнес-процессов.

Ключевая проблема системы

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

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

1. планирование и контроль описания и регламентации процессов;
2. проведение моделирующих сессий;
3. контроль качества моделей процессов;
4. валидация моделей процессов;
5. разработка оперативных методов контроля исполнения НМД;
6. контроль качества проектов НМД;
7. валидация проектов НМД;
8. обучение и аттестация сотрудников на знание НМД;
9. контроль исполнения НМД и поддержка сотрудников во время переходного периода;
10. проведение инвентаризации НМД;
11. периодический оперативный контроль исполнения НМД линейным руководителем;
12. прочие.

Пример компании V-ого уровня

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

«…По особенностям описания бизнес-процессов в компании можно сказать, что система построена на основе сертифицированной ИСМ путем расширения на всю деятельность организации. Была выстроена структура НМД, охватывающая около 80% подразделений и процессов. Составлены требования к процессу разработки и внедрения регламентирующей документации. Все БП взаимосвязаны между собой, от общих стандартов до конкретных инструкций. Специалисты и руководители подразделений в группе с отделом развития принимают непосредственное участие в описании своих и смежных БП, являются инициаторами оптимизации БП и соответствующей регламентации.
Система управления выстроена в обязательном порядке с учетом культуры и ценностей компании. Разработан и развивается комплекс мероприятий по мотивации персонала. Ежегодно проводятся внутренние мероприятия по обучению и развитию персонала, и формированию кадрового резерва. Это и плановые внешние или внутренние семинары с последующим контролем применения полученных знаний, и различного рода номинации по крупным индивидуальным и групповым проектам, перспективным техническим решениям и др.
Оценка знаний и использования действующей НМД включена в общую аттестацию сотрудников, проводится при плановых и внеплановых аудитах подразделений, а также составляется непосредственным руководителем по результатам работы. Вся НМД размещена и актуализируется на внутреннем портале, к которому имеют соответствующий доступ все сотрудники компании, ее филиалов, представительств и дочерних организаций.
В части автоматизации БП предстоит немало работ, частично реализованных и также запланированных на ближайшее будущее. На данный момент практически всё построено в ручном режиме и во многом держится на исполнительности, ответственности и вовлеченности персонала, поэтому смело можно сказать, что коллектив компании — это действительно её капитал…

Зернева Светлана Анатольевна
Специалист Отдел развития корпоративной системы менеджмента
ЗАО Фирма «Август»

Выводы

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

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

В.В. Репин,
к.т.н., доцент,
тренер, консультант,
Исполнительный директор и партнер ООО «BPM Консалтинг Групп»

Февраль 2015 г.

В условиях кризиса сокращение численности персонала является одним из факторов выживания компании. Но необоснованное сокращение численности существенно увеличивает риски не выполнения процессов в срок и с нужным качеством. А это может привести к потере клиентов, сокращению выручки и, как следствие, к банкротству организации. Может ли руководитель опираться на простую формулу для расчета численности персонала? Какова вероятность принять неправильное управленческое решение? Как можно использовать процессный подход и имитационное моделирование бизнес-процессов для определения оптимальной численности персонала? В статье Владимира Репина обсуждаются эти вопросы на примере моделей процессов, разработанных в среде Business Studio 4.0.

Введение

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

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

«Простой» процесс

На рис. 1. показан простейший бизнес-процесс. Он заключается в том, что три сотрудника, находящиеся на различных должностях, последовательно выполняют три операции по созданию документа для внешнего заказчика: находят нужную информацию, подготавливают и передают заказчику некоторый документ. Каждая операция (согласно хронометражу) длится 10 минут. Заявки от заказчиков поступают равномерно с интервалом в 5 минут (всего около 2000 заявок в месяц). Получится ли у нас рассчитать на пальцах, сколько сотрудников нужно для подготовки документов? Основным ограничением является срок подготовки документа – «в течение 1 рабочего дня с момента подачи заявки». Давайте попробуем. Полезное время работы сотрудника – 22860 минут = 10560 минут. Время, требуемое одному сотруднику для обработки заявки, составит 2000*10 минут = 20 000 минут. Очевидно, что нужно иметь двух сотрудников на должности А, чтобы обработать все заявки.

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

Результаты имитации процесса показывают (см. рис. 1), что в феврале 2015 года на вход процесса поступило 1920 заявок. Из них только 958 (почти 50%) было выполнено к концу месяца. На первой операции процесса возникла очередь длинной 6 дней 16 часов. Наши расчеты «на пальцах» подтвердились. Давайте посмотрим, что будет, если увеличить численность всех сотрудников вдвое. На рис. 2. показаны результаты соответствующей имитации.

На рис.2 видно, что практически все заявки были выполнены. Длина очереди почти нулевая. Это означает, что численность по два сотрудника на каждой должности является оптимальной численностью для получения результата данного процесса (документ выдается «в течение 1 рабочего дня с момента подачи заявки» и даже быстрее). При этом мы, конечно, не учитывали прогулы, пьянки и беременность.
Любой скажет, что такие расчеты легко сделать безо всякого описания и имитационного моделирования процесса. Безусловно, это можно сделать (в т.ч. учесть % неявки персонала на работу, беременность и другие факторы при помощи коэффициентов, как это делают опытные нормировщики). Но давайте посмотрим, можно ли будет так просто выполнить расчет в более реальной практической ситуации.

«Сложный» процесс

Усложним процесс следующим образом:

1. заявки поступают неравномерно в течение дня;
2. операции процесса выполняются не точно 10 минут, а их длительность имеет некоторое распределение (минимум – 6, максимум – 14 минут);
3. существует определенный уровень «брака» при подготовке документов – 5% (выявляется потребителями при получении документов).

На рисунках 3, 4 и 5 показаны распределения соответствующих параметров, используемых при имитации.

На рис. 3. видно, что пиковая нагрузка приходится на три часа дня.

В целом, распределения на рис. 3 и 4 подобраны так, чтобы общее количество заявок в месяц составляло около 2000, как и в предыдущем случае.

На рис. 5. показано распределение времени выполнения операций процессов. Видно, что матожидание времени выполнения составляет 10 минут.

Вопрос. Кто-то может рассчитать «на пальцах» по простой формуле, сколько сотрудников потребуется для результативного выполнения такого процесса? Вряд ли… Кто-то скажет, что можно сделать расчет «по среднему», но он не будет учитывать пиковые нагрузки, которые для реального бизнеса и представляют наибольший интерес… И это только один простейший процесс. А сколько в организации сложных процессов? Обосновывая численность персонала по формуле, мы можем допустить ошибку, которая приведет либо:
А) потерям из-за избыточного количество сотрудников;
Б) снижению результативности бизнес-процессов, недовольству клиентов и т.п.

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

На рис. 6 видно, что к сотруднику, выполняющему операцию «Находит нужную информацию» стоит очередь из заявок, длинна которой на конец месяца составляет немногим более 2 дней. Т.е. мы не выполняем требования «В течение 1 рабочего дня с момента подачи заявки». Попытаемся увеличить численность сотрудников до 9 человек. На рис. 7. показаны результаты соответствующей имитации.

На рис. 7 видно, что при численности 9 человек (3 человека на каждой должности), очереди заявок практически нет.

Давайте предположим, что нам удалось провести работы по улучшению процесса, которые обеспечили:
1) сокращение среднего времени выполнения каждой операции процесса на 30%;
2) сокращению уровня брака до 1%.

Результаты имитации оптимизированного процесса показаны на рис. 8.

На рис. 8. мы видим, что очереди вообще нет. В связи с этим возникает подозрение, что сотрудники недостаточно загружены работой. Действительно, если посмотреть график работы сотрудника, занимающего должность С (рис. 9) видно, что он недостаточно загружен в первой половине дня, т.е. до пиковой нагрузки. Возникают мысли, как организовать работу так, чтобы в первой половине дня выводить меньше сотрудников и устранить соответствующие потери. Но это уже совсем другая история…

Выводы

В данной статье мне хотелось обратить внимание читателя на следующие моменты:

1. определение численности персонала «на пальцах» (по формуле с коэффициентами) может приводить к ошибкам и, как следствие, к росту потерь. Необоснованное сокращение численности персонала может нанести вред организации;
2. описание и анализ процессов (в т.ч. имитационное моделирование) дают возможность обосновать меры по их оптимизации;
3. методы и инструменты описания и анализа процессов должны использоваться в организации единой командой, состоящей из:
   a. руководителей подразделений (постановка задачи, обеспечение информацией, организация работ, анализ процессов и принятие решений по оптимизации, организация и контроль реализации решений);
   b. бизнес-аналитиков (описание процессов, имитационное моделирование, анализ процессов, разработка мероприятий по оптимизации);
   c. специалистов по нормированию труда (сбор данных для формирования имитационной модели, анализ результатов имитации процесса, участие в разработке мер по оптимизации).

В.В. Репин,
к.т.н., доцент,
тренер, консультант,
Исполнительный директор и партнер ООО «BPM Консалтинг Групп»

Январь 2015 г.