Când poți opri sistemul vechi: unde închei comenzile deschise
Ce faci cu operațiunile începute înainte de migrare: trei alegeri și o fișă pentru a decide când poți retrage vechiul flux.
Poți retrage vechiul sistem pentru un flux când munca începută acolo are un loc verificat în care să se încheie, iar celelalte operațiuni nu mai depind de funcțiile pe care le oprești. O comandă importată în noua aplicație poate fi vizibilă și totuși imposibil de continuat. Înainte de data opririi, trebuie stabilit unde se livrează restul, unde se face o corecție și cine decide care informație este corectă.
La SurCod, construim produse software și sisteme pentru afaceri și rămânem implicați în operare, mentenanță și îmbunătățiri[1]. Pentru un sistem care înlocuiește altul, asta pune o întrebare de proiectare: până unde merge responsabilitatea noului sistem asupra muncii deja începute? Răspunsul se vede mai bine pe o comandă decât pe o diagramă cu două baze de date.
Comanda începută înainte, corecția cerută după
Să luăm un exemplu ipotetic. O firmă are o comandă acceptată și livrată parțial. La trecerea în noua aplicație, echipa copiază clientul, produsele și cantitățile. După trecere, clientul cere schimbarea adresei pentru partea nelivrată.
Operatorul găsește comanda. Dar unde schimbă adresa? Dacă o modifică în noul sistem, depozitul poate continua să citească vechea variantă. Dacă o modifică în vechi, următorul import poate aduce în nou o valoare diferită. Întrebarea rămasă este cine conduce livrarea restantă și de unde citește informația.
Mai târziu poate apărea o cerere de corecție pentru partea deja livrată. A vedea documentul vechi ajută la identificarea operațiunii. Pentru a o corecta trebuie să existe și un traseu de lucru autorizat, cu documentele și referințele necesare.
Într-un interviu istoric publicat de SeniorERP, Paulina Camberea, General Manager Mergeani, descrie compararea facturilor introduse cu cele din aplicația anterioară, înainte de pornire[2]. Relatarea privește o tranziție din perioada denominării. Este un reper concret pentru întrebarea cumpărătorului: cum verifici că informația preluată poate susține munca firmei?
Alege unde se încheie operațiunile deschise
Pentru comanda din exemplu ai trei alegeri, cu limite diferite.
O termini în vechiul sistem. Comenzile noi încep în aplicația nouă, iar cele deja deschise se încheie în vechea aplicație. Echipa trebuie să poată identifica aceste două grupuri și să știe unde lucrează pentru fiecare. Stabilești cine suportă operarea rămasă și la ce dată reevaluezi ultima dependență. O comandă foarte veche ori o excepție rară poate prelungi perioada.
Transferi operațiunea în noul sistem. Transferul include starea ei: ce s-a livrat, ce mai rămâne, ce documente există și ce acțiuni sunt încă permise. Echipa verifică legătura cu depozitul și cu celelalte sisteme care o folosesc. După momentul convenit, modificările pentru acea operațiune au un singur loc autorizat; celălalt sistem poate păstra o copie pentru citire.
Păstrezi acces limitat la istoric. Alegerea ajută pentru consultarea unei operațiuni încheiate. Pentru comanda încă deschisă trebuie rezolvat separat unde se livrează restul. La fel, dacă apare o corecție, accesul la istoric trebuie însoțit de un proces care o poate executa legitim. Un ecran cu documentul vechi nu oferă singur această posibilitate.
Poți folosi alegeri diferite pentru grupuri diferite de operațiuni. Important este ca un operator să poată afla, pentru comanda pe care o are în față, unde continuă munca.
Fișa de retragere pentru un singur flux
Începe cu livrarea comenzilor acceptate înainte de trecere. Completează aceste șase răspunsuri cu responsabilul operațional și echipa tehnică:
- Ce rămâne deschis? Identifică exact grupul de comenzi și starea lor. Include excepția relevantă: livrare parțială, retur ori corecție în așteptare.
- Unde se lucrează după trecere? Numește aplicația și acțiunea: modificarea adresei, livrarea restantă, închiderea comenzii. Separă locul de lucru de locul unde se consultă istoricul.
- Cine decide informația corectă? Numește responsabilul de business care poate rezolva o diferență și sursa din care lucrează operatorul. „Cele două baze se sincronizează” nu stabilește cine decide când valorile diferă.
- Ce probă permite retragerea funcției vechi? Cere continuarea unei comenzi de test din starea preluată până la rezultatul așteptat. Verifică unde apare modificarea, ce vede depozitul și cum ajunge operațiunea în raportul folosit de firmă.
- Ce mai depinde de sistemul vechi? Notează raportul, exportul, integrarea sau corecția care încă îl folosește, cu responsabil și condiție de închidere.
- Ce poți recupera dacă trecerea eșuează? Cere echipei să precizeze ce stare poate restaura, cum recuperează schimbările făcute între timp și ce efecte externe trebuie reconciliate, cum ar fi o livrare deja expediată.
În exemplul nostru, alegerea este transferul în nou. Fișa ar putea spune: comenzile livrate parțial sunt preluate cu documentele existente; adresa pentru rest se schimbă numai în nou; responsabilul de logistică soluționează diferențele; depozitul și raportul citesc noua stare.
Proba arată însă că exportul pentru depozit continuă să citească adresa din vechi. Ai găsit o condiție lipsă precisă. Păstrezi funcția de care depinde exportul până când traseul nou este pregătit și verificat. Comanda vizibilă în nou nu justifică încă oprirea acelui traseu.
Când fișa îți permite să decizi
În ghidul Microsoft despre migrarea graduală, sistemul vechi se retrage după mutarea funcționalităților și eliminarea dependențelor de el[3]. Pentru un decident, dependența trebuie numită în limbajul muncii: depozitul citește adresa de aici, raportul de vânzări se generează aici, corecția se poate face încă doar aici.
Thoughtworks descrie rapoartele care agregă informații din mai multe părți ale afacerii ca o posibilă piedică în retragerea sistemului vechi[4]. De aceea, proba comenzii include și raportul folosit pentru decizie. Altfel, poți muta livrarea și păstra pe ascuns aceeași dependență prin raportare.
Fișa unui flux îți permite să decizi asupra acelui flux. Pentru oprirea întregului sistem trebuie parcurse și celelalte dependențe, inclusiv accesul la istoricul necesar. Poți opri scrierea într-o zonă și păstra citirea în alta; spune exact ce retragi și ce rămâne disponibil.
Coexistența are și cost: două aplicații de operat, legături între ele și oameni care trebuie să știe unde lucrează. Microsoft tratează această arhitectură ca temporară și arată că, pentru un sistem mic, înlocuirea completă poate fi mai simplă[3]. Alege trecerea graduală când limitează riscul muncii tale. Pentru o înlocuire integrală, pregătește tot operațiunile deschise, proba și recuperarea; doar momentul schimbării este comun.
Ce ceri echipei care construiește noul sistem
Perspectiva SurCod leagă construcția de operarea și îmbunătățirea sistemului în munca reală[1]. Într-o tranziție, asta înseamnă să discuți limita dintre vechi și nou prin ce poate face operatorul: să termine livrarea, să găsească documentul și să urmeze traseul unei corecții.
Alege acum o comandă încă deschisă și completează fișa. La următoarea discuție cu echipa care construiește sau operează sistemul, cere demonstrația condiției care lipsește: „Arătați-mi unde modific adresa pentru restul comenzii și ce adresă primește depozitul.”
Cu acest răspuns poți autoriza retragerea funcției respective sau poți amâna oprirea pentru un motiv concret. Data din calendar devine o decizie susținută de felul în care continuă munca.