В статье Владимира Репина представлен пример описания бизнес-процесса и настройки среды моделирования Business Studio для создания технического задания на автоматизацию бизнес-процесса в BPMS. Обсуждаются вопросы вовлечения руководителей и сотрудников подразделений компании в работу по проектированию исполняемых процессов и формированию ТЗ на автоматизацию.

Возможная постановка задачи

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

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

Постановка задачи. Необходимо с использованием Business Studio:
а) перевести все подготовленные схемы в универсальный формат, при этом:
б) создать архитектуру бизнес-процессов компании;
с) сделать процессы исполняемыми;
д) подготовить ТЗ на автоматизацию процессов в BPMS.

Поставленная задача может быть решена путем использования программного продукта Business Studio и нотации BPMN.

В данном случае, я привел пример только одной схемы. Если бы речь шла об автоматизации одного процесса, то не было бы никакого смысла переводить схему из MS Visio сначала в Business Studio, а потом в BPMS. Но совсем другое дело, когда нужно подготовить сначала модели нескольких процессов, взаимосвязанных с точки зрения технологии и входов-выходов.

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

Специалист по Business Studio Иван Глебов, считает, что «дополнительным положительным результатом использования среды моделирования Business Studio для формирования ТЗ является документирование функциональной архитектуры информационных систем, используемых для автоматизации бизнес-процессов. Архитектура информационных систем формируется в разделе «Программные продукты» среды моделирования Business Studio».

Перевод схемы в нотацию BPMN в Business Studio

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

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

Фрагмент схемы показан на рис. 3. Использованы маркеры операций, чтобы показать, какая операция будет выполняться пользователем в интерфейсе BPMS (Business process management system), а какая может быть выполнена скриптом (соответствующий маркер и серая заливка).

Не все операции процесса при переводе в исполняемый формат сохраняются в том виде, как на оригинальной схеме в MS Visio. При разработке модели процесса для BPMS многие действия рационально объединить в рамках одной операции.

Так же показаны информационные системы, которые в текущий момент используются для выполнения операций процесса, например, «АИС «Управление планом ПИР». Кроме того, в качестве примера, показана возможность отобразить документооборот на схеме процесса и используемые для хранения документов базы данных компании.

Стоит упомянуть, что возможен импорт схем, созданных в MS Visio, в Business Studio. Но в данном случае было быстрее нарисовать «правильную» схему заново, чем редактировать схему, полученную после импорта. Но этот пример не говорит о том, что так поступать нужно всегда. Функция импорта полезна.

Настройка аналитики по бизнес-процессу и формирование ТЗ на автоматизацию

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

Кроме того, для настройки BPMS требуется дополнительная информация, которая не представлена на схеме. Необходимо определить, какие аналитические данные нужны автоматизации процесса в конкретной исполняемой системе. Затем настроить Business Studio путем расширения объектной модели с использованием модуля Meta Edit так, чтобы можно было удобно вносить данные через интерфейс системы. На рис. 4 показан пример возможной настройки. Для каждой операции процесса доступна закладка «ТЗ на автоматизацию», которая содержит ряд полей (атрибутов), которые необходимо заполнить.

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

После занесения информации по всем операциям процесса, можно автоматически сформировать готовое Техническое задание на автоматизацию бизнес-процесса. Для этого в Business Studio настраивается специальный шаблон отчета. Возможна выгрузка в MS Word или в MS Visio в зависимости от требований проекта. На рисунках 5 и 6 показаны фрагменты такого ТЗ. В данном случае, ТЗ сформировано в весьма упрощенной, демонстрационной форме.

Какая еще аналитика может и должна быть собрана при подготовке к автоматизации процесса в BPMS? В своей статье Андрей Чепакин предлагает следующую структуру:

1. Схема инициации процесса.
   1.1. Роль «Инициатор бизнес-процесса».
   1.2. Мотив инициации бизнес-процесса.
   1.3. Способы запуска бизнес-процесса.
2. Схема создания ценности.
   2.1. Типизация клиентов/заказчиков бизнес-процесса.
   2.2. Составляющие ценности, формируемой процессом, по типам клиентов.
   2.3. Сценарии использования процесса его клиентами.
3. Схема работы процесса.
   3.1. Спецификация входов процесса.
   3.2. Спецификация выходов процесса.
   3.3. Определение единицы потока и ее состояний.
   3.4. Ролевая модель процесса.
   3.5. Спецификация метрик и показателей процесса.
4. Схема данных процесса.
   4.1. Спецификация данных процесса.
   4.2. Определение источников данных для процесса.
5. Схема контроля процесса.
   5.1. Спецификация контролируемых метрик и показателей.
   5.2. Способы сбора и обработки данных.
   5.3. Способы доставки информации владельцам процесса.
6. Схема обратной связи процесса.
   6.1. Способы доставки обратной связи участникам процесса.
   6.2. Способы получения обратной связи от клиентов процесса.
   6.3. Способы доставки обратной связи высшему руководству.
7. Схема компетенций процесса.
   7.1. Требования к перечню участников процесса.
   7.2. Требования к компетенциям участников процесса.
   7.3. Реестр возможностей снижения требований к компетенциям.

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

Интересные мысли по аналитике высказывает Денис Котов в своей статье. Он рекомендует включать в ТЗ на автоматизацию процессов в BPMS (кроме схемы) следующую информацию:
• Модель данных.
• Объекты системы (например, договор, закупочная процедура или клиент).
• Данные процесса (информация, относящаяся к конкретному экземпляру процесса).
• Отчеты.
• Автоматизации: эскалации руководителям, расчеты («математика»), бизнес-правила, проверка из базы данных, триггеры, интеграции.

