Managementul schimbării pentru o implementare YMS reușită
Software-ul poate fi configurat perfect și totuși poate eșua în producție dacă paznicul de poartă, spotterul și dispecerul transportatorului nu adoptă niciodată complet noul mod de lucru pe care îl impune. Implementările YMS reușesc sau eșuează în principal din cauza managementului schimbării, nu a implementării tehnice — un tipar valabil pentru majoritatea software-ului operațional, dar deosebit de accentuat într-o curte, unde persoanele afectate adesea nu sunt deloc angajați direcți ai unității.
O implementare de sistem de management al depozitului afectează în principal proprii angajați ai unității, care pot fi instruiți, supravegheați și trași la răspundere prin canalele normale de management. O implementare YMS afectează și șoferii de camion, care lucrează pentru transportatori externi, vizitează adesea unitatea rar și nu au nicio relație directă de raportare către managementul unității. Un șofer care găsește confuză noua aplicație de check-in nu poate fi pur și simplu trimis la o sesiune de instruire așa cum se poate face cu un angajat intern — unitatea trebuie să proiecteze pentru o populație pe care nu o poate controla complet sau de la care să impună conformitate.
Pentru personalul de curte, spotteri și personalul de poartă, modul de eșec mai comun este revenirea tacită la obiceiurile vechi sub presiune — recurgerea la apeluri radio și notițe mentale într-o tură aglomerată, deoarece noua interfață de sistem pare mai lentă în acel moment, chiar dacă produce date mai bune per ansamblu. Combaterea acestui lucru necesită mai mult decât o singură sesiune de instruire: consolidare în timpul primelor câteva săptămâni de utilizare live, sprijin vizibil al managementului pentru folosirea noului proces chiar și când pare mai lent și, ideal, o modalitate de a arăta personalului beneficiul din aval (mai puține telefoane furioase, mai puțin timp căutând remorci pierdute) care face frecarea pe termen scurt să merite tolerată.
Transportatorii și șoferii lor au nevoie de preaviz privind schimbările de proces — cerințe noi de check-in, reguli de rezervare a programărilor sau utilizare a aplicației — comunicate prin canalele pe care o unitate le folosește deja pentru a-i contacta (actualizări ale ghidului de rutare, scorecard-uri de transportator, contact direct cu transportatorii frecvenți), cu mult timp înainte ca schimbarea să intre în vigoare. Unitățile care activează brusc un nou proces de poartă fără comunicare prealabilă către transportatori observă de obicei un vârf de sosiri confuze și frustrate în primele zile, ceea ce reflectă prost asupra schimbării chiar și atunci când îmbunătățirea de proces de bază este solidă.
În loc să treacă de la un proces vechi la unul nou peste noapte, rularea ambelor în paralel pentru o fereastră definită — de exemplu, backup pe hârtie vechi disponibil alături de noul check-in electronic — oferă personalului și transportatorilor o plasă de siguranță în timp ce se adaptează, și oferă unității șansa de a prinde probleme de configurare înainte ca vechiul proces să fie complet retras. Perioada paralelă ar trebui să aibă o dată de final clară, comunicată în avans, astfel încât să funcționeze ca o tranziție susținută, nu să devină o scuză permanentă pentru a evita noul sistem.
Lansarea nu este același lucru cu adoptarea. Urmărirea metricilor reale de utilizare după implementare — procentul de check-in-uri finalizate electronic față de revenirea la procesul manual, frecvența derogărilor de sistem, tichete de suport sau reclamații ale personalului — oferă o citire factuală a dacă efortul de management al schimbării funcționează, în loc să presupună succes doar pentru că software-ul a fost instalat și instruirea a fost livrată.