Как описать бизнес-процесс перед автоматизацией: шаблон «как есть / как будет» и пример

Короткий ответ: перед автоматизацией процесс описывают дважды — «как есть», то есть как работа идёт сегодня со всеми обходами, и «как будет», то есть что должна делать система, а что остаётся людям. Для этого не нужна специальная нотация: хватает таблицы из восьми граф на каждый шаг и схемы из прямоугольников и стрелок. Один процесс своими силами описывают за 1–2 дня, а с таким описанием разработчик называет цену точнее и реже ошибается в объёме автоматизации.

Зачем описывать процесс до автоматизации?

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

Без описания типичный сценарий такой. Заказчик говорит: «Нужно, чтобы заявки из сайта шли в CRM, а счёт создавался в 1С». Разработчик делает ровно это. На запуске выясняется, что треть заявок приходит звонком, счёт для постоянных клиентов делают со скидкой, которую согласует директор, а склад отгружает по оплате, о которой узнаёт из чата. Связка работает, а процесс — нет: люди продолжают вести его по-старому параллельно с новой системой.

Описание даёт три практических результата:

• Список того, что именно автоматизировать. Не «отдел продаж», а конкретные шаги: создание сделки, проверку остатка, формирование счёта, смену статуса после оплаты.
• Цифры для решения. Сколько раз в день повторяется шаг и сколько минут занимает — из этого считается, оправдана ли работа. Формула расчёта — в статье «7 признаков, что бизнесу пора автоматизировать процессы».
• Границы проекта. Что входит в первый этап, а что откладывается. Это защищает и вас, и подрядчика от разговора «мы думали, это тоже входит».

Что такое «как есть» и «как будет»?

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

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

Вторая ошибка — переносить «как есть» в программу один в один. Если сегодня счёт трижды согласуют в мессенджере, потому что никто не доверяет ценам в таблице, автоматизировать три согласования не нужно — нужно сделать цены надёжными. Поэтому между двумя описаниями всегда есть шаг пересмотра: какие действия убрать, какие объединить, где хватит правила вместо ручной проверки.

Рабочий порядок такой:

1. Выберите один процесс с понятным началом и концом: «от заявки до отгрузки», «от счёта поставщика до оплаты», «от обращения клиента до закрытия».
2. Опишите «как есть» по шагам, разговаривая с теми, кто делает работу, а не только с руководителем.
3. Отметьте в каждом шаге, что болит: ожидание, двойной ввод, ошибки, потерянные задачи.
4. Опишите «как будет»: что делает система, что человек, где нужно подтверждение.
5. Решите, что войдёт в первый этап, а что — позже.

Нужна ли нотация BPMN?

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

BPMN — Business Process Model and Notation — стандарт графической нотации для схем бизнес-процессов. Текущая версия спецификации, 2.0.2, опубликована консорциумом OMG в январе 2014 года (страница спецификации на сайте OMG). В нотации есть строгие обозначения для событий, задач, развилок, ролей-дорожек и обмена сообщениями между участниками.

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

• если в компании нет человека, который уже работает с BPMN, рисуйте схему как умеете — прямоугольник на шаг, ромб на развилку, стрелки, подписи ролей;
• если такой человек есть, пусть рисует в BPMN, но таблицу шагов всё равно приложите — в ней время, частота и боли, которых на схеме нет;
• если процесс большой, разбейте его на дорожки по ролям: продажи, склад, бухгалтерия. Так сразу видно, где задача переходит из рук в руки, а именно там чаще всего и теряется.

Графа	Что записать	Пример для шага «выставить счёт»
1. Шаг	Глагол + объект, одно действие	Выставить счёт клиенту
2. Кто делает	Роль, а не фамилия; замена на время отпуска	Менеджер по продажам; замещает старший менеджер
3. Что запускает шаг	Событие или документ на входе	Клиент подтвердил состав заказа в переписке
4. Где работает	Программа, файл, чат, бумага	1С: документ «Счёт на оплату», отправка с личной почты
5. Что получается	Результат и куда он уходит дальше	PDF счёта у клиента, копия в папке сделки
6. Сколько времени и как часто	Минуты на один раз, раз в день или неделю	7–10 минут, около 25 раз в день
7. Исключения	Что бывает не по правилам и как поступают	Нестандартная скидка — согласуют с директором в мессенджере
8. Что болит	Ошибки, ожидание, двойной ввод	Цены переносят руками из прайса, раз в неделю ошибаются