Многие специалисты считают, что модель данных, кроме схемы, является ключевой для эффективного решения задачи автоматизации процесса в BPMS. В текущей версии Business Studio, к сожалению, нельзя создать графическую модель структуры данных, как это можно быть сделать, например, в ERWin (ER модель — entity-relationship model, модель «сущность — связь» — модель данных, позволяющая описывать концептуальные схемы предметной области). В Business Studio можно только описать атрибуты для всех документов, которые используются в моделях бизнес-процессов, как показано на рис. 7.

Иван Глебов отмечает, «что хотя в настоящий момент в среде Business Studio нет возможности графически моделировать структуру данных для ТЗ, но зато в ней есть возможность давать детальное описание атрибутов документов, используемых в процессах, что позволяет достаточным образом смоделировать необходимую структуру данных в «текстово-табличном» виде. При этом, посредством MetaEdit, таблицу атрибутов документа можно дополнить колонкой, в которой, при необходимости, можно указать другой документ в бизнес-модели, с которым атрибут документа должен иметь связь при автоматизации документа в информационной системе».

Кто будет настраивать BPMS?

Настройка любой BPMS включает, как минимум:

1. создание модели организационной структуры компании;
2. создание графической модели процесса;
3. определение участников процесса и их прав;
4. определение необходимых данных;
5. настройка показателей для контроля и управления процессом;
6. создание экранных форм;
7. проверка процесса и публикация на исполняемом сервере.

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

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

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

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

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

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

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

Сравнение двух подходов. Таблица.

В случае Варианта I (столбцы 3-4) руководители и специалисты подразделений владеют компетенциями:
• по описанию и анализу бизнес-процесса;
• по использованию базового функционала BPMS на уровне пользователей.

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

В свою очередь ИТ специалистов не нужно специально учить методам анализа и оптимизации процессов (TOC, Lean, KPI).

В случае Варианта II (столбцы 5-6) руководители и специалисты подразделений должны овладеть специальными компетенциями (см. красный шрифт) на весьма глубоком уровне.

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

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

Приведу пример. В моей книге «Моделирование бизнес-процессов в нотации BPMN. Пособие для начинающих. Часть I» представлены модели трех процессов. Первый процесс называется «Подача заявки на оплату». В компании может быть одновременно инициировано несколько экземпляров этого процесса. Второй процесс – «Согласование графика платежей на неделю». Он запускается по таймеру и выполняется один раз в неделю. Третий процесс называется «Оплата счетов». Он инициируется процессом «Согласование графика платежей на неделю». Модели процессов были созданы в Business Studio в нотации BPMN. Используя семантику BPMN, я показал на схеме, что каждый экземпляр процесса «Подача заявки на оплату» должен получить сообщения из процессов «Согласование графика платежей на неделю» и «Оплата счетов». Далее эти три схемы были переданы в качестве ТЗ специалисту по Elma, который быстро настроил исполняемые процессы в этой системе (большое спасибо!). При настройке нужно было решить несколько задач, явно выходящих за пределы компетенций бизнес-пользователя, а именно: дополнение структуры данных, создание переменных процессов, создание скриптов на C#, управляющих отправкой сообщений, доработкой модели процесса с учетом технологических особенностей работы скриптов.

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

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

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

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

В статье представлены результаты имитационного моделирования процесса «Рассмотрение и согласование оперативных заявок» в среде Business Studio. Выполнен анализ процесса «как есть». Определены направления оптимизации процесса. Разработана модель «как должно быть». Путем имитации процесса определен потенциальный экономический эффект от возможного проекта оптимизации, в т.ч. за счет автоматизации в BPMS. Статья может быть интересна специалистам в области организационного развития, использующим модели процессов в нотации BPMN в среде Business Studio.

Введение

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

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

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

В данной статье рассматривается имитационная модель реального процесса «Рассмотрение и согласование оперативных заявок». крупной промышленной компании. Используемый инструмент имитационного моделировании – Business Studio 4.2.

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

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

Автоматизация процесса практически отсутствует.

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

Исходная модель процесса для анализа «как есть» (80% заявок, поступающих в процесс, содержат ошибки).

Диаграмма процесса «как есть» представлена на рис.1. Участниками процесса являются:
• Инициатор подачи заявки.
• Оперативный персонал, в оперативном ведении у которого находится оборудование.
• Технический руководитель объекта.
• Оперативный персонал, в оперативном управлении у которого находится оборудование.

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

На рис. 2 показана интенсивность запуска процесса (нагрузка на процесс). В месяц поступает около 1200 оперативных заявок на обработку. Фактически, заявки могут готовиться в любое время, но процесс запускается только в период с 16 до 18-00 ежедневно. В другое время заявки просто не рассматриваются.

На схеме процесса показано время выполнения каждой операции. Например, для операции «Рассмотреть и согласовать заявку (совместимость)» сверху указано «Норм.Константа (0:05:00)». Это означает, что нормативное время выполнения данной операции составляет 5 минут. Там, где снизу операции написано «Ож.Константа…» это означает время ожидания выполнения из-за, например, отсутствия ресурса и проч.

Обратим внимание, что время выполнения первой операции процесса «Оформить оперативную заявку» не является константой. Около 64% всех заявок оформляется 5 минут. В 27% случаев необходимо собирать данные для заявки, а это занимает 15 минут. В 9% случаев сбор данных занимает 20 минут.

Такое дискретное распределение было выбрано, т.к. реальный закон распределения времени формирования заявок неизвестен, учета нет. Со слов экспертов по процессу «в 20-30% случаев заявка формируется 15-20 минут из-за необходимости сбора данных». Довольно неточное определение, к сожалению.

На схеме процесса (см. рис. 1) красным цветом показана вероятность перехода по соответствующим стрелкам после шлюзов. Так, например, переход по стрелке «да» после шлюза «Имеются критичные ошибки в заявке?» будет осуществляться с вероятностью 80% и т.п.

Имитация процесса проводилась для одного месяца – ноября 2018 г. По результатам имитации получены следующие данные:
• среднее время выполнения одного экземпляра процесса — 2 часа 40 минут;
• суммарная стоимость процесса за месяц – 128 тыс. рублей.

