Досвід побудови рішення автопоповнення товарів у магазинах компанії INTERTOP

На початку – короткий опис організаційної структури компанії INTERTOP з точки зору логістики.  

На малюнку 1 класична схема товарних потоків, що використовується в галузі Retail. У компанії INTERTOP є один великий розподільчий центр у Київській області та безліч магазинів різного формату й розмірів у містах та регіонах. Розподільчий центр (далі скорочено РЦ) і всі магазини належать одній юридичній особі (одна балансова одиниця). Усі закупівлі (імпорт і локальні) доставляються від постачальників тільки в РЦ. Водночас РЦ слугує джерелом для поставок товарів у магазини. Чи не правда, зручна організаційна структура в рамках системи SAP? На мій погляд, це класична схема побудови потоків товарів у Retail компанії. 

Загалом побудова рішення поповнення запасів товарів у магазинах ділиться на два потоки. PUSH – стратегія, яка використовується в даному рішенні при первинному заході нової моделі товару в торговельну мережу. І PULL – процес із підтримки запасів товарів у магазинах на певному рівні.

PUSH-процес 

Давайте розглянемо докладніше PUSH-процес розподілу товарів по магазинах і оптових клієнтах.  

Перед початком кожного сезону (в налаштуваннях системи визначено 2 сезони: весна-літо, осінь-зима) менеджер по товарних групах на підставі своєї експертної думки визначає, які нові моделі товарів і в якому обсязі (в розрізі кожного магазину) будуть користуватися попитом. Це планування відбувається поза системою. Після узгодження цих планів у системі S4/HANA завантажуються основні дані нових товарів. Специфіка Fashion полягає в тому, що взуття, одяг і багато інших товарних груп ведуться, як правило, з розмірною сіткою (малюнок 2). Це передбачає створення родового конфігурованого товару (модель + колір) з підлеглими йому варіантами (розмірами) товарів. Варіанти побудови ведення довідника товарів можуть бути різними, але на цьому проєкті було обрано такий спосіб. 

Крім того, при плануванні товарного розподілу за методом PUSH слід враховувати, що майже всі постачальники доставляють розмірні товари в упаковках, де міститься кілька розмірів однієї моделі товару. В термінах системи SAP (дивіться малюнок 3) така упаковка товару називається Prepack (структурний товар).

Отже, в S4/HANA плани з початкового розподілу нових моделей товарів узгоджені, нові моделі з розмірними сітками та структурні товари створені. Наступний крок – це створення таблиць розподілу (Allocation tables).  Таблиця розподілу – це інструмент розподілу товарів, що використовується для планування, контролю та моніторингу поставок на підприємства (магазини, розподільчі центри). Вони використовуються, наприклад, під час первинного розподілу матеріалів, розподілу рекламних товарів, розподілу запасів і розподілу імпортних товарів, що закуповуються централізовано (малюнок 4). 

На цьому проєкті було розроблено програму з автоматичного завантаження розподільчих відомостей на підставі Excel-файлу шаблону. Причини написання такої програми наступні: 

1. Таким чином полегшується процес створення документів з великою кількістю товарних позицій у поєднанні з групами магазинів.  
2. У процесі створення таблиці розподілу нові товари розподіляються на асортимент магазинів, куди планується поставка. Таким чином, на локальний асортимент магазину розподіляються як Prepack товар, так і його розмірні варіанти.  
3. Після розподілу товарів на локальний асортимент магазину виконується налаштування автопоповнення в картці товару. Необхідна кількість товару в магазині визначається на підставі налаштування. Наприклад, у компанії є флагманські, середні та малі магазини – для кожного формату оптимально підтримувати певний обсяг вільного запасу. 
4. Додаткова перевірка в програмі дозволяє швидко визначити помилки в основних даних товарів. 

