В статье Владимира Репина представлен Фреймворк Системы стандартизации бизнес-процессов компании. В него включены все процессы, которые необходимы компании для управления внутренними нормативно-методическими документами (регламенты, положения, инструкции) в рамках всего жизненного цикла: планирование, разработка и внедрение регламентов, обучение и аттестация, актуализация, контроль использования, отмена.

Цели создания Фреймворка

Вашему вниманию предлагается Фреймворк Системы стандартизации бизнес-процессов компании. В 2015 году я издал книгу «Бизнес по правилам: регламенты должны работать». Она и сейчас продается в издательстве «Инфра-М». В рамках данной книги была предложена архитектура Системы стандартизации бизнес-процессов и разработана методика оценки зрелости такой системы. Информация, представленная в книге, продолжает, на мой взгляд, оставаться достаточно актуальной и полезной. Тем не менее, настало время несколько обновить процессный Фреймворк. C одной стороны, целесообразно было упростить некоторые процессы, с другой – сделать модели процессов в нотации BPMN в большей степени ориентированными на автоматизацию. В данной статье представлен результат переработки Фреймворка с учетом указанных аспектов.

Общая модель Системы стандартизации бизнес-процессов (ССБП)

На рис. 1 представлена общая модель (Фреймворк) Системы стандартизации бизнес-процессов (ССБП) компании.

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

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

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

Принцип построения Фреймворка ССБП – жизненный цикл внутренних нормативно-методических документов компании (регламенты, положения, инструкции): от разработки и ввода в действие, до анализа использования и отмены ВНМД. Не нужно путать ВНМД с планово-отчетными и организационно-распорядительными документами. Для управления документами указанных типов нужны другие бизнес-процессы. Они не входят в рассматриваемый Фреймворк.

1. Управление регламентацией процессов

На рис. 2 представлена схема процесса «Управление регламентацией процессов». На ней представлен контур управления ССБП: ежегодный и ежемесячный.

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

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

План может создаваться на год по месяцам с последующей ежемесячной корректировкой. Форма плана – файл в MS Excel. Документ может включать в себя одновременно плановую и фактическую информацию.

Для корректной работы по планированию Процессному офису нужны соответствующие нормативы. Например, работа по созданию одноуровневого регламента бизнес-процесса на основе уже готовой и согласованной графической схемы в нотации BPMN может занять от 8 до 32 часов в зависимости от структуры регламента (простая или сложная). Например, создание регламента, включающего схему, текстовое описание, цели и показатели, требования к ресурсам, описание действий в случае отклонений, риски, контрольные процедуры может занять 24-32 часа рабочего времени Бизнес-аналитика Процессного офиса (без учета времени сотрудников подразделений, принимающих в этом участие).

Если у вас есть возможность, то целесообразно автоматизировать планирование и отчетность в специализированной системе.

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

Проект Плана рассматривается и утверждается на Процессном комитете. Если у вас нет Процессного комитета, то его роль могут играть Комитет по ИСМ, Совет директоров или просто ЕИО (Генеральный директор).

Далее ежемесячно, например, 20 числа каждого месяца, Бизнес-аналитик Процессного офиса выполняет анализ исполнения Плана РАО на месяц и готовит соответствующий Отчет.

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

В случае необходимости он выполняет корректировку Плана РАО. В этом случае проект Плана РАО с корректировками передается на рассмотрение и утверждение на Процессом комитете. Далее цикл продолжается.

2. Разработка/корректировка ВНМД

На рис. 3 представлена схема процесса «Разработка/корректировка ВНМД». Участники процесса показаны при помощи ролей: «Разработчик ВНМД», «Руководители, согласующие ВНМД», «Бизнес-аналитик».

Разработчик ВНМД приступает к разработке в соответствии с Планом. В зависимости от ситуации, могут использоваться следующие документы: 1) модель (модели) бизнес-процесса в нотации BPMN (согласованная); 2) текущая версия ВНМД; 3) предложения по корректировке/дополнению ВНМД, накопленные в базе знаний, в том числе – предложения сотрудников.

В рамках рассматриваемого Фреймворка формирование проекта ВНМД осуществляется в Business Studio путем заполнения необходимых атрибутов модели: текстового описания задач процесса, привязки целей и показателей, определения методов контроля, привязки форм рабочих документов и т.п. После подготовки проекта ВНМД, разработчик, в качестве самоконтроля, проверяет документ с использованием чек-листа. Если по ходу работы выясняется, что необходимо изменить схему процесса, инициируется процесс «Описание процесса в нотации BPMN».

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

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

Процесс согласования может быть разработан для компании в целом и использован на схеме в качестве типового (процесс-ссылка в Business Studio).

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

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

3. Ввод ВНМД в действие

На рис. 4 показана схема процесса «Ввод ВНМД в действие». Разработчик ВНМД запрашивает у Бизнес-аналитика код ВНМД. Бизнес-аналитик присваивает ВНМД код в соответствии с утвержденными правилами и вносит проект ВНМД в Реестр ВНМД.

Разработчик ВНМД готовит проект приказа о вводе ВНМД в действие и, в качестве приложения к нему, — План внедрения ВНМД.

Здесь нужно сделать небольшое отступление. Как вы думаете, когда руководитель ставит свою подпись «Утверждаю» на проекте регламента, это магическое действие? Любое магическое действие должно приводить к мгновенному исполнению задуманного (это – шутка). Когда новый ВНМД утверждается, означает ли это, что его требования начинают мгновенно и правильно выполнять сотрудники организации? Конечно, нет. Прежде всего, они должны узнать о том, что новый документ введен в действие. Затем ознакомиться с ним. Понять требования и научиться их исполнять. Это даже вопрос не одного дня, а целого переходного периода. Не говоря уже о том, что необходим контроль исполнения требований нового регламента со стороны руководителей. Именно поэтому внедрение ВНМД – это не только утверждение соответствующего документа, это – целый процесс, который должен быть запланирован и выполнен в организации. Для этого создается План внедрения ВНМД.

