Техническое задание на ERP: как написать чтобы не пожалеть

📅 9 июля 2025 г.⏱ 10 мин чтения

Структура ТЗ на 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), укажите их в нефункциональных требованиях.