Компания часто начинает выбор CRM или ERP с таблицы на сотни функций: карточка клиента, склад, отчёты, интеграции, мобильный доступ. Поставщики ставят отметки «есть», но после запуска заказ проходит не по правилам бизнеса, остатки обновляются с задержкой, а руководитель не получает нужного решения.
Функция без сценария ничего не гарантирует. Техническое задание должно описывать, кто выполняет действие, с какими данными, по какому правилу, что происходит при исключении и какой результат считается правильным.
От бизнес-боли к проверяемому требованию
| Слабая формулировка | Рабочее требование | Критерий приёмки |
|---|---|---|
| Нужен контроль заявок | Каждая заявка с сайта, телефона и мессенджера создаёт запись с источником и ответственным | Тестовые обращения из трёх каналов появились без дублей |
| Нужен склад | Менеджер видит физический, зарезервированный и доступный остаток по складу | После резерва доступность уменьшилась, физический остаток не изменился |
| Нужны отчёты | Собственник видит маржинальный доход по товару, клиенту и каналу | Итог раскрывается до исходных заказов и затрат |
| Нужны права | Менеджер изменяет свои сделки, руководитель видит отдел | Негативный тест подтвердил запрет чужих записей |
Такая формулировка позволяет сравнить решения и проверить результат. Ответа «у нас есть складской модуль» уже недостаточно.
Структура технического задания
- Цель проекта. Измеримые проблемы: потери заявок, ошибки остатков, время подготовки отчёта.
- Границы первого этапа. Что входит в запуск и что сознательно отложено.
- Роли. Кто создаёт, согласует, выполняет, контролирует и исправляет данные.
- Сценарии. Нормальный путь операции и важные исключения.
- Данные. Справочники, обязательные поля, источники, владельцы качества и история.
- Интеграции. Система-источник и поведение при ошибке обмена.
- Отчёты и контроль. Решение, которое принимается по каждому показателю.
- Критерии приёмки. Конкретные тесты, ожидаемый результат и ответственный.
Описывайте процесс через события
Вместо абстрактного «вести продажи» зафиксируйте последовательность: обращение получено → дубль проверен → ответственный назначен → потребность уточнена → предложение сформировано → товар зарезервирован → оплата получена → отгрузка создана.
Для каждого события определите вход, результат и правило перехода. Если клиент превысил кредитный лимит или товара недостаточно, система не должна молча двигать сделку дальше.
| Элемент сценария | Вопрос для ТЗ |
|---|---|
| Триггер | Какое событие запускает действие? |
| Владелец | Кто отвечает за результат и срок? |
| Входные данные | Что должно быть известно до выполнения? |
| Правило | При каких условиях действие разрешено или запрещено? |
| Результат | Какой документ, статус или движение создаётся? |
| Исключение | Что делать, если данных нет или сервис недоступен? |
Зафиксируйте источник истины
Клиенты могут существовать в CRM, товары — на сайте, остатки — в учётной системе, а платежи — в банке. Для каждой сущности определите владельца: где запись создаётся, где изменяется и кто решает конфликт.
Без этого интеграция создаст взаимное перезаписывание. Исправленное имя клиента вернётся из старой системы, а менеджер и сайт увидят разные остатки.
Отделите обязательное от желательного
| Приоритет | Значение | Пример |
|---|---|---|
| Обязательно для запуска | Без требования процесс или контроль не работает | Уникальность номера заказа и резерв товара |
| Нужно на первом этапе | Даёт основную пользу, но имеет временный обход | Автоматическое напоминание о просроченной оплате |
| Следующий этап | Расширяет уже стабильный процесс | Прогноз повторной покупки |
| Не входит | Сознательно исключено из проекта | Полная замена бухгалтерской системы |
Приоритет не должен означать «всё критично». Если каждое требование получает высший уровень, команда не сможет собрать управляемый первый запуск.
Критерий приёмки сильнее описания
Для ключевых сценариев создайте тестовые данные и ожидаемый результат. Проверяйте дубль клиента, недостаточный остаток, отмену, повторное событие интеграции и запрещённое действие роли, а не только идеальный путь.
Фраза «работает корректно» не является критерием. Должно быть понятно, какая запись создана, какой статус изменился, что попало в журнал и какой итог показал отчёт.
Типичные ошибки ТЗ
- копирование функций из рекламной презентации;
- описание только идеального процесса;
- отсутствие владельца данных и правил дублей;
- попытка включить все отделы в один запуск;
- смешение требования с дизайном конкретной кнопки;
- отсутствие тестов и границ ответственности.
Вывод
Техническое задание на CRM/ERP должно связывать бизнес-цель, событие, роль, данные, правило, результат и проверку. Тогда документ становится основой для оценки, настройки, разработки и приёмки, а не списком пожеланий.
После согласования требований следующий риск — перенос старых дублей, ошибочных справочников и неверных начальных остатков в новую систему. Посмотреть ядро Business Reactor.
