Как описать бизнес-процесс, чтобы его можно было автоматизировать

Почему «как у всех» не работает

У автосервиса, стоматологии и оптовой компании слово «клиент» означает разное. У первых — машина и заказ-наряд, у вторых — пациент и приём, у третьих — контрагент, договор и отгрузка. Когда процесс описан абстрактно («ведём клиентов, делаем продажи»), исполнитель — человек или программа — достраивает детали из головы. Обычно — не ваши.

Автоматизация — это не «купить софт с галочками». Это перевод повторяющихся действий в правила: что создаётся, кто меняет статус, какие поля обязательны, что происходит дальше. Без этого любая система превращается в дорогой блокнот.

Из чего состоит описание процесса для автоматизации

Для малого бизнеса достаточно пяти блоков. Это минимальный каркас, который понимает и разработчик, и конструктор систем, и нейросеть при грамотном запросе.

1. Сущности — объекты учёта: клиент, заявка, заказ, услуга, автомобиль, счёт. «О чём строки в системе».
2. Поля — что нужно знать о каждой сущности: телефон, источник, сумма, дата визита, VIN, комментарий мастера.
3. Этапы (статусы) — через какие состояния проходит объект: Новая → В работе → Выполнено / Отказ.
4. Роли — кто имеет право создавать, менять, видеть: администратор, менеджер, мастер, бухгалтер.
5. Правила перехода — что должно быть заполнено, чтобы перейти дальше; кто получает уведомление; что считается завершением.

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

Шаблон описания: «Кто → Что → Когда → Результат»

Для каждого шага процесса заполните четыре пункта. Пример для типовой заявки на услугу:

Такой шаблон сразу показывает, сколько ролей нужно в системе и сколько статусов — не 15 «на всякий случай», а ровно столько, сколько есть в реальности.

Пример 1: сервисная компания (выезд мастеров)

Сущности: Клиент, Заявка, Выезд, Мастер, Услуга (из прайса).

Поля заявки: адрес, тип работ, желаемое время, источник (сайт / рекомендация / Avito), фото (необязательно).

Этапы: Новая → Назначен мастер → Выезд запланирован → В работе → Завершено / Отмена.

Роли: диспетчер (создаёт и назначает), мастер (видит только свои выезды, меняет статус и добавляет отчёт), руководитель (все заявки, отчёты).

Правила: нельзя перевести в «Выезд запланирован» без назначенного мастера и даты; при «Завершено» — обязательны выполненные услуги и сумма (или «по договорённости»).

Такое описание — на 1–2 страницы текста — уже достаточно, чтобы собрать рабочую систему учёта без месяца согласований.

Пример 2: B2B-продажи с длинным циклом

Здесь часто путают «воронку» и «процесс». Воронка — этапы сделки. Процесс — кто и что делает на каждом этапе.

• Сущности: Компания-клиент, Контакт, Сделка, Коммерческое предложение, Договор.
• Этапы сделки: Лид → Квалификация → КП → Переговоры → Договор → Оплата → Закрыта (успех/отказ).
• Обязательные поля при переходе: на «КП» — потребность и бюджет (хотя бы диапазон); на «Договор» — номер и сумма; на «Отказ» — причина из списка.
• Исключение: повторная сделка с тем же клиентом — можно создавать из карточки компании, не дублируя контакт.

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

Пример 3: запись на услуги (клиника, салон, СТО)

Типичная ошибка — описать только календарь. Реальный процесс шире:

1. Клиент записывается (администратор или онлайн-форма).
2. Напоминание за день / за час (кто отвечает — система или администратор).
3. Визит: статус «Пришёл» / «Не пришёл» — важно для статистики no-show.
4. Оказание услуги, оплата (нал / карта / счёт).
5. Повторная запись — из карточки клиента, с историей прошлых визитов.

В описании укажите: один клиент — много записей; услуги из справочника; мастер/кабинет как ресурс с ограничением по времени.

7 ошибок при описании процесса

• Описывают идеал, а не факт. «У нас всё через CRM» — а на деле половина в WhatsApp. Опишите реальность, потом улучшайте.
• Слишком много статусов. 12 этапов для команды из трёх человек — никто не будет переключать.
• Нет владельца процесса. Кто отвечает, что описание актуально? Обычно — руководитель или старший менеджер.
• Путают документ и процесс. «Нужен договор в PDF» — это артефакт; процесс — кто готовит, кто согласует, где хранится ссылка.
• Игнорируют исключения. «Клиент передумал», «перенос на завтра», «скидка только с директором» — 3–5 частых исключений стоит описать явно.
• Не разделяют права. Мастер не должен видеть маржу; бухгалтер — не обязан редактировать заявки.
• Ждут «идеального» описания. Лучше версия 1.0 за два часа и правки через месяц, чем полгода «допишем ТЗ».

Чек-лист перед автоматизацией

Пройдите по пунктам — если на большинство есть ответ «да», описание готово к передаче в систему или ИИ-конструктор:

1. Названы все сущности (объекты учёта) — не больше 5–7 на старте.
2. Для каждой сущности — список полей: обязательные и «желательные».
3. Этапы/статусы — 4–8 штук, формулировки понятны сотрудникам без обучения.
4. Роли — кто что видит и кто что меняет.
5. Для каждого перехода статуса — что должно быть заполнено.
6. Описаны 3–5 типовых исключений.
7. Понятно, где процесс начинается и где заканчивается.
8. Есть один человек, который подтверждает: «да, так у нас работает».

Ниша / тип бизнеса:
Кто участвует (роли):
Сущности (что ведём в учёте):
Поля по каждой сущности:
Этапы / статусы:
Кто что создаёт и меняет:
Правила переходов (что обязательно):
Исключения (3–5 типичных):
Что НЕ входит в процесс:
Откуда приходят обращения (каналы):

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

Проведите «настольную репетицию» без компьютера:

1. Возьмите реальную заявку за последнюю неделю.
2. Пройдите по вашим этапам — откуда пришла, кто брал, где застряла, чем закончилась.
3. Отметьте, где описание не совпало с жизнью — поправьте текст.
4. Повторите с другой заявкой другого типа (если есть).

Если обе проходят без «ну тут по-другому бывает» — описание жизнеспособно. Если на каждом шаге оговорки — процесс ещё не формализован, и автоматизация будет буксовать.

От описания к системе: что дальше

Дальше возможны три пути — от простого к сложному:

• Таблица / база по шаблону — если команда маленькая и процесс уже описан.
• Конструктор под свой процесс — когда нужны роли, связи, отчёты; описание становится основой конфигурации.
• ИИ-ассистент — когда описание на человеческом языке можно подать как запрос: «CRM для выездного сервиса: диспетчер, мастера, статусы …» — и получить черновик структуры для доработки.

В NXR-Engine как раз такой сценарий: описали процесс → ИИ или готовый шаблон из магазина конфигураций → донастройка в визуальном конструкторе → демо → разовая оплата и установка у себя. Без обязательной «CRM-революции» и без подписки за каждого пользователя.

Связь с учётом заявок

Если вы уже навели порядок во входящих обращениях (WhatsApp, почта, звонки), описание процесса — следующий слой: не только «зафиксировать заявку», но и провести её по этапам до результата. Материалы дополняют друг друга: сначала — не терять обращения, затем — формализовать путь от обращения до оплаты.

Частые вопросы

Материал подготовлен для блога NXR-Engine. Ключевые темы: описание бизнес-процесса, автоматизация малого бизнеса, сущности и статусы, роли и правила, подготовка к внедрению системы учёта.