Анализ отчета по результатам имитации, сгенерированного Business Studio, показывает, что самая дорогая операция в рамках одного экземпляра процесса – это операция «Оформить оперативную заявку». Она стоит 32 рубля.

Измененная схема процесса — 10% заявок с ошибками.

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

Было принято решение выполнить имитацию для случая полной загрузки процесса — когда только 10% заявок имеют критические ошибки (требуется их переделка). Кстати, устранение ошибок при оформлении заявок – это первое необходимое действие по оптимизации процесса.

По результатам имитации для случая с 10% ошибочных заявок получены следующие данные:
• среднее время выполнения одного экземпляра процесса – 1 день и 6 часов (!);
• суммарная стоимость процесса за месяц – 320 тыс. рублей.

Видно, что поскольку процесс работает «в полную силу», во время имитации периодически возникает очередь на обработку заявок. Иногда длинна этой очереди достигает 10 часов. Если бы все заявки были корректными и не отклонялись, реальный процесс сразу бы стал нежизнеспособным (сотрудники «разгребали» бы заявки почти целый рабочий день и более).

Оптимизация процесса

Итак, какие же проблемы можно отметить в результате имитации процесса. Прежде всего это:

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

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

Полный список предложений следующий:
• заполнение заявок должно выполняться без ошибок и без ожидания данных (данные должны быть доступны в функциональной информационной системе);
• необходимо сокращение времени формирования заявок до 3 минут в 80% случаев;
• необходимо устранить операции типа «Передать» и «Получить»;
• необходима автоматизация самого процесса в системе класса BPM (Business Process Management);
• ряд операций необходимо сделать полностью автоматическими, например, «Сформировать/Внести заявку в сменное задание»;
• требуется создание единой базы данных в рамках функциональной ИС по управлению работой и обслуживанием оборудования;
• для всех операций необходимо сокращение времени выполнения операций за счет автоматизации.

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

По результатам имитации оптимизированного процесса получены следующие данные:
• среднее время выполнения одного экземпляра процесса – 1 час 34 минуты;
• суммарная стоимость процесса за месяц – 106 тыс. рублей.

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

Выводы по результатам имитационного моделирования процесса

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

Таблица. Сравнение процессов «как есть» и «как должно быть».

Таким образом, потенциальный годовой эффект от оптимизации процесса «Рассмотрение и согласование оперативных заявок» может составит 2,57 млн. рублей.

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

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

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

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

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

А.Э. Мельникова
Ведущий специалист по стандартизации отдела оптимизации бизнес-процессов и стандартизации
ООО «ИНК»

Декабрь 2018 г.

В статье Владимира Репина рассмотрены недостатки методологии SADT с точки зрения создания инженерной модели бизнеса (ИМБ). Сформулированы новые правила использования SADT, позволяющие создать такую модель. Статья адресована специалистам, которые разрабатывают архитектуру бизнес-процессов своих компаний с использованием нотации IDEF0 в инструменте Business Studio (и не только).

Введение

Более 15 лет назад, когда IDS Sheer вывел на рынок методологию ARIS, для моделирования процессов верхнего уровня в ней использовалась нотация VAD (Value Added Chain – цепочка создания ценности). Маркетологи, продвигавшие ARIS, заявляли, что нотация IDEF0 (SADT) безнадежно устарела, т.к. представляла собой «функциональный взгляд на организацию», а VAD – «процессный взгляд»… Они были неправы. Сегодня становится очевидно, что скорее умрет VAD в том виде, как он реализован в ARIS. Это просто набор значков, по сути, представляющий собой субъективное видение реестра бизнес-процессов компании. Вокруг выбора состава этих значков много шаманства с бубном (типа разделения процессов на основные и вспомогательные и т.п.), но инженерного подхода там точно нет.

Практически единственной и, казалось бы, доступной (в силу своей кажущейся простоты) методологией построения моделей сложных систем является SADT (Structured Analysis & Design Technique), на основе которой в 1963 году был создан американский стандарт IDEF0 (разрешен в России в виде РД IDEF0 – 2000).

Классической книгой по SADT до сих пор считается книга Дэвида А. Марки и Клемента МакГоуэна с предисловием Дугласа Т. Росса «Методология структурного анализа и проектирования». Ниже в статье я буду цитировать авторов этого фундаментального труда (другого такого же на русском языке не издавалось).

Речь пойдет о моделировании сложных систем. И вот первая цитата (курсив автора статьи):

«Под словом «система» мы понимаем совокупность взаимодействующих компонент и взаимосвязей между ними… Под термином «моделирование» мы понимаем процесс создания точного описания системы. Особенно трудным оказывается описание систем средней сложности, таких, как система коммутаций в телефонных сетях, управление аэровоздушными перевозками или движением подводной лодки, сборка автомобилей, челночные космические рейсы, функционирование перерабатывающих предприятий. С точки зрения человека, эти системы описать достаточно трудно, потому что они настолько велики, что практически невозможно перечислить все их компоненты со своими взаимосвязями… Наша неспособность дать простое описание, а следовательно, и обеспечить понимание таких систем делает их проектирование и создание трудоемким и дорогостоящим процессом и повышает степень их ненадежности. С ростом технического прогресса адекватное описание систем становится все более актуальной проблемой. SADT (аббревиатура выражения Structured Analysis and Design Technique — методология структурного анализа и проектирования) — это методология, разработанная специально для того, чтобы облегчить описание и понимание искусственных систем, попадающих в разряд средней сложности».

Что можно сказать? Крупная организация (от 1000 человек, например) – это сложная система. Разработка комплексной модели бизнес-процессов организации – это создание модели сложной системы.

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

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

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

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

Архитектура бизнес-процессов организации и проблемы ее построения

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

