Cum se face migrarea datelor în ERP, fără pierderi

Datele proaste costă organizațiile în medie 12,9 milioane de dolari pe an, arată cercetarea Gartner — iar migrarea într-un ERP nou e exact momentul în care datele proaste ies la iveală, nu momentul în care apar. Migrarea datelor nu e un import tehnic care rulează peste noapte; e procesul prin care decizi ce date chiar merită mutate, le cureți, le mapezi corect pe structura noului sistem și verifici, înainte de go-live, că totul se potrivește cu realitatea. Ghidul de față trece prin pașii tehnici concreți ai migrării — nu doar la nivel de checklist, ci cu ce verifici exact la fiecare etapă.

Cum se face migrarea datelor în ERP

Migrarea datelor înseamnă mutarea informațiilor de business — clienți, furnizori, stocuri, tranzacții financiare, istoricul comenzilor — din sistemele vechi (Excel, ERP legacy, exporturi parțiale) în structura noului sistem. Procesul are patru etape distincte: pregătire (ce migrezi și de unde), curățare și mapare (cum arată datele în sistemul nou), testare și validare (confirmi că totul e corect înainte de go-live) și cutover-ul propriu-zis (trecerea efectivă, cu plasă de siguranță).

Fiecare etapă are propriile verificări — le detaliem mai jos, cu pașii tehnici concreți, nu doar la nivel de principiu general.

Ce date migrezi și cum le pregătești

Primul pas nu e tehnic, e de decizie: ce date chiar merită mutate. Un audit de date, înainte de orice altceva, răspunde la patru întrebări:

• Volum — câte înregistrări există pe fiecare categorie (clienți, furnizori, articole, tranzacții)?
• Vechime — cât de departe în urmă trebuie să meargă istoricul migrat, față de ce poate fi arhivat?
• Calitate — ce procent din înregistrări au erori, duplicate sau câmpuri lipsă?
• Structură sursă — cum se mapează modelul de date vechi pe schema noului ERP?

Nu tot ce există în sistemul vechi merită migrat. Tranzacții istorice de peste 3-5 ani se arhivează, de regulă, separat, într-un mediu read-only de raportare, nu se mută în sistemul activ. Clienți inactivi de ani de zile, furnizori fără comenzi deschise, articole discontinuate — migrarea lor „ca să fie toate" aglomerează sistemul nou și încetinește migrarea în sine, fără beneficiu real. Arhivează agresiv; migrează doar ce chiar folosești operațional.

Pregătirea nu e un singur eveniment. Firmele care fac migrări incrementale — seturi mici de date, la intervale regulate, pe parcursul dezvoltării, nu doar o încărcare masivă chiar înainte de go-live — ajung la lansare cu un set de date deja parțial validat, nu cu tot riscul concentrat într-o singură fereastră de import.

Curățarea și maparea datelor

Curățarea vine înaintea mapării, nu invers — nu are sens să mapezi date duplicate sau inconsistente pe structura nouă, doar ca să le corectezi acolo. Pașii tipici:

• Deduplicare — clienți sau furnizori înregistrați de mai multe ori, sub nume ușor diferite
• Standardizare de format — adrese, numere de telefon, coduri de TVA, unități de măsură, scrise consistent
• Completare câmpuri obligatorii — sistemul nou poate cere date pe care cel vechi nu le-a impus niciodată (de exemplu cod CAEN sau alt câmp de clasificare)

Maparea propriu-zisă documentează, câmp cu câmp, cum se traduce fiecare element din sistemul vechi în cel nou — și, unde structurile nu coincid direct, ce logică de transformare se aplică. E o muncă de detaliu, nu doar clerică: șabloanele oferite de furnizor ajută, dar migrarea are nevoie și de cineva care înțelege ambele sisteme, nu doar „completează template-ul". Implică, pe lângă echipa tehnică, oameni din finanțe, vânzări și operațiuni — ei recunosc rapid o valoare greșit mapată pe care echipa tehnică o vede doar ca „dată validă, format corect".

Testarea migrării și validarea rezultatelor

Testarea nu așteaptă până la final. Din momentul în care primele date sunt transferate, verifici rezultatele — nu aștepți să rulezi totul ca să descoperi o problemă sistemică prea târziu ca s-o corectezi ieftin.

