De ce migrarea la un nou CRM sau ERP este mai dificilă decât pare — și ceea ce face o migrare să funcționeze cu adevărat

Există o versiune a poveștii migrării CRM sau ERP care merge bine. Compania decide să facă schimbul, exportă datele, mapează câmpurile, rulează validarea, rezolvă problemele și se lansează la o dată fixă. Echipa este instruită. Sistemul vechi este retras. În câteva săptămâni noul sistem a devenit mediul de operare și nimeni nu regretă pe cel vechi.

Acea versiune există, dar nu este cea tipică. Mai des migrarea durează de două până la trei ori mai mult decât s-a planificat, vine cu probleme semnificative de calitate a datelor și produce un sistem pe care o parte importantă a echipei continuă să-l ocolească în liniște. Înțelegerea de ce — și ceea ce versiunea reușită are în comun — se începe cu recunoașterea faptului că cea mai mare parte a riscului nu se află în tehnologie.

Problema Întârzierii: Rămânerea Prea Mult Pe Ceea Ce Funcționează Suficient

Companiile care au depășit sistemul lor curent rareori fac schimbul în momentul în care și-l dau seama. Fac schimbul după luni sau ani de acumulare a soluțiilor improvizate: foi de calcul suplimentare care umplut golurile, lanțuri de e-mailuri care transportă informații pe care sistemul nu poate, dubla intrare manuală între instrumente care nu au fost niciodată concepute să comunice între ele. Întârzierea este rațională individual — schimbarea este perturbatoare și soluțiile improvizate funcționează suficient pentru a trece prin săptămână — dar agravează problema de bază.

În fiecare lună în care o companie rulează pe un sistem pe care l-a depășit, mai multe date se acumulează în formate care nu se potrivesc cu locul unde trebuie să meargă. Convenții devin mai implicite. Mai multe fluxuri de lucru se înghesuie în jurul limitărilor sistemului existent. Până în momentul în care decizia de migrare este luată, problema este substanțial mai mare decât ar fi fost la momentul prim al depășirii clare.

Acest lucru este deosebit de vizibil în trecerea de la foi de calcul la un sistem structurat. Ceea ce a început ca o singură listă de clienți principală a devenit cincisprezece versiuni, menținute de oameni diferiți din departamente diferite, cu nume de coloane inconsistente, convenții diferite de urmărire a relațiilor și niveluri variabile de completitudine. Munca de migrare care trebuie să se întâmple este parțial o funcție a timpului în care migrarea a fost întârziată — și în companiile native de foi de calcul, acea întârziere este aproape întotdeauna mai lungă decât ar trebui să fie.

Capcana „Curățarea Datelor Înainte"

Cea mai fiabilă credință care întârzie migrarea este că datele trebuie să fie curate înainte ca migrarea să poată începe. Raționamentul este de înțeles: nimeni nu vrea să importe o dezordine în noul sistem și să se confrunte cu consecințele. Dar în practică, „curățarea datelor înainte" devine un proiect care nu se termină niciodată.

Efortul de curățare a datelor durează mai mult decât așteptat. Cazurile limită se multiplică. Oamenii descoperă inconsistențe pe care nu știau că există. Înregistrări noi sunt create în sistemul vechi în perioada de curățare, care au nevoie, de asemenea, să fie curățate. Deciziile cu privire la ceea ce se numără ca o duplicare, ce să faci cu contactele care nu au fost active de trei ani și cum să gestionezi înregistrări care există într-un sistem, dar nu în altul se transformă în întrebări organizaționale contestate mai degrabă decât în sarcini tehnice. Până când datele sunt declarate gata, luni au trecut și implementarea noului sistem și-a pierdut impulsul și adesea proprietarul proiectului.

