Hvordan velger du riktig partner for Dynamics 365 Business Central?

Kort svar: partnerfeltet er bredest her av alle Dynamics-områder, noe som gjør størrelsesmatchingen til den viktigste seleksjonen. Dere skal være en kunde som er synlig hos leverandøren, ikke den minste hos en stor eller den største hos en liten. Ta deretter utgangspunkt i hvilket system dere forlater, finn ut hvilke apper som er inkludert og hvem som eier dem, og kontroller hvordan partneren håndterer Business Centrals to store oppdateringssykluser per år og de mindre løpende oppdateringene.

Denne guiden er skrevet av d365 Guide. Vi implementerer ikke Dynamics 365 og vi selger ingen lisenser. Vi finnes for at kjøperen skal kunne sammenligne partnere på samme grunnlag.

Den gjelder spesifikt Business Central. For utvelgelsesprosessen generelt, uansett applikasjon, se vår guide om hvordan du finner riktig partner for Dynamics 365 i Norge.

Hva som kjennetegner denne anskaffelsen

Business Central er Microsofts forretningssystem for små og mellomstore selskaper, med røtter i Navision. d365 Guide vurderer at det tilkommer i størrelsesorden fem hundre nye avtaler per år i Norge, og at prosjektene ofte starter rundt tre hundre tusen NOK. Det gjør det til den vanligste Dynamics-implementeringen i landet. Tallene er d365 Guide sin markedsbedømmelse, oppdatert i september 2026, ikke offisiell Microsoft-statistikk.

Partnerfeltet er samtidig det bredeste. Det finnes dusinvis av norske partnere, fra selskaper med noen få konsulenter til nordiske konsern med hundrevis. Dette er gode nyheter for deres forhandlingsposisjon og dårlige nyheter for utvalget, ettersom forskjellen mellom kandidatene sjelden synes i tilbudet.

Den lave inngangskostnaden er anskaffelsens største felle. En Business Central-implementering kan ofte komme i gang relativt raskt, og nettopp derfor blir partneren noen ganger gransket lettvint. Kostnaden for et svakt valg vises ikke alltid i prosjektbudsjettet. Den vises senere i forvaltningsavgifter, tillegg og tilpasninger som skal vedlikeholdes over tid.

Trinn 1: Ta utgangspunkt i hva dere skal erstatte

Kravlisten blir omtrent den samme uansett utgangspunkt, men arbeidet som skal utføres skiller seg, og dermed hvilken partner som passer.

Utgangspunktet påvirker også hvordan dere bør lese et estimat. Et bytte fra NAV kan se billig ut fordi mye er gjenkjennelig, men den gamle løsningens tilpasninger er ofte det som trekker tid. Et bytte fra et lite økonomisystem ser dyrt ut, men mye av kostnaden er virksomhetens eget arbeid med prosesser som ikke har eksistert før.

Trinn 2: Match størrelsen

Dette er den enkelt viktigste seleksjonen i Business Central-segmentet, og den det er lettest å gjøre feil med.

Velger dere en betydelig større partner enn dere selv er, risikerer dere å bli en liten kunde: junior konsulenter, lav prioritet i forvaltningen og en kunderådgiver som byttes ut. Velger dere en svært liten partner, får dere ofte seniorpersoner og stort engasjement, men sårbarhet hvis en nøkkelperson slutter, og begrenset utholdenhet hvis dere vokser eller skal ut i flere land.

Still to spørsmål som gir raskt svar:

• Hvor i kundebasen deres ville vi havnet størrelsesmessig? En partner som svarer ærlig på det, sier også noe om hvor mye oppmerksomhet dere vil få.
• Hvor mange kunder har den konsulenten som blir vår i sin forvaltningsportefølje? I dette segmentet bærer en konsulent ofte mange kunder samtidig, og det avgjør svartidene i praksis.

Geografien veier mindre enn den pleide, men ikke null. Under design og idriftsettelse er det verdt en del å kunne møtes.

Trinn 3: Standard, apper og tilpasninger

Business Central bygges ut med tillegg, ikke gjennom endringer i systemets kjerne. Det høres ut som en teknisk detalj, men styrer både kostnad og smidighet.

Tre forskjellige ting blandes vanligvis sammen i et tilbud, og de har helt forskjellige konsekvenser:

