Varför det är svårare att migrera till ett nytt CRM eller ERP än det ser ut — och vad som faktiskt får det att fungera

Det finns en version av CRM- eller ERP-migreringshistorien som går bra. Företaget bestämmer sig för att byta, exporterar sina data, mappar fälten, kör validering, löser problemen och går live på ett fast datum. Teamet tränas. Det gamla systemet pensioneras. Inom några veckor har det nya systemet blivit driftsmiljön och ingen saknar det gamla systemet.

Den versionen finns, men den är inte den typiska. Oftare tar migreringen två till tre gånger längre än planerat, anländer med betydande datakvalitetsproblem och producerar ett system som en betydande del av teamet tyst fortsätter att arbeta runt. Att förstå varför — och vad den framgångsrika versionen har gemensamt — börjar med att inse att det mesta av risken inte ligger i teknologin.

Fördröjningsproblemet: Att stanna för länge på det som fungerar tillräckligt väl

Företag som har vuxit ur sitt nuvarande system byter sällan när de först inser det. De byter efter månader eller år av ackumulerade arbetsvägar: extra kalkylblad som fyller luckorna, e-postkedjor som för information som systemet inte kan hantera, manuell dubbelinmatning mellan verktyg som aldrig var designade att kommunicera med varandra. Förseningen är individuellt rationell — att byta är störande och arbetsvägarna fungerar tillräckligt väl för att klara veckan — men den förstärker det underliggande problemet.

Varje månad ett företag kör på ett system det har vuxit ur, ackumuleras mer data i format som inte matchar vart den behöver gå. Konventionerna blir mer implicita. Fler arbetsflöden införs runt det befintliga systemets begränsningar. När migrationsbeslutet äntligen fattas är problemet betydligt större än vad det skulle ha varit vid första tydliga tecknet på att man har vuxit ur systemet.

Detta är särskilt tydligt vid övergången från kalkylblad till ett strukturerat system. Vad som började som en huvudlista för kunder har blivit femton versioner, underhållna av olika personer på olika avdelningar, med inkonsekventa kolumnnamn, olika relationsspårningskonventioner och varierande nivåer av fullständighet. Migreringsarbetet som behövs beror delvis på hur länge migreringen försenades — och i företag som är vana vid kalkylblad är den förseningen nästan alltid längre än den borde ha varit.

Fällan 'Ren data först'

Den mest pålitliga tron som fördröjer migrering är att data måste vara ren innan migreringen kan börja. Förståeligt nog vill ingen importera ett röra till ett nytt system och behöva hantera konsekvenserna. Men i praktiken blir "ren data först" ett projekt som aldrig tar slut.

Arbetet med datarensning tar längre tid än förväntat. Gränsfall multipliceras. Människor upptäcker inkonsekvenser de inte visste fanns. Nya poster skapas i det gamla systemet under rensningsperioden, vilket också behöver rensas. Beslut om vad som räknas som en dubblett, vad man ska göra med kontakter som inte har varit aktiva på tre år, och hur man ska hantera poster som finns i ett system men inte i ett annat blir omstridda organisatoriska frågor snarare än tekniska uppgifter. När datan förklaras vara redo har månader gått och den nya systemimplementeringen har förlorat sitt driv och ofta sin projektägare.

En mer effektiv metod är att migrera det som spelar roll, acceptera att vissa poster kommer behöva rensas efter migreringen, och använda importprocessen själv för att synliggöra och lösa problem. Ett väldesignat importverktyg — ett som visar din data mappad mot målkatalogen, flaggar dubbletter och formatöverträdelser, och låter dig lösa eller åsidosätta dem innan något committas — är snabbare på att hitta datakvalitetsproblem än en rensning baserad på kalkylblad, eftersom verktyget förstår måldatamodellen och kan tala om exakt vad som bryter mot den. Datarensning som sker under en strukturerad import är kvalitativt annorlunda än datarensning som sker isolerat innan den.

De poster som verkligen behöver vara rena innan migreringen är de aktiva. Historiska kontakter utan aktivitet under två år, ersatta produkter, avslutade affärer från tre räkenskapsår sedan — dessa kan migreras som de är, arkiveras eller lämnas kvar helt. Företaget kan driva utmärkt på ett nytt system som har rena aktiva poster och ett parkerat arkiv av historiska data som ingen regelbundet konsulterar.

Vad som faktiskt behöver flyttas — och vad som inte gör det

Ett av de mest motverkande instinkterna i en migrering är önskan att flytta allt. Om du genomgår störningen av en migrering bör du föra över alla poster, all historik, alla bilagda dokument — och idealiskt återställa varje rapport och automatiserad arbetsflöde som fanns i det tidigare systemet i det nya. Detta maximerar omfattningen, kostnaden och varaktigheten av migreringen utan att proportionellt öka det levererade värdet.