Этот документ может содержать следующую информацию: 1) перечень лиц для ознакомления с ВНМД; 2) план по обучения/инструктажу сотрудников по ВНМД; 3) контрольные действия на переходном этапе (кто, когда и как будет контролировать исполнение требований нового регламента); 4) создание «горячей линии» для ответа на вопросы сотрудников по новому документу; 5) сбор обратной связи (оценку) по новому ВНМД от руководителей и сотрудников и прочее.

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

Если замечаний нет, то комплект документов передается на утверждение. Комплект включает: 1) согласованный проект ВНМД; 2) проект приказа в вводе ВНМД в действие; 3) План ввода ВНМД в действие.

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

Далее владелец процесса/руководитель подразделения организует выполнение плана внедрения ВНМД.

4. Размещение ВНМД в архиве, на портале и уведомление о статусе

На рис. 5 представлена схема процесса «Размещение ВНМД в архиве, на портале и уведомление о статусе». Выполняет процесс Бизнес-аналитик Процессного офиса.
На схеме показаны два стартовые события: «ВНМД утвержден» и «ВНМД отменен». Далее представлены два разных потока работы.

В случае, когда ВНМД утвержден, Бизнес-аналитик:

1. изменяет статус ВНМД в Реестре ВНМД;
2. сканирует ВНМД и помещает оригинал ВНМД в архив документов компании;
3. размещает ВНМД в базе Business Studio (публикация на портале BS Portal выполняется автоматически по расписанию);
4. выполняет рассылку уведомлений в вводе ВНМД в действие (например, по e-mail).

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

В случае, когда ВНМД отменен, Бизнес-аналитик:

1. изменяет статус ВНМД в Реестре ВНМД;
2. удаляет ВНМД из Business Studio;
3. помещает оригинал ВНМД в архив отмененных документов;
4. утилизирует оригинал ВНМД (при необходимости);
5. выполняет рассылку уведомлений об отмене ВНМД (например, по e-mail).

Особенностью рассматриваемого процесса является использование:
• Реестра ВНМД;
• внутреннего портала (базы знаний компании по бизнес-процессам);
• бумажного архива ВНМД.

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

Уведомление сотрудников в вводе ВНМД в действие (или отмене) является весьма важной задачей. Этот процесс доведения информации должен быть четко проработан. В идеальном варианте, сотрудники должны подтверждать свое ознакомление с этой информацией.

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

5. Выдача учтенных копий ВНМД

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

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

В случае, если ВНМД отменен, Бизнес-аналитик делает отметку об отмене ВНМД в Реестре и уведомляет сотрудников, использующих копии данного документа. Сотрудники обязаны изъять и утилизировать копии ВНМД (данная задача не включена в рассматриваемый процесс).

6. Контроль необходимости актуализации ВНМД

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

Ежемесячно, 15 числа месяца Бизнес-аналитик Процессного офиса отправляет напоминания сотрудникам, ответственным за актуализацию ВНМД (не всем, а только тем, у которых подходит плановый срок актуализации). Задачу напоминания, кстати, целесообразно автоматизировать (например, в BPMS).

Ответственные за актуализацию предоставляют отчеты о статусе (нужна/не нужна) актуализации и планируемых датах ее начала.

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

7. Отмена ВНМД

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

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

8. Анализ использования ВНМД

На рис. 9 показана схема процесса «Анализ использования ВНМД». К сожалению, системно анализ использования ВНМД в компаниях, как правило, не ведется. Поэтому обратите на рассматриваемый процесс особенное внимание.

Один раз в полгода (или ежегодно) Бизнес-аналитик последовательно выполняет следующие задачи:

• проводит анкетирование сотрудников по ВНМД для выявления их актуальности и практической полезности;
• анализирует статистику использования ВНМД на внутреннем web-портале (сколько раз смотрели документы, как долго и т.п.);
• выполняет анализ результатов аудитов в части несоответствий по ВНМД;
• выполняет анализ предложений сотрудников по улучшениям ВНМД (поданных, внедренных).

После этого Бизнес-аналитик формирует Отчет по использованию ВНМД и предоставляет его руководителю Процессного офиса. После того, как Руководитель согласует Отчет, Бизнес-аналитик помещает его в базу знаний компании.

Отчет используется для планирования работы с ВНМД в рамках процесса «Управление регламентацией процессов».

9. Обучение и аттестация по ВНМД

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

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

Далее он готовит/корректирует вопросы для аттестации. Для этого используется Методика подготовки вопросов и действующие ВНМД.

Технически вопросы для аттестации могут быть занесены в соответствующие атрибуты процессов (и других объектов) в базе данных Business Studio.

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

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

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

Информация по итогам аттестации предоставляется сотрудникам и руководителям подразделений
Бизнес-аналитик помещает результаты аттестации в архив (базу знаний). В случае, если необходимо дополнительное обучение, то Бизнес-аналитик ставит задачу разработчикам ВНМД на проведение обучения.

После проведения соответствующего обучения разработчики ВНМД уведомляют Бизнес-аналитика и руководителей подразделений о проведенном обучении.

10. Контроль исполнения ВНМД руководителями

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

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

По итогам проведения контроля его результаты (факт, причины, предложения) фиксируются в журнале контроля ВНМД (в электронном виде).

Далее, при необходимости, руководитель принимает решения и проводит работу с сотрудниками, допустившими нарушения требований регламентов.

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

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

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

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

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

