Hvordan velge riktig partner for Dynamics 365 Finance & Supply Chain Management?

Kort svar: ikke start med partnerens merittliste, men med hva dere skal forlate. Et konsern som bytter fra AX 2012 stiller helt andre krav til leverandøren enn et som forlater SAP eller konsoliderer fem forskjellige systemer. Feltet av partnere med reell kapasitet er lite, så tyngdepunktet i evalueringen ligger på personene i teamet, på hvordan leveransen er organisert mellom land, og på hvem som forvalter løsningen når prosjektet er slutt.

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 Finance & Supply Chain Management. For utvelgelsesprosessen generelt, uavhengig av applikasjon, se vår guide om hvordan du finner riktig partner for Dynamics 365 i Norge.

Hva som kjennetegner denne anskaffelsen

Finance & Supply Chain Management er Microsofts enterprise-gren, med røtter i Axapta og senere AX. Systemet er bygget for konsern med flere juridiske enheter, komplekse vareflyter og virksomhet i flere land. Det merkes i alt: prosjektenes størrelse, tidsbruken, antallet involverte og hvor få leverandører som faktisk kan levere.

Et par størrelsesordener som ramme, og som er d365 Guide sin vurdering av det norske markedet. Prosjektene starter normalt rundt fem millioner NOK og løper over flere år regnet fra forstudie til stabil drift. Vi vurderer at det finnes i størrelsesorden hundre kundekonsern i Norge som kjører systemet eller dets forgjengere, og at det kommer til i størrelsesorden femti nye avtaler per år. d365 Guide har identifisert flere aktører med F&SCM-kompetanse, men for større norske flerfirma- eller internasjonale end-to-end-programmer vurderer vi at gruppen med tilstrekkelig kapasitet er omtrent et titalls. Tallene er vår markedsvurdering, oppdatert i september 2026, ikke offisiell Microsoft-statistikk.

Det får en konsekvens som sjelden uttales: rene nysalgsavtaler er uvanlige. Mange partnere søker seg i stedet inn i eksisterende kunder gjennom konsulentutleie, gjennom en bedre forvaltningsavtale eller ved å overta videreutviklingen, og utvider deretter oppdraget land for land.

For dere som kjøper betyr det to ting. Konkurransen om prosjektet deres er mindre enn dere tror, noe som senker forhandlingsposisjonen deres. Og den partneren dere velger vil sannsynligvis være hos dere i mange år, ettersom bytte av leverandør midt i en installasjon av denne størrelsen er dyrt og risikabelt. Evalueringen må derfor være skarpere, ikke mildere, enn ved en mindre anskaffelse.

En terminologisk sak som påvirker omfanget

Finance og Supply Chain Management er to separate applikasjoner som lisensieres hver for seg, selv om markedet og de fleste partnere snakker om dem som ett system. Klargjør tidlig hvilke av modulene dere faktisk skal ha, ettersom det påvirker både lisenskostnad og hvilken kompetanse som trengs i teamet. Det samme gjelder tilgrensende applikasjoner som Project Operations og Human Resources, som ofte sniker seg inn i omfanget under forstudien.

Steg 1: Gå ut fra hva dere skal erstatte

Dette er den viktigste avgrensningen, og den som oftest hoppes over. Kravlisten blir omtrent den samme uansett utgangspunkt, men arbeidet som skal utføres skiller seg fundamentalt, og dermed også hvilken partner som passer.

Hvis dere forlater AX 2012 eller AX 2009

Dette er det vanligste utgangspunktet i Norge. AX 2012 ligger siden flere år utenfor Microsofts ordinære support, og de fleste som fortsatt kjører det har skjøvet beslutningen foran seg av gode grunner: systemet fungerer, det er tungt tilpasset og det er dypt integrert i virksomheten.

For AX 2012 R2 og R3 finnes en Microsoft-støttet oppgraderingsvei til Finance and Operations som kan ta med både data og kode. Det betyr derimot ikke at alt bør flyttes uendret. En sentral del av forstudien er å avgjøre hva som skal oppgraderes, hva som skal bygges om og hvilke gamle tilpasninger og prosesser som bør etterlates. AX 2009 følger ikke den samme støttede oppgraderingsveien og skal derfor vurderes som et migreringsscenario med andre forutsetninger.

Det dere skal se etter er en partner som har gjort akkurat denne reisen flere ganger, og som kan vise hvordan de går frem for å avgjøre hvilke gamle tilpasninger som skal med. En vanlig og kostbar feil er å bygge tilbake alt som fantes, av frykt for at noen skal savne noe.

