Ко мне регулярно приходят с запросом «нужно построить бизнес-процессы». Обычно за этим стоит одно и то же: в компании всё держится на памяти двух-трёх человек, и как только один из них в отпуске или уходит — начинает сыпаться.
Построение бизнес-процессов — это про то, чтобы работа шла по понятным правилам, а не по памяти конкретного человека. Идея простая. Сложности начинаются, когда её пытаются реализовать.
Что такое построение бизнес-процессов на практике
Построение бизнес-процессов — это описание того, кто, что и в каком порядке делает, чтобы результат получался предсказуемо. Не красивая схема в Miro, а реальный порядок действий, который продолжает работать, даже если ключевой сотрудник заболел или уволился.
Это часто путают с оптимизацией. Разница простая: оптимизировать можно только то, что уже есть. Если процесса нет вообще — а по факту есть только привычки конкретных людей — сначала нужно его построить, и только потом оптимизировать.
С чего начинать построение бизнес-процессов
Я обычно начинаю не с документа, а с разговора. Прошу показать, как задача проходит от начала до конца — на реальном примере, а не в теории. Почти всегда выясняется, что «официальная» версия процесса и то, что происходит на самом деле, — два разных процесса.
Дальше — три вопроса, без которых построение бизнес-процессов превращается в бумажную работу:
- Кто отвечает за результат, а не просто «участвует»?
- Что происходит, если этот человек недоступен?
- По какому признаку понятно, что процесс сработал?
Если на эти три вопроса нет чёткого ответа, никакая схема не поможет. Она просто зафиксирует хаос красивым цветом.
Где обычно ломается построение бизнес-процессов
Начинают с инструмента. Покупают CRM или таск-трекер, надеясь, что процесс появится сам. Не появляется. Инструмент фиксирует процесс, который уже есть, — он не создаёт его из ничего.
Делают процесс без тех, кто по нему будет работать. Сотрудники видят регламент впервые на общем собрании — и саботируют его в первую же неделю. Не потому что ленивые, а потому что их не спросили, как они на самом деле работают.
Пытаются описать всё сразу. Маленькая компания получает несколько десятков страниц регламентов, которые никто не читает и не открывает второй раз. Лучше один процесс, который реально соблюдается, чем десять — только на бумаге.
Инструменты — это последний шаг, а не первый
Когда процесс понятен и люди по нему уже работают руками, тогда есть смысл выбирать, во что его упаковать: таблицу, CRM, отдельный сервис. До этого момента инструмент — просто трата бюджета.
Построение бизнес-процессов без такого порядка почти всегда заканчивается одинаково: система куплена, регламент написан, а по факту всё держится на памяти тех же двух-трёх человек, что и раньше.
Кто должен строить бизнес-процесс — руководитель или сотрудники
Здесь тоже есть типичная ошибка: процесс либо пишет один человек в кабинете, либо его пускают на самотёк, надеясь, что команда сама себя организует. Ни один из этих подходов не работает надёжно.
Руководитель или внешний консультант задаёт рамку — какие вопросы должны получить ответ, каким должен быть результат процесса, кто за него в итоге отвечает. А детали самого процесса — кто конкретно что делает в какой последовательности — точнее знают те, кто с этим работает руками каждый день. Если пропустить их мнение, регламент получается технически правильным и практически нерабочим: сотрудники находят десять причин, почему «на самом деле так не получится», и в итоге всё равно делают по-своему.
Рабочая связка — человек снаружи держит структуру и задаёт вопросы, а команда изнутри заполняет её реальными деталями. Тогда регламент описывает то, что действительно происходит и может происходить, а не то, что выглядело бы красиво на бумаге.
Если команда сопротивляется самому факту описания процесса — это почти всегда сигнал не о лени, а о недоверии: люди опасаются, что регламент станет инструментом контроля и наказания, а не помощи. Снять это напряжение можно только одним способом — на практике показать, что описанный процесс упрощает работу самим исполнителям, а не просто добавляет им отчётности.
Как понять, что процесс наконец построен
Есть простая проверка: попросите сотрудника, который раньше не занимался этой задачей, выполнить её только по описанию процесса — без подсказок и без звонка тому, кто «всегда это делал». Если результат получается приемлемым, процесс построен. Если человек застревает на первом же шаге, потому что в описании не хватает контекста, который был очевиден только автору, — регламент существует на бумаге, но не работает как процесс.
Вторая проверка — время. Работающий процесс переживает отпуск и увольнение ключевого сотрудника без просадки в качестве. Если через месяц после того, как человек, который «всегда это делал», ушёл в отпуск, всё снова начинает сыпаться, — значит, на самом деле построили не процесс, а просто задокументировали чужую память, и без автора документ не работает.
Построение процессов в маленькой компании
В компании с пятью-десятью сотрудниками часто кажется, что процессы — это про крупный бизнес, а маленькой команде достаточно просто договориться. Отчасти это верно: чем меньше людей, тем меньше формальных процедур нужно на бумаге. Но одно-два ключевых места, где всё держится на памяти конкретного человека, есть даже в самой маленькой команде — обычно это работа с деньгами, с клиентами или то единственное, в чём разбирается только основатель.
Задача в маленькой компании не в том, чтобы описать всё подряд, а в том, чтобы найти эти одну-две точки риска и закрыть именно их. Остальное можно и нужно оставлять гибким — избыточная бюрократия убивает маленькую команду быстрее, чем её отсутствие. Признак того, что бюрократии уже больше, чем нужно, простой: если сотрудники начинают жаловаться, что бумажной работы стало больше, чем самой работы, — это повод сократить регламенты, а не добавить ещё один документ поверх существующих.
Признаки того, что процесс пора пересматривать
Построенный однажды процесс не остаётся рабочим навсегда. Компания растёт, меняется команда, появляются новые клиенты и задачи — и то, что отлично работало на пяти сотрудниках, начинает давать сбои на двадцати. Несколько сигналов, что процесс требует пересмотра: сотрудники массово начинают его обходить «для скорости»; на одном и том же шаге регулярно возникают одни и те же вопросы, которые регламент не покрывает; результат стал менее предсказуемым, хотя формально все действуют по описанной процедуре.
Разница между этой ситуацией и полным отсутствием процесса важна: здесь не нужно строить заново с нуля — нужно найти конкретное узкое место и скорректировать именно его. Пересмотр отдельного шага занимает часы, а не недели, если основа процесса уже есть и по ней есть история наблюдений.
Инструменты, которые помогают, а не подменяют процесс
Таск-трекер, CRM, регламент в общей папке — всё это способы зафиксировать процесс, а не создать его. Ошибка, о которой уже шла речь выше, повторяется настолько часто, что стоит сказать отдельно: покупка инструмента до того, как процесс понятен, почти всегда означает, что через полгода в новой системе будет храниться тот же хаос, что был раньше, только теперь с более красивым интерфейсом.
Правильный порядок обратный. Сначала процесс проговорен и работает хотя бы на бумаге или в голове двух-трёх человек, которые его выполняют. Потом, когда понятно, какие шаги повторяются и какие данные нужно передавать между людьми, выбирается инструмент под эту конкретную задачу — не самый популярный на рынке, а тот, что закрывает именно ваш случай.
Сколько времени занимает построение процесса
Ожидание, что процесс можно построить за один вечер, — частая причина разочарования в самой идее. Реалистичный срок для одного полноценного процесса — от нескольких недель до пары месяцев, в зависимости от того, сколько людей в нём участвует и насколько сильно расходятся их версии происходящего.
Основное время уходит не на написание документа, а на согласование деталей между людьми, которые до этого работали по-разному и уверены, что именно их способ — единственно правильный. Торопить это согласование бессмысленно: попытка продавить процесс через несогласных решением сверху экономит время сейчас и теряет его позже, когда несогласные саботируют внедрение. Документ пишется быстро, когда согласование уже пройдено; большая часть работы — до этого момента, в разговорах, а не в тексте.
Построение бизнес-процессов почти никогда не заканчивается одним документом навсегда: живой процесс продолжает уточняться по мере того, как меняется команда и масштаб компании. Задача первого прохода — не написать идеальный регламент, а закрыть конкретный риск, из-за которого работа держится на памяти одного-двух человек. Если после первой попытки построить процесс что-то пошло не так — это не повод возвращаться к работе по памяти, а сигнал уточнить конкретный шаг, где расходится теория с практикой, и переписать именно его, а не выбрасывать всю проделанную работу.
Если хотите разобраться, с чего начать построение бизнес-процессов в вашей компании — напишите в Telegram.