Стикаючись з автоматизацією, часто доводиться чути про «хвильове складання» і «хвилі замовлень». Для початку, маленька ввідна про те, яким чином з'явився термін «хвиля». Уявімо собі графік, де по осі X - час, а по осі Y - деякий показник. Ми чекаємо, поки значення показника по осі Y не збільшиться до заданої максимальної величини, і починаємо виконувати дії, що призводять до зменшення значення. Потім, «впавши» до заданого мінімального значення, знову чекаємо накопичення. Таким чином, у нас з'являється графік у вигляді своєрідних «хвиль». Наведу простий приклад, коли використання таких «хвиль» нам може бути вигідно при збірці замовлень:
1) На склад надходить безліч замовлень, кожен з яких за своїм обсягом приблизно 1/10 від обсягу цілого піддону висотою 1,8 метра;
2) Співробітник може взяти для набору один піддон і набрати відразу 10 замовлень, довівши його висоту до 1,8 метра, що не завадить йому переміщати його;
3) Ми чекаємо, поки на склад надійде 10 замовлень, після чого відправляємо співробітника набирати їх всі за один прохід.
Одне з основних завдань при комплектації замовлень - це скорочення маршруту комплектувальника. Для порівняння: відбір 1-ї коробки з комірки займає 3 секунди, а переміщення між комірками може займати і 30 секунд, залежно від структури зони набору. Як наслідок, якщо ми видамо комплектувальнику одне замовлення в роботу, то він побіжить його збирати, набере 1/10 від того обсягу, який фізично може перемістити, і повернеться назад, пройшовши чималенький маршрут, так як в цьому замовленні можуть бути номенклатурні позиції, що знаходяться досить далеко один від одного. Якщо ж ми скомпонуємо відразу 10 замовлень, то співробітник - пройшовши схожий маршрут - зможе зібрати в 10 разів більше.
Однак, крім оптимального значення на рівні того ж обсягу для комплектації, у нас є ще одна величина, яку нам доведеться взяти до уваги: час. Якщо ми будемо дуже довго чекати, поки у нас збереться оптимальний обсяг, то можемо втратити дорогоцінний час, а можливо - якщо у нас, наприклад, склад-магазин - клієнта, який не захоче занадто довго чекати. Саме тому, «хвилі» можуть бути не однакової висоти, але суть від цього не змінюється.
Ця концепція дуже схожа з концепцією «бетчингу» (batching), коли ми намагаємося об'єднати розрізнені завдання в групи таким чином, щоб мінімізувати трудовитрати на їх виконання. Наприклад, який сенс відправляти штабелер в сусіднє приміщення виконувати одне-єдине завдання, якщо у нього їх достатньо в поточному місці розташування? Звичайно, спокушені в цих питаннях фахівці напевно підмітять, що кожна операція має свій пріоритет, і будуть по-своєму праві, але питання пріоритезації містить так багато нюансів, що я віддам перевагу присвятити йому окрему статтю, а зараз залишимо його «за бортом».
Щодо згаданого штабелера, одне тільки його переміщення в сусіднє приміщення, а також повернення назад після виконання завдання можуть бути більш трудовитратні, ніж виконання 2-3 завдань «тут і зараз».
Розуміючи, що «хвилі» можуть використовуватися по відношенню практично до будь-якого параметра, розглянемо найбільш часто використовувані варіанти:
1) «Хвилі замовлень» - накопичення певного обсягу замовлень для відправки в роботу з метою оптимізації завантаження виконавців і скорочення маршруту комплектації;
2) «Хвилі переміщень» - очікування досягнення заданої величини при формуванні завдань на виконання переміщень пале всередині складі з метою скорочення часу експлуатації важкої техніки;
3) «Хвильове складання» - термін, що найчастіше позначає очікування такої кількості замовлень, які б дозволили вивезти на окрему ділянку цілу палету з певним товаром, і розсортувати її в повному (або близькому до повного) обсязі за кожним замовленням.
Окремо зупинюся на варіанті 3. Він відмінно підходить для тих складів, які працюють з невеликою кількістю номенклатурних позицій, але при цьому отримують велику кількість замовлень. В такому випадку, ми можемо не ходити по всьому складу, набираючи замовлення, а здійснювати розподіл заданих номенклатурних позицій по пулу замовлень, які знаходяться в обробці. Припустимо, у Вас є 100 замовлень, в кожному з яких по 1-й коробці товару X. Одна палета (піддон з товаром) містить, припустимо, 100 коробок. Таким чином, ми можемо взяти палету, провезти її вздовж місць комплектації замовлень, і розподілити по них, або ж поставити в центр ділянки високоінтенсивного розподілу, і дати можливість співробітникам взяти необхідну для кожного замовлення кількість на стадії переупакування або контролю, скоротивши трудовитрати на комплектацію за рахунок істотного скорочення маршруту.
Хочу також зазначити, що замовлення можуть мати різну структуру, і класично прийнято ділити задану кількість по кожній позиції на три складових:
1) Те, що можна вивезти цілими палітами;
2) Те, що можна набрати цілими упаковками;
3) Те, що буде збиратися штуками (мінімальними одиницями).
Добре спроектована WMS дозволяє працювати з кожною такою складовою окремо, і використовувати різні алгоритми угруповання з «хвиль» і «бетчів», пов'язувати з такими групами свої алгоритми розрахунки тари, послідовності виконання, комбінування і пріоритетності, і багато іншого.
Наостанок, хочу зазначити, що «хвилі» - це приблизно такий же інструмент, як горезвісний «ABC-аналіз», який всі знають, але далеко не всі вміють грамотно використовувати.