OMS pentru programarea livrărilor de mobilă și produse voluminoase
Mobila, electrocasnicele mari și alte produse voluminoase nu pot fi expediate printr-o rețea standard de curierat, ceea ce înseamnă că OMS-ul trebuie să coordoneze onorarea comenzii cu un model de livrare programată, pe bază de întâlnire, în loc de o etichetă de expediere trimisă și uitată. Comanda nu este completă până când o echipă de doi oameni nu a livrat, despachetat și, uneori, asamblat produsul în locuința clientului.
Un OMS generic presupune că o comandă devine expediere în momentul alocării stocului și că transportatorul alege independent data livrării. Onorarea produselor voluminoase inversează asta: data livrării trebuie negociată cu clientul înainte ca depozitul să confirme un slot de livrare, deoarece camioanele rulează pe rute fixe cu un număr limitat de opriri pe zi, iar echipele de instalare au capacitate finită. OMS-ul are nevoie de un pas de programare integrat în ciclul de viață al comenzii, nu de o soluție externă adăugată ulterior.
După plată și alocarea stocului, OMS-ul prezintă ferestre de livrare disponibile provenite dintr-un motor de rutare care ține deja cont de capacitatea camionului, zona de livrare și competența echipei (capabilă de asamblare vs. doar predare). Datele cheie pe care le poartă comanda:
- Fereastra de întâlnire pentru livrare (adesea un slot de jumătate de zi) confirmată de client
- Marcaje de manipulare specială: white-glove, camera aleasă, ridicarea produsului vechi
- Constrângeri de acces — scări, dimensiunea liftului, uși înguste — capturate la momentul programării
- Cerința de asamblare și timpul estimat la fața locului, care afectează câte opriri poate face camionul în acea zi
Modelele standard de status OMS se opresc semnificativ la „expediat" și „livrat". Produsele voluminoase au nevoie de stări intermediare: staged la DC, în curs de livrare, livrare încercată (clientul nu era acasă), reprogramată, livrată și instalată, livrată dar instalare în așteptare. Fiecare schimbare de stare provine de obicei din aplicația mobilă a echipei de livrare, nu dintr-un feed de tracking al transportatorului, deci punctul de integrare al OMS-ului este diferit — este mai apropiat de un sistem de dispecerizare field-service decât de un API de expediere.
O singură comandă poate include o canapea dintr-un DC și o masă de sufragerie din altul, ambele voluminoase, ambele necesitând livrare cu camion. OMS-ul trebuie să decidă dacă le consolidează într-o singură întâlnire (reținând articolul mai rapid până când cel mai lent este gata) sau le livrează separat, și să expună acest compromis clientului la finalizarea comenzii, nu să îl surprindă cu două livrări. Această decizie de consolidare este mai importantă decât în expedierea de colete, deoarece reprogramarea unei rute de camion este costisitoare.
O livrare voluminoasă ratată costă mult mai mult decât un colet ratat — se pierde un slot de camion, o echipă de doi oameni și combustibil. OMS-ul ar trebui să urmărească distinct motivele livrării eșuate (clientul absent, acces blocat, produs deteriorat în tranzit) și să declanșeze remedieri diferite: reprogramare automată, oferte de compensare sau un blocaj de calitate pe SKU dacă deteriorarea este cauza recurentă. Această codificare granulară a motivelor alimentează scorecard-urile de furnizori și transportatori, ceva ce un motor generic de retururi/excepții OMS nu captează.