Через два месяца после запуска первого 3PL CEO спросил, почему у компании до сих пор только один оператор.

Первого 3PL еще не интегрировали. Товар через него уже шел, но обмен обрабатывали вручную. Второй оператор удвоил бы нагрузку, а команда не справлялась даже с первым.

После вопроса CEO команда сосредоточилась на первой интеграции и закончила ее. Параллельно компания подписала договор со вторым оператором.

Прошел еще месяц. Второй 3PL так и не подключили, работа почти не продвинулась. При этом компания уже вела переговоры более чем с десятью потенциальными партнерами.

Собственник пригласил меня в компанию как CIO. Подключение 3PL было одной из обозначенных проблем.

Зачем понадобились региональные операторы

Компания расширяла сеть по всей стране. При расчете экономики новых объектов стоимость доставки заложили так, как будто магазины находятся рядом с собственным складом.

После открытия удаленных объектов фактические логистические расходы превысили плановые. В некоторых регионах доставка со своего склада делала работу убыточной: открывать магазины было можно, зарабатывать на них - нет.

В самом проблемном регионе нашли местного 3PL, согласовали условия и направили через него первые поставки. Они подтвердили расчет: региональный партнер обходился дешевле доставки с собственного склада.

Компания начала искать операторов в других регионах и странах. Найти партнера, согласовать условия и подписать договор удавалось быстрее, чем подключить его к системам компании.

Каждый новый 3PL превращался в отдельный ИТ-проект. Поэтому через три месяца после запуска новой логистической модели компания по-прежнему работала только с одним оператором.

Почему второй оператор не подключался

Интеграцией занималась отдельная команда: тимлид и два разработчика. Других задач у них не было.

Тимлид почти все время проводил на встречах с операторами. Его приглашали на обсуждение общих условий работы, затем на технические совещания, потом на уточнение сообщений, статусов и отдельных полей. После каждой встречи разработчики меняли интеграцию под требования конкретного партнера. Затем стороны находили очередное расхождение, снова собирались и согласовывали следующую доработку.

Так команда закончила первую интеграцию. Со вторым оператором тот же процесс начался с нуля.

Каждый 3PL приносил свои форматы и правила, а компания переделывала под них собственную систему. При более чем десяти операторах в переговорах для каждого потребовались бы отдельные встречи, проектирование и разработка.

Дополнительные сотрудники позволили бы вести больше интеграций одновременно, но не изменили бы саму модель подключения.

Я снял тимлида с общих встреч и поручил ему подготовить первую версию единого стандарта: верхнеуровневую схему обмена и спецификацию интерфейсов, одинаковую для всех 3PL.

На документ ушло три дня. После этого тимлид и один разработчик начали собирать интеграционную шину, а второй разработчик продолжил поддерживать работающий обмен с первым оператором.

Единый стандарт интеграции

До этого команда компании разбирала техническую документацию каждого партнера и адаптировала под нее свою систему.

Мы изменили порядок: компания задает стандарт обмена, а оператор реализует его на своей стороне.

Первому и второму 3PL направили новую спецификацию. После рабочих встреч документ уточнили с учетом вопросов, возникших при реальном подключении.

Первый оператор принял новый порядок и переделал свою часть. На нем же команда проверила работу шины. После завершения тестирования второй разработчик освободился от постоянных исправлений первой интеграции и подключился к общей реализации.

В базовый стандарт включили операции, необходимые для запуска поставок: передачу справочника товаров, запрос остатков, приемку и отгрузку с подтверждением основных этапов. Спецификация определяла обязательные поля, допустимые значения, форматы сообщений, коды ошибок, сроки обмена и правила повторной отправки.

Позже состав операций расширяли, не меняя базовой модели подключения. Внутреннее устройство WMS или учетной системы оставалось зоной ответственности партнера. Компания больше не переделывала свои системы под каждого 3PL.

Ответственность оператора

ИТ-служба второго оператора отказалась выполнять доработку:

  • Интеграция нужна вам. Вы и делайте.

Вопрос решила коммерческая команда самого 3PL. Для нее подключение клиента было частью сделки, поэтому она обеспечила участие своего ИТ.

С другим партнером я подключил к разговору его коммерческого руководителя и обозначил позицию компании: мы покупаем логистическую услугу и не будем за свой счет разрабатывать интеграцию за поставщика. Если оператор не готов выполнить условия клиента, компания выберет другого.

После этого речь шла уже не о месте задачи в backlog ИТ-подразделения, а о подписании или потере договора.

Одновременно мы с юристами изменили условия контрактов. В договоре закрепили обязанность оператора реализовать интеграцию по стандарту компании. Там же зафиксировали обязательные сообщения, подтверждение получения, сроки передачи, обработку ошибок, повторную отправку и SLA.

Компания отвечала за своевременную передачу информации. Оператор - за точность выполнения складских операций.

Мы направили новые требования всем 3PL, с которыми уже шли переговоры. Примерно половина партнеров приняла их и начала разработку. Остальные запросили технические встречи.

Тимлид участвовал в этих встречах, но больше не проектировал отдельную интеграцию с каждым оператором. Он отвечал на вопросы по готовой спецификации. Обычно обсуждение занимало не более 30 минут.

ИТ-службы трех операторов отказались выполнять доработки. В двух случаях их коммерческие подразделения решили вопрос внутри своих компаний. У третьего партнера коммерция не смогла договориться с собственным ИТ.

Мы прекратили переговоры и нашли другого оператора.

Тестирование и приемка

После завершения шины команда подготовила тестовую среду.

Каждый оператор после подписания NDA получал доступы, спецификацию и примеры запросов в Postman. Его ИТ-служба могла реализовать и проверить свою часть без постоянного участия наших разработчиков.

Документация описывала обязательный сценарий, который 3PL должен был пройти перед промышленным запуском. После технического тестирования проводилась бизнес-проверка. Результат подтверждал пользователь со стороны логистики, которая оставалась владельцем процесса.

Неделя подключения начиналась с момента подписания договора. За это время сотрудники оператора реализовывали обмен, проверяли его и проходили приемку.

Раньше после подписания договора начиналась серия встреч, на которых стороны только определяли будущую схему работы. Теперь оператор сразу получал требования, доступ к тестированию и критерии готовности.

Поддержка после запуска

В первый месяц разработчики контролировали интеграции через отчет с операциями и их статусами.

После стабилизации статусы и ошибки вывели в пользовательский интерфейс. Для типовых ситуаций подготовили инструкции: пользователь видел причину сбоя и выполнял предусмотренное действие. Если инструкция не помогала, обращался в ИТ.

Пограничные ошибки разбирали по журналам обмена. В них было видно, какой запрос отправила компания, что получил оператор и какой ответ вернул. По журналу определяли место сбоя по фактам, а не по предположениям сторон.

После первого месяца разработчиков привлекали к таким ситуациям редко.

Что изменилось

Перестройка заняла один месяц.

Первый 3PL до этого более двух месяцев работал без завершенной интеграции. Второго не смогли подключить за следующий месяц, хотя задачей постоянно занимались три сотрудника.

После перехода на единый стандарт новый оператор реализовывал свою часть и проходил тестирование за неделю с момента подписания договора. По этой модели подключались 3PL в трех странах.

Раньше интеграцией постоянно занимались три человека. После стабилизации поддержку и развитие обеспечивали два специалиста, каждый из которых тратил на эту работу примерно половину своего времени.

Подключение нового 3PL больше не требовало отдельного проектирования, постоянных встреч и полной занятости команды из трех человек.