Migrasjon fra Visma Business eller Visma Global til Microsoft Dynamics 365 Business Central (eller Finance & Operations for større selskap) er en av de vanligste ERP-bevegelsene i Norge i dag. Visma har sluppet store deler av sin gamle Business-portefølje i pleie-modus, og selskaper som vokser ut av Visma eXpert eller Global ser ofte til Dynamics, IFS eller SAP.
Etter mange diskusjoner med selskap som er midt i denne migrasjonen — og noen som har vært gjennom den — er det fem fallgruver jeg ser oftere enn andre. De handler ikke om Dynamics i seg selv; de handler om hva as-is-mappingen burde ha fanget opp, men ikke gjorde.
Fallgruve 1: Du undervurderer Excel-mellommodellene
Visma Business er en gammel plattform, og store deler av forretningen kjøres i Excel-modeller som henter ut data, prosesserer dem, og laster dem tilbake. Hver gang vi gjør as-is hos Visma-kunder, finner vi mellom 5 og 20 Excel-modeller som er kritiske for daglig drift, men som ingen har dokumentert.
Når man flytter til Dynamics, er det fristende å si "alt skal kjøres i ERP-en". Men hvis du ikke har kartlagt hva Excel-modellene faktisk gjør — hvilke kalkulasjoner, hvilke business rules, hvilke unntakshåndteringer — vil de overleve migrasjonen som skygger-IT.
Hva du bør gjøre: Be hver økonomi- og innkjøps-ansatt liste opp alle Excel-arbeidsark de bruker i daglig drift. Sjekk hver enkelt: hva henter den, hva gjør den, hvor sender den dataene videre. Inkluder dette i as-is.
Fallgruve 2: Du tror Visma-tilpasninger er enkle å oversette
Mange Visma-installasjoner har egne tilpasninger — egne moduler, custom-kolonner i tabeller, integrasjoner via VismaConnect eller direkte ODBC, lokale skript. Konsulenten som solgte Dynamics-migrasjonen estimerte sannsynligvis basert på en standard-mal, ikke på dine faktiske tilpasninger.
Hva du bør gjøre: Be Visma-leverandøren eller intern IT om en komplett liste over tilpasninger. For hver tilpasning: hvorfor er den der, hvem bruker den, hva skjer hvis den forsvinner. Ikke alle skal med videre — men du må vite hva som er på spill.
Fallgruve 3: Kontoplan-mapping behandles som teknisk øvelse
Migrering av kontoplan ser ut som teknisk arbeid. Det er det ikke. Visma-installasjoner har ofte vokst over år, og kontoplanen reflekterer ting som ikke står andre steder: hvilke konti som brukes for periodisering, hvilke som er "samle-konti" for ting ingen ville lage egen konto for, hvilke som er døde fra fjerde omorganisering men fortsatt brukes av én avdeling.
Hvis du gjør en mekanisk én-til-én-mapping mellom Visma-konti og Dynamics-konti, mister du betydningen. Det vil dukke opp i avstemming og rapportering måneder etter go-live.
Hva du bør gjøre: For hver konto i Visma, dokumenter formålet, eieren, og hvordan den brukes. Diskuter med revisor om migrasjonen er anledningen til å rydde i kontoplanen.
Fallgruve 4: MVA- og A-melding-konfigurering forutsettes "standard"
Norge har spesifikke krav til MVA-rapportering og A-melding. Visma har bygd dette inn over år. Dynamics har norsk lokalisering, men den er ikke alltid satt opp riktig "out of the box" — særlig hvis du bruker Finance & Operations versus Business Central.
Vi har sett tilfeller der MVA-koder, importkjøp, omvendt avgiftsplikt eller mva-fritak for spesifikke produkter ikke var konfigurert riktig før go-live. Konsekvensen er feil på MVA-meldingen, som er korrigerbar, men også tidkrevende.
Hva du bør gjøre: Lag en komplett liste over alle MVA-scenarier dere har: innenlands omsetning, EU-eksport, tredjelandseksport, omvendt avgift, MVA-fritak, gevinstavgift, særavgifter. For hver: hvilken kode brukes, hvilken regel ligger bak. Inkluder dette i as-is, ikke i siste sprint før go-live.
Fallgruve 5: Manuelle godkjenningsflyt-er ignoreres
I Visma kjøres godkjenninger ofte som e-post-vedlegg eller utskrift med signaturer. Dynamics har innebygde workflow-funksjoner som er gode, men de må konfigureres etter den faktiske godkjenningsterskel-strukturen — som ofte ikke står skrevet noe sted.
Vi har sett selskap med faktiske godkjenningsregler som "Lise godkjenner under 10 000, Per godkjenner 10 000–50 000, daglig leder over 50 000, men hvis det er en av våre tre nøkkelleverandører, går alt direkte til daglig leder uansett beløp". Hvis dette ikke fanges i as-is, blir det konfigurert som "Lise <10k, Per <50k, DL >50k" — og en kritisk forretningsregel går tapt.
Hva du bør gjøre: For hver type godkjenning (innkjøp, faktura, ansettelse, lønnsendring), kartlegg alle terskelregler, unntak og spesialtilfeller. Skriv det ned. Sjekk med faktisk praksis, ikke bare med policy-dokumenter.
Når as-is gjøres skikkelig
Når as-is gjøres skikkelig før Dynamics-migrasjon, ser typisk gevinsten slik ut:
- 20–40 % færre endringsbestillinger etter design-fasen
- Færre overraskelser i UAT
- Lavere risiko for at en kritisk prosess "mister" funksjonalitet
- Bedre grunnlag for change management — fordi du faktisk vet hva som endres
Det føles som ekstra arbeid før prosjektet starter. Det er ekstra arbeid som tas ut av prosjektet senere. For en grundigere gjennomgang av hva as-is-mapping skal inneholde, se denne artikkelen.
Hva NorthControl leverer i Visma-til-Dynamics-kontekst
For selskap som vurderer eller planlegger Visma-til-Dynamics, kan vi levere as-is-mapping av kjerneprosesser i åpne formater som integratoren kan jobbe videre med. Du eier dokumentasjonen, og den følger ikke med ett spesifikt firma.
Typisk omfang er 3–8 kjerneprosesser kartlagt over 2–4 uker. Se pakkene eller se et eksempel på en leveranse.
Oppsummering
Visma-til-Dynamics-migrasjonen er teknisk håndterbar. Det som typisk får prosjekter til å sprekke er ikke teknologi — det er mangel på as-is-forståelse av kompleksiteten i den eksisterende installasjonen. Excel-mellommodeller, tilpasninger, kontoplan-historikk, MVA-konfigurering og uskrevne godkjenningsregler er de fem mest vanlige stedene der as-is må gå dypt.
Hvis du er midt i denne reisen og vurderer om du skal investere i en uavhengig as-is — ja, det bør du gjøre. Spørsmålet er bare hvor mye dybde du trenger.