Описание бизнес-процессов: как подготовить процесс к автоматизации

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

Главный принцип простой: код усиливает порядок. Если порядка нет, код усиливает беспорядок — только ошибки теперь происходят быстрее и в большем масштабе.

Что должно получиться в результате

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

В результате должны быть зафиксированы:

• начало процесса и проверяемый конечный результат;
• владелец результата, участники и зоны ответственности;
• последовательность шагов в текущем состоянии AS IS («как есть»);
• входные данные, документы и результат каждого шага;
• используемые программы, таблицы, почта и мессенджеры;
• правила принятия решений, ожидания и нестандартные сценарии;
• места потерь: ручной перенос, двойной ввод, возвраты, задержки и потерянные задачи;
• целевая модель TO BE («как должно быть»);
• перечень требований и критериев приёмки для команды разработки.

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

Как выбрать первый процесс для описания

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

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

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

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

Что собрать до схемы

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

На интервью полезно пройти один конкретный недавний случай от начала до конца и задать вопросы:

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

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

Как описать бизнес-процесс AS IS

AS IS фиксирует фактический процесс без попытки сразу его улучшить. Если менеджер получает заявку в почте, копирует телефон в CRM, уточняет остаток в 1С и пишет коллеге в мессенджере, так и нужно записать. Фраза «по регламенту всё работает иначе» не заменяет наблюдение.

Двигайтесь в таком порядке:

1. Назовите триггер: наблюдаемое событие, после которого процесс начинается.
2. Определите результат: объект или состояние, которое можно проверить.
3. Назначьте владельца результата и перечислите роли участников.
4. Запишите основной маршрут шаг за шагом глаголами: «проверяет», «создаёт», «согласует», «передаёт».
5. Для каждого шага укажите вход, выход, систему и допустимое время ожидания.
6. Добавьте правила и развилки: при каких условиях процесс идёт по другому пути.
7. Отдельно перечислите исключения, ручные обходы и способы восстановления после ошибки.
8. Согласуйте карту со всеми ролями, которые передают работу друг другу.

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

Пример описания процесса обработки заявки

Ниже — сокращённый пример AS IS для входящей заявки. Это не универсальный регламент: значения и правила нужно заменить фактическими данными вашей компании.

Такая таблица быстро обнаруживает разрывы. Например, обращение зарегистрировано на сайте, но координатор узнаёт о нём только из письма; менеджер повторно вводит сведения в CRM; задача создаётся без исходных файлов; клиент не получает подтверждения. Это уже список проверяемых проблем, а не общее пожелание «ускорить продажи».

Как это выглядело в проекте TBI Group

При разработке системы расчёта групповых туров для TBI Group мы не начинали с экранов и кнопок. Сначала вместе с сотрудниками туристической компании разобрали, как менеджер собирает программу поездки, рассчитывает состав группы, размещение, услуги, тарифы, себестоимость и прибыль, запрашивает поставщиков и готовит коммерческое предложение.

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

Этот пример показывает, зачем описание AS IS нужно разработке: оно превращает разговор «сделайте нам систему для туров» в проверяемые сценарии, структуру данных и правила расчёта.

Когда достаточно текста и таблицы

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

Оставайтесь на простом формате, когда:

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

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

Когда нужна BPMN

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

BPMN стоит использовать, если:

• процесс проходит через несколько отделов или организаций;
• есть параллельные действия, ожидания и взаимные сообщения;
• решение зависит от нескольких условий;
• важны таймауты, отмена, повторная попытка и обработка ошибок;
• участвуют CRM, 1С, сайт, почта и другие системы;
• схема станет основой для автоматизированного маршрута или технического задания.

Начинать всё равно нужно не с редактора диаграмм, а с фактов AS IS. BPMN делает логику видимой, но не исправляет неверные исходные данные. Для первой схемы достаточно стартового события, задач, ролей, основных шлюзов и конечных событий; технические детали можно вынести на следующий уровень.

Лайфхак: как получить черновик процесса с помощью ChatGPT

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

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

Используйте такой промпт:

Ты выступаешь как бизнес-аналитик. Ниже дана расшифровка реального процесса. Не додумывай отсутствующие факты. Сначала выдели начало и конечный результат процесса, участников и используемые системы. Затем составь таблицу AS IS: шаг, роль, вход, действие, результат, система, срок ожидания и исключение. Отдельно перечисли противоречия, пропущенные данные и вопросы, которые нужно задать сотрудникам. После этого подготовь черновик BPMN по дорожкам: события, задачи, шлюзы, сообщения и конечные состояния.

Если в используемой версии ChatGPT доступен режим построения диаграмм, попросите визуализировать полученный черновик. В остальных случаях текстовое описание по дорожкам можно перенести в bpmn.io, Camunda Modeler или другой редактор BPMN.

