Техническое задание на автоматизацию: структура без лишней бюрократии

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

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

Контекст и цель

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

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

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

Границы работ

ТЗ должно прямо отвечать, что входит и что не входит в проект. Это защищает обе стороны от разных ожиданий.

Укажите:

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

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

Роли и права доступа

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

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

Сценарии процесса

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

Карточка этапа

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

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

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

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

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

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

Отчёты и контроль

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

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

Критерии приёмки

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

Пример структуры:

1. Пользователь с заданной ролью создаёт карточку.
2. Без обязательного поля переход недоступен.
3. После заполнения карточка попадает ответственному подразделению.
4. При возврате сохраняется причина и инициатор получает уведомление.
5. Руководитель видит карточку в согласованном отчёте.

Это не описание конкретной реализации, а формат проверки. Реальные роли, поля и переходы подставляются из проекта.

Изменения после согласования

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

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

Чек-лист качественного ТЗ

• Есть деловая цель и проверяемые критерии.
• Границы работ перечислены явно.
• Описаны роли и ограничения доступа.
• Основной маршрут дополнен исключениями.
• У каждого поля есть назначение и источник.
• Интеграции описывают ошибки и повторную обработку.
• Отчёты связаны с реальными вопросами руководителя.
• Приёмка состоит из воспроизводимых сценариев.
• Зафиксирован порядок управления изменениями.
• Определено, кто поддерживает процесс после запуска.

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