Tilbage

Det evigt sløve Business Intelligence team

Hvordan kan man konkurrere mod en self service-kultur, hvor data i Excel-ark og Power BI lever i bedste velgående, mens Business Intelligence-teamet (BI) er underlagt tunge ITIL-lignende processer, styregrupper, change boards og andet godtfolk? Og skal man overhovedet konkurrere eller blot huske dette, inden der peges fingre.

Den anden dag var jeg ude at spise med en kammerat, som frækt stillede mig det spørgsmål, hvorfor det var, at BI-afdelingen i den virksomhed han arbejder for (han kunne i princippet have arbejdet i hvilken som helst virksomhed med et BI-team) altid var så længe om at levere de nøgletal og data, som de havde brug for til deres analyser. Han havde med andre ord brug for at vide, hvad de lavede og brugte al den tid på.

Samtidig kunne han så fortælle, at alle controllerne og dataanalytikerne spyttede den ene nye rapport ud efter den anden i en hast, der ikke tidligere var set i virksomheden, hvilket underbyggede hans pointe om det langsomme BI-team. Jeg kunne ikke umiddelbart svare på, hvorfor netop dette BI-team var så langsomme, men jeg prøvede alligevel at kaste mig ud i en redegørelse, som måske kunne underbygge hans påstand.

Andre arbejdsbetingelser i BI-teamet

Vi parkerer alt omkring arbejdsmoral, motivationsfaktorer, engagement, værdisnak, ”the why”, nye metoder til at anskue BI på, ejersskab og alt i denne boldgade for en stund.

Min hypotese er, at de personer der sidder i BI-teamet uden sammenligning er de dygtigste og mest effektive databehandlere, der arbejder i den pågældende virksomhed. Samtidig er der dog ingen tvivl om, at BI-teamet kan arbejde hurtigere og jeg stiller heller ikke spørgsmålstegn ved, at teamet helt sikkert kan løfte deres kompetencer til et højere niveau.

Dog er jeg dog overbevist om, at det BI-team han refererede til som værende langsomme, er underlagt nogle helt andre præmisser, end de controllere, dataanalytikere og ”ad hoc-statistikmagere” der sidder ude i organisationen.

Så hvad er de andre præmisser, og bør der overhovedet være de forskelle? Jeg prøvede med et eksempel på, hvordan det langsomme BI-team formentlig arbejder sammenlignet med de lynhurtige databehandlere:

Scenarie 1 – det sløve Business Intelligence team (dermed ikke sagt, at det behøver være virkeligheden)

BI-teamet skal levere en ny rapport til CEO’en med et nyt nøgletal for 2018. Så hvad er processen for at finde frem til dette ene nøgletal? Det kunne være noget a la dette:

En projektleder modtager en ”ordre” fra øverste ledelse omkring det nye KPI og går i gang med at indsamle krav fra forretningen. Projektlederen kører på den helt store klinge den dag og ruller arsenalet af Concept Mapping teknikker og hele pivtøjet for at sikre, at forretningens krav bliver indsamlet korrekt. Forretningen skal blive enige med sig selv om, hvordan dette nye nøgletal skal beregnes - og det kan godt tage lidt tid ifølge min erfaring. Det kræver minimum 2-3 møder for forretningen at nå til enighed, for der er jo forskel på gennemsnit, vægtet gennemsnit, medianer, summer etc. Herefter skal virksomhedens GDPR-ansvarlige på banen for at vurdere GDPR-perspektivet for de data, der skal udstilles og opbevares i Data Warehouset - hvad er jeres process for anonymisering af data?

Det nye nøgletal skal beskrives i et tre siders langt KPI use case-dokument. KPI use case-dokumentet afleveres til BI-teamet, som prioriterer dette højt, da 2018 jo er i gang, så det skal jo leveres hurtigst muligt. BI-teamet mødes med en dataarkitekt, som peger BI-teamet i retning af, hvilke datakilder, der ligger til grund for KPI’et. Herefter arrangeres møder med eksperterne, der har kendskab til de datakilder, der skal benyttes, og datakilderne til KPI’et gennemgås og dokumenteres… måske.

Nu er alt på plads, og det er tid til at gå i gang med udviklingen. Der køres med korte sprints, opgavestyring, tekniske designdokumenter, der lige reviewes af BI-teamets arkitekt samt morgen-scrummøder, hvor alting lige skal koordineres. Der laves aftaler med kildesystemejerne, så de er informeret omkring, hvornår der fremover kopieres data fra kildesystemet til Data Warehouset.

Samtidig ved kildesystemejerne nu, hvilke tabeller og databaser der benyttes, så hvis databaser skal ændres i fremtiden, kan de give BI-teamet besked (kører man den helt dyre model, ja så udstiller BI-teamet i en rapport, hvilke datakilder, tabeller og kolonner der benyttes, så kildesystemejerne til enhver tid kan se, hvilke afhængigheder Data Warehouset har til de respektive kilder).

