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

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

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

Что такое карта бизнес-процессов

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

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

Есть и вторая путаница, между картой процессов и моделью процесса. Карта даёт обзор: какие процессы вообще есть в компании и как они питают друг друга. Модель берёт один процесс и разбирает его по шагам. Собственнику нужны оба уровня, и дальше будет видно, как они складываются в одну иерархию.

Главное свойство хорошей карты в том, что она честная. Нарисовать процесс, каким он должен быть в идеальном мире, легко и бесполезно. Польза появляется, когда на схеме видны обходные пути, ручные переносы данных из таблицы в таблицу и шаг «спросите у главбуха, она знает».

Зачем собственнику бизнеса карта процессов

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

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

Работу можно передавать. Новый сотрудник смотрит на схему и понимает, откуда к нему приходит задача и куда он её отдаёт. Без карты знания передаются из уст в уста и теряются по дороге. Вместе с регламентами схема заменяет вечное «спросите у того, кто давно работает».

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

Появляется общий язык. Продажи уверены, что заказ уходит в производство в тот же день, производство уверено, что продажи тянут с документами. Обе стороны правы про свой участок и не видят целого. Карта кладёт обе версии рядом, и спор о мнениях превращается в разговор о факте.

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

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

Уровни детализации: от карты компании до отдельной операции

Главная ловушка в работе с процессами в том, чтобы сразу нырнуть в детали. Человек начинает рисовать, какие кнопки менеджер нажимает в CRM, и к вечеру тонет в подробностях, так и не увидев процесс целиком. Двигаться надо сверху вниз, от общего к частному, и уровней здесь три или четыре.

Уровень 0. Карта верхнего уровня. Весь бизнес на одном листе, крупными блоками вроде маркетинга, продаж, закупок, производства, доставки, финансов и найма. Стрелки показывают, как блоки питают друг друга. Задача уровня в том, чтобы увидеть компанию целиком и честно ответить себе, какие процессы в ней вообще есть. Времени на такую карту уходит немного, а пользы от неё непропорционально много.

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

Уровень 2. Подпроцессы и операции. Здесь появляется конкретика. Кто выполняет шаг, в какой системе, по какому правилу, что на входе и что на выходе. Этот уровень и нужен для стандартизации и автоматизации.

Уровень 3. Инструкции. Пошаговое «нажми сюда, заполни это». Схемой его уже не рисуют, его пишут текстом или записывают на видео с экрана. Нужен там, где ошибка стоит дорого, например в бухгалтерии или при отгрузке.

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

Нотации: BPMN и простые схемы

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

Простая блок-схема

Хватает трёх-четырёх типов фигур, и для большинства задач малого бизнеса этого достаточно.

• Прямоугольник обозначает действие или шаг («выставить счёт»).
• Ромб ставят на развилке, где принимается решение («клиент согласовал?»).
• Овалом или скруглённым прямоугольником отмечают начало и конец процесса.
• Стрелка показывает направление движения.

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

К фигурам добавляют дорожки (swimlanes): горизонтальные или вертикальные полосы, по одной на каждую роль. Шаг попадает в дорожку того, кто его выполняет. По дорожкам сразу видно, кто перегружен и где работа скачет между отделами туда и обратно.

Простая схема рисуется в чём угодно, в Miro, Figma, draw.io или маркером на доске. Её поймёт любой сотрудник без обучения, и для старта я советую именно её.

BPMN

BPMN (Business Process Model and Notation) это международный стандарт моделирования процессов с богатым набором элементов, где разведены типы событий, шлюзов, задач и сообщений между участниками. Стандарт точен настолько, что по грамотной модели процесс можно частично автоматизировать в BPM-системе почти без переписывания.

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

Разумный компромисс в том, чтобы взять из BPMN базовый словарь (задача, шлюз, событие, пул и дорожки) и не трогать экзотику. Так получается стандартный, узнаваемый язык без перегруза. Если впереди внедрение BPM-платформы или работа с ИТ-подрядчиком, осваивать BPMN стоит. Если цель навести порядок в голове и в команде, начинайте с простых блок-схем и усложняйте по мере надобности.

Моё мнение прямое: с BPMN начинают те, кто уже нарисовал хотя бы одну схему. Соблазн сначала выучить «правильный» стандарт заканчивается тем, что работа над процессами откладывается на полгода, потому что «сначала надо разобраться в нотации». Кривая блок-схема, нарисованная сегодня, принесёт больше пользы, чем идеальный BPMN, которого нет.

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

Дальше конкретный порядок действий. Он работает и для собственника, который садится за схему один, и для команды с ведущим.

Шаг 1. Составьте список процессов. Выпишите всё, что компания делает регулярно, чтобы зарабатывать и обслуживать клиента. Один из критериев отбора простой: всё, что в компании делается два раза и больше, уже считается процессом. Пока без глубины, просто перечень от привлечения клиентов до найма и финансов. Это заготовка для карты верхнего уровня.

Шаг 2. Выберите один процесс для детальной проработки. Описывать всё сразу бессмысленно, выгорите на третьем. Возьмите тот, что болит сильнее прочих, где срываются сроки, теряются заявки или жалуются клиенты, и работайте с одним процессом за подход.

На этом шаге легко ошибиться. На трекинге собственник небольшой торговой компании сам поставил себе задачу «описать бизнес-процессы». Я спросил, что он под этим имеет в виду и зачем ему это нужно. Выяснилось, что подчинённые его плохо понимают, и ему кажется, что бумага с правилами это снимет. Я предложил взять процесс, который хромает и в котором он сам до конца не разбирается, потому что описывать понятное незачем: «А что тогда вы описать хотите?» И сразу предупредил, что правила, за исполнением которых никто не следит, так и остаются бумагой. Процесс он на той встрече не выбрал, ушёл думать, начинать ли с оформления возвратов.

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

