Картирование процессов решает проблему, при которой обсуждение улучшений начинается сразу с решения, минуя понимание текущего состояния: команда предлагает «давайте автоматизируем этот шаг» до того, как кто-то нарисовал сам процесс и увидел, что реально происходит на каждом этапе. Визуальная карта процесса — блок-схема с шагами, решениями и ответственными — переводит процесс из набора устных описаний в единый артефакт, который все участники видят и понимают одинаково.
Пока процесс не нарисован, каждый участник представляет его немного по-своему — а значит, обсуждение улучшений идёт про разные процессы одновременно.
Классический пример того, что вскрывает именно нарисованная карта процесса, — кейс IBM Credit Corporation, дочерней компании IBM, финансировавшей покупку компьютеров и услуг клиентами IBM (описан Майклом Хаммером и Джеймсом Чампи в книге «Reengineering the Corporation», 1993). Оформление одной заявки на кредит в среднем занимало 6 дней, а в сложных случаях — до двух недель; при этом заявку последовательно передавали через 4-8 разных специалистов (проверка кредитоспособности, корректировка типового контракта, расчёт ставки и т. д.). Когда менеджеры прошли с одной заявкой лично через все этапы, засекая время на каждом, оказалось, что реальная работа над заявкой занимает около 90 минут — почти всё остальное время заявка просто лежала в очереди на столе у следующего специалиста. Именно физическое прослеживание процесса шаг за шагом — то есть его картирование — показало, где на самом деле возникает задержка: не в сложности отдельных операций, а в передачах между специалистами. После замены цепочки узких специалистов одним универсальным «структуратором сделки», ведущим заявку от начала до конца, время обработки сократилось с 6 дней до 4 часов, а без увеличения штата компания стала обрабатывать в 100 раз больший объём сделок.
Происхождение и исследовательская база
Картирование процессов — базовая практика процессного управления (Business Process Management), использующая графические нотации (блок-схемы, BPMN, диаграммы дорожек) для визуального представления последовательности шагов, решений и участников бизнес-процесса.
Ключевые идеи и принципы
Принцип: Карта строится по реальному процессу, а не по идеальному представлению
Как и в подходе As-Is, карта должна отражать процесс таким, каким он реально выполняется, включая исключения и обходные пути, а не идеализированную версию из регламента — иначе карта не отражает реальность и последующий анализ строится на неверных данных.
Принцип: Единая нотация с чёткими обозначениями шагов, решений и участников
Использование стандартной нотации (начало/конец, действие, точка решения, роль исполнителя) делает карту понятной для любого, кто с ней знакомится, без необходимости устных пояснений автора.
Принцип: Уровень детализации соответствует цели картирования
Карта высокого уровня (крупные этапы) полезна для общего понимания процесса, а детальная карта (отдельные действия) нужна для точечного анализа конкретного участка — избыточная детализация на уровне общего понимания перегружает карту и мешает её читать.
Принцип: Карта фиксируется в письменном виде и доступна всем участникам процесса
Карта, существующая только в голове одного сотрудника или на фотографии со встречи, не выполняет свою функцию единого понимания — она должна быть зафиксирована в доступном формате и актуализироваться со временем.
Ограничения, слепые зоны и критика
Картирование процесса само по себе не улучшает процесс — это диагностический шаг перед оптимизацией, и организации иногда останавливаются на составлении красивой карты без последующих реальных изменений. Составление детальной карты для сложных процессов с множеством исключений и вариаций отнимает значительное время, и при слишком дробной детализации карта становится нечитаемой. Наконец, карта отражает состояние процесса на момент составления и без регулярного обновления быстро устаревает по мере изменения реальной практики.
Типовые ошибки
Ошибка 1: Карта строится по идеализированному представлению процесса, а не по тому, как он реально выполняется.
Последующий анализ и улучшения строятся на неверных данных, не соответствующих реальности.
Как избежать: Строить карту через прямое наблюдение и интервью с реальными исполнителями процесса.
Ошибка 2: Карта составлена без чёткого разделения на шаги, точки решения и ответственных.
Карта плохо читается и не помогает однозначно понять логику процесса.
Как избежать: Использовать единую понятную нотацию с явным обозначением шагов, решений и ролей исполнителей.
Ошибка 3: Уровень детализации карты не соответствует цели картирования.
Карта либо слишком общая для точечного анализа, либо перегружена деталями для общего понимания.
Как избежать: Выбирать уровень детализации в зависимости от конкретной цели — общее понимание или детальный анализ участка.
Ошибка 4: Составление карты становится конечной целью без последующего анализа и улучшений.
Значительные трудозатраты на картирование не приводят к реальным изменениям процесса.
Как избежать: Использовать карту как основу для дальнейшего анализа узких мест, потерь и проектирования улучшений.
Ошибка 5: Карта составлена один раз и не обновляется при изменении процесса.
Карта постепенно перестаёт отражать реальную практику выполнения процесса.
Как избежать: Регулярно пересматривать и актуализировать карту при значимых изменениях процесса.
Главное, что нужно знать
Картирование процессов переводит устные и разрозненные представления о процессе в единый визуальный артефакт с чёткой нотацией шагов, решений и ответственных, отражающий реальную, а не идеализированную практику выполнения. Карта — диагностический инструмент перед оптимизацией, а не самоцель, и должна регулярно обновляться, чтобы оставаться актуальной.
План внедрения
Неделя 1: выбрать ключевой процесс и определить цель картирования — общее понимание или детальный анализ.
Неделя 2: провести наблюдение и интервью с исполнителями, составить черновик карты.
Неделя 3: согласовать карту с участниками процесса и зафиксировать в едином доступном формате.
Неделя 4: использовать карту как основу для анализа узких мест и потерь.
Далее: регулярно пересматривать и обновлять карту при изменении процесса.
Как реализовать этот план с помощью фрейма «Картирование процессов» в OrgDevTools
Фрейм строит процесс как растущую цепочку карточек-шагов, соединённых стрелками: у каждого шага — название, тип (Начало/Действие/Решение/Конец, с разной формой и цветом карточки), ответственный, а на детальном уровне — заметка про исключение или обходной путь. Переключатель «Общее понимание / Детальный анализ» меняет, показываются ли эти заметки. Вердикт вычисляется по стадиям: нет ни одного шага → предложение начать с «Начала»; нет явного начала или конца → процесс не замкнут, границы размыты; есть шаги без ответственного → красное предупреждение с их числом; всё заполнено → зелёный вердикт.
Неделя 1-2 — заполнение цепочки шагов с явным типом и ответственным на каждом. Обязательное поле «Ответственный» на каждой карточке — прямая структурная защита от главного урока кейса IBM Credit: реальная задержка процесса чаще всего прячется не внутри отдельного шага, а на стыке между шагами и их владельцами, и фрейм требует явно зафиксировать, кто отвечает за каждый шаг, а не оставить это подразумеваемым.
Неделя 2-3 — переключатель уровня детализации и поле «Исключение / обходной путь» на детальном уровне. Прямая структурная защита от ошибки 1 (карта строится по идеализированному представлению): поле для исключений заложено в саму форму, а не остаётся вне карты.
Неделя 3-4 — вердикт «процесс не замкнут» при отсутствии явного начала или конца. Структурная защита от ошибки 2 (карта без чёткого разделения на шаги и роли): фрейм физически требует типизировать каждый шаг единой нотацией, а не оставлять карту произвольным текстом.