Med alt på plads går udviklingen forholdsvis hurtigt. I BI teamet har man nemlig automatiseret nogle af de manuelle ETL processer (eks. BIML eller ezAPI) - "man vil jo nødig være den sløveste kniv i skuffen". Dog er det langt fra sikkert, at ETL processen er blevet automatiseret - "det tager jo tid at komme til at arbejde smartere". Data denormaliseres efter alle kunstens regler, og Data Warehouse-delen kommer hurtigt på plads, og det er tid til, at front end-delen skal bygges. I organisationen skal alle data være tilgængelige i kuberne, som kan tilgås via Excel. Ydermere skal KPI’et integreres i 2018 scorecardet/dashboardet – og her skal farverne spille, men det har kommunikationsafdelingen styr på – organisationens corporate color farvepalette kan jo findes på intranettet... et sted …, hvis man lige finder det eller ved, hvor der skal ledes - mere realistisk er det, at teamet via virksomhedens hjemmeside forsøger at identificere organisationens ”corporate colors”. Den nøjagtige farvekode identificeres vha. Paint (Gud forbyde dem der har besluttet at fjerne Paint fra kommende Windows-versioner, så skal man jo kunne finde farverne på intranettet). Fordi BI-udvikleren går op i at fortælle den gode historie med data

if you take this action, you can expect this result, here is the data that explains why…

og gøre det nemt for slutbrugeren at forstå og arbejde med tallene, så tager denne process lidt tid.Inden de nye ændringer sendes til test, foretages der et hurtigt peer-review for at sikre, at best practice mm. er overholdt. I opgavestyringssystemet opdateres status, og den BI-ansvarlige har det komplette overblik over alle igangværende BI-opgaver i teamet.

Herefter sendes ændringerne vedrørende det nye KPI til test i forretningen. Foruden test i forretningen, køres der på testmiljøet automatisk nogle unit- og integrationstests, der skal sikre validiteten i de nye data, samt at det eksisterende setup fortsat spiller.

I den forretningsmæssige test af KPI’et skal der nu fem personer i organisation på banen for at godkende det data, som nu findes i testmiljøet, før det bliver flyttet til produktion. Der skal der udføres manuelle function tests, usability tests, data transformation-tests og sikkerhedstests, da det er vigtigt, at alt fungerer som det skal, og at data er pålidelige. Der opsættes et ugentligt UAT-møde for at sikre fremdrift på testene – der går dog lidt tid inden de fem nævnt ovenfor, prioriterer at validere KPI’et og får underskrevet sign off-dokumentet – de har jo også andre ting at lave rundt omkring i forretningen.

Efter endt test flyttes KPI’et til produktionsmiljøet, men pga. organisationens ITIL- og governance-processer, samt den freeze-periode man pt. kører pga. årsafslutning, er næste mulighed for at få idriftssat det nye KPI om to måneder. Der er dog mulighed for at ansøge om at omgå den aktuelle freeze-periode. Dette skal dog godkendes af både ITIL-ansvarlige, dataarkitekten og CFO’en.

Efter en rum tid lykkes det at komme uden om freeze-perioden og få idriftsat det nye KPI. BI-udvikleren krydser fingre for, at alt hvad der skulle idriftsættes er flyttet til produktion. Det er ikke 100% sikkert, fordi noterne omkring deployment formentligt ligger i OneNote eller Notepad på skrivebordet. Men mon ikke alt er kommet med – det plejer det jo.

KPI’et er nu tilgængeligt i dashboardet, som er integreret på virksomhedens intranet. Dokumentationen af løsningen kan ligeledes findes på virksomhedens intranet.

Hver fredag gennemgår BI-teamet deres monitoreringsrapport ("fredagsrapporten"), der viser potentielle fremtidige ”performance-flaskehalse” i produktionsmiljøet. Det gennemgås, hvor mange brugere der har brugt de forskellige dashboards og kuber, og datakvalitetsrapporten afslører potentielle problemer med data. Ydermere gennemgås, hvilke dashboards der måtte performe dårligt og dermed resulterer i en forringet brugeroplevelse. I samarbejde med IT-afdelingen sikres det, at der tages en daglig back-up af data. Alt i alt har teamet godt styr på deres løsning, men det bruger de altså lidt tid på det hver fredag.

Scenarie 2 – den lynhurtige controller

