что такое сап магазина пятерочка
Что такое SAP?
И как получилось, что 77% мировой торговли, в том числе 78% поставок продуктов питания, проходит через программы SAP?
ERP — то место, где компании хранят основные операционные данные. Мы говорим о прогнозах продаж, заказах на покупку, складских запасах, а также о процессах, которые срабатывают на основе этих данных (например, выплаты поставщикам при оформлении заказов). В некотором смысле ERP является «мозгом» компании — она хранит все важные данные и все действия, которые инициируются этими данными в рабочих процессах.
Но прежде чем полностью захватить современный мир бизнеса, как вообще появилось это программное обеспечение? История ERP начинается с серьёзной работы по автоматизации офисной деятельности в 1960-е годы. Ранее, в 40-е и 50-е годы происходила главным образом автоматизация механической работы «синих воротничков» — вспомните General Motors, создавшую свой отдел автоматизации в 1947 году. А вот автоматизация работы «белых воротничков» (часто с помощью компьютеров!) началась в 60-е.
Автоматизация 60-х: появление компьютеров
Первыми бизнес-процессами, которые автоматизировали с помощью компьютеров, стали расчёт зарплаты и выставление счетов. Раньше целые армии офисных работников вручную подсчитывали часы работы сотрудников в бухгалтерских книгах, умножали на почасовую ставку, затем вручную вычитали налоги, вычеты на пособия и так далее… всё это только для того, чтобы посчитать зарплату за один месяц! Этот трудоёмкий, повторяющийся процесс был подвержен человеческим ошибкам, при этом он идеально подходит для компьютерной автоматизации.
К 60-м годам многие компании для автоматизации расчёта зарплаты и выставления счетов использовали компьютеры IBM. Процессинг данных —устаревший термин, от которого осталась только компания Automatic Data Processing, Inc. Вместо него сегодня мы говорим «ИТ». Тогда ещё не сформировалась отрасль разработки программного обеспечения, поэтому в отделы ИТ часто брали аналитиков и учили их программировать на месте. Первый в США факультет Computer Science открыл университет Пердью в 1962 году, а первый выпуск по специальности состоялся спустя несколько лет.
Написание программ для автоматизации/обработки данных в 60-е годы было сложной задачей из-за ограничений памяти. Не было ни языков высокого уровня, ни стандартизированных операционных систем, ни персональных компьютеров — только большие дорогие мейнфреймы с небольшим объёмом памяти, где программы запускались на катушках магнитной ленты! Программисты часто работали с компьютером по ночам, когда он был свободен. Для компаний вроде General Motors обычным делом было писать собственные операционные системы, чтобы получить максимальную отдачу от своих мейнфреймов.
Cегодня мы запускаем прикладное программное обеспечение в нескольких стандартных операционных системах, но такого не было до 1990-х гг. В средневековую эпоху мейнфреймов 90% всего программного обеспечения писалось на заказ, и только 10% продавалось в готовом виде.
Такая ситуация глубоко повлияла на то, как компании развивали свои технологии. Некоторые предполагали, что будущее за стандартизированным оборудованием с неизменной ОС и языком программирования, как система SABRE для авиационной промышленности (которая используется до сих пор!) Большинство компаний продолжали создавать собственное полностью изолированное программное обеспечение, часто изобретая велосипед.
Рождение стандартного программного обеспечения: расширяемая программа SAP
В 1972 году пять инженеров уволились из IBM, чтобы заключить контракт на поставку программного обеспечения с крупной химической фирмой под названием ICI. Они основали новую компанию под названием SAP (Systemanalyse und Programmentwicklung или «системный анализ и разработка программ»). Как и большинство разработчиков программного обеспечения в то время, они в основном занимались консалтингом. Сотрудники SAP приходили в офисы клиентов и разрабатывали софт на их компьютерах, в основном, для управления логистикой.
Но самое главное, программное обеспечение SAP изначально создавалось расширяемым. В первоначальном контракте с ICI компания SAP не создавала программное обеспечение с нуля, как было принято в то время, а писала код поверх предыдущего проекта. Когда SAP выпустила своё программное обеспечение для финансового учёта в 1974 году, то изначально планировала в будущем писать поверх него дополнительные программные модули и продавать их. Такая расширяемость стала определяющей особенностью SAP. В то время взаимодействие между клиентскими контекстами считалось радикальной инновацией. Программы писались с нуля для каждого клиента.
Важность интеграции
Когда SAP представила свой второй программный модуль для производства в дополнение к первому финансовому модулю, эти два модуля смогли легко взаимодействовать друг с другом, поскольку у них была общая база данных. Такая интеграция сделала сочетание модулей значительно более ценным, чем просто две программы по отдельности.
Поскольку ПО автоматизировало определённые бизнес-процессы, его влияние в значительной степени зависело от доступа к данным. Данные заказа на закупку хранятся в модуле продаж, данные по запасам продукции хранятся в модуле склада и т. д. И поскольку эти системы не взаимодействуют, их регулярно нужно синхронизировать, то есть сотрудник вручную копировал данные из одной базы в другую.
Интегрированное ПО решает эту проблему, облегчая коммуникацию между системами компании и позволяя новые виды автоматизации. Такого рода интеграция — между различными бизнес-процессами, а также источниками данных — является ключевой особенностью ERP-систем. Это стало особенно важным по мере развития аппаратного обеспечения, что открывало новые возможности автоматизации — и системы ERP процветали.
Скорость доступа к информации в интегрированном ПО позволяет компаниям полностью изменить свои бизнес-модели. Компания Compaq с помощью ERP внедрила новую модель «производство по заказу» (то есть сборка компьютера только после явного получения заказа). Эта модель экономит деньги, уменьшая складские запасы, полагаясь на быстрый оборот — именно то, в чём помогает грамотная ERP. Когда IBM последовала тому же примеру, то сократила время доставки комплектующих с 22-х до трёх дней.
Как на самом деле выглядит ERP
Слова «корпоративное программное обеспечение» никак не ассоциируется с модным и удобным интерфейсом, и SAP не исключение. Базовая установка SAP содержит 20 000 таблиц БД, 3000 из которых являются таблицами конфигурации. В этих таблицах около 8000 конфигурационных решений, которые нужно принять ещё до начала работы программы. Вот почему SAP Configuration Specialist — это реальная профессия!
Несмотря на сложность настройки, программное обеспечение SAP ERP обеспечивает ключевую ценность — широкую интеграцию между собой нескольких бизнес-процессов. Эта интеграция приводит к тысячам вариантов использования в организации. SAP организует эти варианты использования в «транзакциях», которые представляют собой бизнес-действия. Некоторые примеры транзакций включают «создание заказа» и «отображение клиента». Эти транзакции организованы в формате вложенного каталога. Таким образом, чтобы найти транзакцию «Создать заказ на продажу», вы идёте в каталог «Логистика», затем «Продажи», затем «Заказ», и там найдёте фактическую транзакцию.
Если назвать ERP «браузером транзакций», то это будет удивительно точным описанием. Он очень похож на браузере, тут есть кнопка «Назад», кнопки зуммирования и текстовое поле для кодов “TCodes”, эквивалент адресной строки в браузере. SAP поддерживает более 16 000 типов транзакций, поэтому навигация по дереву транзакций может быть сложной без этих кодов.
Несмотря на головокружительное количество доступных конфигураций и транзакций, у компаний всё равно встречаются уникальные варианты использования, им нужно тонко настраивать свои действия. Для обработки таких уникальных рабочих процессов у SAP есть встроенная среда программирования. Вот как работает каждая часть:
Данные
В интерфейсе SAP разработчики могут создавать собственные таблицы БД. Это реляционные таблицы как обычные базы SQL: столбцы различных типов, внешние ключи, ограничения значений, а также разрешения на чтение/запись.
Логика
SAP разработала язык под названием ABAP (Advanced Business Application Programming, первоначально Allgemeiner Berichts-Aufbereitungs-Prozessor, по-немецки «общий процессор создания отчётов»). Он позволяет разработчикам запускать индивидуальную бизнес-логику в ответ на определённые события или по расписанию. ABAP — это язык с богатым синтаксисом, здесь примерно втрое больше ключевых слов, чем в JavaScript (см. реализацию игры 2048 на языке ABAP). Когда вы написали свою программу (в SAP есть встроенный редактор для программирования), то публикуете её как собственную транзакцию, вместе с индивидуальным кодом TCode. Можете настроить существующее поведение с помощью обширной системы хуков, которые называются «бизнес-надстройками» (add-ins), где программа настраивается для запуска при выполнении определённой транзакции — аналогично триггерам SQL.
SAP также поставляется с конструктором для создания UI. Он поддерживает драг-н-дроп и поставляется с удобными функциями, такими как сгенерированные формы на основе таблицы БД. Несмотря на это, его довольно трудно использовать. Моя любимая часть конструктора — рисование столбцов таблицы:
Трудности внедрения ERP
Интегрированная природа ERP означает, что для её внедрения требуются усилия компании целиком. А поскольку компании получают выгоду только после повсеместного внедрения, это особенно рискованно! Внедрение ERP — не просто решение о покупке: это обязательство изменить свои методы управления операциями. Установка программного обеспечения — это легко, перенастройка рабочего процесса всей компании — вот где основная работа.
Для внедрения у себя ERP-системы клиенты часто нанимает консалтинговую фирму, такую как Accenture, и платят ей миллионы долларов за работу с отдельными бизнес-подразделениями. Аналитики определяют, как интегрировать ERP в процессы компании. И как только интеграция начинается, компания должна начать обучение всех сотрудников, как использовать систему. Gartner рекомендует резервировать 17% бюджета только на обучение!
Современная индустрия ERP
Крупнейшими игроками являются Oracle и SAP. Хотя обе являются лидер ами рынка, их ERP-продукты удивительно отличаются. Продукт SAP был в основном построен внутри компании, в то время как Oracle агрессивно скупила конкурентов, таких как PeopleSoft и NetSuite.
Oracle и SAP настолько доминируют, что даже Microsoft использует SAP вместо своего собственного ERP-продукта Microsoft Dynamics.
Поскольку в большинстве отраслей довольно специфические потребности в ERP, у Oracle и SAP есть готовые конфигурации для многих отраслей, таких как пищевая, автомобильная и химическая, а также вертикальные конфигурации, такие как процессы организации продаж. Тем не менее, всегда остаётся место для нишевых игроков, которые, как правило, ориентируются на конкретную вертикаль:
Однако специализация — не единственная возможность найти свою нишу на рынке. Некоторые стартапы пытаются вывести на рынок более современные программные платформы. Примером может служить Zuora: она предлагает возможность интеграции (с разными ERP!) по подписке. Стартапы вроде Anaplan и Zoho предлагают то же самое.
ERP на подъёме?
В 2019 году SAP чувствует себя прекрасно: в прошлом году выручка составила €24,7 млрд, а рыночная капитализация сейчас превысила €150 млрд. Но мир программного обеспечения уже не тот, что раньше. Когда SAP впервые появилась, данные были изолированы и трудно интегрировались, так что хранение всего этого в SAP казалось очевидным ответом.
Но теперь ситуация быстро меняется. У большинства современных корпоративных программ (например, Salesforce, Jira и т. д.) есть бэкенд с хорошими API для экспорта данных. Формируются озёра данных: например, Presto облегчает соединение между собой баз данных, невозможное всего несколько лет назад.
Хозяева «Пятерочки» и «Перекрестка» перенесли все SAP-системы из-за границы в российский ЦОД
Массивная миграция ИТ-систем
Как сообщили CNews в X5 Retail Group, компания совместно с SAP завершила масштабный проект миграции своих ИТ-систем в российский ЦОД. По данным компании, функциональная структура проекта включала 11 систем, в том числе, SAP ERP, с суммарным объемом данных порядка 150 ТБ.
Итогом проекта миграции стало создание в России новой ИТ-инфраструктуры X5 Retail Group для SAP ERP и других ИТ-систем. В компании также заявили, что в связи с консолидацией всех ИТ-систем в России запланировано завершение эксплуатации европейского ЦОДа.
«В рамках одной из крупнейших на российском рынке миграций мы перевели 11 SAP-систем, на которых каждую секунду работает весь бизнес Х5, – сказал Андрей Звеков, директор по инфраструктуре бизнес-единицы «Х5 технологии». – На новое оборудование было переведено около 2000 интеграционных потоков, через которые системы обмениваются данными. Общее число всех специалистов, участвующих в реализации проекта, достигало 120 человек».
Новая инфраструктура с запасом прочности
По данным Х5 и SAP, реализованный проект – единственный опыт подобного масштаба, когда миграция SAP ERP с такой большой базой данных произведена незаметно для бизнес-подразделений, с соблюдением непрерывности процессов и без их остановки.
«Переезд одной из крупнейших в мире инсталляций SAP ERP — уникальный проект для российского рынка как с точки зрения объема перенесенной базы данных, так и с точки зрения скорости миграции без остановки основных бизнес-процессов, – отметил Андрей Горяйнов, заместитель генерального директора SAP CIS. – Проект был реализован силами большой команды, эксперты SAP были привлечены еще на этапе планирования проекта и далее предоставляли ресурсы, экспертизу и поддержку на всех этапах миграции».
Как сообщили CNews в X5 Retail, в процессе миграции на новую инфраструктуру также было произведено обновление операционных систем и другого корпоративного ПО. Новая ИТ-инфраструктура спроектирована и создана с расчетом на «достаточный запас производительности для стабильной работы информационных систем в высокие сезоны», пояснили в X5 Retail.
По словам Андрея Звекова, новая, более надежная ИТ-инфраструктура, созданная в российском ЦОДе компании, обеспечивает «достаточный запас производительности для стабильной работы информационных систем в высокие сезоны следующих двух лет».
В настоящее время ИТ-инфраструктура X5 Retail Group включает такие системы SAP, как SAP for Retail, SAP ERP HCM, SAP BW/4HANA, SAP BPC, SAP Mobile Documents, SAP BI, SAP PI, SAP ERP и другие.
В конце августа X5 Retail Group сообщила о начале интеграции в свою ИТ-систему платформы для хранения и обработки данных SAP HANA в облачной среде SAP HANA Enterprise Cloud на ресурсах ЦОД SAP в Москве. Внедрение обеспечит ритейлеру получение отчетности о торговых операциях практически без задержки – с разницей в 30 минут, в то время как ранее для оперативного анализа были доступны данные только за предыдущий день.
По итогам III квартала 2020 г. X5 Retail Group объявила о росте выручки на 15,3% год к году до 486,6 млрд руб., при этом чистая прибыль компании составила 7,8 млрд руб.
Автозаказ: как сделать так, чтобы нужные продукты сами попадали на полки 17 000 магазинов по всей стране
В школе все мы решали задачки вида «… едет из пункта А в пункт Б». Речь преимущественно шла о скорости и времени – как быстро доберётся транспортное средство? Реальность, однако, подбрасывает задачки значительно интереснее: «Существует масштабная ритейл-сеть по продаже товаров, которой необходимо, чтобы огромное количество номенклатурных позиций доезжало в каждый из 17000 магазинов, расположенных на половине площади самой большой страны в мире, вовремя и в нужном количестве». Для решения такой задачи в X5 Group существует ряд реализованных решений, и одним из самых важных является процесс автозаказа товаров.
Техническую поддержку этого направления в X5 Group обеспечивает команда 2-SAP Логистики.
Наша команда поддерживает решения, которые помогают бесперебойно обеспечивать полки магазинов свежими продуктами, а покупателям на территории всей России доступны к продаже десятки тысяч товарных позиций.
Автозаказ – это комплекс процессов управления запасами и заказами
Поддержание объемов товарных запасов на установленном уровне, который обеспечивает постоянное наличие товара при оптимальных запасах в системе. Это достигается путем автоматического выполнения процессов:
Экономическое обоснование поддерживаемого уровня.
Контроль за состоянием запасов.
Для этого используются разные механизмы прогнозирования в зависимости от формата магазина и гибких настроек в системе.
Прогноз продаж, построенный SAP – это прогноз спроса на период 42 дня, который строится на исторических данных по продажам. Период анализа продаж и модель прогноза определяется из настройки Профиля прогноза.
В периоде анализа продажи могут быть Плановые – регулярные продажи и Внеплановые – промо продажи.
Прогноз запускается ночью (по календарю) в фоновом режиме массово для всех комбинаций товар-магазин, в рамках ассортимента и является частью Автозаказа.
Модель прогноза – определенный алгоритм расчета прогноза, который устанавливается для каждого товара в магазине.
Для больших форматов прогнозирование и создание рекомендаций для Автозаказа производится в JDA, алгоритмы и логика расширены в данной системе и позволяют учитывать огромное количество параметров для расчета.
Около 04:30 эти данные по потребности из JDA поступают в SAP, где обрабатываются фоновым заданием с интервалом запуска каждые 15 минут, в результате чего создаются Автозаказы.
Автозаказ подскажет, какие товары из-за их низкой оборачиваемости можно вывести из постоянного товарооборота, какие заказные товары пользуются популярностью и их можно вводить в постоянный ассортимент, уменьшаются ли остатки по товарам, выводимым из ассортимента и т.п.
Большую роль этот функционал играет для персонала магазинов магазинах, так как он исключает необходимость формировать заказы вручную. За исключением отдельных случаев всё происходит в автоматическом режиме с учетом большого количества факторов и сложных расчетов. Автозаказ облегчает ежедневный труд тысяч сотрудников по всей стране – от Калининграда до Новосибирска.
Через автозаказ пополняется до 80% основного ассортимента магазинов, а ручное пополнение выполняется для товаров in-out.
Схема реализации товара:
Классическое пополнение происходит примерно в таком виде: представим, что есть некий товар, допустим, это пакет молока, который поставляется напрямую от внешнего поставщика в магазин торговой сети «Пятёрочка».
Так выглядит децентрализованная цепочка:
в 00:00 стартует задание по АЗ, в период его работы по нашему товару рассчиталась потребность, сформировался автозаказ, и он бы отправлен из SAP в программу магазина GK(Пятёрочка), там у сотрудников магазина есть время отредактировать рассчитанное кол-во (в большую или меньшую сторону) до наступления времени автосогласования (например, до 11 утра, время зависит от тайминга поставщика, т.е. до какого момента он должен получить заказ, чтобы собрать и вовремя привезти заказ в магазин);
после внесения корректировок эти изменения отправляются в SAP, и дальше происходит процесс автосогласования – заказ согласовывается и автоматически отправляется поставщику по почте или его провайдеру (в зависимости от того, по какой схеме поставщик работает). Например, если поставщик работает по EDI (через электронный документооборот), то после доставки заказа в его систему, нам провайдер передает информацию о размещении заказа в своем ПО и в системе ER2 заказ переходит в статус «Размещен»;
далее нам поступает буфер приемки, который мы передаем в ПО магазина. По этому буферу магазин осуществит приемку товара от поставщика. После осуществления приемки поставщику отправляется информация об этом. На этом путь закончен, сотрудникам магазина остается выставить на полки товар и продать его счастливым покупателям.
Автозаказ (Ночной профиль) – фоновое задание, имеющее внутри себя несколько шагов, выполняющих определённые функции. Результатом задания является создание заказов на закупку товаров. Запускается параллельно по магазинам.
На ежедневной основе автозаказ формирует более 400 000 тысяч заказов для магазинов, как на распределительные центры, так и внешним поставщикам.
Продажи за период в прошлом
Прогноз на период в будущее (на основании продаж строится прогноз SAP)
Остатки на объекте получателе (остаток в SAP на момент расчёта)
Открытые заказы (заказы на поставку и возвраты)
Продажи приходят из магазинов каждый вечер до расчёта фонового задания Автозаказа.
Факт получения продаж запускает расчет Автозаказа. Если до 03:00 продажи не получены SAP ERP, то происходит безусловный запуск задания Автозаказа.
Автозаказ формируется строго по графику заказа/поставки согласованному с поставщиком, так категории FRESH и ULTRA FRESH, как правило, заказываются и поставляются в магазины ежедневно.
Кроме того, для каждого товара в магазине при расчете потребности учитывается Презентационный запас и дополнительные выкладки. В зависимости от продаж количество может варьироваться от нескольких единиц товара до нескольких полок.
Для того, чтобы заказать оптимальное кол-во товара, учитывается прогноз, который строится в SAP в момент расчета Автозаказа.
Если по этому товару уже есть запас или размещенный заказ, который еще не закрыт, то система также учтёт это при определении размера финального заказа.
Автозаказ определяет цепочку и поставщика по каждому товару для каждого магазина, согласно записей книги источников поставок (смежный функционал, автоматизирован, и ведется также в SAP) и формирует заказ.
Запускается задание ежедневно в 00:00. Первыми выполняются расчеты по регионам Сибирь и Урал, далее по регионам Волга, ЮГ, Москва, Центральные регионы и Северо-запад. Последовательность выполнения крайне важна, т.к. наши магазины расположены в разных часовых поясах, и пока в Москве все сладко спят, в Сибири уже в разгаре рабочий день.
Задача нашей команды контролировать, поддерживать и обеспечивать работоспособность автозаказа на каждом шаге, а в случае каких-либо сбоев в системе, проактивно реагировать и минимизировать возможный ущерб для бизнеса и для наших покупателей.
Для этого мы реализовали различные системы мониторинга, инструменты для анализа, а в случае необходимости и возможность отправки в магазины резервных шаблонов заказа.
Такие ситуации практически исключены, но мы готовы к любому повороту событий, и, если вдруг в системе случился какой-то сбой и автозаказ не сформировался, мы можем запустить программу по выгрузке в магазин шаблонов заказов. Шаблон заказа – это по- сути прайс-лист в рамках ассортимента магазина на определенного поставщика, но без предложенного количества. Такой шаблон позволяет магазинам сделать заказ самостоятельно на необходимое количество товара в случае форс-мажора.
Также предусмотрен инструмент для выгрузки резервных заказов, рассчитанных накануне, в случае сбоев в системе JDA по прогнозированию и пополнению магазинов больших форматов «Перекрёсток» и «Карусель».
«Выручай-рейсы» в X5 Transport. Как мы сократили затраты на доставку путем автоматизации «пересменки» водителей
X5 Group — это более 18 000 магазинов «Пятёрочка» и «Перекресток» по всей стране. И именно от логистики и эффективности транспортных процессов зависит насколько быстро и своевременно нужные товары будут оказываться на полках. Ранее мы уже рассказывали о том как устроен автозаказ и как мы обновили архитектуру системы мониторинга автотранспорта. Сегодня продолжим посвящать вас во внутреннюю кухню Х5 Transport.
1. На чем «держится» логистика Х5 Group
Логистический каркас построен на нескольких решениях:
SAP ERP – корпоративная система управления ресурсами предприятия
X5 Transport – мобильное приложение для водителей, получение и назначение водителей на рейс.
TMS ORD/LTL – система планирования и оптимизации маршрутов.
WMS NQ/EXCEED – система управления складом.
WMОS Manhattan – система управления складом.
СОМ – система оперативного мониторинга транспорта. Об этой системе мы вам рассказывали ранее в статье.
Оптимизация процессов логистики требует постоянного изменения в системном ландшафте, как в части доработок бизнес-логики, так и в части архитектуры. Поэтому мы уже начали рассматривать возможности внедрения таких решений как SAP TM, взамен используемых в настоящий момент систем управления транспортом, но об этом мы вам расскажем чуть позже в следующих постах.
2. В чем состоял бизнес-кейс
X5 Transport, как и любая транспортная компания, всегда хочет быть конкурентоспособной в части тарифообразования, даже когда речь идет о внутрикорпоративном рынке перевозок, ведь тарифы на перевозку также влияют на стоимость товара на полке. В качестве одного из драйверов снижения тарифов нами было найдено решение по оптимизации работы водителей.
Суть решения состоит в том, что водитель, завершающий свою смену и готовящийся к окончанию рабочего дня, может помочь своему сменщику (которому он передает автомобиль) в его дальнейшей работе, мы назвали это «Выручай-рейс.
Водитель, завершающий смену, вместо ожидания пересменки, может с пользой провести это время, выручив своего сменщика путем заблаговременной загрузки машины товаром для рейса своего сменщика. Эта инициатива также стимулируется материально – водитель, который выручает, получает за это вознаграждение.
Анна Блынских, Начальник управление развития городского экспедирования БЕ «Транспорт»
3. Как мы это автоматизировали
На старте проекта, весь учет и планирование «выручай-рейсов» выполнялся частично вручную в Excel, частично в SAP диспетчерами на местах. Вознаграждения за выручай-рейсы учитывались также в ручном режиме.
Когда обдумывали план по автоматизации, приняли решение решение, что ограничимся планированием «выручай-рейсов» в ORD, автоматизацией базовых процессов и начисления вознаграждений в SAP. Планировали не затрагивать WMS-системы и документооборот в принципе. Согласовали с юристами, что процесс будет легитимный, и мы можем просто делать вычерки в транспортных накладных, которые печатаются на складах.
Что такое вычерки – водителю печатаются товарно-сопроводительные документы на груз, там указан водитель, который выручает своего коллегу. В момент передачи документов и груза другому водителю, которого он выручает, необходимо зачеркнуть фамилию, сходить к диспетчеру АТП (авто-транспортного предприятия) и завизировать это печатью и подписью.
В итоге все же пришлось заняться доработкой WMS-систем и изменением документооборота, так как ранее согласованный процесс очень сильно повлиял на трудозатраты и ресурсы диспетчера, которых оказалось недостаточно для того, чтобы обработать весь пул выручай-рейсов, пришлось бы нанимать дополнительный штат специалистов.
Мы начали прорабатывать новый процесс документооборота, который все же привел нас к доработке WMS-систем. Суть нового процесса заключалась в печати транспортной накладной с указанием двух водителей и интеграцию изменений в процесс карусельной печати на РЦ, только на это мы потратили около месяца, в первую очередь на согласования с бизнес-заказчиками, т.к. необходимо было учесть все процессы, всю цепочку поставок, согласовать решение с методологами, бухгалтерами и налоговиками, также наложился факт выпуска Минтрансом новой редакции транспортной накладной в январе 2021 года.
Александр Тарасенков, Руководитель проектов БЕ «Технологии»
4. С какими проблемами мы столкнулись в процессе автоматизации
Основной проблемой для нас явилась, как вы уже наверное догадались, доработка WMS-систем. Команде пришлось изыскивать ресурсы внутренних специалистов для того, чтобы вписаться в уже новые сроки проекта.
Параллельно с планированием доработок базовой WMS, команда проработала автоматизацию в целевой WMS-системе Manhattan, которая уже находится на стадии тиражирования. Пришлось договориться с командой внедрения Manhattan и встроиться в их сборку для тиражирования, тем самым мы снизили нагрузку на проектную команду выручай-рейса в части мониторинга качества тиража функционала на РЦ.
Сама суть доработок WMS систем заключалась в настройке процесса склада для двух водителей по одному рейсу, ведь это по сути явилось новшеством для компании, раньше была исключительно связка 1 водитель = 1 рейс.
Рисунок 1. Инфрмация в WMS по двум водителям.
5. Как пришли к результату
О том, как решили проблему с разработкой WMS систем рассказали в предыдущей части статьи, но повторимся – нам удалось мобилизовать несколько команд. Первая команда – релизная, которая обеспечила нам базовые доработки WMS NQ Exceed без привлечения дополнительных людей. Для этого, пришлось поработать с пулом задач в релизах, договориться со смежными заказчиками о более высоком приоритете нашего проекта. Вторая команда – проектная, нам удалось встроиться в сборку WMOS Manhattan для дальнешего тиражирования на РЦ.
По мере реализации проекта были сделаны и другие доработки:
Доработками системы планирования ORD занимался вендор. При выборе пула смен система ORD автоматически определяет те смены, которые подходят для планирования выручай-рейса, исходя из остаточного времени рейса. Доступно как ручное, так и автоматическое планирование.
Рисунок 2. Мастер кнопка для планирования смен ЗнС
Система рассчитала время доступное на предзагрузку 229 минут. (рисунок 3).
Рисунок 3. Расчитанный рейс с доступмным временем на загрузку.
Автоматизацией процессов SAP занималась внутренняя команда Х5. Был автоматизирован расчет начисления вознаграждения за выручай-рейс – расчет происходит автоматически, после закрытия путевого листа в режиме онлайн.
Доработками системы оперативного мониторинга транспорта занимался вендор. Система в режиме online «разделяет» рейсы на основе выявления факта прибытия и убытия из геозоны «пересменки», также строит аналитическую отчетность в разрезе двух водителей по рейсу.
Функционал получения заказов, подписания и передачи ЭТРН для водителей реализован в нашем мобильном приложении для водителей X5 Transport.
6. Какие выгоды получили от внедрения
В первую очередь мы рассчитываем на снижение нагрузки на комплектацию – мы можем загрузить машину раньше, а не в момент пиковой нагрузки на склад, таким образом оптимизируется количество комплектовщиков и выравнивается нагрузка на склад в высокий сезон.
Если говорить об объемах, то выручай рейс сейчас доступен на 6 складах торговой сети «Пятерочка», что составляет, примерно 200 рейсов в день. Ежеденевно в выручай-рейсе учавствует 400 водителей. К концу года эта цифра вырастет до 350 в сутки (700 водителей), а если этим заинтересуется Перекресток, то это еще плюс 100 выручай-рейсов (200 водителей).
Что касается затрат на перевозки, то стоимость выручай-рейса для торговой сети на 4% ниже стоимости обычного рейса. Транспортные средства, используемые при выручай-рейсах, оборачиваются более эффективно.
Новый процесс документооборота, о котором мы говорили выше, позволил сократить трудозатраты диспетчеров АТП на обработку документов. Для работы по старому процессу и без автоматизации, необходимо было расширять штат диспетчеров на АТП до четырех вместо двух.
7. Перспективы развития решения
В качестве основного направления развития решения мы видим автоматизацию процесса передачи электронной транспортной накладной (ЭТРН). Сейчас эту задачу решает диспетчер АТП нажатием на кнопку – документооборот электронный, но подтверждение человека все равно необходимо. В перспективе мы хотим сделать передачу ЭТРН полностью автоматизированной и не зависящей от диспетчера. Процесс будет запусться после выписки путевого листа на водителя, которого выручают. Передача будет сопровождаться генерацией акта приема-передачи транспортного средства, что позволит разграничить зоны ответственности двух водителей (передающего и принимающего). Таким образом, после утверждения Минтрансом формата ЭТРН, у нас будет польностью автоматизированый выручай-рейс.
Никита Семин, Руководитель направления проектов БЕ «Технологии»