Cele mai bune practici înainte de tranziția sistemului

O tranziție de sistem rareori întârzie din cauza unei aplicații noi care este defectuoasă în sine. Mai des, problemele apar atunci când, în timpul tranziției, se descoperă că datele de comandă diferă în mai multe locuri, o excepție de depozit există doar în mintea unui coleg experimentat sau un tabel Excel susține o decizie pe care nimeni nu a documentat-o. cele mai bune practici înainte de tranziția de sistem nu sunt, prin urmare, doar puncte de control IT. Acestea sunt condițiile controlului operațional.

Într-o companie în creștere, schimbarea sau integrarea sistemului poate afecta vânzările, achizițiile, producția, depozitul, facturarea și rapoartele manageriale. Dacă tranziția începe doar ca un proiect tehnologic, vechile erori pot rămâne - doar pe o nouă interfață. O abordare mai bună este ca firma să examineze mai întâi cum lucrează cu adevărat și abia apoi să decidă ce trebuie transferat, transformat sau abandonat.

Înainte de tranziția de sistem, evaluați procesul real

Procesul descris și funcționarea efectivă de multe ori nu sunt aceleași. De exemplu, diagrama de proces arată că comanda din magazinul online este transferată automat în ERP, dar în practică, un angajat verifică, corectează și completează manual datele lipsă în fiecare dimineață. Aceasta nu este neapărat o eroare din partea colegului implicat. Mai degrabă este un semn că sistemul sau procesul nu gestionează corect excepțiile.

Înainte de tranziție, merită să urmăriți câteva cazuri reale de la început până la sfârșit. O comandă primită, o returnare, o achiziție urgentă, o deviație de producție sau o reclamație. Cine inițiază procesul? Pe baza căror informații ia decizia? În ce sistem înregistrează datele? Unde așteaptă cazul și cine intervine dacă ceva nu se desfășoară conform obișnuinței?

Această muncă nu este o formalitate administrativă. De aici se poate vedea ce funcții trebuie să funcționeze cu adevărat din prima zi într-un nou sistem și care sunt acele vechi etape care nu mai servesc unui scop de afaceri. În multe cazuri, cel mai mare rezultat nu este o dezvoltare, ci eliminarea unei aprobări inutile, a unei introduceri paralele de date sau a unei reconciliere manuale.

Excepțiile pot fi mai importante decât cazurile obișnuite

Procesul normal este de obicei ușor de prezentat. Dificultatea începe atunci când sosesc livrări parțiale, clientul solicită o altă adresă de livrare, stocul unui produs devine negativ sau o comandă trebuie modificată după emiterea facturii. Aceste cazuri nu sunt frecvente, dar totuși provoacă timp semnificativ, coordonare și risc.

Nu este scopul automatizarea completă a fiecărei excepții. În cazul unei decizii rare și care necesită expertiză mare, poate fi mai bine ca sistemul să semnaleze clar problema și să o direcționeze către o persoană desemnată. Esențial este ca gestionarea excepției să nu fie o cale ocolitoare ascunsă, dependentă de persoană.

Înainte de migrarea datelor, trebuie clarificat cine este responsabil de date

Una dintre cele mai frecvente neînțelegeri în tranziții este că toate datele existente trebuie transferate. Nu neapărat. Migrarea unui set de date vechi de zece ani, incomplet sau duplicat nu este o conservare, ci o perpetuare a vechii incertitudini.

Mai întâi trebuie să se stabilească ce date sunt necesare pentru operațiunile zilnice, obligațiile legale sau contractuale și analiza de afaceri. Apoi trebuie identificat cine este responsabil de date. Cine este responsabil pentru denumirea, unitatea de măsură și statutul unui articol? Cine poate decide modificarea datelor unui partener? Care sistem este sursa principală dacă aceeași informație despre client apare în CRM, ERP și sistemul de facturare?

Dacă nu există un răspuns clar la aceasta, integrarea doar va răspândi mai rapid discrepanțele. Conexiunea tehnică poate transmite date, dar nu poate decide care date sunt corecte.

Nu testați doar înregistrările, ci și regulile de afaceri

Un import de date nu poate fi considerat de succes chiar dacă toate rândurile au fost încărcate. Trebuie verificat și dacă operațiunile de afaceri importante pot fi efectuate cu datele. Se creează corect comanda? Poate fi rezervat stocul? Sunt aplicate corect TVA, condițiile de plată, prețul sau discountul pe document? Raportul arată același lucru pe care l-a folosit conducerea până acum și, dacă nu, știu exact de ce?

Este util dacă verificarea nu este doar responsabilitatea IT și a furnizorului. Finanțele, depozitul, vânzările și producția pot observa erori care nu sunt neapărat vizibile tehnic, dar care cauzează imediat blocaje în timpul operațiunii.

Cele mai bune practici înainte de tranziția de sistem: responsabilități clare