Controlleren har brug for omsætningstal fra ERP-systemet Navision til en hurtig rapport. Dataene findes i Data Warehouset, men fordi controlleren allerede har et Excel-ark, der henter data direkte ud af Navision og endda i real-tid (hvabehar kaffebar - kan I måske klare det i BI-teamet...), bruges dette. Excel-arket eksisterede før dataene kom i Data Warehouset, så hvorfor bruge Data Warehouset som kilde; "Så skal jeg jo til at finde ud af, hvad det er jeg har lavet i mit Excel-ark". Rapporten laves i samme Excel-ark, som også henter data ud fra kildesystemet, hvor der måske også er lavet en fræk makro, og alt er klar efter en times arbejde.

Excel-arket distribueres nu rundt i organisationen uden større polemik via diverse e-mails, intranet og fælles filsystemer - dog er der ingen, der kan forklare den frække makro, som får det hele til at hænge sammen, men der er jo en ”9 trins-guide” vedhæftet, så det er ingen sag at få opdateret alle data, så det går nok. For hver gang dette Excel-ark opdateres af alle de kollegaer, der er begyndt at bruge arket i deres dagligdag, lægges der nu et enormt performancepres på kildesystemet, som kildeejerne nu skal slås med; ”Måske vi skal have et nyt ERP-system, vores nuværende performer ikke særlig godt”.

Controlleren overvejer ikke at bruge Data Warehouset fremover, derimod er der kommet et nyt fedt BI-værktøj, der hedder Power BI, så controlleren nu kan hente endnu flere og større mængder data direkte ud af kildesystemerne. Det er fantastisk og nemt at arbejde med "og så behøver jeg ikke stå i kø nede på BI-kontoret". Glem alt om moderne ”5 days to launch-programmer”, her skal vi maksimalt bruge et par timer, så er der styr på sagerne.

Pointen skåret ud i pap

I begge scenarier leveres der en rapport med et KPI. I scenarie 1 har vi med et KPI at gøre, som er fuldstændig valideret - såvel datamæssigt som forretningsmæssigt og er klar til, at CEO’en i organisationen kan træffe vigtige beslutninger for fremtiden med baggrund i dette. Her taler vi ”one truth” (altså indtil man begynder at slice/dice og filtrere i data).

I det andet scenarie har vi ikke den fjerneste idé om, hvorvidt data i rapporten er troværdige. Vores kildesystem bliver formentlig belastet hver gang, data opdateres i Excel-arket (husk på, der sidder ikke kun en person i organisationen og laver dette nummer). Der er ikke styr på, hvordan Excel-arket kommer til at leve i organisationen, og hvilke beslutninger der bliver truffet med baggrund i det.

Men det blev leveret hurtigt. Betragteligt hurtigere end af vores kammerater i BI-teamet.

Tilbage til pointen hvis du ikke allerede har regnet den ud. Umiddelbart så kunne det godt se ud som om, at vores venner i BI-teamet er nogle sløve bananer, og det kan ikke afvises, at der er noget om snakken, men det er ikke udelukkende BI-teamets skyld. BI-teamet opererer som nævnt under nogle helt andre præmisser, når det gælder Corporate BI, end når det gælder resten af organisationen.

Så snart det ikke gælder Coporate BI, kan BI-teamet dog overveje at ændre disse præmisser; for skal alting altid i Data Warehouset og ligge pænt og nydeligt? Ikke nødvendigvis, men det er en anden snak omkring, hvordan man bør orkestrere et moderne BI-setup, hvor hurtige ad hoc-løsninger kan leve (for en stund), hvor self-service bliver mere og mere udbredt etc.

Så måske er de ikke så sløve trods alt, men scenarie 2 er svært at konkurrere med. Og når det nu skal være så sløvt at få data igennem BI-teamet, så vælg data med omhu. Vælg det data, der flytter noget i forretningen. Vælg det data, der understøtter virksomhedens strategi.

Der er ikke nødvendigvis noget rigtig eller forkert i de to scenarier. Som slutbruger får man dog med sikkerhed to vidt forskellige ”varer”, som måske passer rigtig godt til de formål og analyser, de skal understøtte. Begge scenarier er blot virkeligheden i mange organisationer.

Hjælp jer selv ved at markedsføre jeres løsninger!

I stedet for at konkurrere ligger der en stor kommunikations- og forankringsopgave i at få markedsført BI-teamets processer og løsninger, så BI-teamets løsninger bliver brugt og små ”satellit-/Excel-databaser” ikke opstår rundt omkring i organisationen indeholdende samme data som BI-løsningen.

Det er her den store og måske nye opgave for nogle BI-teams ligger: Få nu markedsført og forankret jeres løsning. Investér lige så meget tid i markedsføring og kommunikation, som i at udvikle – det er godt givet ud på sigt!

Og i relation til spørgsmålet om de tunge ITIL-processer: Drop det nu. BI og data skaber værdi her og nu og ikke nødvendigvis, når det passer ind i næste release cycle.