Как описать бизнес-процесс: пошаговая инструкция | СМБД: Стратегия, Маркетинг, Бизнес, Доход.

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

Многие руководители откладывают описание процессов до лучших времён. Причины знакомые: «нет времени», «у нас всё слишком специфично», «сначала наладим работу, потом опишем». В итоге лучшие времена не наступают, ключевые сотрудники уходят вместе со своими знаниями, а масштабирование превращается в хаос.

Хорошая новость: описать бизнес-процесс проще, чем кажется. Это не требует специального образования, дорогих инструментов или недель работы. Нужен алгоритм — и немного дисциплины.

С чего начать: выбор формата

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

Текстовое описание (проза) — простой связный текст с перечислением шагов. Подходит для несложных процессов, которые сложно разбить на чёткие этапы. Легко написать, легко прочитать. Сложно обновлять и сложно отследить ответственных.

Чек-лист — пронумерованный список шагов с отметкой о выполнении. Идеален для повторяющихся операций, которые выполняет рядовой сотрудник: «сделал — поставил галочку». Прост в использовании, не требует никаких инструментов.

Таблица — каждый шаг в отдельной строке, рядом — ответственный, срок, инструмент, результат. Хорошо структурирует информацию, легко читается и обновляется. Оптимальный выбор для большинства ситуаций.

Блок-схема — визуальная диаграмма с условиями, ветвлениями и стрелками. Незаменима для процессов, где есть разветвления («если клиент одобрил — переходим к X, если нет — возвращаемся к Y»). Требует чуть больше времени на создание, зато наглядно показывает логику.

BPMN-нотация — стандартизированный язык описания процессов для специалистов. Мощный инструмент, но избыточный для большинства малых бизнесов. Подробнее о нём — в отдельном материале.

Правило выбора: используйте самый простой формат, который справляется с задачей. Начинать с BPMN, когда достаточно чек-листа — типичная ошибка перфекциониста.

Алгоритм описания процесса: 8 шагов

Шаг 1. Выберите один процесс

Не пытайтесь описать всё сразу. Выберите один — тот, который болит сильнее других: где чаще случаются ошибки, который зависит от одного конкретного человека, где клиенты жалуются.

Хороший критерий выбора первого процесса: что произойдёт, если ключевой сотрудник заболеет завтра? Процесс, ответ на который «катастрофа» — описывайте первым.

Шаг 2. Определите границы процесса

У каждого процесса есть начало и конец. Сформулируйте их явно:

Начало (триггер): что запускает процесс? Входящая заявка, звонок клиента, поступление товара на склад?
Конец (результат): что является завершением? Подписанный договор, отправленный заказ, закрытая задача?

Граница должна быть конкретной, а не размытой. «Работа с клиентом» — это не процесс, у него нет чётких границ. «Обработка входящей заявки с момента получения до первого звонка клиенту» — это процесс.

Шаг 3. Соберите информацию у тех, кто выполняет процесс

Это самый важный шаг — и самый часто пропускаемый.

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

Поговорите с теми, кто непосредственно выполняет каждый шаг. Спросите:

Что конкретно вы делаете, когда получаете [триггер]?
Что делаете дальше?
Что происходит, если [нестандартная ситуация]?
Где чаще всего что-то идёт не так?
Есть ли шаги, которые кажутся лишними?

Не записывайте «как должно быть» — записывайте «как есть».

Шаг 4. Опишите процесс «как есть» (AS-IS)

На основе собранной информации зафиксируйте текущую версию процесса в выбранном формате. Без приукрашивания и без улучшений — только реальность.

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

AS-IS нужен, чтобы:

Увидеть, как процесс работает сейчас;
Найти проблемы и потери;
Иметь точку отсчёта для улучшений.

Шаг 5. Проверьте описание с участниками

Покажите черновик тем, кто участвует в процессе. Попросите проверить: всё ли правильно, ничего ли не упустили, все ли исключения учтены.

Это не формальность. Почти всегда на этом этапе выясняется, что что-то упущено или описано неточно. Лучше исправить сейчас, чем получить регламент, которому никто не следует, потому что «там написано не так, как мы делаем на самом деле».

Шаг 6. Найдите проблемы и точки улучшения

Имея описание AS-IS, посмотрите на него аналитически:

Есть ли лишние шаги, которые не добавляют ценности?
Где возникают задержки и почему?
Где теряется информация или возникает путаница с ответственными?
Какие шаги можно автоматизировать?
Где самый высокий риск ошибки?