Архитектура бизнес-процессов — «совокупность взаимосвязанных или взаимодействующих БП компании, представленная в виде иерархического списка и графических моделей в нотациях IDEF0 и BPMN в программном продукте «Х».

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

• иерархическая модель бизнес-процессов, включающая 5-6 уровней декомпозиции;
• уровни 1-3 (уровень 0 – контекстная диаграмма), местами до 4, описаны в нотации IDEF0;
• уровни 4-6 и ниже описаны в нотации BPMN;
• общее количество «процессов» (разного уровня) на диаграммах 1-6 уровней – 262 144 (если считать по 8 объектов на каждом уровне).

Последняя цифра не должна никого вводить в заблуждение или пугать. Это транзакции -элементарные действия, выполняемые отдельными сотрудниками или информационными системами. Много это или мало? По сравнению с численностью транзисторов на кристалле последней модификации Intel – это очень мало… По сравнению с численностью сотрудников… много? Не факт. Если в вашем холдинге работает 10 тыс. человек, то это всего лишь 26 транзакций на человека. Очевидно, что сотрудник выполняет гораздо больше элементарных действий во время повседневной работы (а значит для полного описания системы нужен еще уровень 7 или, даже 8).

Конечно, глубина описания должна определятся практическими задачами, ключевыми из которых являются:
• утверждение зон ответственности владельцев процессов (руководителей верхнего уровня) за счет определения границ бизнес-процессов (стыковки по входам/выходам);
• определения целей и показателей для управления бизнес-процессами для решения задачи стратегического и оперативного управления (невозможно определить адекватные показатели для процесса, границы которого размыты);
• регламентация бизнес-процессов (причем в виде гипертекстовых документов на web-портале компании);
• автоматизации системы синхронизованных между собой бизнес-процессов (в BPM-приложениях, СЭД);
• архитектурная интеграция различных подсистем управления на основе единой процессной модели (процессы в разных подсистемах и ИС не должны существовать перпендикулярно друг другу);
• создание базы знаний о работе компании, в т.ч. системы стандартизации бизнес-процессов (включая элементы дополненной и виртуальной реальности).

Если же вы хотите создать полную цифровую модель бизнеса (что пока, конечно, утопия), то придется переходить на уровни 7-8. Но в ближайшем будущем, при использовании технологий Big Data, BPM, ERP, MES и искусственного интеллекта такая задача уже не будет казаться утопией…

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

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

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

По моему убеждению, борьба должна идти НЕ за «выделение» процессов (слово-то какое!), а полноту архитектуры бизнес-процессов с точки зрения выполнения всех задач бизнеса. При этом крайне важно четко определить границы каждого процесса и интегрировать его в систему. Границы процессов – это результат договоренности руководителей. Они могут и должны изменяться. Главное – полнота и связность архитектуры бизнес-процессов.

Посмотрите на рис. 1. На нем представлена цифровая модель здания.

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

Кстати, если вы внимательно посмотрите на так называемое «программное обеспечение для моделирования бизнес-процессов» (даже импортное), то увидите там идеологическое отставание функционала, как минимум, на 15-20 лет. Например, ни в одной такой системе невозможно быстро отключить те или иные «слои», чтобы увидеть те аспекты модели, которые интересуют аналитика в данный момент. Или, например, автоматически сформировать диаграмму всех процессов одного уровня со всеми связями между ними, отследить движение конкретного документа через систему или увидеть в виде анимации последовательность запуска процессов в рамках конкретного сценария… (ограниченные возможности такого рода есть в некоторых системах для Process Mining). Создание моделей сложных организационных систем в современном софте для бизнес-моделирования исключительно неудобно и трудоемко!

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

1. иерархическая модель, включающая связанные между собой схемы бизнес-процессов на 1-7 уровнях (по «горизонтали» и «вертикали»);
2. все бизнес-процессы имеют реальные связи (не абстрактно-обобщенные) со всеми другими бизнес-процессами, с которыми они взаимодействуют;
3. все связи должны базироваться на потоках реальных объектов (информация, документы, материальные ресурсы), используемых в организации;
4. бизнес-процессы должны быть стыкованы по входам/выходам в соответствии со своим уровнем иерархии (процесс нижнего уровня не может быть поставщиком, например, процесса уровня +3);
5. бизнес-процессы, описанные в нотации BPMN, должны быть синхронизованы между собой по событиям (там где это необходимо).

Посмотрим, насколько методология SADT годится для построения архитектуры бизнес-процессов организации в виде инженерной модели бизнеса (ИМБ).

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

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

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

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

Количество объектов

Во-первых, хотел бы отметить требование по количеству процессов на одной диаграмме. Ограничение SADT – от 3 до 6 объектов. Цитата: «Диаграмма ограничивается 3-6 блоками для того, чтобы детализация осуществлялась постепенно. Вместо одной громоздкой модели используется несколько небольших взаимосвязанных моделей, значения которых взаимно дополняют друг друга, делая понятной структуризацию сложного объекта…».

Но практика создания моделей организации показывает, что 6 – это слишком мало (8-10 – нормально). Если жестко следовать ограничениям SADT, то появляются псевдо-уровни, усложняющие модель без практической необходимости (особенно при использовании в методологии цикла PDCA, рекомендованного РД РФ по IDEF0). Возможно, ограничение в 6 объектов было уместно, когда чертежи делали вручную на кульмане. Но сейчас это требование, на мой взгляд, устарело.

Смысл стрелок на диаграммах

Теперь рассмотрим интерпретацию стрелок на диаграммах SADT. Для начала приведу несколько цитат:
• «Дуги на SADT-диаграмме изображаются одинарными линиями со стрелками на концах. Для функциональных SADT-диаграмм дуга представляет множество объектов…»
• «Таким образом, SADT-диаграммы не являются ни блок-схемами, ни просто диаграммами потоков данных. Это предписывающие диаграммы, представляющие входные-выходные преобразования и указывающие правила этих преобразований . Дуги на них изображают интерфейсы между функциями системы, а также между системой и ее окружающей средой…»
• «Дуга в SADT редко изображает один объект. Обычно она символизирует набор объектов…»
• «…дуги SADT изображают иерархические наборы данных…».

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

