Innehållsförteckning

Introduktion

Masterdata är data av referenskaraktär som nyttjas av flera olika system och/eller verksamhetsprocesser inom en organisation. Vilka data som skall klassas som masterdata styrs främst av verksamhetens behov och som regel är det de företeelser som har störst betydelse för den organisation som genererar de data som brukar klassas som masterdata. Vanliga exempel på masterdata är data om kunder, anställda, medborgare, leverantörer, avtal och produkter.

Masterdatahantering syftar till att säkerställa hög kvalité på masterdatat genom att minska risken för redundans och datainkonsistens i de system som använder masterdatat. För att åstadkomma detta är det viktigt att kartlägga verksamhetsperspektivet, dvs hur informationsmängder/objekt produceras och bearbetas i olika processer eller värdeflöden. Från verksamhetens beskrivning av hur information hanteras definieras masterdatamodeller som kan implementeras i IT-system och integrationer mellan dessa. I masterdatahantering ingår även de aktiviteter som görs för att kontinuerligt förbättra datats kvalité, exempelvis att hantera dubletter, ta bort inaktuellt data mm.

Denna vägledning riktar sig främst till arkitekter som behöver förstå hur de på bästa sätt kan bidra till en effektiv masterdatahantering och ett högkvalitativt masterdata. Följande aktiviteter är de som arkitekter i huvudsak är inblandade i:

• Analys av behov av masterdata och masterdatahantering

• Informationskartläggning genom exempelvis processanalys och informationsklassning

• Informationsmodellering för att definiera struktur och samband mellan informationsobjekt

• Skapande av datamodeller och regler för masterdata

• Beskrivning av var masterdata lagras och hur det utbyts i nuvarande och framtida lösningar

• Beskrivning av arkitektur för masterdatalösningar

Nyttor med masterdatahantering

Enligt undersökningar som http://tdwi.org har genomfört rapporterar 75% av organisationer att inkonsekventa definitioner av gemensamma termer och manuell inmatning av data är de vanligaste bidragande faktorerna för problem med datakvalitet.

Masterdatahantering skapar förutsättningar för att gemensam data blir tillgänglig, korrekt samt jämförbar för enheter och organisationer. Detta leder till följande nyttor för organisationen:

• Skapar förutsättning för automatisering eftersom data blir mer tillförlitligt

• Bidrar till tillförlitligt beslutsstöd där data från olika källor analyseras

• Ger enhetligare begreppshantering genom arbete med gemensamma datamodeller

• Möjliggör interoperabilitet och samverkan inom och mellan organisationer

• Tydliggör och effektiviserar informationshantering och dataflöden genom distribution och synkronisering av masterdata

• Bidrar till att hantera information (data) som en värdefull tillgång.

Taxonomi för data

Det finns många olika sätt att kategorisera och förklara olika typer av data. Dessa klassificeringar är viktiga för att förstå vad som är masterdata och inte, dvs vad som ska ingå i masterdatahantering och inte.

De huvudsakliga typerna av data, de som i princip finns med i alla taxonomier för data är:

• Masterdata, d v s data av referenskaraktär som nyttjas av flera system och/eller verksamhetsprocesser inom en organisation som exempelvis anställda, tjänster och leverantörer.

• Transaktionsdata, d v s data som representerar någon form av transaktion eller händelse i verksamheten som exempelvis en faktura, bokning eller beställning.

• Metadata, d v s data som definierar och beskriver annan data som exempelvis vilket format data har eller från vilken källa data härrör.

Utöver dessa förekommer i varierande grad andra typer så som:

• Ostrukturerad data, d v s data som inte har något bestämt format som exempelvis löpande text i ett e-postmeddelande eller i ett dokument.

• Hierarkisk data, d v s relationer mellan data som exempelvis delegationsordning, organisationsstruktur och produktstruktur.

• Samt en lång rad andra typer så som referensdata, mätdata och grunddata.

Här är de källor som använts för identifikationen ovan.

ISO 8000...

