Din rolle som BI-ansvarlig
Hvad er BI?
Vi er nødt til at begynde med et helt grundlæggende spørgsmål, som mange virksomheder desværre ikke har tænkt nok over: Hvad er Business Intelligence egentlig?
Det handler naturligvis om ”viden” (intelligence) i forbindelse med ”forretning” (business), så din rolle som ansvarlig for Business Intelligence handler om bedst muligt at skabe relevant viden hos dine kolleger. Vel at mærke, så det har en forretningsmæssig gevinst, og det bringer os frem til denne definition:
Business Intelligence (BI) handler om at anvende IT til at hjælpe medarbejdere med at opnå indsigt, så de kan træffe kloge beslutninger i virksomheden.
BI-løsningen skal reelt hjælpe mennesker med at kvalificere den viden, de har om forretningen. Som IT-system er Business Intelligence ikke værdifuldt i sig selv. Mange virksomheder begår den fejl at tro, at BI-løsningen er målet i sig selv. Det er et instrument, der kun skaber værdi, hvis det understøtter mennesker i at træffe bedre beslutninger.
Du er først en succes som BI-ansvarlig, når viden fra BI bliver anvendt i praksis af mennesker. Når data omsættes til brugbar indsigt og beslutninger, der forbedrer forretningen.
Derfor handler denne guide i langt højere grad om mennesker og forretning, end om teknik og IT-løsninger.
Hvad er en BI-ansvarlig?
Denne guide er skrevet til dig, der har kasketten som ”BI-ansvarlig”. Men hvad er en ”BI-ansvarlig” egentlig?
Det kan være, at du arbejder fuld tid med Business Intelligence i et job som fx:
- BI Developer
- BI Manager
- Data Analyst
- Business Intelligence Specialist
- Data Engineer
Men i de fleste virksomheder er rollen som BI-ansvarlig en ekstra kasket, som du har i dit job som fx:
- CFO
- Finance manager
- Financial controller
- Finance analyst
- Business analyst
- Business controller
- Sales operations
- Sales coordinator
- IT manager
Det er muligt, at det er en definition, vi selv har opfundet, men vi synes, at den BI-ansvarlige har to overordnede ben at stå på: det menneskelige og det tekniske.
- Det menneskelige handler om at sørge for, at BI-rapporterne bliver brugt og har effekt. Det har fokus på brugerdesign, menneskelig adfærd, rapportlayout og alt det, der handler om ”adoption” (at det bliver brugt).
- Det tekniske handler om at sørge for, at BI-løsningen er operationel. Det har fokus på data warehouse, integrationer, queries, dashboards og alt det andet IT-tekniske.
Det er forskelligt fra virksomhed til virksomhed, om den BI-ansvarlige har begge ansvarsområder, eller kun ét af dem. I større virksomheder er ansvarsområderne opdelt i endnu flere specialiserede roller.
Men der er desværre også mange virksomheder, hvor Business Intelligence handler alt for meget om teknik, og derfor handler den første sektion i denne guide specifikt om menneskedelen. For det skal vi sætte et større fokus på.
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 ærgerligt. Og hovedårsagen er, at BI-rapporterne ikke bliver designet til de mennesker, som skal bruge dem.
Det kommer til at handle rigtig meget om mennesker. For mennesker er på mange måder en flaskehals i forhold til at opnå succes med Business Intelligence. Mennesker lærer og forstår data forskelligt, og vores hukommelse har begrænsninger.
Derfor er en teknisk velfungerende BI-løsning ikke nok i sig selv. Der skal mere til for at få succes med BI. Der skal fokus på de mennesker, der skal bruge BI-løsningen.
Del 1: Det menneskelige aspekt af Business Intelligence
Alt for ofte bliver BI-løsningen ikke den succes, som virksomheden havde håbet på. BI-løsningen bliver sat i drift, men så sker der… ingenting.
Ingen bruger den, og den bliver i praksis overflødig. Det skyldes ikke tekniske fejl, men snarere menneskelig psykologi.
Der er et mønster i årsagerne. BI fejler ikke, fordi løsningen er forkert, men fordi den 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.
Din succes som BI-ansvarlig bør måles i hvor lidt tid brugerne kan slippe med at bruge på at opnå indsigt via BI-løsningen. Din opgave er at gøre brugernes arbejde nemmere.
Dine brugere er ikke ansat til at betjene BI-rapporter – de er bogholdere, sælgere, controllere, produktionsplanlæggere osv. Hvis de bruger for meget tid på at afkode dine BI-rapporter, så har du fejlet.
Business Intelligence skal smelte naturligt ind i deres daglige arbejde, så de kan bruge deres tid på at træffe beslutninger, ikke på at lede efter data. Store organisationer er typisk bedre til at lykkes med dette end mindre virksomheder.
Den bedste BI-løsning er ikke nødvendigvis den mest avancerede. Det er den mest brugervenlige.
Kend mennesker
Forstå hvordan mennesker tænker
For at forstå, hvorfor nogle BI-løsninger fejler, er det afgørende at se på, 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.
Når BI-rapporter fejler, er det ofte fordi de udelukkende er designet til System-2.
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 vi alle sammen 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 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æsenter 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 re-sultat? 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. På papiret 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 sidst siden, der er vigtig, så fremhæv den i stedet for 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 med opskrifter og gode råd til at designe en BI-rapport, som tager højde for System-1 og System-2. Det var kun en smagsprøve.
Men inden du går i gang med at designe BI-rapporten, så er du nødt til at kende og forstå dine brugere i detaljer. Det er en forudsætning.
Kend dine brugere
Den oversete disciplin
En af de mest afgørende, og ofte oversete, discipliner inden for Business Intelligence er ikke teknisk. Det er at forstå brugeren. Mange ser udelukkende BI som en data-disciplin, men i virkeligheden handler BI rigtig meget om at forstå brugerne.
Ideelt skal din rapport løse et eller flere konkrete problemer. Det betyder i praksis, at det er din fornemmeste opgave at gøre livet lettere for dine slutbrugere.
Og det er meget nemmere at lykkes med, hvis du forstår brugernes 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.
Og ved du hvad? Det gør også dit eget job mere interessant, at du forstår hvordan dit produkt skal bruges.
Her kommer en lille tre-trins-raket, du kan følge:
1. Forstå din bruger
Før du overhovedet åbner din BI-løsning, bør du spørge dig selv: Hvem skal bruge denne rapport?
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 mangler desværre i mange rapport-designs.
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.
Vi talte om en omsætningsrapport for lidt siden. Hvad skal brugerne anvende rapporten til? Er det 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 rapporten understøtter brugernes forretningsprocesser, så risikerer du at præsentere data, der kræver for meget mental energi eller simpelthen ikke er relevante 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 handler sjældent om at inkludere mest mulig data. Mange BI-brugere tror, at de har brug for at se mange tal, men ofte kan du som BI-ansvarlig hjælpe med at kortlægge, hvad der egentlig 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.
Du kender ikke alle behov
Som BI-ansvarlig kan du ikke forudsige alle de behov, dine brugere har. Du er nødt til at være i dialog med dem.
Brugerne kender forretningen, men de ved måske ikke, hvad der er muligt at udtrække af data. Omvendt, som BI-ansvarlig kender du data, men du har måske ikke indsigt i de forretningskritiske spørgsmål, der kræver svar.
Kun ved at kombinere de to perspektiver kan du skabe BI-løsninger, der ikke bare rapporterer data, men reelt skaber indsigt.
Det er også den sjove udfordring ved at være BI-ansvarlig: at lære mennesker og forretningen at kende.
Forhold dig kritisk til KPI’er
Når du designer BI-rapporter, så handler det ikke kun om at vise de KPI’er, som brugerne har bedt om. Det handler om at vise de ”rette” KPI’er, som kan gøre en forskel for brugerne i deres arbejde. Men det er jo et godt spørgsmål, hvilke KPI’er der er bedst.
Men du skal være opmærksom på, at de KPI’er, som du vælger, påvirker hvordan beslutninger bliver truffet. Sådan er det.
Og derfor bør du altid tænke over, hvilke KPI’er, der reelt skaber værdi. Det er ikke altid dem, brugerne beder om.
Et klassisk eksempel er omsætning. De fleste virksomheder måler på omsætning, og hvis du spørger en sælger eller en salgschef, hvad de vil se i deres rapporter, vil svaret næsten altid være: Omsætning.
Det lyder umiddelbart fornuftigt. Men som BI-ansvarlig er det din opgave ikke bare at tage svaret for pålydende, men at stille de kritiske spørgsmål, der sikrer, at tallene skaber reel indsigt.
Det kan lyde lidt selvmodsigende. På den ene side siger vi, at du skal lytte trofast til dine brugere, men på den anden side skal du ikke tage alt for gode varer. Men det behøver ikke at være i modsætning til hinanden.
BI skal tage udgangspunkt i processer, ikke data, og information om processerne finder du altid hos brugerne, men det er ikke sikkert, at brugerne er eksperter i data, så når det kommer til data og KPI’er, så skal du være kritisk indstillet. Du er nødt til at være både åben og kritisk.
De ved ikke, hvad de har brug for
Som BI-ansvarlig forventer du måske, at brugerne selv kan definere præcis, hvilke data og rapporter de har brug for. Det virker logisk, for de kender trods alt deres egen forretning bedst. Men i praksis fungerer det sjældent sådan.
Hvis du samler et helt team i et mødelokale og spørger, hvad de har brug for, så bliver der stille.
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. 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.
Du skal gribe det an på en anden måde. Du skal begynde med at kortlægge forretningsbehovet. Det er tre-trins-raketten igen:
- Forstå 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 brugeren skal træffe, og hvad der afgør, om en dag, uge eller måned er en succes for dem.
- Find data til forretningsbehovet: Først når du forstår brugernes arbejde og de beslutninger, de træffer, kan du finde de 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.
Min første fejl som BI-ansvarlig
Den klassiske begynderfejl i Business Intelligence er at tage en rapport med mange kolonner og gøre den otte gange så lang. Flere data, mere kompleksitet. Det tager en evighed at scrolle ned til bunden af rapporten, og det tager endnu længere tid at forstå noget af den.
Begynderfejlen er at tage udgangspunkt i data frem for brugeren. Du er nødt til at begynde med at overveje, hvordan rapporten vil hjælpe nogen i deres arbejde.
Det er egentlig lige meget, om du har en perfekt datamodel med perfekte ERP-data, og om du er god til at håndtere høj kompleksitet, og om dine queries kører lynhurtigt. Hvis din rapport ikke er designet til at formidle indsigt på en intuitiv måde, så fejler den.
Når en BI-rapport er intuitiv, så øger det sandsynligheden for, at brugerne faktisk bruger den. Og når de bruger BI mere, så træffer de bedre beslutninger. Og bedre beslutninger fører til en bedre forretning.
Design til dine brugeres psykologi
Psykologiske principper der forbedrer BI-design
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 farvekodning 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, desto 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 filtre-ringsmuligheder, 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 information lettere at forstå.
Inden for BI kan du bruge nogle af gestaltprincipperne til at overveje, hvordan du bedst visualiserer data, så du formidler det budskab, du gerne vil.
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 til sammen 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.
Du skal have styr på, hvordan mennesker opfatter visuelle elementer, når du designer en BI-rapport. For det giver dig mulighed for at hjælpe dine brugere med at forstå rapporten lettere.
Struktur for en BI-rapport
3, 30 og 300 sekunder
Nu skal vi snakke om et design-princip i Business Intelligence, der kaldes 3-30-300-reglen. 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).
3-30-300-reglen kan hjælpe dig med at designe en rapport, som opfylder brugernes behov, men det forudsætter naturligvis, at du på forhånd har styr på den tre-trins-raket, som vi talte om tidligere:
- Forstå din bruger
- Hvilke beslutninger skal brugerne træffe?
- Hvilke data er nødvendige?
Denne viden er en forudsætning for at designe din rapport, som skal have følgende 3 niveauer:
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å aller-vigtigste 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 Microsoft, 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 fra bunden
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 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.
Teknik
Og først nu bygger du din BI-rapport.
Nu har du brug for at få data fra ERP og andre kilder ind i Power BI. Det er der teknisk kyndige BI-folk, der er gode til. Og de skal på banen her.
Det skal vi tale meget mere om i næste sektion af denne artikel, men først skal vi tale om forandringsledelse: dvs at få brugerne til at anvende BI-rapporten.
Få BI-rapporten i brug
Fjern friktion
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 i de kommende afsnit med på en mission for at fjerne alle former for friktion.
Manglende ”adoption” er faktisk 2 problemer i en træls forening:
1. Ingen har lyst til at finde din rapport
Er det nemt at komme ind i din rapport?
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).
Du skal flytte truget hen foran snuden på hesten. Det kommer vi med nogle gode forslag til om lidt.
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.
2. Ingen har lyst til at lære på forhånd
Er det intuitivt at bruge din rapport? Eller kræver det oplæring?
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 Power BI. 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.
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).
Undervis og find en ambassadør
Men selv om din BI-rapport er supersimpel og letforståelig, så er det stadig ikke sikkert, at dine kolleger finder vej ind i rapporten. ”Adoption” kræver, at du ændrer deres vaner, og vaner er svære at bryde.
1. 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.
2. 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. Vedkommende kan endda ende med at yde første-linje-support til brugerne, hvis alt går godt.
3. 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.
Og lad os nu skille skarpt på, hvilke muligheder du har for at fjerne endnu mere friktion, så brugerne har nemt ved at bruge din BI-rapport i hverdagen.
Direkte adgang til indsigt
Du skal sørge for at udgive din BI-rapport som en ”app”. Og når vi siger ”app”, så tænker vi hverken på en app på din mobiltelefon eller sådan en fra Microsoft AppSource. Ordet ”app” bliver anvendt til rigtig meget, og i Power BI er en ”app” en brugergrænseflade, som er designet udelukkende til slutbrugerne.
Hvis man bare åbner app.powerbi.com for at finde sin rapport, så får man adgang til alle muligheder, workspaces, datakilder og alt muligt. Og hvis man er udvikler, så er det herligt, men hvis man er slutbruger, så skaber det friktion, og System-2 kommer på overarbejde, og det mindsker sandsynligheden for, at rapporten bliver brugt. Den oplevelse skal du undgå.
Hvis du udgiver rapporten i en ”app”, så vil brugeren have et link til en brugergrænseflade, som er målrettet til slutbrugeren. Der er ikke nogen unødvendige valgmuligheder, ingen bøvl med rettigheder til underliggende arbejdsområder. Der er bare direkte adgang til indsigt.
Som BI-ansvarlig kan du tilrettelægge, at der i en app er præcis de ting, som dine brugere skal anvende, og ikke spor andet. Det gør en virkelig stor forskel for brugernes oplevelse.
Og samtidig tillader det dig at versionsstyre rapporten, så du kan videreudvikle på rapporten i kulisserne, og så udgive en ny version af app’en med rapporten til brugerne, når du har testet og alt er klar.
Direkte adgang hvor brugerne allerede er
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. Det er det med truget, der skal hen foran snuden på hesten.
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.
Let at bruge på en mobiltelefon
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 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.
Men den generelle pointe er, at du skal beslutte på forhånd, om din rapport skal have et mobil-layout, for det skal du tage højde for i designet.
Dine UX-venner i Marketing
Måske har du nogle venner i Marketingafdelingen, som kan hjælpe dig med at designe til brugernes psykologi.
Hvis der er UX-kyndige medarbejdere i Marketingafdelingen, så kan du med fordel alliere dig med dem, når du designer din BI-rapport. Marketingfolk arbejder dagligt med brugeroplevelse (UX) på websites og mobilapplikationer, og de ved, hvad der skal til for at gøre en brugergrænseflade intuitiv og let at navigere i.
Selvom de måske ikke kender særlig meget til Power BI, så kan de hurtigt identificere uhensigtsmæssige designvalg, fx overdreven scrolling eller visuelle elementer, der gør det sværere for brugeren at forstå rapporten. Brug deres erfaring til at sikre, at BI-rapporten ikke bare er funktionel, men også brugervenlig.
Du bør gå langt for at få din BI-rapport til at ligne et brugervenligt website og ikke en Power BI-rapport.
Marketingafdelingen har helt sikkert en række grafiske assets, som fx din virksomheds logoer, farvekoder og designguidelines. Du skal sørge for at anvende virksomhedens visuelle identitet i BI-rapporterne, for det giver nogle gode fordele:
Brugerens System-1 genkender velkendte farver og elementer intuitivt, og det gør rapporten lettere at afkode. Der er simpelthen mindre friktion ved første øjekast, når designet er velkendt. Du kan med fordel orientere dig efter navigationen og formsproget fra din virksomheds website.
Rapporten fremstår faktisk også mere gennemarbejdet og professionel, når man kan se, at du har brugt energi på at få den til at passe ind i virksomhedens generelle udseende. Og når alle BI-rapporter har samme layout, så virker det meget enklere at bruge mange rapporter.
Du kan lave en skabelon i Powerpoint, som du anvende til hver ny BI-rapport. På den måde sparer du tid, og du reducerer også mængden af elementer, som Power BI skal genindlæse i rapporten.
Abonnement på viden
En anden måde at fjerne friktion på, det er at anvende abonnementer på ”dashboards” i Power BI.
Et ”dashboard” og en ”rapport” er to forskellige ting i Power BI. Med et dashboard tager man elementer fra forskellige rapporter og tilføjer dem til dashboardet. Og så kan man oprette et abonnement på et dashboard, så man periodisk modtager en e-mail med et snapshot fra Power BI.
E-mailnotifikationer kan også være den primære måde organisationen interagerer med Power BI på. I stedet for at åbne Power BI, så kan medarbejderne modtage faste daglige og ugentlige e-mails med de vigtigste indsigter.
Hver morgen kan de salgsansvarlige modtage en e-mail med et snapshot af et dashboard, der 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 folk alligevel tjekker deres e-mail hver morgen. Det bliver en naturlig del af den daglige samtale, fordi alle modtager den samme information om morgenen, og det skaber en fælles referenceramme.
En gang om ugen kan en detaljeret rapport blive sendt til de ansvarlige ledere. Overblik over ugens samlede resultater og tendenser over tid. Så er alle forberedt til det næste ledermåde ud fra de samme data.
Power BI kan på den måde understøtte forretningsprocesser, hvor rapporter ikke bare er passiv information, men en aktiv del af beslutningstagningen. Endda uden at nogen åbner Power BI-applikationen.
Man skal dog være opmærksom på, at funktionaliteten afhænger af, hvilken type licens man har. Med en Power BI Pro-licens skal man vedligeholde individuelle dashboards, men med Fabric er der nogle meget fleksible værktøjer med dynamiske abonnementer, hvor en enkelt rapport kan filtreres automatisk, så hver bruger kun ser det relevante indhold.
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.
Igen skal du se på forskellene mellem licenser. I Fabric findes en funktion, der hedder Data Activator, som giver dig mulighed for at opsætte dynamiske regler, og det er et virkelig stærkt værktøj, hvis du vil arbejde med alarmer og adviseringer.
Hvis du fx har et termometer i et kølerum, så kan du koble det til Fabric 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å omsætningen, og når afdelingen har nået månedens budget, så modtager alle en Teams-besked med informationen.
Der er rigtig mange anvendelsesmuligheder, og du skal tænke over, hvordan du kan udnytte funktionen, for det fjerner friktionen og bringer Business Intelligence derhen hvor brugerne befinder sig.
Afrunding af første del
At have en stærk teknologisk løsning er en nødvendig men ikke en tilstrækkelig betingelse for succes. Det kan godt være, at du har en skarp datamodel og lynhurtige queries, og alt det er et godt fundament, men i sig selv garanterer det ikke, at din BI-løsning skaber reel værdi.
Selv den bedste datamodel vil ikke gøre en forskel, hvis brugerne ikke engagerer sig i løsningen. Hvis du tror, at målet er nået, så snart en teknisk avanceret BI-løsning er implementeret, så overser du en afgørende faktor: de mennesker, der skal bruge den.
For at få det fulde udbytte af en BI-løsning skal du forstå hvem brugerne er, hvordan deres organisation fungerer, og hvilke mål og strategier de arbejder efter.
Alt det handler egentlig ikke om Power BI-løsningen. Det handler om change management, psykologi og forretningsprocesser.
Alle de overvejelser, vi har gennemgået omkring brugerflade, design, kognitive principper og ”adoption”, er mindst lige så vigtige som selve teknologien.
Hvis ingen kigger på rapporterne, skaber de ingen forandring. Og i sidste ende er det netop forandring, vi ønsker.
Det var den første del om mennesker. Nu skal vi tale om teknik.
Del 2: Det tekniske aspekt af Business Intelligence
Her i del 2 af artiklen vil vi hjælpe dig med at lægge en solid plan for at bygge Business Intelligence med Power BI oven på din Microsoft Dynamics 365 Business Central.
Business Intelligence handler naturligvis ikke kun om ERP-data, men det er det konkrete scenarie, som vi gerne vil belyse her. Så det giver bedst mening, hvis du er en lille eller mellemstor virksomhed, der bruger (eller er på vej på) Business Central.
Du kan også læse mere om Power BI på Microsofts website eller her på siden, eller se Microsofts videoer på youtube.
Vores mål er at skabe en teknisk Business Intelligence-strategi, som løser dine aktuelle behov i dag med en overkommelig indsats – men som også er noget, du kan vokse i.
Og så er det gode spørgsmål:
Hvilke valg skal du træffe for at komme nemt i mål nu – men samtidig være parat til forandringer og vækst i fremtiden?
Lad os begynde med at definere to vigtige udtryk:
Rapportering – med et IT-udtryk kalder vi det Business Intelligence, og forkorter det til BI. Men det betyder egentlig blot, at vi vil anvende data til at skabe den rette indsigt for de rette personer på det rette tidspunkt.
Vi vil skabe mulighed for at betragte data fra mange forskellige vinkler og modulere data, så vi får en større indsigt og kan træffe klogere beslutninger.
Strategi for rapportering favner ret bredt. En Business Intelligence-strategi er ikke kun for Microsoft Power BI-løsningen.
En strategi skal favne både kildesystemerne som fx Business Central – og det værktøj man vil visualisere det i, som fx Power BI.
Strategien handler både om, hvordan man ønsker at rapportere på sine ERP-data, men også hvordan man ønsker at bruge andre data i virksomheden.
Rapportering kan både være en simpel eller en omfattende opgave.
Nogle gange er det ikke særlig svært. En simpel rapport eller oversigt med ERP-data kan skabe rigtig stor værdi. Andre gange er ambitionsniveauet større, og ERP-data kan blive ganske komplekse. Og der kan være flere datakilder end blot Business Central, og det øger også kompleksiteten.
Men hvis du gerne bare vil i gang, skal du så købe en rapportpakke, som er klar til brug, eller skal du bygge dine egne rapporter?
Skal du nøjes med at løse aktuelle behov, selv om det kan sætte begrænsninger for fremtidige behov?
Det er nogle af de spørgsmål, vi skal besvare nu.
Kortlægning af behov
Mange virksomheder oplever, at data er svære at overskue og analysere direkte i forretningssystemet, og så udarbejder de ad-hoc analyser i Excel, hvilket er tidskrævende, ofte fejlbehæftet og afhængigt af enkeltpersoner. Og derfor ønsker de sig en Business Intelligence-løsning til at gøre det nemmere at opnå indsigt.
Hvis rejsen begynder med et rapporteringsbehov på ét område, så bliver det en nålestiks-operation, og det kan være helt okay, men hvis du har for mange isolerede nålestiks-operationer, så bliver det kompliceret at vedligeholde.
Vi vil anbefale, at du begynder rejsen med at skabe overblik over din virksomheds rapporteringsbehov.
Du skal kende målgrupperne for rapportering i virksomheden, og du skal vide hvilke forretningsprocesser, du ønsker at rapportere på.
Projektportefølje
Det kan du opgøre i 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, ressourcestyring, distribution, HR, projektstyring, booking, point-of-sale osv.
Så taler du med hver målgruppe om deres rapporteringsbehov og noterer, hvilke procesområder og datakilder der skal i spil for at understøtte deres behov.
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 målgrupper og rapporteringsbehov først.
Du kan sagtens begynde med en nålestiks-operation, der giver hurtig gevinst, men når du har overblik over hele porteføljen, så kan du sørge for, at alle tiltag passer ind i den samlede plan.
IT-infrastruktur
Din næste overvejelse vil være, hvilken IT-infrastruktur du vælger til dit Business Intelligence-projekt. Vi kommer til at gennemgå alle muligheder om lidt..
Hvis du ikke kigger længere frem end den første nålestiks-operation, så er IT-infrastrukturen ganske simpel, men hvis du ønsker en IT-infrastruktur, som kan understøtte en ambitiøs projektportefølje, så bliver det måske mere komplekst.
Det vigtige er at vide, hvor langt dine valg vil række, og hvornår du vil støde hovedet mod loftet.
Vi er store tilhængere af at begynde simpelt og tilføje kompleksitet senere, men du skal naturligvis vide, hvilke begrænsninger det har at begynde simpelt, og hvornår du er nødt til at tage teknologiske spring, når du øger ambitionsniveauet senere.
Projektplanlægning
Det er helt okay, hvis du planlægger 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 Business Central, 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 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 Business Central-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 tager 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 er fin som den er.
Vi oplever rigtig mange virksomheder, der bare bruger standard-rapportpakker som de er. Og vi oplever sjældent, at virksomheder vokser helt ud af rapportpakkerne.
Vi anbefaler klart, at du begynder simpelt, så du kan komme hurtigere i gang med at indsamle erfaring.
Hvad består business intelligence af?
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.
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 integration til data.
Business Central er født med teknologi, der kan udstille data til dette formål. Det kalder teknikeren 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.
Sammensætning af data for et BI-værktøj er nødt til at være lidt anderledes end for en ERP-løsning, og derfor er det nødvendigt at kopiere data over i en anden database.
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 den database, hvor data replikeres over i.
I 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 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. Den koster et abonnement, men det er til gengæld leverandøren, som er ansvarlig for at vedligeholde den.
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. 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 rigtig 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 virkelig 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 en masse 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.
Power BI kan godt foretage transformationen af data. Der er ikke helt så mange muligheder som i et rigtigt Data Warehouse, men Power BI kan godt gøre data klar til brug, og man kan også foretage beregninger på data.
Der er dog en begrænsning i den kapacitet, som Power BI har til at foretage transformationer og beregninger internt i Power BI. Power BIs transformationer fungerer rigtig godt, men det er et værktøj, der er bygget til mindre datamængder.
Hvis der skal foretages mange eller avancerede transformationer, så skal der som hovedregel et Data Warehouse på banen.
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 ører 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 afspejle 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 til BI bliver større, eller når behov 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 opdaterering 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 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 SQL Server 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 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 SQL Server-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.
Microsoft Fabric
Her til sidst skal vi nævne, at du skal lære at kende det nye navn for alle Microsofts aktiviteter inden for Business Intelligence, som er “Microsoft Fabric”.
Man kan påstå, at Microsoft Fabric er alle de kendte værktøjer i en ny struktur.
Men den nye tilgang i Microsoft Fabric kommer til at give mange spændende muligheder fremover. Alle data kan placeres i en “data lake”. Og alle Business Intelligence-værktøjerne bliver koblet på den “data lake”.
Indtil nu har alle systemer og værktøjer haft sit eget proprietære storage-format at gemme data i. Derfor flytter vi data for at have dem tilgængelige i de formater, som vores systemer har behov for. Det vil Microsoft Fabric gøre op med.
Data skal ligge i en “data lake”, og det storage-format kan anvendes i Power BI, Excel og alle mulige værktøjer. Microsoft har modificeret Power BI til at kunne anvende det nye storage-format som sit interne format, og de har lavet en version af SQL Server, som anvender det nye storage-format.
På den måde vil Microsoft skabe et nyt dataformat, som alle analytiske IT-systemer kan anvende, så vi principielt ikke behøver at flytte data frem og tilbage.
Det er en rigtig god vision, som bliver mere og mere interessant med tiden, uden at det nødvendigvis ændrer meget på alt det, vi har talt om i denne artikel.
Nu har du været igennem hele strategirejsen om Business Intelligence. Du har hørt om en simpel løsning og en avanceret løsning for Business Intelligence til dine ERP-data fra Business Central, og vi har gennemgået de spørgsmål, som typisk afgør hvor stort et Business Intelligence-setup, du har behov for.
Nu er du klar til at lægge en god plan, der kan føres ud i livet. Og hvis du har spørgsmål undervejs på rejsen, så er du meget velkommen til at spørge os til råds. Vi er klar til at hjælpe.
Hvis du undervejs får behov for en Power BI-pakkeløsning, så finder du vores udvalg her: abakion.dk/power-bi
Med denne guide er du forhåbentlig blevet klogere på din rolle som BI-ansvarlig og har fået en masse inspiration.
På internettet er det blevet nemmere at finde information både om Power BI og om brugerdesign. Vi håber også, at vi i Abakion kan bidrage. På abakion.dk/viden/#bi kan du finde nyheder og gode tips om Microsofts forretningsløsninger.
Og så gør vi også hvad vi kan for at yde de services, som vi synes er nødvendige for en BI-ansvarlig. Læs fx om pakkeløsninger på abakion.dk/power-bi eller find denne guide i mange formater på abakion.dk/power-bi/bi-ansvarlig
Skriv til os på abakion@abakion.com hvis du har spørgsmål. Vi vil meget gerne hjælpe.
E‑bog
PDF
Trykt
Lyd