Після створення розподільчої таблиці окремим процесом запускається створення подальших документів – замовлень на переміщення (STO) товарів з РЦ у магазин або створення збутових замовлень (SO) оптовим клієнтам. Надалі цей список вихідних поставок буде планом з відвантаження товарів після доставки в РЦ від постачальника. 

Паралельно з процесом створення розподільчих таблиць відділ закупівель виконує планування закупівлі товарів (в основному у вигляді Prepack упаковок розмірних товарів) на підставі планів розподілу, плюс запас на наступні продажі. Усі наступні поставки товарів від постачальників менеджери планують за результатами продажів товарів у магазинах, без прогону планування потреби товарів (MRP) на рівні РЦ. Планування потреби в матеріалах не використовується на рівні РЦ у зв’язку з великим горизонтом планування закупівель у Retail Fashion і постійною зміною моделей товарів. 

Коли товар надходить у РЦ від постачальника, на складі в системі управління складом WMS уже є план з розподілу одиничних і Prepack товарів (за вихідними поставками) з урахуванням рівнів пріоритету. Так само в частині закупівельних замовлень є інформація щодо розподілу товарів по магазинах. Усе це дає змогу розподілити товари, що надійшли від постачальника в РЦ, між магазинами наскрізним процесом без розпакування і тимчасового зберігання на складі. Складські операції зводяться до перенесення Prepack упаковок товарів з місця приймання в зону відвантаження. Потім відбувається відвантаження з РЦ в запас у дорозі у напрямку до магазину або відвантаження оптовому клієнту. 

При надходженні Prepack товару в магазин відбувається його автоматичне розпакування. На рівні магазинів ми оперуємо тільки одиничними товарами або варіантами розмірів родового товару. Коли в систему S4/HANA по інтерфейсу надходить підтвердження надходження товару на замовлення на переміщення, додатково (у точці розширення системи) відбуваються такі дії: 

1. Перевіряється, що одиничний товар або варіант родового товару вперше надходить у магазин.
2. Якщо виконується умова з пункту 1, то в даних картки товару на рівні магазину проводиться активація PULL-процесу (автопоповнення).

На цьому ланцюжок з початкового поділу товару методом PUSH закінчується. 

PULL-процес, проблеми та їх вирішення

Тепер ми переходимо до процесу PULL – підтримання запасів товару в магазинах на необхідному рівні. Тип MRP і рівень підтримки запасу в магазині у нас в даних товару вже встановлені після першого надходження товару. Здавалося б, залишається спланувати фонове завдання з прогону планування потреби (MRP) на рівні магазинів і автоматично створювати заявки на дефіцит товару (малюнок 5). Але виникають труднощі з різними форматами зберігання розмірних товарів у магазині та РЦ. На рівні РЦ товар із розмірною сіткою надходить у вигляді Prepack, а в магазині зберігаються розмірні товари (як варіанти родового товару) і тип MRP із точкою замовлення вказується на рівні варіанта родового товару. І виходить, що перевіряти наявність і поставляти з РЦ треба розмірні варіанти, але в РЦ лежать Prepack. У стандартному рішенні S4/HANA for Retail при виконанні операції поповнення запасів товарів магазинів немає можливості контролювати вільні залишки компонентів структурних товарів (розмірні варіанти Prepack). Одразу напишу, що варіант розпакування всіх Prepack товарів на рівні РЦ не розглядають через дорожнечу операцій на складі з розпакування, зберігання та подальшої комплектації під час відвантаження.  

Врешті було розроблено таке рішення. 