Abordarea mai eficace este să migrezi ceea ce contează, să accepți că unele înregistrări vor avea nevoie de curățare după migrare și să folosești procesul de import în sine pentru a identifica și rezolva problemele. Un instrument de import bine conceput — unul care îți arată datele tale mapate la structura țintă, semnalează duplicatele și încălcările de format, și te lasă să le rezolvi sau să le ignori înainte ca ceva să se confirme — este mai rapid la găsirea problemelor de calitate a datelor decât o curățare bazată pe foi de calcul, deoarece instrumentul înțelege modelul de date țintă și îți poate spune exact ce o încalcă. Curățarea datelor care se întâmplă în timpul unui import structurat este calitativ diferită de curățarea datelor care se întâmplă în izolare înainte.

Înregistrările care trebuie să fie cu adevărat curate înainte de migrare sunt cele active. Contactele istorice fără activitate de doi ani, produsele depășite, înțelegerile închise de acum trei ani fiscali — acestea pot fi migrate ca și cum ar fi, arhivate sau lăsate deoparte cu totul. Afacerea poate funcționa perfect pe noul sistem care are înregistrări active curate și un arhiv parcat de date istorice pe care nimeni nu le consulta în mod regulat, oricum.

Ceea Ce Trebuie De Fapt Să Se Mute — Și Ce Nu

Una din cele mai contraproductive instincte într-o migrare este dorința de a muta totul. Dacă treci prin perturbarea unei migrări, ar trebui să aduci toate înregistrări, toată istoria, toate documentele atașate — și în mod ideal să reconstruiești fiecare raport și flux de lucru automat care a existat în sistemul anterior în noul. Aceasta maximizează domeniul de aplicare, costul și durata migrării fără a maximiza proporțional valoarea livrată.

Majoritatea datelor istorice care depășesc doi-trei ani nu sunt consultate în operațiunile normale. Reconstruirea rapoartelor moștenite care nu mai servesc deciziile comerciale actuale adaugă timp fără a adăuga valoare. Automatizările personalizate construite pentru fluxul de lucru anterior reflectă adesea cum funcționa afacerea în trecut mai degrabă decât cum funcționează acum — reconstruirea lor cu fidelitate replicează constrângeri care ar fi putut fi eliminate.

Întrebarea mai bună nu este „ce există în sistemul vechi?" ci „ce are nevoie echipa pentru a-și face jobul din ziua unu în noul sistem?" Răspunsul este tipic: contacte și clienți activi, oferte și oportunități deschise, informații actuale despre prețuri și produse, și suficientă istorie pentru a avea o conversație semnificativă cu un client care sună cu o întrebare. Aceasta este de obicei o fracție din ceea ce există în sistemul vechi — și migrarea unei fracții este mai rapidă, risc mai mic și mai ușor de validat decât migrarea tuturor.

Două Eșecuri ale Migrării: Tehnic și Uman

Eșecul migrării tehnice este cel care se discută cel mai mult. Înregistrări corupte, erori de mapare a câmpurilor care pun un număr de telefon într-un câmp de adresă a companiei, relații între înregistrări care se rup deoarece structura cheii străine diferă între sisteme, integrări care au funcționat împotriva API-ului vechi și nu au echivalent împotriva celui nou. Aceste eșecuri sunt reale și se întâmplă, în special în migrări din sisteme cu modele de date idiosincratice sau din foi de calcul în care structura este inconsistentă și convenții sunt implicite mai degrabă decât impuse.

Eșecul migrării umane este mai puțin vizibil și mai frecvent. Se întâmplă când migrarea tehnică reușește complet — datele se află în noul sistem, câmpurile sunt mapate corect, validările au trecut — și apoi oamenii nu o folosesc. Se conectează din când în când pentru a satisface o cerere a managerului. Își mențin înregistrările reale în altă parte. Găsesc motive pentru care situația lor specifică nu se potrivește cu fluxul de lucru al noului sistem, ceea ce este o afirmație diferită de „noul sistem nu are caracteristica" — înseamnă că sistemul are caracteristica, dar funcționează diferit de ceea ce s-au așteptat, și fricțiunea noului flux de lucru depășește motivația de a se schimba.