Еще одна цитата: «Представьте себе толстый телефонный кабель. Если вы разрубите его пополам, то увидите, что главный кабель состоит из нескольких меньших кабелей, которые, в свою очередь, состоят из еще меньших кабелей, и т.д. вплоть до отдельных проводов. Дуги SADT могут рассматриваться как кабели, соединяющие, разъединяющие и переносящие многообразие объектов. Вот почему дуги имеют разветвления и соединения…»

Итак, дуга SADT или стрелка на диаграмме IDEF0, например в Business Studio, — это труба по которой движется поток объектов: информация, документы, материальные ресурсы. Еще раз обращаю ваше внимание: «…кабели, соединяющие, разъединяющие и переносящие многообразие объектов..».

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

Количество стрелок

SADT ограничивает количество стрелок с каждой стороны процесса числом 6. Т.е. я могу провести шесть стрелок от одного процесса к другому. И здесь мы наблюдаем одно из самых методически плохо проработанных мест в SADT. Методом выбора стрелок и их именования является метод… пристального взгляда! Еще одна цитата:

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

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

Те, кто практически участвовал в проекте создания модели крупной организации в IDEF0, знают сколько копий было поломано и нервов потрачено на обсуждение смысла стрелок и их названий. Некоторые участники таких проектов просто пытались перечислять в названии стрелок все объекты, которые по ним перемещаются. Это хотя бы интуитивно понятно, но, конечно, запрещено методологией SADT.

Однонаправленность стрелок

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

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

Тоннельные стрелки

Крупнейшая провокация SADT – это тоннельные стрелки. Неопытные пользователи IDEF0 один раз вкусив «прелесть» тоннельных стрелок начинают их использовать даже… на диаграмме А0. В итоге разваливается вся модель.

Как же Марка и МакГоуэн обосновывают наличие тоннельных стрелок в методологии SADT? Вот некоторые цитаты (много, но по делу):

• «Тоннельные дуги, имеющие скрытый приемник, кончаются скобками, чтобы отразить тот факт, что такая дуга идет к какой-то другой части модели или выходит из нее или что она не будет более в этой модели рассматриваться…. Хотя мы неоднократно сталкивались с полезным применением этой методики, советуем применять ее с большой осторожностью. При неправильном использовании она быстро становится прикрытием плохого моделирования. Поэтому мы рекомендуем ее только опытным SADT-аналитикам, да и то редко…»
• «Тоннельные» обозначения были введены в SADT после нескольких лет интенсивного использования этой методологии в ряде областей. Опыт показал, что при описании сложных систем требуется большое число дуг для корректного и подробного представления системы (Прим. автора статьи: т.е. они увидели недостатки методологии SADT, но пошли не по тому пути!).
• «Тоннельные» обозначения используются для того, чтобы избежать хаотического заполнения нежелательными подробностями диаграмм высокого уровня. (Прим. автора статьи: но они же сами писали про необходимость ветвления и слияния дуг!).
• «… мы рекомендуем сначала проводить дуги сквозь границы блоков, а затем определять, в каких случаях это снижает качество описания (Прим. автора статьи: вот только как померить это качество?!). Только после этого можно помещать дуги в тоннели для улучшения читабельности модели…» (Прим. автора статьи: читабельность модели – идеальный критерий, чтобы сделать из инженерной модели симулякр).

Лично я считаю тоннельные стрелки наиболее слабым местом методологии SADT. Последствие их применения – создание модели, которая никакого отношения к инженерному походу не имеет. Однако, например в Business Studio, специально добавлен функционал так называемых «междиаграммных ссылок» (МДС), который делает перемещение между диаграммами, связанными тоннельными стрелками, простым и удобным. Но такая возможность искушает пользователей и они забывают про системность, соединяя блоки системы (процессы на уровнях 3 и 4) напрямую. Вспомните аналогию пука проводов, торчащих из ящика…

Создавать сначала модель объектов, а потом процессов

Приведу еще некоторые важные цитаты:

• «Чем лучше проанализированы объекты системы, тем полнее функциональные диаграммы будут описывать работу системы. Из этого следует, что декомпозиция данных должна начинаться раньше и проводиться согласованно с декомпозицией функций. Хорошая декомпозиция данных является ключом к хорошей декомпозиции функций..».
• «…Вот почему SADT предусматривает дополнительное описание полной иерархии объектов системы посредством формирования глоссария для каждой диаграммы модели и объединения этих глоссариев в Словарь данных. Таким образом, Словарь данных, важное дополнение модели, становится основным хранилищем полной иерархии объектов системы..».
• «Списки объектов системы, создаваемые в ходе моделирования, в SADT принято называть «списками данных»» Термин «данные» здесь употребляется как синоним слова «объект»… Составление списка данных является начальным этапом создания каждой диаграммы функциональной SADT-модели. Правило заключается в том, чтобы вначале составить список данных, а потом список функций…
• «В современных аналитических методах слишком часто уделяется повышенное внимание функциям в ущерб данным. Начиная с составления списка данных, вы сможете избежать перехода к немедленной функциональной декомпозиции. Списки данных помогут выполнить более глубокий анализ и при этом не концентрироваться на функциях системы, избегая пробелов, которые часто возникают из предвзятых представлений о функциональных декомпозициях».

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

Например, при моделировании в нотации IDEF0 в среде Business Studio многие бизнес-аналитики рисуют стрелки на диаграммах, но вообще не привязывают к ним объекты из справочника «Объекты деятельности». В результате модель оказывается крайне субъективной и оторванной от реальности.