Таблица сравнительного анализа

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

Андрей Краснобаев, Директор по качеству СТД «Петрович», практик в области организационного развития.

Вячеслав Гончаров, Начальник управления технологического сопровождения АО «Концерн «Уралвагонзавод».

Наталья Косарева, Руководитель компании. Эксперт в области организационного развития. Эксперт в области аудита производственных систем. Организатор Кубка Гастева. Член ABPMP Russian Chapter

Юрий Федосеев, Начальник отдела оптимизации бизнес-процессов и стандартизации ООО «ИНК».

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

«Если посмотреть в общем, то данный Фреймворк действительно имеет практическое применение. Многие методологические аспекты нашего процесса были взяты из первой книги В.В. Репина «Бизнес по правилам…». И сейчас, спустя годы, они продолжают успешно работать. Если уходить в детали, то в каждой компании тот или иной представленный процесс может работать несколько иначе. На это оказывают влияние применяемые информационные системы, сложившиеся практики работы с документами, этап развития, территориальная разрозненность подразделений и даже особенности корпоративной культуры организации».
Юрий Федосеев

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

Выводы

В статье представлен Фреймворк Системы стандартизации бизнес-процессов компании (ССБП). Это часть общей Системы управления бизнес-процессами (СУБП).
Использовать представленный в статье материал вы можете следующим образом:

1. сравнить существующие у вас процессы и решения с представленными во Фреймворке;
2. найти отличия (то есть провести так называемый «маппинг»);
3. дополнить/скорректировать вашу модель работы с ВНМД;

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

В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент», член ABPMP Russian Chapter.

Апрель 2022 г.

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

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

Из практики известно, что один и тот же процесс любой бизнес-аналитик может смоделировать десятками разных вариантов. И каждый вариант процесса может иметь свою «правду жизни». Какую “правду” выбрать? Ту, которая нужна владельцу процесса. На примере процесса обработки заявки попытаюсь рассмотреть влияние идеологии на моделирование процесса (носитель идеологии – владелец процесса, остается скрытым, но незримо присутствует в данной статье). Обработка заявки – это типовой бизнес-процесс, который «живет» внутри любой организации, – обработки заявки на закупку, заявки на подбор персонала или заявки на какой-либо иной сервис внутри организации. Ниже будут рассмотрены варианты ролевых моделей этого процесса. Процесс описан в максимально простой нотации «процедура», поддерживаемой Business Studio, где постараюсь проиллюстрировать влияние идеологии на описание процесса. Также представлен вариант процесса в нотации BPMN (рис.2).

Для простоты я определяю идеологию как совокупность требований/ценностей/принципов, которые владелец процесса транслирует в процесс всем своим образом действий, стилем управления, способом коммуникаций и т.д. Требования к централизации приемки заявок, требования к контролю качества исполнения заявок (внутренняя оценка, т.е. оценка в компании и/или внешняя оценка качества исполнения заявки), требования к разделению ответственности между исполнителями заявок, требования к фиксации факта/срока выполнения заявки и другие требования – все вместе и в совокупности составляет идеологию, составляющую базу для моделирования целевого процесса «to be». Чаще бывает так, что владелец процесса именно в диалоге с бизнес-аналитиком оттачивает свои мысли, глубже осознает свои требования к настройке “своего” бизнес-процесса в контексте конкретной организации.

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

Свободное текстовое описание бизнес-процесса обработки заявки:
Стартовое событие: регистратор зафиксировал получение заявки от заказчика.

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

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

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

4 шаг: приемка выполнения заявки.
На 4 шаге руководитель принимает заявку и закрывает ее как исполненную или отправляет ее на доработку.

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

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

2 вариант описания процесса:

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

3 вариант описания процесса:

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

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

• Количество/ доля своевременно выполненных заявок;
• Количество/ доля несвоевременно выполненных заявок;
• Количество/ доля невыполненных заявок;
• Количество/ доля заявок, направленных повторно на выполнение;
• Количество/ доля заявок, выполненных 1 сотрудником;
• Количество/ доля заявок, некорректно квалифицированных и т.д., с учетом типов заявок, видов клиентов, географии бизнеса и других аналитических признаков.

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

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

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

Сергей Третьяк, Эксперт по стратегическому менеджменту, разработке BSC, OKR. Руководитель проектов орг. развития, руководитель отдела организационного развития, руководитель проектного офиса.

Статья адресована читателям, которые используют или предполагают использовать программный продукт Business Studio, в частности BS Portal (web-портал). Рассматриваются возможности и ограничения Business Studio и BS Portal для поддержки оперативного управления бизнес-процессами компании.

Введение

Business Studio – хороший инструмент для моделирования и регламентации бизнес-процессов. При грамотном методическом подходе можно получать качественные графические схемы процессов и автоматически сформированные регламенты, основанные на 100% понимании этих процессов. Кроме того, все эти модели и регламенты можно просматривать в виде гипертекстовых страниц при помощи приложения BS Portal, что дает возможность сотруднику относительно быстро находить нужную ему информацию регламентирующего или справочного характера.

Но процессное управление – это не создание регламентов. В первую очередь, это оперативное управление бизнес-процессами. Цель небольшого исследования, которое я провел, состоит в анализе возможностей Business Studio в комплекте с BS Portal для поддержки оперативного управления бизнес-процессами компании.

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

