Hvordan vælger du den rette partner til Dynamics 365 Finance & Supply Chain Management?

Kort svar: Start ikke med partnerens meritter, men med hvad I skal forlade. En koncern, der skifter fra AX 2012, stiller helt andre krav til leverandøren end en, der forlader SAP eller konsoliderer fem forskellige systemer. Feltet af partnere med reel kapacitet er lille, så tyngdepunktet i evalueringen ligger på personerne i teamet, på hvordan leverancen er organiseret mellem lande, og på hvem der forvalter løsningen, når projektet er afsluttet.

Denne guide er skrevet af d365 Guide. Vi implementerer ikke Dynamics 365, og vi sælger ingen licenser. Vi er her, for at køberen kan sammenligne partnere på samme grundlag.

Den gælder specifikt Finance & Supply Chain Management. For udvælgelsesprocessen generelt, uanset applikation, se vores guide om, hvordan du finder den rette partner til Dynamics 365 i Danmark.

Hvad der kendetegner denne udbudsproces

Finance & Supply Chain Management er Microsofts enterprise-gren, med rødder i Axapta og senere AX. Systemet er bygget til koncerner med flere juridiske enheder, komplekse varestrømme og aktiviteter i flere lande. Det mærkes i alt: projektets størrelse, tidsforbruget, antallet af involverede, og hvor få leverandører der faktisk kan levere.

Et par størrelsesordener som ramme, og som er d365 Guide’s vurdering af det danske marked. Projekterne starter normalt omkring 3.325.000 kr. og løber over flere år regnet fra forstudie til stabil drift. Vi vurderer, at der er i størrelsesordenen hundrede kundekoncerner i Danmark, der kører systemet eller dets forgængere, og at der kommer i størrelsesordenen tredive til nye forretninger om året. d365 Guide har identificeret flere aktører med F&SCM-kompetence, men for større danske flerfirma- eller internationale end-to-end-programmer vurderer vi, at gruppen med tilstrækkelig kapacitet er omkring et dusin. Tallene er vores markedsbedømmelse, opdateret i september 2026, ikke officiel Microsoft-statistik.

Det får en konsekvens, som sjældent udtales: rene nysalgsforretninger er ualmindelige. Mange partnere søger i stedet ind hos eksisterende kunder gennem konsulentudlejning, gennem en bedre forvaltningsaftale eller ved at overtage videreudviklingen, og udvider derefter opgaven land for land.

For jer som købere betyder det to ting. Konkurrencen om jeres projekt er mindre, end I tror, hvilket sænker jeres forhandlingsposition. Og den partner, I vælger, vil sandsynligvis være hos jer i mange år, da udskiftning af leverandør midt i en installation af denne størrelse er dyrt og risikabelt. Evalueringen skal derfor være skarpere, ikke mildere, end ved en mindre udbudsproces.

En terminologisk ting, der påvirker omfanget

Finance og Supply Chain Management er to separate applikationer, der licensieres hver for sig, selvom markedet og de fleste partnere taler om dem som ét system. Afklar tidligt, hvilke af modulerne I faktisk skal have, da det påvirker både licensomkostninger og hvilken kompetence der er nødvendig i teamet. Det samme gælder tilstødende applikationer som Project Operations og Human Resources, der ofte sniger sig ind i omfanget under forstudiet.

Trin 1: Tag udgangspunkt i, hvad I skal erstatte

Dette er den vigtigste afgrænsning, og den der oftest springes over. Kravspecifikationen bliver nogenlunde den samme uanset udgangspunktet, men arbejdet der skal udføres, adskiller sig fundamentalt, og dermed også hvilken partner der passer.

Hvis I forlader AX 2012 eller AX 2009

Dette er det mest almindelige udgangspunkt i Danmark. AX 2012 har i flere år ligget uden for Microsofts ordinære support, og de fleste, der stadig kører det, har udskudt beslutningen af gode grunde: systemet fungerer, det er tungt tilpasset, og det er dybt integreret i forretningen.

For AX 2012 R2 og R3 findes en Microsoft-understøttet opgraderingsvej til Finance and Operations, som kan medtage både data og kode. Det betyder dog ikke, at alt bør flyttes uændret. En central del af forstudiet er at afgøre, hvad der skal opgraderes, hvad der skal ombygges, og hvilke gamle tilpasninger og processer der bør efterlades. AX 2009 følger ikke den samme understøttede opgraderingssti og skal derfor betragtes som et migrationsscenarie med andre forudsætninger.

Det, I skal lede efter, er en partner, der har foretaget netop denne rejse flere gange, og som kan vise, hvordan de går til værks for at afgøre, hvilke gamle tilpasninger der skal medtages. En almindelig og kostbar fejl er at genopbygge alt, hvad der fandtes, af frygt for at nogen skal savne noget.