Merk også at lang erfaring med AX ikke automatisk er det samme som dyp erfaring med dagens Finance og Supply Chain Management. Plattform, extensionsmodell, drift og oppdateringsmodell har endret seg. Vurder derfor hvor mange moderne implementeringer, oppgraderinger og go-live personen faktisk har gjennomført, ikke bare antall år i AX.

Hvis dere forlater SAP, IFS eller et annet større ERP

Her finnes ingen legacykode å forholde seg til, noe som høres enklere ut enn det er. Arbeidet flyttes i stedet til prosessdesign og til å oversette virksomhetens begreper til en ny struktur. Kontoplan, produktdata, kundestruktur og lagerlogikk ser sjelden ut som dere er vant til, og organisasjonen vil oppleve det.

Partneren må her ha erfaring med å lede den typen oversettelse, ikke bare med å konfigurere systemet. Spør spesielt hvordan de arbeider med virksomhetens nøkkelbrukere under designfasen, og hvor mye av den tiden som ligger hos dere.

Hvis dere konsoliderer flere systemer i et konsern

Da er det ikke et prosjekt, det er et program. Spørsmålet blir hva som skal være felles kjernemal og hva hvert selskap får bestemme selv, og det er et styringsspørsmål like mye som et teknisk spørsmål.

En partner som skal levere dette må kunne beskrive sin mal- og utrullingsmodell konkret: hvordan malen forvaltes, hvordan avvik håndteres, hvordan lokale krav i ulike land bygges inn, og hva et annet og tredje land faktisk koster sammenlignet med det første. Be om tall fra en tidligere kunde, ikke om en prinsippbeskrivelse.

Hvis dere synes Business Central er blitt for lite

Dette er utgangspunktet hvor vi oftest ser feil konklusjon. Mangelen ligger ikke sjelden i et fåtall prosesser, i integrasjoner som aldri ble ferdige, eller i at systemet ble konfigurert for en virksomhet som dere siden vokste fra.

Et bytte oppover løser det, men til en helt annen kostnad og kompleksitet enn å utbedre det som faktisk plager. Den partneren dere spør har normalt en interesse i svaret. Sørg derfor for at analysen gjøres av noen som tjener like mye på begge utfall, eller gjør den internt.

Hvis konklusjonen blir at dere blir værende, er det i stedet partnervalg på det nivået som skal vurderes. Vi går gjennom det i guiden om hvordan du finner riktig partner for Dynamics 365 i Norge.

Steg 2: Bestem om det er et prosjekt eller et program

En F&SCM-innføring i ett selskap og en utrulling over åtte selskaper i fem land er ikke det samme. Likevel anskaffes de ofte likt, og avvikene viser seg først når land nummer to skal i gang.

Klargjør før dere går ut:

• Hvor mange juridiske enheter og land omfattes, og i hvilken rekkefølge?
• Hva skal være felles og hva kan skille seg mellom selskapene?
• Hvem hos dere eier malen etter første go-live?
• Skal partneren levere alle land, eller skal dere kunne bruke lokale ressurser i enkelte?

Svarene styrer hvilken type leverandør som er rimelig. En partner uten egen tilstedeværelse utenfor Norden kan fortsatt levere en utrulling, men da skal det fremgå hvordan, og hvem de samarbeider med.

Steg 3: Bygg en langliste uten å gjøre feltet unødvendig smalt

Det sies ofte at F&SCM krever en av de globale systemintegratorene. Det stemmer ikke for norske forhold. De største aktørene har dype ressurser og global rekkevidde, men det finnes også mellomstore nordiske partnere med lang F&SCM-historikk og betydelig høyere andel senior konsulenter i sine team.

Det som virkelig sorterer er ikke selskapets størrelse, men tre ting:

• Antallet go-live på Finance and Operations de siste tjuefire månedene. Ikke antallet kunder totalt, og ikke AX-historikken.
• Om de har levert noe som ligner deres utgangspunkt, altså samme type bytte fra samme type system.
• Om de kan bemanne dere med seniorpersoner uten å tømme et annet pågående prosjekt.

Fire til seks kandidater er et rimelig utgangspunkt. Flere blir vanskelig å evaluere på det dypet som kreves, og færre gir dere ingen sammenligning i det hele tatt.

Steg 4: Evaluer teamet, ikke selskapet

I et prosjekt av denne størrelsen er det ikke leverandøren dere kjøper, det er et arkitektteam. Forskjellen mellom to partnere i samme prisklasse sitter nesten alltid i personene.