Eșecul migrării umane nu este rezolvat prin mai multă instruire, care este răspunsul organizațional cel mai comun. Instruirea abordează lacune în cunoștințe. Nu abordează lacune în motivație sau lacune în fricțiunea fluxului de lucru. Oamenii care încetează să folosească noul sistem după o migrare de obicei înțeleg cum să-l folosească. Se opresc pentru că a-l folosi este mai lent decât soluția lor improvizată pentru sarcinile lor zilnice specifice, pentru că sistemul nu le dă nimic pe care să-și doară personal și pe care nu l-au avut deja, sau pentru că dinamica organizațională permite non-utilizarea continuă fără consecință.

Capcana Rulării în Paralel

Sfatul standard de migrare este să rulezi sistemele vechi și noi în paralel până când încrederea în noul este stabilită. În principiu, aceasta reduce riscul: dacă noul sistem eșuează sau produce date nesigure, cel vechi rămâne disponibil. În practică, rularea în paralel este unul dintre cei mai fiabili predictori ai unei migrări eșuate.

Când oamenii pot actualiza fie sistemul, nu actualizează nici unul în mod consecvent. Datele se diverg în zile. Noul sistem arată un total de oferte deschise; cel vechi arată una diferită. O înregistrare de client în noul sistem are ultimul contact notat ca acum două săptămâni; sistemul vechi arată un apel ieri care a fost înregistrat acolo din obicei. O decizie luată pe baza noului sistem diferă de aceeași decizie luată pe baza celui vechi. Echipa pierde încrederea în ambele, pentru că nici una nu este autoritară — care este opusul a ceea ce migrarea era menționată să producă.

Organizațiile care migrează cu succes o fac de obicei ca o reducere bruscă: o dată specifică după care sistemul vechi este doar citire sau inaccesibil, și noul sistem este singura opțiune. Aceasta elimină rețeaua de siguranță și o înlocuiește cu urgență. Dacă există probleme cu noul sistem, acestea sunt rezolvate pentru că nu există alternativă. Disconfortul ajustării este preplanificat și rezolvat. Abordarea rulării în paralel distribuie disconfortul pe luni fără a rezolva niciodată întrebarea de bază a sistemului real.

Porția de Refugiu Excel

Pentru companiile care se mută din foi de calcul mai degrabă decât din alt sistem structurat, există un mod de eșec care nu se aplică migrărilor de la sistem la sistem: porția de refugiu Excel. Pentru că toată lumea știe deja cum să folosească o foaie de calcul, și pentru că foile de calcul sunt cu adevărat capabile pentru anumite sarcini — analiză ad-hoc, aspect flexibil, fără autentificare, fără model de permisiuni — oamenii care găsesc noul sistem neobișnuit se retrag imediat. Nu pentru că noul sistem nu are capacitatea. Pentru că modelul mental și memoria musculară sunt deja acolo, și costul fricțiunii reînvățării unui flux de lucru pe care deja știu să-l facă este real chiar și atunci când rezultatul este același.

Porția de refugiu Excel este deosebit de greu de închis pentru că foile de calcul sunt legitime pentru unele utilizări. Nu vrei să previi oamenii să modeleze scenarii în Excel sau să construiască tabele pivot ad-hoc. Ceea ce vrei să previi este utilizarea unei foi de calcul ca înregistrare primară pentru clienți activi, oferte deschise, niveluri de inventar, sau orice altceva pe care noul sistem ar trebui să-l deține. Granița este adesea neclară, și fără o politică clară impusă cu privire la ceea ce trăiește în sistem în comparație cu ceea ce este permis să trăiască într-o foaie de calcul personal, sistemul se golește treptat pe măsură ce oamenii găsesc versiunile lor personale mai rapide de menținere. Noul sistem devine o strat de raportare mai degrabă decât un mediu de operare — care este aceeași dinamică care face adoptarea CRM să eșueze, doar ajunsă dintr-o direcție diferită.

