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.
Del 4 – Utmaningarna med datakvalitet
Datakvalitet är en av de viktigaste sakerna att ta tag i under affärssystembyten och moderniseringsprojekt. – Peter Karlsson igen, som leverantör gick ni in med ganska ”blankt papper”. Inom det här ämnet, vilket var det första steget ni tog?
Det första vi ville göra var att skapa oss en egen bild av vad det är för utmaningar vi har framför oss. Det var faktiskt väldigt lätt att få svar från verksamheten – men svårare att få rätt och tillräckligt utförliga svar. Vid en första anblick återspeglas sällan verkligheten. Svaren blir ofta att man är duktig på städning och rensning, att man är duktig på att hålla ordning på sin data och att det är korrekt och bra. Och det är tyvärr alltför ofta inte hela sanningen.
Hur kommer det sig?
Man får tänka på att de här människorna kommer faktiskt från en fungerande verksamhet. Beställningar kommer in, ordrar expedieras och kunderna får sina varor – och ur det perspektivet verkar ju allt vara bra och rätt. Det man däremot inte ser är att längs vägen finns många individer som fixar och rättar saker manuellt. Åtgärder som kostar både tid och pengar och dessutom skapar personberoende och med det en sårbarhet.
Ok, så målet är att ta sig förbi den första föreställningen om att allt står rätt till. Hur gör ni det?
Vi börjar med att begära ut en sub-set av data från ett antal entiteter som är primära för just den verksamheten. Kund, Produkt, Leverantör etc..
Får ni då en tydlig bild av dessa entiteter?
Nej, så enkelt är det tyvärr aldrig, i just det här fallet så hämtades sub-seten ut från ERP-system som varit i drift under nära 40 års tid. Och det var inte överraskande att ett kundkort som registrerades under sena 1900-talet skilde sig avsevärt från ett kundkort registrerat i år.
När vi gör den första analysen av den här datan så använder vi verktyg för Data Profiling, men utan att gå in och detaljstudera exakt vad som står i respektive fält. Målet i detta steg är i stället att få fram normalfördelningskurvor för saker som ifyllnadsgrad. T.ex hur stor andel av fältet för organisationsnummer är ifyllt för kunder och leverantörer.
Vad använder ni resultatet av den analysen till?
Värdet av detta är att redan tidigt i projektet kunna påbörja städning, och just ifyllnadsgrad är en typiskt ”lågt hängande frukt”. Det går enkelt att analysera och även enkelt att lämna över för berikning medan man dyker djupare i analysen av övriga data. Dessutom ger den första analysen en fingervisning både för oss i projektet, såväl som för beställarorganisationen, om hur det faktiskt står till med datakvalitén i stort. Resultatet blir ett diskussion- och beslutsunderlag inför vilka steg man skall ta härnäst och i vilken ordning de skall göras.
Gör man då denna upprättning i verktyget för Data Profiling?
Nej, det gör man inte, man rättar i källsystemet. Data Profiling-verktygen är i första hand till för att identifiera, inte rätta. Gör man det direkt i källan så blir allt senare arbete med moderniseringen enklare. Det är ju lite som det lite fula uttrycket ”skit-in-skit-ut”. Blir den felaktiga eller saknade datan kvar i källsystemet riskerar den att kontaminera helheten genom hela moderniseringen, för att hantera det enkelt behöver man implementera och strikt följa temporära och kostsamma rutiner. Bättre då att rätta i källan så att man är säker på att det är kvalitet man får ut.
Finns det andra vinster med den här första analysen?
Ja absolut, den tvingar ju verksamheten att faktiskt ta en mer noggrann titt på sin data. Man granskar den mer kritiskt. Bland annat finns det ofta klara orsaker till att viss viktigt data som exempelvis organisationsnummer med mera saknats under lång tid, och ändå inte upptäckts. Orsaker som att kunder faktiskt inte är kund längre, och rimligen borde inaktiveras, eller rent av städas bort. Även sådant är en väldigt viktig del i upprätthållandet av hög datakvalitet.
Hur väl stämde kvalitetsnivån med er förväntan?
Jag får erkänna att jag blev förvånad över hur låg kvaliteten faktiskt var. Men det beror ju också på vad man lägger för definition i vad kvalitet är. Verksamheten har ju trots allt fungerat, även före moderniseringen, och när du har människor som läser av till exempel leveransadresser så har de oftast kunnat leverera, även om det finns annan data utöver själva adressen, eller rent av fel och missvisande data.
Vad syftar du på då, har du något exempel?
Ja, det kan till exempel vara instruktioner om vilken dörr man skall leverera paket till, telefonnummer man skall ringa till för att någon skall öppna, specialinstruktioner för leverans på måndagar, andra för torsdagar.
Inget av detta är ju data som har att göra i ett adressfält, men i brist på andra ställen att lagra informationen har den ändå hamnat där. Och på frågan om vad som definieras som bra och dålig kan man säga att mängden data är mycket bra och informativ – vilket är bra, men strukturen på den gör den svårhanterlig – vilket är dåligt. Alla sådana här avvikelser behöver identifieras och bättre sätt att lagra och hantera dem behöver skapas. Så ”i kråksången” har vi här ännu en förbättringspotential identifierad redan i den inledande analysen av datakvalitet.
När man använder vissa fält för flera syften som du beskriver ovan, och orsaken är att det saknas många värdehållare – blir man inte då ändå tvungen att rätta i målsystemet och inte i källan?
Ja så är det ju, och det är ju inte helt svart på vitt heller. Utgångspunkten är att alltid rätta i källan, men där det inte är möjligt eller då man identifierar högre effektivitet eller bättre resultat att ta emot den felaktiga datan och rätta den med hjälp av nya verktygen så gör man det såklart. Och allra helst med så hög grad av automatisering som möjligt.
Jag misstänkte det, kan du berätta mer? Några bra exempel?
Absolut, vi har ett konkret exempel när det kommer till begreppet ”Land”. I det här fallet fann vi att de flesta variationer var återkommande och enhetliga. Beroende på vem som registrerade, och vad hen hade som modersmål kunde Grekland läggas upp som just ”Grekland” av någon som har svenska som modersmål, men som ”Grækenland” för de som talar danska, eller som i vissa fall enbart med nationalitetsbeteckningen ”GR”. Till detta skapade vi nya kvalitetregler som automatiskt identifierade landet i samband med onboarding och satte den gemensamma benämningen på registreringen av landstillhörighet på leverantörsposten.
Men innebär inte det att problemen kommer fortsätta? Samma människor som registrerat med olika språk och koder i de gamla systemen kommer väl fortsätta göra det i det nya.
Sant, men vi ser till att det löses av sig själv. I den nya MDM-systemet är varje land en färdig kod. I stället för att manuellt stansa in landsnamnet kommer användaren tvingas att välja land utifrån en färdig lista. Detta ger dessutom fördelen att man kan språkhantera landsbeteckningen. En dansk användare ser alternativet ”Grækenland”, och en svensk som loggar in på samma leverantör ser ”Grekland” och en britt ser ”Greece”, men alla tre är helt enkelt varianter av exakt samma registrering. Därtill får man möjligheten till att koppla till synonymer och akronymer till varje land. Alltså så varje integrerande system får exakt den landsidentifiering det behöver, t.ex. nationalitetsbeteckningen ”GR”, ISO:s kod för Grekland ”GRC” etc.
Gör ni detta med hjälp av de verktyg som finns i MDM-suiten?
Ja, just datakvalitetsreglerna skapas med hjälp av den inbyggda kvalitetsmotorn i IDMC.
Nu finns alla artiklar
tillgängliga om MDM-lösningar i
moderniseringsprojekt.
Läs mer här!
Vill du veta mer om
hur vi på Fiwe
kan hjälpa dig?
”Claire är själva AI-motorn och är knuten till merparten av modulerna som ingår i MDM-suiten från Informatica. En värdefull funktion i dataprofileringen är att allt som läggs in där är inspel till Claire. ”
Du sa att Land ofta var angivet med återkommande varianter, vilket gjorde det enkelt att automatiskt identifiera vilken landskod som skall sättas, men hur hanterar ni undantagen, felstavningar etc.? Läggs de vid sidan av för manuell bearbetning, eller har ni skapat automatiserade stöd för sådant också?
Ja, det har vi faktiskt. Det finns inbyggda stöd i systemet för att validera variationer på stavning där systemet gör en kvalificerad gissning och ger tillbaka förslag. Den här vägen skapar i viss mån manuellt arbete, men med väldigt mycket förberett. Den manuella insatsen reduceras därför till nästintill endast beslutsfattande utifrån att man serverats förberedd och tydligt underlag. Den här tekniken har vi använt i många fler fall än just för länder. E-postadress exempelvis måste ju följa ett tydligt format med tecken ”@”, följt av domän och en punkt etc. Sådant valideras med hjälp av datakvalitetsregler. Därtill tar vi hjälp av mailservrar som i många fall kan användas för att få en respons om den angivna e-postadressen faktiskt finns och om den är aktiv. Även på gatuadresser och ortnamn går det att validera korrektheten genom att ta med postnummer och med tjänster som ”Data as a Service” automatiskt säkerställa den korrekta stavningen utifrån matchningar med korrekta adresser.
Just för adressfälten så har vi även byggt in automatisk separering i tvättningsprocessen. Datamodellen har ett fält för gatunamn, ett annat fält för gatunummer, ett tredje för ev. antal trappor etc. I legacysystemen är detta ofta angiven sammansatt på en enda rad, och den separeringen slipper man nu alltså göra manuellt i och med att kvalitetsreglera är definierade på sådant sätt att outputen blir ett färdigt set av korrekt data separerad och lagrat per fält.
Har ni jobbat med Artificiell Intelligence i arbetet med datakvalitet?
Ja, i Informaticas värld heter deras verktyg ”Claire”. Claire är själva AI-motorn och är knuten till merparten av modulerna som ingår i MDM-suiten från Informatica. En värdefull funktion i dataprofileringen är att allt som läggs in där är inspel till Claire. Den här datan använder sedan Claire för att föreslå uppsättningar av kvalitetsregler som skall användas för respektive fält. Den data som matas in används av AI-motorn för att dra slutsatser om vad det faktiskt är typ av data som kommer i just det fältet. Detta underlättar också datamodelleringsarbetet som omfattar många hundratals fält. Genom att vi som modellerar redan vid första anblick med hjälp av Claire dels får input om vad fältet rimligen är för något, dessutom får en färdig uppsättning av regler att applicera, så underlättar och effektiverseras moderniseringsarbetet avsevärt.
Hur stor effekt har AI i det här arbetet?
Det beror på i hur hög grad man väljer att nyttja det, men enkelt sagt blir det som en kollega extra, eller snarare – ett helt gäng nya kollegor. Dels i samband med moderniseringsprojektet, men framför allt i den vardagliga hanteringen av MDM-data så kommer många tidsödande arbetsmoment inte behöva göras längre på grund av att Claire gör jobbet åt dig. Det är alltså fråga om tid- och resursbesparing med ökad effektivitet som resultat.
Projektet har ju pågått under ganska många månader, och ni är än så länge inte live. De första spadtagen kring datakvalitet var ju utifrån den data som fanns just då. Den datan kan ju till stor del ha förändrats idag, hur hanterar ni det?
Det har vi löst genom att hela tiden justera våra datakvalitetsregler. Vi har löpande efterfrågat uppdateringar av data och genom den kunnat validera, vidareutveckla och implementera anpassade regler baserat på den verklighet som gäller just nu.
Men blir inte det att ni får göra om samma arbete igen och igen?
Nja, på ett sätt kan man säga det, men det repetitiva görs ju i första hand automatiskt. När vi får in den nya, uppdaterade datan så körs den via vår redan genomförda dataprofiliering, och då även via de existerande kvalitetsreglerna. Det är med outputen från dessa som vi ser vilka ytterligare åtgärder och ändringar som vi behöver göra. Det är alltså egentligen inte fråga om att göra om samma arbete, utan snarare att med utgångspunkt från det vi redan gjort, få assistans med att hitta ytterligare förbättringsmöjligheter.
Det låter väldigt mycket som att ni verkligen lyckas få ut värde av kvalitetshanteringen redan innan den är färdig?
Ja precis, så är det verkligen, varje pusselbit som läggs ger potential att vara värdeskapande vid läggandet av alla senare pusselbitar.
Ett framgångsrecept alltså?
Exakt!
Artikelförfattare:
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