De flesta historiska data som är äldre än två till tre år konsulteras inte i normala verksamheter. Att återuppbygga gamla rapporter som inte längre tjänar nuvarande affärsbeslut lägger till tid utan att lägga till värde. Anpassade automatiseringar byggda för ett tidigare arbetsflöde återspeglar ofta hur företaget brukade fungera snarare än hur det fungerar nu — att återuppbygga dem troget replikerar begränsningar som hade kunnat tas bort.

Det bättre frågan är inte "vad finns i det gamla systemet?" utan "vad behöver teamet göra sina arbeten från dag ett i det nya systemet?" Svaret är vanligtvis: aktiva kontakter och kunder, öppna affärer och möjligheter, aktuell prissättning och produktinformation, samt tillräckligt med historik för att kunna ha ett meningsfullt samtal med en kund som ringer med en fråga. Detta är vanligtvis bara en bråkdel av vad som finns i det gamla systemet — och att migrera en bråkdel är snabbare, mindre riskabelt och lättare att validera än att migrera allt.

De två migreringsfelen: Tekniskt och mänskligt

Tekniskt migreringsfel är det som diskuteras mest. Skadade poster, fältmappningsfel som placerar ett telefonnummer i ett företagsadressfält, relationer mellan poster som bryts eftersom främlingsnyckelstrukturen skiljer sig mellan system, integrationer som fungerade mot det gamla API:et och har ingen motsvarighet mot det nya. Dessa fel är verkliga och de inträffar, särskilt vid migrering från system med idiosynkratiska datamodeller eller från kalkylblad där strukturen är inkonsekvent och konventionerna är underförstådda snarare än tvingande.

Mänskligt migreringsfel är mindre synligt och vanligare. Det inträffar när den tekniska migreringen lyckas helt — datan finns i det nya systemet, fälten är korrekt mappade, valideringarna godkändes — och sedan använder personer det inte. De loggar in då och då för att uppfylla en chefens begäran. De behåller sina faktiska någon annanstans. De hittar skäl till varför deras specifika situation inte riktigt passar det nya systemets arbetsflöde, vilket är ett annat påstående än "det nya systemet saknar funktionen" — det betyder att systemet har funktionen men den fungerar annorlunda än vad de förväntade sig, och friktionen i det nya arbetsflödet överstiger motivations till att förändra.

Mänskligt migreringsfel löses inte av mer utbildning, vilket är den vanligaste organisatoriska responsen. Utbildning adresserar kunskapsluckor. Den adresserar inte motivationsluckor eller arbetsflödesfriktionsluckor. Människor som slutar använda ett nytt system efter en migrering förstår vanligtvis hur man använder det. De slutar eftersom användandet är långsammare än deras arbetsväg för deras specifika dagliga uppgifter, eftersom systemet inte ger dem något de personligen behöver som de inte redan hade, eller eftersom den organisatoriska dynamin tillåter fortsatt icke-användning utan konsekvens.

Fällan med parallell drift

Standardrådet för migrering är att köra gamla och nya system parallellt tills förtroendet för det nya är etablerat. I princip minskar detta risken: om det nya systemet misslyckas eller ger opålitlig data, finns det gamla kvar som reserv. I praktiken är parallell drift en av de mest tillförlitliga förutsägarna för en misslyckad migrering.

När personer kan uppdatera antingen systemet uppdaterar de ingen konsekvent. Data skiljer sig inom dagar. Det nya systemet visar ett öppet affärtotal; det gamla visar ett annat. En kundpost i det nya systemet har senaste kontakt noterad som två veckor sedan; det gamla systemet visar ett samtal från igår som loggades där av vana. Ett beslut baserat på det nya systemet skiljer sig från samma beslut baserat på det gamla. Teamet förlorar förtroendet för båda, eftersom ingen är auktoritativ — vilket är motsatsen till vad migreringen skulle åstadkomma.

Organisationer som migrerar framgångsrikt gör vanligtvis en hård avskärning: ett specifikt datum efter vilket det gamla systemet är skrivskyddat eller otillgängligt, och det nya systemet är det enda alternativet. Detta tar bort säkerhetsnätet och ersätter det med brådska. Om det finns problem med det nya systemet löses de eftersom det inte finns något alternativ. Obehaget vid anpassning är framlastat och löst. Metoden med parallell drift sprider obehaget över månader utan att någonsin lösa den underliggande frågan om vilket system som är det verkliga.

Excel-utvägen

