Charlotta Carlsson

Kvalitet i din Business Intelligence

2018-06-07 Blogg Kravhantering Läst 279 gånger

Ett BI-system (Business Intelligence, beslutsstöds-system) hämtar data från organisationens olika verksamhetssystem, strukturerar dessa i ett samlat datalager och ger beslutsfattare i en organisation möjlighet att ta ut och kombinera den information som de behöver som beslutsunderlag för vitt skilda syften. Systemarkitekturen är grovt sett: 1. Diverse källsystem -> 2. ETL (extract, transform, load, dvs. programvara som hämtar, omvandlar och laddar in data) -> 3. Ett datalager -> 4. Diverse utdataformat.

I en stor organisation blir detta snabbt komplext vilket ställer höga krav på dem som förvaltar BI-systemet att ha koll på kvaliteten. Det krävs tyvärr bara några få brister för att skada förtroendet för informationen som kommer ut ur systemet.

Den goda nyheten är att detta går att undvika! Förebygg problem med kvaliteten genom att arbeta smart med kraven. I en BI-förvaltning förekommer som regel över tid en mängd olika utvecklingsprojekt när olika delar av verksamheten önskar nya möjligheter att få ut information. Oavsett vad det är för omfattning på projekten vill jag rekommendera fyra huvudprinciper för kravarbetet:

  1. Ett nära samarbete mellan IT och verksamhet

 Det som först och främst ger god kvalitet är att de som är duktiga på att bygga BI-system träffar dem som är duktiga på sitt verksamhetsbehov. Det första du behöver göra är därför att säkerställa att personer med rätt kompetens har tid avsatt för avstämningar i projektet. Tänk på att det på verksamhetssidan kan gälla både ”dataproducerande” och ”datakonsumerande” verksamhet. Beställningen kommer nog oftast från den sistnämnda, men det är ofta nödvändigt att även få tillgång till personer som kan datakällorna.

  1. En överenskommen uppdragsbeskrivning för varje projekt

En tydlig uppdragsbeskrivning för varje utvecklingsprojekt som sätter ramar och säkerställer resurser är att rekommendera även om utvecklingen sker in house, och även om uppdraget är till synes obetydligt. Den hjälper både beställaren och leverantören att förstå sitt åtagande för att uppdraget/projektet ska lyckas. Några förslag till innehåll:

  • Syfte – en första beskrivning av målet med uppdraget.
  • Vem har behovet av information och till vad?
  • Gäller det ändringar eller nyutveckling?
  • Idé om datakällor
  • Idé om utdata
  • Bemanning från både IT och verksamhet: namn, roll och avsatt tid under viss period
  • Arbetssätt i uppdraget; avstämningsrutiner, dokumentationssätt m.m.
  • Planerad leveranstidpunkt
  • Preliminär tidsuppskattning
  • Datum och underskrift av beställare och leverantör
  1. Ett iterativt arbetssätt med avstämningar

Jag föreslår att du bygger krav- och utvecklingsarbetet kring ett antal avstämningstillfällen mellan IT och verksamhet, där kraven och lösningen växer fram parallellt. Varje avstämningstillfälle ska ha ett tydligt mål och bemannas med rätt roller/kompetens. Till avstämningarna har du med ett underlag med ett antal frågor som tar er vidare i kravarbetet.

Mellan träffarna kan utvecklare undersöka vilka möjligheter som finns i det befintliga datalagret, och presenterar kanske ett utkast till datauttag och -presentation vid nästa träff. Verksamhetspersonerna kan ta med sig olika frågeställningar att undersöka på hemmaplan till nästa gång. Hur många avstämningar som behövs beror förstås på hur stort, och hur nyskapande, utvecklingsuppdraget är.

Bygg kravdokumentationen efter hand, från övergripande behovsbeskrivning ner på regelnivå för datauttag och -presentation. Troligen kan man behöva hoppa mellan dessa nivåer under resans gång, varför det är bra att en och samma roll har helhetsansvaret för dokumentationen. Vill ni dela upp det, tänk ändå på att dokumentationen ska hänga ihop och, inte minst, vara aktuell. Den som är kravansvarig, oavsett om hen kommer från verksamhets- eller IT-sidan, kan med fördel hålla i den röda tråden genom att facilitera avstämningarna och dokumentera kraven.

  1. Samla ett frågebatteri

Med tiden samlar ni på er ett helt standard-frågebatteri, utifrån just er BI-lösning, som kan återanvändas i kommande uppdrag. Frågor behöver ställas inom olika områden:

  • Bakgrundsfrågor till intressenter
  • Användningsfrågor till användarrepresentanter
  • Lösningsidéer från användarrepresentanter
  • Informationsrelaterat
  • Utdata-relaterat
  • Källsystem-relaterat
  • Datalager-relaterat
  • Hur påverkas befintliga system?

För att illustrera hur jag menar kommer här några exempel på informationsrelaterade kravfrågor.

  • Hur aktuell information krävs?
  • Hur ofta behöver informationen uppdateras?
  • Ska informationen presenteras granulärt eller aggregerat?
  • Ska numerisk information avrundas?
  • Ska informationen hämtas även om det finns luckor (t.ex. bruten tidsserie) i källdata?
  • Ska informationen hämtas även om det finns andra kvalitetsbrister i källdata?
  • Finns känsligt persondata i önskat urval? Vad gäller kring spridning/avidentifiering av dessa?
  • Ska urval göras på:
    • Status? (t.ex.: alla poster/bara godkända poster/bara nya poster/bara arkiverade poster)
    • Tidsintervall? (t.ex.: hur långt bakåt i tiden? Hur långt framåt? Är det en ögonblicksbild?)
    • Omfattning verksamheter? (alla verksamheter/endast vissa verksamheter – vilka?)
    • Kombinationer av datakällor? (t.ex. bara den information från källa x som kan kombineras med källa y? alternativt all information från källa x oavsett om den kan kombineras med källa y?)
    • Andra specifika villkor: (t.ex. ProduktId <> ’ABC’)

Sammanfattningsvis vill jag rekommendera dessa huvudprinciper för kravarbetet i förvaltning av BI-system:

  1. Ett nära samarbete mellan IT och verksamhet
  2. En överenskommen uppdragsbeskrivning för varje projekt
  3. Ett iterativt arbetssätt med avstämningar
  4. Samla ett frågebatteri
Dela artikeln