Migrări pilot, pe eșantion, înaintea migrării complete: încarci un set limitat de date reale, verifici rezultatul, corectezi ce nu se potrivește, repeți. Fiecare rundă de test compară explicit datele migrate cu cifrele din sursă — nu „pare corect", ci verificare linie cu linie pe un eșantion reprezentativ.

Testarea trece dincolo de format. Confirmarea că un câmp s-a completat corect nu e suficientă — validezi și că datele funcționează în scenarii reale de business: o factură migrată generează raportul corect, un client migrat apare corect în istoricul de comenzi, un produs migrat calculează corect stocul disponibil.

Utilizatorii de business validează, nu doar echipa tehnică. Cineva din finanțe sau vânzări recunoaște o discrepanță pe care un developer o citește ca „date valide, format corect" — pentru că înțelege ce ar trebui să însemne cifra, nu doar cum arată tehnic.

Documentează fiecare rundă de testare — ce s-a verificat, ce a picat, ce s-a corectat. Pe lângă utilitatea imediată, documentația asta devine referință dacă apare o discrepanță după go-live: poți verifica rapid dacă problema exista deja în datele testate sau a apărut din altă cauză.

Bune practici pentru un go-live fără pierderi

Cutover-ul — trecerea efectivă de la sistemul vechi la cel nou — are nevoie de reguli clare, stabilite dinainte, nu improvizate în weekend-ul lansării:

• Definește data de îngheț a sistemului vechi — din ce moment nu se mai introduc date acolo
• Calculează fereastra de migrare — câte ore durează migrarea finală, ca să nu blochezi operațiunile mai mult decât ai anunțat
• Fă un backup complet, verificat, înainte să pornești — nu „presupui" că a rulat corect
• Pregătește un plan de rollback explicit, pentru cazul în care validarea finală eșuează
• Programează cutover-ul într-un weekend sau la final de lună — începi vineri seara, ținta e luni dimineața funcțional, cu o zi întreagă de rezervă în plan

Migrarea nu se termină la go-live. Primele două-trei săptămâni în sistemul nou sunt momentul în care apar problemele pe care testele nu le-au prins — cazuri marginale, combinații de date neobișnuite, fluxuri rar folosite. Monitorizare activă în perioada asta, cu cineva responsabil clar de rezolvarea rapidă a discrepanțelor, face diferența între un go-live curat și săptămâni de corecții manuale descoperite pe rând.

Întrebări frecvente

Cât durează migrarea propriu-zisă de date?

Variază cu volumul, dar fereastra de cutover — perioada în care sistemul vechi e înghețat și noul sistem preia — durează de regulă de la câteva ore la un weekend întreg. Pregătirea dinaintea ei (audit, curățare, mapare, teste pilot) durează mult mai mult, adesea săptămâni.

Ce se întâmplă cu datele care nu se mapează direct pe noul sistem?

Se documentează o regulă de transformare explicită — un câmp din sistemul vechi poate deveni o combinație de câmpuri în cel nou, sau poate necesita o valoare implicită acolo unde vechiul sistem nu cerea deloc informația respectivă.

Poți migra datele treptat, în loc de tot deodată?

Da — migrarea în paralel sau în etape reduce riscul de cutover, mai ales la volume mari. Recomandată mai ales pentru organizații mari; pentru un proiect mic, o migrare completă dintr-o dată poate fi mai simplă de gestionat.

Cine ar trebui să valideze datele migrate, nu doar să le transfere?

Un mix: echipa tehnică verifică formatul și completitudinea, dar oamenii din finanțe, vânzări și operațiuni confirmă că datele au sens în contextul de business real — cele două tipuri de validare prind categorii diferite de erori.

Migrarea de date bine făcută e invizibilă — utilizatorii se loghează în sistemul nou și găsesc exact ce așteaptă, corect structurat. Ajungi acolo prin disciplină la fiecare etapă, nu printr-un import rulat o singură dată și sperat să fie bine. Pentru contextul complet al proiectului, vezi etapele implementării unui ERP și ghidul despre sisteme ERP la comandă, sau explorează seria despre implementare ERP și toate ghidurile despre ERP.