Løsningsarkitekten

Prosjektets viktigste rolle. Arkitekten binder sammen konsernets økonomiske struktur, altså konsernregnskap, internprising og felles funksjoner, med de operative flytene. Be om CV, spør hvilke av personens nyeste prosjekter som gikk i produksjon, og snakk med arkitekten selv før dere skriver avtale.

Oppdelingen økonomi og supply chain

Det er uvanlig at samme konsulent er sterk i både den avanserte økonomimodellen og i tung logistikk eller produksjon. Evaluer derfor teamet som helhet, og be om CV på dem som skal sette opp de modulene dere faktisk er avhengige av. Har dere avansert lagerstyring, produksjon eller global innkjøpslogistikk skal det finnes navn knyttet til hvert slikt område.

Prosjektleder og endringsleder

Prosjektlederen bør ha drevet minst én innføring av sammenlignbar størrelse hele veien til stabil drift, ikke bare til go-live. Endringsledelsen er ikke et mykt spørsmål i dette systemet: F&SCM oppleves som komplekst av dem som skal arbeide i det daglig, og adopsjonen avgjør om investeringen gir noe.

Steg 5: Gransk leveransemodellen

Nesten alle større partnere kombinerer konsulenter i Norge med ressurser i andre land. Det er ikke et problem i seg selv, og en leveranse fullt bemannet med norske seniorkonsulenter blir svært dyr uten å nødvendigvis bli bedre.

Det som avgjør er hvor i prosjektet grensen går. Analyse, design og de beslutningene som former løsningen bør ligge nær virksomheten og på et språk der nyanser ikke forsvinner. Konfigurering, utvikling, datavask og testing fungerer godt å legge til et etablert senter i et annet land.

Spør rett ut hvordan teamet er sammensatt, i hvilke tidssoner det arbeider, og hvem som skriver kravspesifikasjonen som utviklerne deretter bygger etter. Det er i den overleveringen de dyre misforståelsene oppstår.

Steg 6: Spørsmål å stille, og hvordan svarene skal leses

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

1. Hvor mange go-live har dere hatt på Finance and Operations de siste to årene?

Dette er det enkeltvis mest informative spørsmålet i hele evalueringen, og det som oftest besvares svevende.

Gode svar inneholder:

• Et tall, med kunder som kan navngis og gjerne kontaktes.
• Et skille mellom nye innføringer, utrullinger til ytterligere land og overtatte forvaltninger.

Varseltegn:

• Svaret glir over i antallet kunder totalt eller i selskapets historikk i AX.
• Referansene ligger flere år tilbake.

2. Hvem blir vår løsningsarkitekt, og får vi møte hen nå?

Arkitekten er den personen hvis beslutninger dere lever med i ti år. Å møte personen først ved oppstart er for sent.

Gode svar inneholder:

• Et navn, en CV og et møte uten selger i rommet.
• Beskjed om hvor stor del av sin tid personen har på dere, og hva hen gjør ellers.

Varseltegn:

• Arkitekten utnevnes etter avtaleinngåelse.
• Personen presenteres som arkitekt, men har i hovedsak arbeidet i AX.

3. Hvordan planlegger dere datamigreringen, og hvem eier den?

Datamigrering er et eget prosjekt inni prosjektet, og den vanligste årsaken til at go-live utsettes.

Gode svar inneholder:

• En beskrivelse av hvor mange testmigreringer som planlegges og når den første skjer.
• En tydelig ansvarsfordeling for datakvalitet, der en stor del rimeligvis ligger hos dere.

Varseltegn:

• Migreringen beskrives som en teknisk aktivitet sent i prosjektet.
• Ingen forskjell gjøres mellom saldi, historikk og stamdata.

4. Hva blir kjernemal og hva blir lokalt?

Spørsmålet gjelder alle konsern, også de som starter i ett land, ettersom malen settes ved første innføring uansett om dere kaller den det.

Gode svar inneholder:

• En konkret modell for hva som styres sentralt og hva som kan avvike.
• Erfaringstall på hva et annet land har kostet sammenlignet med det første hos en tidligere kunde.

Varseltegn:

• Spørsmålet besvares prinsipielt uten eksempel.
• Alt skal være felles, uten diskusjon om hva som skjer når et selskap ikke kan følge malen.

5. Hvordan ser teamets sammensetning ut mellom land?

Se avsnittet om leveransemodellen ovenfor. Spørsmålet skal stilles rett ut og besvares med tall.

Gode svar inneholder:

• En fordeling per rolle og fase, ikke bare en total prosentandel.
• Beskjed om hvem som skriver kravene som utviklerne bygger etter.

Varseltegn:

• Andelen lokale konsulenter presenteres høy i salgsfasen og synker i tilbudet.
• Analysefasen bemannes overveiende med ressurser som ikke møter virksomheten.

6. Hvilke tilleggs applikasjoner foreslår dere, og hvem eier forholdet?

De fleste F&SCM-løsninger inneholder apper fra tredjepart for eksempel lagerstyring, EDI, skatterapportering eller dokumenthåndtering.

Gode svar inneholder:

• En liste med hvem som er leverandør, hva det koster løpende og hvem dere har avtale med.
• Et resonnement om hva som skjer med appen hvis dere bytter implementeringspartner.

Varseltegn:

• Partnerens egne apper presenteres uten prisbilde.
• Avhengighetene fremgår først i avtalebilagene.

7. Hvordan ser forvaltningen ut, og hvem gjør videreutviklingen?

Systemet oppdateres løpende av Microsoft, og deres løsning må følge med. Forvaltningen er den fasen dere lever lengst i, og den der totalkostnaden avgjøres.

Gode svar inneholder:

• En skriftlig forvaltningsmodell med navngitt kundeansvarlig, svartider og prismodell.
• En plan for hvordan regresjonstesting håndteres ved Microsofts oppdateringer.
• Beskjed om hvorvidt forvaltningsteamet er de samme personene som prosjektteamet, og hvordan overleveringen gjøres.

Varseltegn:

• Forvaltningsavtalen diskuteres først etter at prosjektavtalen er signert.
• Videreutvikling prises utelukkende løpende, uten noen form for prioriteringsprosess.

Meritter og begreper som måler noe annet enn du tror

• FastTrack for Dynamics 365 er Microsofts kundesuksess- og rådgivningsprogram for kvalifiserte prosjekter, levert sammen med implementeringspartneren og basert på Success by Design. Det er ikke en partnersertifisering eller partnermeritt i seg selv. Erfaring med FastTrack, Implementation Portal og go-live readiness reviews kan derimot være relevant når dere vurderer partnerens vane med Microsofts implementeringskrav.
• Microsofts partnerbetegnelser bygger siden 2022 på Solutions Partner-designasjoner. Begrepet gullkompetanse finnes ikke lenger og bør ikke forekomme i et aktuelt underlag.
• Sure Step er avviklet. Microsofts aktuelle implementeringsveiledning er strukturert rundt Success by Design. En partner som fortsatt beskriver Sure Step som sin aktuelle metodikk sier noe utilsiktet om hvor ofte materialet revideres.
• Sertifiseringer er knyttet til personer, ikke til selskaper. Spørsmålet er om de sertifiserte personene er de som blir deres.
• Antallet konsulenter i selskapet sier ingenting om hvor mange av dem som er tilgjengelige når prosjektet deres starter.

Hva som pleier å gå galt i selve utvelgelsen

• Kravspesifikasjonen gjøres for detaljert for tidlig, noe som låser løsningen i den gamle verdens prosesser og driver frem tilpasninger dere deretter skal forvalte.
• Evalueringen vektes mot demo og presentasjon. Alle kandidater i dette segmentet demonstrerer bra.
• Forvaltningsfasen utelates fra anskaffelsen, selv om den utgjør størstedelen av totalkostnaden over ti år.
• Ingen intern eier utnevnes for malen, noe som gjør at partneren i praksis bestemmer hvordan konsernet skal arbeide.
• Tidsplanen settes etter en dato i virksomheten i stedet for etter hvor mange testmigreringer som faktisk trengs.
• Beslutningsgruppen er ikke enige om hvorfor byttet gjøres, noe som viser seg først under designfasen når prioriteringene kolliderer.

En anmerkning om kilder

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

I dette segmentet veier det tyngre enn i noe annet, ettersom antallet leverandører er lite og hver enkelt anskaffelse er stor. Les flere kilder, og spør dere hvem som har nytte av at akkurat de kriteriene veier tyngst.

Neste steg

Begynn med å skrive ned tre ting før dere kontakter noen leverandør: hva dere forlater, hvilke land og selskaper som omfattes i hvilken rekkefølge, og hva som skal være løst om to år. Med de tre svarene på plass blir leverandørsamtalene kortere og betydelig mer opplysende.

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.

Skal dere samtidig se over CRM-siden finnes separate guider om Dynamics 365 Sales og Customer Service og Field Service.