Исключение составляет ситуация, когда сначала создают документ в справочнике «Объекты деятельности», а потом переносят его на диаграмму. Автоматически создается стрелка с тем же названием. По данной стрелке передается документ, на основе которого стрелка была создана. Но такой способ годится только на самом нижнем уровне описания в нотации IDEF0. Если применять его на А0, то вы получите лес стрелок и абсолютно нечитаемую диаграмму.

Кстати, в Business Studio 4.2. (текущая версия на момент написания статьи) сформировать иерархический справочник объектов деятельности невозможно – только линейный список. Либо приходится создавать псевдо-иерархию за счет использования папок.

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

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

Как можно доработать SADT для решения указанных проблем?

Сформулируем некоторые практические правила использования SADT для создания действительно инженерной архитектурной модели бизнеса (в Business Studio):

1. два процесса на схеме (в случае двустороннего взаимодействия между ними) могут соединяться только двумя стрелками («правило двух стрелок» — туда и обратно); стрелки (трубы) именуются, например, следующим образом: БП1.И1-БП2.В1 (исходящая стрелка 1 Бизнес-процесса 1 поступает как входящая стрелка 1 в Бизнес-процесс 2);
2. на каждом уровне модели (до уровня BPMN) определяются процессы управления;
3. по каждой стрелке должны двигаться реальные объекты из справочников (информация, документы, материальные ресурсы);
4. внешние ссылки разрешены только на диаграмме А0;
5. использование междиаграммных ссылок (МДС) запрещено на всех диаграммах (исключение может быть только одно – когда создано две отдельных модели в IDEF0 (у каждой своя контекстная диаграмма) и их нужно связать между собой. Но в этом случае допускаются только МДС на диаграмме А0).

На рисунке 2 представлена модель компании (промышленное производство), сформированная на основе представленных выше правил (кроме «правила двух стрелок» — пока выбрано некоторое промежуточное решение).

Использованы разные цвета для стрелок, по которым движутся объекты разного типа:
• красные стрелки — управляющие воздействия (ограничения, планы, приказы и т.п.);
• серые стрелки – отчетность всех видов, проекты планов и т.п.;
• синие стрелки – информационные и материальные потоки;
• розовые стрелки – запросы на предоставление сервисов (входы в обеспечивающие процессы);
• зеленые – ресурсы для выполнения процессов и результаты сервисов (оборудование, ИТ-сервисы, персонал и т.п.).

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

Вверху рисунка 2 показана процессная категория «Управление бизнесом». Из этого четырехугольника выходят стрелки красного цвета – стрелки управления, которые входят сверху во все остальные категории процессов.

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

Еще ниже представлен четырехугольник категории «Инженерно-техническое обеспечение». Из него выходят стрелки зеленого цвета – ресурсы, необходимые для выполнения остальных процессов (оборудование, ЗИП и проч.). На диаграмме видно, что эти зеленые стрелки заходят во все остальные процессы снизу в соответствии с методологией SADT.

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

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

Если бы в Business Studio была возможность включать/выключать отображение различных типов стрелок (например, показать только управление и отчетность), то модель можно было разрабатывать и смотреть по слоям. Такое решение было бы намного удобнее.

Представленная на рисунке 2 модель может показаться сложной. Но она имеет то преимущество, что все взаимодействующие процессы связаны стрелками, по которым движутся реальные объекты (информация, документы, материальные объекты). Это означает, что:
• можно четко определить входы/выходы процессов и зоны ответственности руководителей;
• для каждого процесса можно определить цели и показатели;
• процессы можно синхронизовать между собой.

Выводы

По итогам анализа недостатков методологии SADT можно сделать следующие выводы:
• методология SADT в классическом варианте содержит ряд допущений, которые не позволяют использовать ее для создания инженерной модели бизнеса (ИМБ);
• за счет отмены тоннельных стрелок и введения новых правил моделирования можно скорректировать методологию SADT и сделать ее применимой для создания ИМБ;
• существующие системы бизнес-моделирования (такие, как ARIS или Business Studio) крайне неудобны для создания сложной ИМБ;
• есть основания полагать, что ИМБ может служить платформой для создания полной цифровой модели бизнеса путем интеграции подсистем управления и ряда функциональных приложений на единой процессной платформе.

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

Ноябрь 2018 г.

В статье Владимира Репина рассмотрены типовые ошибки, которые допускают сотрудники организации, начинающие осваивать моделирование бизнес-процессов в среде Business Studio с использованием нотации BPMN. Обсуждается вопрос о возможности и целесообразности использования данной нотации для комплексного описания бизнес-процессов организации силами собственных сотрудников.

Введение

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

Для выполнения этой задачи нужны: эффективная система управления проектом, методология, инструмент (система моделирования) и человеческие ресурсы, адекватные по численности и подготовке. Если инструмент можно легко купить, то с методологией и ресурсами всё не так просто. Качество управления проектом сильно зависит от конкретного руководителя.

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

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

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

Кроме того, рассматривается вопрос о принципиальной возможности обучения сотрудников (не специалистов по орг. развитию или ИТ) нотации BPMN для комплексного описания бизнес-процессов организации.

Исходные данные для анализа

Исходные данные для анализа таковы. В ряде компаний (нефтедобыча, производство, ритейл и проч.) проводилось обучение временных рабочих групп (ВРГ) численностью 25-30 человек. Некоторые участники когда-то занимались «описанием» процессов при помощи «диаграмм с ромбиками» (в Business Studio – это нотация «Процедура) или сталкивались с нотацией eEPC. Но большинство специалистов созданием графических схем не занимались.

Обучение проводилось в течение 2 дней на основе методического пособия «Моделирование бизнес-процессов в нотации BPMN. Пособие для начинающих. Часть I» (В.В. Репин, 2018 год). В первый день слушателей последовательно знакомили с основами нотации BPMN. Они выполняли ряд связанных между собой заданий, моделируя процесс в среде Business Studio и двигаясь от простого к сложному.

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

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

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

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

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

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