• Konfigurasjon i standard. Følger normalt med gjennom Microsofts oppdateringer og kan vanligvis forvaltes videre av en annen kvalifisert Business Central-partner. Dette bør være hoveddelen av løsningen.
• Ferdige apper fra Microsofts kommersielle markedsplass eller fra en ISV. Lisensmodellen kan være per bruker, per tenant eller bygge på andre mål. En generell ISV-app kan normalt brukes videre selv om dere bytter implementeringspartner, men kontroller lisensavtale, supportansvar og om appen eller avtalen er knyttet til den nåværende partneren.
• Tilpasninger bygget kun for dere. Kan være helt riktig, men de skal vedlikeholdes av noen ved hver oppdatering, og den noen er i praksis oftest den som bygde dem.

Be om en skriftlig oppdeling av hva som er hva, per funksjonsområde. Mange partnere har egne bransjeapper, og det er ofte det de faktisk selger. Det trenger ikke å være et problem: en gjennomarbeidet bransjeapp kan spare mye. Men dere bør vite at den er der, hva den koster løpende og hva som skjer med den hvis samarbeidet avsluttes.

Trinn 4: Oppdateringene to ganger i året

Microsoft har to store oppdateringssykluser for Business Central per år, med større versjoner i april og oktober. I tillegg kommer mindre oppdateringer løpende, normalt månedlig. I skyversjonen kan dere planlegge en større oppdatering innenfor det tilgjengelige oppdateringsvinduet, men dere kan ikke velge bort at tjenesten holdes oppdatert. Det er en tydelig forskjell fra eldre forretningssystemer og et spørsmål der forskjellen mellom partnere merkes tidlig etter idriftsettelse.

Spør hver kandidat hvordan de arbeider med dette: om de har et testmiljø der deres løsning kontrolleres før oppdateringen trer i kraft, hvilke flyter som testes, om det inngår i forvaltningsavtalen eller faktureres separat, og hvordan de informerer dere om ny funksjonalitet som dere faktisk kan ha nytte av.

En partner som ikke har en rutine her, vil håndtere hver oppdatering som en hendelse, og dere betaler for den.

Trinn 5: Spørsmål å stille, og hvordan svarene skal leses

Følgende spørsmål er formulert for ikke å ha et selvfølgelig godt svar. Bedømmelsen av svaret er minst like viktig som spørsmålet.

1. Hvor mange Business Central-kunder har dere satt i drift de siste to årene, og hvor mange ligner oss?

Andre del av spørsmålet er den viktige. Antallet kunder totalt sier lite når feltet er så bredt.

Gode svar inneholder:

• Et tall, med kunder i deres størrelsesklasse og bransje som kan kontaktes.
• Et skille mellom nye implementeringer og overtatte forvaltninger.

Varseltegn:

• Svaret glir over i selskapets historikk i Navision.
• Alle referanser er betydelig større eller mindre enn dere.

2. Hvilke apper er inkludert, hvem eier dem og hva koster de løpende?

Dette avgjør både månedskostnaden og hvor låst dere blir.

Gode svar inneholder:

• En liste med leverandør, avgift per bruker og måned, og hvem dere tegner avtale med.
• En klar beskjed om hva som skjer med hver app hvis dere bytter partner.

Varseltegn:

• Partnerens egne apper presenteres som en del av løsningen uten separat prismerking.
• Kostnadene fremgår først i avtalevedleggene.

3. Hvor mye blir konfigurasjon og hvor mye blir egen kode?

Se trinn 3. Spørsmålet avgjør hva forvaltningen koster over tid.

Gode svar inneholder:

• En oppdeling per funksjonsområde, skriftlig.
• Forslag til hvor dere bør tilpasse dere standard i stedet for omvendt, med begrunnelse.

Varseltegn:

• Alt dere ønsker kan bygges, uten innvendinger.
• Mengden egen kode presenteres utelukkende som en styrke.

4. Hvem blir vår konsulent, og hvor mange kunder har den personen?

I dette segmentet er det sjelden et stort team. Ofte er det en eller to personer, og disse personene er i praksis hele leveransen.

Gode svar inneholder:

• Navn, erfaring og et møte før avtaleinngåelse.
• En ærlig beskjed om porteføljestørrelse og hva som skjer ved ferie og sykdom.