Шаблон описания: 8 граф

На каждый шаг процесса заполните восемь граф: что делается, кто делает, что запускает шаг, в какой программе, что получается на выходе, сколько времени и как часто, какие бывают исключения и что болит. Это одна строка таблицы на шаг; процесс среднего размера укладывается в 10–20 строк.

Несколько правил, которые экономят время на сверке:

• Один шаг — одно действие. «Проверить остаток и выставить счёт» — два шага: их делают в разных программах, и автоматизировать их можно по отдельности.
• Роли вместо фамилий. Система назначает задачи ролям. Если шаг делает «Марина, потому что она одна знает», это отдельная боль, её нужно записать.
• Цифры приблизительно, но честно. «7–10 минут, около 25 раз в день» полезнее, чем «быстро». Если не знаете — засеките неделю.
• Образцы документов. К шагу, где появляется документ, приложите пример: счёт, заявку, выгрузку. Разработчику важны реальные поля, а не их названия.

Таблицу удобно вести в любом редакторе таблиц, общий доступ — исполнителям процесса. Схему можно нарисовать на доске и сфотографировать: для первого разговора этого достаточно.

Шаг	Как есть	Как будет
Приём заявки	Письмо на общую почту, форма с сайта, звонок — каждый канал отдельно	Все каналы создают сделку в CRM, звонок менеджер заносит в одну форму
Назначение	Кто первым увидел, тот и взял; часть писем никто не открыл	Сделка уходит менеджеру по очереди, через 30 минут без ответа — уведомление руководителю
Проверка остатков	Менеджер звонит на склад или смотрит выгрузку вчерашнего дня	Остаток подтягивается из 1С в карточку сделки
Счёт	Набирается в 1С вручную, цены копируются из таблицы	Счёт формируется в 1С по позициям сделки одной кнопкой
Контроль оплаты	Бухгалтер раз в день пишет в общий чат, кто оплатил	Статус оплаты из 1С меняет этап сделки и уведомляет менеджера
Отгрузка	Склад узнаёт о заказе из мессенджера, документы печатает сам	Заказ на отгрузку создаётся после оплаты; склад видит очередь с документами

Пример: обработка заявки до и после

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

Что видно из такого сравнения. Во-первых, процесс рвётся не внутри программ, а между ними: заявка не доходит до CRM, оплата не доходит до менеджера, заказ не доходит до склада. Это задача интеграции, а не новой системы. Во-вторых, шаг «Назначение» решается правилом распределения и уведомлением, без сложной логики. В-третьих, шаг «Приём заявки» по звонку остаётся ручным — и это нормально: автоматизация не обязана покрывать всё.

Для такого первого этапа связки CRM и 1С обычно достаточно тарифа интеграций — по прайсу от 32 000 ₽ и от 2 дней за связку до двух систем, с уведомлениями в Telegram и обработкой ошибок обмена. Доработка самой конфигурации 1С и подписки сторонних сервисов в этот тариф не входят, каждая система сверх двух оценивается отдельно. Если по ходу описания выясняется, что нужны свои кабинеты для склада и клиентов, роли и отчёты, это уже веб-приложение — от 160 000 ₽ и от 10 дней. Подробнее о вариантах — на странице «Интеграции».

Где прячутся исключения и ручные обходы?

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

Вопросы, которые стоит задать каждому, кто участвует в процессе:

• Что вы делаете, когда клиент меняет заказ после выставления счёта?
• Какие заказы идут не по правилам: без предоплаты, со спецценой, срочно?
• Кого вы спрашиваете, когда не знаете, что делать, и как — устно, в чате, по почте?
• Какие таблицы или заметки вы ведёте для себя, хотя «официально» всё в 1С или CRM?
• Что ломается, когда вы в отпуске?
• Какая ошибка за последний месяц стоила больше всего денег или нервов?

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

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

Что передать разработчику для точной оценки?

