Как моделировать бизнес-процессы: советы и инструменты для руководителей

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

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

Сначала – о бизнес-процессах и о том, зачем их нужно моделировать

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

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

Банальный пример – общий подъём в армии: нужно определиться, во сколько вставать, сколько времени одеваться и тратить на туалет, куда идти на зарядку и при каких условиях (погода, ветер, наличие ограничений от дежурного по части), кто идёт, а кто остаётся, у кого освобождение, кто контролирует личный состав…

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

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

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

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

Бизнес-процессы бывают различных видов: управляющие, операционные и поддерживающие. Основная деятельность предприятия описывается в операционных бизнес-процессах.

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

Почти всегда внедрение бизнес-процессов присуще управленческой концепции BPM (Business Process Management), то есть все движения внутри компании рассматриваются исключительно как процессы. Надо поменять ценники после актуализации каталога? Бизнес-процесс. Нужно отзвониться клиенту по результатам закрытой сделки? Бизнес-процесс… И т.д.

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

Это легко сказать, но очень тяжело сделать.

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

BPMN (так называемые «нотации», в их основе производится разложение на конкретные функции – процессы, сам подход называется «процессным»).
EPC (моделирование на основе событий).
DFD (методология на основе диаграмм потоков данных).
IDEF (семейство методологий, основанных на логических последовательностях и взаимосвязях, включает в себя стандарты IDEF0, IDEF1x и другие).

О каждом из подходов можно почитать в Википедии.

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

Мы же подробнее остановимся на подходе BPMN, так как он является наиболее «правильным» с точки зрения проектирования отдельных процессов.

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

BPMN в действии

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

Текущая актуальная версия стандарта – BPMN 2.0 (ранее действующей была версия 1.2). Посмотреть документацию к стандарту и краткие руководства можно на официальном сайте проекта – bpmn.org.

Если погрузиться в технические детали, то можно обнаружить, что с графическими обозначениями BPMN тесно связан язык программирования BPEL (каждый объект здесь – это web-служба), который использует в своей основе синтаксис XML. В результате качественно отрисованную схему BPMN можно легко преобразовать в полноценную программу и наладить реальную автоматизацию предприятия или проекта. Эдакий No-code-подход.

Базовыми элементами BPMN-схем являются:

События (Events)
Активности или задачи (Activity)
Шлюзы или логические операторы (Gateway)
Потоки (Flow)
Дорожки и пулы (Swimlane, дословно «дорожки для плавания»).

У каждого типа элементов есть свои разновидности и подвиды. Например, события могут быть стартовыми, конечными или промежуточными. Стартовые события могут быть прерываемыми (по таймеру, по сообщению, по условию запуска, по определённому сигналу и т.п.), непрерываемыми, с множественными запусками и пр.

Активности могут включать подпроцессы, сделки, звонки и т.п. Шлюзы работают примерно как логические операторы: И, ИЛИ (исключающее и включающее), НЕ. А могут использовать события для управления. Они не принимают никаких решений, а только направляют поток.

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

Как проектировать бизнес-процессы на BPMN-схемах

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

Внутри пула создаются дорожки (по необходимости) и далее – остальные мелкие элементы.

Любой процесс имеет начало и конец. За эти состояния отвечают специальные типы элементов Events (круги).

От начала к концу должны проходить линии потоков (Flow). Это обычные стрелки.

На пути потоков должны использоваться шлюзы (Gateway, ромбы) и активности/задачи (Activity, прямоугольники со скруглёнными углами).

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

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

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

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

Чтобы составить свою BPMN-схему, нужно:

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

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

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

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

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

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

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

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

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

Ручкой и бумагой (схему можно нарисовать от руки).
Любым графическим редактором (как векторным, так и растровым, но желательно векторным, чтобы схему можно было масштабировать до любого размера).
Мастером делегирования задач в Projecto. Любая задача и связанные с ней подзадачи автоматически отображаются на специальной графической схеме – в виде сетевой диаграммы. Да, здесь не будет обозначений, присущих BPMN, но легко можно отследить все связи и ответственных лиц.