До 40% проектов по автоматизации складов выходят за рамки бюджета или срывают сроки из-за размытого ТЗ, которое превращается в «список пожеланий». Профессиональный интегратор не примет от вас документ в духе «хотим, чтобы всё работало быстро», а потребует жестко формализованные бизнес-процессы и параметры интеграции.
Карта топологии и детальный реестр ресурсов
Дилетант попросит «план склада». Профи потребует актуальную карту топологии с разбивкой до уровня ячейки (bin), указанием типов зон (приемка, хранение, комплектация, отгрузка) и габаритов каждой из них. Если у вас 5 000 паллетомест, подрядчик должен запросить данные по грузоподъемности стеллажей и ширине проходов для разных типов техники (ричтрак vs штабелер). Без этого расчет производительности системы будет фиктивным.
Пример: при внедрении на складе 10 000 м² отсутствие данных о «узких местах» в зоне отгрузки привело к тому, что система назначала задания, создавая затор из 5 тележек в одном проходе. Итог — падение скорости сборки на 15%. Экспертный вывод: требуйте от подрядчика составить матрицу соответствия типов ТМЦ и типов ячеек, иначе получите хаос в адресном хранении.
Формализация бизнес-процессов и исключений
Профессиональный подрядчик потребует описания не «идеального пути» заказа, а всех сценариев исключений. Вас заставят расписать: что происходит, если товар пришел с браком (процесс карантина), если позиция отсутствует в ячейке (short-pick) или если клиент изменил состав заказа в момент сборки. В среднем, стандартные процессы занимают 60% ТЗ, а остальные 40% — это обработка ошибок, которая и определяет реальный успех запуска.
Кейс: компания внедрила WMS, забыв описать процесс «переупаковки из коробов в паллеты». В итоге при пиковых нагрузках (декабрь, рост заказов в 3 раза) склад встал, так как система не умела распределять задания на переупаковку. Экспертный вывод: если интегратор не спрашивает вас об «ошибках и исключениях», он не знает, как работает реальный склад, и ведет проект по шаблону.
Технические требования к интеграции и API
WMS не живет в вакууме. Профи потребует детальную спецификацию обмена данными с вашей ERP (1С, SAP, Oracle). Вас попросят определить частоту синхронизации: в реальном времени (real-time) или пачками (batch). Для e-commerce с оборотом от 1 000 заказов в сутки задержка синхронизации даже в 5 минут может привести к продаже товара, которого уже нет в наличии (overselling).
Сравнение: использование стандартных коннекторов экономит до 20% бюджета на разработку, но ограничивает гибкость. Кастомная разработка через API стоит дороже (дополнительно 300-700 тыс. руб. на один модуль), но позволяет автоматизировать передачу данных в службы доставки. Экспертный вывод: требуйте от подрядчика схему потоков данных (Data Flow Diagram), чтобы видеть, где именно может произойти разрыв цепи.
Требования к оборудованию и инфраструктуре
Квалифицированный интегратор не просто предложит «купить ТСД», а запросит карту покрытия Wi-Fi и требования к ОС терминалов. Он потребует определить количество одновременно работающих пользователей и пиковую нагрузку на сервер. Ошибка в выборе серверных мощностей на старте приводит к «фризам» системы при росте числа операторов с 10 до 30 человек, что увеличивает время обработки одного заказа на 20-30 секунд.
Пример: на холодном складе (-18°C) использование обычных ТСД привело к конденсату на экранах и выходу из строя 20% парка за месяц. Профи потребовал бы ТСД в специальном исполнении и подогреваемую зону зарядки. Экспертный вывод: инфраструктурный раздел ТЗ должен содержать конкретные модели оборудования и требования к пропускной способности сети, а не общие фразы о «совместимости с оборудованием».
Критерии приемки и KPI запуска
Главный маркер профи — требование зафиксировать KPI до начала работ. Вас попросят определить, по каким цифрам вы поймете, что система работает. Например: сокращение времени сборки заказа с 40 до 25 минут, снижение процента пересорта с 2% до 0,1%, или увеличение точности инвенризации с 92% до 99,8%. Без этих цифр этапы взаимодействия с компанией-интегратором превратятся в бесконечные споры о том, «считается ли система внедренной».
Кейс: клиент принял WMS по факту наличия функций, но не по KPI. В итоге скорость отгрузки упала на 10% из-за избыточного количества подтверждений в интерфейсе ТСД. Исправление этого «удобства» стоило еще 15% от стоимости лицензий. Экспертный вывод: фиксируйте в ТЗ конкретные метрики производительности и сроки их достижения после промышленного запуска.
Вывод
Качество ТЗ — это зеркало компетенций интегратора. Если подрядчик соглашается на ваши общие формулировки, он переложит ответственность за ошибки на вас при приемке. Начинайте с глубокого аудита процессов, избегайте «коробочных» решений без адаптации под вашу топологию и выбирайте того, кто требует от вас цифр и сценариев ошибок. Лучшая стратегия: заказать разработку ТЗ как отдельный платный этап — это сэкономит до 30% бюджета на этапе реализации за счет отсутствия доработок «по ходу дела».