Nogle gange er det gået lidt hurtigt med at få oprettet systemer, og det bliver først tydeligt når man skal rapportere et koncernregnskab fra flere forskellige regnskaber der er knopskudt. Rapporterne fra alle selskaber skal samles, kvartalet er ved at lukke, og tallene passer bare ikke. Den samme vare hedder “Bolt M8” i det ene selskab, “M8 rustfri” i det andet og et tilfældigt varenummer uden tekst i det tredje. Kunden er oprettet fire gange, to af dem med et CVR-nummer der er tastet forkert, og med tre forskellige betalingsbetingelser. Et sted i huset sidder der en medarbejder som ved præcis hvilken af de fire der er den rigtige. Hun holder ferie.
Det er master data. Altså de stamdata der beskriver hvad du sælger, hvem du handler med, og hvordan tingene konteres: varer, kunder, leverandører, kontoplan, dimensioner. Det er ikke transaktionerne, men skabelonen alle transaktioner hælder ned i. Og når skabelonen ser forskellig ud fra selskab til selskab, forplanter forskellen sig til alt det der bygger ovenpå.
Rod opstår når det går stærkt
Den slags rod opstår næsten aldrig fordi nogen har sjusket. Det sker når det går stærkt og der ikke lige er tid til at samle et hold til en beslutning. Det sker når man har dygtige medarbejdere der ikke bare stopper op. Et nyt selskab skulle op at køre inden månedsskiftet, en stor kunde skulle oprettes mens sælgeren stod med telefonen i hånden, en vare skulle bruges i en ordre her og nu. Så tog man en hurtig beslutning for at komme videre. Sådan vokser virksomheder. Det sker for alle.
Problemet er ikke at det sker, problemet er når man ikke får ryddet op. For så ender man med at stå med rodet senere på året, hvor det er dyrere at rette op. I situationen, hvor man ikke lige kan finde kunden, koster det ingenting at oprette kunden for fjerde gang. Det koster først noget tre måneder senere, når nogen skal finde ud af hvorfor den samme kunde optræder med fire forskellige saldi i en kreditvurdering og man ikke kan give kunden et samlet overblik over hvad kunden skylder. Rod er billigt at lave og dyrt at leve med, og der går typisk et stykke tid inden man opdager det.
Min påstand er ikke at man skal undgå at der nogensinde opstår rod. Det kan man ikke, ikke hvis man samtidig vil vokse i et fornuftigt tempo. Spørgsmålet er et andet: hvornår tager man fat? For jo før man rydder op, når man opdager at det begynder at gå galt, jo mindre når rodet at brede sig, og jo billigere er oprydningen.
Ensartethed er hele pointen
God master data-håndtering ender altid samme sted: det handler om at få systemerne til at opføre sig så ens som muligt. Ikke fordi ensartethed er pænt (selvom en velordnet kontoplan har en vis skønhed, hvis man er til den slags), men fordi hver eneste forskel mellem to selskaber er en oversættelse nogen skal lave bagefter.
Tænk på det som sprog. Hvis selskab A og selskab B kalder den samme vare to forskellige ting, så skal der en tolk til hver gang de to selskaber skal tale sammen. Tolken er som regel en dygtig controller med et regneark og for lidt tid. Fjerner man forskellen, har controlleren tid til at gøre det vedkommende var ansat til.
Det er helt konkret der gevinsten ligger. Det tværgående samarbejde bliver nemt, fordi en indkøber i det ene selskab kan læse det andets varekartotek uden at skulle gætte. En medarbejder kan flytte sig fra én enhed til en anden uden at skulle lære et nyt internt sprog. Rapporteringen bliver genbrugelig i stedet for at skulle bygges forfra i hvert selskab, fordi en konto og en dimension betyder det samme overalt. Og konsolideringen, som for mange er kvartalets lavpunkt, bliver næsten mekanisk, fordi kontoplan, dimensioner og de interne modparter allerede stemmer når tallene mødes. Konsolidering er sjældent svær på grund af matematikken. Den er svær fordi dataene ikke passer sammen.
Ryd op, før du bygger
Man kan ikke synkronisere rod. Eller jo, det kan man teknisk set, men så får man bare synkroniseret rodet ud i alle selskaber på én gang. Det er sjældent det man vil.
Så første skridt er en oprydning, og den skal behandles som et projekt med en ejer og en deadline, ikke som noget der “sker over tid” (det gør det aldrig). Det praktiske arbejde er til at overskue: læg jer fast på én fælles struktur for nummerserier, navnekonventioner og dimensioner, find og flet dubletterne, berig de records hvor der mangler felter, og arkivér det der er dødt. Jeg ved godt at “ryd op i dine stamdata” ikke ligefrem får nogen til at hoppe op af stolen. Men det er fundamentet, og alt det sjovere, altså rapportering, automatisering, AI og hvad man ellers drømmer om, hviler på det. Bygger man ovenpå rod, arver man rodet i alt.
En ting er værd at holde fast i undervejs: ensretning betyder ikke at alt skal være ens for enhver pris. To selskaber i vidt forskellige brancher har måske reelt brug for forskellige dele af kontoplanen. Kunsten er at skelne mellem det der er forskelligt af en grund, og det der bare er forskelligt fordi det gik stærkt engang. Det første respekterer man, det andet retter man.
Governance, ikke anarki
Når der først er ryddet op, opstår det næste spørgsmål helt af sig selv: hvordan bliver det ved med at være rent? For en oprydning uden regler er bare en pause i rodet. Om et halvt år er man tilbage hvor man startede, og så har man brugt penge på at rydde op to gange.
Det er her governance kommer ind, og det ord skræmmer folk mere end det burde. Det behøver ikke være tungt. I sin kerne er det tre ting: nogen ejer hvert dataområde og har mandat til at bestemme, nye stamdata oprettes ét sted efter faste regler frem for spredt ud over huset, og der er en let godkendelse inden en ny record ryger i drift. En bogholder, en produktchef, én der siger ja eller nej. Det behøver ikke være mere.
Det vigtige er at gøre den rigtige vej til den nemme vej. Governance holder kun hvis det er lettere at følge processen end at snyde den. Bliver det for besværligt at få oprettet en ny vare gennem den officielle kanal, så laver folk deres egen genvej, og typisk hedder genvejen Excel. Så jeg vil hellere have en let proces som folk faktisk bruger end en perfekt proces som alle omgår. En smule datadisciplin med lav friktion slår en stor politik som ingen læser.
Ét regnskab som holder facitlisten
Så er der spørgsmålet om hvor stamdataene fysisk skal bo. Min anbefaling, når man er flere selskaber, er at samle dem ét sted: et dedikeret master data-regnskab i Business Central. Et regnskab der ikke bogfører noget som helst, men kun findes for at holde stamdataene. Varer, kunder, leverandører, kontoplan, det hele ét sted.
Det lyder måske som et ekstra lag man ikke havde brug for. Men fordelen er at det giver ét sted at rette og ét sted at godkende. Skal en leverandørs betalingsbetingelse ændres, så ændrer man den i master-regnskabet, punktum, i stedet for at jagte den samme rettelse rundt i fem selskaber og håbe man ramte alle fem. Master data-regnskabet bliver den facitliste alle andre regnskaber læser fra. Man kunne kalde det virksomhedens ene autoritative kopi, og alt andet bliver så per definition afskrifter.
“Hvilken af de fire kunderecords er egentlig den rigtige?”
Det spørgsmål, som enhver controller har stillet mindst én gang, skal helst have ét enkelt svar: den der står i master-regnskabet.
Lad softwaren gøre kopieringen
Og så det sidste, for en facitliste er kun noget værd hvis den når ud i de regnskaber hvor folk arbejder.
Business Central har en standardfunktion til Master Data Management. Den fungerer som en pull-model: man udpeger master data-regnskabet som kilde, og hvert af de øvrige selskaber abonnerer og henter automatisk stamdata derfra. Man vælger selv hvilke tabeller der skal følge med, altså om det er varer, kunder, leverandører, kontoplan eller en kombination, og en natlig kørsel via job-køen sørger for resten. Retter man en vare i kilden om aftenen, står den ens i alle selskaber næste morgen. Det tvinger den samme struktur ud i alle regnskaber uden at nogen skal huske at gøre det.
En begrænsning er værd at kende, inden man planlægger for meget op ad den: funktionen synkroniserer mellem selskaber inden for samme miljø. Skal man dele stamdata på tværs af helt adskilte miljøer eller tenants, kræver det en anden løsning, og der bør man tage en snak med sin partner om hvad der giver mening. Men for den klassiske struktur med en håndfuld selskaber under samme tag løser standardfunktionen langt det meste.
Tilbage til rapporten fra før, den der ikke ville stemme. Med en facitliste der er bragt i orden, en let governance der holder den ren, og en synkronisering der kører af sig selv om natten, bliver rapporten pludselig noget nær triviel. Tallene mødes, fordi de taler samme sprog. Konsolideringen tager timer i stedet for dage. Og medarbejderen der vidste hvilken af de fire kunder der var den rigtige, kan endelig holde ferie uden at være det eneste sted den viden findes.
Ingen af delene kræver at man aldrig laver rod. Det kommer man til, næste gang det går stærkt. Det kræver bare at man beslutter sig for hvornår man rydder op, og at man bygger det sådan at det ikke skrider igen. Det er sjældent det mest spændende punkt på en direktions dagsorden, men det er til gengæld et af de billigste steder at hente ro på bundlinjen.