För företag som flyttar från kalkylblad snarare än från ett annat strukturerat system finns ett fel som inte gäller för system-till-system-migreringar: Excel-utvägen. Eftersom alla redan vet hur man använder ett kalkylblad, och eftersom kalkylblad verkligen är kapabla för vissa uppgifter — ad hoc-analys, flexibel layout, ingen inloggning, ingen behörighetsmodell — återgår personer som tycker att det nya systemet är obekant omedelbart till dem. Inte för att det nya systemet saknar förmågan. Eftersom den mentala modellen och muskelminnet redan finns där, och friktionskostnaden för att lära om ett arbetsflöde som man redan kan är verklig även när resultatet är detsamma.

Excel-utvägen är särskilt svår att stänga eftersom kalkylblad är legitima för vissa användningar. Du vill inte hindra människor från att modellera scenarier i Excel eller bygga ad-hoc-pivottabeller. Vad du vill förhindra är att använda ett kalkylblad som primär post för aktiva kunder, öppna affärer, lagernivåer eller något annat som det nya systemet ska äga. Gränsen är ofta oklar, och utan en tydligt tillämpad policy om vad som hör hemma i systemet jämfört med vad som är tillåtet i ett personligt kalkylblad, töms systemet gradvis när människor finner att deras personliga versioner är snabbare att underhålla. Det nya systemet blir ett rapporteringslager snarare än en driftsmiljö — vilket är samma dynamik som får CRM-användning att misslyckas, bara uppnådd från ett annat håll.

Vad en bra introduktion faktiskt ser ut

De implementationer som lyckas tenderar att dela egenskaper som är oberoende av vilken plattform som valdes.

Det första är en namngiven affärsägare för migreringen — inte en IT-ansvarig vars jobb är att köra det tekniska projektet, utan en affärsperson vars jobb är att säkerställa antagande. Denna person definierar vad som är viktigt med data, fattar beslut om vad som ska migreras och i vilket tillstånd, sätter och verkställer avskärningsdatumet, och hanterar situationer där en avdelning vill fortsätta använda det gamla systemet eller sina egna kalkylblad. Utan denna person är migreringen ett tekniskt projekt snarare än en operativ förändring, och tekniska projekt utan operativt ansvar levererar tillförlitligt under vad som förväntas.

Det andra är ett fungerande system på ett fast datum snarare än en fasad utrullning som drar ut på tiden. När det nya systemet lanseras i ett tillstånd av ofullständighet — vissa funktioner är tillgängliga, andra kommer senare, några integreringar är ännu inte klara — arbetar användare runt luckorna med gamla verktyg. Vanan att arbeta runt det nya systemet etableras innan systemet är fullt funktionellt, och består efter att luckorna är stängda. Det är väsentligt enklare att anta ett komplett system på ett klart datum än att stegvis anta ett och ett under flera månader.

Det tredje är att behandla importprocessen som datakvalitetssteget snarare än en grind innan den. De bästa introduktionsverktygen visar din data mappad mot det nya systemets struktur innan något committas, lyfter fram de specifika posterna och fälten som bryter mot målmålet, låter dig lösa eller åsidosätta varje problem, och behåller ett återställningsalternativ för en rimlig tidsperiod efter committet. Företaget behöver inte rena data när det går in i denna process — det behöver en process som gör datan ren när den kommer ut.

Plattformsfrågan vid migreringstid

Migreringar är inflexionspunkter. Ett företag som har bestämt sig för att flytta från Excel eller från ett förstegenerations-CRM har just då mer fokus på sina egna data och mer organisatoriskt tillstånd att omstrukturera hur information lagras och nås än vad det kommer att ha fram tills nästa migrering. Frågan om vad man ska migrera till är inte enbart en funktionsjämförelse — det är ett strukturellt beslut om huruvida man ska adressera fragmentering samtidigt som man byter plattform, eller skjuta upp det igen.

Ett företag som migrerar sina CRM-data till en plattform där samma poster också är tillgängliga för fakturering, lager, bokning och kundservice har gjort integreringsarbetet en gång och eliminerat den kontinuerliga kostnaden för att hålla separata system synkroniserade. Ett företag som migrerar CRM till ett nytt fristående CRM-system och underhåller separata redovisnings-, lager- och kundservice-system skjuter upp integreringsarbetet och fortsätter att betala underhållskostnaden för integrering på obestämd tid — i ingenjörstid, i reconcilationsinsats och i beslutskvalitet baserad på ofullständig data.

För de flesta företag vid migrationspunkten är den integrerade metoden det bättre långsiktiga beslutet även om det gör migreringen själv mer komplex. Komplexiteten av att migrera från två eller tre system till en plattform vid ett enda ögonblick är begränsad och tillfällig. Komplexiteten av att underhålla två eller tre system kopplade via punktintegreringar är obegränsad och permanent. Migreringar är där det här valet fattas — och det är lättare att fatta medan organisationen redan är i tankesättet att förändra hur den arbetar än vid någon annan tidpunkt.

---