Минимизируем простои в логистических процессах-[Копировать #26837] в Ecommerce

Минимизируем простои в логистических процессах

Взяли на техподдержку восемь систем FM Logistic и разгрузили команду разработчиков

#логистика #грузоперевозки

Привет, это STILT

С 2022 года сотрудничаем с логистическим оператором FM Logistic.

В зоне нашей ответственности — обеспечение бесперебойной работы складской инфраструктуры, процессов отгрузки заказов, сопровождаем ключевые ИТ-системы, включая WMS, ERP и интеграционные шины, а также обеспечение технической поддержки пользователей на уровнях (L1–L2-L2,5).

За три года совместной работы нам удалось выстроить процессы так, чтобы минимизировать простои и повысить предсказуемость ИТ-ландшафта заказчика.

Ключевые цифры

10 336

решено инцидентов за 2025

IT-продуктов на поддержке 24/7

с 700

до 2000

изменений в месяц — выросла скорость разработки

с 30%

до 7%

снижение эскалации на продуктовую команду

Разгрузили команду разработчиков

FM Logistic —

это международная логистическая компания, которая специализирующаяся на полном комплексе услуг: складское хранение, транспортировка, копакинг (упаковка/маркировка) и управление цепочками поставок.

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

2022 год

Устранением инцидентов в системах FM Logistic занималась проектная команда. Из-за этого, разработка новых функций и фич вставало на паузу. Ресурсы команды клиента уходили на «тушение пожаров» вместо развития продукта.

Поэтому компания решила передать рутину нам — команде, которая специализируется на техподдержке и знает как:

закрывать 95% инцидентов без привлечения дорогих Dev-ресурсов
соблюдать SLA на 99,8%
автоматизировать решение типовых запросов

Сейчас

Сейчас работаем с системами клиента на трёх уровнях:

L1 — сотрудник решает типовые инциденты по чёткой инструкции.
L2 — инженер собирает и структурирует аналитику по сложным инцидентам, интерпретирует результаты и формулирует гипотезы о возможных причинах проблем. Классифицирует и эскалирует инциденты, работает с мониторингом и логами, а также выполняет задачи по контейнеризации и тестированию API по готовым инструкциям.
L2,5 — специалист может сам решить нетиповой кейс и выявить повторяющийся баг или уникальную ошибку.

Разобрались, как работают системы

Для этого у нас есть пошаговый алгоритм, который охватывает все этапы: от мониторинга и первичной диагностики до долгосрочных улучшений. Вот как мы действуем.

Проводим диагностику и мониторинг

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

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

Анализируем и решаем проблему

После установления причины инцидента инженеры проводят устранение в соответствии с технической инструкцией.

В случае нетиповых ситуаций задействуется уровень поддержки L2. Если силами L2 устранить сбой не удаётся, проблема передаётся продуктовой команде (уровень L3).

Работаем с документацией

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

Системная работа с документацией снижает количество повторных обращений и ускоряет решение инцидентов.

Отчеты и рекомендации

По результатам работы составляем отчеты для клиента:

аналитика по инцидентам с ключевыми метриками;
функционал, который нужно доработать;
рутинные задачи, которые можно автоматизировать;
актуальную документацию.

Сократили количество однотипных тикетов

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

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

Например, когда у кладовщика глючит сканер, он не создает тикет, а идёт с проблемой  к своему руководителю. Тот прогоняет инцидент по чек-листу: перезагружает устройство, проверяет соединение, пробует другой код. Если не помогло и сканер не заработал, создает тикет для техподдержки.

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

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

Подключили YMS — систему управления движением грузовых автомобилей на территории склада

В сентябре 2022 года взяли на поддержку Yard Management System (YMS). Это система, которая фиксирует прибытие фуры на территорию склада для погрузки и разгрузки.

На момент запуска проектная команда недавно завершила разработку YMS, поэтому инциденты возникали достаточно часто.

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

На КПП склада водители прикладывают документы к сканеру для регистрации, однако периодически возникала ошибка, из-за которой в YMS поступали некорректные данные. В качестве временной меры нами выполнялся перезапуск системы; параллельно проектная команда доработала сканеры и устранила причину сбоя.

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

Приняли в работу
ещё 9 систем FM Logistic

Наш клиент использует более 60 IT-систем, но только 20 из них действительно важные — остальные 40 работают в фоновом режиме. Сейчас мы поддерживаем восемь ключевых систем,
а ещё три готовимся взять на обслуживание до конца года.

Все системы разные — одни получается принять быстро, а другие требуют большего времени для погружения.

Показываем на примерах, от чего это зависит:

Функциональность

YMS — простая система, которая отвечает в основном только за въезд-выезд транспорта. Её приёмка заняла две недели. А вот WMS — это целый «центр управления», который отвечает сразу за сборку, хранение, отгрузку, контроль сроков годности и списание товаров на складе. Из-за сложности системы ее подключение к нашей техподдержке растянулось на два месяца.

Внутренние настройки

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

Частота обновлений

BluJay используют в самых разных процессах — от обработки заказов и планирования рейсов до подбора водителей и выставления счетов в адрес транспортных компаний. Система постоянно обновляется,  из-за чего даже на этапе приемки возникают инциденты, которые усложняют подключение.

Какие проблемы
мы помогаем решить

YMS

Система управления складом

Год передачи на поддержку: 2022

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

Для лучшей координации складских и логистических операций
на территории склада проводим:

Мониторинг системы
Диагностику и устранение неполадок
Поддержку интеграции
Готовим техническую документацию

DriverApp

Приложение для водителей

Год передачи на поддержку: 2022

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

В ходе приёмки системы в логах серверного обмена выявлено 2 100 000 необработанных пользовательских запросов. Выполнена ручная обработка и очистка неактуальных сообщений, в результате чего работоспособность приложения была восстановлена.

BluJay

Система транспорта

Год передачи на поддержку: 2022

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

Каждый инцидент инженеры анализируют вручную. Например, при доставленном товаре счёт может не сформироваться или не поступить заказчику — из-за ошибки в данных, некорректного обмена с системой клиента или неактуального статуса заказа. Для восстановления корректной работы выполняется ручная корректировка счетов, повторная отправка документов или устранение ошибок на стороне склада.

Такая работа требует высокой точности и внимания к деталям, что позволяет поддерживать стабильную работу сложной системы BluJay.

Generix (WMS Infolog)

Система управления складом

Год передачи на поддержку: 2023

WMS (Infolog, Reflex. WMS-X) — складские системы, обеспечивающие контроль размещения товаров, сроков годности и приоритетности отгрузок.

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

Talend

Шина данных

Год передачи на поддержку: 2023

Talend обеспечивает надёжную передачу данных о заказах между информационными системами. Обмен выстраивается по заданной логике из функциональных блоков: подключение к базе данных, формирование запроса, создание файла заказа и его передача получателю.

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

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

HRM (Медео)

Система работы с контрагентами

Год передачи на поддержку: 2023

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

Медео имеет простую архитектуру, поэтому причины инцидентов, как правило, выявляются оперативно. Для восстановления работы выполняется ручная корректировка — например, повторная отправка документов, что занимает несколько минут и не влияет на текущие процессы.

Paradigma

Система маркировки

Год передачи на поддержку: 2023

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

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

Для восстановления корректного учёта потребовалась ручная переработка связей и повторное оформление партии.

Magento

Система работы с ecommerce

Год передачи на поддержку: 2024

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

Так, сервис печати этикеток для транспортных компаний регулярно зависал, и инженерам приходилось перезапускать его 3–5 раз за смену. Накопленная статистика позволила инициировать доработку, в результате которой был реализован механизм автоматического перезапуска сервиса.

Чем больше систем под рукой,
тем быстрее справляемся со сбоями

Как было раньше

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

Как сейчас

Все системы под рукой в одном окне. Диагностика занимает минуты, а не дни.

В 2025 году подключили 10-ю систему и количество инцидентов уровня L3 резко снизилось на 22%. Теперь решаем проблемы быстрее и реже беспокоим разработчиков.

NPS, полученный от кей-юзеров и команды разработки, составляет 9,2 из 10.

Создаем инструкции по каждому инциденту

Мы не просто устраняем сбои, но и создаем подробные инструкции по каждому инциденту.

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

Инструкции мы пишем как для себя, так и для клиентов.

Однажды FM Logistic назначила нового сотрудника для работы с системой BluJay. После одного из инцидентов мы решили уточнить у него информацию, а он в ответ прислал нам нашу же инструкцию. Так мы поняли, что всё делаем правильно.

Устранили более 90 дефектов

Чем дефект отличается от инцидента?

Инцидент — это разовый сбой в работе системы, а дефект — ошибка в коде или логике, из-за которой проблема повторяется. Например, если сервис один раз завис — это инцидент, а если системе постоянно не хватает ресурсов и из-за этого возникают сбои — это дефект.

Пофиксили дефект → предотвратили будущие инциденты.

Высвобождаем IT-ресурсы клиента: скорость разработки выросла
с 700 до 2000 изменений в месяц

Экономим IT-бюджет

Каждый месяц на обслуживание одной системы у команды из 6 человек уходит около 1000 часов. Если инцидентами занимаются разработчики, то компания теряет большие деньги: час программиста в 2–3 раза дороже, чем час саппорта.

Возвращаем разработчиков к созданию продукта

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

снижение темпов разработки и увеличение time-to-market;
потеря ключевых компетенций из-за оттока специалистов, не готовых тратить большую часть времени на решение не связанных с разработкой задач.

Наше решение: выведение операционных инцидентов из зоны ответственности продуктовой команды и передача их выделенной поддержке.

Реагируем на инцидент в течение 10 минут

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

Как это работает:

если фура уже ждёт погрузку на складе — инцидент получает высший приоритет, и мы подключаемся к решению немедленно.
если задача не влияет на операционные процессы (например, регистрация нового сотрудника в системе) — она может быть выполнена чуть позже, без ущерба для бизнеса.

Аутсорс техподдержки — это круглосуточная работа с инцидентами с закреплёнными финансовыми гарантиями. Мы берём на себя соблюдение SLA, автоматизацию типовых задач и все репутационные риски.

Именно поэтому FM Logistic после первой пилотной системы передала нам ещё девять и продлила контракт до 2028 года.

Вот как о нас отзываются в FM Logistic

Алексей Петров

FM Logistic
Руководитель IT-направления

Честно? Раньше мой телефон ночью трещал как сумасшедший. Сбой на складе в 2:00 — значит, буди меня, потом разработчиков, потом всех подряд. С тех пор как мы передали в STILT техподдержку, я впервые за 3 года ушел в полноценный отпуск. Без ноутбука.

Что изменилось реально:
Наши PM и тимлиды перестали быть «пожарными». Раньше их рабочий день заканчивался в 22:00, а начинался в 6 утра с разбора ночных ЧП. Теперь инциденты уровня L1/L2/L2,5 закрывает STILT, не дергая нас. Они просто пишут в чат: «С YMS въездом фур разобрались, причина — Х, пофиксили».

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

Рутина ушла. Бизнес-пользователи получают быструю и квалифицированную помощь от инженеров STILT.

STILT не волшебники. Иногда бывают косяки. Но они берут ответственность за наш простой, а не сливают ее. И это дорогого стоит.

Благодарность

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