Сбои на морских маршрутах обнажили негибкость логистических ERP
В начале 2024 года Международный валютный фонд зафиксировал, что за первые два месяца объём торговли через Суэцкий канал упал на 50% год к году. Суда уходили в обход мыса Доброй Надежды, и каждая доставка растягивалась на десять и более дней. Затем добавились удары по Ирану и угроза закрытия Ормузского пролива – очередную волну перекладки маршрутов компании принимали буквально за ночь.
Опытные команды понимали, что делать. Их системы – нет. ERP, WMS, TMS и системы планирования построены на допущениях: стандартные маршруты, сроки поставки, правила работы с поставщиками, циклы пополнения запасов. Эти допущения зашиты глубоко – в рабочие процессы, логику отчётов, в то, как рассчитывается и показывается статус остатков.
Когда маршрут рушится, допущения не пересчитываются. Перенаправленная поставка в системе превращается просто в «опоздание». Она не подскажет, доступен ли товар, заблокирован ли он, задвоен ли по двум разным заказам, уже ли распределён под клиента или всё ещё числится приходящим в исходную дату. Дальше начинается знакомый сценарий: команды садятся за таблицы. Появляются побочные трекеры, ручные списки исключений, общие файлы, которые фиксируют то, чего не видит система. Такие таблицы держат работу на плаву, но плодят новые проблемы – задвоенные данные, разнобой во вводе и решения по разным версиям одних и тех же цифр.
Картина повторялась в мебели, продуктовой рознице, фарме, фешене и B2B-дистрибуции – отрасль роли не играла. Один поставщик мебели, товаров для дома и текстиля столкнулся с резким сбоем входящего потока. Устаревшая ERP умела показывать заказы поставщикам только как просроченные, но не давала планировщикам внятной картины: что ещё в пути, что под угрозой, что уже зарезервировано под клиентов, а что требует немедленного разбора. Отделы продаж работали по устаревшим датам прихода, склад – по неполным планам приёмки, а планировщики рисковали выпустить дублирующие заявки на пополнение, потому что старые заказы выглядели зависшими, хотя формально закрыты не были.
Компания не стала менять ядро, а надстроила над существующими системами рабочий слой. Он собрал воедино открытые заказы поставщикам, складские остатки, статусы отгрузок, распределение под продажи и заметки планировщиков, сопоставил данные по контейнерам, чтобы убрать дубли, и дал единый обзор сверху: доступно, распределено, под риском, на проверку. Прежние системы остались на месте – изменилось то, что у команды наконец появился слой, совпадающий с реальностью операций.
Аргумент в пользу такого подхода прост: полная замена ERP занимает от 12 до 24 месяцев и требует серьёзных вложений, а бизнесу всё это время надо работать и реагировать на сбои за дни, а не за месяцы. Дистрибьютор фармацевтики, сведя разрозненные списки исключений – из ERP, остатков распределительных центров, сигналов по отгрузкам и чувствительных к срокам годности запасов – в одну приоритизированную очередь, за первую неделю срезал ручной повторный ввод данных на 60–70%. Решения при этом остались за людьми: система дала ясность, а не отобрала суждение.
Сбои лишь делают заметной проблему, которая тлеет и в спокойные времена. Каждый запуск нового канала продаж, выход на новый рынок или смена поставщика упираются в тот же разрыв – системы, спроектированные не под ту реальность, в которой компания работает сейчас. Отсюда ставка на модульные надстройки над базовой инфраструктурой: консолидировать данные, поднимать наверх исключения и давать командам более чистый способ действовать, не дожидаясь многолетней замены ядра.
