Når Business Central først kører stabilt, er fristelsen stor til bare at “lade den passe sig selv”. Problemet er, at der hurtigt opstår en skjult gæld i form af små tilpasninger, hurtige fixes og apps uden ejer. Før man ved af det, føles næste opdatering som et risikoprojekt.
Governance handler om at gøre opgraderinger til en rutine, ikke en begivenhed. Det kræver både tekniske spilleregler og en enkel, fast måde at træffe beslutninger på, når forretningen ønsker ændringer.
Hvad governance betyder i Business Central (i praksis)
Governance i Business Central er de principper, roller og arbejdsgange, der sikrer, at løsningen kan ændres kontrolleret over tid, uden at man maler sig op i et hjørne. Det lyder tungt, men god governance er ofte mere “få, tydelige regler” end store styringsmodeller.
I Business Central giver governance ekstra god mening, fordi Microsoft løbende leverer opdateringer. Hvis man vil have glæde af nye funktioner, sikkerhedsrettelser og bedre performance, skal man kunne tage opdateringer ind uden at bruge måneder på konflikter.
Det begynder med ét spørgsmål, der bør stilles igen og igen: Kan vi løse behovet med standard, konfiguration eller en velvalgt app, før vi skriver kode?
Grundreglen for opgraderbarhed: hold standard ren
Den vigtigste best practice er enkel: undgå ændringer direkte i standardapplikationen. Microsofts anbefaling er, at kundespecifik logik ligger i AL-udvidelser (extensions) frem for i modificerede standardobjekter. Det gør det muligt at opdatere baseapplikationen, uden at kundetilpasninger bliver overskrevet eller blokerer opdateringen.
Det betyder ikke “ingen tilpasninger”. Det betyder “tilpasninger med klare rammer”.
Efter en kort afklaring af behov og konsekvens kan en god tommelfingerregel være:
- først konfiguration og standardfunktioner
- så AppSource eller gennemprøvede add-ons
- og til sidst egenudviklede extensions, når de to første ikke rækker
Når man følger den prioritering, falder antallet af specialcases, og man får typisk også bedre dokumentation, fordi standard og etablerede apps kommer med kendte opdateringsspor.
En enkelt sætning, der ofte redder budgettet: Hvis en ændring ikke kan forklares og testes, kan den heller ikke opgraderes trygt.
En beslutningsmodel for ændringer (som ikke bremser forretningen)
Mange virksomheder ender i to yderpunkter: alt skal godkendes af en komité, eller også kan alle “bare bestille” udvikling. Begge dele giver problemer. Governance bør i stedet være en letvægtsmodel, hvor beslutninger tages hurtigt, men på et oplyst grundlag.
Et praktisk setup er at etablere en fast ændringsproces, hvor hver ændring vurderes på værdi, risiko og påvirkning af opgraderbarhed. Det behøver ikke være tungt, hvis man standardiserer skabeloner og krav til accept.
Her er typiske governance-regler, der virker i hverdagen, når de håndhæves konsekvent:
- Standard først: krav skal afprøves mod standard og opsætning, før udvikling godkendes
- Extension-only: ny logik bygges som AL-udvidelser, ikke som “snedige” genveje
- App-ejerskab: hver tredjepartsapp har en intern ejer, der følger versioner og ændringer
- Definition of Done: ingen ændring er færdig uden test, dokumentation og rollback-plan
- Hurtige afklaringer
- Klar prioritering
Den sidste linje er bevidst kort. Governance fejler ofte, fordi man undervurderer, hvor meget ro det giver at have én prioriteret kø og en fast måde at sige ja eller nej på.
DevOps og miljøer: sådan undgår du “det virker hos mig”
Teknisk governance er ikke kun kodekvalitet. Det er også, hvordan man flytter ændringer fra idé til drift uden overraskelser. En klassisk faldgrube er at teste for lidt eller at teste i et miljø, der ikke ligner produktion.
Et robust minimumssetup for Business Central (cloud eller on-prem) er en tydelig miljømodel:
- Udvikling (dev): her bygges og kompileres extensions
- Test (test/UAT): her validerer man processer, integrationer og brugerflow
- Produktion (prod): her skal ændringer være forudsigelige og sporbare
Når man kombinerer det med versionsstyring (Git), automatiske builds og release pipelines (ofte i Azure DevOps eller GitHub), bliver kvaliteten mere stabil, og fejl opdages tidligere.
Et vigtigt princip: Automatisering erstatter ikke faglig test, men den fjerner gentagelige fejl. Og den giver et revisionsspor, som er guld værd, når nogen spørger “hvad blev ændret, og hvornår?”.
“One Version” som arbejdsmåde, ikke som slogan
Business Central er designet til løbende opdateringer, især i cloud. Det ændrer opgraderingslogikken: hellere hyppige, mindre opdateringer end sjældne, store spring. Når ændringer kommer i små bidder, bliver de lettere at teste, og forretningen vænner sig til en fast rytme.
Det kræver governance, fordi man ellers bare udskyder opdateringerne “til vi får tid”.
En god rytme kan være kvartalsvis planlægning med faste vinduer til:
- gennemgang af Microsofts release notes og påvirkning
- opdatering af apps og egne extensions
- regressionstest af nøgleprocesser
- kort brugerkommunikation om ændringer
Det kan føles som ekstra arbejde. I praksis er det ofte mindre arbejde end den store opgradering, der ellers kommer med ophobede konflikter.
Tredjepartsapps og add-ons: styring af noget, du ikke selv ejer
Apps fra AppSource og specialiserede add-ons kan give stor værdi, men de kan også blive en opgraderingsrisiko, hvis ingen følger med i, om leverandøren opdaterer dem i takt med Business Central.
Governance for apps bør derfor handle om udvælgelse og drift, ikke kun indkøb.
En enkel metode er at have et “app-katalog” internt, hvor hver app har:
- formål og kritikalitet
- version, leverandør og opdateringspolitik
- ansvarlig person i virksomheden
- afhængigheder til andre apps og integrationer
- testpunkter ved opdatering
Når man arbejder med en partner, kan det være en fordel at vælge et lille antal velafprøvede add-ons, som passer til behov som dokumenthåndtering, betalinger, EDI eller rapportering. Hos Naviteam ses governance ofte som en del af den samlede leverancemodel: få, kontrollerede byggesten og klare regler for, hvornår man bygger selv, og hvornår man køber.
Roller og ansvar: uden ejerskab bliver governance til papir
Tekniske regler hjælper ikke, hvis ingen føler ansvar for at følge dem. Et governance-setup bør derfor have navngivne roller, også selvom én person kan have flere hatte i en mindre organisation.
Et typisk rolle-billede ser sådan ud:
| Rolle | Primært ansvar | Typiske beslutninger |
|---|---|---|
| Systemejer (Business Central) | Retning, prioritering, budget | Hvad skal bygges nu, og hvad venter? |
| Procesansvarlige | Krav, acceptkriterier, test | Er løsningen korrekt i praksis? |
| Løsningsarkitekt/teknisk ansvarlig | Principper, integrationsdesign, opgraderbarhed | Standard vs extension, app-valg, teknisk gæld |
| Releaseansvarlig | Plan, cutover, kommunikation | Hvornår opdaterer vi, og hvad er scope? |
| Superbrugere | Træning, support tæt på hverdagen | Hvad skaber friktion, og hvad skal justeres? |
I mange SMB-virksomheder er den største forskel ikke værktøjerne, men at der faktisk findes en releaseansvarlig. En person, der ejer kalenderen, testplanen og “hvad gør vi, hvis noget går galt?”.
Dokumentation og test: det, man springer over, betaler man for senere
Governance bliver ofte mødt med “vi har ikke tid til dokumentation”. Den bedste modgift er at gøre dokumentation konkret og anvendelig.
Dokumentation bør ikke være lange tekster. Den bør være et sæt artefakter, der hjælper ved opdatering og fejlsøgning:
- procesflow for de mest kritiske arbejdsgange (ordre til faktura, indkøb, lager, periodisk bogføring)
- liste over integrationer, deres ejer og fejlhåndtering
- beskrivelse af extensions og deres formål
- testcases til regressionstest, gerne med klare forventede resultater
Test behøver heller ikke være altomfattende for at virke. Mange får god effekt af en fast “rød liste” på 20 til 40 testcases, der altid køres ved opdateringer og releases.
Det giver et fælles sprog mellem forretning og IT: “hvis disse 30 ting virker, kan vi gå i drift”.
Telemetri og driftsovervågning: find problemerne før brugerne gør
Opgraderbarhed handler også om at opdage, når noget gradvist bliver skrøbeligt. Her kan telemetri og overvågning være et stærkt element i governance.
Når man følger performance, fejltyper og brugsmønstre, kan man ofte se:
- om en bestemt side eller rapport giver timeouts efter en ændring
- om en integration fejler oftere end normalt
- om en ny app skaber uventede låsninger eller belastning
- om brugerne arbejder uden om processen, fordi den er blevet for tung
Det er ikke overvågning for overvågningens skyld. Det er en måde at holde løsningen “trimmet”, så næste opdatering ikke rammer en allerede presset drift.
En praktisk governance-checkliste til næste ændring
Governance bliver stærkest, når den bruges ved hver ændring, også den lille. Når et nyt ønske kommer ind, kan man køre en fast mini-vurdering, før man siger ja.
Her er en enkel tjekliste, der ofte passer godt til Business Central:
- Værdi: hvilken proces bliver bedre, og hvordan måler vi det?
- Standardmulighed: kan det løses via opsætning, eksisterende funktion eller app?
- Opgraderbarhed: kræver det egen extension, og er den bygget uden “skjulte afhængigheder”?
- Test: hvilke 5 til 10 ting kan gå galt, og hvem tester dem?
- Releaseplan: hvornår går det i drift, og hvad er rollback, hvis noget fejler?
Hvis man kan besvare de fem punkter, er sandsynligheden for en rolig opgradering markant højere.
Og hvis man ikke kan, er det et signal om at stoppe op, ikke om at skynde sig videre.