Når en virksomhed går i gang med Business Central, opstår det samme spørgsmål næsten altid tidligt i forløbet: Skal løsningen tilpasses, så den ligner de nuværende arbejdsgange, eller skal processerne først bringes tættere på standarden?
Det korte svar er, at standardisering næsten altid bør komme før tilretning. Ikke fordi standard er “renere” i teorien, men fordi det giver en løsning, der er lettere at drive, lettere at opgradere og billigere at ændre over tid.
I praksis er det her, mange projekter vinder eller taber fart. Hvis man starter med specialønsker, skærmbilleder, særregler og gamle vaner, får man hurtigt en løsning, som fungerer på go-live dagen, men bliver tung at vedligeholde bagefter. Hvis man derimod begynder med standardprocesser, styring af scope og en klar model for, hvornår tilretning faktisk er berettiget, står man stærkere både teknisk og forretningsmæssigt.
Hvorfor standard først giver mere robuste BC-løsninger
Business Central er bygget til at dække et meget bredt behov inden for økonomi, lager, salg, indkøb, projektstyring og rapportering. Det betyder, at mange behov allerede kan løses med standardfunktioner, opsætning, workflows og velafprøvede apps.
Når en virksomhed vælger standarden til som første valg, opnår den typisk tre ting. Løsningen bliver mere genkendelig for nye brugere. Opgraderinger bliver mindre risikable. Fejlretning bliver hurtigere, fordi man arbejder i kendte mønstre i stedet for i en samling særtilpasninger.
Det er ikke det samme som, at tilretning er forkert. Det betyder bare, at tilretning skal være et bevidst valg, ikke en refleks.
Et klassisk problem fra ældre NAV- og BC-miljøer er, at små ændringer er blevet lagt oven på hinanden gennem mange år. Hver ændring kan virke rimelig alene. Samlet set skaber de afhængigheder, som gør selv små opgraderinger dyre og usikre. Den regning kommer sjældent med i det oprindelige business case, men den dukker op senere i form af længere testforløb, flere fejl og mere intern usikkerhed.
Hvad standardisering faktisk betyder i Business Central
Standardisering handler ikke kun om at sige nej til kode. Det handler om at skabe et fælles grundlag for, hvordan virksomheden bruger løsningen.
I Business Central består standardisering ofte af fire lag: processer, data, roller og teknisk arkitektur. Hvis bare ét af de lag bliver overset, kommer behovet for tilretning hurtigt til at se større ud, end det reelt er.
Efter den indledende afklaring giver det mening at se på standardisering som dette:
- Fælles proces for køb, salg og bogføring
- Ens stamdata og navngivning
- Klare roller og rettigheder
- Fast model for integrationer
- Brug af standardfunktioner før specialudvikling
Når virksomheder siger, at “vores forretning er speciel”, er det ofte kun delvist rigtigt. Selve kerneydelsen kan være særlig, men de administrative processer minder tit om mange andres. Fakturaer skal godkendes. Varer skal modtages. Betalinger skal bogføres. Lager skal afstemmes. Det er netop de områder, hvor standardfunktionalitet og modne add-ons giver mest værdi.
Derfor er standardisering ikke et kompromis. Det er en måde at skelne mellem det, der virkelig skaber konkurrencekraft, og det, der bare skal fungere stabilt hver dag.
Hvornår tilretning giver god mening
Tilretning er relevant, når standarden ikke kan understøtte et vigtigt forretningskrav, eller når et krav er så centralt, at det ikke bør presses ind i en dårlig arbejdsgang. Men grænsen skal være skarp.
Et nyttigt princip er at spørge: Hvis denne tilretning fjernes om to år, vil virksomheden så miste et vigtigt forspring, bryde lovkrav eller få markant dårligere datakvalitet? Hvis svaret er nej, bør man som udgangspunkt holde sig til standard.
De bedste beslutninger om tilretning tager ofte afsæt i få, tydelige kategorier:
- Lovkrav: Kravet er nødvendigt for korrekt bogføring, dokumentation eller compliance
- Kerneproces: Ændringen understøtter en central proces, som virksomheden lever af
- Brugeradoption: Tilpasningen gør standarden realistisk at anvende i daglig drift
- Datakvalitet: Løsningen reducerer fejl, dubletter eller manuelle omveje
- Integration: Kravet binder Business Central ordentligt sammen med vigtige systemer
Det er værd at være særlig kritisk over for tilretninger, der kun eksisterer for at efterligne en gammel løsning. “Vi plejer” er sjældent et stærkt designargument. Hvis en arbejdsgang blev skabt for ti år siden i et andet system, kan den være et udtryk for begrænsninger dengang, ikke for et reelt behov nu.
En praktisk beslutningsmodel før der udvikles noget
Mange projekter har gavn af en fast beslutningsmodel. Den skaber ro, fordi alle ved, hvordan ønsker bliver vurderet.
Før en tilretning godkendes, kan man bruge denne enkle rækkefølge:
- Beskriv behovet i forretningssprog, ikke i løsningssprog.
- Vurder om standardopsætning eller eksisterende funktionalitet kan dække behovet.
- Undersøg om en velafprøvet app kan løse opgaven bedre end egen udvikling.
- Udvikl kun, hvis gevinsten er tydelig, dokumenteret og realistisk at vedligeholde.
Det punkt, mange springer over, er trin 1. Hvis ønsket bliver formuleret som “vi skal have et ekstra felt og en automatisk handling”, starter man for hurtigt i teknik. Hvis det i stedet beskrives som “vi skal sikre korrekt periodisering uden manuelle rettelser”, bliver det lettere at vurdere, om behovet kan løses i standarden.
Her gør strukturerede workshops og proceskortlægning en stor forskel. Det samme gælder governance, tydelige milepæle og små leverancer, hvor brugerne kan validere løsningen løbende frem for først til sidst.
Teknisk best practice for en vedligeholdelsesvenlig løsning
Når tilretning er nødvendig, bør den bygges, så den kan overleve næste opgradering. Det lyder indlysende, men det kræver disciplin i designet.
I moderne BC-løsninger betyder det typisk, at ændringer skal ligge i extensions frem for at bryde standardstrukturen. Kode skal være afgrænset. Navngivning skal være ensartet. Integrationer skal være dokumenterede. Rapporttilpasninger skal holdes adskilt fra kerneprocesser, når det er muligt.
Et typisk sæt tekniske principper ser sådan ud:
- Extensions før indgreb i standard: Hold speciallogik afgrænset og nem at teste
- Apps før egen kode: Brug modne løsninger til dokumenthåndtering, scanning og formularer
- Små leverancer før store pakker: Det gør fejl lettere at finde og ændringer lettere at styre
- Versionsstyring før hurtige rettelser: Alle ændringer skal kunne spores og rulles frem på en kontrolleret måde
Her er samarbejdet med velafprøvede add-ons ofte en styrke. Til funktioner som dokumenthåndtering, godkendelser, rapportlayout og specialiserede processer kan det være mere holdbart at bygge på eksisterende løsninger end at udvikle selv. Det reducerer mængden af kundespecifik kode og flytter en del af vedligeholdelsen over i produkter med faste release-cyklusser.
Det samme princip gælder rapporter og formularer. Hvis hver rapport bliver specialdesignet uden en fælles model, bliver de dyre at ændre. Hvis der i stedet laves en rapportstrategi med få mønstre og klare ejerskaber, bliver administrationen langt lettere.
Hvad det betyder for drift, opgradering og omkostninger
Tidlig standardisering er ikke kun en arkitekturdiskussion. Det kan mærkes direkte i driften. Branchekilder peger på, at mere standardiserede og datadrevne miljøer kan reducere nedetid og vedligeholdelsesomkostninger markant. En omtale af McKinsey-tal gengivet hos Makula nævner blandt andet potentiale for lavere nedetid og færre vedligeholdelsesomkostninger, når processer og data er struktureret til løbende overvågning og forbedring.
I Business Central er pointen mindre dramatisk, men meget konkret: Jo mere ensartet løsningen er, desto mindre tid bruger man på brandslukning. Desto lettere bliver det at teste opgraderinger. Desto hurtigere kan nye brugere trænes. Desto færre steder kan fejl gemme sig.
I stedet for en tabel kan effekten ses som fire enkle driftsbokse:
Driftsstabilitet
Standardnære løsninger giver færre uventede sideeffekter mellem moduler og processer.
Opgraderbarhed
Afgrænsede extensions og færre specialspor gør releases lettere at teste og implementere.
Lavere vedligehold
Mindre specialkode betyder færre særhensyn ved fejlretning, support og dokumentation.
Bedre brugeradoption
Genkendelige arbejdsgange og mindre kompleksitet gør træning og onboarding enklere.
En artikel i Dynamics-fællesskabet beskriver samme grundproblem fra udviklingssiden: Når design og struktur ikke får nok opmærksomhed, bliver løsningen mindre vedligeholdelsesvenlig og sværere at opgradere over tid. Den pointe er stadig relevant, selv om værktøjerne er blevet bedre. Arkitekturen bliver ikke god af sig selv.
De fejl der typisk skaber teknisk gæld i BC-projekter
Mange problemer opstår ikke, fordi virksomheder vælger tilretning, men fordi de vælger den for tidligt eller uden faste kriterier. Det giver en form for teknisk gæld, som senere bliver til driftsgæld.
Det ses særligt i projekter, hvor scope vokser løbende, eller hvor ledelsen ønsker hurtige særønsker implementeret uden at vurdere konsekvensen for helheden.
De mest almindelige fejl er ofte disse:
- Tilretning af gamle vaner i stedet for forbedring af processen
- Manglende ejerskab på stamdata og opsætning
- Uklare beslutninger om, hvem der kan bestille ændringer
- Rapporter og felter uden tydeligt forretningsformål
- Integrationer uden dokumenteret ansvar og fejlflow
Der er en særlig risiko i at overvurdere, hvor meget brugervenlighed der kræver kode. I mange tilfælde handler modstand mod standarden om træning, roller eller uklare processer, ikke om manglende funktionalitet. Hvis den diagnose bliver forkert, ender man med at kode sig ud af et adoptionsproblem, som burde løses med ledelse og forankring.
Sådan arbejder man mere sikkert med standardisering i praksis
En vedligeholdelsesvenlig BC-løsning bliver sjældent skabt i ét stort designmøde. Den bygges gennem en række små, bevidste valg. Her er det vigtigt at kombinere forretningsforståelse med styring af ændringer.
Det gælder fra de første workshops til test, cutover og tiden efter go-live. En god løsning er ikke kun den, der kan gå live. Det er den, der stadig er til at arbejde med om tre år.
I praksis er disse greb ofte afgørende:
- Start med de vigtigste processer og få dem tæt på standarden
- Brug små leverancer, så brugerne kan reagere tidligt
- Beslut add-ons før egen udvikling, når behovet er almindeligt kendt
- Dokumentér fravalg lige så tydeligt som tilvalg
- Planlæg support og implementering, dataflytning og governance allerede før go-live
Her ligger en stor del af værdien i en struktureret tilgang. Når implementering, dataflytning, test og brugertræning bliver tænkt sammen, falder presset på tilretning ofte. Mange ønsker forsvinder, når brugerne ser en enkel standardproces fungere med de rette data og tydelige roller.
For virksomheder, der kommer fra ældre NAV- eller BC-løsninger, er det en god idé at bruge moderniseringen som anledning til oprydning. Ikke alt skal med videre. Nogle tilpasninger har gjort nytte i mange år, men er ikke længere nødvendige. Andre bør erstattes af standardfunktioner eller apps med bedre opgraderbarhed.
Det gør beslutningen mere krævende i starten, men langt lettere senere. Det er netop kernen i en vedligeholdelsesvenlig løsning: mindre improvisation, færre særspor og en tydelig linje mellem det, der skal være standard, og det, der fortjener en reel tilretning.