Типовые ошибки моделирования, допускаемы начинающими

Проблема мышки

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

Оборванные входы-выходы

Следующая проблема – это оборванные входы-выходы. У неопытных и довольно безответственных рисовальщиков документы появляются «из воздуха», «зависают» на выходе операций процесса и никуда не попадают. Часто начинающие вообще не показывают на схеме потоки документов/информации.

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

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

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

Бывает обратная ситуация – на модели верхнего уровня входы/выходы есть, а при переходе на уровень вниз на процессы, описанные в нотации BPMN, эти входы/выходы теряются. Иногда на моделях нижнего уровня в нотации BPMN показывают информационные связи с процессами уровня + 2 выше. Как следствие – низкое качество модели компании в целом.

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

На мой взгляд, наличие потока документов на схеме процесса в нотации BPMN в Business Studio необходимо и практически полезно для целей анализа, регламентации и автоматизации.

На рисунке 1 приведен фрагмент схемы процесса с «оборванным» входом для операции «Проверить корректность заполнения заявки». Для операции «Проверить возможность выполнения заявки по режиму» входы/выходы вообще отсутствуют.

Некорректная логика процесса

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

Непонимание межпроцессного взаимодействия

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

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

Вторая проблема состоит в том, что отправку сообщений между разными процессами начинают показывать везде, где только можно, причем без всякого содержательного смысла:
• отправляют сообщение в другой процесс (свернутый пул на схеме в Business Studio), который не должен запускаться (инициироваться) – с ним просто есть взаимодействие по входам-выходам (причем, чаще всего, опосредованное – через базу данных или файл-сервер компании);
• отправляют сообщение в свернутый пул под названием «Все процессы», «Поставщик» или, что хуже всего, «Отдел такой-то…» (в Business Studio можно создать свернутый пул из так называемой «Внешней ссылки»);
• отправляют сообщение в процесс, который находится в дереве на 2-3 уровня выше описываемого и сформирован в нотации IDEF0 – отправка «на деревню дедушке»;
• показав отправку сообщения на схеме описываемого процесса, не открывают другой процесс и не дают себе труд продумать, куда попадает отправленное сообщение и как оно повлияет на выполнение другого процесса.

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

Использование таймеров

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

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

Описание процесса для одного объекта, которых в реальности множество

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

Процесс в процессе (рекурсия)

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

Красота схемы

Здесь все печально. Только 10-15% сотрудников стремятся сделать схемы красивыми. Для остальных это третьестепенная задача. Но некрасивую схему не хочется брать в руки, а тем более анализировать. Визуальная красота схемы – залог ее проработанности, что снижает трудоемкость последующих согласований и внесения изменений.

Накопление опыта и исправление ошибок

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

Хотел бы отметить, что для освоения навыков моделирования процессов на операционном уровне (в нотации BPMN) очень полезно показать сотрудникам имитацию выполнения процесса в Business Studio. Еще лучше, если после этого они сами попробуют запустить на имитацию отрисованный ими процесс, причем сначала пошагово, чтобы почувствовать себя той самой «мышкой» (токеном). Это упражнение дает хорошее понимание сути моделирования процессов Work Flow.

Выводы

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

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

1. «мышка» или идеология исполняемых процессов;
2. информационное взаимодействие внутри процесса и между процессами («стыковка по входам/выходам»);
3. корректное использование событий отправки-получения сообщений и синхронизация процессов между собой по событиям;
4. соблюдение уровней при описании межпроцессного взаимодействия (процесс BPMN может отправить сообщение только в процесс BPMN);
5. корректное использование событий-таймеров;
6. четкое отслеживание множественных объектов для обработки;
7. визуальная наглядность схемы («Красота схемы»).

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

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

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

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

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

Сентябрь 2018 г.

В статье Владимира Репина описана деловая игра по оптимизации бизнес-процесса, основанная на использовании имитационной модели, созданной в среде Business Studio. Цели игры – анализ процесса, поиск узких мест и «муды» (потерь), разработка предложений по оптимизации процесса. Рабочие группы анализируют процесс и предлагают ряд мероприятий по его оптимизации. Выполняется экспертная оценка предложений, отбираются практические реализуемые. Затем процессы перепроектируются в Business Studio с учетом обоснованных изменений. Проводится имитационное моделирование. Различные варианты моделей сравниваются между собой на основе показателей длительности выполнения и стоимости результата процесса. Игра может использоваться при проведении базового курса обучения процессному управлению в компаниях, в программах MBA и проч.

Введение

Цели деловой игры, предлагаемой вниманию читателя, следующие:

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

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

Сценарий игры

Организация

На группу участников (4-8 человек) распечатывается цветная схема процесса в формате А2.
Дополнительно распечатывается форма перечня предложений по оптимизации (2 листа на каждую группу, всего 6 листов).
Все участники делятся на 3 группы:

1. Команда «А» (выбирает себе название).
2. Команда «Б» (выбирает себе название).
3. Команда экспертов (желательно включить в нее несколько топ-менеджеров).
   Объявляются цели и правила игры. Цель игры – достижение лучших показателей за счет оптимизации бизнес-процесса. Используется два показателя: 1) длительность выполнения процесса; 2) стоимость результата процесса (в данном примере – это коммерческое предложение).

Демонстрация модели

Проводится демонстрация имитационной модели бизнес-процесса (с анимацией хода процесса в Business Studio).
Обсуждаются результаты имитации.
Обсуждаются целевые показатели процесса: 1) длительность выполнения; 2) стоимость результата процесса; 3) качество (количество ошибок и т.п.).

На рис. 1 представлена исходная схема процесса «Формирование КП клиенту». КП – коммерческое предложение. Речь идет о торгово-производственной компании B2B, которая выпускает стандартный ассортимент, но может по требованию заказчиков вносить конструктивные изменения в модели изделий, использовать другие материалы, цвета и т.п.

