Mange SMV’er vælger Business Central, fordi de vil samle økonomi, lager, salg, indkøb og rapportering i én platform, og fordi løsningen kan vokse med virksomheden. Men gevinsten kommer ikke af sig selv. Den kommer af en implementering, der er styret, realistisk og tilpasset hverdagen.
En trin-for-trin køreplan gør det lettere at prioritere, få medarbejderne med og undgå de klassiske overraskelser: uklart scope, for sene afklaringer, datakaos og et go-live, der bliver mere dramatisk end nødvendigt.
Hvorfor en trinvis model virker i praksis
Business Central-projekter går ofte skævt, når man prøver at få “alt med” fra dag ét, eller når man undervurderer, hvor mange beslutninger der faktisk skal træffes: kontoplan, dimensioner, godkendelsesflows, lagerprincipper, moms, rapportering, integrationer, roller og rettigheder.
En faseopdelt tilgang giver tre klare fordele:
- I kan gå i drift på kerneprocesserne først og udskyde “nice to have”.
- I får tid til at rydde op i data og arbejdsgange, uden at forretningen går i stå.
- I kan teste og træne i små bidder, så kvalitet og brugeradoption følger med.
Det kræver til gengæld en tydelig projektmodel, faste beslutningsfora og en aftale om, hvad der er standard, hvad der er opsætning, og hvad der reelt er udvikling.
Fase 0: Forberedelse, scope og styring
Fase 0 handler om at gøre projektet implementerbart, før nogen begynder at konfigurere. Her etableres styregruppe, projektleder, nøglebrugere og en mødestruktur, der kan holde tempoet uden at slide organisationen ned.
Det vigtigste output er et blueprint på et niveau, hvor I kan sige ja eller nej til konkrete valg: Hvilke moduler skal med i første release? Hvilke processer skal ændres? Hvilke integrationer er kritiske ved go-live? Hvad er succeskriterierne, og hvordan måles de?
Efter en indledende afklaring er det typisk hjælpsomt at samle det i et kort beslutningsnotat, så alle arbejder ud fra samme ramme:
- Scope for release 1
- Milepæle og beslutningspunkter
- Roller og ansvar (RACI light)
- Principper for tilretninger og add-ons
Fase 1: Behovsafklaring og gap-analyse
Når rammen er sat, kan I gå dybere i processerne. Målet er at beskrive arbejdsgange, varianter og undtagelser, og samtidig vurdere hvad Business Central kan direkte i standard.
Gap-analysen er central, fordi den skaber gennemsigtighed: Hvilke krav er reelle, og hvilke er vaner? Hvilke “gaps” kan løses med opsætning? Hvilke kræver en app fra AppSource? Hvilke kræver udvikling, og hvad betyder det for opgraderbarhed og budget?
Brug workshops med nøglebrugere, men hold fokus på beslutninger og eksempler fra hverdagen: en typisk salgsordre, en returnering, en kreditnota, en lagerregulering, en indkøbsfaktura, en månedslukning. Jo mere konkret I er her, jo færre misforståelser senere.
Fase 2: Design og opsætning, standard først
I denne fase bliver løsningen bygget op: selskaber, finansopsætning, dimensionsstruktur, nummerserier, bankkonti, momsopsætning, lagerlokationer, vareopsætning, bogføringsgrupper, brugere og rettigheder.
Det er her, mange SMV’er får mest værdi ved at vælge standardfunktionalitet, også selv om det kræver små ændringer i arbejdsgange. Standard betyder hurtigere implementering, enklere test og mindre vedligehold ved fremtidige opdateringer.
Et godt designprincip er at skelne mellem tre typer ændringer:
- Opsætning: valg i BC, der kan ændres igen uden kode
- Udvidelser: apps eller add-ons, der kan opdateres kontrolleret
- Tilretninger: specialudvikling, som kræver disciplin og governance
Det sidste punkt kan være nødvendigt, men det bør være en bevidst beslutning med konsekvensvurdering.
Fase 3: Datamigrering, oprydning og cutover-plan
Datamigrering er sjældent “bare et import-job”. Det er et kvalitetssikringsprojekt, hvor gamle fejl ellers bliver flyttet med over i et nyt system, og så rammer de hårdere, fordi processerne hænger tættere sammen.
Start med at beslutte datamængde: Skal I migrere historik, eller er saldi og åbne poster nok? Mange SMV’er vælger en pragmatisk model, hvor man tager nødvendige stamdata, åbningsbalancer, åbne debitorer/kreditorer og åbne ordrer, og så arkiverer historik i et læsevenligt format.
Dernæst kommer cutover-planen: Hvem gør hvad i “lukke-vinduet”? Hvornår stoppes bogføring i det gamle system? Hvornår tages sidste backup? Hvem godkender at tallene stemmer?
En praktisk måde at styre migreringen på er at lave en dataliste med klare ejere og valideringsregler:
- Stamdata: debitorer, kreditorer, varer, kontoplan, dimensioner
- Åbne poster: fakturaer, kreditnotaer, betalinger, rykkere
- Saldi: bank, mellemregninger, lager, periodiseringer
- Dokumenter: åbne salgs- og indkøbsordrer, igangværende projekter
Fase 4: Integrationer og add-ons, kontrolleret og testbart
De fleste SMV’er har et økosystem omkring ERP: webshop, EDI, betaling, bank, fragt, løn, tidsregistrering, BI og dokumenthåndtering. En af de mest oversete opgaver er at beskrive integrationerne med samme præcision som kerneprocesserne.
Tænk i “hvad skal flyde hvornår”: Skal ordre komme ind som kladde eller som bogføringsklar ordre? Skal lageropdatering ske i realtid eller batch? Hvad er masterdata, og hvor vedligeholdes det?
Når add-ons er relevante, giver det ofte mening at vælge velafprøvede løsninger og holde antallet nede i første release. Eksempler kan være løsninger til dokumenthåndtering og godkendelsesflows, elektroniske bilag, bankintegration eller rapportering, afhængigt af jeres behov og branche.
Fase 5: Test og UAT, så fejl fanges før drift
Test er ikke en formalitet. Det er det sted, hvor beslutninger bliver til virkelighed, og hvor “det virkede på workshop” bliver prøvet af i praksis.
Del test op i mindst to spor: integrationstest (system til system) og UAT (brugernes arbejdsgange). UAT bør drives af superbrugere med faste testcases og klare acceptkriterier, ikke som tilfældige klikrunder.
En enkel testpakke kan bygges op omkring de processer, der påvirker økonomi og leverancer mest:
- Order-to-cash: tilbud, ordre, levering, faktura, betaling, rykker
- Procure-to-pay: indkøb, modtagelse, faktura, godkendelse, betaling
- Perioder: moms, afstemninger, periodiseringer, månedsafslutning
- Undtagelser: kreditgrænse, restordrer, retur, prisafvigelser
Fase 6: Træning og forankring hos brugerne
Træning virker bedst, når den er rollebaseret og tager udgangspunkt i jeres egne data og scenarier. En bogholder har brug for en anden gennemgang end en indkøber, og en lagermedarbejder skal trænes i scanning, registreringer og afvigelser, ikke i finansopsætning.
Superbrugere er nøglen. De skal have tid i kalenderen, adgang til testmiljø og mandat til at sige, når noget ikke giver mening.
Kommunikation er en del af implementeringen.
Det kan også betale sig at planlægge “mikro-leverancer” i ugerne op til go-live: korte sessioner, hvor en proces gennemgås, prøves og justeres, frem for store kursusdage, der glemmes igen.
Fase 7: Go-live, hypercare og drift uden panik
Go-live handler om kontrol, ikke mod. De bedste go-live-forløb er dem, hvor der er taget stilling til driftsspørgsmål på forhånd: supportkanal, prioritering af fejl, hvem må ændre opsætning, og hvordan kommunikeres status til organisationen.
I hypercare-perioden giver det mening at have daglige check-ins med de vigtigste funktionsområder, så små problemer ikke bliver til flaskehalse. Samtidig bør I beskytte driften ved at begrænse ændringer i de første uger, medmindre de er kritiske.
Efter stabilisering kan I åbne backloggen igen og planlægge næste bølge: automatisering, flere integrationer, nye rapporter eller udvidelse til flere selskaber.
Realistisk tidsplan og ressourcebehov for SMV’er
Tidsforbrug afhænger mest af kompleksitet, datakvalitet og beslutningshastighed. Mange mindre virksomheder kan gå i drift på 2 til 3 måneder ved et stramt scope, mens en mere kompleks SMV ofte ligger på 3 til 6 måneder.
Nedenstående skabelon kan bruges som udgangspunkt, når I skal planlægge ressourcer og tempo:
| Fase | Typisk varighed (SMV) | Primære leverancer | Nøgle-roller |
|---|---|---|---|
| Fase 0: Forberedelse | 1 til 2 uger | Scope, milepæle, governance, blueprint | Sponsor, projektleder, nøglebrugere, konsulent |
| Fase 1: Krav og gap | 2 til 4 uger | Procesbeskrivelser, gap-liste, løsningsdesign | Nøglebrugere, funktionsansvarlige, konsulent |
| Fase 2: Opsætning | 2 til 6 uger | Konfiguration, roller, basisdata, miljøer | Konsulent, økonomi, lager, IT |
| Fase 3: Data og cutover | 1 til 3 uger + cutover | Dataskabeloner, validering, cutover-plan | Dataansvarlig, økonomi, konsulent |
| Fase 4: Integrationer | 1 til 4 uger (overlap) | Integrationer, add-ons, end-to-end flow | IT, leverandører, konsulent |
| Fase 5: Test og UAT | 1 til 3 uger | Testcases, fejlrettelser, accept | Superbrugere, konsulent, IT |
| Fase 6: Træning | 2 til 6 uger (overlap) | Rolletræning, vejledninger, Q&A | Superbrugere, ledelse, konsulent |
| Fase 7: Go-live og hypercare | 1 til 2 uger + support | Driftssætning, overvågning, stabilisering | Projektteam, superbrugere, support |
Typiske faldgruber, og hvordan de afværges
De fleste problemer kan spores tilbage til få mønstre: for meget scope, for lidt test, for sene dataafklaringer og uklare beslutningsveje. Når I kender mønstrene, kan I designe projektet, så de bliver svære at falde i.
Her er en kort, praktisk huskeliste, som ofte flytter mest:
- Uklart ejerskab og beslutningsret
- Tilretninger som standardløsning
- Stamdata uden ansvarlige ejere
- Integrationer, der først beskrives sent
- Træning planlagt som engangsaktivitet
Hvad en partner typisk hjælper med, fra plan til drift
Mange SMV’er har stærke nøglepersoner, men begrænset tid og begrænset ERP-erfaring internt. En implementeringspartner kan derfor give mest værdi ved at styre projektet stramt, drive afklaringerne frem og sikre, at løsningen kan opdateres og videreudvikles uden at miste kontrollen.
Et dansk konsulenthus som Naviteam arbejder typisk på tværs af hele forløbet: struktureret implementering med klare milepæle, governance omkring scope og ændringer, procesworkshops, dataflytning og validering, testplan og cutover, træning af brugere og superbrugere samt support efter go-live. Når der er behov for udvidelser, vælger man ofte velkendte add-ons i samarbejde med partnere, eksempelvis løsninger fra Continia, ForNAV eller Little Beacon, så funktionalitet kan tilføjes uden at gøre grundplatformen skrøbelig.
Det vigtigste valg er sjældent “cloud eller on-prem” eller “hvilken app”. Det er at få en arbejdsform, hvor I leverer i små, sikre skridt, og hvor Business Central bliver en del af hverdagen, ikke et sideprojekt ved siden af driften.
Kontakt og næste skridt
Har I spørgsmål, ønsker sparring eller vil I i gang med en afklarende dialog, er I velkomne til at kontakte os direkte. I kan finde kontaktformular og flere oplysninger her: navi-team.dk/kontakt.