Ett exempel ur ISO 8000. Notera att syftet är att visa masterdatas kontext, inte att vara en komplett taxonomi för data.

Open

Region Östergötland

Exempel från material av Kimmo Ulltjärn, Region Östergötland.

Open

I materialet beskrivs kategorierna enl. nedan:

• Ostrukturerad data är information som inte har något bestämt format och som är svår att koppla till ett informationsobjekt t.ex. information i e-post, löpande text i en artikel eller liknande.

• Transaktionsdata beskriver en händelse t.ex. ett vårdbesök, en rumsbokning eller en faktura

• Masterdata är grundinformation om objekt som är viktiga för verksamheten t.ex. information om personer, organisationen, kunder och produkter (har livscykel, ändras över tid)

• Referensdata är en lista över tillåtna värden i datafält, t.ex. kodverk, landskoder och måttenheter

• Metadata är data om data t.ex. modeller

Ett visuellt exempel på hur information vid ett läkarbesök kan kategoriseras:

Ett visuellt exempel på hur produktinformation kan kategoriseras:

Förmågor för masterdatahantering

Förmågan Masterdatahantering definieras på sidan https://inera.atlassian.net/wiki/spaces/AR/pages/528679240 som följer:

Denna förmåga kan i sin tur brytas ner i flera underliggande förmågor som beskriver i mer detalj vad verksamheten behöver göra. Bilden nedan visar dessa förmågor grupperade i fyra olika områden som har valts för att skapa en struktur i vägledningen:

Arkitekturrelaterade aktiviteter per förmåga

Här beskrivs de aktiviteter som normalt sett utförs av arkitekter inom respektive förmåga för masterdatahantering.

Analys

Detta förmågeområde innehåller förmågor som handlar om att analysera masterdata vilket till stor del är en uppgift för arkitekter. För att uppnå förmågorna krävs att ett antal aktiviteter genomförs och det behövs även stödjande tekniska verktyg för att underlätta arbetet och spara resultatet. Aktiviteterna och därmed också förmågorna är tätt sammankopplade med varandra och ofta arbetar man med flera perspektiv samtidigt.

Det finns två huvudsakliga angreppssätt att identifiera vad som är masterdata inom en verksamhet. Det ena är att analysera verksamheten uppifrån och ner, dvs att utgå från strategi och identifiera vilket masterdata som behövs för det som verksamheten ska göra och det andra är att titta nerifrån och upp, dvs att analysera vad verksamheten faktiskt gör och hitta behov av data för användning i flera olika processer och tekniska system.

Behovsidentifikation

Oavsett angreppssätt så handlar behovsidentifikation om att identifiera befintliga problem och möjliga nyttor relaterat till kvalitet och tillgänglighet på data som behövs i flera processer eller verksamhetsfunktioner.

Behov kan uppstå inom organisationen, men också från aktörer utanför såsom patienter, medborgare, hotaktörer ur ett informationssäkerhetsperspektiv etc. Även lagar och regler kan driva behov av masterdatahantering.

En enkel tabell kan användas för att dokumentera resultatet av behovsanalysen:

Masterdatakartläggning

Det finns många verktyg för att kartlägga masterdata. Som ett första steg i kartläggningen är det en god ide att skapa en god förståelse för information i aktuellt område, då kan följande metoder vara lämpliga:

• Processmodellering - Att beskriva verksamhetens process på ett sätt där det framgår var information produceras och konsumeras. Se exempelvis MSBs vägledning för processbaserad informationskartläggning.

• Begrepps- och informationsmodellering - Att beskriva verksamhetens begrepp och information i syfte att förstå dess struktur och innebörd. Se ytterligare vägledning i .

• Integrationskartläggning - Att beskriva hur applikationer är integrerade och vilken information som utbyts. Detta kan med fördel mappas i en matris för god överskådlighet, då kan man på ett enkelt sätt visa vilken applikation som manipulerar vilken information på vilket vis.
  Tänk på att data kan utbytas i flera steg. Därmed kan det vara värdefullt att definiera olika typer av källor, exempelvis originalkälla där datat ursprungligen kom från och hämtningskälla där det hämtas av en viss applikation. Exempelvis kan ett katalogsystem vara hämtningskälla för t.ex. personalinformation, men originalkälla är HR-systemet. Se ytterligare vägledning i .