Ce Arată cu Adevărat Onboarding-ul Bun

Implementările care reușesc tind să aibă caracteristici care sunt independente de platforma care a fost aleasă.

Primul este proprietarul unei afaceri numit al migrării — nu un lider IT al cărui job este să ruleze proiectul tehnic, ci o persoană de afaceri al cărei job este să asigure adoptarea. Această persoană definește ce date contează, face apeluri cu privire la ce se migrează și în ce stare, stabilește și impune data de reducere bruscă, și gestionează situațiile în care un departament vrea să continue să folosească sistemul vechi sau propriile foi de calcul. Fără această persoană, migrarea este un proiect de tehnologie mai degrabă decât o schimbare operațională, și proiectele de tehnologie fără responsabilitate operațională subdeliver în mod fiabil.

Al doilea este un sistem de lucru la o dată fixă, mai degrabă decât o implementare graduată care se trage. Când noul sistem se lansează într-o stare incompletă — unele caracteristici disponibile, altele care vin mai târziu, unele integrări care nu sunt încă gata — oamenii ocolesc golurile folosind instrumente vechi. Obiceiul de a ocoli noul sistem se stabilește înainte ca sistemul să fie complet funcțional, și persista după ce golurile sunt închise. Este substanțial mai ușor să adopți un sistem complet la o dată clară decât să adopți progresiv unul incomplet pe luni.

Al treilea este tratarea procesului de import ca etapa de calitate a datelor mai degrabă decât o poartă înainte. Cele mai bune instrumente de onboarding îți arată datele tale mapate la structura noului sistem înainte ca ceva să se confirme, surfează înregistrări specifice și câmpuri care încalcă modelul țintă, te lasă să rezolvi sau să ignori fiecare problemă, și mențin o opțiune de revenire pentru o fereastră rezonabilă după confirmare. Afacerea nu are nevoie de date curate care intră în acest proces — are nevoie de un proces care face datele curate care ies din ea.

Întrebarea Platformei la Timp de Migrare

Migrările sunt puncte de inflexiune. O afacere care a decis să se mute din Excel sau dintr-un CRM de prima generație are, la acel moment, mai multă atenție asupra propriilor date și mai multă permisiune organizațională de a restructura cum sunt stocate și accesate informații decât va avea în orice moment până la migrarea următoare. Întrebarea a la ce să migrezi nu este pur o comparație de caracteristici — este o decizie structurală cu privire la dacă să aborzi fragmentarea în același timp cu mutarea platformelor, sau să o reamâni din nou.

O afacere care migrează datele sale CRM la o platformă în care aceleași înregistrări sunt de asemenea accesibile pentru facturare, inventar, rezervări și serviciu pentru clienți a făcut munca de integrare o singură dată și a eliminat costul continuu de a ține sistemele separate sincronizate. O afacere care migrează CRM la o nouă platformă CRM independentă și menține sisteme separate de contabilitate, inventar și serviciu pentru clienți reamâne munca de integrare și continuă să plătească costul de mentenanță a integrării la nesfârșit — în timp de inginerie, în efort de reconciliere și în calitatea deciziilor luate pe date incomplete.

Pentru majoritatea companiilor la punctul migrării, abordarea integrată este decizia mai bună pe termen lung chiar dacă face migrarea în sine mai complexă. Complexitatea migrării din două sau trei sisteme într-o singură platformă la un singur moment este delimitată și temporară. Complexitatea menținerii a două sau trei sisteme conectate prin integrări punct este nelimitată și permanentă. Migrările sunt unde această alegere se face — și sunt mai ușor de făcut în timp ce organizația este deja în mentalitatea de a schimba cum funcționează decât în orice alt moment.

---