Fiwe presenterar – en artikelserie om implementering av MDM-lösningar i moderniseringsprojekt

Vid modernisering av affärssystem stöter vi ofta på komplexa utmaningar som berör allt från datakvalitet och förändringshantering till resursallokering. Hos Fiwe Systems & Consulting har vi samlat ovärderliga insikter genom våra projekt av att aktivt engagera verksamheten, effektivisera förändringsprocesser och optimera användningen av MDM-verktyg för att maximalt stärka datakvaliteten.

Vår djupgående artikelserie, baserad på en mängd intervjuer, utforskar de mest värdefulla lärdomarna från våra senaste projekt. Vi delar med oss av både framgångar och utmaningar, för att ge dig en unik inblick i hur MDM kan revolutionera ditt företags datahantering och framförallt ur perspektivet att genomföra ett affärssystemsbyte eller uppgradering. Se till att prenumerera på vår mailinglista för att få direkt tillgång till varje nytt avsnitt i denna upplysande serie.

Vikten av Data Discovery 

Data Discovery handlar om att hitta data och identifiera hur den är kopplad inom organisationen. Det är viktigt att förstå sambanden mellan sin data för att kunna göra en smidig implementation av Master Data Management.  

Vår kollega Peter Karlsson har varit djupt involverad i ett av Fiwe´s senaste MDM-projekt. Vi har ställt ett gäng intressanta frågor till honom kring detta ämne. 

Vilka var de största utmaningarna ni stötte på under projektet? 

Den största utmaningen var att förstå nuläget. Informationen var ofta fragmenterad, spridd över många system och format, och ingen hade översikt över hela bilden. Det var svårt att skapa en komplett karta över läget. 

Hur påverkade detta er som projektleverantör? 

Det gjorde det svårt att förstå helheten. Den förståelsen är avgörande för en smidig implementation. Många frågor förblev obesvarade under långt tid. Det gjorde det ofta utmanande att komma vidare, och att säkra att vi jobbade i rätt riktning. 

Hur fungerade dialog och kommunikation mellan er som leverantör och beställarorganisationen? Fick ni prata med rätt personer och med rätt roller? 

I början var det svårt. De som var ansvariga på beställarsidan var utvalda baserat på sin tekniska kompetens. Det gjorde att diskussionerna ofta fastnade i tekniska detaljer, och vi fick inte tillräckligt uttömmande svar. Det är viktigt att förstå skillnaden mellan ”vad” och ”varför”, då är det otillräckligt med enbart den tekniska kompetensen. Man får reda på ”vad”, men alltför sällan ”varför”. 

Hur påverkade projektets framgång av detta? 

Vi visste vad som gjordes, men inte alltid varför det gjordes. Det gjorde det svårt att dra rätt slutsatser och ta rätt beslut inför nästa steg i projektet. 

Hur hade ni kunnat undvika det här problemet? 

Vi borde varit tydligare med vilka deltagare som behövdes framförallt från affärssidan. 

Framgången i ett implementationsprojekt ökar ofta om man får tillgång till en ”allvetare” från beställarorganisationen. Någon som har ett ”paraply”-kunnande, inte nödvändigtvis i detaljfrågor men en tillräcklig bredd för att kunna ge information om samband och beroende över hela systemfloran. Hade ni tillgång till en sådan person i det här projektet? 

Nej, någon sådan person fanns inte, och det var en stor utmaning. 

Hur löste ni ut det? 

Vi samarbetade med ett annat delprojekt, som startade en liknande resa 1 år före vårt projekt. Deras resa var i mindre omfattning och mer fokuserat på just det delsystemet, men i övrigt fanns det flera gemensamma nämnare. Vi utnyttjade deras slutsatser som grund, och även om det ändå fanns många luckor gav det oss en bra utgångspunkt. 

Hur säkrade ni att den information ni fick tolkades korrekt? 

Det var en utmaning. Det är något vi kommer få se svart på vitt först när vi är framme vid testfasen. 

Ok, så projektet är inte helt avslutat ännu? 

Delar av leveransen är klar och i drift ute i organisationen, men de stora integrationspunkterna är ännu inte i drift. 

Dokumentation är en viktig källa till information, fanns det tillräckligt dokumenterat för att få en bra start på projektet? 

Nej, dokumentationen var i vissa fall bristfällig, och det var svårt att veta vad som fortfarande var giltigt i det material fick. Förändringar kan mycket väl ha skett efter att dokumentationen skrivits och utan att den uppdaterats. Flera av systemen vi interagerar med har varit i drift i mer än 30 år. 

Hur påverkades tidsplanen av dessa brister? 

Vår ambition vid projektets start var att 3 månader in kunna leverera de första delarna, men det blev försenat. Den primära orsaken till detta är att det varit mycket mer ändringar och korrigeringar än vad vi förväntat oss. Till stor det beroende på bristande översikt på den existerande datastrukturen. 

Nu när vi genomför den här intervjun så har det gått 10 månader, hur ser läget ut just nu? 

Vi har idag en mycket bättre helhetsbild på datastrukturen och omfattningen av den, och vi ser mycket ljust på de sista delarna i projektet. 

Vad är den enskild största ”take-away” ni fått från projektet inom området Data Discovery? 

Verktyget ”Data Catalog & Governance”, som är en del i Informaticas MDM-suite, har varit ett ovärderligt hjälpmedel. Den har visat sig vara ett mycket effektivt sätt att kartlägga och dokumentera lösningen. I om med att datakatalogen är hjärtat i själva konfigurationen blir den självdokumenterade.  Detta leder i sin tur leder till att det inte går att ”glömma av” att dokumentera en förändring. Underhållskostnaden för dokumentation blir därför minimal, det är ju redan klart samma stund som man sparar sina konfigurationsförändringar.

”Verktyget ”Data Catalog & Governance”, som är en del i Informaticas MDM-suite, har varit ett ovärderligt hjälpmedel. Den har visat sig vara ett mycket effektivt sätt att kartlägga och dokumentera lösningen.”

Artikelförfattare:

Bosse Axhill

Business Analyst på Fiwe

Bosse har sedan mitten av 90-talet arbetet med en stor variation av systemintegrationer och inom en lång rad branscher. Med sin långa erfarenhet från både systemutveckling såväl som projektledning och kravanalys har han skapat sig förmågan att engagera sig och kunna bidra i de allra flesta IT-relaterade uppdrag och projekt

Läs mer här om Bosses roll på Fiwe

Bosse Axhill 2 Fiwe