În timpul tranziției, multe sarcini ajung la „cineva”. Cineva trebuie să aprobe datele master, să verifice importul, să informeze utilizatorii sau să ia o decizie într-o chestiune deschisă. Totuși, „cineva” nu este un domeniu de responsabilitate.

Încă de la începutul proiectului, trebuie stabilit cine ia decizii de afaceri, cine este responsabil de proces, cine pregătește datele, cine efectuează modificările tehnice și cine poate autoriza lansarea în producție. Este deosebit de important să se delimiteze limitele decizionale. Un dezvoltator nu poate decide singur dacă o excepție de facturare este acceptabilă din punct de vedere al afacerii, dar nici un manager de afaceri nu trebuie să ofere un răspuns tehnic la nivel de bază de date.

Clarificarea responsabilităților face vizibilă și încărcarea persoanelor cheie. Multe proiecte încetinesc pentru că aceiași doi experți efectuează operațiunile zilnice, în timp ce de la ei se așteaptă toate testele și aprobările. În astfel de cazuri, planul de tranziție trebuie să ia în considerare înlocuirea, ferestrele de timp dedicate sau capacitatea temporară.

Lansarea în producție nu trebuie să fie primul test complet

Mediul de testare nu este o garanție în sine. Oferă siguranță reală dacă compania testează scenarii care sunt critice pentru operațiunile zilnice. În cazul unui depozit, acestea pot include recepția, depozitarea, comisionarea, inventarul și livrarea. În producție, eliberarea materialelor, gestionarea fișelor de lucru, înregistrarea rebuturilor și recepția produselor finite. În comerț, lanțul de comandă, plată, facturare, returnare și informare a clienților.

Testul ar trebui să fie efectuat, pe cât posibil, cu cantități și roluri realiste. Nu este suficientă o singură comandă de probă dacă, în operațiunea normală, datele sosesc din mai multe canale, au loc mișcări de stoc și mai multe persoane lucrează pe același fișier. De asemenea, este important ca testerii să nu verifice doar ceea ce noul sistem trebuie să știe, ci și ceea ce a dus anterior la o eroare.

Pentru decizia de lansare în producție, este util să se stabilească în avans condițiile de acceptare. Ce procese trebuie să funcționeze fără erori? Ce discrepanță poate fi gestionată după lansare și ce oprește tranziția? Acest lucru evită o decizie incertă, bazată pe impresii, de „a merge în producție”.

Este necesar un plan de revenire, dar nu este același în toate cazurile

Planul de revenire nu este pesimism, ci disciplină de continuitate a afacerii. Dacă apare o eroare critică în noul sistem, toată lumea trebuie să știe cine decide revenirea, ce date pot fi salvate, până când se poate reveni la vechiul sistem și cum sunt gestionate tranzacțiile create în timpul tranziției.

Revenirea completă nu este întotdeauna realistă sau necesară. În cazul unei noi soluții de raportare implementate treptat, de exemplu, vechiul raport poate fi menținut o perioadă. În cazul unei înlocuiri centrale ERP, acest lucru poate fi mult mai complex, deoarece contabilitatea și gestionarea stocurilor paralele între cele două sisteme pot crea noi discrepanțe. Aici trebuie evaluat în prealabil cât timp poate fi menținută vechea operațiune și ce risc reprezintă gestionarea dublă a datelor.

Planul trebuie să ia în considerare și impactul asupra clienților, furnizorilor și angajaților. Dacă o întrerupere cauzează întârzierea confirmării, livrării sau facturării, trebuie să existe o procedură clară de comunicare și manuală. O tranziție bine pregătită nu este bună pentru că nu există niciodată probleme, ci pentru că organizația nu improvizează când apar probleme.

Primele zile după lansare fac parte din proiect

Tranziția nu se termină când se apasă butonul de lansare în producție. Erorile care apar în primele zile dezvăluie rapid unde a existat o discrepanță între funcționarea presupusă și cea reală. Pentru aceasta, este nevoie de un sistem de suport desemnat, o cale de decizie rapidă și o listă comună de gestionare a erorilor.

Este util să se facă distincția între erorile care opresc funcționarea, problemele care pot fi gestionate cu o soluție ocolitoare și cerințele de dezvoltare. Dacă fiecare observație primește aceeași urgență, echipa își pierde concentrarea. Totuși, dacă problemele critice devin rapid vizibile, conducerea poate lua decizii mai bine fundamentate privind prioritățile.

Întrebările bune puse înainte de tranziția de sistem sunt adesea mai valoroase decât o listă lungă de funcții. Ce muncă facem doar din obișnuință? Unde se creează aceeași informație de două ori? Cine poate repara singur procesul? Dacă se dau răspunsuri sincere la aceste întrebări, noul sistem nu doar înlocuiește vechiul, ci oferă o funcționare mai previzibilă pentru creștere.