ИИ экономит время на расшифровке и первичной структуре, но не знает, где сотрудник упростил рассказ или забыл редкое исключение. Поэтому проверьте черновик с участниками процесса: пройдите по одному реальному случаю от начала до конца и исправьте всё, что не совпало с фактической работой. Только после этого используйте схему как основу для TO BE и технического задания.

Как найти потери в текущем процессе

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

Чаще всего потери находятся в семи местах:

• ожидание: задача лежит между исполнителями без срока и уведомления;
• двойной ввод: одинаковые данные переносят из формы в таблицу, затем в CRM или 1С;
• лишняя передача: каждый участник пересылает файл, но никто не владеет итогом;
• возврат: работа возвращается из-за неполных данных или неясного критерия готовности;
• ручная проверка: человек сверяет сведения, которые уже есть в другой системе;
• скрытая работа: решение принимается в личной переписке и не попадает в общую историю;
• ручной отчёт: руководитель собирает статусы из нескольких источников вместо чтения событий процесса.

Не вся ручная операция должна исчезнуть. Если решение требует экспертной оценки, автоматизация может собрать контекст, проверить полноту и предложить следующий шаг, а окончательный выбор оставить человеку.

Как перейти от AS IS к TO BE

TO BE — это не та же схема с добавленной CRM. Сначала уберите лишние действия и согласуйте новые правила, затем определите, что должна делать система.

Для каждого найденного разрыва выберите один вариант:

1. Убрать шаг, если он не создаёт ценности и не нужен для контроля.
2. Объединить шаги, если один исполнитель может завершить их без передачи.
3. Стандартизировать вход, если ошибки возникают из-за неполных данных.
4. Автоматизировать повторяемое правило, если вход и результат однозначны.
5. Оставить решение человеку, но дать ему данные, срок и понятный интерфейс.

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

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

Что передать команде разработки

Разработчикам нужна не только диаграмма. Для оценки и реализации подготовьте пакет, в котором есть:

• границы первого контура и то, что в него сознательно не входит;
• роли пользователей, права и владелец результата;
• состояния объекта и разрешённые переходы между ними;
• поля, справочники, документы и источник каждого значения;
• бизнес-правила, формулы и условия развилок;
• основной сценарий, исключения, отмена и повторная обработка;
• интеграции: направление обмена, событие запуска, частота, источник истины и реакция на сбой;
• уведомления, сроки и правила эскалации;
• требования к журналу изменений и отчётности;
• критерии приёмки на конкретных примерах.

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

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

Описывать желаемое вместо реального. Команда подтверждает красивую схему, которая не совпадает с ежедневной работой. Сначала фиксируйте AS IS, потом проектируйте изменения.

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

Начинать со всей компании. Большая карта долго согласуется и не даёт быстрого рабочего контура. Выберите один процесс с ясным результатом.

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

Выбирать систему до правил. Название CRM или BPM-платформы не определяет владельца данных, переходы, права и критерии результата.

Автоматизировать лишний шаг. Если согласование никому не нужно, не стоит сначала программировать его, а потом оптимизировать.

Не назначать владельца процесса. Без человека, принимающего решение по спорным правилам, требования остаются противоречивыми.

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

• Названы наблюдаемые начало и конец процесса.
• Есть один владелец конечного результата.
• Интервью проведены с руководителем и фактическими исполнителями.
• Основной маршрут AS IS проверен на реальном примере.
• Для каждого шага указаны роль, вход, действие, результат и система.
• Записаны сроки ожидания, правила, развилки и исключения.
• Найдены двойной ввод, ручные переносы, возвраты и потерянные передачи.
• Согласовано, что нужно убрать или изменить до автоматизации.
• Описана модель TO BE и ответственность каждой системы.
• Определены показатели, которые сравниваются до и после внедрения.
• Сформулированы интеграции, права, журналирование и реакция на сбой.
• Критерии приёмки проверяют конкретное поведение системы.

Если на несколько пунктов нет ответа, это не повод останавливать проект. Это список вопросов для короткого обследования до оценки разработки.

Что делать дальше

Возьмите один недавний случай и заполните таблицу AS IS вместе с теми, кто реально выполнял работу. Не обсуждайте пока интерфейс и технологии. Сначала согласуйте границы, результат, правила и исключения; затем соберите TO BE и только после этого выбирайте способ реализации.

Если процесс проходит через сайт, CRM, 1С, почту и ручные таблицы, посмотрите, как мы подходим к автоматизации бизнес-процессов — от обследования до первого рабочего контура. Практический пример такого маршрута есть в кейсе ТехАрматуры: там до интеграции были описаны процессы, источники данных и ручные переходы между системами.

---

Теги: Бизнес-процессы, Автоматизация, Внедрение, CRM, IT-консалтинг Дата публикации: 9 июля 2026