Как ускорихме времето за разтоварване на стоките в склада

Терминал за събиране на данни Zebra WT-40 с пръстен скенер. Необходим е, за да можете бързо да сканирате стоките, докато физически подреждате кашоните върху палет (свободни ръце).

В продължение на няколко години отворихме магазини много бързо и се разраснахме. Това завърши с факта, че сега нашите складове получават и изпращат около 20 хиляди палета на ден. Естествено, днес вече имаме повече складове: два големи в Москва - 100 и 140 хиляди квадратни метра, но има и малки в други градове.

Всяка спестена секунда в процеса на получаване, сглобяване или изпращане на стоки в такъв мащаб е възможност за спестяване на време за операции. И това също е огромна икономия.

Ето защо двата основни фактора за ефективност са добре обмислен алгоритъм от действия (процес) и персонализирани ИТ системи. За предпочитане „като часовник“, но „работи малко по-малко от перфектно“ също е доста подходящо. Все пак сме в реалния свят.

Историята започна преди шест години, когато разгледахме по-отблизо как точно доставчиците разтоварват камиони в нашия склад. Беше толкова нелогично, но познато, че служителите дори не забелязаха неоптималния процес. Освен това в този момент нямахме система за управление на индустриални складове и основно се доверихме на 3PL оператори, които използваха техния софтуер и опит в изграждането на процеси за логистични операции.

Приемане на стоки

Както казахме, нашата компания по това време (както по принцип и сега) се стремеше да отвори много магазини, така че трябваше да оптимизираме складовите процеси, за да увеличим производителността (повече стоки за по-малко време). Това не е лесна задача и беше невъзможно да се реши просто чрез увеличаване на персонала, дори само защото всички тези хора ще си пречат един на друг. Така започнахме да мислим за внедряване на информационна система WMS (система за управление на складове). Както се очакваше, започнахме с описание на целевите складови процеси и още в самото начало намерихме необработено поле за подобрения в процеса на получаване на стоки. Беше необходимо да се отработят процесите в един от складовете, за да се прехвърлят в останалите.

Приемането е една от първите големи операции в склада. Тя може да бъде няколко вида: когато просто преизчисляваме броя на опаковките и когато трябва допълнително да изчислим колко и какви артикули има на всеки палет. Повечето от нашите стоки преминават през крос докинг потока. Това е, когато стоките пристигат в склада от доставчика, а складът действа като рутер и се опитва незабавно да ги изпрати отново до крайния получател (магазин). Има и други потоци, например, когато складът действа като кеш или като склад (трябва да поставите доставката на склад, да я разделите на части и постепенно да я изнесете в магазините). Вероятно моите колеги, които се занимават с математически модели за оптимизиране на остатъците, ще разкажат по-добре за работата със запаси. Но ето изненада! Започнаха да възникват проблеми чисто при ръчни операции.

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

Какви бяха загубите? Те бяха морето. Първо складовите работници получиха хартиени документи. Те са били насочвани и са взимали решения какво да правят с доставките, според тях. Второ, те броиха палетите на ръка и отбелязваха количествата в същите товарителници. След това попълнените формуляри за приемане бяха пренесени на компютър, където данните бяха въведени в XLS файл. След това данните от този файл бяха импортирани в ERP и едва тогава нашето ИТ ядро ​​действително видя продукта. Имахме много малко метаданни за поръчката, като например часа на пристигане на транспорта, или тези данни бяха неточни.

Първото нещо, което направихме, беше да започнем да автоматизираме самите складове, така че да имат поддръжка на процеси (необходими бяха куп софтуер, хардуер като мобилни скенери за баркод, внедряване на инфраструктурата за всичко това). След това те свързаха тези системи с ERP чрез шина. В крайна сметка информацията за наличността се актуализира в системата, когато товарач пусне скенер за баркод върху палет на пристигащ камион.

Стана така:

