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

Зачем в ТЗ подробно описывать роли, данные и интеграции

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

Хорошее ТЗ на автоматизацию бизнес-процесса делает объем проверяемым. Должно быть ясно, где начинается и где заканчивается работа, что входит в поставку, а что является риском или отдельной задачей. Прозрачность нужна не для формальности, а чтобы потом не спорить на встречах про «мы это имели в виду».

Чаще всего сроки растут из-за того, что в ТЗ недоописаны три вещи: роли и права (кто что может делать), данные (какие объекты и поля нужны), интеграции (что с чем обменивается и как живет при сбоях). Даже один пропущенный участник процесса, например бухгалтерия или служба безопасности, может добавить новые статусы, документы и проверки.

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

Пример: «согласование заявки» выглядит коротко, пока не выяснится, что часть заявок уходит в ERP, часть в закупки, а доступ к суммам видят только отдельные роли. Без этих деталей оценка превращается в гадание.

Фиксируем цель и границы автоматизации

Цель автоматизации стоит описать одним понятным абзацем: что именно станет проще, быстрее или безопаснее, и для кого. Хорошая цель звучит как измеримое улучшение, а не как «сделать систему». Например: «Сократить время согласования заявки на закупку оборудования для ИТ и бухгалтерии с 5 дней до 2, убрать ручные переписки и сделать статус видимым всем участникам».

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

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

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

Роли и права: кто участвует и что может делать

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

Обычно хватает 4-6 ролей. Важно не забыть крайние случаи: внешнего участника (контрагент, аудитор, сотрудник другого юрлица с ограниченным доступом) и системные роли.

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

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

Не забывайте сценарии «без человека»: системная роль (например, «Сервис интеграции»), задания по расписанию (закрыть просроченные заявки) и автоматическое заполнение реквизитов или отправка уведомлений. В проектах по автоматизации такие вещи часто дают заметную часть объема.

Данные: какие объекты и поля должны быть в системе

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

Начните с основных объектов (сущностей): заявки, договоры, контрагенты, товары и услуги. Для каждого объекта зафиксируйте, где он появляется в процессе и кто за него отвечает: создает, проверяет, согласует, исправляет.

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

Для каждого поля обычно достаточно кратко указать:

• обязательное или нет, и правило, когда становится обязательным
• тип данных, формат и длину (например, ИИН 12 цифр)
• допустимые значения или диапазоны (например, сумма больше 0)
• источник (пользователь, справочник, интеграция) и кто может менять
• что делать при пустом или неверном значении

Отдельно опишите справочники и классификаторы: кто ведет (например, отдел закупок), как часто обновляет, кто утверждает изменения. Если справочник приходит извне, запишите, что считается истиной при расхождениях.

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

Сценарии и исключения: как процесс ведет себя в реальности

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

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

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

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

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

По уведомлениям уточните: кому именно они нужны (инициатору, согласующим, исполнителю), когда отправлять (сразу, за день до дедлайна), и что делать, если человек недоступен (замена, эскалация).

Интеграции: что обменивается и как обрабатываются сбои

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

Для каждой интеграции важно описать не просто «есть обмен», а проверяемую конкретику.

Что фиксировать по каждой интеграции

Удобно использовать одинаковую карточку для каждого обмена:

• что отправляем и что получаем (с примерами 2-3 полей)
• формат и протокол (JSON, XML, CSV, файл, API)
• режим и частота (онлайн, пакетно, по расписанию, вручную по кнопке)
• идентификаторы и сопоставление (какое поле ключ, что делать при дублях)
• требования к безопасности (кто имеет доступ, как храним токены или ключи)

Пример: при создании заявки система запрашивает из каталога ФИО и подразделение по табельному номеру, а в ЭДО отправляет номер заявки, инициатора и файл для подписи. Если в ЭДО пришел статус «отклонено», заявка возвращается на доработку с комментарием.

Как обрабатывать сбои

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

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

Нефункциональные требования, которые влияют на оценку

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

Сначала определите нагрузку. Нужны цифры: сколько активных пользователей одновременно, сколько заявок или операций в день, какие действия самые частые (поиск, согласование, загрузка документов). От этого зависят архитектура, оптимизация и тестирование.

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

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

Минимум, который стоит зафиксировать:

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

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

Интерфейсы, отчеты и документы: что именно делаем для людей

Важно описать не только логику, но и то, что увидит человек: экраны, отчеты, печатные формы. Эти «видимые» части часто занимают больше времени, чем ожидают.

Экраны и формы

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

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