Då man ringat in informationsområdet kan det vara lämpligt att utforska den information som identifierats. Då kan följande frågebatteri ge vägledning i att avgöra om information bör betraktas som masterdata eller inte.

• Är det många som använder de? …tillräckligt många? Exempelvis på nationell eller koncernnivå.

• Är det förenat med stor risk eller kostnad om det blir fel?

• Är det möjligt att uppnå stora fördelar i verksamheten genom att hålla datat konsistent?

• Är de långlivade?  …statistik och uppföljning undantagen

• Är de föränderliga? …behövs hantering av livscykel?

• Är de många? …är datavolymen stor nog?

Ju fler ja-svar desto troligare att vi hittat masterdata

Det finns också tecken som pekar mot att data inte är masterdata, exempelvis:

• Datat är specifikt för en process eller aktivitet och utbyts inte mellan aktörer i verksamheten eller mellan organisationer

• Datat är specifikt för en applikation/system och delas inte med andra system

• Datat är ostrukturerat och därmed svårt att tolka på ett enhetligt sätt och kvalitetssäkra

• Datat är transaktionsdata som beskriver en händelse t.ex. ett vårdbesök, en rumsbokning eller en faktura

• Datat är metadata , dvs data om data t.ex. modeller, kvalitetsattribut etc.

Masterdatamodellering

För att kunna automatisera skapande och hantering av masterdata behöver datat beskrivas till en sådan nivå att det går att implementera i de system som hanterar masterdata. Detta görs med fördel i en Datamodell som innehåller följande:

• Dataentiteter

• Attribut för dataentiteterna med definierade datatyper

• Relationer mellan dataentiteter, inklusive kardinalitet

• Masterdataregler för dataentiteter och attribut

Entiteter, attribut och relationer beskrivs med fördel i en informations- eller datamodell. På sidan finns detaljerad vägledning för hur en datamodell kan utformas.

Det är också viktigt att utföra informationsklassificering på masterdata för att förstå om den behöver separeras från annat data och vilka säkerhetsåtgärder som är nödvändiga för att skydda datat. Viss vägledning runt detta finns i .

Masterdataregler avser vanligtvis de regler som behövs för att beskriva hur data ska tvättas, valideras, matchas och berikas. Reglerna används för att kontrollera att data möter uppsatta kriterier. Ett exempel -För att avgöra om ett postnummer är ok sätts följande kriterier upp:

• Postnumret innehåller enbart siffror, inga bokstäver eller andra tecken (krav på format)

• Postnumret måste bestå av fem tecken (krav på format)

• Postnumret måste stämma överens med den angivna orten (krav på konsistens)

• Postnumret måste existera och vara ihopkopplad med en ort (krav på precision)

I sin slutliga form är en masterdataregel typiskt en implementerad algoritm i ett system för masterdatahantering. I analysfasen av arbetet med masterdatahantering rekommenderas att dokumentera reglerna i en tabell. Tabellformen är bra då den enkelt kan byggas ut för att ta höjd för att exempelvis kategorisera regler eller att prioritera dom i relation till varandra.

Det finns ett antal olika artefakter som kan fungera som indata till analys och skapande av datamodellen. Sammanfattningsvis är det följande som är centralt att beakta:

• Det behövs en klar definition, ur ett verksamhetsperspektiv, av vad som ska behandlas som masterdata. Detta kan man med fördel uttrycka i en begreppsmodell.

• Man behöver förstå vilken information som används i verksamheten och hur denna är strukturerad, gärna i form av processmodeller och informationsmodeller.

• Kopplat till begrepp, processer och information kan det finnas verksamhetsregler (principer) som påverkar hur masterdata får skapas, uppdateras och distribueras.

• De lagar och regler som identifierats i behovskartläggningen är ofta relevanta som underlag för att definiera masterdataregler.

