Как описать бизнес-процесс перед автоматизацией

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

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

Автоматизировать нужно не отдельную операцию, а управляемый процесс с понятными входными данными, ответственными, правилами и результатом.

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

Заказчик часто формулирует задачу коротко: внедрить CRM, сделать личный кабинет, настроить обработку заявок или связать сайт с учётной системой. Для разработчика этого недостаточно. Одна и та же формулировка может означать разные сценарии, роли пользователей, правила расчёта и требования к интеграциям.

Например, интернет-магазину нужно автоматизировать обработку заказа. В одном бизнесе заказ после оплаты сразу передаётся на склад. В другом менеджер сначала проверяет наличие, уточняет характеристики товара, согласовывает доставку и только потом переводит заявку в работу. Техническое решение для этих компаний будет разным.

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

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

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

С какого процесса начать автоматизацию

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

Для выбора используйте четыре критерия:

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

Полезно составить предварительную таблицу и оценить процессы по шкале от 1 до 5. Например, обработка заявок получила 5 баллов за частоту, 4 за стоимость ошибки, 4 за количество участников и 5 за ручной труд. Такой процесс обычно лучше подходит для первого этапа, чем редкая внутренняя операция с небольшим влиянием на результат.

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

Какие вопросы задать участникам процесса

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

Проведите короткие интервью с участниками процесса. Для типового отдела достаточно 30-60 минут на одного человека. Задавайте вопросы не о том, как должно быть в идеале, а о том, что происходило в последних реальных случаях.

Вопросы о начале процесса

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

Вопросы о действиях

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

Вопросы о завершении

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

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

Как зафиксировать процесс простым языком

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

• Название, например «обработка заявки на расчёт ремонта».
• Цель, какой измеримый результат должен появиться.
• Начало, событие, после которого запускается работа.
• Конец, событие, которое означает завершение.
• Участники, должности или роли, без привязки к конкретным фамилиям.
• Входные данные, документы, сообщения, файлы и сведения от клиента.
• Результат, заявка, расчёт, договор, отгрузка или другой итог.
• Правила, условия выбора следующего шага.
• Проблемы, задержки, ошибки и повторяющиеся ручные операции.

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

Для каждого шага зафиксируйте пять элементов:

1. кто выполняет действие;
2. что именно он делает;
3. какие данные использует;
4. какой результат получает;
5. что запускается дальше.

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

Как описать процесс в текущем и целевом виде

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

Текущее состояние

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

Для каждого шага полезно отметить примерную длительность и частоту. В типичном проекте достаточно диапазонов: до 5 минут, 5-15 минут, 15-30 минут, больше 30 минут. Если точных измерений нет, не выдавайте предположение за факт. Запишите оценку сотрудника и позже проверьте её на нескольких реальных операциях.

Целевое состояние

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

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

Разницу между текущей и целевой схемой удобно оформлять таблицей:

Как описать роли, правила и исключения

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

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

Затем зафиксируйте правила в формате «если, то». Например:

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

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

Какие исключения нужно проверить

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

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

Какие данные и интеграции нужно определить заранее

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

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

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

Интеграции

Для каждой интеграции ответьте на вопросы:

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

Связка сайта с CRM, телефонией, почтой, оплатой, доставкой или учётной системой может заметно изменить объём проекта. Поэтому интеграцию нужно описывать не названием сервиса, а конкретным сценарием обмена. Если требуется изменить уже работающий сайт, сначала зафиксируйте ограничения текущей системы и только потом планируйте доработку сайта.

Как оценить эффект и понять, что автоматизация удалась

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

Не обязательно проводить сложное исследование. В типичном проекте можно в течение 1-2 недель выбрать несколько десятков операций и записать фактические значения. Если операций мало, используйте данные за последний месяц и отдельно отметьте сезонные особенности.

Примеры измеримых целей:

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

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

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

Как превратить описание в техническое задание

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

Чтобы передать задачу подрядчику без потери смысла, приложите к каждому этапу:

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

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

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

Типичные ошибки при описании бизнес-процесса

Описывают идеальную картину

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

Начинают с функций программы

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

Не назначают владельца процесса

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

Игнорируют исключения

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

Не учитывают изменения после запуска

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

Сразу хотят автоматизировать всё

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

Сколько времени занимает описание и от чего зависит стоимость

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

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

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

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

Можно ли автоматизировать процесс без схемы?

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

Кто должен описывать процесс, руководитель или сотрудники?

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

Нужно ли рисовать специальную схему?

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

Что делать, если сотрудники описывают один процесс по-разному?

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

Как понять, что процесс уже достаточно описан?

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

Нужно ли описывать процесс для продвижения сайта?

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

Что делать: короткий план

1. Выберите один процесс с заметным влиянием на выручку, скорость или качество обслуживания.
2. Назначьте владельца процесса и пригласите сотрудников, которые выполняют его на практике.
3. Зафиксируйте начало, конец, участников, входные данные и ожидаемый результат.
4. Опишите текущие шаги по порядку, включая таблицы, чаты, ручной ввод и проверки.
5. Соберите частые исключения: отмены, возвраты, неполные данные, дубли и просрочки.
6. Разделите действия человека и действия, которые должна выполнять система.
7. Сформулируйте целевой процесс и измеримые критерии результата.
8. Проверьте поля, роли, статусы, уведомления, интеграции и правила доступа.
9. Передайте описание подрядчику для оценки вариантов реализации и сроков.
10. Согласуйте первый этап, сценарии тестирования и порядок дальнейших изменений.

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