В процессе участвуют несколько сотрудников:
• Менеджер, ответственный за формирование КП клиенту (2 шт.);
• Начальник отдела продаж (1 шт.);
• Начальник Инженерно-технического отдела (1 шт.);
• Инженер Инженерно-технического отдела (1 шт.);
• Начальник ФЭО (1 шт.);
• Экономист ФЭО, ответственный за расчет стоимости изделия для КП (1 шт.);
• Коммерческий директор (1 шт.).

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

Процесс выполняется руководителями и специалистами. Практически после каждой операции процесса указаны шлюзы типа «Исключающее ИЛИ». Процесс ветвится – потоки работы разделяются с учетом вероятности. Например, после операции «Проверить расчет параметров изделия» в 20% случаев нужно переделать расчет, т.к. он содержит неточности (ошибки). Вероятности перехода показаны на схеме визуально в процентах красным шрифтом (это сделано вручную – в Business Studio нет возможности визуализировать вероятность перехода на схеме).

Стоимость рабочего времени участников процесса задана в модели. Менеджер получает 150 рублей в час, Начальник отдела продаж – 200 рублей в час и т.п. Другие показатели затрат (например, амортизация оборудования или затраты на аренду офиса) не заданы, т.к. не влияют на результаты игры.

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

На рис. 2 показан фрагмент пошаговой имитации процесса в Business Studio. Пошаговая имитация используется для демонстрации понятия потока работ (Work Flow) и понятия «экземпляр» процесса.

После пошаговой имитации, запускается имитация на интервале 1 календарный месяц.

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

1. средняя длительность процесса формирования коммерческого предложения – 9 дней 5 часов 24 минуты;
2. средняя стоимость подготовки коммерческого предложения — 3203,18 рублей.

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

Анализ процесса и формулирование предложений

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

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

Оценка предложений

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

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

Защита предложений

Команды представляют свои предложения по оптимизации процесса (3-5 минут).

Представили команды экспертов дают аргументированную оценку предложениям.
Затем группы могут потратить некоторое время на дискуссию.

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

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

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

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

Проводится имитация измененных моделей бизнес-процессов.
Определяются показатели процессов Команды «А» и Команды «Б».
Определяется победитель. Совместно обсуждаются итоги игры.

Примеры результатов выполнения игры

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

Одну группу можно условно назвать «Сдержанной», а другую «Радикальной».

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

По результатам имитации оптимизированного процесса получены следующие данные:

1. средняя длительность процесса формирования коммерческого предложения – 2 дня 12 часов 48 минут;
2. средняя стоимость подготовки коммерческого предложения — 1361,25 рублей.

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

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

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

По результатам имитации этого процесса получены следующие данные:

1. средняя длительность процесса формирования коммерческого предложения – 38 минут;
2. средняя стоимость подготовки коммерческого предложения — 47,98 рублей.

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

1. по длительности процесс улучшен в 350 раз;
2. по стоимости подготовки КП процесс улучшен в 67 раз.

Выводы

Вниманию читателя представлен сценарий деловой игры и примеры моделей процессов, полученные при ее проведении.

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

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

Кстати, при желании, можно организовать и провести такую деловую игру в вашей компании. Ее длительность около 4 часов. Буду рад сотрудничеству.

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

Апрель 2018 г.

Статья адресована читателям, которые используют или предполагают использовать программный продукт 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,5 месяца вы принимаете готовый дом и оплачиваете оставшуюся сумму. Во время строительства Вас на участке не было, а жена не могла (или не хотела) брать на себе ответственность за контроль над процессом. В результате, через некоторое время после приемки Вы начинаете обнаруживать скрытые дефекты. А вот их количество и степень важности зависят от компании-подрядчика: технология строительства, уровень культуры, подбор и стимулирование бригады, система контроля и т.п.
Если руководитель оперативно не контролирует процесс, то сотрудники могут начать выполнять работу не так, как требуется регламентом (т.е. технологией выполнения процесса), а так, как им выгодно и/или удобно. Например, им может быть выгодно сделать больший объем работы для получения премии (деньгами, свободным временем). Они могут попытаться сэкономить материал и использовать его в личных целях (продать, например) и т.п. Кроме того, они могут нарушать требования просто по халатности, лени или незнанию. Но до тех пор, пока руководителя интересует только конечный результат, сама работа, приводящая к этому результату, будет выполняться не так, как требуется регламентами, а так как удобнее, выгоднее, быстрее для исполнителей.

К чему ведет отсутствие оперативного контроля исполнения требований регламентов?

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

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

Классификация методов оперативного контроля исполнения требований регламентов

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

Объекты контроля:
• деятельность по управлению процессом;
• входы в процесс;
• деятельность по выполнению процесса (по технологии);
• оборудование;
• среда;
• персонал;
• результаты процесса.

Субъекты контроля:
• владелец процесса (руководитель подразделения, отвечающий за выполнение процесса);
• исполнители процесса (сотрудники);
• потребители результатов процесса (внутренние и внешние);
• поставщики входов (внутренние и внешние);
• внутренние аудиторы;
• представители подразделения организационного развития;
• прочие.

Методы контроля
• визуальный контроль;
• контроль по документам;
• контроль по показателям;
• контроль экземпляров процесса;
• неформальный контроль;
• внутренний аудит;
• прочие.

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

Информация для оперативного контроля исполнения технологии процесса

Давайте попробуем подойти к вопросу разработки методов оперативного контроля путем анализа:

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

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

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

Таблица 1. Информация для контроля исполнения требований технологии выполнения процесса

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

Оперативный контроль при помощи системы Business Studio

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

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

Выводы

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

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

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

Сентябрь 2016 г.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Март 2015 г.

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

Январь 2015 г.

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

В статье В.В. Репина предлагается структура «Карточки бизнес-процесса» и метод автоматизации работы с карточкой при помощи инструментальной среды моделирования процессов 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 г.