Bemærk også, at lang erfaring med AX ikke automatisk er det samme som dyb erfaring med dagens Finance and Supply Chain Management. Platform, extensionsmodel, drift og opdateringsmodel er ændret. Vurder derfor, hvor mange moderne implementeringer, opgraderinger og go-lives personen faktisk har gennemført, ikke kun antallet af år i AX.

Hvis I forlader SAP, IFS eller et andet større ERP

Her er der ingen legacy-kode at forholde sig til, hvilket lyder lettere, end det er. Arbejdet flytter i stedet til procesdesign og til at oversætte virksomhedens begreber til en ny struktur. Kontoplan, produktdata, kundestruktur og lagerlogik ser sjældent ud, som I er vant til, og organisationen vil opleve det.

Partneren skal her have erfaring med at lede den type oversættelse, ikke kun med at konfigurere systemet. Spørg især, hvordan de arbejder med virksomhedens nøglebrugere under designfasen, og hvor meget af den tid, der ligger hos jer.

Hvis I konsoliderer flere systemer i en koncern

Så er det ikke et projekt, det er et program. Spørgsmålet bliver, hvad der skal være en fælles kerneskabelon, og hvad hvert selskab selv må bestemme, og det er et styringsspørgsmål lige så meget som et teknisk spørgsmål.

En partner, der skal levere dette, skal kunne beskrive sin skabelon- og udrulningsmodel konkret: hvordan skabelonen forvaltes, hvordan afvigelser håndteres, hvordan lokale krav i forskellige lande indbygges, og hvad et andet og tredje land faktisk koster sammenlignet med det første. Bed om tal fra en tidligere kunde, ikke om en principiel beskrivelse.

Hvis I synes, Business Central er blevet for lille

Dette er udgangspunktet, hvor vi oftest ser forkerte konklusioner. Manglen sidder ofte i et fåtal processer, i integrationer der aldrig blev færdige, eller i at systemet blev konfigureret til en virksomhed, I siden voksede fra.

En udskiftning opad løser det, men til en helt anden omkostning og kompleksitet end at afhjælpe det, der faktisk skurrer. Den partner, I spørger, har normalt en interesse i svaret. Sørg derfor for, at analysen udføres af nogen, der tjener lige meget på begge udfald, eller udfør den internt.

Hvis konklusionen bliver, at I bliver, er det i stedet partnervalget på det niveau, der skal overvejes. Vi gennemgår det i guiden om, hvordan du finder den rette partner til Dynamics 365 i Danmark.

Trin 2: Bestem om det er et projekt eller et program

En F&SCM-implementering i et selskab og en udrulning over otte selskaber i fem lande er ikke det samme. Alligevel udbydes de ofte ens, og afvigelserne viser sig først, når land nummer to skal i gang.

Afklar, før I går ud:

• Hvor mange juridiske enheder og lande omfattes, og i hvilken rækkefølge?
• Hvad skal være fælles, og hvad må afvige mellem selskaberne?
• Hvem hos jer ejer skabelonen efter første go-live?
• Skal partneren levere alle lande, eller skal I kunne bruge lokale ressourcer i visse?

Svarene styrer, hvilken type leverandør der er rimelig. En partner uden egen tilstedeværelse uden for Norden kan stadig levere en udrulning, men så skal det fremgå hvordan, og hvem de samarbejder med.

Trin 3: Byg en longlist uden at gøre feltet unødigt snævert

Det siges ofte, at F&SCM kræver en af de globale systemintegratorer. Det stemmer ikke for danske forhold. De største aktører har dybe ressourcer og global rækkevidde, men der findes også mellemstore nordiske partnere med lang F&SCM-historik og betydeligt højere andel senior konsulenter i deres teams.

Det, der virkelig sorterer, er ikke selskabets størrelse, men tre ting:

• Antallet af go-lives på Finance and Operations de seneste fireogtyve måneder. Ikke det samlede antal kunder, og ikke AX-historikken.
• Om de har leveret noget, der ligner jeres udgangspunkt, altså samme type skifte fra samme type system.
• Om de kan bemande jer med seniorpersoner uden at tømme et andet igangværende projekt.

Fire til seks kandidater er et rimeligt udgangspunkt. Flere bliver svært at evaluere i den dybde, der kræves, og færre giver jer ingen sammenligning overhovedet.

Trin 4: Evaluer teamet, ikke selskabet

I et projekt af denne størrelse er det ikke leverandøren, I køber, det er et arkitektteam. Forskellen mellem to partnere i samme prisklasse sidder næsten altid i personerne.

Løsningsarkitekten