Datalogistik

Dataextraktion

Avser förmågan att utvinna data ur de identifierade masterdatakällorna. Förutom att identifiera det data som skall användas innebär detta att säkra en över tid stabil åtkomst till identifierad data ner på tabellnivå. Extraktionen kan göras på flera olika sätt och genom olika typer av gränssnitt beroende på omständigheter och vilken typ av verktyg som används. Från att främst ha handlat om batchning av en central masterdatabas, följd av schemalagd regelbunden deltamängdsuppdatering går utvecklingen nu allt mer mot uppdatering via API:er i realtid.

Datatransformation

Datatransformation, dvs. anpassningar och filtreringar av data görs i två olika situationer:

1. När data extraheras ur datakällan görs transformationer för att anpassa extraherat data till det format och regler som valts för masterdatanavet. Tanken är att dataformatet efter denna transformation skall vara så homogent att det enkelt skall kunna anpassas till olika kontextuella tillämpningar.

2. När data därefter skall exporteras till olika system och tillämpningar görs ytterligare en datatransformation för att anpassa informationen till den aktuella kontexten. Det bör påpekas att det är i detta steg som huvuddelen av avgränsningarna av ett dataset görs. Att avgränsa datamängden till kontextberoende krav redan i samband med extraktionen riskerar att begränsa masterdatanavets användbarhet.

Masterdataunderhåll

Bör om möjligt ske i källan och det är viktigt att de ägare av interna system som utgör masterdatakällor är införstådda med att deras system används som masterdatakälla och vilka data det är som berörs. Någon form av överenskommelse eller kontrakt bör sedan upprättas för att förtydliga vilka åtaganden som masterdatahanteringen medför.

Den del av organisationen som ansvarar för masterdatahanteringen bör förbinda sig att inte utöka användningen av redan insamlat masterdata utan att först förankra detta hos den som äger informationen.

Omvänt bör informationsägaren förbinda sig att hålla masterdataförvaltningen uppdaterad om planerade systemförändringar som kan komma att påverka masterdatahanteringen.

Det finns olika sätt att organisera detta arbete. Ett sätt som ger en heltäckande modell för denna hantering är det som kallas ”Data Stewardship”. Den beskriver roller, ansvar och eskaleringsvägar från den enskilda systemförvaltaren till arkitekter, jurister och ledning.

Masterdatadistribution

Att tillgängliggöra data för konsumerande system och tillämpningar. Detta kan innebära relativt enkla filöverföringar till ett konsumerande system där scope och  attributprofil sätts statiskt (dvs. en gång i samband med att integrationen upprättas) till mer avancerade lösningar där scopet (exempelvis användargrupper) löpande kan ändras beroende på de val en beställare gör.

I båda fallen är det viktigt att upprätta villkor samt regler för scope och attributprofil. En frågeställning som bör följa med i arbetet från start till implementation, speciellt om masterdatadistributionen innefattar personrelaterade uppgifter, är ”Vem skall få veta vad om vilka?”. 

Systemlivscykelhantering

Systemdefinition

Det finns tre huvudfrågor som behöver besvaras i och med utformningen av tekniska system för masterdatahantering:

1. Var ska masterdata skapas?

   Detta kallas även att författa eller underhålla masterdata och är i hög grad en organisatorisk och processrelaterad fråga. Skapandet kan ske av människor (exempelvis personal eller kunder) eller automatiserat (exempelvis att generera produktnummer). De tekniska alternativen här är i huvudsak att göra det i befintliga verksamhetssystem eller i en masterdataplattform och ibland en blandning av de två.

2. Var ska masterdata behandlas?

   Detta kallas även att transformera data och handlar om att jämföra data från olika källor, utvärdera och tvätta det enligt verksamhetsregler och berika med referensdata. Detta är grundläggande funktioner i en masterdataplattform, men kan i vissa fall också göras i befintliga verksamhetssystem.
   Observera att behandling av data kan ändra informationsklassificering vilket kan innebära att datat behöver skyddas på ett annat sätt då det är sammankopplat med annat data eller berikat.