Varseltegn:

• Konsulenten tilsettes etter avtaleinngåelse.
• Dere har bare truffet en selger etter flere møter.

5. Hvordan håndterer dere Microsofts oppdateringer?

Se trinn 4. Svaret skal inneholde en rutine, ikke et prinsipp.

Gode svar inneholder:

• En beskrevet testrutine med miljø og hvilke flyter som kontrolleres.
• Beskjed om det inngår i avtalen eller faktureres.

Varseltegn:

• Oppdateringer beskrives som noe Microsoft ordner for dere.
• Spørsmålet har ikke kommet opp hos andre kunder.

6. Hvordan ser migreringen fra vårt nåværende system ut?

Datamigrering er den vanligste årsaken til at en idriftsettelse utsettes, selv i mindre prosjekter.

Gode svar inneholder:

• Beskjed om hva som flyttes og hva som blir: saldi, åpne poster, historikk og stamdata behandles forskjellig.
• Antall testmigreringer og når den første skjer.

Varseltegn:

• All historikk loves uten diskusjon om hva det koster.
• Datakvalitet nevnes ikke som deres ansvar overhodet.

7. Hva kan vi gjøre selv uten å ringe dere?

I et mindre selskap er svaret på det spørsmålet avgjørende for hvordan systemet oppleves i hverdagen.

Gode svar inneholder:

• En avgrensning av hva en superbruker hos dere kan endre selv, og opplæring for det.
• Dokumentasjon som dere eier og kan gi til noen andre.

Varseltegn:

• Hver rapport og feltendring krever en bestilling.
• Ingen intern superbruker planlegges inn i prosjektet.

Meritter som måler noe annet enn du tror

• Erfaring med Navision eller NAV er ikke det samme som erfaring med Business Central i skyen. Utbyggingsmodellen og oppdateringstakten er annerledes.
• Sertifiseringer er knyttet til personer, ikke til selskaper. Spørsmålet er om de sertifiserte personene er de som blir deres.
• Microsofts partnerbetegnelser bygger siden 2022 på Solutions Partner-designasjoner. Begrepet gullkompetanse finnes ikke lenger.
• Utmerkelser fra Microsoft reflekterer partnerens forhold til Microsoft. De er ikke kundetilfredshetsmålinger.
• Antallet konsulenter i selskapet sier ingenting om hvor mange som er tilgjengelige når prosjektet deres starter.

Hva som pleier å gå galt i selve utvalget

• Tilbud sammenlignes på pris uten at apper og løpende avgifter regnes med, noe som gjør det billigste tilbudet dyrest over tre år.
• Kravlisten beskriver dagens arbeidsmetoder i detalj, noe som bygger inn gamle problemer i det nye systemet.
• Forvaltningen utelates fra anbudet og prissettes når dere ikke lenger har forhandlingsmakt.
• Ingen intern superbruker utpekes, noe som gjør dere avhengige av partneren for småting.
• Størrelsesmatchingen vurderes aldri, til tross for at den er den faktoren som skiller kandidatene mest.
• Beslutningen tas uten at noen som skal arbeide i systemet daglig har prøvd det.

En anmerkning om kilder

Mesteparten av det som publiseres i Norge om hvordan man velger partner for Dynamics 365, er skrevet av partnere. Materialet er ofte kompetent, men det er skrevet av en part med interesse i utfallet, og kriteriene havner derfor gjerne nær egen profil.

Les flere kilder, og spør dere hvem som har nytte av at nettopp de kriteriene veier tyngst.

Neste trinn

Skriv ned hvilket system dere forlater, hvor mange brukere dere har og hva som skal være løst om ett år. Med de tre svarene blir leverandørsamtalene kortere, og forskjellene mellom kandidatene synes tidligere.

Er virksomheten på vei mot konsernstruktur i flere land, kan det være verdt å samtidig forstå nivået over: se guiden om partnervalg for Finance & Supply Chain Management. Skal dere også se over CRM, finnes separate guider om Dynamics 365 Sales og Customer Service og Field Service.

På d365 Guide kan dere sammenligne norske Dynamics 365-partnere per applikasjonsområde, bransje og størrelse, og avgrense feltet før dere begynner å booke møter.