Integrarea comerțului electronic și a logisticii

O comandă este primită în magazinul online, apoi cineva o transmite prin e-mail sau Excel către depozit. Colegul verifică stocul, înregistrează manual datele în sistemul de curierat și ulterior modifică starea comenzii într-un alt sistem. Atâta timp cât este vorba de câteva zeci de colete pe zi, acest lucru poate părea gestionabil. Însă, odată cu creșterea, devine rapid evident de ce este crucială integrarea sistemelor de comerț electronic și logistică: nu mutarea datelor este munca reală, dar aici se consumă timpul și apar cele mai multe erori.

Scopul integrării nu este doar ca două software-uri să facă schimb de date. Scopul este de a crea un mod de operare în care toată lumea lucrează din aceeași stare, este clar cine este responsabil pentru ce, iar sistemul efectuează administrarea mecanică în locul oamenilor. Pentru aceasta, mai întâi trebuie pus în ordine procesul de afaceri. Un proces prost conceput, conectat rapid, va genera aceleași erori mai rapid.

De ce se separă magazinul online și logistica?

Cele mai multe probleme nu sunt cauzate de un singur sistem defectuos. Magazinul online, ERP-ul, gestionarea stocurilor, WMS, facturarea, platforma de curierat și instrumentele de asistență pentru clienți pot fi adecvate fiecare în parte. Dificultatea începe atunci când nu este clar care sistem spune adevărul despre un produs, un stoc sau starea unei comenzi.

O situație tipică este când magazinul online promite spre vânzare un stoc pe care depozitul l-a rezervat deja pentru un alt canal. Alteori, depozitul a pregătit fizic coletul, dar în magazinul online apare încă în starea „în procesare”. Serviciul de asistență pentru clienți sună în acest caz, depozitul întrerupe munca pentru a răspunde, iar managerul încearcă ulterior să înțeleagă ce s-a întâmplat din mai multe rapoarte contradictorii.

Acestea nu sunt doar inconveniente informatice. Ele afectează direct promisiunea de livrare, finanțarea stocurilor, gestionarea retururilor și încărcarea angajaților. Dacă un coleg experimentat știe care tabel trebuie actualizat, atunci procesul nu este controlat, ci doar obișnuit.

Cum integrăm sistemele de comerț electronic și logistică?

Prima întrebare corectă nu este dacă există un API între cele două sisteme. Întrebarea este cum trece o comandă prin companie de la plată la livrare și unde trebuie să ia o decizie un om.

Merită să urmărim o comandă concretă. Când este creată? Când este verificată plata? Când este rezervat stocul? Cine gestionează lipsurile, livrările parțiale sau erorile de adresă? În ce moment se emite factura? Când și în ce condiții este notificat clientul? În timpul cartografierii procesului, se dezvăluie adesea că un pas manual nu mai oferă control de afaceri, ci doar compensează o lipsă anterioară a sistemului.

Patru principii de bază oferă un punct de plecare stabil pentru planificarea integrării:

• fiecare dată esențială să aibă un sistem gazdă desemnat;
• datele transmise să aibă un eveniment și o stare de afaceri clară;
• gestionarea excepțiilor să nu fie ascunsă în procesul normal;
• erorile trebuie să fie vizibile, căutabile și corectabile.

Atribuirea sistemului gazdă este deosebit de importantă. Descrierea comercială și prețul produsului sunt gestionate de obicei de magazinul online sau de sistemul de informații despre produse. Stocul fizic disponibil și rezervabil este adesea evidențiat de sistemul de depozitare sau ERP. Sursa adresei de livrare și a comunicării cu clientul poate fi magazinul online, în timp ce eticheta de transport și evenimentul de livrare provin din legătura cu transportatorul. Nu în toate cazurile aceeași împărțire este bună, dar nu poate exista o sursă „finală” independentă și durabilă pentru aceleași date.

Nu conectați câmpuri de date, conectați evenimente de afaceri

O soluție slabă este când un proces programat copiază la fiecare jumătate de oră datele comenzii dintr-o bază de date în alta. În anumite medii, aceasta poate fi un compromis acceptabil, de exemplu, în cazul unui sistem vechi sau al unui volum redus de comenzi. Dar întârzierea, trimiterea repetată și gestionarea procesării întrerupte trebuie planificate și în acest caz.

Un punct de plecare mai bun este definirea evenimentelor de afaceri. De exemplu: comandă aprobată, stoc rezervat, emis pentru comisionare, pachet expediat, livrare nereușită, retur primit. Fiecare eveniment are un sistem responsabil, o stare interpretabilă și, dacă este necesar, o sarcină umană.

