Problemet: når bedriftens data ikke henger sammen

De fleste bedrifter har dataene, men ikke samlet og strukturert. De er spredt i ulike fagsystem - Regnskap, CRM, timeregistrering, prosjektverktøy og regneark - de henger ikke sammen. Dermed går mye verdifull tid til å finne, kontrollere, rydde og sammenstille data før de kan brukes til rapportering, analyse og videre beslutninger.

Et enkelt spørsmål krever data fra flere steder

Tenk deg en ledergruppe som skal svare på et tilsynelatende enkelt spørsmål: Hvilke kunder eller prosjekter tjener vi egentlig penger på? Inntektene ligger i regnskapssystemet, kundeoppfølgingen i CRM-systemet og timene i timeregistreringen. Opplysningene finnes allerede. Likevel må noen hente dem ut, forstå hvordan de er definert, kontrollere dem og koble dem sammen før de kan gi et pålitelig og tydelig svar. Dataene finnes, men kan ikke uten videre brukes slik de ligger i systemene i dag.

Fagsystemene er laget for ulike formål

Et regnskapssystem skal holde orden på bilag, betalinger og økonomisk rapportering. Et CRM-system skal følge kunder og salg, mens et system for timeføring eller prosjekter skal vise hva det arbeides med og hvor ressursene brukes. Hvert av dem løser sin oppgave godt, og dataene får formen sin av nettopp den jobben. De kommer fra arbeidet med å sende en faktura eller følge opp et salg, og de er lagret slik dette arbeidet krevde. Det er ikke en svakhet ved systemene, men nettopp det de er bygget for. Konsekvensen merkes først når dataene skal brukes til noe annet, og særlig når et system skal byttes ut, ettersom historikken blir liggende igjen i det gamle og sammenligning over tid blir tungvint.

Formen dataene har fått, tilhører systemet de kom fra. Skal de brukes til noe annet, må de hentes ut. Veien ut går gjennom et API, en teknisk inngang leverandøren av fagsystemet har laget for at andre programmer skal kunne lese data. Tabeller og kolonner har navn som gir mening inne i systemet, uten at det står forklart noe sted hva de betyr. Så lenge dataene bare finnes i leverandørens format og struktur, er de i praksis bundet til den leverandøren. 

Samme kunde finnes i flere versjoner

Selv når dataene er hentet ut, gjenstår det å forstå hva som hører sammen. Et selskap har gjerne ett kundenummer i regnskapssystemet og en helt annen identifikator i CRM-systemet, uten at noe kobler dem sammen. Det samme gjelder leverandører, produkter, prosjekter og ansatte. Det er ikke bare ID-ene som spriker. To systemer kan begge ha et felt som heter kunde og mene forskjellige ting med det. Det ene teller alle som har fått en faktura, det andre alle som er registrert i en salgsprosess. Skal man finne ut hva en kunde faktisk har kostet og innbrakt, må disse versjonene først kobles sammen til en versjon.

I tillegg varierer skrivemåten. Det samme selskapet kan stå oppført med og uten AS, med organisasjonsnummer i det ene systemet og ingenting i det andre, eller med en adresse som ikke har vært riktig på flere år. Noen registreringer er duplikater, andre er utdaterte uten at det er markert noe sted. Så lenge hvert system brukes hver for seg, merkes ikke dette. Regnskapsføreren finner det han skal finne, og selgeren finner sin kunde. Problemet oppstår i det øyeblikket tallene skal settes sammen. Da blir det uklart hva som faktisk hører sammen, og dere ender opp med flere versjoner av samme sannhet.

Arbeidet må gjøres manuelt, og svaret blir likevel ufullstendig

I praksis løses dette ofte med eksport til Excel. Noen henter ut tallene, rydder dem og setter dem sammen for hånd. Det fungerer den dagen det gjøres, men uka etter er tallene utdaterte, og neste måned gjøres den samme jobben på nytt. I tillegg stjeler dette arbeidet med manuell rydding og strukturering av data verdifull tid fra noen som kanskje helst ville brukt tiden sin annerledes. 

Regnearket ligger også gjerne lokalt hos en enkelt person, ofte uten at andre vet hvilke valg som ble tatt underveis. Er personen borte, stopper det opp. I filen kan det ligge opplysninger om kunder, ansatte og økonomi som burde vært bedre sikret enn på et skrivebord. Noen ganger blir beslutningen heller ikke tatt. Spørsmålet stilles, svaret tar tid, og når tallene endelig er klare, har situasjonen endret seg. 

Når tallene endelig er på plass, beskriver de fortsatt bare bedriften selv. Har lønnskostnadene steget mer enn hos andre i bransjen, eller følger de bare den generelle utviklingen? Skyldes økte kostnader dårlige innkjøp, eller har prisene steget generelt? Uten eksterne tall som prisutvikling, lønnsvekst og regnskapstall for selskapene dere handler med, er det vanskelig å vite. I Norge er slike data offentlige og lett tilgjengelige, men de må kobles til bedriftens egne data for å bety noe. 

BI og KI arver datagrunnlaget

Om en bedrift laster ned en eksportfil fra fagsystemet sitt og gir den til et KI-verktøy som eksempelvis ChatGPT, kan KI-en lese filen og forsøke å analysere innholdet, men først må den selv prøve å tolke grunnlaget:

• Hva betyr de forskjellige kolonnene?
• Hvilke registreringer viser til samme kunde?
• Hvilket år eller hvilken periode gjelder tallene?
• Hvordan er nøkkeltallene bedriften bruker definert og beregnet?
• Inneholder filen alle relevante opplysninger?
• Er dette den nyeste og riktige versjonen?

Dette er spørsmål ingen har svart på i filen. Kolonnenavnene kommer fra fagsystemet og er ikke forklart noe sted. KI-en kan gjøre antakelser og fortsatt gi et svar som høres overbevisende ut. Det betyr ikke nødvendigvis at tolkningen stemmer med hvordan virksomheten selv definerer kundene, periodene eller nøkkeltallene sine. Hvis noe mangler i filen, er uklart beskrevet eller registrert på forskjellige måter, følger usikkerheten med inn i svaret. Verktøyet sier ikke fra at det har gjettet, og for den som leser svaret er det ingen forskjell å se. Det samme gjelder i BI-verktøy. En graf i Power BI ser like ryddig ut enten tallene bak er kvalitetssikret eller ikke. Verktøyene løser visningen, ikke grunnlaget.

Hva som skal til

Problemet er altså ikke at det finnes for lite data. Det er at dataene ligger spredt i systemer med ulike begreper og strukturer, og at sammenhengene ikke er etablert. Skal dataene brukes samlet til rapportering, analyse eller KI, må de først hentes ut og kobles sammen på en måte som gjør at kunder, perioder og nøkkeltall betyr det samme. Spørsmålet fra innledningen, om hvilke kunder eller prosjekter bedriften faktisk tjener penger på, er ikke vanskelig i seg selv. Det blir vanskelig fordi grunnlaget ikke er på plass. Konsekvensen er at tiden går med til å lete og rydde, at svarene kommer for sent til å brukes, og at verktøyene arver et grunnlag ingen helt stoler på.

I neste artikkel ser vi på hva som skal til for å få kontroll på egne data.