Exemplu de automatizare a fluxului de comenzi pentru un magazin online

O comandă de pe un webshop este primită, iar cineva trimite datele prin e-mail sau Excel către depozit. Colegul verifică plata, rescrie datele de facturare, creează o etichetă, schimbă statutul și, în final, încearcă să notifice clientul. Acest lucru funcționează atâta timp cât este vorba de câteva comenzi pe zi. exemplu de automatizare a fluxului de comenzi pe webshop devine cu adevărat util atunci când creșterea înseamnă mai mulți pași manuali, mai multe excepții și responsabilități din ce în ce mai greu de urmărit.

Problema nu este de obicei lipsa aplicațiilor. Mai degrabă, între webshop, ERP, sistemul de depozit, facturare și serviciul de curierat, oamenii mențin fluxul de informații. Dacă o comandă se blochează, de multe ori se descoperă doar atunci când serviciul clienți primește o reclamație. În astfel de cazuri, nu este recomandat să începeți cu un instrument de automatizare, ci cu întrebarea: ce se întâmplă exact cu o comandă de la plată până la livrare?

Unde se întrerupe drumul comenzii?

La un comerciant de dimensiuni medii, procesarea comenzilor rar este un singur proces. Comenzile de pe stoc, cele precomandate, cele cu plată la livrare, cele cu factură de companie sau cele cu ridicare personală pot avea căi diferite. Pachetele promoționale, livrările parțiale, rambursările și erorile de adresă cresc numărul de variante.

De aceea, prima greșeală este adesea că firma încearcă să trateze toate comenzile în același mod. În realitate, scopul nu este ca un sistem să transmită orbește toate datele, ci ca cazurile frecvente și clare să avanseze automat, iar cele incerte sau sensibile din punct de vedere comercial să ajungă la persoana potrivită.

Este util să urmăriți o comandă concretă, nu doar pe ecranele sistemelor, ci și în munca efectivă. Cine decide asupra unei discrepanțe de plată? Cum știe depozitul că un articol este încă rezervabil? Când se emite factura? Ce se întâmplă dacă serviciul de curierat nu acceptă adresa? Dacă răspunsurile la aceste întrebări se bazează pe tradiție orală sau pe memoria unui coleg experimentat, atunci procesul nu este suficient de controlat.

Un exemplu de automatizare a fluxului de comenzi pe webshop

Să presupunem că comenzile primite de pe webshop sunt înregistrate manual în ERP. Depozitul lucrează de acolo, factura este creată dintr-un al treilea sistem, iar etichetele de transport sunt create pe o interfață separată. Statutul comenzii în webshop este adesea actualizat cu întârziere, astfel încât serviciul clienți întreabă telefonic depozitul.

În această situație, nu neapărat un nou webshop sau înlocuirea completă a ERP-ului este primul pas bun. O schimbare mai mică, bine definită, ar putea fi ca o comandă aprobată să creeze sau să actualizeze automat înregistrarea corespunzătoare a comenzii în ERP. ERP-ul rămâne registrul central al îndeplinirii afacerii: de aici vin datele necesare pentru stoc, facturare și decizia de livrare.

Când comanda poate fi procesată, sistemul de depozit primește sarcina de comisionare. După asamblarea pachetului, datele de livrare sunt transmise către curier, eticheta se întoarce la depozit, iar identificatorul pachetului și statutul corespunzător sunt actualizate în webshop. Astfel, clientul este informat nu dintr-un e-mail creat manual, ci pe baza evenimentelor reale de îndeplinire.

Logica procesului poate fi rezumată în cinci stări:

• comanda a fost primită și este tehnic validă;
• plata sau aprobarea comercială a fost verificată;
• stocul a fost rezervat și sarcina de îndeplinire creată;
• pachetul este gata de livrare sau a fost predat transportatorului;
• îndeplinirea este închisă, iar datele financiare și de comunicare cu clientul necesare sunt înregistrate.

Denumirile statutelor pot varia de la o companie la alta. Esențial este ca fiecare stare să aibă o semnificație comercială clară, un responsabil și o sursă sistemică. De exemplu, „în procesare” nu este o stare bună dacă uneori înseamnă că se așteaptă plata, iar alteori că pachetul este deja în depozit.

Automatizarea nu înseamnă eliminarea excepțiilor

