Att arbeta med masterdata kräver ständig skuldsanering

Alla organisationer med någorlunda stor IT-miljö hamnar förr eller senare i utmaningar kring hantering av masterdata.

En klok strävan är att masterdata för en viss domän hålls samman på ett ställe – t.ex. hålla all kundinformation i ett kundvårdssystem (CRM). Detta är dock lättare sagt än gjort eftersom varje förändring kommer att driva mot en fragmentering av informationen. Anledningen till detta är nästan alltid att det saknas information i masterdatakällan och att man därför berikar den i parallella register, utanför sin naturliga hemvist.
Antag t.ex. att vi inför ett nytt system – säg ett tidsbokningssystem – där våra kunder kan gå in och boka tid för att utnyttja våra tjänster. Alla grundläggande kunduppgifter hämtas från CRM-systemet som är master för denna information. Allt frid och fröjd så långt. För att minska kostnaden för kunder som glömmer sin bokning och inte dyker upp på bokad tid vill vi skicka en påminnelse via SMS till kunden. Problemet är att vi inte har mobiltelefonnummer lagrade i CRM-systemet, så nu står vi inför två alternativ:

• Vänta med att införa SMS-påminnelse tills vi kravställt och infört mobiltelefonnummer i CRM-systemet.
• Ta fram ett lokalt register där vi berikar kundinformationen med mobiltelefonnummer.

Personligen tror jag inte på att det första alternativet i praktiken fungerar annat än i mycket enkla fall, och om man skulle följa den principen skulle snart sagt vartenda förändringsinitiativ fastna i en soppa av beroenden som skulle innebära att vår leveransförmåga skulle hämmas avsevärt. I en konkurrensutsatt värld kan vi inte vila på lagrarna, och genom att följa det andra alternativet kan vi leverera värde direkt. Det vi gör nu är att vi börjar bygga upp en teknisk skuld – och det är helt okej – men alla som har sett på lyxfällan vet att skulder måste betalas tillbaka.

På sikt riskerar vi att det poppar upp flera parallella register med kompletterande kundinformation, och vi kan ha olika delar av verksamheten som sitter med olika uppdaterade uppgifter kopplat till kunderna. Nu riskerar vi inte bara att vi är spretiga i vår kommunikation med våra kunder – våra egna processer kan degradera – t.ex. när vi skickar påminnelser till inaktuella mobilnummer fastän kunden uppdaterat sin information i ett annat av våra register.

Lösningen på detta är i mitt tycke att man måste vara aktiv och ständigt arbeta med sin tekniska skuld – inte bara på systemnivå – utan även på en övergripande nivå. Utöka masterdata-domänen och avveckla lokala kompletterande register. Betala av skulderna löpande för att inte hamna i en situation där räntekostnaden bildligt talat överstiger intäkterna. Här tycker jag också att om det finns en EA-funktion (enterprise-arkitektur) inom företaget så ska denna identifiera och driva på för att minska den tekniska skulden. Tyvärr tycker jag att man ser exempel på att man allt för ofta tillåter denna typ av teknisk skuld fortsätta ligga år efter år utan åtgärd – särskilt i stora organisationer som redan från början har komplexa IT-miljöer. I slutändan brukar det inte sällan resultera i att man drar igång ett jätteinitiativ för att införa ett nytt system som ska tillhandahålla masterdata. Dyrt men lönsamt utifrån att man arbetat upp så stora kostnader.