1. Після прогону планування потреби матеріалів (MRP) на рівні магазину автоматично формуються заявки на поповнення дефіциту варіанта розміру товару в магазині, де джерелом постачання завжди слугує розподільчий центр. 
2. Наступним кроком після прогону MRP запускається розроблена нами програма, яка виконує аналіз списку відкритих аявокпрограмі передбачено параметр, у якому у відсотковому відношенні вказується показник збігу списку розмірів товарів зі специфікацією Prepack товару (складність ще була в тому, що зазвичай є кілька варіантів Prepack, з різною пропорцією і списком розмірних варіантів). Якщо знайдено таку відповідність, то програма видаляє позиції заявок розмірних товарів, створених після прогону MRP, і створює одну заявку на переміщення Prepack товару. Таким чином, хоч і трохи з надлишком, ми постачаємо одну упаковку замість кількох розмірів моделі. Але за такого підходу виникають інші складнощі: якщо запустити знову MRP-процес по магазину, то система знову створить заявки на дефіцит розмірних товарів, тому що стандартом не перевіриться доступність (ATP check) розмірних товарів у складі Prepack. Щоб запобігти створенню надлишкових заявок на поповнення, було виконано доопрацювання стандарту роботи прогону MRP у розширення badi MD_CHANGE_MRP_DATA під час виконання прогону MRP. У точці розширення badi під час визначення вільного запасу варіанта розмірного товару в магазині враховували додатково ще не виконані замовлення на переміщення (STO) з позиціями Prepack товарів, що містять у специфікації цей розмірний товар. Потрібно було трохи проявити терпіння для перевірки, налагодження і ретельного тестування цього рішення, але в підсумку все вийшло! 

Але це ще не все. По частині розмірних товарів у заявках магазинів, як правило, Prepack у програмі не підбираються (менше 70 відсотків збігу за специфікацією). У цьому випадку другим етапом програма створює замовлення на декомплектацію Prepack товарів (замовлення на переміщення між складами всередині РЦ) на окремі компоненти. Підбір Prepack товарів проводиться за максимальним збігом розмірних товарів у специфікації. Після створення замовлень на декомплектацію вони автоматично надходять по інтерфейсу в зовнішню систему управління складом WMS систему як завдання всередині складського комплексу.  А позиції заявок на поповнення магазинів, для яких виконується декомлектація Prepack, фіксують (встановлюють мітку фіксації) для того, щоб під час наступного прогону MRP у магазині їх не було змінено. 

У підсумку в нас є оброблені заявки на поповнення в магазини з оптимізованими матеріалами постачання. Подальші кроки обробки заявок магазинів стандартні. Запускається програма з автоматичного створення замовлень на переміщення на підставі заявок на переміщення з присвоєними джерелами постачання. При створенні таких замовлень відбувається створення окремих документів згідно з товарними групами (щоб, наприклад, черевики не їхали в одному постачанні з біжутерією, або косметика – із засобами очищення взуття). 

Усі ці запуски прогону MRP на рівні магазинів і розроблених програм відбуваються послідовно по ланцюжку в нічний час (згідно з розкладом фонових завдань). У підсумку товарний менеджер вранці бачить у системі S4/HANA автоматично створені замовлення на переміщення для поповнення дефіциту товарів у магазинах.  Ці замовлення після створення відразу ж автоматично через інтеграцію надходять на склад у зовнішню WMS як завдання на комплектування і відвантаження товарів у магазини. Менеджер відстежує відстаючі замовлення, які не відвантажені за попередні дні. А також може в ручному режимі створити окремі замовлення на переміщення в разі потреби.  

Коли ухвалюється рішення про вимкнення товару з PULL-процесу, товарний менеджер змінює тип MRP у картці товару на ND. Далі товарна позиція допродається в магазині або виводиться на центральний склад. 

У процесі впровадження системи SAP S4/HANA в компанії INTERTOP було виконано низку додаткових розробок для побудови оптимального процесу планування потреб товарів у магазинах. Це було зумовлено специфікою планування поповнення запасів товарів  Fashion у магазинах і роботою стандартної галузевої системи SAP for Retail по роботі з Prepack товарами. На мій погляд, додатково розроблене нами рішення ефективно доповнило стандартні процеси товарних потоків системи SAP.  

Окремо висловлюю щиру подяку колегам із компанії INTERTOP Ользі Мейлус і Тетяні Таначовій за допомогу у розробці концепції цього рішення при впровадженні системи SAP S4/HANA.