3. Vart ska masterdata distribueras?

   För att masterdata ska komma till nytta i organisationen måste det finnas tillgängligt i de system som ska använda det. Här är det viktigt att bestämma vilket data som ska distribueras till vilka system eftersom alla system inte behöver, och kanske inte ens får, ha all masterdata. Ofta används en integrationsplattform för att åstadkomma distributionen.

Masterdataplattform (MDM-plattform)

En masterdataplattform, även kallad Master Data Management (MDM) plattform är ett tekniskt system som är utformat för att stödja arbetet med masterdatahantering, både för analys, datalogistik och styrning och ledning. Vanligt förekommande funktioner i en MDM-platform är:

• Datamodellering. Att kunna beskriva struktur på masterdatat.

• Regeldefinition. Att kunna definiera regler för hur masterdatat ska utformas.

• Validering. Att kunna utvärdera inkommande data gentemot datamodell och regler och sedan tvätta datat, exempelvis genom normalisering av data, valutakonvertering etc.

• Matchning. Att kunna jämföra data från olika källor hantera dubbletter, länkar till källorna och definiera “golden records”.

• Berikning. Att kunna förbättra datakvalitet med hjälp av externa källor och tjänster. Exempelvis att lägga till postort för kunder/leverantörer baserat på postnummer eller VAT-nummer baserat på organisationsnummer.

• Ändringshantering. Att kunna hantera olika versioner av data, datamodeller, regler etc., säkerställa bakåtkompabilitet och en kontrollerad ändringsprocess som kan innehålla flöden för godkännande.

Dessutom har många MDM-plattformar också funktioner för att få in och ur data ur plattformen på ett effektivt sätt. Dessa funktioner är också vanligt förekommande i integrationsplattformar vilket gör att arkitekter behöver ta beslut om var det ska göras för att uppnå högst effektivitet och hanterbarhet.

• Extraktion. Att kunna få tillgång till data från källor och transportera dessa till MDM-plattformen.

• Transformation. Att kunna justera dataformat och strukturer så att det enkelt kan hanteras i validering och matchning.

• Distribution. Att kunna exportera datamängder anpassade till olika konsumenters behov och distribuera dessa till konsumenterna.

Behövs då alltid en masterdataplattform för att kunna utföra masterdatahantering?

Svaret är nej. Om datat kan författas, behandlas och distribueras av andra system så behövs ingen masterdataplattform. Exempelvis så kan ett HR system vara det enda system där masterdata om personal skapas och behandlas för att sedan distribueras med en integrationsplattform. Utmaningarna brukar dock uppstå när flera system används för att skapa masterdata och när reglerna för behandling av datat blir komplexa. Det är då en masterdataplattform är till nytta.

Det finns fyra vedertagna mönster för implementation av masterdatalösningar vilka beskrivs kortfattat nedan.

Mönster 1: Masterdataregister (Registry)

Syftet med detta mönster är att skapa en ensad vy av masterdata i flera system utan att kräva att källsystemen (system of record) anpassas. I detta mönster skapas masterdata i källsystemen och masterdataplattformen (registret) indexerar därefter datat och skapar en samlad (virtualiserad) vy av allt masterdata som konsumenterna sedan kan dra nytta av. Masterdataplattformen samlar därmed inte själva datat utan fungerar endast som ett index ur vilket man kan skapa anpassade vyer för konsumenterna.

Fördelarna med denna metod är att den är icke-invasiv, dvs inte ställer krav på anpassning av källsystemen och lämpar sig väl för analys och rapportering. Däremot så finns det begränsade möjligheter att jämföra och behandla data som finns i olika system då masterdataplattformen inte lagrar själva datat.

Mönster 2: Konsoliderad (Consolidation)

I detta mönster konsolideras även själva datat i masterdataplattformen (MDM) vilket ger möjligheter att behandla data från flera källor på ett mer sofistikerat sätt. Datat läses in från källsystemen, utvärderas och tvättas enligt verksamhetsregler och distribueras sedan till konsumenterna. Masterdata kan därmed skapas/författas både i källsystemen och sedan underhållas i masterdataplattformen vilket ger stor flexibilitet.

