Det er veldig interessant å få jobbe med ulike systemleverandører med hvordan de best kan tilgjengeliggjøre innsikt og data fra sine system.
For systemleverandørene vil deres evne til å gi effektiv tilgang til "sine" data være et helt åpenbart konkurranseområde fremover.
Jeg tror eksempelvis allerede de aller fleste ERP-leverandørene har fått spørsmålet "kan vi koble oss på rådataene fra Power BI?" i en hver salgsprosess en stund.

En problemstilling som da fort kommer opp er alle nyfrelste Power BI-entusiaster som er klar for å erobre innsiktsverden.
"Bare gi meg tilgang til rådataene, så fikser jeg resten i Power BI".
Ja, Power BI kan for så vidt trylle, men å håndtere rådatamodellene til de fleste ERP-løsninger krever likevel veldig mye av brukeren. Det samme gjelder også for mindre komplekse løsninger.
Det fører ofte til at Power BI-entusiastene går fort fra å være veldig optimistisk og ovenpå, til at videre arbeid går trått.
Strukturen og funksjonaliteten i systemenes rådatamodeller ble ikke designet for å være spesialtilpasset analyse, men for å kunne bygge velfungerende og komplekse driftssystemer.
Mange gir allerede i dag tilgang til data på en god måte ved å eksempelvis tilgjengeliggjøre APIer eller opprette replika-databaser i Azure hvor man kan koble seg på. En del har også utviklet egne adaptere eller "connectors" man kan bruke.
Men skal den gjennomsnittlige Power BI-bruker klare å bruke dataene uten å kreve for mye oppfølging, så er det mye som må være på plass:
Følgende er noen eksempler på informasjon en "Self-Service BI-bruker" ofte vil behøve for å lage analyser og rapporter:
- Dokumentasjon av hvordan en henter data og autentiserer seg
- Hvordan strukturen på tilgjengelig datamodell er satt opp. Finner man all nødvendig informasjon i kundetabellen, eller må man linke sammen flere ulike tabeller?
- Dokumentasjon på hva de ulike kolonne-titlene betyr. Mange rådatabaser er basert på forkortelser som ikke gir mening før blir oversatt. Også da kan det være vanskelig å være sikker. Hva menes egentlig med "valideringsdato", "bokføringsdato" eller "periodiseringsdato" i hovedbokstabellen?
- Andre "ulogiske" steg man må gjøre for ulike analyser. Ofte er det transaksjoner med visse statuser som bør/må filtreres bort, eller andre kjente problemstillinger i datasettet som man kjenner til forkludrer analyser.

Jeg er ikke i tvil om at veksten i "Self Service BI" vil fortsette når en ser verdien slike løsninger tilfører virksomheter.
Men hvilke aktører klarer å utnytte det til sin fordel?
"Unge" løsninger som er født i skyen og selv bygget basert på egne APIer har en åpenbar fordel kontra mer "tungrodde" løsninger når det kommer til fleksibilitet.
Men samtidig har mange tradisjonelle systemleverandører også kommet et godt stykke i arbeidet med å tilgjengeliggjøre dataene for analyseformål. Disse har gjerne også en fordel knyttet til at mer detaljerte data legger til rette for dypere analyse og innsikt over tid.
For oss som er opptatt av denne delen av forretningsverden, så blir det svært spennende å følge utviklingen fremover.
Foreløpig har jeg inntrykk av at mange ikke har tatt det helt på alvor og tenker at hele trykket rundt "Self Service BI-løsninger" er litt overdrevet, men at det virkelig er i ferd med å snu.