Шаг 7. Опишите процесс «как должно быть» (TO-BE)

На основе анализа создайте улучшенную версию процесса. Это и есть целевое состояние, к которому нужно прийти.

TO-BE не обязан быть идеальным. Лучше небольшое реалистичное улучшение, которое будет внедрено, чем идеальная схема, которая останется в ящике стола.

Шаг 8. Согласуйте и зафиксируйте официально

Финальная версия должна быть:

Согласована с теми, кто выполняет процесс, и с руководителем;
Доступна всем участникам — в общей папке, корпоративной вики или системе управления процессами;
Датирована (версия и дата редакции);
Понятно структурирована, чтобы новый сотрудник мог разобраться без дополнительных объяснений.

Что должно быть в описании

Хорошее описание процесса содержит:

Название процесса — чёткое и однозначное;
Владелец процесса — кто отвечает за его исполнение и обновление;
Триггер — что запускает процесс;
Результат — что считается успешным завершением;
Участники — кто и на каком этапе задействован;
Шаги — последовательность действий с указанием ответственного на каждом шаге;
Нормативы — сроки выполнения, если применимо;
Исключения — что делать в нестандартных ситуациях;
Версия и дата — когда последний раз обновлялось.

Практический пример: обработка входящей заявки

Процесс: Обработка заявки с сайта;
Владелец: Менеджер по продажам;
Триггер: Заявка поступила в CRM;
Результат: Клиент переведён в статус «Переговоры» или получил отказ с причиной.

#	Действие	Кто	Срок	Инструмент
1	Проверить заявку в CRM, убедиться в полноте данных	Менеджер	В течение 15 мин.	CRM
2	Позвонить клиенту. При недозвоне — оставить голосовое сообщение, отправить SMS	Менеджер	В течение 1 часа	CRM, телефон
3	Выявить потребность, уточнить бюджет и сроки	Менеджер	При первом контакте	—
4	Занести результат разговора в карточку клиента	Менеджер	Сразу после звонка	CRM
5а	Если клиент целевой → перевести в статус «Переговоры», назначить следующий шаг	Менеджер	В течение 30 мин.	CRM
5б	Если клиент нецелевой → зафиксировать причину отказа, перевести в статус «Закрыт»	Менеджер	В течение 30 мин.	CRM
6	При недозвоне: повторить попытку через 2 часа. Если не дозвонились 3 раза — отправить email с предложением самому связаться	Менеджер	По расписанию	CRM, email

Исключения: Если заявка поступила вне рабочего времени — первый контакт не позднее 10:00 следующего рабочего дня.

Инструменты для описания процессов

Для текста и таблиц: любой текстовый редактор или Google Docs/Яндекс Документы. Ничего лишнего — просто начните писать.

Для чек-листов: TeamDo, встроенные инструменты CRM или даже обычный Excel.

Для блок-схем: draw.io (diagrams.net) — бесплатный браузерный инструмент, работает без установки и доступен в России. Подходит и для простых блок-схем, и для BPMN-диаграмм.

Для BPMN-моделирования: Bizagi Modeler — бесплатная десктопная программа с полной поддержкой BPMN 2.0. Требует установки, но не требует подписки.

Для совместной работы над процессами в команде: корпоративные вики (Confluence, аналоги) или пространства в Projecto — при условии, что инструмент доступен для всей команды.

Совет: не выбирайте инструмент дольше, чем описываете первый процесс. Начните с того, что уже есть — Word, Excel, обычный текстовый файл. Инструмент можно сменить позже.

Типичные ошибки

Начать с TO-BE, минуя AS-IS. Без понимания того, как процесс работает сейчас, невозможно его улучшить. Описание «как должно быть» без фиксации «как есть» — это не описание процесса, а фантазия о процессе.

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

Стремиться к совершенству с первого раза. Идеального описания не существует. Хорошее несовершенное описание, которое реально используется, лучше идеального, которое пылится в папке.

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

Описать один раз и забыть. Процессы меняются. Описание должно обновляться вместе с ними — иначе оно становится историческим артефактом, а не рабочим инструментом.

Вывод

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

Начните с одного процесса — того, который болит прямо сейчас. Поговорите с теми, кто его выполняет. Зафиксируйте как есть. Найдите одно улучшение. Задокументируйте.

Это уже будет больше, чем делает большинство малых бизнесов.