Шаг 3. Определите границы. Где процесс начинается и где заканчивается. У продаж старт «пришла заявка», финиш «деньги на счету и заказ передан в работу». Чёткие границы не дают схеме расползтись на весь бизнес.

Шаг 4. Соберите участников и восстановите реальный ход. Позовите людей, которые выполняют процесс своими руками. Те, кто только думает, что знает, как он идёт, пусть послушают. Каждый рассказывает свой кусок, начиная с того, что получает на входе, и заканчивая тем, кому отдаёт результат. Записывайте на стикеры или прямо в схему. Здесь всплывают обходные пути, дубли и дыры, о которых собственник не подозревал.

Шаг 5. Нарисуйте схему «как есть». Разложите шаги в последовательность, добавьте развилки и дорожки по ролям. Ничего не приукрашивайте. Если менеджер вручную копирует данные из почты в таблицу, а потом в CRM, так и рисуйте. Схема «как есть» ценнее вылизанной картинки «как надо».

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

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

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

Пример: карта процесса продаж

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

Уровень 1, цепочка этапов:

1. Приём заявки (сайт, звонок, мессенджер).
2. Квалификация: подходит ли клиент, есть ли у него бюджет и потребность.
3. Подготовка коммерческого предложения.
4. Согласование КП с клиентом.
5. Заключение договора.
6. Выставление счёта и получение оплаты.
7. Передача заказа в исполнение.

На этом уровне логика уже видна. Теперь спустимся глубже на паре узлов, где прячется больше всего потерь.

Узел «Приём заявки», уровень 2. Заявка приходит по одному из трёх каналов. Менеджер видит её или не видит, если она пришла ночью в мессенджер и утонула в чате. Данные он переносит в CRM вручную, назначает ответственного и отправляет клиенту первый ответ. Уязвимых мест здесь два: заявка из мессенджера может потеряться, а ручной перенос занимает время и рождает ошибки в контактах.

Узел «Согласование КП», уровень 2. Менеджер отправляет предложение, клиент думает, менеджер ждёт. Через сколько дней он напомнит о себе? Если правила нет, кто-то напомнит завтра, кто-то через неделю, а кто-то забудет совсем. Через такую дыру утекают тёплые сделки, и на карте она видна сразу: между шагом «отправил КП» и «получил ответ» нет ни срока, ни правила повторного касания.

Ради таких находок карту и рисуют. Пока процесс в голове, фраза «менеджеры иногда забывают перезвонить» звучит как мелочь. На схеме это провал в середине воронки, через который уходит выручка.

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

Как по карте искать узкие места

Сама по себе карта ничего не меняет, её ценность в решениях, которые она подсказывает. Когда схема готова, смотреть стоит в пять мест.

Точки ожидания. Ищите места, где работа стоит. Она ждёт согласования, ответа клиента или того единственного человека, который умеет это делать. Ожидание ничего не создаёт, но съедает срок. Проставьте на схеме время каждого шага, и станет видно, сколько заказ лежит и сколько с ним работают.

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

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

Лишние согласования. Каждый ромб «получить одобрение» тормозит движение. Часть согласований осталась с тех времён, когда бизнес был маленьким и собственник визировал каждую мелочь. По каждому спросите себя, что случится, если этот контроль убрать. Иногда ничего, кроме ускорения.

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

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

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

Карта как основа для автоматизации

Здесь связь прямая. Автоматизировать процесс, который нигде не описан, технически можно, но результат выйдет плачевным: текущий хаос застынет в системе, а деньги на внедрение уйдут.

Во-первых, карта показывает, что автоматизировать. Ручные переносы данных, типовые уведомления, документы по шаблону, назначение ответственных выглядят на схеме как повторяющиеся однотипные шаги. Они и дают быстрый эффект.

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

Наконец, схема задаёт логику для настройки. Разработчик или специалист по no-code берёт её и переносит в инструмент, и чем точнее карта, тем меньше правок и переделок на внедрении. Бесконечные согласования в духе «а как тут должно работать» схема снимает ещё до старта.

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

Типичные ошибки при составлении карты

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

Рисуют идеал вместо реальности. Схема показывает, как должно быть, и врёт о том, как есть. Найти проблемы по ней нельзя, потому что проблемы живут как раз в разрыве между идеалом и реальностью. Сначала честная схема «как есть», потом «как надо».

Сразу лезут в мелкие детали. Начинают с уровня «какую кнопку нажать» и тонут, не описав целиком ни одного процесса. Идти надо сверху вниз, от карты компании к цепочкам и уже потом к операциям.

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

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

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

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

Отдельно про учёбу вместо схемы. Однажды команда отдела продаж на трекинге взяла задачу описать процессы. К следующей встрече все посмотрели короткий курс по методологии и написали по нему рефлексию, а пробный разбор сделали только на примере найма, потому что руководителей продаж на занятии не было. Один из них сказал прямо, что прописывать смысла нет, обязанности и так все знают. Я попросил начать с одной схемы всего пути клиента, от заявки до обратной связи после услуги, и уже потом описывать каждый переход. На неделю взяли две задачи, блок-схему и один пробный регламент. А в конце я оставил им вопрос на случай, если задача снова встанет: «Почему вам выгодно, чтобы бизнес-процессы не описывались?» Пока правила не записаны, с человека меньше спрос, и эту выгоду полезно назвать вслух.

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