Nogle gange er det gået lidt for stærkt med at få systemerne sat op, og det opdager man først når der skal laves koncernregnskab oven på en håndfuld selskaber der er knopskudt frem hver for sig. 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 virkeligheden rigtigt mange steder. Og det er indbegrebet af master data.
Altså de stamdata der beskriver hvad du sælger, hvem du handler med, og hvordan tingene konteres i BC. Det kunne være vareopsætning, kunder, leverandører, kontoplan, dimensioner og den slags. Det er ikke selve transaktionen, men de skabeloner alle transaktioner hældes ned i. Og hvis du har flere skabeloner som ser forskellige ud fra selskab til selskab, forplanter den forskel sig til alt det du bygger ovenpå.
Rod opstår når det går stærkt
Jeg tror ikke nogen virksomheder har nul rod i deres master data. Det findes overalt og det opstår næsten aldrig fordi nogen har sjusket bevidst. Det sker når det går stærkt og der ikke lige er tid til at samle et hold fra flere afdelinger til at tage en beslutning. Det sker når man har dygtige og arbejdsomme medarbejdere som ikke stopper op, fordi problemet jo gerne skal løses her og nu. Der er en kunde som venter og jeg mener det sker alle steder.
Problemet er ikke at det sker. Problemet er når man ikke får ryddet op løbende. Så ender man med at stå med rodet senere på året eller når man forsøger at bygge noget business intelligence eller analyse op på de data, som er bogført. Og så kan det blive dyrt at rette op på. 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 lige opdager det.
Min påstand er ikke at man skal undgå, at der nogensinde opstår rod. Det kan man ikke og særligt ikke hvis man samtidig vil vokse i et fornuftigt tempo eller udvikle forretningen. Spørgsmålet er et andet: Hvornår tager man fat i datarens og dataoprydningen? For jo før man rydder op, jo mindre når rodet at brede sig. Og det er billigere og tager kortere tid at rydde op.
Ensartethed er hele pointen
God master data-håndtering ender altid samme sted, nemlig ved at få systemerne til at opføre sig så ens som muligt. Ikke fordi ensartethed er et mål i sig selv, 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! Helst 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.
Buzzwordet er Governance
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.
Ét regnskab som giver dig 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. Det er den ene version der gælder, og resten er kopier.
“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 Business Central gøre arbejdet
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. Når facitlisten er bragt i orden, governance holder den ren, og synkroniseringen kører af sig selv om natten, er den rapport ikke noget der vælter kvartalet længere. Tallene mødes, fordi de taler samme sprog, og konsolideringen tager timer i stedet for dage. Og medarbejderen der vidste hvilken af de fire kunder der var den rigtige, kan 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 direktionsdagsorden. Men det er et af de billigste steder at spare sig selv for tid og bøvl senere.
