Важная ремарка: при оценке текущего состояния технической готовности и анализе причин нужно разделять функционал работы с ЭТрН от работы с экспедиторскими документами (ЭЭД). История развития и подготовки этих блоков принципиально разная. В данном посте я рассматриваю именно экспедиторские документы.
С одной стороны, ряд нареканий к операторам вполне обоснован. У разных операторов некоторое элементы реализованы концептуально по-разному, что создает проблемы даже в кросс-отраслевой коммуникации. Где-то возникают ошибки, где-то не отрабатывают ожидаемые сценарии, где-то техническая поддержка не успевает оперативно разбирать инциденты. Доходит до совсем странных ситуаций: система не позволяет отправить электронную экспедиторскую расписку из-за совпадения номера поручения экспедитору и экспедиторской расписки. (?!) 🥶
Логичный вопрос бизнеса: «Мы платим за сервис. Почему к моменту обязательного запуска он не работает стабильно?»
Но здесь есть вторая сторона проблемы, о которой говорят значительно реже. Разработка информационной системы — это процесс, а не одна волшебная кнопка «включить».
У разработки функционала информационных систем есть типовой цикл. На примере внедрения ЭПД он выглядит так:
Утверждение формата → готовность оператора ГИС → разработка у операторов ЭПД → тестирование → доработка бизнес-систем → пилоты → промышленная эксплуатация.
И перескочить через эти стадии невозможно!
Можно увеличить команду разработчиков. Можно работать по ночам. Можно одновременно вести несколько потоков разработки. Но девять женщин не родят ребенка за один месяц. 🤷♀️
Некоторые процессы требуют не только ресурсов, но и времени на последовательное прохождение этапов.
И вот здесь кроется основная причина «неготовности операторов ЭДО» в части экспедиторских документов.
Если посмотреть на историю внедрения ЭТрН, то ее формат был утвержден задолго до обязательного применения. У рынка было несколько лет на разработку, интеграции, тестирование и пилоты. (на тему ЭТрН поговорим отдельно 😉).
С электронными экспедиторскими документами ситуация принципиально иная. Форматы появились только в конце 2-го квартала 2026 года. ГИС ЭПД включил работу с экспедиторскими только в сентябре. Операторы ЭПД выкатили функционал работы с экспедиторскими в августе, но в режиме MVP (потому что были слишком сжатые сроки на разработку). А уже с сентября 2026 года рынок должен был перейти к обязательному применению.
То есть между появлением нормативки и технической готовности продукта и его массовой промышленной эксплуатацией вообще отсутствовал полноценный период стабилизации.
Что в обычном IT-проекте должно происходить после разработки?
∙ Тестирование.
∙ Пилотирование на ограниченном числе пользователей.
∙ Исправление ошибок.
∙ Повторное тестирование.
∙ Интеграционные испытания с внешними системами.
∙ Проверка нетиповых сценариев.
∙ Нагрузочное тестирование.
∙ Подготовка поддержки.
И только после этого — промышленный запуск. Здесь же значительная часть этих стадий оказалась фактически совмещена с обязательной эксплуатацией.
Поэтому в сентябре произошло то, что в каком-то смысле было неизбежно:
Рынок вошел не столько в промышленную эксплуатацию электронных экспедиторских документов, сколько в масштабное отраслевое бета-тестирование.
Только «бета-тестерами» стали не добровольцы. Ими одновременно стали экспедиторы, перевозчики, грузовладельцы, операторы ЭПД, разработчики учетных систем и интеграторы. 😖
Причем тестирование происходит уже на реальных перевозках, реальных документах и реальных бизнес-процессах.
Отсюда и эффект:
— разные реализации одного и того же сценария у операторов;
— ошибки на ранее не встречавшихся комбинациях данных;
— проблемы роуминга и интеграционного взаимодействия;
— перегруженная техническая поддержка;
— необходимость оперативно исправлять функционал уже «на ходу».
Это не означает, что операторов ЭПД не нужно критиковать.
Если система работает нестабильно — проблему надо исправлять. Если поддержка отвечает плохо — сервис надо улучшать. Если один и тот же нормативный сценарий реализован у операторов принципиально по-разному — рынку необходима дополнительная унификация.
Но важно правильно определить первопричину. Именно поэтому фраза «операторы оказались не готовы» описывает ситуацию лишь частично.
И если между утверждением требований и обязательной промышленной эксплуатацией не оставить достаточного пространства для разработки, интеграционных испытаний и пилотов, то тестирование все равно состоится. Просто оно состоится уже на бизнесе. И, похоже, именно этот этап отрасль сейчас и проходит.
А значит нам (бизнесу) нужно проходить период адаптации очень быстро и максимально «компактно», отсекая все лишние телодвижения и эмоции, которые не приближают нас к цели, но лишь тратят энергию.













