Описание бизнес-процессов в средней российской компании обычно проходит по одному из двух сценариев. В первом нанимают консалтинговую компанию за 4–6 миллионов рублей, через четыре месяца получают аккуратную папку из шестидесяти диаграмм BPMN, кладут на полку и больше никогда не открывают. Во втором — собственными силами пытаются что-то описать за два месяца, погружаются в детали первого процесса, теряют темп, и через полгода у компании есть два с половиной описанных процесса из тридцати. Оба сценария — провальные.
Эта статья — про третий путь: как пройти первый рабочий цикл описания бизнес-процессов в компании на 100–300 сотрудников за четыре недели, без консалтинга на миллионы и без увязания в деталях.
Неделя 1. Карта процессов верхнего уровня
Цель — собрать перечень из 25–35 процессов компании на одной странице. Не описывать их, а просто назвать. Это парадоксально сложно: руководители обычно знают, что у них «есть процесс продаж», но не могут разделить его на пресейл, переговоры, заключение договора, постпродажное сопровождение.
Делается за две сессии по 2 часа с топ-командой. На первой — мозговой штурм: каждый функциональный руководитель называет «свои» процессы. На второй — нормализация: убираем дубли, подбираем единые названия, разбиваем слишком крупные.
Результат — карта на одной странице, разделённая на три блока: основные процессы (создают ценность для клиента), вспомогательные (обеспечивают основные), управленческие (планирование, контроль, аналитика). Без этой карты переходить ко второму этапу нет смысла.
Неделя 2. Приоритизация и выбор пилотного процесса
Из 25–35 процессов нельзя описать все одновременно. Выберите 3–5 для первого цикла, и среди них один пилотный.
Критерии приоритизации: — частота сбоев в процессе (если процесс ломается раз в неделю — приоритет высокий); — стоимость одного сбоя (один из показателей — сколько часов руководителя уходит на разбор инцидента); — участие в маржинальности (если процесс непосредственно влияет на выручку или себестоимость).
Хороший пилотный процесс — тот, у которого есть очевидный владелец, не больше 4–5 шагов, и в котором участвуют 2–3 функции. Плохой пилот — кросс-функциональный процесс с участием семи отделов: на нём вы погрязнете.
Типичные хорошие пилоты: оформление возврата клиенту, выставление счёта и договора, заведение нового сотрудника, обработка обращения в техподдержку.
Неделя 3. Описание «как есть» с участниками
Главная ошибка — пытаться описать процесс «как должно быть». Сначала описывается «как есть», даже если выглядит уродливо. Делается это в двух форматах: интервью с непосредственными исполнителями (по 30–40 минут с 3–4 людьми) и наблюдение за выполнением (если возможно).
Записывается в простом формате, без BPMN на первом цикле: — триггер процесса (что запускает); — 6–10 шагов в виде простого списка; — ответственный на каждом шаге; — срок выполнения шага; — результат шага.
Не пытайтесь сразу нарисовать схему в Visio. Текстовое описание понимают все, а схема — только те, кто умеет читать BPMN.
После описания «как есть» — короткий разбор с владельцем процесса: что в этой картине вас не устраивает? Где теряется время? Где идут возвраты? Это и есть точки, в которых процесс нужно менять.
Неделя 4. Регламент и владелец
В четвёртую неделю — два документа. Первый — регламент процесса в финальной версии «как должно быть» (с учётом найденных проблем). Объём — 2–3 страницы текста плюс одна простая схема. Лучше короткое и понятное, чем длинное и точное.
Второй — приказ о назначении владельца процесса. Владелец — это конкретный человек с фамилией и должностью, который отвечает за то, что процесс работает. Не «отдел продаж», а директор по продажам. Не «бухгалтерия», а главный бухгалтер. Без владельца регламент не работает: через три недели его перестанут соблюдать, и спросить будет не с кого.
Дополнительно — простая система мониторинга процесса. Один-два показателя, которые владелец смотрит еженедельно. Например, для процесса возврата клиенту: средний срок возврата от обращения до денег на счёте, доля обращений, закрытых в SLA.
Что не нужно делать на первом цикле
Не нужно покупать дорогую систему BPM. Текстовый регламент в Confluence/Notion и одна схема в draw.io работают первые 6–12 месяцев. Покупка системы становится осмысленной, когда у вас уже описано 15+ процессов и появилась задача интеграции с учётной системой и автоматизации шагов.
Не нужно описывать сразу все 25 процессов. Реалистичный темп — 1 пилотный за месяц, потом 2–3 в месяц, итого 18–22 процесса за первый год.
Не нужно делать ребрендинг процессов с нуля. Если процесс работает приемлемо, описание должно его зафиксировать, а не перепридумать.
Итог
Первый цикл описания бизнес-процессов в средней компании — это не консалтинговый проект на миллионы и не двухмесячное погружение в BPMN. Это четырёхнедельный спринт с понятными артефактами на каждой неделе: карта верхнего уровня, выбор пилота, описание «как есть», регламент с владельцем. Дальше — итерация и масштабирование, по 2–3 процесса в месяц. Через год у компании появляется свойство, которого до этого не было: процессы, на которые можно опереться при найме нового человека и при росте.