Acest lucru este important deoarece comanda nu este un singur înregistrare, ci o serie de stări. Dacă eticheta de curier a fost generată, dar pachetul nu a fost încă plasat pe palet în depozit, nu ar trebui să comunicăm automat clientului ca și cum coletul ar fi deja în drum. Aceste mici diferențe decid dacă rapoartele și informațiile pentru clienți rămân credibile.

Excepțiile decid dacă soluția este utilizabilă

Ruta normală a comenzii este de obicei rapid automatizabilă. Întrebările mai dificile apar la excepții: nu există suficient stoc, clientul dorește să modifice comanda, trebuie îndeplinită din mai multe depozite, adresa este invalidă, marfa deteriorată este returnată sau transportatorul raportează o livrare nereușită.

Nu întotdeauna merită să oferim un răspuns complet automat la acestea. În cazul unei comenzi peste un anumit prag valoric, a unei livrări B2B unice sau a unei probleme recurente de adresă, verificarea umană poate fi justificată din punct de vedere al afacerii. Sarcina sistemului în acest caz este să arate problema colegului potrivit, împreună cu toate datele de fundal necesare. Nu să creeze cicluri de e-mail și liste separate.

Gestionarea excepțiilor necesită și limite de responsabilitate. Depozitul decide asupra unui produs de substituție? Serviciul de asistență pentru clienți poate modifica adresa după comisionare? Cine rezolvă anomalia de plată sau rezervare a stocului? Dacă aceste decizii există doar verbal, integrarea nu va elimina incertitudinea.

Proiectare tehnică: simplă, dar verificabilă

Nu toate companiile au nevoie de o platformă de integrare separată sau de o transformare majoră. Este posibil ca o conexiune standard magazin online-ERP să fie adecvată dacă modelul de date, logica stocurilor și gestionarea excepțiilor se potrivesc cu operațiunea. În alte medii, un strat de integrare intermediar este justificat, mai ales atunci când sunt conectate mai multe canale de vânzare, mai multe depozite, un sistem dezvoltat intern sau structuri de date diferite.

Indiferent de soluția tehnică, sunt necesare identificatori, jurnalizare și posibilitatea de re-procesare. O comandă, un colet și un produs trebuie să fie identificabile în mod consecvent în toate sistemele implicate. Dacă o conexiune nu este disponibilă temporar, sistemul nu trebuie să piardă evenimentul în tăcere. Trebuie să fie vizibil care transferuri așteaptă, care sunt eronate și cine le poate reporni fără decizie de afaceri sau cu aprobare de afaceri.

Planificarea trebuie să includă și autorizările și protecția datelor . Nu toate sistemele și nu toți utilizatorii trebuie să aibă acces complet la datele clienților sau ale comenzilor. În integrare, doar datele personale și de afaceri necesare pentru îndeplinirea sarcinii ar trebui să circule. Acest lucru reduce riscul și face operațiunea mai transparentă.

La implementare, nu înlocuiți întreaga operațiune deodată

O tranziție mare, unică, poate părea eficientă la prima vedere, dar procesarea comenzilor nu este un domeniu în care este ușor să accepți o perioadă lungă de erori. Este mai indicat să alegi o etapă unde durerea este clară și schimbarea este măsurabilă. Acesta poate fi automatizarea transferului de comenzi, corectarea sincronizării stocurilor sau înlocuirea generării etichetelor de transport.

Înainte ca noua conexiune să devină activă, trebuie testată cu cazuri reale. Nu doar o comandă corectă, plătită în avans, ci și anulări, livrări parțiale, lipsuri de stoc, retururi, corectări de adresă și trimiterea repetată a evenimentelor. Condițiile de acceptare trebuie formulate în limbaj de afaceri: ce vede depozitul, ce vede asistența pentru clienți, ce statut primește clientul și ce apare în raportul managerial.

Chiar și după implementare, procesul trebuie monitorizat. Nu este suficient să verifici dacă interfața funcționează. Trebuie să vezi câte comenzi așteaptă nejustificat, câte cazuri necesită intervenție manuală, unde se abate stocul sistemului de la stocul fizic și cât timp trece între diferitele stări. Aceste date nu arată doar funcționarea IT, ci și calitatea procesului de îndeplinire.

În viziunea CGAT, integrarea nu începe ca o sarcină de dezvoltare independentă, ci cu examinarea comună a operațiunilor de comandă și depozitare. Rezultatul bun nu vine adesea din introducerea mai multor tehnologii, ci din eliminarea câtorva transferuri nesigure, surse de date paralele sau aprobări inutile.

La următoarea întâlnire de conducere, merită să nu întrebi ce sistem ar trebui să mai fie conectat. Mai degrabă, alegeți o comandă problematică de ieri și urmăriți-o din sistem în sistem. Acolo unde informația se oprește, se repetă sau continuă doar în mintea unei persoane, acolo începe munca care poate îmbunătăți cu adevărat colaborarea între comerțul electronic și logistică.