Отчеты, выгрузки и печатные формы

Отчет - это не просто таблица. Укажите показатели, периодичность, формат и кто имеет право видеть данные. Если нужен экспорт, уточните, как он запускается: вручную по кнопке или по расписанию.

По печатным формам зафиксируйте, когда они нужны (например, служебная записка или заявка на закупку оборудования), кто утверждает шаблон, какие реквизиты обязательны и что делаем, если шаблон меняется после запуска.

Как собрать ТЗ: пошаговый план на 1-2 недели

Чтобы ТЗ не превратилось в набор общих пожеланий, собирайте его короткими циклами: уточнили, записали, проверили на реальных кейсах, снова уточнили. Так быстрее видно, где «дыры» и что сильнее всего влияет на объем.

За 1-2 недели обычно хватает такого плана:

• согласовать границы процесса и список участников: где начинается заявка, где заканчивается, кто владелец результата, какие отделы затрагиваем
• описать основной сценарий и частые отклонения: 5-10 альтернатив, которые реально происходят (возврат на доработку, замена исполнителя, срочный режим)
• зафиксировать роли и права: кто создает, кто согласует, кто видит финансовые поля, кто может отменить или изменить статус
• описать данные простыми таблицами: сущности (Заявка, Договор, Контрагент), обязательные поля, справочники, примеры значений и кто их заполняет
• перечислить интеграции и сбои: какие системы участвуют, что передаем, что делаем при ошибке (повтор, ручная обработка, уведомление)

После этого договоритесь о формате приемки. Например: «Заявка проходит 6 статусов, логируются все решения, отчет по просроченным согласованиям формируется за 1 минуту, ошибки интеграций видны ответственному». Если вы работаете с интегратором (например, GSE.kz), такие критерии помогают сверить ожидания и оценку еще до разработки.

Как сделать оценку объема точной и проверяемой

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

Удобный подход: сначала фиксируйте блок (интерфейсы, логика, данные, интеграции), а затем описывайте измеримые элементы. Вместо «сделать форму заявки» пишите, сколько экранов, какие поля, какие проверки и какие роли могут редактировать.

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

• экраны и состояния: сколько страниц и вариантов (создание, просмотр, редактирование)
• поля и правила: обязательность, форматы, вычисления, автозаполнение
• сценарии: основной путь плюс 2-3 исключения и ошибки
• обмены: сколько интеграций и операций (отправить, получить, сверить)
• отчеты и документы: количество шаблонов и параметров

Отдельно зафиксируйте риски и допущения. Риск - это неизвестность (например, внешний сервис не дает тестовый доступ). Допущение - то, что вы считаете известным (например, справочник подразделений уже чистый и актуальный).

Чтобы оценка оставалась проверяемой при изменениях, договоритесь о простом правиле:

• любое новое требование оформляется как отдельный пункт
• к пункту добавляются измеримые единицы и причина
• оценка пересчитывается только для затронутых блоков
• версия ТЗ и дата изменения фиксируются в конце документа

Частые ошибки в ТЗ и как их заранее поймать

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

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

Роли часто перечисляют, но не доводят до проверяемых прав. Например, «Менеджер» есть, а что он может: создавать, редактировать, отменять, видеть чужие заявки, запускать согласование? Если это не прописано, на приемке всплывают конфликтные ожидания.

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

Быстрая проверка перед согласованием:

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

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

Быстрый чеклист перед согласованием ТЗ

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

Проверка занимает 20-30 минут, если смотреть на ТЗ как на набор проверяемых обещаний, а не как на «описание процесса».

Минимум, который должен сходиться у всех

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

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

Пример: ТЗ для процесса согласования заявки, без сложной терминологии

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

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

Данные удобнее перечислить как объекты и ключевые поля. Например: «Заявка» (номер, филиал, сумма, статус, бюджетный код, комментарий), «Позиции» (наименование, количество, цена), «Контрагент» (БИН, название), «Вложения» (тип, файл, кто добавил).

Исключения фиксируются как короткие правила: если бюджета нет, заявка уходит в статус «Отклонена» с причиной; если контрагент не найден, закупки создают запрос на добавление; если руководитель возвращает, инициатор правит и отправляет повторно.

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

Такое ТЗ помогает оценке: можно посчитать экраны (создание, согласование, список, карточка), правила (лимиты, статусы), обмены (3 интеграции) и отчеты (например, «Заявки по филиалам и статусам»).

Следующие шаги: как превратить ТЗ в план работ и запуск

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

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

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

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

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