Projektets vigtigste rolle. Arkitekten binder koncernens økonomiske struktur, altså koncernregnskab, internprissætning og fælles funktioner, sammen med de operationelle flow. Kræv CV, spørg hvilke af personens seneste projekter der gik i produktion, og tal med arkitekten selv, før I underskriver aftale.

Opdelingen økonomi og supply chain

Det er usædvanligt, at den samme konsulent er stærk i både den avancerede økonomimodel og i tung logistik eller produktion. Evaluer derfor teamet som helhed, og kræv CV på dem, der skal opsætte de moduler, I faktisk er afhængige af. Har I avanceret lagerstyring, produktion eller global indkøbslogistik skal der være navne knyttet til hvert sådant område.

Projektleder og forandringsleder

Projektlederen bør have drevet mindst én implementering af sammenlignelig størrelse hele vejen til stabil drift, ikke kun til go-live. Forandringsledelsen er ikke et blødt spørgsmål i dette system: F&SCM opfattes som komplekst af dem, der skal arbejde i det dagligt, og adoptionen afgør, om investeringen giver noget.

Trin 5: Gennemgå leverancemodellen

Næsten alle større partnere kombinerer konsulenter i Danmark med ressourcer i andre lande. Det er ikke et problem i sig selv, og en leverance fuldt bemandet med danske seniorkonsulenter bliver meget dyr uden nødvendigvis at blive bedre.

Det, der afgør, er hvor i projektet grænsen går. Analyse, design og de beslutninger, der former løsningen, bør ligge tæt på virksomheden og på et sprog, hvor nuancer ikke forsvinder. Konfiguration, udvikling, datavask og testning fungerer godt at placere hos et etableret center i et andet land.

Spørg lige ud, hvordan teamet er sammensat, i hvilke tidszoner det arbejder, og hvem der skriver kravspecifikationen, som udviklerne derefter bygger efter. Det er i den overlevering, de dyre misforståelser opstår.

Trin 6: Spørgsmål at stille, og hvordan svarene skal læses

Følgende spørgsmål er formuleret til ikke at have et selvfølgeligt godt svar. Vurderingen af svaret er mindst lige så vigtig som spørgsmålet.

1. Hvor mange go-lives har I haft på Finance and Operations de seneste to år?

Dette er det enkeltvis mest informative spørgsmål i hele evalueringen, og det der oftest besvares svævende.

Gode svar indeholder:

• Et tal, med kunder der kan navngives og gerne kontaktes.
• En sondring mellem nye implementeringer, udrulninger til yderligere lande og overtagede forvaltninger.

Advarselstegn:

• Svaret glider over i det samlede antal kunder eller i selskabets historik i AX.
• Referencerne ligger flere år tilbage.

2. Hvem bliver vores løsningsarkitekt, og må vi møde vedkommende nu?

Arkitekten er den person, hvis beslutninger I lever med i ti år. At møde personen først ved opstart er for sent.

Gode svar indeholder:

• Et navn, et CV og et møde uden sælger i rummet.
• Besked om hvor stor en del af sin tid personen har på jer, og hvad vedkommende ellers laver.

Advarselstegn:

• Arkitekten udpeges efter kontraktunderskrivelse.
• Personen præsenteres som arkitekt, men har hovedsageligt arbejdet i AX.

3. Hvordan planlægger I datamigreringen, og hvem ejer den?

Datamigrering er et eget projekt inde i projektet, og den mest almindelige årsag til at go-live udskydes.

Gode svar indeholder:

• En beskrivelse af hvor mange testmigreringer der planlægges, og hvornår den første sker.
• En tydelig ansvarsfordeling for datakvalitet, hvor en stor del rimeligvis ligger hos jer.

Advarselstegn:

• Migreringen beskrives som en teknisk aktivitet sent i projektet.
• Ingen forskel gøres mellem saldi, historik og stamdata.

4. Hvad bliver kerneskabelon, og hvad bliver lokalt?

Spørgsmålet gælder alle koncerner, også dem der starter i ét land, da skabelonen sættes ved første implementering, uanset om I kalder den sådan.

Gode svar indeholder:

• En konkret model for, hvad der styres centralt, og hvad der må afvige.
• Erfaringstal for, hvad et andet land har kostet sammenlignet med det første hos en tidligere kunde.

Advarselstegn:

• Spørgsmålet besvares principielt uden eksempler.
• Alt skal være fælles, uden diskussion om hvad der sker, når et selskab ikke kan følge skabelonen.

5. Hvordan ser teamets sammensætning ud mellem lande?

Se afsnittet om leverancemodellen ovenfor. Spørgsmålet skal stilles lige ud og besvares med tal.

Gode svar indeholder:

• En fordeling per rolle og fase, ikke kun en total procentdel.
• Besked om hvem der skriver kravene, som udviklerne bygger efter.

Advarselstegn:

