Design BI-rapporter der reelt hjælper dine kolleger
Denne guide handler om få mennesker, forretning og teknik til at gå op i en højere enhed. For Power BI skaber kun værdi, hvis det hjælper dine kolleger i deres arbejdsprocesser, skaber indsigt og forandring.
- Forstå forretningens mål
- Vælg den rette teknologi
- Lær at formidle data
- Lær psykologien
- Følg design-opskriften
Læs guiden til at designe BI-rapporter, som mennesker har lyst til at bruge, og som hjælper dem med at træffe kloge beslutninger.
56 sider for dig, der vil sikre at BI-rapporterne bliver brugt og skaber værdi i dagligdagen.
E‑bog
PDF
Trykt
Lyd
Abakion er eksperter i Microsofts forretningsløsninger til ERP, CRM og BI til danske virksomheder. Vi leverer både enkle løsninger, der er klar til brug hos mindre virksomheder – og skræddersyede løsninger til større virksomheder.
Ring til os på 70 23 23 16
eller skriv til abakion@abakion.com
Vi giver gerne et godt råd, uanset om du vil handle hos os eller en anden Microsoft-partner.
Din rolle som BI-ansvarlig
Der er ledermøde i dag, og som ansvarlig for Business Intelligence i din virksomhed, så glæder du dig til at se, hvordan al den gode viden fra din BI-løsning bliver anvendt i praksis.
Men allerede ved første punkt på dagsordenen mærker du, at noget er galt. Salgschefen taler begejstret om, at “salget kører som smurt”, mens du sidder med de nye salgstal, der viser et fald på 5%.
Du er nødt til at bide dig selv i læben, da marketingchefen ruller sin egen Excel-rapport ud.
Tallene ligner ikke dem, du kan se i din BI-løsning. De ligner heller ikke salgschefens tal, og diskussionen udvikler sig hurtigt til en ordkrig om, hvilke tal der er ”mest rigtige”.
Produktionschefen argumenterer for nye investeringer baseret på mavefornemmelser, og økonomichefen trækker en PDF-rapport frem, som hun fik tilsendt for tre uger siden.
Du begynder at svede og overvejer, om du kan tillade dig at skælde dem alle sammen ud.
Så indrømmer HR-chefen, at han aldrig rigtig har logget ind i BI-portalen.
Det er dråben. Nu kan du ikke tie stille længere.
Du tager ordet og forklarer, at de kan finde alle tallene inde i BI-portalen. Der er ingen grund til at bruge tid på at diskutere, hvilke tal der er de rigtige tal.
I dit hoved fortsætter du forurettet med en svada om, at det har taget lang tid at bygge BI-rapporterne, og at det er latterligt, at de ikke bruger den viden, der er tilgængelig. Det er som at installere en elevator, og så begynde at gå baglæns op ad trapperne med bind for øjnene.
Men du siger det ikke højt. Der er blevet stille i lokalet.
Salgschefen bryder stilheden med en indrømmelse af, at han synes det er lidt svært at finde rundt i alle tallene.
Marketingchefen synes, at det føles som at prøve at vælge en film på netflix, og til sidst mister børnene tålmodigheden og sætter noget med en youtuber på.
HR-chefen smiler undskyldende: “Jeg troede egentlig, det bare var et ekstra værktøj for jer talnørder.”
Sandheden begynder at gå op for dig. Det er ikke kollegerne, der er problemet.
Det er dine BI-rapporter. De er for svære at bruge. Der er for mange tal at overskue.
Du har ikke gjort dit arbejde godt nok.
Du er tilbage på dit kontor, og du kan mærke krisen. Og en masse irritation over, at dine kolleger ikke bare bruger BI-løsningen, som de skal.
Du er BI-ansvarlig. Tænk lige over, hvad det egentlig betyder. Ansvarlig for Business Intelligence.
Business er forretningen, og intelligence er noget med viden, så formålet med dit job må være at formidle relevant viden om forretningen til dine kolleger, så det giver en forretningsmæssig gevinst.
Business Intelligence handler om at anvende IT til at hjælpe kollegerne med at opnå indsigt, så de kan træffe kloge beslutninger i virksomheden.
Så du er faktisk først en succes i din rolle, når den indsigt, du har skabt grundlaget for, bliver anvendt i praksis af dine kolleger.
Det er ikke nok at klargøre de data, kollegerne har bedt om. Du skal også tage ansvaret for, at data bliver omsat til brugbar viden og fører til konkrete beslutninger, der forbedrer forretningens resultater.
Det fulde omfang af din rolle begynder at tage form.
Hvad er din rolle?
Hvorfor er der overhovedet brug for en guide som denne? Det er der, fordi rollen som BI-ansvarlig spænder så bredt, at det er de færreste, der formår at dække det hele. Og det vil vi gerne gøre en indsats for at ændre på.
For problemet er tydeligt i mange statistikker:
Undersøgelser viser, at anvendelsesgraden af BI-løsninger generelt er 25-35%. Det betyder, at cirka 70% af de brugere, som kunne (eller burde) bruge BI, gør det ikke.
Det er en enorm spildprocent. Det er virkelig ærgerligt. Og hovedårsagen er, at BI-rapporterne ikke bliver designet til de mennesker, der skal bruge dem.
I mange virksomheder kommer Business Intelligence til at handle for meget om teknik. Man kommer til at fokusere for meget på, hvordan man trækker data ud af datakilderne og bygger en datamodel, og for lidt på hvordan data skal formidles til brugerne.
Så hører man indvendinger som:
”Det er lidt svært at finde rundt i alle de tal”
”Jeg vil gerne bare vide, om det går bedre eller dårligere end sidste måned”
”Jeg kan ikke huske, hvilke tal jeg lagde sammen sidst”
Mennesker er en forhindring for at opnå succes med Business Intelligence. Vi lærer og forstår på en bestemt måde, og hvis du som BI-ansvarlig ikke følger de spilleregler, så kommer kollegerne ikke til at bruge BI-løsningen. Ikke fordi de ikke vil, men fordi de blot er mennesker.
En teknisk velfungerende løsning er ikke nok i sig selv. Der skal også fokus på de mennesker, der skal bruge BI-løsningen.
Som BI-ansvarlig skal du favne meget bredt:
- Teknik
Det handler om at overføre data fra kildesystemer til et data warehouse og sørge for, at systemer og integrationer er operationelle. - Forretning
Det handler om at forstå virksomhedens drift, mål og data, og sørge for datamodellen kan skabe den relevante indsigt. - Formidling
Det handler om at forholde sig til brugernes adfærd, dvs. at sørge for, at layout og design af BI-rapporterne fungerer for brugerne, så data bliver brugt i praksis til at skabe viden.
Det er ret forskelligt fra virksomhed til virksomhed, om den BI-ansvarlige har alle ansvarsområderne, eller om det er opdelt på flere personer. Det er svært at favne det hele, men det kan også være svært at opdele ansvaret mellem flere personer.
Hvis du arbejder fuld tid med Business Intelligence, så har du en god mulighed for at få det hele til at gå op i en højere enhed, men hvis BI er en ekstra kasket, som du har oven i dit job i finans-, salg- eller IT-afdelingen, så skal du gøre en indsats for, at BI ikke kommer til at handle for meget om teknik. Det er nemlig det, der ofte sker. Desværre.
Men nu har vi en køreplan for, hvad der skal til for at få succes med BI:
Og selv om det virker oplagt at tegne oversigten på denne måde, fordi det praktisk skal udføres fra venstre til højre, så skal du ikke begynde planlægningen i venstre side af tegningen og arbejde dig mod højre. Det er en fejl at begynde med data. Du skal begynde med forretningen.
Business Intelligence fejler ind i mellem på grund af teknikken, men langt oftere er det fordi den enten ikke opfylder forretningens mål, eller ikke er designet til de mennesker, der skal bruge den.
Eksistensberettigelsen for BI er at understøtte beslutninger og gøre arbejdet med at opnå viden lettere for brugerne.
Og derfor kommer der nu 3 afsnit, som er praktiske guides til, hvordan du skal:
- Opnå forretningsforståelse, så målet for BI-projektet er klart
- Formidle data, så brugerne opnår den ønskede indsigt
- Konfigurere teknikken, så data replikeres fra kildesystemerne.
Vi kommer til at fokusere på Microsoft-løsninger som Power BI, Fabric og Business Central, når vi kommer til teknik-afsnittet. Det har vi rigtig gode løsninger til. Men du kan sagtens læse de første to afsnit af denne guide med andre systemer i tankerne.
DEL 1: FORRETNING
Vi åbner festen med at skabe enighed om, hvad formålet med BI-rapporten (eller hele BI-projektet) konkret er.
Hvis du er ligesom alle andre mennesker, så har du en masse antagelser om, at ”jeg kender godt målene i vores virksomhed”, og ”jeg ved godt hvad de har brug for i økonomiafdelingen”.
De antagelser kommer til at hæmme dig senere i processen, så begynd med at smide dem alle overbords.
Du har måske overordnet kendskab, og du har indsigt i brudstykker af deres arbejdsprocesser, og det er et glimrende udgangspunkt, men du ved ikke, hvad dine brugere konkret har behov for. Det ved de knap nok selv.
Det er vigtigt, at du bruger energi på at afklare dine brugeres behov, så I har et fælles mål.
Lær brugeren at kende
En af de mest afgørende, og ofte oversete, discipliner inden for Business Intelligence er at forstå brugeren.
Som BI-ansvarlig kan du ikke forudsige de behov, brugerne har. Du er nødt til at være i dialog med dem.
Din bruger søger hjælp i en BI-rapport, fordi vedkommende skal løse et konkret problem eller mangler viden til at træffe en konkret beslutning. Det behov skal du kende.
Du skal forstå deres situation, deres arbejdsprocesser, og hvilke beslutninger de skal træffe, og hvordan de træffer dem. Og på toppen af al den indsigt kan du bagefter bygge et dataprodukt.
Du kan ikke blot spørge, hvilke data og rapporter, de har behov for.
Problemet er, at når du stiller spørgsmålet på den måde, så tvinger du dem til at tænke i data frem for forretning.
Brugerne begynder at spekulere på, hvilke data du som BI-ansvarlig har til rådighed, og ofte gætter de forkert eller undlader helt at svare af frygt for at bede om noget, der ikke er muligt.
Du må aldrig forsøge at tvinge dine brugeres behov ned i data som det første.
Det kræver faktisk en vis analytisk sans at oversætte et forretningsproblem til en konkret BI-løsning. Og mange brugere ved simpelthen ikke, hvilke nøgletal der er mest relevante for at forbedre deres processer, og det er okay, for det er heller ikke deres job at vide det.
Det er dit job. Og ved du hvad? Dit eget job bliver også mere interessant, når du forstår, hvordan dit produkt skal bruges.
Så nu begynder vi processen helt simpelt med at lære en enkelt bruger at kende, og når du har styr på rapporteringsbehovet for hver enkelt bruger, så lægger vi bagefter en plan for BI i hele virksomheden.
Så her kommer en lille tre-trins-raket, du kan følge, når du møder en bruger:
1. Forstå din brugers rolle
Når du skal producere en BI-rapport til en konkret brugers behov, så skal du begynde med at spørge dig selv: Hvem skal bruge denne rapport? Hvad er vedkommendes rolle?
Er det en sælger, en leder eller en finansmedarbejder? Hver type bruger har forskellige behov, forskellige arbejdsprocesser og forskellig teknisk forståelse. Det er vigtigt at tage højde for det hele, når du designer en BI-rapport.
Den bedste måde til at få indsigt i dine brugere, det er at tale med dem. Det er ganske simpelt. Spørg dem, hvordan de arbejder, hvad deres største udfordringer er, og hvilke informationer de har brug for i deres daglige beslutninger.
Det lyder banalt, men den indsigt er nøglen til et godt rapportdesign.
2. Hvilke beslutninger skal brugerne træffe?
En BI-rapport skaber kun værdi, hvis den understøtter konkrete beslutninger. En salgsrapport er ikke værdifuld i sig selv. Det, der giver den værdi, er de erkendelser og handlinger, den hjælper med at skabe.
Hvad skal brugerne anvende rapporten til? Kigger ledelsen i omsætningsrapporten for at beregne bonus til sælgerne? Eller for at følge op på, om nogle kunder har brug for ekstra opmærksomhed? Eller for at justere næste måneds marketingindsats?
Hvis du ikke har indsigt i, hvordan brugerne skal anvende BI-rapporten til at træffe beslutninger, så risikerer du at præsentere data, der enten kræver for meget mental energi at anvende, eller simpelthen ikke er relevant for beslutningstagningen.
3. Hvilke data er nødvendige?
Først når du har lært at forstå brugerne og deres beslutningsprocesser, så kan du vurdere, hvilke data der er relevante.
Det kan være svært at interviewe brugere om deres databehov. Det er ikke så nemt at få et brugbart svar, som man skulle tro.
Brugerne kender forretningen, men de ved ikke, hvad der er muligt at udtrække af data. Omvendt, som BI-ansvarlig kender du data, men du har ikke indsigt i de forretningskritiske spørgsmål, der kræver svar.
Som BI-ansvarlig forventer du måske, at brugerne selv kan definere præcis, hvilke data og rapporter de har brug for.
Den antagelse virker logisk, for de kender trods alt deres egen forretning bedst. Men i praksis fungerer det sjældent sådan.
De KPI’er, der reelt skaber værdi, er ikke altid dem, brugerne beder om.
Din rolle er at stille de kritiske spørgsmål, der afdækker alle nuancer. Du må ikke tage det første svar fra brugerne for pålydende.
Mange brugere tror, at de har brug for adgang til masser af data. Men det er sjældent godt at inkludere mest muligt data. Som BI-ansvarlig skal du hjælpe med at kortlægge, hvad der i realiteten er vigtigt.
Det kan fx være, at salgsrapporten ikke skal vise månedens konkrete salgstal, men blot udviklingen i procent med en pil eller farvekode for at signalere, om det går godt eller skidt.
En god BI-rapport formidler de rette indsigter på den mest intuitive måde. Det går vi i dybden med i del 2. Men lige nu skal du blot skabe overblik over, hvilken information brugerne har på ønskesedlen.
Det var tre-trins-raketten. Den skal du sørge for at bruge hver gang, du taler med en slutbruger:
- Forstå rollen og konteksten: Spørg brugerne, hvad de arbejder med til daglig, og hvilke udfordringer de møder i deres arbejde.
- Identificér beslutningerne: Spørg hvilke beslutninger brugerne skal træffe, og hvad der afgør, om en dag eller en måned er en succes.
- Find data til forretningsbehovet: Når du forstår brugernes arbejde og beslutninger, så kan du foreslå data, der opfylder deres behov.
Det må aldrig være den anden vej rundt, hvor du tager udgangspunkt i eksisterende data og leder efter et forretningsbehov, der passer til det.
Hvis du ikke starter med forretningsbehovet, risikerer du at bygge rapporter, der ikke bliver brugt, fordi de ikke adresserer reelle problemer.
Kortlæg behovene
Nu har du lært én bruger at kende via tre-trins-raketten, og den metode kan du vælge at bruge mange gange i træk, så du arbejder dig igennem alle medarbejderne, og så ender du med at have styr på hele virksomhedens rapporteringsbehov.
Det øger naturligvis kompleksiteten, og så får du brug for en overordnet plan for hele virksomhedens implementering af Business Intelligence.
Og den plan lægger vi nu.
Implementering af Business Intelligence i virksomheden kan både være en simpel eller en omfattende opgave, afhængigt af ambitionsniveauet.
Nogle gange er det ikke særlig omfattende at opfylde organisationens behov. En simpel rapport eller oversigt med ERP-data kan skabe rigtig stor værdi. Andre gange er ambitionsniveauet større. Og der kan være mange datakilder, og det øger også kompleksiteten.
Du skal skabe overblik over, hvilke medarbejdergrupper, der skal have hvad, og i hvilken rækkefølge. Det kalder man en projektportefølje.
Vi vil anbefale, at du skaber overblik over din virksomheds rapporteringsbehov, før du bygger den første BI-rapport.
Du skal kende målgrupperne for rapportering i virksomheden, og du skal vide hvilke forretningsprocesser, du ønsker at rapportere på.
Projektportefølje
Tegn et skema, hvor du i den ene dimension har alle de målgrupper i virksomheden, som har et rapporteringsbehov. Det kan være bestyrelsen, direktionen, økonomiafdelingen, controllere, indkøbere, produktionsledere, salgsledere, mellemledere, medarbejdere osv.
I den anden dimension har du de procesområder, som data kan stamme fra.
Det kunne være økonomi, salg, produktion, lager, tidsregistrering, ressource-styring, distribution, HR, projektstyring, booking, point-of-sale osv.
Så interviewer du hver målgruppe om deres rapporteringsbehov og noterer, hvilke procesområder og datakilder der skal i spil for at understøtte deres behov.
Husk at anvende tre-trins-raketten, når du kortlægger behovene.
Nu har du et samlet overblik. Når du nu prioriterer hver celle i dette skema, så bliver det til en projektportefølje. Så kan du lægge en plan for, hvilke tiltag du vil begynde med, så du kan prioritere de vigtigste behov først.
Du kan sagtens begynde med en nålestiks-operation, der giver hurtig gevinst, men med overblik over hele porteføljen sørger du for, at alt passer ind i den samlede plan.
Projektplanlægning
Det er fint at planlægge dit Business Intelligence-projekt som en delmængde af dit ERP-projekt, hvis det er ERP-projektet, der fylder mest hos dig.
Men nogle gange udskyder man at kigge på Business Intelligence, indtil ERP-projektet er helt overstået, og det er ærgerligt, for det kan gøre det sværere at etablere det Business Intelligence, som du gerne vil have.
Det skyldes, at rapportering sagtens kan stille krav til registreringspraksis i ERP, og derfor er det bedst at have overblik over rapporteringsbehov fra begyndelsen af ERP-projektet. Begynd med scoping, strategi og projektportefølje for Business Intelligence, også selv om du gemmer Business Intelligence-projektet til sidst.
Planlægning af delprojekter
Nogle rapporteringsbehov giver god mening at samle i ét delprojekt, når det fx handler om samme emneområde i samme datakilde.
Det kunne fx være debitoropfølgning, hvor medarbejdere i økonomifunktionen har behov for detaljerede værktøjer, mens CFO og ledelsen har behov for tendens-tal i et dashboard, og bestyrelsen måske blot har behov for et enkelt nøgletal i en større bestyrelsesrapport.
Det er samme emne og samme datakilde, men forskellige målgrupper har forskellige forretningsprocesser og dermed forskellige rapporteringsbehov. Men det er den samme datamodel og langt hen ad vejen de samme beregninger, der kan bruges til rapportering om debitoropfølgning til alle 3 målgrupper på én gang.
Det er også et godt eksempel på, at det er mest effektivt at have overblik over alle rapporteringsbehov fra begyndelsen. Ellers risikerer du at skulle besøge eksempelvis debitoropfølgning flere gange, når du finder ud af, at ledelsen og bestyrelsen også har behov for nøgletal.
Og det gælder på rigtig mange områder.
Salgsledelsen vil gerne have rapportering på vægtet pipeline, og bagefter opdager du, at økonomiafdelingen også gerne vil have salgsforecasts på aggregeret niveau med i deres rapporter, og bagefter opdager du, at indkøberne også gerne vil have prognoser på vareniveau. Det er nemmere, hvis man har overblik fra begyndelsen.
Små iterationer
Når du skal indføre en rapportpakke for et bestemt rapporteringsbehov til en bestemt målgruppe, så vil vi anbefale, at du planlægger en række små iterationer.
Det kan være svært at gennemtænke alle behov på forhånd, hvis man ikke tidligere har brugt Business Intelligence. Det kan være svært at gennemskue, hvad man reelt har behov for, når værktøjet rammer dagligdagens virkelighed.
Hvis du er i gang med et omfattende ERP-projekt, og du ikke har ressourcerne (eller overskuddet) til også at tænke på Business Intelligence, så er det som sagt ærgerligt, hvis du ender med helt at udsætte Business Intelligence til efter ERP-projektet.
Men vi har også fuld forståelse for, at der ikke er ressourcer til at indføre både ERP og BI på samme tid. Og som alternativ vil vi foreslå, at du tidligt i processen kan tage en standardpakke på Business Intelligence i anvendelse, for så er du i gang, og så gør du dig en masse erfaringer, og så kan du senere i rejsen blive meget skarpere på, hvad du har behov for af rapportering.
Det kan også være, at du finder ud af, at dine forretningsprocesser er mindre unikke, end du troede, og at standardpakken bringer dig rigtigt langt.
Vi anbefaler klart, at du begynder simpelt, så du kan komme hurtigere i gang med at indsamle erfaring.
Det var del 1 om at forstå de forretningsmæssige behov. Du har lært at interviewe brugere med tre-trins-raketten og at planlægge en projektportefølje for hele virksomhedens brug af Business Intelligence.
Med denne viden i banken kan vi nu designe BI-rapporter, som understøtter de forretningsmæssige mål, og som brugerne også har lyst til at bruge. Det handler del 2 om.
DEL 2: FORMIDLING
Hvis man er opdraget med data, så ønsker man at have så meget data til rådighed i datamodellen som overhovedet mulig, for så ligger alle muligheder åbne.
Men hvis man er opdraget med formidling, så ønsker man at kommunikere præcis det, som modtageren skal forstå, og udelukkende det. Unødvendige informationer modarbejder budskabet.
Og som BI-ansvarlig skal du rumme disse to modstridende kræfter.
I den første del har du kortlagt det forretningsmæssige mål, og nu skal du forholde dig til BI-brugerne som mennesker og sørge for, at BI-rapporten formidler den rette viden til dem.
Præcis den rette viden.
Og udelukkende den rette viden.
Derfor kommer dette afsnit i høj grad til at handle om, hvordan du undgår de fodfejl, som hæmmer den gode formidling.
- Det dur ikke, hvis du leverer lange datalister i en situation, hvor de har behov for et hurtigt overblik,
… selv om de selv har bedt om alle de data. - Det dur ikke, hvis brugerne har svært ved at finde den rette information og giver op undervejs,
… selv om du har undervist dem i hele BI-portalen. - Det dur ikke, hvis brugerne er nødt til at kopiere data over i Excel for at udregne de nøgletal, de vil se,
… selv om du aldrig har hørt om det behov før. - Det dur ikke, hvis brugerne ikke orker at åbne BI-rapporterne, fordi de synes, at de er svære at bruge,
… uanset om du kan bevise, at de reelt er nemme.
Vi begynder med en vigtig erkendelse: Dine brugere er ikke ansat til at betjene BI-rapporter.
De er bogholdere, sælgere, controllere, produktionsplanlæggere osv. Så de skal ikke bruge tid på at afkode kringlede BI-rapporter.
Så alt hvad du har af argumenter om, at ”de bør kunne gennemskue …” eller ”de må kunne leve med lidt kompleksitet” … alle de argumenter begynder vi med at skrotte.
Din opgave er at gøre brugernes arbejde nemmere. Ikke at tilføje kompleksitet.
Business Intelligence skal smelte naturligt ind i deres daglige arbejde, så de kan bruge deres tid på at træffe beslutninger, og ikke på at lede efter data.
Velkommen til en verden af psykologi og adfærdsmønstre.
Nu skal du først lære at forstå mennesker. De er nogle gange ret irrationelle, men det må du lære at acceptere.
Og så skal vi bagefter dykke ned i konkrete værktøjer til at designe rapporter, som tager højde for brugernes psykologi, så dine BI-rapporter bliver anvendt i praksis og skaber værdi.
Men først skal vi en tur ind i menneskenes dovne hjerne.
LÆR AT FORSTÅ MENNESKER
Vi skal tilbage til ledermødet. PowerPointen viser en kurve, der går nedad. Det er ikke godt.
Salgschefen byder straks ind med, at udviklingen ligner den for et halvt år siden, hvor markedet var i en afmatning. Det er sikkert tilfældet igen.
Økonomichefen siger, at det kan løses effektivt ved at skrue ned for de igangværende udviklingsprojekter, for de er dyre.
Marketingchefen foreslår en prisnedsættelse for at sætte gang i markedet igen.
Det er bare i løbet af de første par minutter. Og der er ikke nogen af dem, der har tænkt sig om mere end 3 sekunder.
Menneskers hjerner er dovne og elsker at træffe intuitive beslutninger, for så er det hurtigt overstået.
Du sidder sikkert og tænker, at cheferne burde analysere en masse af BI-rapporterne, før de byder ind med en løsning, og det gør de forhåbentlig også, før de træffer en beslutning.
Men deres hjerner kan slet ikke lade være med at have en holdning klar på et øjeblik, som er baseret på erfaring og instinkt. Og det er et faktum, som du er nødt til at forholde dig til som BI-ansvarlig, hvis du vil hjælpe dem bedst muligt.
Når du kommer tilbage til dit kontor og skal designe BI-rapporter, som kan hjælpe de stakkels ledere med at træffe de rette beslutninger, så kan du vælge to veje:
- Du kan prøve at opdrage dem til at tænke analytisk, før de byder ind med en løsning. Det er den besværlige vej til målet.
- Eller du kan give dem brugbar indsigt i et intuitivt format, som er skræddersyet til deres dovne hjerner. Det er den nemme vej til målet.
Ja, det er en lidt karikeret historie, men forhåbentlig giver pointen mening.
Det første møde med BI er nødt til at være letfordøjeligt, og derfor skal vi nu gennemgå, hvordan mennesker tænker og træffer beslutninger.
Psykologisk forskning peger på en væsentlig skelnen mellem to tænkesystemer, kendt som System-1 og System-2, som Daniel Kahneman gjorde bredt kendt i ”Thinking, Fast and Slow”.
De fleste kender det fra sig selv som at ”tænke hurtigt” eller at ”overveje langsomt”.
- System-1: Hurtigt, intuitivt og automatisk.
Det er baseret på erfaringer og mønstergenkendelse.
- System-2: Langsomt, analytisk og velovervejet.
Det kræver en bevidst indsats. Det bruges til komplekse overvejelser og kræver mere mental energi.
Og hvorfor skal du vide, hvordan menneskers hjerner fungerer, når de modtager information? Det skal du fordi …
Når BI-rapporter fejler, er det ofte fordi de udelukkende er designet til System-2.
Det er en fælde, som er nem at falde i. Mange BI-ansvarlige forstår intuitivt deres egne komplekse tabeller og detaljerede dashboards, fordi de selv har designet dem.
Men for slutbrugeren, der ikke har samme træning og erfaring, kan de samme rapporter være en kognitiv byrde.
Den fælde er alle faldet i mange gange. Lange tabeller med tal, ingen farver, ingen fremhævninger eller visuelle indikatorer.
Brugeren bliver tvunget til at bruge System-2, og det kræver koncentration og mental energi. Det skaber friktion, og det mindsker sandsynligheden for, at rapporten bliver brugt effektivt, eller brugt i det hele taget.
Den menneskelige hjerne er doven. Den er meget økonomisk indstillet, og den vil helst undgå at aktivere System-2, for det koster for meget energi.
Hvis din BI-rapport ikke giver nogle godbidder til System-1, så er der en risiko for, at brugerens hjerne ikke orker at afkode den.
Nogle af de gode råd til at designe til System-1 er:
- Brug farver og trafiklys til at vise, om noget er godt eller skidt
- Præsentér de vigtigste tal tydeligt og let tilgængeligt
- Brug visuelle elementer som grafer og ikoner, der gør det nemt at afkode information
Det betyder ikke, at System-2 ikke skal have sin plads. Men det skal være en mulighed, ikke en forudsætning.
Brugere, der ønsker at dykke dybere ned i data, skal kunne gøre det, men den første oplevelse bør være så friktionsfri og intuitiv som muligt.
BI skal gøre det lettere at træffe beslutninger, ikke sværere. Når du forstår, hvordan mennesker tænker og behandler information, så kan du skabe rapporter, der rent faktisk bliver brugt.
Farver og kontekst forbedrer forståelsen
Forestil dig, at du åbner en BI-rapport om månedens omsætning, og du ser tallet 57. Umiddelbart siger det dig ikke meget. Er det et godt eller dårligt resultat? Er det bedre eller dårligere end sidste måned? Skal du reagere på det?
Hvis du selv skal dykke ned i tidligere data, sammenligne med sidste år, og måske endda foretage nogle manuelle beregninger for at forstå betydningen af 57, så er rapporten ikke designet optimalt. Den kræver, at du aktiverer System-2 og bruger unødig mental energi på at afkode, hvad du skal gøre.
Det er en klassisk tilgang at præsentere to kolonner: én med salgstal for den aktuelle måned og én med salgstal fra samme måned sidste år. I teorien giver det god mening. Brugeren kan se udviklingen over tid.
Men spørg dig selv: Hvad ønsker du egentlig at vise?
eller
Hvis det er udviklingen siden sidst, der er vigtig, så fremhæv den, i stedet for at fremhæve mellemregningen. Hvis de detaljerede omsætningstal ikke er det vigtigste at forstå ved første øjekast, så gem dem til senere. Brugeren er ikke interesseret i at skulle hovedregne som det allerførste.
Giv brugeren noget til System-1 i første omgang, og gem detaljerne til senere:
- Vis differencen direkte: “-7%” eller “+12%”.
- Brug en farvekode eller en pil opad eller nedad til at indikere, om udviklingen er positiv eller negativ.
- Eller tilføj en sammenligning direkte i visningen, fx: 57 (+12 fra sidste år).
På denne måde kan du gøre informationen intuitiv, så den kan forstås med et hurtigt blik, præcis som System-1 foretrækker det. Så kan brugeren straks vurdere, om handling er nødvendig.
Det er BI, der arbejder for brugeren, ikke omvendt.
Vi vender tilbage til konkrete opskrifter og gode råd til at designe en BI-rapport, som tager højde for System-1 og System-2. Dette var kun en smagsprøve.
Men inden du går i gang med at designe BI-rapporten, så er du nødt til at forstå, hvordan dine brugere forstår de tal og de grafiske elementer, som du vælger at bruge i BI-rapporten. Det er en forudsætning.
Her kommer en række konkrete psykologiske værktøjer, som du kan anvende til at gøre dine rapporter lettere at forstå.
DESIGN TIL DINE BRUGERES PSYKOLOGI
Der er mange psykologiske principper, som visuelle designere og marketing-folk har forfinet gennem årtier, som du med fordel kan anvende, når du skal skabe en BI-rapport, der skal præsentere information på en måde, der maksimerer forståelse og understøtter handling.
Lad os se på nogle af de mest generelle videnskabelige principper, som kan hjælpe dig som BI-ansvarlig med at sikre, at rapporter ikke bare ser flotte ud, men også er intuitive og brugbare.
Von Restorff-effekten: Brug kontrast til at øge opmærksomheden
Hvis der er en bestemt ting, du vil sikre dig, at brugeren ser og husker, så skal du bruge kontrast til at fremhæve det. En farvet baggrund på en ellers neutral flade vil automatisk tiltrække øjet. Det samme gælder farve-kodning i rapporter, fx rød for negative tendenser og grøn for positive.
Millers lov: Begræns mængden af information
Den gennemsnitlige bruger kan kun holde cirka syv datapunkter i arbejdshukommelsen. Hvis der er mere end syv ting, der kræver brugerens opmærksomhed, så begynder du at overbelaste brugerens hjerne. Du er nødt til at udvælge, hvad der er vigtigst at brugeren forstår.
Hicks lov: For mange valg hæmmer beslutningsprocessen
Jo flere valg du præsenterer brugerne for, des langsommere og sværere bliver deres beslutningsproces. Hvis en rapport er fyldt med for mange filtre, dropdowns og valg, så kan det betyde, at brugeren slet ikke når frem til at handle. Gør det let at vælge det vigtigste først og gem det avancerede til senere.
Gestaltprincipper: Gruppér information logisk
Mennesker forstår data bedst, når elementer, der handler om samme emne eller giver mening sammen, er visuelt grupperet. Hvis du præsenterer forskellige KPI’er uden en tydelig opdeling, så bliver det svært at navigere i. Sørg for, at lignende data præsenteres sammen.
Fremhævning med Von Restorff
Von Restorff-effekten kaldes også “the isolation effect”, og det er et psykologisk fænomen, der handler om, at mennesker har en tendens til bedre at huske det element, der skiller sig ud fra mængden.
Effekten blev først beskrevet af den tyske psykolog Hedwig von Restorff i 1933. I hendes eksperimenter viste hun, at hvis en liste af ensartede elementer indeholdt ét, der var markant anderledes, ville folk huske netop det element bedre end resten.
I en BI-kontekst kan du bruge Von Restorff-effekten til at fremhæve kritisk information, så brugeren hurtigt ser og forstår, hvad der er vigtigt.
Du kan både anvende kontraster i farve, eller forskel i størrelser af elementer, eller gøre fonte fed eller kursiv.
Der er mange muligheder for at skabe kontrast. Når du kigger på din BI-rapport, så overvej, om du aktivt styrer brugernes opmærksomhed, så de hurtigt ser det mest relevante.
Enkelhed med Miller
Millers Lov stammer fra en artikel skrevet af den amerikanske psykolog George A. Miller i 1956 med titlen “The Magical Number Seven, Plus or Minus Two”, og hans pointe er, at den menneskelige arbejdshukommelse kun kan håndtere omkring 7 elementer ad gangen.
Hvis vi bliver præsenteret for mere end 7 stykker information på én gang, så begynder vi at miste overblikket, glemme detaljer eller træffe dårligere beslutninger.
I design af BI-rapporter betyder det, at du skal præsentere data på en måde, der ikke overvælder brugeren.
- Begræns antallet af elementer eller nøgletal til højst 5-7 vigtige.
- Hold grafer enkle. Hvis du har mange datapunkter i en visualisering, så kan det være en god idé at gruppere, filtrere eller opsummere.
- Lad et dashboard fokusere på ét tema, i stedet for at samle forskelligartede oplysninger på ét skærmbillede.
Hvis mængden af information i din rapport skaber kognitiv overbelastning, så bliver det sværere for brugeren at tage hurtige og effektive beslutninger.
Færre valg med Hick
Hicks Lov kaldes også for Hick-Hyman-loven, og den siger, at jo flere valg en person præsenteres for, des længere tid tager det at træffe en beslutning.
Loven blev formuleret af psykologerne William Edmund Hick og Ray Hyman i 1952 og beskriver, hvordan beslutningstiden øges i forhold til antallet af valgmuligheder, men også at konsekvensen af flere valgmuligheder er størst i begyndelsen.
Når du designer BI-rapporter og dashboards, så bør du have Hicks lov i tankerne og rydde ud i mængden af valgmuligheder. Ifølge Hicks lov er det bedst, hvis du helt kan undgå valgmuligheder.
- I forhold til betjening, så giv brugeren færre, men mere relevante filtreringsmuligheder, i stedet for at bombardere dem med dropdown-felter.
- I forhold til beslutningstagning, så begræns antallet af elementer og nøgletal på skærmen, så brugeren ikke skal forholde sig til for mange elementer for at træffe en beslutning.
- Brug forudvalgte standardindstillinger. Hvis din rapport har mange valgmuligheder, så vælg de mest relevante som standard, så brugeren ikke behøver tage stilling til noget for at bruge rapporten første gang.
Når brugerne skal forholde sig til mange valgmuligheder, så bruger de for lang tid på at finde den rigtige indsigt og træffe en beslutning. Du skal designe rapporter, der hjælper brugeren effektivt.
Helheder med Gestalt
Gestaltprincipperne stammer fra gestaltpsykologien, som er en teori udviklet af tyske psykologer i starten af 1900-tallet. Gestalt handler om, hvordan mennesker opfatter og organiserer visuelle elementer. Vi ser helheder frem for enkeltdele.
Grundlæggende betyder det, at vores hjerner automatisk grupperer og forbinder visuelle objekter efter bestemte mønstre. Disse principper bruges bredt i brugerdesign (UI/UX), fordi de hjælper med at gøre brugergrænseflader lettere at forstå.
Inden for BI kan du bruge nogle af gestaltprincipperne til at overveje, hvordan du bedst visualiserer data. Når du har styr på, hvordan mennesker opfatter visuelle elementer, så giver det dig mulighed for at hjælpe dine brugere med at forstå rapporten lettere.
Nærhed og gruppering:
Elementer, der er placeret tæt på hinanden, bliver opfattet som relaterede. Det er oplagt at placere relaterede data tæt på hinanden i en rapport, og adskille dem fra data, der handler om noget andet. Hvis du fx sætter en ramme rundt om nogle elementer, så vil brugerne nemt forstå, at de hører sammen og er anderledes i forhold til de andre elementer.
Lighed:
Objekter, der ser ens ud, fx fordi de har samme farve, form eller størrelse, de opfattes som en del af samme gruppe. Du kan hjælpe brugerne til at forstå, hvilke data og elementer, der hører sammen, ved at give dem samme farve, form eller størrelse.
Kontinuitet:
Øjet følger naturligt linjer og mønstre. Elementer, som tilsammen danner et mønster, bliver af brugerne opfattet som hørende sammen. Når du præsenterer data i grafer eller kombinerer flere datasæt i en visualisering, så overvej, om du guider brugerne korrekt til at forstå, hvilke data der hører sammen.
STRUKTUR FOR EN BI-RAPPORT
Nu skal vi snakke om et design-princip i Business Intelligence, der kaldes 3-30-300-reglen. Det er opskriften på, hvordan du skal strukturere et Business Intelligence-dashboard.
Det handler om, at du altid skal tænke over, hvordan brugeren oplever data. Det er en rettesnor for, hvordan du skal opbygge BI-rapporten, så du sikrer, at brugeren kan anvende den til mange formål uden at blive overvældet.
Reglen handler om, at brugeren skal kunne finde svar på forskellige niveauer af indsigt inden for tre sekunder, 30 sekunder og 300 sekunder (5 minutter).
Betragt denne regel som en udvidelse af tre-trins-raketten. Vi repeterer lige raketten hurtigt her:
- Forstå din brugers rolle og kontekst
- Hvilke beslutninger skal brugeren træffe?
- Hvilke data er nødvendige?
Den viden er en forudsætning for at designe din rapport, og den rapport skal opdeles i 3 niveauer, og det er årsagen til, at den hedder 3-30-300-reglen.
Du skal nu forholde dig til, hvilken indsigt brugeren skal opnå med 3 sekunders
indsats, med 30 sekunder, og med 300 sekunder, og hvordan det kan hjælpe brugeren med at træffe de nødvendige beslutninger.
3 sekunder: Giv øjeblikkelig indsigt
Inden for 3 sekunder skal brugeren kunne besvare de vigtigste spørgsmål. Det er målet. Det handler om de overordnede spørgsmål, som fx:
- Hvad er månedens salgstal?
- Ligger vi over eller under budget?
Hvis din rapport kræver, at brugeren scroller, filtrerer eller hovedregner for at få overordnet indsigt, så dur det ikke.
Nogle tror, at kompleksitet i visualisering ikke kan undgås, når man arbejder med forretningsdata, der naturligt er komplekse, men det kan det godt. En BI-rapport bør være så simpel som mulig ved første øjekast, men stadig have avancerede funktioner til dem, der vil fordybe sig.
Vi taler om helt enkle visualiseringer som fx:
- Placér de få allervigtigste KPI’er øverst til venstre, hvor øjet starter sin naturlige læseretning. Udfør de komplekse beregninger i baggrunden og præsentér kun slutresultatet for brugeren.
- Brug store tal, gerne afrundet så de er hurtigere at forstå.
- Brug farvekodning og symboler, fx grønt flueben for positive tal, rødt stopikon for negative tendenser.
- Skjul avancerede filtre og indstillinger, indtil de er nødvendige.
Det skal være så simpelt, at en bruger intuitivt forstår budskabet uden at tænke over det.
“Affordance” er et designprincip om, at et design intuitivt skal vise, hvad det er. Elementerne i din BI-rapport, der er designet til de første 3 sekunder, bør være selvforklarende, så brugeren uden træning kan forstå dem.
Det er oplagt at anvende trafiklys og ikonografi, og der skal helst ikke være behov for forklarende tekst, men hvis det er nødvendigt af hensyn til nogle af brugerne, så læg forklaringer i tool-tips.
30 sekunder: Find årsagen bag tallene
Dette niveau handler om at identificere årsager. Hvis salget er lavere end budgettet, så skal brugeren hurtigt finde ud af, hvor problemet ligger. Det har du 30 sekunder til at vise dem.
På de 30 sekunder skal brugeren kunne finde ud af, hvad der skal gøres noget ved.
Du skal ikke vise alle detaljer, for det er stadig for omfattende. Du skal aggregere på et passende niveau, som giver mening i situationen, og som guider brugeren i den rigtige retning.
Brugeren skal måske kigge på en region, et land, en kundegruppe, en produktkategori, og måske kunne skifte en måned eller et år, eller zoome og filtrere lidt. Du kan give brugeren mulighed for at dykke ned i posterne, men det må ikke være en nødvendighed på dette niveau. Men brugeren skal kunne se, hvor det er meningsfuldt at kigge hen, hvis man fx skal isolere enkelte kunder, varer eller transaktioner.
På dette niveau må brugeren godt bruge lidt tid, men de skal stadig hurtigt kunne navigere uden at miste overblikket. Begræns mængden af elementer og informationer, og tænk på, at der ikke er tid til særlig mange navigationer inden for 30 sekunder.
Følg konventioner for rapportdesign, som brugerne allerede kender. Det kalder man Jakobs lov, og den siger, at brugerne opfatter din BI-rapport ud fra de konventioner, som alle andre rapporter, de kender.
Mange af kontrollerne er styret af producenten, der har udviklet dit BI-system,
så måske er det begrænset, hvor meget du kan ændre på. Men tænk alligevel over, at betjeningen skal være intuitiv.
- Placér filtre i venstre side og KPI’er i toppen.
- Brug kendte farvekoder, fx grøn = godt, rød = dårligt.
- Brug velkendt ikonografi, hvis du har behov for at forklare noget.
- Sørg for, at knapper ligner knapper, og at klikbare elementer ser klikbare ud.
- Gør navigation intuitiv, fx at et klik på et nøgletal åbner uddybende data.
Brugerne forventer velkendte mønstre, så hvis du skal give dem et udbytte på 30 sekunder, så må du hellere lade være med at farve en positiv udvikling rød, for det er kontra-intuitivt.
Formålet med de 30 sekunder er at identificere kategorier, som brugeren kan dykke ned i og analysere hele datagrundlaget, når vi om lidt kommer til 300-sekunders-delen.
300 sekunder: Gå i dybden
På det tredje niveau får brugeren mulighed for at dykke ned i det detaljerede datagrundlag, så de kan træffe en konkret beslutning.
Nu klikker de på de aggregerede tal, fx en kundegruppe, for at se de konkrete kunder og identificere dem, der skal tages handling på. Brugeren skal kunne klikke direkte på visualiseringerne i 30-sekunders-niveauet, og så fungerer det som filter i visningen af datagrundlaget. Det er mest intuitivt.
Nu er vi i høj grad i System-2 med lange tabeller af data. Hvis de indgår i en samlet rapport, så placér tabellen i bunden, hvor brugeren kigger sidst.
Overvej også, om tabeller er den rette visualisering på dette niveau. Økonomifolk kan typisk godt lide at have adgang til hele datagrundlaget i tabelform, men ofte er der andre typer af visualiseringer af hele datagrundlaget, som giver bedre mening.
Lad være med at designe dette niveau som om, at brugeren bare skal eksportere tabellen til Excel. Giv dem i stedet den indsigt, de har tænkt sig at opnå i Excel.
Design nedefra
3-30-300-reglen er nem at huske, og den sikrer, at dine rapporter ikke bare er dataarkiver, men faktisk hjælper brugerne med at tage bedre beslutninger.
3 sekunder: Simple nøgletal, øverst til venstre, hurtig indsigt
30 sekunder: Aggregerede data, midt på skærmen, udforskning og kontekst
300 sekunder: Hele datagrundlaget, nederst eller på en underside, detaljer og analyse
Og når brugeren skal navigere mellem niveauerne, så er en løsning som Power BI så smart, at man kan klikke på data i en visualisering, og så fungerer det som filter i den uddybende visualisering på det næste niveau.
På den måde kan du designe, hvordan brugeren kan springe mellem de 3 niveauer.
Du skal designe din rapport fra bunden af. Som udgangspunkt har du sikkert en masse data i en stor tabel, og det hører til i 300-sekunders niveauet. Sådan en tabel kræver en seriøs indsats fra brugerens System-2, der skal langsomt startes og opvarmes som en gammel traktor på kold januardag. Det hører til i bunden af din rapport.
Nu skal du have en holdning til, hvad udfaldet skal være, når rapporten bliver brugt. Formålet er at lede brugeren frem til en handling. Du skal vide, hvilken type beslutning, brugeren skal tage, og du skal forstå, hvordan brugeren kommer frem til en beslutning.
Du skal med andre ord designe en BI-rapport, der understøtter den erkendelsesproces, der leder brugeren frem til det bedst mulige udfald for forretningen.
Med den viden, så kan du designe 30-sekunders og 3-sekunders niveauerne, så niveauer hænger sammen og hjælper brugeren med at træffe beslutninger.
FÅ BI-RAPPORTEN I BRUG
Nu har du gjort alt dit forarbejde. Du har researchet dine brugere, forretningens strategi, processer, beslutninger og alt det, som ved første øjekast ikke har noget med selve BI-rapporten at gøre, men alligevel er utrolig vigtigt.
Og så har du designet en god BI-rapport efter 3-30-300-reglen, har forholdt dig til menneskelig adfærd og har overvejet de valgte KPI’er grundigt. Din rapport er perfekt.
Langt om længe er der nu brugere, som skal se din BI-rapport, og så er du desværre slet ikke i mål endnu.
Vi skal tale om det, som i IT-sprog kaldes for ”adoption”, dvs både at få brugerne til at bruge rapporten, men også at få dem til at bruge den godt, så de får det fulde udbytte af den.
Du forventer, at de bruger BI-rapporten, enten fordi de skal, eller fordi det giver dem en værdi.
I realiteten bruger de den ikke. Det er ikke fordi de er dovne. Dine kolleger er hårdtarbejdende, dygtige og ærekære mennesker, men deres System-1-hjerner er påpasselige med ikke at bruge for meget energi, så de prøver at undgå alt, der kræver ekstra tankevirksomhed. Sådan er alle mennesker.
Hvis der er friktion, så bliver din rapport brugt mindre. Og derfor skal du nu med på en mission for at fjerne alle former for friktion.
Manglende ”adoption” er faktisk 2 problemer i en træls forening:
Ingen har lyst til at finde din rapport
Brugerne føler ikke, at din rapport er nem at finde eller at komme i gang med at bruge, og derfor orker de ikke at bryde deres indgroede vaner.
Selv om du har en BI-rapport, som svarer perfekt på brugernes behov og sætter dem i stand til at performe ud over alle grænser, så det er stadigvæk ikke garanteret, at de gider åbne rapporten.
Enhver friktion i distribution af BI-rapporten tvinger brugeren over i System-2, og så bruger de den ikke. Har de linket? Hvor er bogmærket? Er det den rigtige rapport? Var der kommet en ny version af rapporten? Det er altid nemmere at stole på sin mavefornemmelse, end at finde en BI-rapport.
Det er også altid nemmere at skrive en email til økonomichefen med nogle spørgsmål, end at åbne en BI-rapport (selv om det tager længere tid).
Nem adgang til BI-rapporten er meget mere vigtigt, end du umiddelbart regner med. Din rapport skal være relevant, men den skal også være nem at få adgang til.
Ingen har lyst til at lære på forhånd
Hvis det ikke er intuitivt at bruge din rapport, så kræver det oplæring, og det er ikke sikkert, at brugerne orker at lære, før det er aktuelt for dem.
Du har skrevet en udførlig manual, og du har holdt uddannelse for dine kolleger. Du kan dokumentere, at du har gjort alt, hvad der er menneskeligt muligt for at lære dem at bruge BI-rapporten.
Men fordi de er mennesker, så har de ikke læst manualen, og de har glemt, hvad du sagde på info-mødet. Når de på et tidspunkt er nødt til at bruge rapporten, så prøver de sig bare frem.
Du er velkommen til at mene, at det ikke er fair. Men du kan ikke ændre på det.
På den ene side er det forståeligt, at brugerne ikke vil bruge energi på at lære at betjene BI-løsningen. Dine BI-rapporter repræsenterer ikke en værdi i sig selv. De skal understøtte dine kollegers værdiskabende aktiviteter. Dine kolleger skal helst bruge så lidt tid som muligt i BI-løsningen. De skal have hurtig indsigt og komme hurtigt frem til beslutninger.
Men på den anden side, så kunne de få mere ud af rapporten, hvis de havde lyttet efter på info-mødet, hvor du forklarede de krøllede detaljer. Sådan er mennesker bare ikke.
Brugerne går bare i gang
Mennesker handler ikke altid rationelt eller optimalt. De vælger den hurtigste vej til et resultat, ikke nødvendigvis den bedste. Du har skrevet en udførlig vejledning, og du kender alle filtre og finurligheder, og så antager du, at andre brugere også har lyst til at lære, hvordan man bruger BI-rapporten bedst.
Der rammer du “Paradox of the Active User”, som er et brugerdesign-begreb, der handler om, at brugere ofte springer introduktioner og vejledninger over, fordi de vil i gang med at bruge et system så hurtigt som muligt, selvom det betyder, at de aldrig lærer at bruge systemet optimalt.
Begrebet blev først beskrevet i 1987 af John M. Carroll og Mary Beth Rosson, der studerede brugere af IBM-systemer. De opdagede, at selvom manualer og træning kunne gøre brugerne langt mere effektive, valgte de fleste at lære systemet gennem trial-and-error, hvilket ofte resulterede i ineffektive arbejdsgange.
Brugerne vil gerne føle, at de sparer tid, og de stoler på deres egne evner til at regne tingene ud, og i øvrigt virker manualer og vejledninger også meget overvældende.
Du kan ikke overtale alle brugerne til at læse manualen og gennemføre hele uddannelsen. Det er en tabt kamp, og dine fornuftige argumenter er spild af energi. Der er kun én løsning på problemet: Gør det enkelt. Nemt. Ligetil. Intuitivt. Supersimpelt.
Så her kommer opskriften på at få BI-rapporter sat i værk:
- Intuitivt design med 3-30-300-reglen
- Nem adgang til indsigt
- Forandringsledelse, og ikke kun undervisning
- Skub indsigt ud til brugerne
Og de 4 punkter tager vi nu én ad gangen:
1. Intuitivt design
Det første punkt er naturligvis 3-30-300-reglen, og den har du allerede læst et helt kapitel om, så den behøver vi ikke gennemgå igen.
Men tænk over, at det bedste er, hvis din rapport slet ikke kræver undervisning og er helt selvforklarende.
Betjeningen og navigationen i rapporten bør aldrig kræve forklaringer. Brugerdesignet skal følge gængse mønstre, så det er intuitivt at forstå, og brugeren ikke skal lære noget nyt.
Og hvis der er behov for forklaringer, så indbyg dem i rapporten, hvor det giver mening for brugeren, fx i form af tool-tips eller forslag.
Jo mere intuitiv og selvforklarende en BI-rapport er, des større er sandsynligheden for, at den faktisk bliver brugt (og brugt korrekt).
2. Nem adgang til indsigt
Du skal ikke kun tænke over, hvordan indholdet i BI-rapporten fungerer, men også hvilken kontekst BI-rapporten skal indgå i.
Hvor får brugerne nemmest adgang til rapporten? Og fungerer den godt for dem, der hvor de har behov for indsigten?
Lad os tage et par gode eksempler for at give dig inspiration.
Et godt mantra er, at:
Du får mere succes med at udgive din BI-rapport dér, hvor dine brugere befinder sig, i stedet for at bede dem om at komme til dig.
Hvis I bruger Teams, så er det et godt sted at placere din BI-rapport. Du kan tilføje rapporten direkte som et faneblad i et Team, og så kan brugerne chatte
om data direkte i teamet. Det er en meget nem måde at bruge en BI-rapport på.
Der er også mange brugere, som hver måned copy/paster data og visualiseringer fra Power BI og Excel over i PowerPoint, for at de kan præsentere månedens resultater. Det bruger de rigtig meget tid på.
Men du kan også implementere din BI-rapport direkte i PowerPoint, og på den måde behøver brugerne slet ikke at copy/paste noget.
Rapporten er altid up-to-date i PowerPoint-præsentationen. Det er også en god måde til at gøre din rapport tilgængelig der, hvor brugerne har brug for den.
Og hvis dine brugere skal anvende rapporten på en mobiltelefon, så skal du tage hensyn til det, allerede når du udvikler rapporten.
Der er stor forskel på, om en rapport skal anvendes på desktop, hvor der er god plads til at overskue mange elementer, eller på en mobiltelefon, hvor overblik ikke eksisterer.
Der er nogle begrænsninger i at bruge Power BI på mobiltelefonen, som du skal være opmærksom på.
Hvis du fx tilføjer en tabel eller en matrice med kolonner til din rapport, så kan du ikke bagefter resize tabellen i mobil-layoutet.
Så skal brugeren scrolle sidelæns på mobiltelefonen for at se tabellen, og det er der virkelig ikke nogen, der gider at gøre i særlig mange sekunder.
Generelt er det virkelig svært at overskue mange elementer på en telefon. Du skal i mobil-layoutet være opmærksom på, at det ikke må være en forudsætning, at brugeren skal kigge på tværs af elementer eller data. Alt skal kunne forbruges i små bidder.
Men mobiltelefonen giver også muligheder. Der er NFC-understøttelse i Power BI på mobiltelefonen, og det kan du udnytte til at give brugerne hurtig adgang til information.
Hvis du fx har NFC-chips på hyldeforkanterne på lageret, så kan du scanne en chip og hoppe direkte ind i lagerrapporten for pågældende vare og se lagerværdi og beholdning og meget mere for varen. Det fjerner virkelig meget friktion for brugerne, at de ikke skal indtaste eller filtrere sig frem til en vare i en rapport.
Det var nogle meget konkrete eksempler, men den overordnede pointe er, at der er tusind måder at gøre BI lettere tilgængelig for brugerne.
Tænk ud af boksen og find de måder, hvor du kan give brugerne BI-indsigt der, hvor de befinder sig, i stedet for at bede dem om at logge ind i en portal.
3. Forandringsledelse
Men selv om din BI-rapport er både supersimpel og let tilgængelig, så er det stadig ikke sikkert, at dine kolleger finder vej ind i rapporten. Du er i gang med at ændre deres vaner, og vaner er svære at bryde.
Betragt uddannelsen af brugerne som forandringsledelse. Du skal ikke kun instruere dem i at anvende BI-portalen. Du skal planlægge forandrings-aktiviteter, som kan ændre brugernes hidtidige adfærd.
Begynd med klassisk undervisning
Det er ikke nok i sig selv, men det er et fundament. Brug 30 minutter med brugerne. Vis dem hvor de skal klikke, hvordan de sætter filtre, og spørg dem direkte, om de har noget konkret de gerne vil se.
Hvis de forstår, hvordan rapporten kan give dem værdi, så er fundamentet stærkere.
Find en ambassadør
Identificér en leder eller en stærk influencer i organisationen, som ser
værdien i rapporten, og som kan være med til at sprede det gode budskab.
Få vedkommende til at starte møder med information fra BI-rapporten, så alle kan mærke, at den er et udgangspunkt for viden i virksomheden. Vedkommende kan endda ende med at yde første-linje-support til brugerne, hvis alt går godt.
Aktivér ledelsen
Vi ved fra forskning, at det bidrager positivt, hvis ledelsen aktivt bruger elementer fra BI-rapporten i præsentationer og møder. Det skaber en præcedens og en implicit forventning om, at medarbejderne orienterer sig i de samme rapporter.
Når din BI-rapport er blevet en naturlig del af samtalen i organisationen, så begynder folk at bruge den i dagligdagen.
Skub indsigt ud til brugerne
Nu er vi nået til 4. trin, og i de første 3 trin har du sørget for, at din BI-rapport er intuitiv at bruge, let tilgængelig, og at brugerne finder det naturligt at bruge rapporten.
Nu skal du tænke et nummer mere offensivt. Her i 4. trin skal du overveje, om du kan skubbe information ud til brugerne, så de slet ikke behøver at anvende din BI-rapport.
Det fjerner al friktion, hvis indsigt kommer naturligt til brugerne som en del af deres arbejdsrutiner.
Her kommer nogle eksempler til at sætte gang i dine overvejelser:
Abonnement på dashboards
Det mest simple tiltag er at oprette et abonnement på et ”dashboard” i Power BI, så brugeren periodisk modtager en e-mail med et snapshot fra Power BI.
Det kan faktisk fungere som den primære måde, organisationen modtager indsigt fra Power BI på.
Forestil dig en salgsafdeling, hvor alle de salgsansvarlige hver morgen modtager en e-mail med et snapshot af salgs-dashboardet. Det viser omsætningen for dagen før og en sammenligning med budgettet. På tre sekunder kan de aflæse det vigtigste uden at logge ind.
Det fjerner friktionen for at bruge BI, fordi sælgerne alligevel tjekker deres e-mail hver morgen. Og det bliver hurtigt en naturlig del af den daglige samtale, fordi alle modtager den samme information om morgenen. Det skaber en fælles referenceramme.
Og så kan et andet abonnement sørge for, at en detaljeret omsætningsrapport bliver sendt til de ansvarlige ledere en gang om ugen. Den kan indeholde ugens resultater, tendenser over tid, og alt det, der hører til 30-sekunder-niveauet.
BI på storskærm
Men du kan også overveje et dashboard med centrale nøgletal, som kører på en storskærm i din virksomhed, så alle nemt kan følge med. Det er en anden slags ”abonnement”. Det er rigtig effektivt at ”nudge” medarbejderes System-1 i retning af fælles mål, der er synlige for alle på samme tid på kontoret.
Adviseringer og alarmer
En anden mulighed for at nedbringe friktionen for brugerne, det er at udsende adviseringer og alarmer, når data er aktuelle for brugerne.
Så skal de ikke selv kontrollere noget i en applikation. De bliver prikket på skulderen, når der sker noget i BI-data, som de bør vide. Ikke blot bringer det BI-viden ud, hvor brugerne er, det sker også på præcis det tidspunkt, hvor brugerne bør modtage viden.
Du kan definere alarmer på KPI- og Gauge-visualiseringer i Power BI, og det er så enkelt, at når det du måler på overstiger en prædefineret værdi, så sender systemet en besked. Det er ret basalt, men det er effektivt.
Tænk meget bredere end de klassiske eksempler med omsætningstal. Adviseringer kan bruges til alt muligt i din virksomhed.
Hvis du fx har et termometer i et kølerum, så kan du koble det til BI-løsningen og overvåge temperaturen, og hvis den stiger til mere end 5 grader, så modtager du en besked inden for et par sekunder.
De samme muligheder kan også anvendes til forretningsdata. Du kan fx også sætte en overvågning på en afdelings nøgletal, og når afdelingen har nået månedens mål, så modtager alle en Teams-besked med informationen.
Der er rigtig mange anvendelsesmuligheder. Tænk over, hvordan du kan udnytte mulighederne, for det fjerner friktion og bringer Business Intelligence derhen, hvor brugerne befinder sig.
Det var del 2 om at designe BI-rapporter, som brugerne har lyst til at anvende. Du har lært de psykologiske mekanismer at kende, og en praktisk 3-30-300-regel, som bringer dig i mål.
Nu er du klar til at vælge den rette teknologi til dit projekt, og det handler del 3 netop om.
DEL 3: TEKNIK
Som almindelig bruger kan man sagtens tænke, at Power BI vel ”bare” skal kobles sammen med Business Central, og så kan vi bruge ERP-data i Power BI.
Det er en helt forståelig tanke, og Microsoft får det også til at lyde nemt i deres reklamemateriale, men det er desværre ikke helt så simpelt i praksis.
Data kommer ikke ud af Business Central i et format, som er særlig godt til rapportering.
Der skal foretages en transformation, for at vi kan anvende data, sådan som vi gerne vil i Power BI.
Og dette afsnit giver dig overblik over, hvilke værktøjer vi skal have i spil, for at du har et velfungerende Business Intelligence-system til dine ERP-data.
Du er blevet kaldt ind på CFO’en kontor. Budskabet er klart, og ordene falder nogenlunde således:
“Jeg er med på, at du gerne vil begynde med en masse research, men der er efterhånden gået lang tid, så jeg tænker, at vi skal have noget sat i gang nu.”
CFO’en har set en smart pakkeløsning med Power BI, som man kan komme i gang med på en eftermiddag, og det giver nogle flotte dashboards. “Kan vi ikke bare begynde der?” lyder spørgsmålet.
Efter mødet støder du på den it-ansvarlige, som har den stik modsatte holdning. Forelskelsen i det store Microsoft Fabric data warehouse skinner tydeligt igennem, og du tør slet ikke nævne den pakkeløsning, du lige har fået besked på at begynde med.
CFO vil have en delebil, og den it-ansvarlige vil have en racerbil. Men det gode spørgsmål er: Hvad er det rette valg?
En pakkeløsning kan være en udmærket begyndelse, men hvad sker der, hvis nogen senere får behov for at få data opdateret jævnligt, og har 40 mio. poster i et andet system, som også skal inkluderes som datakilde?
At begynde stort eller småt. Begge dele kan være det rette valg, hvis det matcher virksomhedens aktuelle behov, og kan udvides til fremtidige behov.
Den tager vi lige igen for at være sikker:
Matcher i dag. Forberedt til fremtiden. Det er det rette valg.
Derfor er det vigtigt, at du har været gennem del 1 og 2 i denne guide, før vi nu tager hul på teknikken.
OVERBLIK OVER DEN TEKNISKE LØSNING
Her i teknik-afsnittet tager vi udgangspunkt i Microsoft Power BI som værktøj til visualisering, og ERP-systemet Microsoft Dynamics 365 Business Central som kildesystem.
Som nævnt kan du vælge at begynde med en enkel pakkeløsning, men du kan også vælge et rigtigt Data Warehouse med Microsoft Fabric. Det gennemgår vi alt sammen om lidt.
Og bare fordi vi nu fokuserer på Business Central som datakilde, så forhindrer det dig ikke i at tilføje mange flere kildesystemer, eller at begynde et helt andet
sted, men BI-rapporter med ERP-data er en klassiker, så det er der, vi begynder.
Tegningen giver dig et overblik over den tekniske løsning, og lad os først gennemgå den fra venstre til højre, og så går vi i detaljer bagefter.
Grundlaget for alt er kildesystemet, som i dette tilfælde er Business Central, men som ellers kan være en hel række af kildesystemer.
Den første opgave er at skabe adgang til data.
Business Central er født med teknologi, der kan udstille data til dette formål. Det kalder man et API.
Men Business Centrals API er ret begrænset, og ofte er man nødt til at finde en løsning til at udstille og skabe adgang til flere data.
Så skal vi have en service, som replikerer data over i en anden database, som Power BI kan anvende.
Databasen for et BI-værktøj er anderledes end databasen for en ERP-løsning, og derfor er det nødvendigt at kopiere data over i et Data Warehouse.
BI-værktøjet kan teknisk set ikke køre direkte på ERP-databasen, og det ville også være et performancemæssigt mareridt.
Den database, som data bliver replikeret til, kalder man et Data Warehouse. De fås i mange størrelser og kompleksiteter.
Den mest simple er bygget ind i maven på Power BI, og den er så enkel, at en BI-konsulent næppe ville kalde det for et rigtigt Data Warehouse – og i den større ende finder man egentlige Data Warehouses med staging-lag og mange muligheder af frihedsgrader for behandling af data.
Vi tillader os i denne sammenhæng at bruge udtrykket ”Data Warehouse” som en fællesbetegnelse for de databaser, som kan fungere som grundlag for Business Intelligence.
I et Data Warehouse foregår en transformation af data, til dels for at gøre data brugbare for visualiseringsværktøjet Power BI, men også for at sammenkøre data, udregne nøgletal, og skabe de muligheder for at gruppere, afgrænse og sortere, som man ønsker, og meget mere.
Det sidste skridt er visualisering af data. Her kommer Power BI på banen, hvor brugeren har rapporter og dashboards til rådighed, som viser de data, der er forberedt i Data Warehouse.
Det er de elementer og processer, der skal være styr på for at bruge Power BI til at analysere data fra Business Central (og andre kildesystemer). Det kan som sagt løses både simpelt og avanceret, og det afhænger helt af dit ambitionsniveau, hvilken løsning du bør vælge.
Nu gennemgår vi mulighederne, fra simpel til avanceret, og vi lægger især vægt på de emner, som er afgørende for, hvor avanceret en løsning, du skal vælge.
Målet er at klæde dig på til at træffe det valg, som matcher dine behov, og at du på forhånd har indblik i, hvor meget du kan vokse i den løsning, du har valgt.
DEN SIMPLE LØSNING
Den simple løsning er, at Power BI får lov til at stikke snablen direkte ned i Business Centrals data. Det foregår via en teknologi, der hedder OData.
Adgangen til data kan du løse ved at installere en app i Business Central, og så skal du sikkert have en smule konsulenthjælp til at koble Power BI sammen med Business Central. Men derfra er opgaven ikke særlig teknisk.
Power BI vil placere data i sit eget dataformat inde i Power BI-servicen, og der er ikke noget rigtigt Data Warehouse, men der er en slags dataplatform indbygget i Power BI, hvor man kan transformere sine data til en vis grad.
Den simple løsning består således af 2 elementer: Adgang til data + Power BI rapporter, og de to elementer gennemgår vi nu.
Det scenarie forudsætter, at man kan anvende Business Centrals datastruktur uden større transformationer.
Med den simple løsning har vi begrænsede muligheder for at modulere data, men simple transformationer af data kan sagtens lade sig gøre direkte i Power BI. Beregninger af nøgletal vil altid foregå i Power BI, uanset om der er et eksternt Data Warehouse eller ej.
Adgang til data
Adgang til data i Business Central foregår enten via Microsofts standard-API, eller ved at du installerer en app fra Microsoft AppSource med et bedre API, eller at du hyrer en udvikler til at skabe et nyt API. Det er de 3 muligheder, du kan vælge mellem.
Det er en begrænset mængde data, Microsofts standard-API’er giver adgang til. Man løber nemt ind i, at man ikke har adgang til alle de kolonner i centrale Business Central tabeller, som man har behov for.
Så har man behov for en løsning til at udstille de nødvendige data. 
I den situation kan man vælge at abonnere på en app, der hedder Data Access, som vi i Abakion har udgivet på Microsoft AppSource – eller en tilsvarende app fra en af vores kolleger i branchen.
Besøg appsource.microsoft.com
Med en app fra Microsoft AppSource får du en standardløsning, som er klar til brug, og giver adgang til et udvalg af tabellerne i Business Central. Den koster et abonnement, men det er til gengæld leverandøren, som er ansvarlig for vedligeholdelse.
Når der sker ændringer i Business Central, så er leverandøren forpligtet til at opdatere app’en, så den uafbrudt virker efter hensigten.
En app er en “managed service”, som du kan vælge, hvis du vil tage en af de tekniske udfordringer ud af ligningen.
Du kan naturligvis hyre en udvikler til at lave de samme API’er, som du får med en app, men du skal være opmærksom på, at det er lidt af en specialkompetence. Det er langt fra alle Business Central-udviklere, som har erfaring med at skabe API’er.
Og så er der naturligvis de åbenlyse forskelle, at du selv skal betale for udviklingsprojektet samt de løbende ændringer, som nye versioner af Business Central kræver, men at du slipper for at betale abonnement.
Vi har i Abakion valgt app-vejen, fordi vi ikke vil opfinde den dybe tallerken hver gang, men det er naturligvis et spørgsmål om, hvad man foretrækker.
Standardpakke
Når du med ”den simple løsning” har adgang til Business Central-data, så mangler du kun at etablere de rapporter i Power BI, som du gerne vil have.
Microsoft kalder det low-code. Indlæringskurven er ikke særlig stejl, og det kræver ikke udvikler-kompetencer at arbejde med ERP-data i Power BI. Det kræver i højere grad indsigt i datastrukturen i de ERP-data, du vil arbejde med.
Du kan vælge at anvende en færdigbygget rapportpakke i Power BI, i stedet for at bygge dine egne dashboards og rapporter i Power BI. Så er det plug’n’play. Det er bare at tegne et abonnement.
En standardpakke er ikke blot en nem måde at komme i gang på. Den datamodel, som følger med en standardpakke, er også et rigtig godt grundlag for, at du kan bygge dine egne nye rapporter i Power BI.
Datamodellen i en standardpakke indeholder som regel flere muligheder, end der er udnyttet i de rapporter, som pakken indeholder. Det betyder, at du (eller en konsulent) nemmere kan bygge videre på rapporterne, eller oprette nye rapporter – uden at skulle etablere en ny datamodel.
I en standardpakke er det egentlig mere datamodellen, som er “produktet” du skal betale for, end de rapporter der er inkluderet i pakken. Det er rapporterne, du visuelt oplever som “produktet”, men det er ikke svært at bygge rapporter i Power BI, når du har styr på designprincipperne, du lige har læst om. Det er datamodellen, arbejdet er lagt i.
Når du overvejer en standardpakke af rapporter til Power BI, så kig under motorhjelmen og spørg om datamodellens omfang.
Se eksempel på en standardpakke til Finans på abakion.dk/finans og prøv selv løsningen online.
EMNER DER ØGER KOMPLEKSITETEN
Nu har vi den simple løsning på plads. Og nu skal vi tale om en række emner, som potentielt øger kompleksiteten, og som kan skabe et behov for et ”rigtigt” Data Warehouse, et data-replikeringsværktøj og transformation af data for at gøre alt klar til visning i Power BI.
Nu taler vi først om alle de vigtige emner, og så beskriver vi bagefter ”den avancerede løsning” med et Data Warehouse.
Datamængder
Hvis du fx har 100.000 finansposter og gerne vil have data opdateret i Power BI en gang om dagen, så er den simple løsning perfekt. Det er ikke et kompliceret scenarie, og du kan næsten klare tingene på egen hånd.
Men det er en forudsætning for ”den simple løsning”, at datamængderne ikke bliver for store. Du kan ikke bede Power BI om at trække mange millioner finansposter direkte fra Business Central.
Man kan ikke sige entydigt, hvor grænsen for datamængden går, men jo flere poster, des større risiko er der for, at Power BI får datamængderne galt i halsen.
Power BIs interne datalagring er slet ikke et Data Warehouse, men det fungerer i praksis godt, og det har mange funktioner, men det er bygget til mindre datamængder, og der er en begrænsning i kapacitet.
Microsoft har sat en licensmæssig grænse for hvor meget data, der kan håndteres direkte i Power BI, og den grænse øges, hvis man køber et større abonnement, så det er ikke en teknisk grænse men en licensmæssig.
Men når vi taler om den simple løsning med direkte forbindelse til Business Central, så er det ikke den licensmæssige grænse, der er problemet. Grænsen er i skrivende stund 10gb, og med den simple løsning vil du opleve kapacitetsproblemer allerede under 1gb.
Men det er ikke nødvendigvis et problem, fordi mange af de brugsscenarier, vi vil anvende den simple løsning til, er langt under 1gb i størrelse.
Opdateringsfrekvens
Og hvis du har behov for hyppige dataopdateringer, så øger det også den samlede mængde af data, som skal flyttes.
Mange vælger én daglig opdatering, måske om natten så opdateringen ikke forstyrrer brugerne. Men det kan også være, at en ugentlig eller månedlig opdatering er nok til det konkrete behov. Alt det virker fint i den simple løsning.
Det er vigtigt at vide, at når Power BI opdaterer data, så sletter den alle de gamle data, som den har gemt i sit interne format, og så henter den en frisk kopi af det komplette datasæt fra Business Central.
Det tager lang tid at eksekvere. Og det er en af årsagerne til, at denne løsning er sårbar over for store datamængder.
Power BI risikerer at ramme en time-out, fordi den simple løsning er designet til mindre datamængder. Hvis et af systemerne slår en lille bøvs undervejs, så fejler den samlede opdatering, og så er der ikke friske data den dag.
I den almindelige Power BI, som hedder Power BI Pro, der kan man planlægge op til 8 opdateringer af data i døgnet, som man kan placere som man vil.
Nogle opdaterer data en gang i timen i løbet af 8 timers åbningstid, mens andre fordeler opdateringer over døgnet. Det fungerer fint med den simple løsning, så længe datamængderne ikke er for store til at Power BI kan nå at ekspedere det.
Med Power BI Premium kan man planlægge mange flere opdateringer, 48 i døgnet i skrivende stund. Så kan du opdatere data hver halve time døgnet rundt. Men det er stadig hele datasættet, der skal opdateres hver gang, så det skal ikke tage særlig mange minutter at udføre en opdatering – for det er ikke hensigtsmæssigt, at data-replikeringen kører hele tiden uden pauser.
Hvis du ønsker at få data opdateret hyppigt, fx en gang hver time eller hvert 15. minut, så skal Power BI nå at hente det komplette datasæt, inden den skal gentage hele manøvren igen om 15 minutter. Det er svært at få til at fungere godt i praksis, og det bliver for stor en opgave i den simple løsning.
Nu lyder det måske som om, at den simple løsning er problematisk, men det er slet ikke tilfældet. Den er god til rigtig mange formål. Du skal bare vide, at hvis du øger kompleksiteten eller datamængden, så rammer du på et tidspunkt loftet.
Transformation af data
Når du har behov for at transformere de data, som skal vises i Power BI, så står du i grænselandet mellem den simple løsning og den avancerede med et Data Warehouse.
Transformation af data handler om at foretage en behandling af data, uden for kildesystemet. Power BI kan sagtens håndtere nogen grad af transformation af data, men i komplekse scenarier er det en fordel at anvende et Data Warehouse.
Transformation kan fx være logik, som udleder en konklusion af de data, som er til rådighed, og beriger data med konklusionen.
Lad os tage et eksempel: Række 1 har en værdi på 53, og række 2 har en værdi på 87. Hvis logikken foreskriver, at over 60 klassificeres som ”høj”, og under 60 som ”lav”, så vil data blive beriget med, at række 1 er ”lav”, og række 2 er ”høj”. Den klassificering kan så anvendes i en Power BI-rapport, men klassificeringen ligger ikke i kildesystemet.
Det er et eksempel på data-transformation, og dette eksempel kan faktisk sagtens klares i den simple løsning, men der kunne også være tale om datavask, samkøring af data fra flere kilder, omformattering af data, beregning af nøgletal og meget mere.
Findes data overhovedet?
Du kan løbe ind i den udfordring, at din datakilde slet ikke understøtter den rapportering eller analyse, som du ønsker. Det kan være fordi data ligger i Excel eller i et ustruktureret format, eller at de ønskede data slet ikke findes i kildesystemet.
Hvis du fx vil analysere tendenser inden for langtidssygdom og korttidssygdom i Business Intelligence, men i dit tidregistreringssystem bliver sygdom ikke kategoriseret på en brugbar måde – så vil du være nødt til at ændre registreringspraksis, for at du har data til at udføre analysen.
Hvis du gerne vil analysere ‘perfect order fulfillment’, dvs. hvor stor en procentdel af kundeordrerne der er leveret perfekt med rette antal på rette tid, så mangler du måske også data i kildesystemet. Der er registreret en realiseret leveringsdato på ordren, men måske mangler du at registrere den oprindeligt aftalte leveringsdato. Og det er netop denne, der skal indgå i beregningen. Ordren indeholder måske også en erstatningsvare, men den vare, som kunden oprindeligt bestilte, er blevet slettet fra ordren. Det kræver både en ændring i registreringspraksis, men også en systemændring i kildesystemet, hvis du skal have data til din analyse i Business Intelligence.
På denne måde kan du opleve, at din Business Intelligence-strategi ikke kun handler om opsætning af Power BI, men at den også griber ind i din registreringspraksis, dine forretningsprocesser, og i kildesystemer som fx dit ERP-system.
Det er grunden til, at vi anbefaler, at du lægger en BI-strategi og kortlægger en projektportefølje, inden ERP-projektet eller andre store projekter om forretningssystemer begynder.
Historik
Historik er et spændende emne, for det afhænger af, om kildesystemet er opbygget med eller uden historik på det område, som du ønsker at analysere. Nogle gange er historikken indbygget i datakilden, og andre gange er det ikke.
Et eksempel kunne være tidsregistrering. Alle historiske tidsregistreringer ligger i kildesystemet, så hvis du ønsker at analysere en tendensudvikling af antal registrerede timer, så er den nødvendige historik tilgængelig i datakilden.
Men i samme eksempel kunne det være en udfordring, hvis du vil analysere udviklingen per afdeling. Medarbejderens tilhørsforhold til en afdeling er typisk registreret på medarbejderen og ikke på den enkelte tidsregistrering, så hvis en medarbejder skifter afdeling, så vil alle historiske tidsregistreringer også skifte afdeling, og det er jo ikke korrekt. I dette tilfælde er historikken ikke indbygget i datakilden.
Et andet eksempel kan være, at salgsledelsen vil gerne analysere udviklingen over tid i den vægtede pipeline i salgsafdelingen. En CRM-løsning kan sagtens vise den aktuelle vægtede pipeline, men der er typisk ikke nogen registrering af, hvad den vægtede pipeline var i går, og i forgårs osv. I dette tilfælde er der ingen historiske data.
Historik kan stille krav til systemændringer i kildesystemerne, og til ændrede registrerings-processer i din organisation.
Den bedste løsning er at indbygge historikken i kildesystemet, for det er der, data hører hjemme. Man kan også lægge et dagligt snapshot af data i et Data Warehouse, for på den måde at skabe historik, men det er en metode med nogle forbehold og forudsætninger, som vi gerne vil gå i detaljer med en anden gang, hvis du har lyst til at lægge øre til det.
Men lige nu skal du blot vide, at hvis du ønsker at analysere historik, så har du afgjort behov for et Data Warehouse, og du bør kortlægge dine rapporteringsbehov så tidligt i processen, at du kan nå at øve indflydelse på kildesystemet og registreringsprocesserne.
Mange datakilder
De fleste virksomheder har mange IT-systemer, og hvis man ønsker at rapportere på tværs af systemerne, så skal Business Intelligence-systemet være klar til at håndtere flere datakilder.
Ud over ERP, så har du måske IT-systemer til HR, salg (CRM), kundeservice, tidsregistrering, lagerstyring, kørende teknikere, osv.
Det kan fx være, at du gerne vil have en rapport, der sammenligner sidste års omsætning med dette års realiserede omsætning, igangværende arbejde, et salgsforecast og den aktuelle vægtede pipeline fra salgsafdelingen. Det kræver en samling af data fra ERP og CRM.
Den simple løsning med OData kan principielt godt anvendes, når der er flere datakilder. Men de rapporter og analyser, som du formentlig gerne vil have på tværs af datakilderne – de har sikkert en kompleksitet som gør et Data Warehouse relevant.
I eksemplet med data fra CRM og Business Central kan vi udtrække data fra Business Central med Data Replicator eller Data Factory, og i CRM-løsningen har Microsoft faktisk indbygget et tilsvarende værktøj, så det dataudtræk er relativt nemt at opsætte. Og de to datakilder skal samles i et Data Warehouse og transformeres til det datagrundlag, vi gerne vil have i rapporten i Power BI.
Hvis der ikke eksisterer et connector-værktøj til et bestemt kildesystem, så skal vi udvikle forbindelsen til kildesystemets API, så vi får de ønskede data overført til Data Warehouse i den rette frekvens. Det er en udvikleropgave, og det kan både være en stor eller en lille opgave, afhængigt af hvor godt dit kildesystem er forberedt til at udstille data.
Det er i et Data Warehouse, at vi samler data fra forskellige kilder og transformerer data. Når Power BI bagefter anvender Data Warehouse som kildesystem, så har Power BI ingen idé om, hvor mange kildesystemer der oprindeligt lå til grund for datasættet.
Sikkerhed
Sikkerhed er et vigtigt emne med mange aspekter.
Den interne sikkerhed, som er indbygget i kildesystemerne, skal naturligvis afspejles i Business Intelligence-rapporterne. Der kan være data, som kun må tilgås af bestemte medarbejdergrupper.
Et scenario kunne være, at medarbejderne kun må se deres egne tidsregistreringer, mellemlederne må se deres medarbejderes, HR-afdelingen må se alles, og ledelsen må se aggregerede tal.
På den måde har de fleste datasæt begrænsninger på, hvem der må se hvad.
Og så er der databeskyttelse, så man overholder GDPR. Det er vigtigt at have med i overvejelserne, men lige hvad angår ERP-data fra Business Central, så er der sjældent behov for at anvende personhenførbare data i rapportering. Og i så fald bør de data slet ikke gemmes i et Data Warehouse.
Vi anbefaler, at du får en GDPR-kyndig rådgiver til at vurdere din Business Intelligence, for det emne er din Business Central-konsulent og din Business Intelligence-konsulent som regel ikke juridisk ekspert i.
Inkrementelle opdateringer
Når datamængden i BI bliver større, eller når behovet for opdateringsfrekvens stiger, så er det værd at overveje ”inkrementelle” opdateringer af data.
”Inkrementel” betyder bare ”trinvis”, og inkrementelle opdateringer handler om, at data-replikeringen fra et kildesystem som Business Central til Data Warehouse kun behandler de data, som er ændret siden sidst. Det er ikke hele datasættet, der skal overføres hver gang – men kun “delta”, dvs. ændringerne.
Der er mange grunde til, at det er smart. Det belaster kildesystemet mindre, og det belaster BI-systemet mindre, og det forbedrer performance af begge dele. Og når replikeringen tager kortere tid, så kan opdateringerne planlægges med kortere mellemrum.
Og så er det færre data, der skal overføres, og hvis man anvender teknologi, der afregnes efter datamængder, som fx Microsofts Data Factory, så er der en ret stor prisforskel. Hvis man har store datamængder, så er det en markant prisforskel. Det er faktisk en af grundende til, at vi i Abakion har bygget værktøjet Data Replicator. Transaktionsafgifterne med Data Factory er alt for dyre i store projekter.
De fleste bliver overraskede over, hvor omfattende det reelt er at flytte data fra et kildesystem til et Data Warehouse.
Især hvis man skal opsætte nye integrationer til kildesystemers API’er, men også selv om det alt sammen er Microsoft-systemer. Det lyder enkelt at replikere data, men det er reelt omfattende.
Det er ikke særlig svært at koble Power BI sammen med Business Central, men hvis du har 5 regnskaber i Business Central, og du beder Power BI om at replikere alle data i Business Central en gang i timen, så går det hele i knæ. Inkrementel opdatering er et vigtigt emne, når opdateringsfrekvensen skal være høj.
Konsolidering af regnskaber
Mange virksomheder har flere regnskaber i Business Central, og når man gerne vil have Business Intelligence på tværs af alle regnskaber, så taler vi om konsoliderings-regnskaber og om eliminering.
For den udenforstående kan man sige, at konsolidering handler om, at man lægger flere selskabers data sammen til ét. Man samler alle aktiver, forpligtelser og andre finansielle poster. Så kan man i Business Intelligence se rapporteringen, som den ville se ud, hvis alle selskaberne var ét selskab.
Dette er slet ikke nogen svær opgave i Power BI – hvis blot udfordringen er løst i Business Central. Men det er den ikke altid, og derfor nævner vi emnet her.
Hvis selskaberne ikke har samme datastruktur, så er det ikke simpelt at lægge data sammen. Hvis kontoplanerne er helt forskellige, så skal de ‘mappes’ til hinanden, så data bliver sammenlignelige.
Hvis der er tilgodehavender og forpligtelser mellem selskaberne, så skal de elimineres. Det samme gælder intercompany-transaktioner, dvs hvis selskaberne har handlet med hinanden. At fjerne den slags data kalder man ‘eliminering’.
Nogle håndterer det via en Intercompany-app i Business Central, og dermed kan man sige, at elimineringen bliver forberedt i Business Central. Så kan du i Power BI vælge at se en rapport med data fra alle regnskaber, og så filtrere intercompany-posteringer fra. Men der er mange måder at løse det på, og der er mange niveauer af kompleksitet i behov.
Flere regnskaber kan i sig selv sagtens håndteres med den simple løsning, men den samlede vurdering af dine behov gør sikkert et Data Warehouse til en god idé.
Og så skal vi lige nævne, at kompleksiteten naturligvis bliver højere, hvis du har flere Business Central-konti, der skal konsolideres. Det kalder vi ‘tenants’ i IT-sprog. Det kan være, at du har 3 selskaber i én Business Central-konto, og et fjerde selskab i en separat Business Central-konto af sikkerhedsmæssige årsager.
Det er i Business Intelligence-forstand separate kildesystemer, selv om de begge to er Business Central.
DATA WAREHOUSE
Nu skal vi tale om Data Warehouse og replikering af data.
Når ambitionerne er for store til den simple løsning, så har du behov for en mellemstation mellem Business Central og Power BI, hvor data kan samles og transformeres. Den mellemstation kalder vi et Data Warehouse.
Med et Data Warehouse løser vi mange af de begrænsninger, som vi har talt om: opdateringsfrekvens, datamængder, antal selskaber, driftsikkerhed, transformationsmuligheder osv.
De værktøjer, som vi anvender til at replikere data fra Business Central over i et Data Warehouse kan meget mere, end når vi i den simple løsning kobler Power BI direkte til Business Central med OData. Vi kan nøjes med at overføre ændringer siden sidst og opsætte en historik af ændringer, som giver mulighed for at analysere ændringer og tendenser i Power BI.
Som koncept indeholder et Data Warehouse meget mere end blot et replika af dine Business Central-data, og et Data Warehouse kan have mange forskellige former.
Men for nemheds skyld bruger vi bare udtrykket Data Warehouse som en fællesbetegnelse for den database, der fungerer som mellemtrin mellem kildesystemerne og Power BI, hvor vi også har mulighed for at transformere data til de visualiseringer, vi gerne vil lave i Power BI.
Replikering af data
Til at replikere data fra Business Central over i et Data Warehouse anvender mange værktøjet Data Factory, som er en Microsoft Azure cloud service. Data Factory kan hive data ud af Business Central og en masse andre kildesystemer og skrive ind i staging-laget i Data Warehouse. Typisk har et Data Warehouse en to- eller tre-lags logik, hvilket afhænger af kompleksiteten af dine behov.
Data Factory er et godt værktøj, det er peg-og-klik, og det fungerer godt, men i nogle tilfælde bliver det ret dyrt at anvende. Jo flere Business Central-regnskaber – og jo højere frekvens data skal opdateres med – des højere bliver prisen.
Hvis du har 15 tabeller i 1 regnskab med opdatering 1 gang i døgnet, så har Data Factory en fornuftig pris. Men hvis du har 20 regnskaber med opdatering hvert kvarter, så stikker prisen på at bruge Data Factory helt af.
Mange virksomheder oplever, at Data Factory er billigt i begyndelsen, men bliver ret dyrt når ambitionsniveauet senere stiger.
Når det bliver dyrt, så anvender vi i Abakion i stedet Data Replicator, som er vores eget standardværktøj, som er langt billigere, når datamængderne stiger.
Data Replicator anvender en Microsoft Azure-funktion til at forespørge data i Business Central. En Azure-funktion er “atomet” i Azure, som er den billigste funktion, og samtidig forsimpler Data Replicator overførslen allerede i forespørgslen, fordi den kan udnytte, at den er bygget specifikt til at trække data ud af Business Central.
Hvis der skal overføres 50 tabeller, og der er 20 regnskaber, så er det 1000 reelle tabeller, der skal forespørges og overføres, og det konsoliderer Data Replicator allerede i forespørgslen, så overførslen bliver simplere, og data er bedre transformeret til Business Intelligence-behov.
Det er en afvejning, hvad der bedst kan betale sig. Hvis man specialbygger overførslen i Data Factory, så koster hver kørsel noget mere, og hvis man bruger Data Replicator, så er det i stedet på abonnement.
Du vokser ikke ud af Power BI
Power BI er præsentationsværktøjet, og det er afhængigt af, at data er klargjort tidligere i fødekæden.
Derfor er al transformation af data færdiggjort i Data Warehouse, og i Power BI konfigurerer man, hvilke relationer der er mellem data, og man opretter ‘measures’, som er nøgletal, der beregnes.
Nu er du godt oppe i størrelse og kompleksitet, fordi vi har gennemgået alle de emner, som øger kompleksiteten i din Business Intelligence-løsning. Du har en masse datakilder, og du har et Data Warehouse, som transformerer data og gør alt klar til Power BI.
Når du anvender et Data Warehouse, dvs Microsoft Fabric eller en SQL Server, så er det et langt mindre problem at indlæse hele datasættet i Power BI i hver opdatering. Forbindelsen mellem Power BI og databasen performer markant bedre end med den simple løsning med OData, så ofte er det slet ikke noget
problem at indlæse hele datasættet i Power BI hver gang, når du har Microsoft Fabric eller en SQL Server på banen.
Men hvis der fx ligger 100 millioner rækker af data i Data Warehouse, så vil det alligevel være ret omfattende at indlæse alle 100 millioner rækker i hver eneste opdatering.
Det performer bedre, hvis der kun overføres ændringer i data. Og den mulighed får du med en Data Warehouse-løsning. Det giver mulighed for at håndtere ret store datamængder, at vi kun overfører ændringer til Power BI.
Det er en løsning med stor kapacitet, og det betyder, at det i dag er svært at vokse ud af en Power BI-løsning, uanset hvor meget du hæver ambitionsniveauet.
AFRUNDING
Teknikken er et godt fundament, men i sig selv garanterer teknikken ikke, at din BI-løsning skaber reel værdi.
Det kan godt være, at du har en skarp datamodel og lynhurtige queries, men du har også brug for, at brugerne engagerer sig i løsningen.
For at få det fulde udbytte af en BI-løsning skal du forstå hvem brugerne er, hvordan deres arbejdsgange fungerer, og hvilke mål og strategier de arbejder efter.
Du har læst om change management, psykologi, forretningsprocesser, brugerflade, design, kognitive principper og ”adoption”. Alt det er mindst lige så vigtigt som teknologien.
Hvis ingen kigger på rapporterne, så skaber de ingen forandring. Og i sidste ende er det netop forandring, vi ønsker.
