Зачем нужно ТЗ и что будет без него
Риски покупки WMS без технического задания
Составить тз на wms до начала переговоров с вендором - значит зафиксировать объём проекта на своих условиях, а не на условиях поставщика. Без этого документа вендор сам определяет границы работ, и трактует их в свою пользу. Доработки, которые заказчик считал само собой разумеющимися, оказываются вне базового контракта. По открытым данным, бюджет проектов без детального ТЗ превышает первоначальную оценку на 30-70%.
Типичный сценарий: компания согласовала с вендором «внедрение WMS под ключ» на словах, получила коммерческое предложение и подписала договор. Через два месяца выяснилось, что интеграция с ERP, настройка адресного хранения под конкретную топологию и обучение персонала входят в отдельный прайс. Запуск сдвинулся на четыре месяца, итоговая сумма выросла вдвое. Причина - размытые требования, которые каждая сторона читала по-своему.
Кто теряет деньги при размытых требованиях
ТЗ - юридически значимый документ. Он фиксирует границы проекта, перечень функций и критерии приёмки. Без него у заказчика нет инструмента, чтобы доказать: система работает не так, как договаривались. Подробнее о том, из каких статей складывается итоговая сумма проекта, можно прочитать в материале о стоимости внедрения WMS и факторах, которые на неё влияют.
Важно разграничивать два типа документов. ТЗ на разработку кастомной WMS описывает систему, которой ещё не существует: архитектуру, модели данных, алгоритмы. ТЗ на внедрение коробочного решения описывает, как существующий продукт должен быть настроен, доработан и интегрирован под конкретный склад. Структура документа схожа, но глубина проработки технических разделов различается. В первом случае вендор строит с нуля, во втором - адаптирует готовое ядро. Это меняет распределение рисков и ответственности.
Предпроектный анализ: что собрать до написания ТЗ
Описание текущих складских процессов
Прежде чем формулировать требования к системе, нужно зафиксировать, как склад работает сейчас. Описание AS-IS - не формальность: оно выявляет узкие места, нестандартные сценарии и исключения, которые потом войдут в функциональные требования.
По каждому процессу фиксируют: кто инициирует операцию, какие данные используются на входе, что происходит при отклонении от нормы. Минимальный перечень процессов для описания: приёмка товара, верификация по документам, размещение в зоны хранения, отбор по заданиям, комплектация и упаковка, отгрузка с оформлением документов, инвентаризация. Каждый процесс описывается отдельно, со схемой или текстовым регламентом.
Топология склада и товарная матрица
Для корректного описания требований к WMS нужны количественные параметры объекта. Собирают следующие данные: общая площадь склада и площадь каждой зоны, высота стеллажей и тип хранения (напольное, стеллажное, мезонин), количество адресов хранения, количество активных SKU, среднесуточный и пиковый товарооборот в строках и паллетах, сезонные коэффициенты нагрузки.
Топологию склада нельзя оставлять на усмотрение вендора. Если зонирование не зафиксировано в ТЗ, вендор настроит систему под типовую схему, которая может не совпадать с реальным расположением зон приёмки, карантина, отбора и отгрузки. Переконфигурация после запуска обходится дороже, чем проектирование с нуля.
Товарная матрица влияет на стратегии размещения и отбора. В ТЗ указывают: есть ли товары с температурным режимом, опасные грузы, товары с ограниченным сроком годности, крупногабаритные позиции с нестандартными условиями хранения. Это напрямую определяет, какие алгоритмы WMS должна поддерживать.
Интеграционный ландшафт: ERP, 1С, ТСД, оборудование
Перечень систем, с которыми WMS будет обмениваться данными, составляют до написания ТЗ, а не в процессе. Изменение интеграционного контура на поздних этапах - одна из главных причин роста бюджета.
Стандартный интеграционный ландшафт склада включает: учётную систему (ERP, 1С или отраслевое решение), систему управления транспортом (TMS), платформу электронного документооборота, систему маркировки («Честный знак» и аналоги), терминалы сбора данных (ТСД), весовые терминалы, принтеры этикеток, конвейерное и сортировочное оборудование.
По каждой системе фиксируют: версию и вендора, какие объекты данных передаются, в каком направлении, с какой частотой. Оборудование описывают с указанием модели и операционной системы - это влияет на совместимость с клиентской частью WMS. Если часть оборудования планируется к замене или закупке, это тоже отражают в ТЗ: вендор должен знать, под какой парк техники настраивается система.
Структура ТЗ на WMS: обязательные разделы
Документ строится по единой логике: от целей проекта - к описанию процессов - к техническим ограничениям и критериям приёмки. Такая последовательность позволяет вендору понять контекст каждого требования, а заказчику - проверить полноту документа перед отправкой.
| Раздел ТЗ | Что описывает | Кто готовит данные | Типичный объём (стр.) |
|---|---|---|---|
| Общие сведения и цели проекта | Назначение системы, границы проекта, ожидаемые результаты | Руководитель проекта со стороны заказчика | 2-4 |
| Функциональные требования | Что система должна делать по каждому процессу, сценарии и исключения | Руководитель склада, операционные менеджеры | 15-40 |
| Нефункциональные требования | Производительность, доступность, масштабируемость, безопасность | ИТ-директор, системный архитектор | 4-8 |
| Требования к интеграциям | Перечень систем, объекты данных, протоколы, частота обмена, ответственность | ИТ-отдел заказчика совместно с владельцами смежных систем | 5-12 |
| Требования к оборудованию и инфраструктуре | Парк ТСД, принтеры, серверная инфраструктура или облако, сетевое покрытие | ИТ-отдел заказчика | 3-6 |
| Порядок приёмки и критерии готовности | Этапы тестирования, измеримые KPI, условия подписания актов | Руководитель проекта, юридический отдел | 3-6 |
Общие сведения и цели проекта
Первый раздел задаёт контекст для всего документа. Здесь описывают: для какого объекта внедряется система, какие бизнес-задачи должны быть решены, какие метрики изменятся после внедрения. Цели формулируют конкретно: не «повысить эффективность», а «сократить время комплектации заказа с X до Y минут» или «снизить расхождения при инвентаризации до уровня не выше Z%».
В этом же разделе фиксируют ограничения: сроки запуска, бюджетный потолок, организационные ограничения (например, запрет на остановку склада дольше чем на одну смену при переходе). Раздел занимает 2-4 страницы и читается первым - от его качества зависит, правильно ли вендор поймёт приоритеты.
Функциональные требования
Это самый объёмный раздел. Он описывает, что система должна уметь делать, с детализацией до уровня отдельной операции. Каждое требование формулируют через процесс, триггер, действие системы, ожидаемый результат и обработку исключений.
Недостаточно написать «система должна поддерживать приёмку товара». Нужно указать: по каким документам ведётся приёмка, как система реагирует на расхождение с заказом, что происходит с товаром, не прошедшим верификацию, как фиксируется факт приёмки для передачи в ERP. Каждый нестандартный сценарий - кросс-докинг, возврат, карантин - описывается отдельно.
Нефункциональные требования
Раздел описывает характеристики системы, не связанные напрямую с бизнес-логикой, но критичные для эксплуатации. Производительность: сколько строк в час система должна обрабатывать в пиковый период, сколько пользователей работают одновременно. Доступность: допустимое время простоя, SLA на восстановление после сбоя. Масштабируемость: как система должна вести себя при росте SKU или открытии новых складов.
Безопасность описывают через требования к ролевой модели и разграничению доступа. Этот раздел часто пишут формально - и потом получают систему без журнала действий пользователей или с единственной ролью «администратор» для всех.
Требования к интеграциям
Раздел перечисляет все точки обмена данными: какие системы участвуют, какие объекты передаются (заказы, остатки, справочники, документы), в каком направлении, с какой частотой, по какому протоколу. Для каждой интеграции указывают ответственную сторону и порядок обработки ошибок.
Отдельно фиксируют требования к API: тип (REST или SOAP), формат данных (JSON, XML), механизм аутентификации, требования к логированию запросов. Если интеграция асинхронная, описывают очередь сообщений и поведение системы при недоступности смежного сервиса.
Требования к оборудованию и инфраструктуре
Раздел описывает физическую и технологическую среду, в которой будет работать WMS. Для ТСД указывают модели, операционные системы, способ подключения (Wi-Fi, Bluetooth). Для принтеров - тип (термо, термотрансферный), поддерживаемые форматы этикеток. Для серверной инфраструктуры - требования к вычислительным ресурсам при on-premise развёртывании или параметры облачного окружения.
Требования к инфраструктуре влияют на выбор WMS: часть решений не поддерживает определённые модели ТСД или работает только в облаке. Зафиксировать ограничения в ТЗ дешевле, чем обнаружить несовместимость после подписания контракта.
Порядок приёмки и критерии готовности
Раздел отвечает на вопрос: как стороны определят, что система работает корректно и проект можно закрыть. Критерии приёмки должны быть измеримыми. Не «система корректно обрабатывает приёмку», а «при приёмке партии из 100 позиций система фиксирует расхождения с точностью 100% и формирует акт расхождения в течение 30 секунд».
Раздел описывает этапы тестирования: функциональное, нагрузочное, интеграционное, приёмочное. Для каждого этапа фиксируют: кто проводит, какие сценарии проверяются, какой результат считается успешным, что происходит при обнаружении критических дефектов. Подписание актов привязывают к прохождению конкретных тестов, а не к субъективной оценке сторон.
Функциональные требования: что описать по каждому процессу
Функциональные требования - это ядро ТЗ. Каждое требование должно описывать конкретную операцию, а не абстрактную возможность системы. Удобный шаблон: процесс, триггер, действие системы, ожидаемый результат, исключения. Такая структура исключает двойное толкование и даёт вендору достаточно контекста для оценки трудоёмкости.
Приёмка и верификация товара
Приёмка охватывает несколько сценариев, и каждый нужно описать отдельно. Стандартная приёмка по заказу - один сценарий. Кросс-докинг, когда товар не уходит в хранение, а сразу формируется в исходящий заказ, - другой. Расхождение фактического количества с заказом, пересортица, повреждённая упаковка - третий, четвёртый, пятый.
Для каждого сценария фиксируют: какой документ инициирует приёмку, как система реагирует на расхождение, куда направляется товар с претензией, кто подтверждает операцию. Карантинная зона - отдельный объект в топологии склада: опишите, при каких условиях товар туда попадает и какие операции с ним разрешены до решения по претензии.
Адресное хранение и управление ячейками
Требования к хранению начинаются с описания стратегий размещения. Фиксированное место, динамическое, размещение по зонам с учётом оборачиваемости - каждый вариант влияет на логику системы. Если склад работает с пищевой продукцией или фармацевтикой, обязательно укажите ротацию: FIFO по дате поступления или FEFO по сроку годности.
Ограничения совместимости хранения тоже входят в этот раздел. Химия и продукты питания в одной зоне, крупногабаритный и мелкий товар на одной стеллажной секции - система должна знать эти правила и блокировать некорректное размещение. Опишите также логику управления ячейками: условия консолидации остатков, правила освобождения ячейки, признаки блокировки.
Отбор, комплектация и упаковка
Стратегия отбора напрямую зависит от профиля заказов. Дискретный отбор - один сборщик, один заказ - подходит для крупных заказов с большим количеством строк. Кластерный позволяет одному сборщику одновременно собирать несколько заказов в разные контейнеры. Волновой отбор объединяет заказы в волны по времени отгрузки или маршруту перевозчика.
В ТЗ нужно указать, какие стратегии применяются на вашем складе, и при каких условиях система выбирает ту или иную. Если используется несколько стратегий, опишите приоритеты. Требования к упаковке включают: выбор типа упаковки по параметрам товара, печать упаковочного листа, контроль веса на упаковочной станции, формирование паллеты и нанесение этикетки.
Отгрузка и документооборот
Процесс отгрузки в ТЗ описывают от момента формирования задания на отгрузку до закрытия транспортного документа. Фиксируют: как система формирует задание на отгрузку, как контролирует комплектность перед погрузкой, какие документы печатаются автоматически - накладная, УПД, транспортная накладная, упаковочный лист.
Отдельно описывают сценарии частичной отгрузки и возврата. Если склад работает с маркированными товарами, требования к передаче кодов маркировки в систему оператора - обязательный пункт. Укажите, какие статусы отгрузки должна фиксировать WMS и в каком порядке они передаются в ERP.
Инвентаризация и управление остатками
Инвентаризация в ТЗ описывается в трёх вариантах: плановая полная, выборочная по зоне или группе товаров, циклическая по ячейкам. Для каждого варианта фиксируют: кто инициирует, как система формирует задание, нужна ли блокировка ячеек на время пересчёта, как обрабатываются расхождения.
Требования к управлению остатками включают: логику резервирования под заказы, учёт товара в разных статусах (доступный, зарезервированный, в карантине, повреждённый), правила списания и корректировки. Отчётность по инвентаризации - отдельный пункт: какие формы нужны, в каком формате, с какой детализацией до ячейки и серийного номера.
Требования к интеграции WMS с ERP и смежными системами
Типовые точки интеграции и форматы обмена
Интеграция - раздел, где размытые формулировки обходятся дороже всего. «Система должна обмениваться данными с ERP» - не требование. Требование выглядит иначе: перечень объектов данных, направление передачи, частота, формат, ответственная сторона за каждый поток.
Типовой набор объектов между WMS и ERP: заказы на поставку и отгрузку, справочник номенклатуры, остатки по складу, приходные и расходные документы, данные о серийных номерах и партиях. Для каждого объекта укажите, кто является источником, кто потребителем и что происходит при конфликте данных.
Синхронная интеграция нужна там, где задержка недопустима: резервирование остатков под заказ, подтверждение отгрузки. Асинхронная подходит для передачи справочников, отчётных документов, исторических данных. Выбор режима фиксируют в ТЗ для каждого потока отдельно - это влияет на архитектуру интеграционного слоя и трудоёмкость разработки.
Требования к API формулируют конкретно: протокол (REST или SOAP), формат данных (JSON, XML), частота опроса для асинхронных потоков, тайм-аут ожидания ответа, поведение системы при ошибке, требования к логированию каждого обмена. Если интеграция строится через шину данных или промежуточный брокер, это тоже фиксируют в ТЗ.
Особенности интеграции с 1С
Интеграция с 1С имеет специфику, которую стоит учесть до начала проектирования. Основная проблема - качество нормативно-справочной информации. Дублирующиеся карточки номенклатуры, несогласованные единицы измерения, отсутствие штрихкодов в справочнике - всё это выясняется в процессе интеграции и тормозит запуск.
В ТЗ нужно зафиксировать требования к НСИ как предусловие интеграции: состав обязательных атрибутов номенклатуры, правила уникальности, ответственного за актуализацию справочника. Подробнее о типовых сложностях и способах их решения - в материале Интеграция WMS с 1С и ERP: способы обмена данными.
Отдельно опишите требования к интеграции с оборудованием: ТСД, весовые терминалы, системы маркировки. Для ТСД укажите модели и операционные системы, которые уже используются или планируются к закупке. Весовые терминалы требуют описания формата передачи данных о взвешивании и правил привязки веса к конкретной операции. Системы маркировки - отдельный поток с требованиями к получению, хранению и передаче кодов.
Нефункциональные требования: производительность, безопасность, инфраструктура
Нефункциональные требования определяют, как система работает, а не что она делает. Их отсутствие в ТЗ - одна из причин, по которым система формально соответствует функциональным требованиям, но не выдерживает реальной нагрузки в пиковый период.
Производительность описывают через измеримые показатели. Базовые метрики: количество строк отбора в час при штатной нагрузке, пиковое значение в сезон, количество одновременно работающих пользователей, допустимое время отклика системы на операцию с ТСД. Пиковую нагрузку берут из данных о сезонности, собранных на этапе предпроектного анализа, и закладывают запас не менее 30% сверх исторического максимума.
Требования к доступности фиксируют через SLA: допустимый процент времени работы системы в месяц, максимальное время восстановления после сбоя (RTO), максимально допустимая потеря данных (RPO). Для склада с круглосуточной работой параметры будут принципиально другими, чем для объекта с односменным графиком. Резервное копирование описывают отдельно: частота, место хранения резервных копий, порядок проверки восстановления.
Выбор между развёртыванием on-premise и в облаке влияет на содержание ТЗ. Для on-premise фиксируют требования к серверному оборудованию, операционной системе, СУБД, сетевой инфраструктуре, резервному питанию. Для облачного варианта - требования к провайдеру, географии размещения данных, соответствию законодательству о персональных данных, гарантиям доступности со стороны провайдера.
Ролевая модель и разграничение доступа - обязательный раздел. Перечислите роли пользователей системы, укажите, какие операции доступны каждой роли, опишите требования к журналированию действий: какие события фиксируются, как долго хранится журнал, кто имеет доступ к его просмотру. Это требование актуально и с точки зрения внутреннего контроля, и с точки зрения аудита.
Требования к отчётности операционного менеджмента формулируют через конкретные дашборды и выгрузки. Текущий статус отбора по волнам, производительность сборщиков за смену, процент расхождений при приёмке, оборачиваемость по зонам хранения - каждый отчёт описывают с указанием источника данных, периодичности обновления и формата выгрузки. Если часть отчётности строится в BI-системе на основе данных WMS, это тоже фиксируют в требованиях к интеграции.
Типичные ошибки в ТЗ на WMS и как их избежать
Большинство проблем при внедрении WMS закладываются не на этапе разработки, а на этапе написания ТЗ. Разбор типичных ошибок помогает их предотвратить до передачи документа вендору.
Ошибка 1: требования написаны на языке решения, а не на языке процесса.
«Система должна поддерживать волновой отбор» - это требование к функции. «При формировании отправки более 50 строк система должна автоматически группировать задания по зонам и назначать их нескольким сборщикам одновременно» - это требование к процессу. Первая формулировка позволяет вендору реализовать волновой отбор так, как удобно ему. Вторая оставляет меньше пространства для интерпретации.
Ошибка 2: интеграции описаны как «передача данных» без форматов и регламентов.
Это источник большинства конфликтов на проектах. Если в ТЗ написано «WMS должна передавать остатки в ERP», каждая сторона понимает это по-своему: разные форматы, разная периодичность, разная логика обработки ошибок. Раздел интеграций должен содержать конкретные объекты данных, направление передачи, частоту, формат и ответственную сторону за каждый поток.
Ошибка 3: отсутствие требований к миграции данных.
Перенос справочников, остатков и истории операций из текущей системы - отдельный объём работ. Если он не зафиксирован в ТЗ, вендор либо не закладывает его в смету, либо выполняет по минимуму. В ТЗ нужно описать состав данных для миграции, требования к их качеству, ответственность сторон и критерии успешной миграции.
Ошибка 4: не зафиксированы требования к обучению и документации.
Система, которую персонал не умеет использовать, не даёт ожидаемого эффекта. В ТЗ фиксируют: форматы обучения (очное, дистанционное, на рабочем месте), категории сотрудников, объём пользовательской документации и язык её написания. Отсутствие этих требований означает, что вендор поставит ровно столько, сколько посчитает нужным.
Ошибка 5: критерии приёмки размыты.
«Система должна работать корректно» - не критерий. Измеримый критерий выглядит иначе: «Система обрабатывает не менее 500 строк отбора в час при одновременной работе 20 пользователей без деградации времени отклика выше 3 секунд». Без таких формулировок подписание актов превращается в переговоры, а не в проверку факта.
Подробнее о том, как незакрытые риски ТЗ перерастают в системные сбои проекта, - в материале об основных причинах, по которым проекты внедрения WMS не достигают целей.
Чек-лист готовности ТЗ перед отправкой вендорам
Перед отправкой документа вендорам стоит пройти по структурированному списку проверок. Он охватывает содержание, полноту и измеримость требований.
Содержание и структура
- Зафиксированы цели проекта и измеримые результаты внедрения
- Описаны AS-IS процессы по всем операциям: приёмка, размещение, отбор, упаковка, отгрузка, инвентаризация
- Указаны площадь склада, зонирование, количество SKU, суточный оборот, сезонные пики
- Приведена схема топологии склада с описанием зон и типов ячеек
- Перечислены все системы, с которыми WMS должна обмениваться данными
Функциональные требования
- Каждое требование описано по схеме: процесс, триггер, действие системы, результат, исключения
- Для каждого процесса указаны все нестандартные сценарии
- Составлена матрица покрытия: каждый складской процесс соответствует хотя бы одному функциональному требованию
- Указаны стратегии отбора и размещения, которые нужны именно этому складу
Интеграции
- Перечислены все внешние системы с указанием версий и архитектуры
- Для каждого потока данных указаны: объект, направление, частота, формат, ответственная сторона
- Зафиксированы требования к обработке ошибок и логированию обменов
- Описаны требования к интеграции с оборудованием: ТСД, принтеры, весовые терминалы
Нефункциональные требования
- Указана пиковая нагрузка в строках/час и количество одновременных пользователей
- Зафиксированы SLA по доступности и время восстановления после сбоя
- Определён вариант развёртывания: on-premise или облако
- Описаны требования к ролевой модели и журналированию действий
Миграция, обучение, приёмка
- Зафиксирован состав данных для миграции и критерии их качества
- Описаны требования к обучению персонала и пользовательской документации
- Критерии приёмки сформулированы в измеримых показателях
Признак того, что ТЗ готово к отправке: вендор может назвать фиксированную цену без оговорки «уточним после детального обследования». Если вендор составляет ТЗ самостоятельно, заказчику нужно проверить, что в документе отражены все нестандартные сценарии, зафиксированы критерии приёмки и не упущен раздел миграции данных.
От ТЗ к проекту: следующие шаги после согласования документа
Согласованное ТЗ становится основой для тендера. Запрос предложений (RFP) строится на требованиях из документа, а не на предпочтении конкретного бренда. Это позволяет сравнивать предложения вендоров по единым критериям: покрытие функциональных требований, архитектура интеграций, сроки, стоимость.
Детальное ТЗ снижает итоговую стоимость внедрения. Вендор, который видит полный объём работ, закладывает меньше резервов на непредвиденные доработки. Размытое ТЗ, напротив, вынуждает поставщика страховаться: либо через высокую базовую цену, либо через дополнительные соглашения в ходе проекта.
После выбора вендора ТЗ трансформируется в техническое проектирование на его стороне. Вендор детализирует требования до уровня настроек системы, описывает архитектуру интеграций и формирует план проекта с контрольными точками. О том, как устроены этапы этой работы и какая команда задействована на каждом из них, подробно написано в материале «Внедрение WMS: этапы, сроки, команда проекта».
На этапах тестирования и приёмки ТЗ выполняет функцию контрольного документа. Каждый критерий приёмки из раздела «Порядок приёмки» проверяется на реальных данных. Если реализация расходится с требованием, у заказчика есть основание для доработки без дополнительной оплаты.
Вопросы и ответы
Q1Зачем составлять ТЗ, если вендор сам проводит предпроектное обследование?
Предпроектное обследование вендора решает его задачу: понять, как продать и внедрить свой продукт с минимальными рисками для себя. Независимое ТЗ заказчика решает другую задачу: зафиксировать объём работ и критерии приёмки до начала переговоров. Тот, кто формулирует требования, контролирует границы проекта. Если этот документ составляет вендор, границы определяет он.
Q2Сколько времени занимает подготовка ТЗ на WMS?
Для небольшого склада с типовыми процессами подготовка ТЗ занимает 2-3 недели. Крупный распределительный центр с нестандартными сценариями, сложными интеграциями и несколькими зонами хранения потребует 6-10 недель. Основная часть времени уходит не на написание документа, а на сбор и согласование данных внутри компании.
Q3Можно ли использовать одно ТЗ для нескольких складов сети?
Если склады работают по одинаковым процессам, имеют схожую топологию и подключаются к одной ERP, ТЗ можно унифицировать с указанием общих требований и параметров каждого объекта в приложениях. Когда склады существенно различаются по топологии, ассортименту или операционной модели, для каждого объекта нужен отдельный документ. Единое ТЗ для разнородных складов создаёт те же риски, что и размытое ТЗ для одного.
Q4Как описать в ТЗ требования к интеграции, если архитектура ERP ещё не определена?
Описывайте интеграцию через объекты данных и бизнес-события: какие данные, когда и в каком направлении должны передаваться. Конкретные технологии и протоколы можно оставить в виде плейсхолдеров с пометкой «уточняется». Такой подход позволяет оценить объём интеграционных работ и не блокирует выбор WMS до окончательного решения по ERP.
Q5Нужно ли включать в ТЗ требования к оборудованию или это отдельный документ?
Требования к ТСД, принтерам этикеток, весовым терминалам и сетевой инфраструктуре влияют на выбор WMS: не все системы поддерживают все модели оборудования и протоколы связи. Минимально необходимо включить в ТЗ перечень уже используемого оборудования и планируемых закупок в виде ограничений. Детальные спецификации на оборудование могут оформляться отдельно, но ссылка на них должна быть в ТЗ.
Q6Как зафиксировать в ТЗ требования к миграции данных из старой системы?
Выделите миграцию в отдельный раздел ТЗ и опишите в нём состав данных (справочники, остатки, история операций), требования к их качеству и формату, ответственность сторон за подготовку и проверку данных. Зафиксируйте критерии успешной миграции: например, расхождение остатков после переноса не более 0,1%. Без этого раздела вендор либо не включает миграцию в смету, либо выполняет её по минимуму.