• Andelen af lokale konsulenter præsenteres som høj i salgsfasen og falder i tilbuddet.
• Analysefasen bemandes overvejende med ressourcer, der ikke møder virksomheden.

6. Hvilke tillægsapplikationer foreslår I, og hvem ejer relationen?

De fleste F&SCM-løsninger indeholder apps fra tredjepart for eksempelvis lagerstyring, EDI, skatterapportering eller dokumenthåndtering.

Gode svar indeholder:

• En liste med hvem der er leverandør, hvad det koster løbende, og hvem I har aftale med.
• En argumentation for, hvad der sker med appen, hvis I skifter implementeringspartner.

Advarselstegn:

• Partnerens egne apps præsenteres uden prisbillede.
• Afhængighederne fremgår først i aftalebilagene.

7. Hvordan ser forvaltningen ud, og hvem foretager videreudviklingen?

Systemet opdateres løbende af Microsoft, og jeres løsning skal følge med. Forvaltningen er den fase, I lever længst i, og den hvor totalomkostningen afgøres.

Gode svar indeholder:

• En skriftlig forvaltningsmodel med navngiven kundeansvarlig, svartider og prismodel.
• En plan for, hvordan regressionstestning håndteres ved Microsofts opdateringer.
• Besked om hvorvidt forvaltningsteamet er de samme personer som projektteamet, og hvordan overleveringen foretages.

Advarselstegn:

• Forvaltningsaftalen diskuteres først, efter at projektaftalen er underskrevet.
• Videreudvikling prissættes udelukkende løbende, uden nogen form for prioriteringsproces.

Meritter og begreber, der måler noget andet, end du tror

• FastTrack for Dynamics 365 er Microsofts kundesucces- og rådgivningsprogram for kvalificerede projekter, leveret sammen med implementeringspartneren og baseret på Success by Design. Det er ikke en partnercertificering eller partnermerit i sig selv. Erfaring med FastTrack, Implementation Portal og go-live readiness reviews kan derimod være relevant, når I bedømmer partnerens erfaring med Microsofts implementeringskrav.
• Microsofts partnerbetegnelser bygger siden 2022 på Solutions Partner-designationer. Begrebet guldkonkurrence findes ikke længere og bør ikke forekomme i et aktuelt grundlag.
• Sure Step er udfaset. Microsofts aktuelle implementeringsvejledning er struktureret omkring Success by Design. En partner, der stadig beskriver Sure Step som sin aktuelle metodik, siger noget utilsigtet om, hvor ofte materialet revideres.
• Certificeringer er knyttet til personer, ikke til selskaber. Spørgsmålet er, om de certificerede personer er dem, der bliver jeres.
• Antallet af konsulenter i selskabet siger intet om, hvor mange af dem der er tilgængelige, når jeres projekt starter.

Hvad der plejer at gå galt i selve udvælgelsen

• Kravspecifikationen gøres for detaljeret for tidligt, hvilket låser løsningen fast i den gamle verdens processer og driver tilpasninger frem, som I derefter skal forvalte.
• Evalueringen vægtes mod demo og præsentation. Alle kandidater i dette segment demonstrerer godt.
• Forvaltningsfasen udelades fra udbuddet, selvom den udgør størstedelen af totalomkostningen over ti år.
• Ingen intern ejer udpeges for skabelonen, hvilket betyder, at partneren i praksis bestemmer, hvordan koncernen skal arbejde.
• Tidsplanen sættes efter en dato i virksomheden i stedet for efter hvor mange testmigreringer, der faktisk er nødvendige.
• Beslutningsgruppen er ikke enige om, hvorfor skiftet foretages, hvilket først viser sig under designfasen, når prioriteterne kolliderer.

En bemærkning om kilder

Hovedparten af det, der publiceres på dansk om, hvordan man vælger partner til Dynamics 365, er skrevet af partnere. Materialet er ofte kompetent, men det er skrevet af en part med en interesse i udfaldet, og kriterierne havner derfor gerne tæt på den egne profil.

I dette segment vejer det tungere end i noget andet, da antallet af leverandører er lille, og hver enkelt udbudsproces er stor. Læs flere kilder, og spørg jer selv, hvem der har gavn af, at netop de kriterier vejer tungest.

Næste skridt

Start med at skrive tre ting ned, før I kontakter nogen leverandør: hvad I forlader, hvilke lande og selskaber der omfattes i hvilken rækkefølge, og hvad der skal være løst om to år. Med de tre svar på plads bliver leverandørsamtalerne kortere og betydeligt mere oplysende.

På d365 Guide kan I sammenligne danske Dynamics 365-partnere per applikationsområde, branche og størrelse, og afgrænse feltet, før I begynder at booke møder.

Skal I samtidig se på CRM-siden, findes separate guides om Dynamics 365 Sales og Customer Service og Field Service.