Термінал збору даних Zebra WT-40 зі сканером-кільцем. Потрібен для того, щоб була можливість швидко сканувати товар, при цьому укладати фізично короби на палету (вільні руки).
Протягом кількох років ми дуже швидко відкривали магазини та росли. Закінчилося це тим, що зараз наші склади приймають та відправляють близько 20 тисяч палет на день. Звісно, сьогодні у нас уже більше складів: два великі у Москві — 100 і 140 тисяч квадратних метрів, але є й невеликі в інших містах.
Кожна заощаджена секунда в процесах приймання, збирання або відправлення товару в таких масштабах - це можливість зберегти час на операції. А ще це величезна економія.
Саме тому два головних множники ефективності – це продуманий алгоритм дій (процес) та налаштовані ІТ-системи. Бажано "як годинник", але "працюючі трохи менше, ніж ідеально" теж цілком підійде. Все ж таки ми в реальному світі.
Історія почалася шість років тому, коли ми придивилися, як саме постачальники розвантажують фури у нас на складі. Це було настільки нелогічно, але звично, що співробітники навіть не помічали неоптимальності процесу. Більше того, у той момент у нас не було промислової системи управління складом, і в основному логістичні операції ми довіряли 3PL-операторам, які використовували свій софт та досвід у побудові процесів.
Приймання товару
Як ми вже говорили, наша компанія на той момент (як, в принципі, і зараз) прагнула відкрити багато магазинів, тому довелося оптимізувати складські процеси для збільшення пропускної спроможності (більше товарів за меншу кількість часу). Це непросте завдання, і вирішити її, просто збільшивши персонал, було не можна хоча б тому, що всі ці люди заважатимуть один одному. Таким чином ми почали думати про впровадження інформаційної системи WMS (warehouse management system). Як і належить, ми почали з опису цільових складських процесів і вже на самому початку виявили неоране поле для покращень у процесі приймання товару. Треба було відпрацювати процеси одному зі складів, щоб потім накотити їх у інші.
Приймання - це одна з перших великих операцій на складі. Вона буває кількох типів: коли ми просто перераховуємо кількість вантажних місць і коли нам необхідно, окрім цього, порахувати, скільки та яких артикулів лежить на кожній палеті. Більшість товарів у нас проходить по потоку крос-докінг. Це коли товари приїжджають на склад від постачальника, а склад виступає в ролі роутера і намагається відразу переправити їх на кінцевого одержувача (магазин). Є й інші потоки, наприклад, коли склад виступає у ролі кеша чи ролі накопичувача (потрібно покласти постачання у стік, розділити на частини й поступово вивозити у магазини). Напевно, про роботу зі стоком краще розкажуть мої колеги, які опікуються математичними моделями оптимізації залишків. Але ж тут сюрприз! Проблеми почали виникати суто на ручних операціях.
Процес виглядав так: вантажівка приїжджала, водій змінювався документами з адміністратором складу, адміністратор розумів, що там приїхало і куди його відправити, потім направляв вантажника забирати товар. Все це займало близько трьох годин (звичайно, багато в чому час приймання залежить від того, який логістичний потік ми приймаємо: десь необхідно робити внутрішньотарний перерахунок, а десь ні). Більшу кількість людей на одну вантажівку направити не можна: заважатимуть один одному.
Які втрати? Їх було море. По-перше, працівники складу отримували паперові документи. Вони орієнтувалися і приймали рішення, що робити з постачанням за ними. По-друге, вони вважали палети вручну і в цих же товарних накладних зазначали кількість. Потім заповнені бланки приймання належали до комп'ютера, де дані забивалися в XLS-файл. Дані з цього файлу потім імпортувалися до ERP, і лише тоді наше ІТ-ядро за фактом бачило товар. Ми мали дуже мало метаданих про замовлення на кшталт часу прибуття транспорту або ці дані були неточними.
Перше, що ми зробили — це почали автоматизувати самі склади так, щоб у них з'явилася підтримка процесів (потрібно було поставити купу софту, заліза на кшталт мобільних сканерів штрих-кодів, розгорнути інфраструктуру для всього цього). Потім ці системи зв'язали з ERP через шину. Зрештою інформація про наявність товару оновлюється в системі, коли вантажник проводить сканером штрих-коду по палеті на вантажівці.
Стало так:
- Постачальник сам заповнює дані про те, що надсилає до нас і коли. Для цього є зв'язка із SWP та EDI-порталів. Тобто магазин публікує замовлення, а постачальники беруться виконати заявку та поставити товар у потрібній кількості. Вони ж при відправленні товару вказують склад палет у фурі та всю необхідну інформацію логістичного характеру.
- Коли машина поїхала від постачальника до нас, ми знаємо, який товар до нас йде; більше, з постачальниками налагоджений електронний документообіг, тому ми знаємо, що УПД вже підписано. Готується схема оптимального переміщення цього товару: якщо це крос-докінг, ми вже замовили транспорт зі складу, розраховуючи на товар, а також для всіх логістичних потоків ми вже визначили, скільки складських ресурсів нам знадобиться для обробки поставок. У деталях для крос-докінгу попередній план з транспорту зі складу робиться на більш ранньому етапі, коли постачальник лише зарезервував слот на постачання в системі управління складською брамою (YMS — yard management system), яка інтегрована з порталом постачальника. Інформація надходить у YMS відразу.
- YMS отримує номер вантажівки (якщо бути точніше, то номер відвантаження із SWP) і записує водія на приймання, тобто відводить йому необхідний слот часу. Тобто тепер водію, який приїхав вчасно, не треба чекати живої черги, а під нього відведено його законний час та док розвантаження. Це дозволило нам, крім усього іншого, оптимально розподіляти вантажівки по території та ефективніше використовувати розвантажувальні слоти. А ще, оскільки ми заздалегідь складаємо графік, хто, куди і коли приїде, знаємо, скільки людей і де потрібно. Тобто це пов'язано з робочими графіками співробітників складу.
- У результаті цієї магії вантажники вже не потребують додаткової маршрутизації, а лише чекають на машини для їх розвантаження. Фактично їхній інструмент — термінал — каже їм, що робити і коли. На рівні абстракції це як API вантажника, але у human-computer interaction-моделі. Момент сканування першої палети з вантажівки - це ще запис метаданих на постачання.
- Розвантаження поки робиться так само руками, але по кожній палеті вантажник проводить сканером штрих-кодів і підтверджує, що дані етикетки в порядку. Система контролює, щоб це була правильна палета, на яку ми очікуємо. До кінця розвантаження у системі буде точний перерахунок усіх вантажних місць. На цій стадії ще відсівається шлюб: якщо є явні ушкодження транспортної тари, то досить просто відзначити це в процесі розвантаження або зовсім не ухвалити цей товар, якщо він зовсім непридатний.
- Раніше палети перераховувалися в зоні розвантаження після того, як усі будуть вивантажені з машини. Наразі вже процес фізичного вивантаження є перерахунком. Шлюб ми повертаємо відразу, якщо він очевидний. Якщо він неочевидний і виявляється згодом, то ми накопичуємо його в особливий буфер на складі. Набагато швидше прокинути палету далі в процес, зібрати з десяток таких і дати можливість постачальнику забрати все одразу за один окремий приїзд. Деякі види шлюбу переводять у зону утилізації (це часто стосується закордонних постачальників, яким простіше отримати фотографії та надіслати новий товар, ніж приймати його назад через кордон).
- Наприкінці розвантаження підписуються документи, і водій їде далі у своїх справах.
У старому процесі палети переміщалися найчастіше до спеціальної буферної зони, де вже з ними працювали: вважали, реєстрували шлюб і так далі. Потрібно це було для того, щоб звільнити док для наступної машини. Наразі всі процеси налаштовані так, що ця буферна зона просто не потрібна. Є вибіркові перерахунки (один із прикладів — процес вибіркового внутрішньотарного перерахунку для крос-докінгу на складі, реалізований у проекті «Світлофор»), але більша частина товару обробляється відразу за фактом приймання і саме з дока їде на оптимальне місце на складі або одразу в інший док для навантаження, якщо транспорт на відвантаження зі складу вже прибув. Знаю, вам це звучить трохи звичайно, але п'ять років тому на величезному складі можливість обробити постачання відразу на кінцеві точки на кшталт доку навантаження для іншої вантажівки - це нам здавалося чимось на кшталт космічної програми.
Що далі відбувається із товаром?
Далі, якщо це не крос-докінг (і товар уже не поїхав у буфер перед відправкою або прямо в док), його потрібно покласти в стік на зберігання.
Потрібно визначити, куди цей товар піде, до якого осередку зберігання. У старому процесі потрібно було візуально визначити, в якій зоні ми зберігаємо товари даного типу, і потім вибрати там місце та відвезти, покласти, записати, що поклали. Зараз у нас налаштовані маршрути розміщення по кожному товару за топологією. Ми знаємо, який товар у яку зону і в який осередок має потрапити, знаємо, скільки осередків зайняти додатково поруч, якщо це негабарит. Людина підходить до палеті та сканує її SSCC за допомогою ТСД. Сканер показує: "Везі до А101-0001-002". Далі він везе туди і зазначає, що поклав, тицяючи сканером у код на місці. Система перевіряє, що все правильно, і зазначає. Нічого не треба писати.
У цьому перша частина роботи з товаром закінчується. Далі магазин готовий забирати його зі складу. І це породжує наступний процес, про який краще розкажуть колеги з відділу постачання.
Отже, в системі стік оновлюється в момент прийому замовлення. А запас осередку — у момент постановки палети до неї. Тобто ми завжди знаємо, скільки товару є на складі разом і де який лежить конкретно.
Дуже багато потоків працює безпосередньо в хаби (регіональні перевалочні склади), тому що ми маємо багато місцевих постачальників у кожному регіоні. Ті ж кондиціонери з Воронежа зручніше ставити не на федеральний склад, а відразу в хаби на місцях, якщо це швидше.
Зворотні потоки шлюбу теж трохи оптимізовані: якщо товар на крос-докінгу, то постачальник може забрати його зі складу у Москві. Якщо шлюб розкрився після відкриття транспортної упаковки (і зовні це було незрозуміло, тобто він з'явився не з вини транспортників), тобто зони повернення в кожному магазині. Шлюб можна закинути на федеральний склад, а можна віддавати постачальнику з магазину. Друге трапляється частіше.
Ще один процес, який зараз потребує оптимізації, — це обробка непроданих сезонних товарів. Справа в тому, що у нас є два важливі сезони: Новий рік і час саду-городу. Тобто в січні ми отримуємо на РЦ нереалізовані штучні ялинки та гірлянди, а до зими – газонокосарки та інші сезонні товари, які потрібно зберегти, якщо вони витримають ще рік. За ідеєю, потрібно розпродавати їх повністю наприкінці сезону або віддавати комусь ще, а не тягнути назад на склад - ось це та частина, куди в нас ще не дійшли руки.
За п'ять років ми скоротили час приймання товару (розвантаження машини) вчетверо і прискорили ряд інших процесів, що загалом покращило оборотність крос-докінгу трохи більше, ніж удвічі. Наше завдання — оптимізація, щоб знизити запас і не заморожувати гроші на складі. І дали можливість магазинам отримувати потрібний товар трохи вчасно.
За складськими процесами великі поліпшення полягали в тому, щоб автоматизувати те, що раніше було папером, позбутися зайвих етапів у процесі за рахунок обладнання та правильно налаштованих процесів та поєднати всі ІТ-системи компанії в єдине ціле, щоб замовлення з ERP (наприклад, в магазині чогось не вистачає на третій полиці зліва) зрештою перетворювався на конкретні дії в системі складського зберігання, замовлення транспорту і так далі. Зараз оптимізація більше стосується тих процесів, яких ми ще не добиралися, і математики прогнозування. Тобто епоха бурхливого застосування закінчилася, ми зробили ті 30 % роботи, які дали 60 % результату, і далі треба поступово покривати все інше. Або рухатись на інші ділянки, якщо там можна зробити більше.
Ну і якщо рахувати у врятованих деревах, то перехід постачальників на EDI-портали теж дуже багато дав. Сьогодні майже всі постачальники не дзвонять і не спілкуються з менеджером, а самі в особистому кабінеті дивляться замовлення, підтверджують їх і везуть товар. По можливості відмовляємось від паперу, з 2014 року вже 98% постачальників – на електронному документообігу. Загалом це збережені 3 000 дерев за рік лише на відмові від друку всіх необхідних паперів. Але це без урахування тепла від процесорів, але й без урахування заощадженого робочого часу людей на кшталт тих самих менеджерів на телефоні.
За п'ять років у нас стало вчетверо більше магазинів, утричі більше за різні документи, і, якби не було EDI, у нас було б утричі більше бухгалтерів.
Ми не зупиняємось на досягнутому та продовжуємо підключати до EDI нові повідомлення, нових постачальників до електронного документообігу.
Минулого року ми відкрили найбільший розподільчий центр у Європі – 140 тис. кв. м — і взялися до його механізації. Про це я розповім в іншій статті.
Джерело: habr.com