Как построить схему бизнес-процесса: пошаговая инструкция

Автоматизация с помощью BPM-технологий по данным Forrester даёт 30–50% экономии времени на рутинных операциях, 15–30% — на сложных интеллектуальных задачах. Но до формализации и автоматизации, необходимо составить детализированную схему (диаграмму) бизнес-процесса. На первый взгляд, это может показаться простым делом. Однако не нужно забывать, что диаграммы — это не только последовательность действий, но и все те сопутствующие документы, сотрудники, ресурсы, которые являются частью бизнес-процесса.

Как составляются блок-схемы бизнес-процесса и о чём нужно помнить при их построении?

Какие задачи решают схемы бизнес-процессов?

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

Основные символы диаграмм Гилбрета-ASME

В 1950-х гг. инженеры General Electric создали диаграммы, которые быстро стали стандартом графического описания процессов, в 1980-х гг. с появлением методологий Всеобщего управления качеством и «Шесть сигм» построение схем стало частью программ улучшения.

Сегодня такая визуализация превратилась в стандартную практику, где диаграммы — практический инструмент анализа, автоматизации, оптимизации, который решает следующие задачи:

Задача	Конкретный результат
Анализ текущей деятельности	Визуализация взаимосвязей между отделами, выявление дублирования функций
Унификация рабочих процедур	Фиксация единых правил в чётких регламентах выполнения операций
Выявление точек оптимизации	Обнаружение и устранение «узких мест»
Повышение качества операций	Снижение ошибок за счёт стандартизации, внедрения контрольных точек
Формирование основы для автоматизации	Перевод словесных описаний рабочих операций в данные для внедрения BPM-систем
Управление изменениями	Моделирование вариантов реорганизации

Для описания бизнес-процессов используются специальные языки визуального моделирования — графические нотации. В Comindware Platform применяется нотация BPMN 2.0, которая помогает детально описывать процедуры любой сложности, понятна аналитикам и ИТ-специалистам.

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

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

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

Этап 1. Определение и ограничение бизнес-процесса

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

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

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

Этап 2. Задание точек начала и окончания, основных блоков

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

• Регистрация входящей заявки.
• Презентация клиенту продукта.
• Оформление конкретной заявки.
• Производство продукта (или поиск его на складе)/
• Отправка клиенту.

Этап 3. Детализация схемы бизнес-процесса

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

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

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

Пример схемы бизнес-процесса «От заявки до закупки», созданной в Comindware Platform

Бизнес-процессы имеют три типа путей протекания рабочего процесса: базовый (он же стандартный или «счастливый»), альтернативные и пути исключений. Базовый путь есть всегда и он только один. Обычно имеется один или несколько альтернативных путей и один или несколько путей исключений. Джеймс Проктор, управляющий директор Inteq Group, Inc. и автор книги «Mastering Business Chaos»

Этап 4. Задание ролей участников процесса, этапов обработки документов, баз данных

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

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

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

Назначение исполнителей для пользовательской задачи в Comindware Platform

Этап 5. Проверка схемы описания бизнес-процесса

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

 

Подбираете инструменты для автоматизации рабочих процессов? Запросите демонстрацию функционала Comindware Platform.

Заказать демо

 

Типичные ошибки при построении диаграмм и как их избежать

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

Ошибка	Как проявляется	Как избежать
Моделирование «идеального» процесса вместо реального	Схема бизнес-процесса организации отражает «как должно быть», а не реальные действия сотрудников	Проводить интервью с участниками процесса, фиксировать неформальные согласования
Несоответствующий уровень детализации	Либо чрезмерная проработка с избыточным количеством шагов, либо излишняя абстракция без раскрытия сути процесса	Углублять детализацию только в ключевых или проблемных точках
Неучтённые исключения	Отсутствие описания действий при сбоях или отклонениях	Для каждого этапа анализировать возможные сбои
Неопределённость ролей и зон ответственности	Неясно, кто несёт ответственность за выполнение этапа	Указывать конкретные должности или роли в ответственных
Игнорирование документооборота	Не указаны документы и данные, используемые или создаваемые на этапах	Для каждого этапа фиксировать входные и выходные документы, обозначать используемые системы и базы данных
Несоблюдение единой нотации	Использование элементов разных нотаций	Использовать элементы только одной нотации
Изоляция процесса от смежных операций	Процесс не интегрирован в общую цепочку операций организации	Проверять стыковку со смежными процессами, фиксировать межпроцессные события
Перегруженность визуализации	Попытка отобразить все процессы на одном уровне	Разделять схемы по уровням, проводить декомпозицию подпроцессов на отдельных диаграммах
Отсутствие процедуры валидации	Схема утверждается без тестирования и проверки со стороны владельца процесса	Проводить тестирование на реальных сценариях с участниками процесса

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

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

1. Границы процесса определены
   • Обозначены точки входа и выхода (начало и конец).
   • Определены все участники (роли/отделы).


2. Процесс визуализирован
   • Схема составлена в единой нотации.
   • На ней отражены все этапы (блоки).
   • Указаны все возможные ветвления.


3. Детализация
   • Каждый этап содержит конкретные действия.
   • Для каждого действия определены:
     • исполнитель,
     • входные, выходные данные.


4. Потоки данных проработаны
   • Указаны все документы/данные на каждом этапе.
   • Определены форматы данных (Excel, PDF и т.д.).
   • Указаны системы-источники данных.


5. Исключения и ошибки учтены
   • На диаграмме отражены альтернативные сценарии.
   • Прописаны сценарии при ошибках/отказах.


6. Валидация проведена
   • Схема проверена на реальном процессе.
   • Получена обратная связь от участников.
   • Выявлены, устранены противоречия.


7. Готовность к автоматизации
   • Схема стабильна (не меняется ежедневно).
   • Все этапы формализованы.

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

Используя решения на базе low-code платформы Comindware Platform для создания бизнес-процессов и последующей автоматизации, вы сможете вносить большинство изменений в работу системы без помощи ИТ-специалистов, создавать схемы бизнес-процессов онлайн через браузер в нотации BPMN 2.0, а также выбирать тот набор функций и возможностей, которые нужны вашей компании на данном этапе её развития.

 

Узнайте больше о возможностях Comindware Platform в построении диаграмм процессов и их исполнении, запросив персональную демонстрацию продукта.

Заказать демо