Предполагаю так же, что читатель уже имеет минимальный набор знаний об архитектуре Business Studio и видел в работе BS Portal (см. http://www.businessstudio.ru/load/portal/).

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

Функционал для регулярного оперативного управления бизнес-процессами – что в него должно входить? Какие инструменты может использовать владелец процесса (руководитель структурного подразделения)? Другими словами, нужен методически грамотный ответ на вопрос: «Что есть оперативное управления бизнес-процессами»? Ответ на этот вопрос не так прост, как может показаться на первый взгляд.

Замечу, что контроль прохождения экземпляров процессов в BPMS я рассматриваю как небольшую (не более 5-7%) часть задач оперативного управления процессами. Так что если у вас нет системы автоматизации процессов такого класса, это не означает, что у вас нет, или не должно быть управления бизнес-процессами.

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

1. Оперативное планирование процесса (деятельности подразделения).
2. Мониторинг и контроль процессов по показателям;
3. Анализ причин отклонений в процессе и принятие решений (выбор — коррекция или корректирующее действие);
4. Оформление, выдача и контроль исполнения разовых задач по процессу (в т.ч. коррекций).
5. Планирование, организация и контроль исполнения корректирующих действий по процессу.
6. Оперативный контроль исполнения требований нормативно-методических документов (регламентов).
7. Анализ процесса в целом (в т.ч. на основе статистики), планирование, организация и контроль исполнения внутренних проектов развития (PDCA).
8. Оперативный контроль экземпляров бизнес-процессов.

Хотел бы обратить внимание, что автоматизация задач 1-3 во многих компаниях до сих пор отсутствует. Руководители используют подручные средства для хранения и анализа информации: свою голову, ежедневник, файлы MS Excel и т.п. В более продвинутых компаниях применяют BI-системы, автоматизируют работу с поручениями, внедряют документооборот, BPMS и проч.

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

Посмотрим, насколько Business Studio и, в особенности, BS Portal смогут помочь нам в поддержке указанных выше задач.

Персональная страница на портале

Итак, заходим на портал Business Studio. В рассматриваемой компании (демо-базе) я назначил себя на должность Коммерческого директора (на Генерального – скромность не позволила).

Для входа на портал нужно ввести свой логин и пароль. Кстати, я поменял логотип производителя на логотип моего портала www.bpm3.ru (там можно купить Business Studio и заказать консалтинг, извините за продакт плейсмент).

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

Для настройки пиктограмм разделов нужно разместить новые файлы в системной папке BS Portal. Через интерфейс Business Studio сделать это не получится. А уж если говорить о настройке стилей, то придется редактировать файл css.

Разделы «Показатели», «Цели» и «Документы» формируются по умолчанию, хотя их можно отключить. Но я оставил – их вполне можно использовать. Было создано несколько новых разделов, внутри которых используются так называемые разделители. Например, есть раздел «Мои процессы и НСД». В нем первый разделитель – «Управление процессами». Внутри некоторых разделов в виде гиперссылок показаны названия отчетов, в некоторых – «Коммерческий директор». Дело в том, что движок Business Studio работает следующим образом. Для отчетов, сформированных по классу физические лица, он выводит название самого отчета. Для отчетов по классу «Субъекты» — название должности. Если бы я занимал две должности в рамках данной модели (например, был бы еще Директором ООО «СбытПромЗакупка» — дочерней компании), то кроме «Коммерческого директора» была бы видна должность «Директор». Дело в том, что разработчики считаю, что в компаниях физические лица часто занимают несколько должностей.

Кстати, функционал настройки персональной страницы в Business Studio выполнен весьма сложно – нужно провалиться вниз на 9 уровней различных меню (если я не сбился со счета), чтобы сделать все необходимые настройки. Чтобы их проверить – снова на 7 уровней вниз и т.п. Понятие «Предпросмотр» web-страницы отсутствует и проч. Нужно запустить портал на формирование, и только потом смотреть результат.

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

Контроль процесса по показателям

Давайте зайдем в раздел «Мои показатели» на персональной странице, выберем один из показателей и посмотрим, что покажет система как результат работы стандартного отчета. Результаты представлены на рис. 4.

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

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

Так же в системе можно сделать своеобразный drill down. Если показатель является расчетным (т.е. считается по формуле на основе других показателей), то по гиперссылкам можно «провалиться» на отчет по соответствующему показателю.

Таким образом, если вы хотите контролировать показатели на BS Portal будьте готовы перемещаться между разными web-страницами с разными показателями (через Персональную страницу или Навигатор), с простейшей графикой и почти полным отсутствием интерактива. Можно сказать, что в BS Portal нет и 5% от функционала не самой дорогой BI-системы. Возможно, за свои деньги (1200 рублей за одну лицензию портала) это вполне адекватный функционал. Кроме того, хочу еще раз напомнить, что основное назначение системы – моделирование и регламентация деятельности организации. BS Portal нужен для вывода информации о моделях процессов и регламентов в интерактивном, гипертекстовом виде. Если эта задача для вас основная, то лучшего инструмента вы сегодня на рынке не найдете.

Мои процессы и НСД

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

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

Возможность создания такого рода отчетов – «плюс» как самой Business Studio, так и BS Portal. Легкость доступа к разработанным моделям процессов очень важна. Часто, причем даже в крупных компаниях, процессная модель остается «военной тайной» подразделения организационного развития и не доводится до линейных руководителей. Но ведь именно они являются потребителями этой информации! BS Portal в такой ситуации может оказаться реальным решением проблемы информирования широких масс сотрудников о процессных наработках.

Следующий отчет – «Процессы, в которых я участвую». Его задача – показать все операции, которые выполняет сотрудник, занимающий данную должность. Важно быстро находить требования к работе, которую нужно выполнить. Перелистывать десятки (если не сотник) бумажных регламентов невозможно. Поэтому BS Portal дает отличную возможность доступа к информации регламентирующего характера. Результат работы отчета представлен на рис. 6. Хочу заметить, что вид таблицы определяется пользователем – можно вывести всё, что необходимо руководителю (например, требования к срокам, периодичность выполнения, даты и т.п.).

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

Вернемся к разделу «Мои процессы и НСД». Последний отчет в данном разделе подготовлен для демонстрации возможности вывода фотографий. В данном случае я создал справочник оборудования, используемого в процессе. Добавил (через Meta Edit) поле для закачки фотографий и сделал соответствующий отчет – см. рис. 8.

Естественно, кроме названия и фото можно добавить всё, что угодно – описание, технические характеристики, порядок подготовки к работе и проч.

Мои страт. карты

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

Оперативный контроль

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

Первый отчет – «Оперативный контроль процессов». Результат его работы показан на рис. 10. Фактически, представленная таблица – это электронный ежедневник владельца процесса, в котором он осуществляет фиксацию отклонений процесса от нормального хода. Делается это на основании контроля значений показателей (через тот же BS Portal). Почему не хватает только отчетов с показателями? Попытайтесь ответить на простой вопрос: «Как убедиться в том, что руководитель регулярно мониторил процесс, фиксировал отклонения и разбирался с ними?!» Всё в голове или ежедневнике… Если вы сторонник неконтролируемого, субъективного ручного управления, то для вас этот вопрос покажется надуманным.

Вернется к отчету. Он включает: дату проверки, показатель, суть отклонения, формулировку причины отклонения, выбор реакции (коррекция или корректирующее действие), описание коррекции (оперативной разовой задачи в рамках процесса, необходимой для устранения отклонения), плановую и фактическую даты и т.п. Возможна дополнительная аналитика, классификатор отклонений и т.п. В правой части таблицы (на рисунке не видна) указан ответственный исполнитель и статус («Выполнено», «Не выполнено»). В крайней правой ячейке – ссылка на так называемое «Сообщение о несоответствии», созданное владельцем процесса по факту выявления отклонения и принятия решения о выполнении корректирующего действия. Почему так? Дело в том, что в Business Studio создать корректирующее мероприятие можно путем создания «Сообщения о несоответствии» (функционал СМК), для которого нужно указать список мероприятий. Кроме того, мероприятия можно создать для объектов «Несоответствия» и «Причина». Кстати, посмотреть нужные мероприятия в системе можно, но это неудобно. Замечу, что при настройке отчетов я старался максимально использовать штатную структуру данных Business Studio, а не громоздить новые классы и объекты через Meta Edit.

Теперь хотел бы обратить внимание читателя на простой, но ключевой аспект – все указанные выше данные можно внести только через интерфейс Business Studio. Через BS Portal это сделать невозможно (как, впрочем, и редактировать регламенты в гипертекстовом виде – это моя мечта). Напомню, что одна лицензия Business Studio стоит 76 800 рублей. Т.е. если владелец процесса хочет вести ежедневник контроля отклонений в BS, ему нужно будет потратит эту сумму. Хотя, стоит отметить, что сообщения о несоответствиях можно вводить через модуль Cockpit, который стоит 980 рублей.

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

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

Пример работы отчета представлен на рис. 11.

Как видно на рис. 11, в таблице есть такие столбцы, как: дата проверки, процесс, регламент (кстати по ссылке можно его открыть), пункт НМД (который проверялся), описание несоответствия и сообщение о несоответствии.

Следующий отчет – «КД, которые я контролирую». Расшифровка КД – корректирующие действия. Владелец процесса должен иметь оперативную информацию о статусе этих корректирующих действий. Иначе опять голова, ежедневник или Excel… Чуть не забыл 1С. Но в нем такие настройки есть далеко не во всех компаниях. Пример работы отчета представлен на рис. 12.

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

Последний отчет в рассматриваемом разделе – «Мои проекты» — см. рис. 13. При помощи этого отчета владелец процесса получает информацию по проектам внутреннего развития (PDCA), для которых он является контролирующим лицом. Опять же – приведена простейшая форма отчета. При желании можно вывести любые данные по проекту — даже График Ганта со статусом исполнения. Для этого можно присоединить соответствующий файл MS Project. При просмотре портала в MS Internet Explorer можно будет открывать этот файл на редактирование. На крайний случай, просто приложите скрин-шот из MS Project.

Но опять подчеркиваю, что для ввода данных потребуется полнофункциональная лицензия Business Studio. В BS Portal можно только просматривать информацию.

Другие разделы персональной страницы

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

Для прикола добавлен раздел «Мои фото», где сотрудник может что-то опубликовать. Однако механизм занесения фото в Business Studio таков – через текстовое поле формата rtf (тип атрибута «Изображение» хотя и есть в Meta Edit, но не поддерживается системой). Более правильный путь – создание специальных справочников через Meta Edit. В этом случае можно делать ссылки на файлы прямо из списка, доступного для каждой должности (процесса и т.п.).

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

Какие еще разделы можно добавить? Например, «Бенчмаркинг» или «Отзывы клиентов» и т.п. Важно помнить, для кого создается персональная страница. В этом контексте стоит обратить внимание на следующий момент. В BS Portal – внешний вид и структура персональной страницы (в т.ч. состав отчетов) не могут изменяться в зависимости от категории должности сотрудника. Например, для специалиста структура персональной страницы должна быть совершенно другой. Ему не нужны разделы по управлению процессом, аудитам и т.п. Но он увидит ту же страницу (как для «Коммерческого директора»), но большинство отчетов будут пустыми.

Резюме

Итак, подведем итоги. Что может Business Studio Portal в части поддержки оперативного управления бизнес-процессами:

Итог – соответствие функционала BS Portal задачам оперативного управления бизнес-процессами – всего 14%. Понятно, что моя оценка субъективна.

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

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

Октябрь 2016 г.

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

Краткое введение

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

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

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

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

Функционально-целевая модель ССБП

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

Как видно на рис. 1, основной результат или цель функционирования ССБП в целом – это «Возможность ведения прозрачного, управляемого и эффективного бизнеса» для собственников и топ-менеджмента. Не думаю, что для кого-то из собственников это не важно.
Надеюсь, вы обратили внимание на термин «Возможность» в формулировке результата. Честно говоря, я не люблю (на то имеются конкретные основания), когда используют термин «Обеспечение» при формулировке целей. Термин «возможность» — довольно близкий. Но в данном контексте понятные, корректные и актуальные регламенты – это действительно ВОЗМОЖНОСТЬ для руководителей — возможность эффективного контроля и управления процессами. А вот воспользуются ли они этой возможностью – это другой вопрос. Это другая часть системы управления, которую я в данной статье не рассматриваю.
Надеюсь, что представленная модель будет иметь для вас ценность. После осмысления схемы рис. 1, вы сможете четко обосновать для собственника компании ценность ССБП и суть каждого процесса в системе.

Рассмотрим кратко каждый процесс, представленный на схеме рис. 1.

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

Основной результат: возможность функционирования и развития системы стандартизации бизнес-процессов.
Описание: ССБП, как любая система, требует управления. Предоставленная себе самой она будет деградировать. К сожалению, такая ситуация наблюдается довольно часто.
Основной результат подпроцесса управления, на мой взгляд, — возможность ССБП выполнять свое функциональное назначение (как части более сложной системы), а так же ее развитие, синхронизированное с изменениями организации в целом. Уровень развития ССБП должен соответствовать уровню развития организации в целом. За управление ССБП должен отвечать конкретный руководитель организации, например Директор по организационному развитию.

2. Описание и оптимизация бизнес-процессов

Основной результат: Глубокое и адекватное понимание процессов бизнеса. Понимание возможностей оптимизации процессов
Описание: Первый результат дает возможность регламентации процессов. Если мы глубоко и адекватно понимаем выполняемые процессы, знаем важные практически нюансы, мы способны создавать регламенты, основанные на 100% понимании процессов. Это – одно из важнейших условий эффективной работы по регламентам.
Второй результат заключается в возможности инициации и выполнения внутренних проектов организационного развития, которые изменяют процессы организации. Точки старта – это понимание проблем в процессах и путей их устранения.

3.Разработка НДМ

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

4. Ввод НМД в действие

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

5. Поддержка базы знаний и web-портала

Основной результат: Возможность доступа к базе знаний для ведения бизнеса по стандартам.
Описание: Легкость и простота доступа к регламентирующим документам принципиально важна для эффективной работы ССБП. База знаний и, особенно, внутренний web-портал – это необходимые для этого инструменты. Основной результат процесса – возможность быстрого и легкого доступа к информации. Другими словами, — это создание информационного пространства в области регламентации деятельности компании.

6. Хранение НМД и выдача копий НМД

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

7. Контроль необходимости актуализации НМД

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

8. Инвентаризация НМД

Основной результат: Соответствие стандартов требованиям бизнеса.
Описание: Цель процесса практически повторяет цель процесса № 7, но методы выполнения этих процессов разные. Инвентаризация НМД проводится раз в полгода (год) более сложным методом. Выявляется реальное состояние каждого НМД с точки зрения актуальности и практической полезности для бизнеса.

9. Отмена НМД

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

10. Анализ использования НМД и оценка эффекта для бизнеса

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

11. Внутренний аудит

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

12. Обучение и аттестация по НМД

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

Модель потоков

На рис. 2 так же показана модель ССБП, но вместо описания ценности (главного результата), создаваемой каждый процессом, представлены потоки документов (информации).

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

Вполне вероятно, что читателю данная схема будет более понятна. Она вполне подходит для дальнейшей декомпозиции каждого подпроцесса, например, в нотации CFFC, BPMN или eEPC.
Хотел бы привести небольшую практическую рекомендацию по выполнению такой работы. Прежде чем начать формировать модели подпроцессов ССБП (т.е. выполнять декомпозицию), рабочей группе проекта внедрения ССБП целесообразно заполнить таблицу, содержащую следующие столбцы:
• №.
• Наименование процесса.
• Главная цель процесса.
• Входы (информация, документы).
• Выходы (информация, документы).
• Участники.
• Ответственный.

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

Резюме

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

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

Февраль 2016 г.

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

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

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

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 г.

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

Введение

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

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

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

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

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

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.

Управление процессами – основа эффективности и выживания компаний в будущем

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

Графическая схема или управляемый бизнес-процесс?

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

Все эти аспекты сложны в той степени, что не могут быть описаны при формировании простой графической схемы процесса. Что толку детально описывать процессы на 3-4-м уровне, если существует несколько системных ограничений, которые существенно снижают эффективность сквозного бизнес-процесса в целом? В связи с этим возникает мысль, что руководителям верхнего и среднего уровня важно системно (так сказать «по Демингу») посмотреть на свои процессы. Заниматься детальным описанием процессов в графической форме стоит тогда, и в ровно в той степени, когда это реально необходимо.

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

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

Карточка бизнес-процесса

Предлагаемая вниманию читателя «карточка бизнес-процесса» содержит 10 разделов:

1. Владелец процесса.
2. Выходы и потребители процесса.
3. Входы и поставщики процесса.
4. События.
5. Цели и показатели по процессу.
6. Ограничения.
7. Технология выполнения процесса.
8. Ресурсы процесса.
9. Риски.
10. Графические схемы процесса.

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

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

В разделе 5 необходимо описать существующие цели и показатели для управления процессом. В соответствии с методическим подходом (см. статью «Процессное управление: границы применимости») показатели могут быть следующего вида:
• общие показатели;
• показатели выхода процесса;
• показатели выполнения процесса;
• показатели входа процесса;
• показатели ресурсов процесса.
Классификация показателей по указанным видам не является обязательной, но она полезна при выполнении анализа процесса со всех важных точек зрения.
Последние три столбца таблицы заполняются следующим образом – ставится либо «ДА», либо «Нет». Если в подразделении (компании) существует (в какой либо форме) документ, в котором сформулированы правила (методика) расчета показателя, в то в столбце «Наличие метода расчета» ставится «Да». Если для расчета показателя есть фактические данные, то в следующем столбце «Наличие данных» так же ставится «Да». Последний столбец — «Наличие интерфейса» — показывает, можно ли автоматически сформировать отчет по показателю в какой-либо программе (кроме MS Excel). Если показатели рассчитываются вручную в данном столбце ставится «Нет».

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

Раздел 7 служит для «ревизии» технологии выполнения процесса. В первую очередь необходимо определить состав внутренних нормативно-методических документов, которые регламентируют процесс. Затем нужно определить внешние НМД. Далее необходимо обратить отдельное внимание на нормативные документы, которые устанавливают требования к продуктам/услуга процесса со стороны потребителей («стандарты качества потребителей»). Это важно для понимания требований, предъявляемых потребителями.
Далее в таблице разделе 7 представлены четыре вида учета. Если определенный вид учета реализован при выполнении процесса, то в первом столбце ставится «Да». Во втором столбце приводится краткое текстовое описание существующей системы учета.
Учет операций означает, что мы учитываем все операции, выполняемые по ходу процесса. Если выполнение какой-то части или вида операций не учитывается, то в первый столбец ставим «НЕТ». Это означает, что технология выполнения процесса (а значит, и сам процесс) не полностью находится под нашим контролем. В зависимости от требований ГД, данный критерий может более или менее жестким. Например, можно считать, что учета операций нет, если в одном из подпроцессов процесса отсутствует учет 10% выполняемых операций. «Жесткость» критерия зависит от требовательности руководителя. В принципе, все операции всех подпроцессов процесса должны учитываться (т.е. учет операций должен быть на всех уровнях).
Учет очередей означает, что фиксируется размер очереди обрабатываемых объектов перед каждой операцией процесса. Наличие очереди перед операцией означает, что выполняющий эту операцию ресурс загружен (не простаивает). Учет очередей необходим для понимания узких мест при выполнении процесса и возможности его последующей оптимизации (как, впрочем, и учет операций).
Учет расхода ресурсов дает нам возможность анализировать затраты ресурсов, связанные с выполнением процесса и рассчитывать различные показатели эффективности.
Учет производительности необходим для понимания и анализа результатов выполнения процесса.
Корректное заполнение раздела 7 является очень важным для понимания текущего уровня управляемости процесса.

В разделе 8 следует представить информацию о ресурсах, которые необходимы для выполнения процесса. К ним относятся: персонал, оборудование, ИТ-инфраструктура, среда, измерительный инструмент. При заполнении таблицы указывается тип ресурса, количество, приводится список НМД, устанавливающих требования к данному ресурсу.

В разделе 9 описываются риски, связанные с выполнением процесса. Как и в Разделе 6, здесь представлено три вида рисков: в зоне контроля, в зоне влияния, во внешней среде (вне зоны нашего влияния).

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

Реализация карточки процесса в Business Studio и вывод информации в web через BS Portal

Работу по заполнению карточки процесса (паспорта процесса) можно автоматизировать. Удобно это сделать в специализированной среде моделирования процессов Business Studio 4.0. Фактически, при помощи Business Studio можно построить базу знаний компании по бизнес-процессам.
Рассмотрим пример настройки карточки процесса на условном примере. Схема процесса, для которой была создана карточка, представлена на рис. 8.

Для того, чтобы можно было занести необходимые данные по процессу в Business Studio, необходимо создать ряд новых атрибутов для процесса. Для этого были выполнены определенные доработки модели данных при помощи инструмента Meta Edit (входит в комплект поставки Business Studio в версии Enterprise). Например, был создан новый класс для описания ограничений процесса – см. рис. 9.

Дополнение структуры данных в Meta Edit и формирование необходимого для вывода карточки отчета заняло около 2-х рабочих дней.
После того, как все необходимые доработки были сделаны, мы заполнили соответствующие поля для тестового процесса (примеры представлены на рис. 9 и 10).

Далее был сформирован web-портал при помощи Business Studio Portal. Карточка тестового процесса была выгружена из Business Studio при формировании портала при помощи специально разработанного шаблона отчета. На рис. 12 показано, как выглядит web-портал и карточка нашего тестового процесса.

Каждый руководитель подразделения может заполнить карточки для своих процессов прямо в Business Studio. Информация фактически сразу будет доступна всем заинтересованным руководителям и сотрудникам через web-портал. Например, Генеральный директор может оперативно посмотреть, как идет заполнение карточек, правильно ли определены клиенты, ограничения и риски, насколько хорошо поставлен учет по процессу, определены ли показатели для управления и т.п.

Выводы

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

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

Август 2013 г.

В настоящее время в большинстве российских компаний регламентирующие документы принято утверждать и хранить в бумажной форме. При таком подходе к регламентации исключительно сложно оперативно поддерживать актуальность регламентной базы, вносить изменения в связанные между собой документы, уведомлять пользователей об изменениях. Бумажная гора становится все больше. Регламенты быстро устаревают. Сотрудники не исполняют требования и т.п. Использование систем электронного документооборота (СЭД) улучшает ситуацию, но не кардинально. Хранение скан-копий регламентов в виде pdf-файлов не решает задачи быстрой актуализации множества связанных между собой документов.
Если ли выход из данной ситуации? Какие возможности предоставляют современные программные продукты? Что ждет нас в будущем? В статье Владимира Репина предпринята попытка ответить на эти вопросы. Основная идея статьи – использование web-решения в рамках средства моделирования для создания базы знаний по бизнес-процессам в масштабах компании.

Бумажные горы

«Какова трудоемкость описания и регламентации одного бизнес-процесса»? Этот вполне конкретный вопрос часто задают руководители, отвечающие за организационное развитие. Им нужно знать, сколько бизнес-аналитиков привлечь. Очевидно, что нужен какой-то норматив для обоснования численности сотрудников.
Для определения трудоемкости удобно ввести понятие «нормо-процесса». Такой нормо-процесс представляет собой схему на листе формата А4, содержащую от 8 до 12 операций (иногда – больше). Графическое описание нормо-процесса, ввод нужных данных в систему моделирования (текстовое описание операций, описание входов/выходов и событий, формы документов, цели и показатели, методы контроля и т.п.) плюс время на согласование вместе составляют около 4-5 полных рабочих дней работы одного бизнес-аналитика.
Представим себе, что нам нужно полностью регламентировать процессы сбыта крупной компании (3000 человек). Потребуется описать, как минимум, 60-80 нормо-процессов. Такая работа потребует около 400 рабочих дней. Один бизнес-аналитик будет выполнять ее почти 2 года. Очевидно, что нужно выделить больший ресурс. Так обычно и поступают руководители компаний, которые поверили в регламентацию процессов и предприняли активные действия по ихразработке и внедрению. В отдел орг. развития приглашают 4-5 специалистов. Пять специалистов смогут детально описать и регламентировать весь сбыт примерно за 4 месяца. Будет создано большое количество регламентов, которые после утверждения будут доведены до сотрудников сбыта.
Но жизнь не стоит на месте. Внутри и вне компании постоянно все меняется. Необходимо вносить изменения в регламенты, которые уже созданы. Причем изменения в одном регламенте (процессе), как правило, затрагивают и многие другие. Так же возникают изменения в структурных нормативных документах: в должностных инструкциях, положениях о подразделениях. Для поддержки уже существующей регламентной базы необходимо взять еще 2-3 бизнес-аналитиков.Растет бумажная гора регламентов. Растет численность штата бизнес-аналитиков. Растут расходы, а эффективность бизнес-процессов не повышается.
В чем же причина данной проблемы? Что является узким местом? Если бы узким местом было количество бизнес-аналитиков, работающих в компании, то простым увеличением их числа проблема была бы решена. Но это не так. Массив информации по бизнес-процессам становится настолько сложным, что даже 10 человек не могут быстро и эффективно вносить в него изменения. Что же делать? Отказаться от описания и регламентации совсем?! Нет. Надо искать причины проблем в используемой в компании технологии работы с регламентирующими документами. Рассмотрим 3 существующих технологических подхода к регламентации, представленные в следующей таблице.

Технология I. Традиционное решение
Традиционное решение (I) предполагает использование среды моделирования только для описания процессов и выгрузки регламентирующих документов. Выгруженный в файл MS Word регламент может быть отправлен нескольким сотрудникам по e-mail для получения замечаний. Полученные замечания вносятся в среду моделирования. Затем выгружается следующая версия файла с регламентом и так далее. После внесения всех замечаний, распечатывается бумажная версия регламента. Далее на бумажном документе собирают согласующие подписи (т.е. в каком-то смысле дублируют при этом предыдущую работу по согласованию). Обратим внимание на тот факт, что сбор подписей на бумажных оригиналах нормативно-методических документов является неотъемлемой чертой корпоративной культуры большинства российских компаний. Далее документ утверждается и в бумажной форме помещается в архив нормативно-методических документов компании.

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

Технология III. Web-портал
При использовании web-портала среды моделирования ситуация радикально меняется. Во-первых, нет необходимости формировать какие-либо регламентирующие документы в виде файлов MS Word. Вся информация о процессе представлена на web-портале, причем в интерактивном виде: графическая схема, ответственные сотрудники, требования к выполнению процесса, описание используемых ресурсов, цели и показатели и т.п. Все процессы связаны между собой – можно легко перемещаться от одного процесса к другому, просматривать требования к ресурсам и т.д. Согласование требований к процессу может осуществляться прямо на web-портале, причем с использованием ЭЦП (без необходимости установки СЭД).

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

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

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

Для сравнения мы выбрали лучшие среды моделирования бизнес-процессов: Business Studio 4.0, ARIS 9, Casewise и iGrafx 2013. В следующей таблице 2 представлены их функциональные характеристики с точки зрения работы web-портала.

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

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

Как видно из таблицы 2, современные среды моделирования очень похожи с точки зрения возможностей представления и работы с информацией на web-портале. Однако, есть и различия, которые могут сыграть свою роль при выборе соответствующей системы. Если руководством компании принято решение сделать ставку на безбумажную технологию регламентации процессов на web-портале, то нужно выбирать систему, обеспечивающую наиболее легкую и удобную работу сотрудников организации именно с web-порталом.
Ключевыми требованиями при выборе web-решения могут быть:
• простота и скорость размещения информации на web-портале;
• возможность автоматического обновления информации;
• возможность автоматической интеграции с другими базами данных (учетные системы, ERP) для автоматического вывода на портал информации по плановым и фактическим значениям показателей по бизнес-процессам;
• возможность согласования контента на web-портале с использованием ЭЦП.

Выводы

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

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

Июнь 2013 г.