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