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