Содержание
Константин Степанов CEO & Founder BPA Develop · в IT с 2007 года · более 50 подготовленных ТЗ на разработку ERP Май 2025 24 мин. чтения
Картина типовая: руководитель приходит к разработчику с фразой «нам нужна ERP, давайте начинать». Стороны жмут руки, подписывают договор по укрупнённой оценке, команда приступает к работе. Через шесть месяцев выясняется, что складской модуль не учитывает приёмку по партиям, финансовый блок не понимает многофирменную структуру с пятью юрлицами, а интеграций с банковским клиентом и Честным ЗНАКОМ нет вообще, потому что про них «само собой разумеется» забыли.
Бюджет уже потрачен на 80%, сроки сдвинуты на квартал, команда заказчика разочарована и саботирует приёмку. В девяти случаях из десяти причина одна: нормального технического задания не было.
Техническое задание на разработку ERP — это не бюрократический документ ради документа и не формальность для договора. Это инструмент, который защищает бизнес заказчика и даёт разработчику точные ориентиры. Без него разработка ERP превращается в дорогую игру в угадайку, где ставки исчисляются миллионами рублей. В этой статье разберём, что должно быть в ТЗ, как оно готовится, кто за что отвечает и каких ошибок стоит избегать.
Что такое техническое задание на разработку ERP и зачем оно нужно
Техническое задание (ТЗ) на разработку ERP — это документ, в котором зафиксированы все требования к будущей системе: какие функции она должна выполнять, как должна работать, с какими внешними системами обмениваться данными, кто будет ею пользоваться, на какой инфраструктуре развёртываться. По сути ТЗ переводит бизнес-задачи компании в техническую плоскость и фиксирует договорённости между заказчиком и разработчиком в одном документе.
ТЗ нужно при любой кастомной разработке, но в случае ERP его роль становится критической. Вот почему:
ERP охватывает несколько бизнес-блоков одновременно. Финансы, склад, производство, HR, закупки, продажи — все эти модули связаны общими справочниками, единым учётом, сквозными процессами. Ошибка в проектировании одного модуля ломает логику соседних. Например, если в проектировании склада не учтена работа с партиями и сроками годности, страдают и закупки, и продажи.
Разработка ERP длится от 6 до 24 месяцев. За это время бизнес заказчика меняется: открываются новые направления, приходят новые требования, уходят сотрудники, которые описывали процессы. Без зафиксированной базовой версии каждое изменение превращается в спор: «это входило в объём» или «это новый функционал».
Стоимость разработки начинается от 750 000 рублей и легко доходит до 10–20 миллионов на крупных проектах. При таких суммах разбираться «по ходу дела» обходится в разы дороже, чем потратить 3–6 недель на качественную предпроектную работу.
Главная мысль: ТЗ защищает обе стороны. Заказчик, который согласовал и подписал документ, точно знает, что он получит. Разработчик, у которого на руках утверждённое ТЗ, не может сдать «что-то похожее» вместо заказанного. И что важнее всего, обе стороны заранее видят границы проекта и могут договариваться по факту изменений, а не на эмоциях в конце.
Что будет, если разрабатывать ERP без технического задания
Теоретически можно начать разработку с минимальным брифом, договориться «дорабатывать по ходу» и идти итерациями. На практике в проектах от полумиллиона рублей это превращается в набор предсказуемых проблем.
1 | Неопределённый бюджет и сроки Без детального ТЗ невозможно дать обоснованную оценку трудозатрат. Разработчик называет вилку, которая может отличаться в 2–3 раза от финального счёта. Каждое новое требование добавляет время и деньги. В итоге проект, обещанный за 4 миллиона и 9 месяцев, заканчивается на 8 миллионах и через 16 месяцев. |
2 | Ошибки в архитектуре системы ERP — система со множеством взаимосвязей. Если архитектура спроектирована без понимания полной картины требований, переделка фундаментального модуля на поздних стадиях обходится в 3–5 раз дороже, чем правильное проектирование изначально. |
3 | Система делается, но не для тех пользователей Разработчик проектирует интерфейс исходя из своих предположений о работе бизнеса. В результате кладовщик получает экран, который удобен программисту, но не ему: 18 полей вместо 4. Это прямая дорога к саботажу при внедрении. Сотрудники продолжают вести параллельный учёт в Excel. |
4 | Интеграции, о которых «забыли» Интеграция с 1С:Бухгалтерией, банковским API, ЕГАИС, Честным ЗНАКОМ, CRM, телефонией. Если они не зафиксированы в ТЗ, разработчик не закладывает их в оценку. На финальной стадии они добавляются как «дополнительные работы» — часто 20–30% от изначального бюджета. |
5 | Нет критериев приёмки Без ТЗ заказчик и разработчик по-разному понимают, что значит «готово». Разработчик считает: модуль работает, баги исправили, сдаём. Заказчик считает: работает не так, как ожидали, переделывайте. Спор затягивает проект на месяцы и часто заканчивается претензиями и юристами. |
Из практики BPA Develop: к нам регулярно приходят компании, которые уже обожглись на разработке без ТЗ. Типичная история: потратили 1,5–2 миллиона рублей, получили систему, закрывающую 60% реальных потребностей, и пришли за переработкой. В большинстве случаев переделать дороже, чем сделать заново с нуля и с нормальным техническим заданием. Это самая обидная статья расходов в IT-бюджете: деньги, потраченные дважды на одну и ту же задачу.
Структура технического задания на разработку ERP
Хорошее ТЗ — это не набор разрозненных требований, а структурированный документ с предсказуемой логикой. Разберём по разделам, что и зачем должно быть в каждом из них.
1. Введение и цели проекта
В этом разделе фиксируется контекст: чем занимается компания, какие системы использует сейчас, почему текущие инструменты перестали устраивать, какого результата ждёт от новой системы.
Главное здесь — цели проекта. Их нужно формулировать измеримо. «Автоматизировать бизнес-процессы» — не цель, а лозунг. Цели должны звучать иначе:
«сократить время обработки заказа от приёма до отгрузки с 4 часов до 30 минут»
«объединить учёт по трём юридическим лицам в единой системе с консолидированной отчётностью»
«уменьшить количество ошибок при инвентаризации в 5 раз за счёт работы со штрихкодами»
Размытые цели в начале ТЗ дают размытые результаты на выходе. Если цели измеримы, на этапе приёмки можно объективно проверить, достигнуты ли они. Если нет, любая претензия превращается в спор о вкусах.
2. Описание текущих бизнес-процессов («как есть»)
Раздел, который заказчики чаще всего хотят пропустить. И зря: именно его пропуск приводит к 80% проблем на проекте.
Что нужно описать:
Какие системы используются сейчас (1С, Excel, самописные решения, внешние SaaS)
Как передаётся информация между отделами и где теряется
Где возникают узкие места: ручной труд, ошибки, задержки
Какие отчёты формируются вручную и сколько времени это занимает
Разработчик не знает вашего бизнеса. Без описания «как есть» новая система проектируется под абстрактный бизнес, а не под конкретный. Полезный совет: не пытайтесь описать процессы самостоятельно в свободной форме. Опытный бизнес-аналитик описывает процессы в нотации BPMN или EPC, которые однозначно интерпретируются и заказчиком, и разработчиком.
3. Требования к функциональности («как должно быть»)
Самый объёмный раздел ТЗ — обычно 60–70% от общего объёма документа. Здесь перечисляются все модули будущей системы и для каждого описывается бизнес-логика.
Для каждого модуля прописываются:
Назначение модуля и место в общей логике системы
Роли пользователей, которые с ним работают
Полный перечень функций: добавить, редактировать, удалить, экспортировать, согласовать, утвердить
Бизнес-правила и ограничения: «заказ с суммой выше 500 000 рублей требует утверждения коммерческого директора»
Состав форм: какие поля вводятся вручную, какие подставляются автоматически, какие обязательные
Отчёты и аналитика по модулю
4. Требования к интеграциям
Один из самых недооценённых разделов. Интеграции — это всегда отдельная боль: технология, бюджет, риски. Их нужно фиксировать отдельным разделом и максимально подробно.
Для каждой интеграции в ТЗ описывается: внешняя система, направление обмена, периодичность (реальное время или пакеты), формат (API, файловый обмен), перечень передаваемых сущностей, правила обработки конфликтов.
Типичные интеграции для российских компаний:
1С:Бухгалтерия или 1С:Управление торговлей
Банковский клиент и банковские API
Честный ЗНАК (для маркированных товаров)
ЕГАИС (для алкогольной продукции)
ЭДО-операторы (Диадок, СБИС, Контур)
Маркетплейсы (Wildberries, Ozon, Яндекс.Маркет)
Системы доставки (Boxberry, СДЭК, DPD)
Телефония и мессенджеры (для CRM-функций)
Если интеграции не зафиксировать в ТЗ, разработчик не закладывает их в оценку, и они выпадают из бюджета.
5. Требования к ролям и правам доступа
ERP хранит финансовые, коммерческие, кадровые и персональные данные. Кто что может видеть и редактировать — нужно проектировать заранее, а не настраивать «по ходу».
В этом разделе строится матрица доступа: список ролей по вертикали, список модулей и функций по горизонтали, в ячейках — уровень доступа (нет доступа, просмотр, редактирование, удаление, утверждение).
Типичные роли для ERP среднего бизнеса: администратор, директор и собственник, финансовый директор и бухгалтерия, коммерческий директор и менеджеры продаж, руководитель склада и кладовщики, производственный мастер и технолог, HR-специалист, сотрудник колл-центра.
Неправильно настроенный доступ — это либо утечка коммерческих данных, либо ситуация, когда сотрудник не может выполнить работу. Особенно тонко: может ли менеджер видеть продажи коллег, может ли кладовщик видеть остатки других складов.
6. Нефункциональные требования
Этот раздел определяет архитектурные решения. Если он плохо проработан, разработчик принимает решения «по умолчанию», которые потом дорого переделывать.
Если не задать требование «система должна работать при 500 одновременных пользователях», разработчик спроектирует под 50, и переделка архитектуры на этапе масштабирования — это пересборка фундамента под зданием.
7. Требования к инфраструктуре и развёртыванию
Здесь фиксируется, где и как будет жить система. Собственные серверы заказчика, облако (Yandex Cloud, VK Cloud, Selectel), гибридная модель. Какие требования к технологическому стеку — если у заказчика есть предпочтения (корпоративный стандарт на PostgreSQL или запрет на иностранное ПО). Совместимость с операционными системами, браузерами, мобильными платформами.
Для российских компаний всё чаще добавляется требование импортонезависимости: отечественные СУБД, серверное ПО, средства защиты информации. Это влияет на выбор технологий и должно быть проговорено в самом начале.
8. Прототипы ключевых экранов
Раздел, который снимает 80% разногласий на этапе приёмки. Прототипы (wireframes) — это схематичные макеты интерфейса для ключевых экранов: список заказов, карточка клиента, форма приёмки на склад, рабочее место кладовщика, кабинет руководителя.
Важно: прототип — это не дизайн. Это схема, которая показывает расположение элементов, состав форм, логику навигации, последовательность экранов. Дизайн делается позже, поверх согласованного прототипа.
Из практики BPA Develop: прототипирование ключевых экранов стоит 10–15% от стоимости разработки и снимает порядка 80% разногласий, которые иначе всплывают на приёмке. Клиент, который посмотрел и согласовал прототипы, принимает работу с первого раза без болезненных переделок. Это лучшая инвестиция в проект после собственно ТЗ.
9. Критерии приёмки и порядок тестирования
Без этого раздела «готово» становится понятием субъективным. Разработчик считает, что всё сделано, и хочет закрыть проект. Заказчик считает, что есть нюансы, и не хочет подписывать акт.
В разделе критериев приёмки для каждого модуля фиксируются: сценарии использования (use cases), которые должны работать без ошибок; порядок их проверки; допустимое количество и категории дефектов на момент сдачи; регламент исправления выявленных проблем.
Хорошо проработанные критерии приёмки превращают сдачу проекта из эмоционального обсуждения в техническую процедуру: прошли по сценариям, отметили результаты, подписали акт.
Кто должен готовить техническое задание на ERP
Распространённое заблуждение: «ТЗ — это работа заказчика». Это путь к проблемам, описанным выше. Реальное распределение ролей выглядит иначе.
Главная мысль: заказчик не обязан уметь писать ТЗ. Это работа разработчика. Хороший подрядчик берёт подготовку на себя: задаёт правильные вопросы, структурирует ответы, переводит «нам надо удобно» в конкретные функциональные требования. Если разработчик предлагает заказчику сделать ТЗ самостоятельно — это серьёзный звоночек.
Как выглядит процесс подготовки ТЗ на ERP
Предпроектная работа над ТЗ — это не одно действие, а последовательность этапов. Каждый из них важен и имеет свою задачу.
Сколько страниц должно быть в ТЗ на ERP
Заказчики часто спрашивают, какой объём документа считается нормальным.
| Масштаб ERP | Количество модулей | Ориентировочный объём ТЗ |
|---|---|---|
| Небольшая ERP (до 50 пользователей) | 5–7 | 50–100 страниц |
| ERP среднего масштаба (50–200 пользователей) | 8–12 | 100–200 страниц |
| Крупная ERP (200+ пользователей, сложные интеграции) | 12+ | 200–400 страниц |
Важная оговорка: объём документа — не самоцель. Хорошее ТЗ — это конкретное и понятное ТЗ, а не объёмное. Размытые формулировки на 300 страницах хуже, чем чёткие требования на 80.
Частые ошибки при составлении ТЗ на разработку ERP
Семь ошибок, которые встречаются почти на каждом проекте без подготовленного ТЗ или с плохо подготовленным ТЗ.
1 | Размытые цели проекта «Хотим ERP, которая поможет навести порядок» — это не цель, а пожелание. Цель формулируется иначе: «сократить время формирования производственного задания с 2 часов до 15 минут». Конкретные цели позволяют выбрать правильное решение и проверить результат. |
2 | ТЗ пишет разработчик без участия бизнес-пользователей Документ описывает архитектуру и техническую логику, но не отвечает на главный вопрос: как система поможет конкретному кладовщику или менеджеру работать эффективнее. Система делается для людей, мнения которых никто не спросил. Внедрение встречает сопротивление. |
3 | Не описаны исключения и граничные условия «Менеджер оформляет заказ» — нормальный сценарий. А что происходит при отсутствии товара? При частичной отгрузке? При аннулировании после оплаты? Каждое исключение, не описанное в ТЗ, превращается в спор при разработке и часто в неожиданный счёт за «доработки». |
4 | Интеграции добавляются в конце или забываются Интеграции сильно влияют на архитектуру. Если требование интеграции с 1С появляется «на финальном этапе», это может потребовать переработки нескольких модулей. Все интеграции должны быть спроектированы до начала разработки. |
5 | Нет матрицы прав доступа «Кладовщик работает со складом» — слишком общо. Может ли он видеть остатки чужих складов? Менять данные задним числом? Видеть закупочные цены? Без ответов система оказывается либо опасно открытой, либо ограничивает работу так, что сотрудники не могут выполнять обязанности. |
6 | Прототипы не согласовываются до начала разработки Заказчик впервые видит интерфейс на этапе демонстрации готового модуля: «Мы думали, что это будет выглядеть совсем иначе». Переделка дизайна и логики экранов на финальной стадии стоит в 3–5 раз дороже, чем правки wireframe. |
7 | ТЗ не обновляется в ходе проекта Если изменения вносятся устно «давай по ходу», к концу проекта у заказчика и разработчика разные версии реальности. Любое изменение требований нужно фиксировать дополнением к ТЗ с оценкой трудозатрат и сроков. Это не бюрократия, а способ договариваться по фактам. |
Из практики BPA Develop: примерно 70% проектов, которые приходят к нам как «доработка после другого подрядчика», страдают от первой и третьей ошибок. Размытые цели и неописанные граничные условия дают огромное поле для разной интерпретации, и в итоге обе стороны искренне считают, что правы они, а виноваты другие.
Чем ТЗ отличается от концепции, брифа и технического проекта
Терминологическая путаница на старте проекта — типичная история. Разберём четыре близких понятия.
| Документ | Объём | Назначение | Когда создаётся |
|---|---|---|---|
| Бриф | 1–3 стр. | Первичное понимание масштаба задачи | Первая встреча |
| Концепция системы | 10–30 стр. | Общая логика: модули, принципы, сценарии. Проверка, что стороны понимают систему одинаково | До ТЗ |
| Техническое задание | 50–400 стр. | Полное описание требований. Основа для разработки и приёмки. Юридически значимый документ | До разработки |
| Технический проект | Зависит от системы | Архитектурные и технические решения: схемы БД, API, диаграммы. Для внутренней работы команды | После утверждения ТЗ |
Логика простая: бриф запускает разговор, концепция фиксирует общий взгляд, ТЗ фиксирует требования к продукту, ТП фиксирует решения по реализации. Все четыре документа нужны, но на разных этапах.
Как проверить качество готового ТЗ на ERP
Если ТЗ уже подготовлено, полезно проверить его по чеклисту. Хорошее ТЗ отвечает «да» на следующие вопросы:
В документе сформулированы измеримые цели проекта?
Описаны все модули с детальным перечнем функций?
Для каждой функции описана бизнес-логика и граничные условия?
Есть матрица ролей и прав доступа?
Перечислены все интеграции с указанием направления, периодичности и формата обмена?
Описаны нефункциональные требования: производительность, доступность, безопасность, масштабируемость?
Есть прототипы (wireframes) хотя бы для ключевых экранов?
Сформулированы критерии приёмки для каждого модуля?
Документ понятен человеку, который не присутствовал на этапе обследования?
Заказчик и разработчик одинаково интерпретируют ключевые требования?
Если хотя бы на 3–4 вопроса ответ «нет» — ТЗ нужно дорабатывать до начала разработки. Запуск разработки по неполному ТЗ — это сознательный выбор работать с повышенным риском перерасхода бюджета и сроков.
Вывод
Техническое задание на разработку ERP — это не лишний шаг перед началом работы, а условие её успеха. Компании, которые приходят с детальным ТЗ или готовы поработать над ним вместе с подрядчиком, получают системы в срок, в бюджете и без неприятных сюрпризов на приёмке.
Компании, которые экономят на предпроектной работе ради скорого старта, потом многократно платят за это в виде доработок, переделок и упущенного времени. Если вы планируете разработку ERP или уже столкнулись с проблемами на проекте без ТЗ, команда BPA Develop готова помочь на любом этапе.
Часто задаваемые вопросы
