De sju dyraste mappningsfelen vid byte av affärssystem
I vanlig drift kostar en felaktig mappning timmar. Vid övergången till ett nytt affärssystem kostar den dagar, ibland ett helt kvartal. Vi ser samma sju fel gång på gång, och alla går att undvika.
1. Mappningen som blir klar för sent
Enligt projektplanen skulle mappningarna vara klara vecka sex. Det var de inte. Bygget drog i gång ändå, för det stod i tidplanen. Varje ändring i mappningen efter vecka sex betyder nu att något som redan är byggt måste göras om.
Lösning: Se mappningen som en förutsättning, inte som ett parallellt spår. Bygget börjar inte förrän mappningen är godkänd.
2. Målet som flyttar sig
Det nya affärssystemets struktur för konton, kostnadsställen och kundtyper ska vara spikad från start. Ofta är den inte det. Mappningar som stämde på tisdagen är fel på fredagen, för målstrukturen har ändrats.
Lösning: Frys målschemat innan mappningen börjar. Behandla ändringar i målet som ändringar av projektets omfattning, inte som justeringar.
3. De inaktiva koderna som glöms bort
Det nya affärssystemet behöver både aktuell och historisk data. Den historiska datan innehåller koder som inte längre är aktiva i källsystemet. Någon antar att inaktiva koder inte behöver mappas. Vid första månadsbokslutet visar det sig att fjolårets jämförelsesiffror bygger på koder som inte finns i det nya systemet.
Lösning: Mappa alla koder som någon gång har förekommit i källsystemet, aktiva eller inte. Markera dem som inaktiva i målet om det behövs, men hoppa inte över dem.
4. Den stora inklistringen utan kontroll
Under projektet byggs mappningarna oftast i Excel. Någon klistrar in tusen rader från en export. Några har inledande nollor som Excel tar bort. Några har blanksteg som inte finns i källan. Migreringen körs, och fellistan fylls med avvikelser som alla går att spåra till en och samma inklistring.
Lösning: Kontrollera varje inklistring när den sparas. Klarar Excel inte det, så bygg inte mappningen i Excel.
5. Standardvärdet som ingen märker
Mappningen säger vad som ska hända med kända värden. Den säger ingenting om okända. Vid övergången blir ett omappat värde antingen en avvisad rad eller ett standardvärde. Det värsta som kan hända är ett felaktigt standardvärde på tusentals rader. Inläsningen gick ju igenom utan fel, så ingen märker något förrän någon granskar rapporten.
Lösning: Bestäm det uttryckligen. För de flesta fält är det säkrare att avvisa omappade värden. Måste ni ta emot dem, låt standardvärdet vara ett tydligt ”okänt”, aldrig ett riktigt värde.
6. Parallellkörningen som glider isär
Under parallellkörningen måste mappningarna hållas i synk med källsystemet. Nya koder i det gamla systemet behöver mappas. Det gamla systemet lever vidare och mappningarna hänger inte med. Vid övergången har luckorna hunnit bli många.
Lösning: Gör mappningen till en del av processen när källsystemet ändras, inte till något som görs i klump i efterhand. Den som lägger till en kod ansvarar också för att mappa den.
7. Ingen äger mappningarna efter driftstart
Projektgruppen byggde mappningarna. Projektgruppen upplöses vid driftstart. Nya koder dyker upp. Ingen ansvarar för att lägga till dem.
Lösning: Utse en ägare i förvaltningen för varje mappning före driftstart. Låt den personen göra minst en mappning själv medan projektgruppen finns kvar.
Sammanfattning
| Fel | Typisk kostnad när det slår till |
|---|---|
| Mappning klar för sent | Veckors omarbete |
| Mål som flyttar sig | Ett ständigt småfixande |
| Bortglömda inaktiva koder | Tidigare perioder måste räknas om |
| Inklistring utan kontroll | Hundratals omappade rader efter övergången |
| Tyst standardvärde | Fel data i det nya systemet, svårt att rätta i efterhand |
| Parallellkörning som glider isär | Luckan upptäcks vid övergången, för sent |
| Ingen ägare | Datakvaliteten försämras hela tiden |
Ett enskilt fel går att rätta till. Tre eller fyra tillsammans gör ett projekt på arton månader till ett på trettio.
Alla sju har samma grundorsak. Mappningen behandlas som något man tar fram en gång, inte som ett levande system. Kalkylark, en ägare bara så länge projektet pågår, ingen validering, ingen spårbarhet. Lösningen ser likadan ut varje gång: flytta mappningarna till ett system som tvingar fram struktur, sparar varje ändring, har en namngiven ägare och gör resultatet tillgängligt för andra system. I gridmap är det systemet ett register, och det fungerar likadant under migreringen som efteråt. Då finns det ingen överlämning att göra efter driftstart.
Att undvika de sju felen kostar lite: bättre disciplin från början och lite mer struktur runt mappningsarbetet. Att trampa i bara ett av dem kan i en riktig migrering kosta ett kvartals försening och skador i verksamheten som ingen kan sätta en siffra på. Det är sällan en svår kalkyl.