1. Доставчикът сам попълва данните какво и кога ни изпраща. За това има куп SWP и EDI портали. Тоест магазинът публикува поръчката, а доставчиците се задължават да изпълнят заявката и да доставят стоките в необходимото количество. При изпращане на стоките посочват и състава на палетите в камиона и цялата необходима информация от логистичен характер.
2. Когато колата напусна доставчика за нас, ние вече знаем какви стоки идват при нас; Освен това е установено електронно управление на документи с доставчици, така че знаем, че UPD вече е подписан. Изготвя се схема за оптимално движение на този продукт: ако това е крос докинг, тогава вече сме поръчали транспорт от склада, разчитайки на стоките, и за всички логистични потоци вече сме определили колко складови ресурси ще имаме необходимост от обработка на доставките. При детайлите на крос докинга се прави предварителен план за транспорт от склада на по-ранен етап, когато доставчикът току-що е запазил слот за доставка в системата за управление на вратите на склада (YMS - yard management system), която е интегрирана с доставчика портал. Информацията идва веднага в YMS.
3. YMS получава номера на камиона (по-точно номера на пратката от SWP) и записва шофьора за приемане, т.е. разпределя му необходимия времеви интервал. Тоест, сега шофьорът, който е пристигнал навреме, не трябва да чака жива опашка, а законното му време и докът за разтоварване са разпределени за него. Това ни позволи, наред с други неща, да разпределим оптимално камионите по територията и да използваме по-ефективно слотовете за разтоварване. Освен това, тъй като ние правим график предварително, кой, къде и кога ще пристигне, ние знаем колко хора и къде имаме нужда. Тоест, свързано е и с работните графици на складовите служители.
4. В резултат на тази магия товарачите вече не се нуждаят от допълнително маршрутизиране, а само чакат колите да ги разтоварят. Всъщност техният инструмент - терминалът - им казва какво да правят и кога. На ниво абстракция, това е като API за зареждане, но в модела на взаимодействие човек-компютър. Моментът на сканиране на първия палет от камиона също е запис на метаданните за доставка.
5. Разтоварването все още се извършва на ръка, но за всеки палет товарачът пуска баркод скенер и потвърждава, че данните на етикета са правилни. Системата контролира дали това е правилният палет, който очакваме. До края на разтоварването системата ще има точно преизчисляване на всички пакети. На този етап бракът все още е елиминиран: ако има очевидна повреда на транспортния контейнер, тогава е достатъчно просто да отбележите това по време на процеса на разтоварване или изобщо да не приемате този продукт, ако е напълно неизползваем.
6. Преди това палетите се брояха в зоната за разтоварване, след като всички бяха разтоварени от камиона. Сега процесът на физическо разтоварване е преизчисление. Връщаме брака веднага, ако е очевиден. Ако не е очевидно и се открие по-късно, тогава го натрупваме в специален буфер в склада. Много по-бързо е да хвърлите палет по-нататък в процеса, да съберете дузина от тях и да оставите доставчика да вземе всичко наведнъж в едно отделно посещение. Някои видове дефекти се прехвърлят в зоната за рециклиране (това често се отнася за чуждестранни доставчици, за които е по-лесно да получат снимки и да изпратят нов продукт, отколкото да го върнат обратно през границата).
7. В края на разтоварването документите се подписват и шофьорът тръгва по своя работа.

В стария процес палетите често се преместват в специална буферна зона, където вече се работи по тях: преброяват се, бракът се регистрира и т.н. Това беше необходимо, за да се освободи докинг станцията за следващата машина. Сега всички процеси са конфигурирани така, че тази буферна зона просто не е необходима. Има селективни преизчисления (един от примерите е процесът на селективно вътрешноконтейнерно преизчисление за кросдокинг в склад, реализиран в проекта Светофор), но повечето стоки се обработват веднага след приемане и именно от дока отива до оптималното място в склада или веднага до друг док за товарене, ако вече е пристигнал транспортът за експедиция от склада. Знам, че това ви звучи малко банално, но преди пет години, в огромен склад, възможността да обработваме пратка директно до крайни точки като товарен док за друг камион ни изглеждаше като вид космическа програма.

Какво се случва след това с продукта?

