ТЗ на автоматизацию бизнес-процесса: границы, роли и приёмка

ТЗ должно описывать работу, а не кнопки платформы

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

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

Мини-шаблон требования и проверка на примере

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

• Пример: «После отправки формы услуга и контакт сохраняются с идентификатором события. Заявка с тем же идентификатором при повторной доставке не создаётся заново. Если услуга относится к группе A, назначается ответственный A; если он недоступен, назначается резервный B. Клиент получает подтверждение, а руководитель видит запись без владельца до её назначения». Такой пункт уже можно разложить на тесты.
• Создайте тестовые случаи: полный вход, неполный вход, дубль, неизвестная категория, отсутствующий сотрудник, отказ CRM, повтор события, просрочка и ручное переназначение. Для каждого укажите ожидаемый статус, получателя уведомления, запись в журнале и условие завершения. Если нельзя указать результат, правило ещё не согласовано.
• Разделите приёмку на функциональную, операционную и доступную. Функциональная проверяет переходы; операционная — восстановление после отказа и поиск зависших случаев; доступная — возможность сотрудников и клиентов выполнить действия с клавиатуры и понятными сообщениями об ошибке. Пилот проводите на ограниченном канале или подразделении с возможностью ручного отката.
• Опишите ответственность за изменение процесса после запуска: кто редактирует правила, кто утверждает новые состояния, как сохраняются версии и как обучают сотрудников. Жёстко зашитый маршрут может работать сегодня и стать неверным после перестройки отдела; документация и процедура изменения — часть результата проекта.

Исследуйте фактический процесс

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

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

Как формулировать требования к целевому процессу

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

• Вход и проверка. Опишите все каналы поступления: форма, письмо, мессенджер, API или ручной ввод. Укажите обязательные поля, правило определения дубля, источник и время поступления. Если вход неполон, система не должна молча терять случай: нужен статус уточнения и владелец, который видит очередь.
• Маршрутизация. Запишите условия назначения исполнителя и их приоритет. Что происходит, если сотрудник отсутствует, команда перегружена или категория не распознана? Правило должно давать определённый результат и позволять ручное переназначение с причиной. Для важных случаев сохраните след, почему система выбрала конкретного владельца.
• Состояния. Назовите минимальный набор состояний и разрешённые переходы: получено, назначено, в работе, ожидает клиента, выполнено, закрыто или отменено — только если они действительно нужны. Для каждого перехода укажите, кто его делает и какое доказательство требуется. Статус «выполнено» без фактического результата не должен закрывать задачу.
• Время и уведомления. Для каждого обещанного срока укажите точку начала, рабочий календарь, паузы, предупреждения и эскалацию. Если дело ожидает клиента, решите, останавливается ли отсчёт. Уведомление должно вести к действию и не раскрывать лишние данные; успешная отправка письма ещё не означает, что задача принята исполнителем.
• Интеграции. Для CRM, ERP, почты и внешнего сервиса укажите сущности, направление, идентификаторы, формат ошибок и повторную доставку. Событие может прийти повторно или не по порядку; обработка должна быть идемпотентной там, где создаются записи. Синхронизация должна позволять найти зависшие и расходящиеся случаи, а не только считать успешные запросы.
• Исключения и ручной контроль. Опишите отмену, исправление неверных данных, дубли, временный отказ API и конфликт двух решений. У каждого исключения должен быть владелец, видимый статус и способ восстановить нормальный путь. Автоматическое повторение допустимо лишь там, где действие безопасно повторять и не создаёт новую заявку или платёж.
• Отчётность и журнал. События процесса должны отвечать на вопросы: где случай сейчас, кто ответственный, сколько он ждёт и почему завершён. Запишите права на отчёты и правила очистки данных. Не собирайте показатели только ради красивого дашборда; у каждого измерения должен быть управленческий вопрос и известный источник.

Что мерить в пилоте

Показатели должны отражать результат процесса, а не только активность новой системы.

• Время от входного события до принятия назначенным исполнителем и до завершения полезного действия.
• Доля случаев без владельца, число дублей и количество переходов, которые пришлось исправить вручную.
• Размер и возраст очереди ошибок внешних систем, время обнаружения и восстановления после отказа.
• Качество результата по выборке: клиент получил ответ, заказ прошёл, документ согласован. Сравнивайте с исходным периодом и учитывайте изменение объёма входящих.

Из-за чего автоматизация не помогает

Обычно проблема не в самой платформе, а в невидимых решениях, которые оставили ей на усмотрение.

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

Документ, с которым можно начинать пилот

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

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

Один процесс — несколько обязательных испытаний

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

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

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

Для интеграции укажите не только endpoint, но и операционный сценарий отказа. Что произойдёт, если CRM недоступна десять минут, сообщение пришло повторно или ответ системы потерялся после успешной записи? Нужны устойчивый идентификатор, безопасный повтор, очередь с возрастом и назначенный человек, который может разобрать расхождение. Отчёт «успешно отправлено» сам по себе не доказывает, что другая сторона приняла работу. Сверка контрольных случаев должна входить в приёмку пилота.

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