OMS pentru direcționarea comenzilor de livrare mâncare
Gestionarea comenzilor pentru restaurante și mâncare preparată comprimă întregul ciclu de viață al comenzii — plasare, preparare și livrare — într-o fereastră măsurată în minute, nu în zile, ceea ce obligă un OMS să direcționeze comenzile pe baza capacității bucătăriei și a disponibilității curierilor aproape în timp real, nu pe baza disponibilității statice a stocului.
Un OMS tradițional întreabă „acest SKU este în stoc la această locație". Un OMS pentru comenzi de mâncare întreabă „poate această bucătărie produce această comandă într-o fereastră de timp acceptabilă, având în vedere coada curentă". Capacitatea bucătăriei este o resursă perisabilă, care se resetează constant — o locație cu ingrediente din belșug poate fi totuși efectiv „fără stoc" dacă coada de preparare este blocată, iar OMS-ul are nevoie de un semnal de debit live de la sistemul bucătăriei pentru a direcționa corect.
Ciclul de viață al comenzii are trei etape strâns legate pe care un model generic de status OMS nu le surprinde bine: comandă acceptată de bucătărie, preparare în curs cu o oră estimată de finalizare și alocarea curierului cronometrată pentru a sosi aproape de acea oră. Alocarea curierului prea devreme îi irosește timpul de așteptare; alocarea prea târziu adaugă întârziere inutilă. OMS-ul trebuie să expună estimarea timpului de preparare ca un câmp live, actualizat, pe care sistemul de dispecerizare îl consumă direct.
Comenzile care combină articole de la mai mult de o bucătărie sau furnizor (un model de tip marketplace) necesită ca OMS-ul să coordoneze două cronologii de preparare independente într-o singură ridicare, decizând dacă curierul așteaptă la bucătăria mai lentă sau comanda este livrată în două curse. Aceasta reflectă logica de expediere divizată din retailul fizic, dar la o scară de timp comprimată, unde o întârziere de zece minute este o eșec de serviciu, nu un inconvenient minor.
În perioadele de vârf, bucătăriile se pot supraîncărca mai repede decât poate reacționa orice proces manual. OMS-ul ar trebui să susțină limitarea dinamică a comenzilor — ascunderea temporară a unui meniu sau extinderea timpilor de preparare afișați pe măsură ce coada crește — condusă de același semnal de capacitate live folosit pentru direcționare, în loc să accepte comenzi nelimitat și să lase calitatea serviciului să se prăbușească pe toată linia.
Deoarece mâncarea se alterează și nu poate fi revândută, politica de anulare a OMS-ului are nevoie de un termen limită strict legat de începerea preparării, nu de o fereastră generică bazată pe timp. Odată ce o bucătărie a început să prepare o comandă, anularea ar trebui să declanșeze o politică de rambursare diferită (parțială sau deloc) față de o anulare solicitată înainte de începerea preparării, iar această distincție trebuie aplicată automat, nu lăsată la aprecierea de la caz la caz a serviciului clienți.