Освен това, ако това не е крос-докинг (и стоките още не са заминали за буфера преди изпращане или директно до дока), тогава трябва да бъдат поставени на склад за съхранение.

Необходимо е да се определи къде ще отиде този продукт, в коя клетка за съхранение. В стария процес беше необходимо визуално да определим в коя зона съхраняваме стоки от даден тип, след което да изберем място там и да вземем, поставим, запишем поставеното. Вече сме конфигурирали маршрути за разположение за всеки продукт според топологията. Знаем кой продукт в коя зона и коя клетка трябва да отиде, знаем колко клетки да вземем допълнително една до друга, ако е извънгабаритна. Човек се приближава до палета и го сканира със SSCC, използвайки TSD. Скенерът показва: "Занесете го на A101-0001-002." След това той кара там и отбелязва какво е поставил, като бърка скенера в кода на място. Системата проверява дали всичко е правилно и отбелязва. Не е нужно да пишете нищо.

С това приключваме първата част от работата с продукта. Тогава магазинът е готов да го вземе от склада. И това поражда следващия процес, за който колегите от отдела за доставки ще разкажат по-добре.

Така в системата наличността се актуализира в момента на приемане на поръчката. А захранването на клетката е в момента на поставяне на палета в нея. Тоест винаги знаем колко стоки общо има на склад и къде коя точно се намира.

Много потоци работят директно към хъбове (регионални складове за претоварване), защото имаме много местни доставчици във всеки регион. Същите климатици от Воронеж са по-удобни за инсталиране не във федералния склад, а веднага в местните центрове, ако е по-бързо.

Обратните потоци от бракове също са леко оптимизирани: ако стоките са кръстосани, тогава доставчикът може да ги вземе от склад в Москва. Ако бракът беше отворен след отварянето на транспортния пакет (и не беше ясно отвън, тоест не се появи по вина на транспортните работници), тогава във всеки магазин има зони за връщане. Бракът може да бъде хвърлен във федералния склад или можете да го дадете на доставчика директно от магазина. Второто се случва по-често.

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

За пет години намалихме четири пъти времето за приемане на стоката (разтоварване на машината) и ускорихме редица други процеси, което общо подобри оборота на крос-докинга с малко повече от два пъти. Нашата задача е да оптимизираме, за да намалим наличностите и да не „замразяваме“ парите в склада. И направиха възможно магазините да получат правилния продукт малко по-навреме.

За складовите процеси големите подобрения бяха да се автоматизира това, което преди беше хартия, да се отърват от ненужните стъпки в процеса поради оборудване и правилно конфигурирани процеси и да се свържат всички ИТ системи на компанията в едно цяло, така че поръчка от ERP (например в магазина липсва нещо на третия рафт отляво) в крайна сметка се превърна в конкретни действия в складовата система, поръчване на транспорт и т.н. Сега оптимизацията е повече за тези процеси, които все още не сме достигнали, и математиката на прогнозирането. Тоест, ерата на бързото внедряване свърши, свършихме тези 30% от работата, които дадоха 60% от резултата, а след това постепенно трябва да покрием всичко останало. Или се преместете в други области, ако там може да се направи повече.

Е, ако броим запазените дървета, тогава преходът на доставчиците към EDI портали също даде много. Сега почти всички доставчици не се обаждат и не комуникират с мениджъра, но сами преглеждат поръчките в личния си акаунт, потвърждават ги и доставят стоките. Ако е възможно, отказваме хартия; от 2014 г. 98% от доставчиците използват електронно управление на документи. Общо това са 3 дървета, спасени годишно само с отказ да се отпечатат всички необходими документи. Но това е без да се вземе предвид топлината от процесорите, но и без да се вземе предвид спестеното работно време на хора като същите мениджъри на телефона.

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

Ние не почиваме на лаврите си и продължаваме да свързваме нови съобщения с EDI, нови доставчици с електронно управление на документи.

Миналата година открихме най-големия дистрибуционен център в Европа - 140 XNUMX кв.м. m - и се зае с неговата механизация. Ще говоря за това в друга статия.

Източник: www.habr.com