În fluxul de comenzi vor exista întotdeauna excepții. Un produs poate fi epuizat din stoc, confirmarea bancară poate întârzia, adresa poate fi incompletă sau clientul poate dori să combine mai multe comenzi. Nu este recomandabil să le ascundeți în spatele unui proces automat.

O soluție bună recunoaște că o anumită comandă nu poate avansa în siguranță, o oprește la punctul potrivit și creează o sarcină. Sarcina trebuie să fie vizibilă: cine o primește, pe baza căror informații decide, cât timp așteaptă comanda și ce se întâmplă după decizie. Acesta nu este un detaliu administrativ. Dacă gestionarea excepțiilor devine o căutare prin e-mail, automatizarea va genera doar mai rapid incertitudine.

Erorile parțiale merită o atenție deosebită. Se poate întâmpla ca o comandă să fie creată în ERP, dar sarcina de depozit să nu fie. Sau eticheta de curier să fie creată, dar webshop-ul să nu primească identificatorul de urmărire. În astfel de cazuri, sistemul nu trebuie să genereze din nou și din nou comenzi, facturi sau etichete duplicate.

De aceea, în proiectarea tehnică este nevoie de identificatori unici, procesare repetabilă și jurnalizare. Simplu spus: trebuie să se poată spune ulterior care sistem a transmis ce date, când și de ce s-a oprit un proces. Aceasta este parte a controlului operațional, nu doar o chestiune de dezvoltare.

Care sistem spune adevărul?

Multe erori de comandă provin din faptul că aceleași date sunt editate în mai multe locuri. Adresa este modificată în webshop, dar în ERP rămâne cea veche. Depozitul lucrează dintr-un tabel, în timp ce stocul s-a schimbat deja. Sistemul de facturare folosește alte date ale clientului decât cele văzute de serviciul clienți.

Pentru fiecare dată esențială, este recomandat să se desemneze sistemul principal. Pentru catalogul de produse, preț, datele clientului, stoc, statutul comenzii și datele de facturare, nu neapărat aceeași sursă va fi principală. Acest lucru este în regulă dacă regula este exprimată și sincronizarea o urmează.

Stocul este un domeniu deosebit de sensibil. În vânzările pe webshop, nu întotdeauna stocul fizic al depozitului este cel disponibil pentru vânzare. Trebuie luate în considerare cantitățile deja rezervate, produsele aflate în controlul calității, mărfurile aflate în transfer și, uneori, stocul așteptat din achiziții. Dacă această diferență nu este clarificată, transferul automatizat al comenzilor poate duce la supra-vânzare sau opriri nejustificate.

Măsurarea nu este raportare ulterioară

Fluxul automatizat de comenzi oferă valoare managerială dacă face vizibilă operațiunea. Nu este suficient să știți câte comenzi au fost primite. Este util să urmăriți cât timp trece între comandă și eliberarea din depozit, câte comenzi așteaptă gestionarea excepțiilor, care eroare se repetă și unde se acumulează munca.

Aceste date adesea ridică întrebări incomode. Poate că nu integrarea este lentă, ci aprobarea facturilor o dată pe zi întârzie comenzile. De asemenea, este posibil ca depozitul să nu primească informații suficient de devreme despre campanii. Scopul măsurării nu este controlul colegilor, ci înțelegerea locului unde este necesară schimbarea procesului.

La implementare, este recomandat să începeți cu un tip de comandă bine delimitat. De exemplu, comenzile de pe stoc, plătite în avans, cu livrare internă. Acestea sunt de obicei bine reglementate, iar pe baza experienței pot fi ajustate statuturile, câmpurile de date, regulile de gestionare a erorilor. Apoi pot fi incluse cazurile mai complexe.

Abordarea treptată nu încetinește neapărat dezvoltarea. Mai degrabă reduce șansele de a încorpora un proces greșit înțeles în mod permanent în sisteme. În viziunea CGAT, integrarea și automatizarea sunt valoroase dacă ordinea de lucru din spatele lor devine mai clară, mai măsurabilă și mai sustenabilă.

Prima întrebare bună nu este care instrument conectează webshop-ul la ERP. Mai degrabă, dacă mâine ar veni de două ori mai multe comenzi, exact la ce pas ar pierde compania controlul. Acolo merită să faceți ordine mai întâi.