Når man spørger til prisen på en Business Central-implementering, får man ofte et svar, der lyder som “det kommer an på”. Det er irriterende, men ikke forkert. Prisen består af flere lag: licenser, selve projektet, jeres interne tid, data, integrationer, træning og drift efter go-live.
Det gode er, at man ret hurtigt kan gøre “det kommer an på” konkret nok til at lægge et realistisk budget, vælge den rigtige projekttilgang og undgå de klassiske budgetfælder.
Hvad betaler man egentlig for?
En Business Central-implementering er ikke kun “at få et nyt ERP-system”. Det er en ændring af arbejdsgange, dataansvar, rapportering og ofte også roller i økonomi, lager, salg og indkøb. Derfor består prisen typisk af både en fast del (licenser) og en variabel del (projekt og løbende udvikling).
Det er også grunden til, at to virksomheder med samme antal brugere kan få vidt forskellige tilbud. Den ene har ryddet op i stamdata, standardiseret processer og kan nøjes med standardfunktionalitet. Den anden har mange undtagelser, flere systemer der skal snakke sammen, og historik der skal med over.
Et nyttigt pejlemærke er at se på totalomkostningen i to spor: “at komme i drift” og “at drive og udvikle løsningen stabilt bagefter”.
Licenser: den faste månedlige del
Business Central i cloud sælges som abonnement pr. bruger pr. måned. Microsofts officielle listepriser i Danmark (ved årlig betaling) ligger omkring:
- Essentials: ca. 550,00 kr. pr. bruger pr. måned
- Premium: ca. 750,00 kr. pr. bruger pr. måned
- Team Members: ca. 55,00 kr. pr. bruger pr. måned
Essentials dækker typisk økonomi, salg, køb, lager og basale processer. Premium bruges ofte, hvis man har behov for produktions- eller servicefunktionalitet.
To ting betyder meget for licensbudgettet:
- Antal fulde brugere vs. Team Members (Team Members er ofte oplagt til brugere, der primært skal læse data, godkende, lave simple registreringer eller se rapporter)
- Valg af Essentials vs. Premium (hvis I reelt har brug for Premium-funktioner, bør I budgettere Premium til de relevante fulde brugere, og i nogle scenarier kan det påvirke hele brugergruppen)
Licenser er sjældent den største udgift i en implementering her og nu, men det er den udgift, der fortsætter måned efter måned. Derfor giver det mening at lave et simpelt 36-måneders overblik, så man ikke kun ser på “projektprisen”, men på hele økonomien i skiftet.
Implementeringen: hvor budgettet typisk ligger
Selve implementeringen er ofte den største engangsomkostning. Her ligger timer til projektledelse, workshops, opsætning, afklaring af krav, procesdesign, dataflytning, test, træning og go-live-aktiviteter.
Det er vigtigt at huske, at implementeringsbudgettet typisk består af to dele: konsulentydelser (partnerens timer) og kundens interne indsats (jeres egne timer til beslutninger, stamdata, test, procesafklaringer, træning og forankring). I mange projekter svarer kundens interne indsats groft til 20-40% af den samlede implementeringsindsats, og i perioder kan det fylde endnu mere, fordi de rigtige beslutninger, godkendelser og datavalideringer kun kan komme fra jer.
Det betyder også, at et konsulentbudget kan se “stort” ud isoleret, men at det reelle implementeringsbudget og arbejdet bag er fordelt på begge parter. En vigtig pointe er derfor, at implementeringsbudgettet ikke kun er “partnerens timer”, fordi jeres egen tid har en pris, også selv om den ikke kommer på en faktura.
I danske SMV-projekter ser man ofte, at en implementering for cirka 10 til 30 brugere lander i et niveau omkring 300.000 til 600.000 kr. i konsulentydelser, når scope er rimeligt afgrænset og der ikke er for mange specialtilpasninger.
Det tal kan både være højere og lavere. Det bliver højere ved flere selskaber, avancerede lagerflows, produktion, mange integrationer og krav om at flytte meget historik. Det bliver lavere, hvis man kan køre meget standard, tage en trinvis udrulning og holde antallet af særregler nede.
De oversete poster, der ofte flytter budgettet
Mange budgetter sprækker ikke på licenserne, men på det man ikke fik sat ord på tidligt nok: data, testdisciplin, integrationsdetaljer og forandring i hverdagen.
Her er poster, der ofte bliver undervurderet, når man laver et første budget:
- Stamdataoprydning
- Afklaring af proces-ejerskab
- Testcases og UAT-tid
- Rapporter og udskrifter
- Rettigheder og governance
- Parallelkørsel og cutover-plan
Det er ikke “nice to have”. Det er ting, der afgør, om man går i drift med ro i maven.
Dataflytning er et godt eksempel. En mindre SMB-migrering kan koste alt fra et mindre femcifret beløb til et pænt sekscifret beløb, afhængigt af datamængde, kvalitet og hvor meget historik der skal med. Den store forskel ligger tit i oprydning og validering: hvem tager ansvar for at data er korrekte, og hvornår er de “gode nok” til at starte?
Hvad driver prisen mest?
Der er mange faktorer, men et mønster går igen: kompleksitet koster, og uklarhed koster endnu mere. Projekter løber sjældent løbsk, fordi man “mangler et par timer”. De løber løbsk, fordi scope bliver flydende, eller fordi man opdager sent, at en central proces ikke er afklaret.
De største prisdrivere er typisk:
- Antal processer og undtagelser i drift (ikke kun antal brugere)
- Antal integrationer og krav til real-time data
- Mængde og kvalitet af data, der skal flyttes
- Specialtilpasninger og kundespecifik udvikling
- Krav til rapportering, dokumenter og godkendelsesflows
- Antal selskaber, lokationer og lagerprincipper
Specialtilpasninger er værd at være ekstra nøgtern omkring. Branchespecifikke add-ons kan være et godt valg, hvis de er gennemtestede og opgraderbare, men skræddersyet kode kan hurtigt give højere implementeringspris og mere arbejde ved fremtidige opgraderinger.
Tre typiske budgetscenarier (forenklet overblik)
Nedenstående er ikke et tilbud, men et praktisk overblik over, hvordan budgetter ofte fordeler sig i danske projekter, når man regner både projekt og de mest almindelige tillægsposter med. Tallene varierer, men kan bruges til at kalibrere jeres forventninger.
Scenarie A: Standard og afgrænset Typisk, hvis I er 5-15 brugere, har ét selskab og få integrationer.
- Engangsbudget til implementering (typisk): 200.000 til 450.000 kr.
- Kendetegn:
- Standardopsætning og få tilpasninger
- Begrænset historik (fx åbningsbalance/åbne poster)
- Få rapport- og dokumenttilpasninger
- Ongoing efter go-live (år 1): ca. 10-15% af projektbudget
Scenarie B: Klassisk SMV Typisk, hvis I er 10-30 brugere, arbejder med handel/distribution og har flere integrationer.
- Engangsbudget til implementering (typisk): 300.000 til 800.000 kr.
- Kendetegn:
- Mere dataarbejde (mapping, oprydning, validering)
- Integrationer til fx webshop, lager, EDI eller BI
- Flere roller, godkendelser og afklaringer på tværs af afdelinger
- Ongoing efter go-live (år 1): ca. 10-20% af projektbudget
Scenarie C: Kompleks Typisk, hvis I er 25-60+ brugere, har flere lokationer/selskaber og produktion/service.
- Engangsbudget til implementering (typisk): 800.000 til 2.000.000+ kr.
- Kendetegn:
- Premium-scope (produktion/service) og mere procesdesign
- Avanceret lager/produktion og større testindsats
- Flere integrationer og større krav til styring og governance
- Ongoing efter go-live (år 1): ca. 15-25% af projektbudget
Licenser kommer oveni som den faste månedlige del. Hvis man vil lave en enkel tommelfingerregel til en første business case, kan man ofte starte med at budgettere implementeringen som den store engangspost og licenserne som den stabile driftspost, og så sætte en buffer på projektet.
Bufferen er ikke et tegn på dårlig planlægning. Den er et tegn på moden risikostyring.
Sådan kan I styre pris og risiko uden at bremse projektet
Prisstyring handler sjældent om at presse timepriser. Det handler om at gøre scope styrbart og få de rigtige beslutninger tidligt. En struktureret tilgang, hvor man arbejder i milepæle og accepterer små leverancer, gør det nemmere at holde budget og samtidig få værdi løbende.
Når Navision og Business Central arbejder med Business Central, er et typisk fokus netop styring, governance og forankring hos brugerne, fordi det er her mange projekter vinder eller taber økonomi: færre overraskelser, tydelige beslutninger og en løsning der kan videreudvikles kontrolleret.
Praktiske greb, der ofte virker i budgettet:
- Skær tidligt i scope: Definér hvad der skal med i første go-live, og hvad der bevidst kommer bagefter.
- Standard først: Brug standardfunktionalitet som udgangspunkt, og dokumentér hvorfor en afvigelse giver reel forretningsværdi.
- Fast metode for ændringer: Aftal hvordan change requests vurderes, estimeres og godkendes, før de sættes i gang.
- Data som delprojekt: Planlæg ejerskab, oprydning, mapping og validering som en selvstændig leverance med egne deadlines.
- Træning med ansvar: Udpeg superbrugere, og giv dem tid til at teste og træne andre, ikke kun til at “deltage i et kursus”.
Et ekstra tip: vær konkrete om, hvad “færdig” betyder i test. Hvis “færdig” er noget med “det virker nogenlunde”, så kommer regningen ofte senere.
Cloud vs. on-prem: påvirker det prisen?
De fleste nye Business Central-projekter i Danmark lander i cloud, fordi infrastrukturomkostningerne bliver mindre synlige, og opdateringer håndteres løbende. On-prem kan stadig give mening i særlige scenarier, men så skal man regne med mere ansvar og flere tekniske driftsopgaver.
Cloud flytter ikke hele regningen væk. Den flytter den. Licenser og løbende udvikling fylder mere i driftsbudgettet, og man bør stadig budgettere tid til governance, opdateringer, test af nye releases og vedligehold af integrationer.
Hvis jeres budget er stramt, er cloud ofte stadig en fordel, fordi I undgår store engangsudgifter til servere, miljøer og drift, men det kræver disciplin på ændringer og løbende forbedringer.
Efter go-live: drift, support og videreudvikling
Mange virksomheder undervurderer, hvor meget der sker efter go-live. Ikke fordi projektet er mislykket, men fordi man først rigtigt lærer den nye hverdag at kende, når man bogfører, plukker, fakturerer og afstemmer i den nye løsning.
Et fornuftigt driftssetup handler om at have en klar kanal til support, aftalt svartid, en prioritering af forbedringer og en rytme for ændringer, så systemet ikke bliver “lappeløsninger på lappeløsninger”.
Her giver det mening at tænke i en enkel styringsmodel:
- Hvad er “drift” (fejl, stopklodser, brugerhjælp)?
- Hvad er “små forbedringer” (rapporter, felter, godkendelser)?
- Hvad er “nye initiativer” (ny integration, nyt lagerflow, nyt selskab)?
Når rollerne er tydelige, bliver budgettet også tydeligere. Mange lægger et årligt beløb til support og mindre videreudvikling, ofte i niveauet 10 til 20% af projektets størrelse i år 1, og justerer efter stabilisering.
Spørgsmål der giver et bedre estimat fra starten
Hvis I vil have et estimat, der holder bedre, så stil spørgsmål der tvinger afklaringer frem, før løsningen tegnes færdig. Det sparer tid for begge parter og giver et skarpere budget.
Her er en kort liste over spørgsmål, der typisk flytter et prisestimat fra “bredt interval” til “styrbart budget”:
- Hvilke processer skal være i drift dag 1? Og hvad kan vente 4 til 12 uger?
- Hvor meget historik skal med? Balance, åbne poster, lagerbeholdning, åbne ordre, eller flere års transaktioner?
- Hvilke integrationer er forretningskritiske? Og hvilke kan starte som manuelle arbejdsgange i en periode?
- Hvilke rapporter og dokumenter er nødvendige? Hvilke er “gode at have”?
- Hvem ejer stamdata og test? Navngivne roller, tid i kalenderen og beslutningsret.
Når de svar ligger fast, bliver det langt nemmere at vælge licenser, lægge en realistisk tidsplan og få en implementering, der både kan sættes i drift og holdes sund over tid.