Карта бизнес-процесса – один из самых рабочих инструментов для того, чтобы навести порядок в операционной деятельности компании. Она показывает, кто, что и в какой последовательности делает, где возникают потери, кто несет ответственность и где процесс можно улучшить. Ниже собраны примеры карты бизнес-процесса в разных форматах – от текстовых описаний и таблиц до нотаций BPMN и Swim Lane, – которые помогут разобраться в структуре и логике этого инструмента.
В подборку вошли те варианты, с которыми чаще всего работают на практике: они охватывают разные уровни детализации, разные типы бизнеса и разные способы визуализации. Каждый пример снабжен пояснением, чтобы было понятно не только что написано, но и почему именно так.
В этой статье разобраны следующие форматы карт бизнес-процесса:
- Текстовые карты процесса
- Процесс обработки входящей заявки в отделе продаж
- Процесс найма нового сотрудника
- Процесс возврата товара в интернет-магазине
- Табличные карты процесса
- Процесс согласования договора
- Процесс выставления счета и оплаты
- Процесс технической поддержки клиентов
- Карты в формате Swim Lane (дорожки)
- Процесс обработки заказа в интернет-магазине
- Процесс закупки материалов
- Карты в нотации BPMN (упрощенные текстовые схемы)
- Процесс согласования маркетингового бюджета
- Процесс выхода нового сотрудника на работу (онбординг)
- Карты верхнего уровня (общие процессные карты)
- Операционная карта производственной компании
- Карта процессов сервисной компании
Примеры карты бизнес-процесса разных видов и форматов: основной FAQ
Что такое карта бизнес-процесса. Карта бизнес-процесса – это визуальное или структурированное текстовое описание последовательности действий, которые выполняются для достижения определенного результата. Она показывает шаги, участников, точки принятия решений, входы и выходы каждого этапа.
Зачем нужна карта процесса. Карта помогает увидеть процесс целиком, найти слабые места, распределить ответственность и договориться о едином понимании того, как должна работать та или иная операция. Без нее разные сотрудники нередко выполняют один и тот же процесс по-разному.
Основные форматы карт бизнес-процесса:
- Текстовая карта – нумерованный список шагов с указанием ответственных, входов и выходов. Подходит для простых процессов и начального описания.
- Табличная карта – таблица с колонками "Шаг", "Ответственный", "Действие", "Результат", "Срок". Удобна для регламентов и внутренних инструкций.
- Swim Lane (дорожки) – схема, в которой каждый участник процесса занимает свою "дорожку". Наглядно показывает, кто за что отвечает и как передается работа между участниками.
- BPMN – нотация для формального описания процессов с событиями, шлюзами и потоками. Используется в IT-проектах, автоматизации и системном анализе.
- Карта верхнего уровня – общая схема всех ключевых процессов компании или подразделения без детализации каждого шага. Нужна для стратегического обзора.
Где применяются карты процессов. В управлении операциями, при внедрении CRM и ERP, при разработке регламентов, при оптимизации сервиса, при аудите и сертификации (например, по ISO), при обучении новых сотрудников и при постановке задач разработчикам.
Текстовые карты бизнес-процесса
Текстовый формат – самый доступный способ зафиксировать процесс. Он не требует специального программного обеспечения и понятен любому сотруднику. Такие карты хорошо работают для несложных линейных процессов, которые нужно быстро описать и передать в команду. Главное – четко указывать, кто выполняет каждый шаг и что является его результатом.
📌 Процесс обработки входящей заявки в отделе продаж
- Сценарий: фиксация и маршрутизация входящего обращения от нового клиента
- Участники: менеджер по продажам, руководитель отдела продаж (РОП), клиент
- Задача: показать полный цикл от получения заявки до передачи в работу
Пример:
Карта процесса: обработка входящей заявки в отделе продаж
Цель процесса: обеспечить своевременную и корректную обработку каждой входящей заявки от потенциального клиента.
Шаг 1. Получение заявки
Ответственный: менеджер по продажам
Вход: заявка через сайт, звонок, email или мессенджер
Действие: зафиксировать заявку в CRM-системе в течение 15 минут с момента поступления
Выход: карточка клиента создана, статус – "Новая заявка"
Шаг 2. Первичная квалификация
Ответственный: менеджер по продажам
Вход: данные из карточки клиента
Действие: связаться с клиентом в течение 30 минут, уточнить потребность, бюджет, сроки
Выход: заявка квалифицирована (целевая / нецелевая)
Шаг 3. Маршрутизация
Ответственный: менеджер по продажам
Условие: если заявка целевая – перейти к шагу 4; если нецелевая – закрыть с фиксацией причины
Выход: заявка переведена в статус "В работе" или "Отказ"
Шаг 4. Подготовка коммерческого предложения
Ответственный: менеджер по продажам
Вход: квалифицированная потребность клиента
Действие: подготовить и согласовать КП в течение 1 рабочего дня
Выход: КП отправлено клиенту, зафиксировано в CRM
Шаг 5. Согласование и закрытие
Ответственный: менеджер по продажам, РОП (при сделках выше 200 000 ₽)
Действие: провести переговоры, получить решение клиента
Выход: договор подписан или заявка переведена в статус "Отказ" с указанием причины
Контрольные точки:
- Время первого контакта с клиентом – не более 30 минут
- Срок подготовки КП – не более 1 рабочего дня
- Все статусы фиксируются в CRM
- Почему подходит: линейный процесс с четкими ответственными и контрольными точками – классический формат для отдела продаж
- Где работает лучше всего: в компаниях с небольшим количеством участников и стандартным циклом сделки
- Что важно не испортить: не пропускать условие маршрутизации – именно оно отделяет целевые заявки от нецелевых и исключает потерю времени
📌 Процесс найма нового сотрудника
- Сценарий: открытие вакансии и закрытие позиции от заявки руководителя до выхода кандидата
- Участники: руководитель подразделения, HR-менеджер, кандидат, служба безопасности (при наличии)
- Задача: зафиксировать зоны ответственности и не допустить выпадения шагов
Пример:
Карта процесса: найм нового сотрудника
Шаг 1. Открытие вакансии
Ответственный: руководитель подразделения
Действие: заполнить заявку на подбор с описанием требований, условий и срока закрытия
Выход: заявка на подбор передана в HR
Шаг 2. Поиск кандидатов
Ответственный: HR-менеджер
Действие: разместить вакансию на hh.ru и внутренних ресурсах, запустить поиск по базе
Срок: не позднее 2 рабочих дней с момента получения заявки
Выход: список первичных кандидатов
Шаг 3. Первичный скрининг
Ответственный: HR-менеджер
Действие: провести телефонное интервью, проверить соответствие базовым требованиям
Выход: шорт-лист кандидатов для собеседования с руководителем
Шаг 4. Собеседование с руководителем
Ответственный: руководитель подразделения, HR-менеджер
Действие: провести интервью, оценить профессиональные компетенции
Выход: решение – приглашение на следующий этап или отказ
Шаг 5. Проверка и оффер
Ответственный: HR-менеджер
Действие: направить оффер, согласовать условия, зафиксировать дату выхода
Выход: оффер принят, дата выхода согласована
Шаг 6. Подготовка к выходу
Ответственный: HR-менеджер, IT-служба, руководитель
Действие: подготовить рабочее место, доступы, план онбординга
Выход: сотрудник вышел на работу
- Почему подходит: процесс найма часто теряет шаги именно из-за отсутствия четкой фиксации – текстовая карта закрывает этот пробел
- Что важно не испортить: шаг подготовки к выходу нередко пропускают, из-за чего новый сотрудник в первый день не имеет ни доступов, ни рабочего места
📌 Процесс возврата товара в интернет-магазине
- Сценарий: клиент хочет вернуть товар ненадлежащего качества или воспользоваться правом на возврат в течение 14 дней
- Участники: клиент, менеджер поддержки, склад, бухгалтерия
- Задача: исключить потерю заявок и обеспечить соблюдение сроков возврата средств
Пример:
Карта процесса: возврат товара в интернет-магазине
Шаг 1. Обращение клиента
Ответственный: менеджер поддержки
Канал: чат на сайте, email, телефон
Действие: принять обращение, уточнить причину возврата, зафиксировать в системе
Выход: заявка на возврат создана
Шаг 2. Проверка основания
Ответственный: менеджер поддержки
Действие: проверить, соответствует ли запрос условиям возврата (срок, состояние товара)
Условие: если возврат возможен – перейти к шагу 3; если нет – уведомить клиента с объяснением причины
Выход: решение зафиксировано
Шаг 3. Организация отправки
Ответственный: менеджер поддержки
Действие: выслать клиенту инструкцию по возврату, при необходимости – оформить бесплатную отправку
Выход: клиент отправил товар
Шаг 4. Приемка товара на складе
Ответственный: сотрудник склада
Действие: проверить комплектность и состояние товара, зафиксировать результат приемки
Выход: акт приемки оформлен
Шаг 5. Возврат денежных средств
Ответственный: бухгалтерия
Действие: произвести возврат на карту или счет клиента в течение 10 рабочих дней
Выход: средства возвращены, клиент уведомлен
- Почему подходит: процесс возврата затрагивает несколько подразделений – текстовая карта с указанием ответственных на каждом шаге снижает риск "потери" заявки между отделами
- Где работает лучше всего: в небольших и средних интернет-магазинах, где нет автоматизированной системы управления возвратами
Табличные карты бизнес-процесса
Таблица – удобный формат для процессов, в которых важно видеть сразу несколько параметров: кто делает, что делает, в какой срок и что получается на выходе. Такие карты хорошо встраиваются в регламенты, должностные инструкции и корпоративные базы знаний. Они проще для восприятия, чем сплошной текст, и легко обновляются.
📌 Процесс согласования договора
- Сценарий: внутреннее согласование договора с контрагентом перед подписанием
- Участники: инициатор (менеджер), юридический отдел, финансовый директор, генеральный директор
- Задача: исключить подписание договоров без обязательных согласований
Пример:
Карта процесса: согласование договора
| № | Шаг | Ответственный | Действие | Срок | Результат |
| 1 | Инициация | Менеджер | Заполнить лист согласования, приложить проект договора | До передачи | Пакет документов сформирован |
| 2 | Юридическая проверка | Юрист | Проверить условия договора, внести правки или согласовать | 2 рабочих дня | Договор с визой юриста или с замечаниями |
| 3 | Финансовая проверка | Финансовый директор | Проверить финансовые условия и соответствие бюджету | 1 рабочий день | Виза финансового директора или отказ с обоснованием |
| 4 | Финальное согласование | Генеральный директор | Рассмотреть и подписать или вернуть на доработку | 1 рабочий день | Подписанный договор или решение о доработке |
| 5 | Регистрация | Секретариат / менеджер | Присвоить номер, зафиксировать в реестре договоров | В день подписания | Договор зарегистрирован, оригинал передан на хранение |
- Почему подходит: таблица с четкими сроками на каждом шаге позволяет отслеживать, где договор "завис" и кто является узким местом в согласовании
- Что важно не испортить: не оставлять колонку "Срок" пустой – именно она превращает карту из описания в рабочий инструмент контроля
📌 Процесс выставления счета и оплаты
- Сценарий: стандартный цикл от выставления счета клиенту до фиксации оплаты в учетной системе
- Участники: менеджер по работе с клиентами, бухгалтерия, клиент
- Задача: исключить случаи, когда счет выставлен, но оплата не поступила и никто не контролирует ситуацию
Пример:
Карта процесса: выставление счета и контроль оплаты
| № | Шаг | Ответственный | Действие | Срок | Результат |
| 1 | Запрос на выставление счета | Менеджер | Передать в бухгалтерию реквизиты клиента и сумму | В день договоренности | Заявка на счет передана |
| 2 | Формирование счета | Бухгалтерия | Выставить счет в учетной системе, подготовить PDF | 1 рабочий день | Счет готов |
| 3 | Отправка клиенту | Менеджер или бухгалтерия | Направить счет на email клиента, подтвердить получение | В день формирования | Клиент получил счет |
| 4 | Контроль оплаты | Менеджер | Проверить поступление оплаты на 3-й рабочий день после отправки | 3 рабочих дня | Оплата поступила или инициирован повторный контакт |
| 5 | Фиксация в системе | Бухгалтерия | Отразить поступление в учетной системе, закрыть задачу | В день поступления | Оплата зафиксирована, документы закрыты |
- Почему подходит: шаг контроля оплаты часто выпадает из процесса – в результате счет отправлен, но никто не знает, оплачен ли он
- Где работает лучше всего: в компаниях с большим потоком счетов и несколькими ответственными за разные этапы
📌 Процесс технической поддержки клиентов
- Сценарий: обработка обращения клиента с технической проблемой – от получения тикета до закрытия
- Участники: клиент, специалист первой линии поддержки, специалист второй линии, тимлид
- Задача: обеспечить соблюдение SLA и правильную эскалацию сложных обращений
Пояснение: SLA (Service Level Agreement) – соглашение об уровне сервиса, в котором зафиксированы допустимые сроки реакции и решения.
Пример:
Карта процесса: техническая поддержка клиентов
| № | Шаг | Ответственный | Действие | Срок | Результат |
| 1 | Прием обращения | 1-я линия поддержки | Зафиксировать тикет, присвоить приоритет (низкий / средний / высокий) | До 15 минут | Тикет создан, клиент получил подтверждение |
| 2 | Первичная диагностика | 1-я линия поддержки | Воспроизвести проблему, проверить по базе знаний | До 1 часа | Решение найдено или тикет эскалирован |
| 3 | Эскалация (при необходимости) | 1-я линия → 2-я линия | Передать тикет с описанием проблемы и шагами диагностики | Сразу после решения об эскалации | Тикет принят 2-й линией |
| 4 | Решение проблемы | 2-я линия поддержки | Устранить причину, протестировать, задокументировать решение | Согласно SLA по приоритету | Проблема устранена |
| 5 | Закрытие тикета | 1-я линия поддержки | Уведомить клиента, получить подтверждение, закрыть тикет | В день решения | Тикет закрыт, клиент доволен или обращение продолжено |
- Почему подходит: процесс поддержки часто страдает от нечеткой эскалации – карта фиксирует, в какой момент и кому передается обращение
- Что важно не испортить: шаг документирования решения критичен – он наполняет базу знаний и сокращает время обработки похожих тикетов в будущем
Карты бизнес-процесса в формате Swim Lane
Swim Lane (или "дорожки") – это формат, в котором каждый участник процесса занимает отдельную горизонтальную или вертикальную полосу. Благодаря этому сразу видно, кто за что отвечает, как передается задача между участниками и где могут возникать задержки на стыках. Этот формат особенно полезен, когда в процессе задействованы три и более участника с разными зонами ответственности.
В текстовом виде Swim Lane передается через структуру "дорожка – шаги на ней", что позволяет сохранить логику схемы без графического редактора.
📌 Процесс обработки заказа в интернет-магазине
- Сценарий: полный цикл от оформления заказа покупателем до его доставки
- Участники: покупатель, менеджер магазина, склад, служба доставки
- Задача: показать, как задача переходит между участниками и где может потеряться
Пример:
Карта процесса: обработка заказа в интернет-магазине (Swim Lane)
Дорожка 1: Покупатель
- Оформляет заказ на сайте, выбирает способ доставки и оплаты
- Получает подтверждение заказа на email
- Получает уведомление об отправке с номером трека
- Получает заказ, подтверждает получение
Дорожка 2: Менеджер магазина
- Получает уведомление о новом заказе
- Проверяет оплату (для предоплатных заказов)
- Подтверждает заказ, передает на склад
- Вносит трек-номер в систему, уведомляет покупателя
Дорожка 3: Склад
- Получает задание на сборку заказа
- Собирает, проверяет комплектность, упаковывает
- Передает курьерской службе, фиксирует факт отгрузки
Дорожка 4: Служба доставки
- Принимает отправление, присваивает трек-номер
- Доставляет заказ покупателю в согласованный срок
- Фиксирует факт вручения
Точки передачи (хэндоверы):
- Менеджер → Склад: подтвержденный заказ с заданием на сборку
- Склад → Доставка: упакованный заказ с сопроводительными документами
- Доставка → Покупатель: вручение и подтверждение получения
- Почему подходит: Swim Lane сразу показывает точки передачи – именно там чаще всего теряются заказы или возникают задержки
- Где работает лучше всего: в процессах с тремя и более участниками, где важно видеть, кто сейчас "держит мяч"
- Что важно не испортить: хэндоверы (точки передачи) нужно фиксировать явно – без этого схема остается набором действий без логики взаимодействия
📌 Процесс закупки материалов
- Сценарий: плановая закупка расходных материалов для производства или офиса
- Участники: инициатор (сотрудник / руководитель подразделения), отдел закупок, финансовый директор, поставщик
- Задача: исключить закупки без согласования бюджета и показать, где процесс может замедляться
Пример:
Карта процесса: закупка материалов (Swim Lane)
Дорожка 1: Инициатор
- Формирует заявку на закупку с указанием наименования, количества и обоснования
- Согласует заявку с руководителем подразделения
- Принимает материалы, подписывает накладную
Дорожка 2: Отдел закупок
- Получает согласованную заявку
- Запрашивает коммерческие предложения у поставщиков (не менее 3)
- Выбирает поставщика, согласовывает условия
- Передает на финансовое согласование
- После согласования выставляет заказ поставщику
- Контролирует сроки поставки
Дорожка 3: Финансовый директор
- Получает заявку с выбранным поставщиком и суммой
- Проверяет соответствие бюджету
- Согласовывает или возвращает на пересмотр
Дорожка 4: Поставщик
- Получает заказ, подтверждает сроки
- Отгружает материалы, передает документы
Точки передачи:
- Инициатор → Закупки: согласованная заявка
- Закупки → Финдиректор: выбранный поставщик с суммой и обоснованием
- Финдиректор → Закупки: согласование или отказ
- Закупки → Поставщик: официальный заказ
- Поставщик → Инициатор: поставка с документами
- Почему подходит: процесс закупки часто буксует именно на этапе финансового согласования – карта делает это видимым и помогает установить норматив по срокам
- Что важно не испортить: без явного указания на необходимость трех коммерческих предложений закупки часто проходят у "любимого" поставщика без реального сравнения условий
Карты бизнес-процесса в нотации BPMN
BPMN (Business Process Model and Notation) – стандартная нотация для формального описания процессов. Полноценная BPMN-диаграмма строится в специальных инструментах (Camunda, Bizagi, draw.io), но ее логику можно передать и в текстовом виде: через описание событий, шлюзов и потоков. Такой формат полезен при постановке задач разработчикам, при описании процессов для автоматизации и при системном анализе.
Шлюз в BPMN – точка разветвления или слияния потока. Эксклюзивный шлюз (X) означает выбор одного из путей. Параллельный шлюз (+) означает одновременное выполнение нескольких потоков.
📌 Процесс согласования маркетингового бюджета
- Сценарий: согласование бюджета на рекламную кампанию внутри компании
- Участники: маркетолог, руководитель маркетинга, финансовый директор
- Задача: показать BPMN-логику с точками ветвления и обратными петлями
Пример:
Карта процесса: согласование маркетингового бюджета (BPMN-описание)
Стартовое событие: Маркетолог инициирует запрос на согласование бюджета кампании
Задача 1: Маркетолог заполняет бриф кампании и бюджетный расчет
Задача 2: Руководитель маркетинга проверяет соответствие стратегии и приоритетам
Шлюз 1 (эксклюзивный, X): Руководитель маркетинга согласовал?
- Да → Задача 3
- Нет → Задача 1 (возврат на доработку с комментариями)
Задача 3: Финансовый директор проверяет соответствие бюджету и финансовым ограничениям
Шлюз 2 (эксклюзивный, X): Финансовый директор согласовал?
- Да → Задача 4
- Нет → Шлюз 3
Шлюз 3 (эксклюзивный, X): Возможна корректировка суммы?
- Да → Задача 1 (возврат на пересмотр)
- Нет → Конечное событие: бюджет отклонен, кампания не запускается
Задача 4: Маркетолог получает подтверждение, запускает кампанию
Конечное событие: Бюджет согласован, кампания запущена
- Почему подходит: BPMN-описание явно показывает обратные петли – ситуации, когда процесс возвращается назад. Без этого согласование часто превращается в бесконечную переписку без фиксированного результата
- Где работает лучше всего: при передаче процесса разработчикам для автоматизации или при внедрении системы электронного согласования
- Что важно не испортить: каждый шлюз должен иметь явные условия для каждого пути – иначе исполнители не будут знать, по какой ветке идти
📌 Процесс выхода нового сотрудника на работу (онбординг)
- Сценарий: первые две недели нового сотрудника – от подписания документов до завершения вводного периода
- Участники: HR-менеджер, IT-служба, руководитель, наставник, новый сотрудник
- Задача: показать параллельные потоки подготовки и их слияние перед выходом сотрудника
Пример:
Карта процесса: онбординг нового сотрудника (BPMN-описание)
Стартовое событие: Оффер принят, дата выхода согласована
Параллельный шлюз (+): начало параллельных потоков
Поток A – HR-менеджер:
- Подготовить трудовой договор и кадровые документы
- Провести первичный инструктаж
- Выдать корпоративные материалы (welcome-kit, регламенты)
Поток B – IT-служба:
- Создать учетные записи (email, CRM, корпоративные системы)
- Подготовить рабочее место и оборудование
- Провести инструктаж по информационной безопасности
Поток C – Руководитель:
- Подготовить план работы на первые 30 дней
- Назначить наставника
- Провести встречу-знакомство с командой
Параллельный шлюз (+): слияние потоков
Условие: все три потока завершены → переход к следующему шагу
Задача: Наставник проводит погружение в рабочие процессы в течение первых двух недель
Задача: Руководитель проводит чек-ин по итогам первых двух недель
Шлюз (эксклюзивный, X): Сотрудник успешно прошел вводный период?
- Да → Конечное событие: онбординг завершен
- Нет → Задача: скорректировать план, назначить дополнительную поддержку → повторный чек-ин через неделю
- Почему подходит: онбординг – типичный пример процесса с параллельными потоками. Если IT и HR готовятся последовательно, а не одновременно, сотрудник приходит в первый день без доступов или без документов
- Что важно не испортить: параллельный шлюз слияния должен требовать завершения всех потоков – нельзя выходить сотруднику, пока хотя бы один поток не закрыт
Карты бизнес-процесса верхнего уровня
Карта верхнего уровня – это не детальное описание каждого шага, а общий обзор того, из каких ключевых процессов состоит деятельность компании или подразделения. Она нужна для стратегического взгляда: понять, какие процессы есть, как они связаны между собой и где находятся точки роста. Такие карты часто используются при управленческом аудите, при разработке операционной стратегии и при подготовке к автоматизации.
📌 Операционная карта производственной компании
- Сценарий: описание ключевых процессов среднего производственного предприятия для управленческого обзора
- Задача: показать структуру деятельности компании на одном листе без лишней детализации
Пример:
Карта процессов верхнего уровня: производственная компания
Уровень 1. Управляющие процессы
- Стратегическое планирование
- Управление финансами и бюджетирование
- Управление качеством и соответствие стандартам
- Управление рисками
Уровень 2. Основные процессы (создание ценности)
- Маркетинг и привлечение клиентов
- Продажи и заключение договоров
- Планирование производства
- Закупка сырья и материалов
- Производство продукции
- Контроль качества
- Логистика и отгрузка
- Послепродажное обслуживание
Уровень 3. Поддерживающие процессы
- Управление персоналом (найм, обучение, оценка)
- IT-поддержка и обеспечение инфраструктуры
- Юридическое сопровождение
- Административно-хозяйственное обеспечение
Ключевые связи между уровнями:
- Управляющие процессы задают цели и ограничения для основных и поддерживающих
- Основные процессы создают ценность для клиента и формируют выручку
- Поддерживающие процессы обеспечивают бесперебойную работу основных
- Почему подходит: карта верхнего уровня дает быстрый ответ на вопрос "что вообще происходит в компании" – без погружения в детали каждого шага
- Где работает лучше всего: при управленческих аудитах, при подготовке к сертификации по ISO, при разработке стратегии автоматизации
- Что важно не испортить: не перегружать карту деталями – как только на ней появляются конкретные шаги и ответственные, она перестает быть картой верхнего уровня и превращается в детальный регламент
📌 Карта процессов сервисной компании
- Сценарий: обзор ключевых процессов компании, оказывающей профессиональные услуги (консалтинг, IT, юридические услуги)
- Задача: показать, как устроена операционная модель без привязки к конкретной сфере услуг
Пример:
Карта процессов верхнего уровня: сервисная компания
Уровень 1. Управляющие процессы
- Управление стратегией и целями
- Финансовое управление
- Управление качеством услуг
- Управление портфелем проектов
Уровень 2. Основные процессы
- Маркетинг и формирование репутации
- Лидогенерация и квалификация запросов
- Продажа услуг и оформление договора
- Планирование и запуск проекта
- Оказание услуги / выполнение работ
- Контроль качества и приемка
- Закрытие проекта и работа с обратной связью
- Удержание клиента и повторные продажи
Уровень 3. Поддерживающие процессы
- Подбор и развитие персонала
- Управление знаниями (база знаний, шаблоны, методологии)
- IT-инфраструктура и инструменты работы
- Юридическое и бухгалтерское сопровождение
Ключевые точки роста, которые видны на карте:
- Работа с повторными продажами часто выпадает из процессной логики – клиент уходит после закрытия проекта без системного удержания
- Управление знаниями нередко остается неформальным – методологии существуют в головах, а не в базе
- Почему подходит: в сервисных компаниях операционная модель менее очевидна, чем в производстве – карта верхнего уровня делает ее видимой и управляемой
- Где работает лучше всего: при масштабировании бизнеса, при найме операционного директора, при подготовке к внедрению CRM или PSA-системы
Как создать карту бизнес-процесса. Правила и этапы сборки с примерами
Примеры выше показывают рабочую логику разных форматов карт. Ниже – не абстрактный совет "опишите свои процессы", а разбор того, как собрать карту с нуля под конкретную задачу. Этот блок нужен для адаптации под свою ситуацию, а не для копирования чужого содержания.
Базовая схема сборки карты бизнес-процесса:
- Шаг 1. Определить границы процесса: где он начинается и где заканчивается
- Шаг 2. Определить участников и их роли
- Шаг 3. Выявить все шаги процесса (лучше – совместно с участниками)
- Шаг 4. Зафиксировать входы и выходы каждого шага
- Шаг 5. Обозначить точки принятия решений (развилки)
- Шаг 6. Указать сроки и контрольные точки
- Шаг 7. Выбрать формат визуализации под задачу
- Шаг 8. Согласовать карту с участниками процесса
Таблица смысловых блоков карты бизнес-процесса:
| Блок | Зачем нужен | Что сюда подставляется | Пример заполнения |
| Название процесса | Однозначно идентифицировать процесс | Действие + объект, без размытых формулировок | Обработка входящей заявки от клиента |
| Границы процесса | Показать, где процесс начинается и заканчивается | Стартовое событие и конечный результат | Начало: заявка поступила. Конец: КП отправлено клиенту |
| Участники и роли | Распределить ответственность | Должности или подразделения, участвующие в процессе | Менеджер по продажам, РОП, бухгалтерия |
| Шаги процесса | Показать последовательность действий | Конкретные действия в логическом порядке | Принять заявку → Квалифицировать → Подготовить КП → Отправить |
| Входы и выходы | Зафиксировать, что нужно для выполнения шага и что получается в итоге | Документы, данные, решения, артефакты | Вход: заявка клиента. Выход: квалифицированная потребность |
| Точки решений | Показать развилки в процессе | Условия и варианты пути при каждом условии | Заявка целевая? Да → в работу. Нет → закрыть с фиксацией |
| Сроки и нормативы | Превратить описание в рабочий инструмент контроля | Допустимое время выполнения каждого шага | Первый контакт – не позднее 30 минут с момента поступления |
| Контрольные точки | Зафиксировать, где и кто проверяет результат | Метрики, ответственные за контроль, периодичность | Еженедельная проверка РОП: все ли заявки обработаны в срок |
Пошаговая сборка на одном кейсе: карта процесса выставления счета для небольшой дизайн-студии
Шаг 1. Границы процесса
Начало: клиент подтвердил готовность к оплате.
Конец: оплата поступила и зафиксирована в учетной системе.
Шаг 2. Участники
Менеджер проекта, бухгалтер (или сам руководитель в небольшой студии), клиент.
Шаг 3. Шаги процесса
- Менеджер передает бухгалтеру данные клиента и сумму
- Бухгалтер выставляет счет в течение 1 рабочего дня
- Менеджер отправляет счет клиенту, подтверждает получение
- Менеджер проверяет оплату на 3-й рабочий день
- Если оплата не поступила – менеджер делает напоминание
- Бухгалтер фиксирует оплату в учетной системе
Шаг 4. Точки решений
Оплата поступила в срок? Да → фиксация и закрытие. Нет → напоминание клиенту → повторная проверка через 2 дня.
Шаг 5. Сроки
Выставление счета – 1 рабочий день. Первая проверка оплаты – 3-й рабочий день после отправки. Напоминание клиенту – не позднее 5-го рабочего дня.
Готовая собранная карта процесса: выставление счета и контроль оплаты (дизайн-студия)
| № | Шаг | Ответственный | Действие | Срок | Результат |
| 1 | Передача данных | Менеджер проекта | Передать бухгалтеру реквизиты клиента и сумму | В день подтверждения | Данные переданы |
| 2 | Выставление счета | Бухгалтер | Выставить счет, подготовить PDF | 1 рабочий день | Счет готов |
| 3 | Отправка клиенту | Менеджер проекта | Отправить счет на email, подтвердить получение | В день выставления | Клиент получил счет |
| 4 | Контроль оплаты | Менеджер проекта | Проверить поступление оплаты | 3-й рабочий день | Оплата поступила или инициировано напоминание |
| 5 | Напоминание (если нужно) | Менеджер проекта | Направить вежливое напоминание клиенту | 5-й рабочий день | Клиент подтвердил срок оплаты |
| 6 | Фиксация оплаты | Бухгалтер | Отразить поступление в учетной системе | В день поступления | Оплата зафиксирована |
Где схема работает, а где ломается:
- Работает: для линейных процессов с небольшим числом участников и понятными точками передачи
- Ломается: если в процессе много параллельных потоков – тогда нужен Swim Lane или BPMN-нотация
- Нельзя выкидывать: сроки и точки контроля – без них карта остается описанием, а не инструментом управления
- Можно менять: формат таблицы, набор колонок, уровень детализации – в зависимости от сложности процесса и аудитории
- Нельзя переносить без адаптации: готовую карту из одной компании нельзя просто перенести в другую – роли, сроки и условия всегда отличаются
Практические советы по работе с картами бизнес-процессов
Сводная таблица: форматы карт и когда их использовать
| Формат | Когда подходит | Главное преимущество | Ограничение |
| Текстовая карта | Простые линейные процессы, быстрое описание | Не требует инструментов, понятна всем | Плохо показывает параллельные потоки |
| Табличная карта | Регламенты, инструкции, процессы с четкими сроками | Удобна для контроля и обновления | Не показывает ветвления наглядно |
| Swim Lane | Процессы с 3+ участниками, межотдельное взаимодействие | Сразу видно, кто за что отвечает | Требует графического оформления для максимальной пользы |
| BPMN | Автоматизация, IT-задачи, сложные процессы с ветвлениями | Стандарт, понятный разработчикам и аналитикам | Требует знания нотации и специального ПО |
| Карта верхнего уровня | Стратегический обзор, аудит, масштабирование | Дает общую картину без лишних деталей | Не показывает конкретные шаги и ответственных |
6 практических приемов при работе с картами процессов:
- Описывайте процесс так, как он есть, а не так, как должен быть. Только после фиксации реального процесса имеет смысл его улучшать. Карта "идеального процесса" без понимания текущего – это фантастика, а не инструмент.
- Вовлекайте участников процесса в его описание. Руководитель редко знает все детали лучше, чем исполнители. Лучший способ составить точную карту – провести совместную сессию с теми, кто выполняет шаги ежедневно.
- Начинайте с границ, а не с шагов. Самая частая ошибка – начать перечислять действия, не договорившись, где процесс начинается и где заканчивается. Без границ карта расползается.
- Фиксируйте точки принятия решений явно. Развилки "если – то" – самые ценные части карты. Именно там чаще всего теряются задачи и возникают недопонимания между участниками.
- Не перегружайте карту деталями на первом этапе. Начните с уровня "что происходит", потом добавляйте "кто", "когда" и "как". Слишком детальная карта с первой итерации часто устаревает раньше, чем ее успевают согласовать.
- Обновляйте карты после изменений в процессе. Карта, которая не обновляется, быстро перестает отражать реальность и превращается в формальный документ, которым никто не пользуется.
- Используйте разные форматы для разных аудиторий. Для операционного совещания подойдет Swim Lane, для разработчиков – BPMN, для нового сотрудника – текстовая карта с пояснениями. Один и тот же процесс может быть описан в нескольких форматах под разные задачи.
- Проверяйте карту на граничных случаях. Задайте вопрос: "Что происходит, если клиент не отвечает? Если документ потерян? Если ответственный в отпуске?" Если карта не дает ответа – она неполная.
- Не путайте карту процесса с должностной инструкцией. Карта описывает последовательность действий для достижения результата. Инструкция описывает обязанности должности. Это разные документы с разными задачами.
Примеры карты бизнес-процесса, разобранные в этой статье, показывают, что не существует единственно правильного формата – выбор зависит от сложности процесса, числа участников и задачи, которую нужно решить. Текстовая карта подойдет для быстрого описания, таблица – для регламента, Swim Lane – для межотдельного взаимодействия, BPMN – для автоматизации.
Главное, что объединяет все рабочие образцы карт: четкие границы, явные ответственные, зафиксированные точки передачи и сроки. Без этих элементов карта остается декоративным документом, а не инструментом управления операциями.
