Структура ТЗ на ERP которое защитит бюджет и сроки. Что обязательно включить, типичные ошибки и шаблон разделов.
Техническое задание — документ который определяет что именно разрабатывается, в каком объёме и по каким критериям принимается работа. Хорошее ТЗ экономит 30–50% бюджета. Плохое или отсутствующее ТЗ — главная причина срыва сроков, перерасхода бюджета и споров с разработчиком.
Зачем нужно ТЗ: что бывает без него
- Разработчик понимает задачу по-своему — переделки за ваш счёт
- Непонятно что входит в проект, а что «дополнительные работы»
- Нет критериев приёмки — как понять что работа сделана?
- Споры о том «договаривались ли» на тот или иной функционал
- Стоимость растёт по мере разработки из-за «уточнений»
Структура ТЗ на ERP систему
1. Общее описание проекта
Кто заказчик, чем занимается бизнес, цель автоматизации, ключевые пользователи системы. Даёт разработчику контекст.
2. Описание бизнес-процессов
Как работают процессы сейчас и как должны работать в новой системе. Это самый важный раздел. Для каждого процесса: триггер (что запускает), участники, шаги, результат.
3. Функциональные требования
Список конкретных функций разбитый по модулям. Каждая функция описывается через пользовательские истории: «Менеджер может создать сделку и привязать к ней контакт, файлы и задачи». Не «нужна CRM», а конкретные действия которые должна выполнять система.
4. Нефункциональные требования
Производительность (страница загружается менее чем за 2 секунды), доступность (99.5% uptime), безопасность (роли доступа, шифрование), масштабируемость.
5. Интеграции
С какими системами нужна интеграция, какие данные передаются в каком направлении, через какие форматы (API, EDI, файлы).
6. Пользовательские роли
Какие роли будут в системе (администратор, менеджер, склад, бухгалтер, директор), к чему у каждой роли есть доступ.
7. Требования к данным и миграции
Откуда переносятся данные, в каком объёме, в каком формате. Какие данные мигрируют, какие остаются только для чтения в старой системе.
8. Критерии приёмки
По каким критериям работа считается выполненной? Функциональные тесты, нагрузочное тестирование, прохождение обучения пользователями.
Типичные ошибки в ТЗ на ERP
- «Система должна быть удобной» — неизмеримо. Пишите конкретно: «все операции выполняются не более чем за 3 клика».
- Описание интерфейса вместо функций — как выглядит менее важно чем что делает.
- Отсутствие приоритетов — что нужно в первой версии, что может подождать?
- «Как в 1С» — разработчик не знает «как у вас в 1С». Описывайте логику словами.
- Описание только «хорошего пути» — что происходит при ошибках, отказах, исключениях?
Кто должен писать ТЗ
Лучший вариант — аналитик разработчика вместе с вашими ключевыми пользователями. Аналитик знает как формализовать требования, ваши сотрудники знают реальные процессы. Написать ТЗ самостоятельно без опыта — риск упустить критические детали.
Мы проводим бесплатную предпроектную консультацию: разбираем ваши процессы, задаём правильные вопросы и помогаем сформулировать требования. Записаться →
Часто задаваемые вопросы
Кто платит за составление ТЗ?+
Обычно предпроектная аналитика оплачивается отдельно — 50–200 тыс. рублей в зависимости от объёма. Многие студии делают базовую консультацию бесплатно. Хорошее ТЗ окупается снижением стоимости разработки.
Как подробным должно быть ТЗ?+
Настолько подробным чтобы незнакомый разработчик мог реализовать систему без дополнительных вопросов. На практике: 20–50 страниц для небольшой CRM, 80–150 страниц для полноценной ERP.
Что делать если требования меняются в процессе разработки?+
Изменения фиксируются письменно и оцениваются отдельно. Это нормально — бизнес развивается. Важно чтобы изменения были запроцессированы, а не добавлялись устно.
Можно ли начать разработку без полного ТЗ?+
Да — в Agile-подходе разработка начинается с базового описания и уточняется итерациями. Но это требует высокой вовлечённости клиента и договора в формате T&M. Не подходит если нужна фиксированная цена.
Насколько важно описывать интерфейс в ТЗ?+
Прототипы и wireframes в ТЗ значительно снижают риск расхождения ожиданий. Можно использовать простые схемы в Figma или даже на бумаге — не обязательно детальный дизайн.
Нужно ли указывать технический стек в ТЗ?+
Функциональные требования — да, технический стек — обычно нет: это зона ответственности разработчика. Если у вас есть требования к стеку (например, только open-source), укажите их в нефункциональных требованиях.