Не обязательно быть программистом, чтобы спроектировать бизнес-процессы на предприятии… Или все-таки нужно? На самом деле всё не так просто, как может показаться опытным руководителям. Если вы хотите создать с нуля или оптимизировать имеющиеся рабочие процессы, потребуется качественная детализация всех действий сотрудников – в формате «от и до», с учётом потенциальных проблем и рисков, а также взаимодействия с другими лицами (будь то клиенты или соседние отделы и службы). Тут волей-неволей станешь немного программистом.
В этом материале расскажем, как и с помощью каких инструментов можно моделировать бизнес-процессы в своих проектах и компаниях.
Сначала – о бизнес-процессах и о том, зачем их нужно моделировать
Любое простое действие, зависящее только от нашей воли, можно выполнить практически мгновенно. Это большая часть всех наших бытовых задач: встать, одеться, пойти на работу, приготовить ужин…. С одной стороны, они типовые, но с другой — вы вольны выполнять эти задачи так, как посчитаете нужным.
Но если собрается группа людей, которые должны вместе делать одно дело, возникает настоящий бизнес-процесс, поскольку необходимо предусмотреть много нюансов и синхронизировать всех между собой так, чтобы никто никому не мешал и каждый мог завершить своё действие.
Банальный пример – общий подъём в армии: нужно определиться, во сколько вставать, сколько времени одеваться и тратить на туалет, куда идти на зарядку и при каких условиях (погода, ветер, наличие ограничений от дежурного по части), кто идёт, а кто остаётся, у кого освобождение, кто контролирует личный состав…
Когда бизнес-процесс отлажен, он работает на автопилоте. Участие вышестоящего руководителя не требуется, поэтому он может потратить своё время на более полезные мероприятия, например, на разработку планов (про стратегическое планирование).
Бизнес-процессы – это любые повторяющиеся действия сотрудников, относящиеся к достижению или созданию ценного конечного продукта проекта. И так как они зачастую связаны между собой, нарушение одного или нескольких действий может приводить к ухудшению качества продукта или к полной остановке его производства.
Если бизнес-процесс хорошо детализирован, он похож на программу с описанием шагов и условий наступления тех или иных событий. Почти всегда бизнес-процессы визуализируются в виде блок-схем (например, в виде диаграмм связей, графов). Они ещё чем-то напоминают 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, но легко можно отследить все связи и ответственных лиц.