Enigt detta mönster återläses inte data till källsystemen vilket gör att dom inte påverkas nämnvärt, men dom kan därmed också sakna viss data eftersom dom inte tagit del av vad masterdataplattformen har gjort.

Mönster 3: Samexistens (Coexistence)

Detta är det vanligaste mönstret och fungerar på samma sätt som i ett konsoliderat scenario med skillnaden att masterdata även läses tillbaks till källsystemen när det så behövs. Tillbakaläsningen behöver inte ske för alla system utan avgörs från fall till fall. Källssystemen drar därmed nytta av den förmåga masterdataplattformen har att behandla data, men måste i gengäld anpassas för att kunna ta emot data.

Mönster 4: Centraliserad (Centralized)

Enligt detta mönster blir masterdataplattformen det enda system där masterdata kan skapas och blir därmed "system of record". Från masterdataplattformen distribueras sedan data till alla system/konsumenter som behöver det.

Fördelen med detta är att det är tydligt var masterdata skapas och därmed enklare att styra och följa upp, men samtidigt ställer det krav på att alla system som har masterdata måste kunna ta emot denna från masterdataplattformen. Det finns också utmaningar i processperspektivet i och med att masterdata inte kan skapas i befintliga verksamhetssystem utan måste skapas i masterdataplattformen.

Sammansatt bild

Så här kan en sammansatt bild se ut av en systemarkitektur för masterdata.

Styrning och ledning

Styrning av masterdatahantering

Varje organisation bör ha en klar bild över vilka steg som bör göras för att uppnå god datakvalitet generellt. Masterdatahantering är en grundbult för att säkra att korrekt information finns tillgänglig vid rätt tillfälle. Masterdata utgörs av information som rör flera konsumenter av samma information och att korrigera vid källan är målbilden för att få bukt med risken att felaktig och motsägande data sprids i olika delar av organisationen. Görs inte detta arbete konsekvent och styrt skapas risker och onödig administration i flera led. En strategi för detta arbete bör upprättas och drivas löpande och det faller under begreppet Information Governance. Här krävs mandat och medel för att besluta om styrning mot Internationella och Nationella standarder samt uppnå ett genomförande som påverkar flera delar av organisationen. TOOP - The Once Only Principle definerat inom EU fungerar som en god målbild för styrning mot effektiva obrutna informationskedjor. Digitaliseringsmyndigheten (DIGG) definierar flera vitala grunddatadomäner som ligger till grund för implementering av masterdata lokalt.

Arbetet utgörs av flera delar såsom

• Definition och kommunikation av vision för masterdatahantering

• Definition och kommunikation av mål för masterdatahantering

• Etablering av styrsystem med roller, ansvar och befogenheter för masterdatahantering

• Säkerställa efterlevnad av styrsystem

Ledning av masterdatahantering

Som all verksamhet behöver även masterdatahantering ledas för att säkerställa att verksamheten utförs på ett effektivt sätt och i linje med den strategi och policy som styrningen definierat. För masterdatahantering gäller detta särskilt masterdatalogistik, men även analys och arkitekturarbete samt systemlivscykelhantering.

Arbetet utgörs av flera delar såsom

• Prognoisticering av behovet av masterdatahantering

• Planering av utförande av analys och masterdatalogistik samt att kommunicera förväntningar på verksamhetens processer för kvalitetssäkring av data

• Koordinering av daglig verksamhet samt förbättrings och förändringsaktiviteter

• Prioritering av stegvis införande av vilken Masterdata som skall prioriteras först och ger störst nytta för konsumerande led.

• Utveckling och beslut om organisering, dvs vilka personer och organisationer som innehar olika roller i masterdatahantering

• Leda och påverka andra att uppfylla målen med masterdatahantering

Referensmaterial

Presentation som sammanfattar vägledningen:

Open