O arhitectură de tranziție care a integrat două ERP-uri și procesele de comandă în șase luni și a dat echipei de business spațiu pentru transformarea reală.
Contextul
O rețea de retail a fost achiziționată de un grup mai mare. Fiecare companie avea propriul ERP, iar procesele de comandă depindeau de ele. Un singur ERP era ținta pe termen lung, dar o migrare completă nu se putea face în siguranță în timpul de care avea nevoie business-ul.
Provocarea
Compania rezultată avea nevoie rapid de procese de comandă funcționale în ambele organizații, fără oprirea operațiunilor și fără o migrare grăbită care să fixeze decizii înainte de clarificarea noului model operațional.
Rezultatul
Ambele ERP-uri și procesele de comandă au fost integrate în șase luni de la achiziție. Cu sistemele funcționând împreună, echipa de business a avut spațiu să facă transformarea reală și remodelarea în ritmul ei, nu sub presiunea integrării.
Abordarea: o arhitectură de tranziție
- Coexistență gândită de la început. Ambele ERP-uri au rămas pe perimetrul lor; un strat de integrare le-a conectat, fără a-l înlocui pe vreunul.
- Responsabilitate clară pentru date. Pentru fiecare entitate principală (articole, furnizori, magazine, prețuri, comenzi) un singur sistem a fost sursa, cu o corespondență între cele două sisteme de coduri.
- Un singur proces de comandă. Comanda a fost armonizată cap-coadă, astfel încât utilizatorii lucrau cu un singur proces, indiferent de ERP-ul care îl executa.
- Construită să fie temporară. Fiecare interfață de tranziție a avut un responsabil și un plan de dezafectare, ca starea intermediară să nu devină legacy permanent.
Ce pot lua de aici CTO-ii
După o achiziție, arhitectura țintă nu trebuie să fie primul pas. O arhitectură intermediară, gândită deliberat, câștigă timp pentru deciziile care contează: stabilește responsabilitatea pentru date înainte de interfețe, armonizează procesul de business înaintea sistemelor și planifică ieșirea fiecărei componente temporare din prima zi.
Numele clientului și detaliile care l-ar putea identifica nu sunt publicate. Livrabile tipice într-un astfel de proiect: arhitectura de tranziție, matricea de responsabilitate pentru date, catalogul interfețelor și planul de dezafectare.