Описание «как есть» и «как будет», список систем с указанием версий и доступов к API, образцы документов и данных, объёмы, перечень исключений с решением по каждому и приоритеты: что обязательно в первом этапе, а что можно позже. С таким комплектом оценка будет опираться на ваш процесс, а не на догадки.

Чек-лист комплекта для брифа:

1. Таблица шагов по 8 графам — «как есть» и «как будет».
2. Схема процесса — в любой нотации или фото с доски.
3. Список систем: 1С (какая конфигурация и где работает — у вас на сервере или в облаке), CRM, сайт, склад, банк, маркетплейсы. Для каждой — есть ли API и кто может выдать доступ.
4. Образцы: заявка, счёт, выгрузка остатков, акт — с реальными полями, персональные данные клиентов можно заменить вымышленными.
5. Объёмы: сколько заявок, счетов, позиций в день или в месяц.
6. Исключения и решение по каждому: автоматически, человеку, вне системы.
7. Роли и права: кто что видит и подтверждает. Шаги с деньгами и документами разумно оставить на подтверждение сотрудника.
8. Приоритеты и то, по чему вы поймёте, что первый этап удался: например, «ни одной заявки без ответственного дольше часа».

Описание процесса не заменяет техническое задание, но становится его основой. Если вы заказываете ещё и сайт или кабинет, порядок подготовки ТЗ мы разбирали в статье «Как составить ТЗ на сайт или веб-сервис без опыта». А о том, с какого процесса начинать, если хочется автоматизировать всё и сразу, — в материале «Автоматизация документооборота и закупок: с чего начать».

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

Когда подробное описание не нужно?

Когда задача маленькая и линейная. Если нужно, чтобы заявка с сайта приходила в Telegram и CRM, достаточно абзаца текста и примера заявки. Подробное описание нужно там, где в процессе участвуют несколько людей, несколько систем и есть деньги или документы.

Ещё три случая, когда стоит остановиться раньше:

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

Какие ошибки встречаются чаще всего?

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

• Описание «сверху». Руководитель рассказывает, как должно быть. Проверьте каждый шаг у исполнителя.
• Слишком крупные шаги. «Менеджер обрабатывает заявку» — это не шаг, а целый процесс внутри.
• Нет цифр. Без частоты и времени нельзя решить, какой шаг автоматизировать первым и стоит ли вообще.
• Нет владельца. Если за процесс никто не отвечает, после запуска некому решать спорные случаи и согласовывать изменения.
• Всё в первый этап. Чем больше шагов в первом запуске, тем дольше до первого результата. Начните с самого болезненного из простых, а остальное добавляйте по мере работы — поддержка и развитие по прайсу от 7 900 ₽ в месяц.

Короткие ответы на частые вопросы

Сколько времени занимает описание бизнес-процесса?

Один процесс среднего размера — от заявки до отгрузки или от счёта поставщика до оплаты — обычно описывают за 1–2 рабочих дня: полдня на разговоры с исполнителями, день на таблицу и сверку. Если процесс затрагивает три-четыре отдела, закладывайте больше.

Обязательно ли рисовать схему в нотации BPMN?

Нет. Для заказной автоматизации в небольшой и средней компании хватает таблицы шагов и простой схемы из прямоугольников и стрелок. BPMN полезна, когда процесс будет исполнять специальная система управления процессами или когда схемы согласуют аналитики разных команд.

Чем описание процесса отличается от технического задания?

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

Кто должен описывать процесс — мы или разработчик?

Описать текущую работу может только тот, кто её знает, то есть ваша команда; разработчик задаёт вопросы и проверяет полноту. Удобная схема: вы готовите черновик по шаблону, затем на брифе вместе разбираете исключения и решаете, что автоматизировать первым.

Сколько стоит автоматизация после того, как процесс описан?

По прайсу связка до двух систем, например CRM и 1С, — тариф интеграций от 32 000 ₽ и от 2 дней; отдельная система с ролями и кабинетами — тариф веб-приложения от 160 000 ₽ и от 10 дней. Точную сумму называем после разбора описания и фиксируем в договоре до старта.

Услуги и кейсы по теме: автоматизация и ИИ · интеграция с 1С и CRM от 32 000 ₽ · цены и сроки