Карта процесса: шаги, роли и ошибки, из-за которых она не работает
Карту процесса обычно рисуют, когда что-то уже сломалось: заявка потерялась, клиент ушёл, отчёт не сошёлся. Рисуют в спешке, показывают руководителю и убирают в папку, потому что «и так всё понятно». Через полгода карту достают, чтобы на её основе что-то автоматизировать, и видят, что половина шагов уже не так. Ниже — как описать работу так, чтобы схема пережила эти полгода.
Коротко
- Рабочая карта отвечает на четыре вопроса: кто делает, что именно, что получает на входе и что отдаёт дальше. Пять обязательных элементов — шаг, роль, вход и выход, точки решения с условиями и метрика (срок, объём или стоимость).
- Обзор 105 исследований карт процессов (Antonacci et al., BMC Health Services Research, 2021): карту подтверждали у ключевых участников в 48% работ, исполнителей процесса вовлекали в 15%, а к действиям после карты переходили в 42% работ.
- Справочная модель SAP (Mendling et al., 2008): из 604 схем процессов минимум 34 (5,6%) содержат формальные ошибки логики, причём ветки с ошибками крупнее среднего — в Asset accounting 7 из 43 схем (16,3%). Это нижняя оценка: проверялась только связность схем.
- Правила 7PMG (Mendling, Reijers, van der Aalst, 2010): в реальных проектах документирования доля ошибочных моделей — 10–20%, а у схем крупнее 50 элементов вероятность ошибки превышает 50%, поэтому большие карты режут на части.
- Приоритеты правил расставил 21 профессиональный модельер со средним опытом пять лет: первое место у структурированности схемы (суммарный ранг 58,5), последнее — у отказа от OR-развилок (104).
Зачем карта, если работа и так идёт
Процесс без карты существует — он живёт в головах. Пока один человек точно знает, как «на самом деле» согласуют счёт или срочно отгружают товар, всё работает. Как только он уходит в отпуск, работа встаёт: остальные знают свою часть, но не видят передач между шагами. Карта выносит договорённость из головы в документ, по которому можно спорить и который можно улучшать.
Сбои качества и безопасности чаще связаны с системами и процессами, чем с ошибками отдельных людей.
Вывод прикладной: если проблема повторяется у разных людей и в разных сменах, дело в процессе, а не в исполнителе. И оговорка — карта не регламент: она описывает, как работают сейчас, а не как предписано. Как только эти два документа смешивают, люди начинают рисовать «правильную» схему вместо настоящей.
Как строят карту: шесть шагов и две остановки
Порядок ниже — наша рабочая последовательность. Она не требует курсов и покупки систем: хватает одного человека, который ведёт работу, и двух-трёх исполнителей с часом свободного времени.
Две остановки важнее остальных шагов. Наблюдение: сотрудник рассказывает, как надо, и только на рабочем месте видно, что между двумя шагами он открывает таблицу и переносит данные руками. Проверка: пока карту не прочитали те, кто делает работу каждый день, в ней останутся пропущенными «очевидные» шаги.
Пять элементов рабочей карты
Карта без ролей — рисунок, карта без метрик — плакат. Минимальный набор, который делает схему рабочим документом, такой.
- Шаг: действие в формате «глагол + объект» — «согласовать счёт», а не «согласование счёта». Требование однозначных названий в наборе правил 7PMG опирается на эксперименты, а не на вкус.
- Роль, а не фамилия: за шаг отвечает должность или подразделение. Фамилия стареет быстрее схемы.
- Вход и выход: что нужно, чтобы шаг начался, и что получается на выходе. Передача «в никуда» — первый признак, что где-то переделывают чужую работу.
- Точки решения: где путь разветвляется и по какому условию. Без подписанного проверяемого условия автоматизировать развилку нельзя.
- Метрика шага: срок, объём или стоимость. Без цифр спор о приоритетах идёт о впечатлениях.
Нотация простыми словами: что выбрать, если учить BPMN некогда
Карта не обязана быть в BPMN. Нотация — это язык, на котором договорились рисовать, и для внутреннего разбора хватает пяти значков: прямоугольник (шаг), ромб (развилка), стрелка (передача), дорожка (роль) и подпись с данными.
Формальный стандарт BPMN 2.0 принят в декабре 2010 года и описывает нотацию, которую можно перевести в исполняемые правила, — это нужно, когда схему выполняет система или её передают подрядчику. Для регламента сотрудникам хватит таблицы «шаг / кто / что на входе / результат / срок». Три правила важнее названия нотации: одна карта — один процесс, одно начало и один конец, схема крупнее экрана делится на уровни.
Пять ошибок, из-за которых карта не работает
Обзор 105 опубликованных работ по картированию процессов в медицине (Antonacci et al., 2021, журнал BMC Health Services Research) показывает не идеал, а практику. Медицина выбрана не случайно: процессы там сложные и распределены между службами — условия близки к снабжению, логистике и сервису.
- Карту рисуют без исполнителей. Разные группы участников собирали схему только в 45% работ, а исполнителей процесса вовлекали в 15%. Отсюда берутся шаги, которых нет, и пропущенные операции.
- Карту не проверяют на точность: подтверждение ключевых участников или внешних экспертов описано лишь в 48% работ. Половина схем не проверена — спорить потом приходится о том, чья версия вернее.
- Работа останавливается на карте: действия после разбора описаны в 42% работ, остальные проблемы нашли, но к изменениям не перешли.
- На схеме нет цифр: задержки и поток данных наносили 78% работ, а в программе рисовали только 19% — остальные карты остались на бумаге и в записях.
- У карты нет владельца и даты пересмотра (в обзоре это не измерялось, здесь наш ориентир из практики): ответственный и пересмотр раз в полгода.
Что говорят исследования о крупных схемах
Есть вторая причина, по которой карта не доживает до автоматизации: ошибки в самой схеме. Публичный пример — справочная модель SAP: почти 10 000 моделей, из которых 604 оказались настоящими схемами процессов. Минимум 34 из них содержат ошибки логики — тупики и недостижимые ветви, то есть 5,6% от проверенных (Mendling et al., 2008).
Оценка эта нижняя: авторы искали только ошибки связности, а не расхождение схемы с реальной работой. Ветки, где ошибок больше 10%, оказались крупнее среднего — в Asset accounting 7 ошибочных схем из 43. По пяти показателям сложности модель предсказывает наличие ошибки с точностью 95,2%.
Набор правил 7PMG сводит наблюдения в семь пунктов: меньше элементов, меньше связей на элемент, одно начало и один конец, структурированность, отказ от OR-развилок, названия «глагол + объект» и деление схем крупнее 50 элементов. Приоритеты расставили 21 модельер с опытом в среднем пять лет: на первом месте структурированность (суммарный ранг 58,5), на последнем — отказ от OR-развилок (104). Проще: сначала выравнивайте структуру, а число развилок сокращайте в крайних случаях.
Роли: кто рисует карту и кто её подтверждает
Частая причина провала — не метод, а роли: карту делает один человек, а подтвердить её некому. Ниже рабочее распределение из наших проектов.
| Этап | Кто делает | Что остаётся | Частая ошибка |
|---|---|---|---|
| Границы | Владелец процесса и руководитель | Фраза «от … до …» и список того, что в процесс не входит | Границы «на всё сразу» |
| Сбор фактов | Исполнители, наблюдение на месте | Черновик шагов, передач и фактических сроков | Опрос только руководителя |
| Схема | Тот, кто ведёт работу | Один файл-источник, из которого делаются копии | Три версии у трёх людей |
| Подтверждение | Исполнители и владелец процесса | Пометка «сходится» с датой и списком спорных мест | Согласие «в целом нормально» |
| Метрики и пересмотр | Владелец процесса | Сроки на шагах, ответственный, дата пересмотра | Карта без даты |
Как устроены такие разборы в проектах и что остаётся заказчику, описано в разделе подхода; примеры процессов, где карта сразу шла под автоматизацию, — в кейсах.
Как проверить карту перед автоматизацией
Проверка занимает час-два и экономит недели разработки: возьмите последний реальный случай и проведите его по карте, отмечая расхождения.
- У каждого шага есть роль и результат.
- На каждой развилке подписано проверяемое условие: число, дата, статус, а не «если ситуация сложная».
- Одно начало и один конец, нет стрелок в пустоту и ветвей, которые никуда не ведут.
- Схема помещается на экран или разбита на уровни.
- У ключевых шагов стоят цифры: сколько раз в неделю выполняется и сколько минут занимает.
- Есть владелец карты, дата пересмотра и список известных исключений.
- Нетиповые случаи описаны отдельно: наш ориентир для старта — 70–80% типовых.
Порядок действий и что дальше
Итог короткий: определить границы одного процесса, разобрать реальный случай, посмотреть работу на месте, собрать схему с ролями, дать её прочитать исполнителям, добавить сроки и объём, назначить владельца с датой пересмотра. Дальше на карте видно, что автоматизировать первым: повторяющиеся операции с цифровым следом — как в материале про выбор первого процесса. Если карта показала, что заявки теряются на передачах, посмотрите разбор причин потерь и варианты связки почты, CRM и мессенджеров.
Чего подход не обещает — эффекта от самой схемы. Карта ничего не улучшает: она делает работу видимой для разговора, в котором появляются решения. Ускорение начинается, когда команда согласилась, что на схеме описана её работа, и взяла на себя договорённости по срокам и ролям.
Соберём карту вашего процесса и покажем, что в нём можно автоматизировать первым.
Получить диагностикуИсточники
- Antonacci G. et al. — Process mapping in healthcare: a systematic review (BMC Health Services Research, 14.04.2021) — систематический обзор по PRISMA (регистрация PROSPERO CRD42017082140), в анализ вошли 105 эмпирических работ на английском языке; 86% опубликованы в 2010 году или позже, 65% выполнены в США и Великобритании; 32% работ — стационары, 68% — проекты улучшения процессов; ни одна работа не выполнила все 10 критериев качества, только 7% работ выполнили 8 или 9 критериев, чаще всего 5–6 из 10; исполнителей процесса (в медицине — пациентов и пользователей услуг) вовлекали в 15% работ, обучение методике описано в 15%, карты генерировали несколько групп участников в 45%, рисовали схему в программе в 19%, наносили задержки и поток данных в 78%, подтверждали карту у участников или экспертов в 48%, действия после карты описаны в 42%; авторы предупреждают, что данные взяты из публикаций и подвержены bias отбора и публикации, а язык моделирования в работах почти не указывался
- Mendling J., Verbeek H.M.W., van Dongen B.F., van der Aalst W.M.P., Neumann G. — Detection and prediction of errors in EPCs of the SAP reference model (Data & Knowledge Engineering, 64(1), 2008, cc. 312–329; авторская копия PDF) — в справочной модели SAP 9 844 модели, из них 604 схемы процессов с начальным событием и функцией; при проверке на связность минимум 34 схемы содержат ошибки — 5,6% от 604 (авторы называют это нижней границей: проверялись только формальные ошибки потока управления, соответствие реальным процессам не проверялось); ветки с долей ошибок выше 10% в среднем крупнее: Asset accounting — 43 схемы, 7 с ошибками (16,3%), Real estate management — 16,7%, Enterprise controlling — 13,6%; логистическая регрессия подтвердила, что сложность (число событий, функций, связей, развилок) значимо повышает вероятность ошибки, точность предсказания по пяти коэффициентам — 95,2%
- Mendling J., Reijers H.A., van der Aalst W.M.P. — Seven Process Modeling Guidelines (7PMG), Information and Software Technology, 52(2), 2010, cc. 127–136 (авторская копия PDF) — семь правил моделирования процессов, выведенных из эмпирических работ авторского коллектива: меньше элементов, меньше связей на элемент, одно начало и один конец, структурированность, отказ от OR-развилок, названия по схеме «глагол + объект», деление моделей крупнее 50 элементов; в реальных проектах документирования доля ошибочных моделей — 10–20%; у моделей крупнее 50 элементов вероятность ошибки превышает 50%; приоритеты правил расставил 21 профессиональный модельер (7 из берлинского сообщества BPM-Offensive и 14 из практики крупной консалтинговой фирмы в Нидерландах, средний опыт 5 лет и более 50 схем), суммарный ранг: структурированность — 58,5 (первое место), отказ от OR — 104 (последнее); авторы отмечают, что приоритет опирается на небольшую выборку и обсуждается дальше
- OMG — Business Process Model and Notation (BPMN), версия 2.0 (декабрь 2010) — официальная спецификация нотации BPMN 2.0: нотация задумана и для описания процессов участниками работы, и достаточно строгой, чтобы схему можно было перевести в исполняемые компоненты; актуальная версия — 2.0.1, спецификация 2.0 помечена как заменённая, но остаётся базовым публичным стандартом и цитируется как де-факто стандарт описания процессов