Hur väljer du rätt partner för Dynamics 365 Finance & Supply Chain Management?

Vad som utmärker den här upphandlingen

Finance & Supply Chain Management är Microsofts enterprisegren, med rötter i Axapta och senare AX. Systemet är byggt för koncerner med flera legala enheter, komplexa varuflöden och verksamhet i flera länder. Det märks i allt: projektens storlek, tidsåtgången, antalet inblandade och hur få leverantörer som faktiskt kan leverera.

Ett par storleksordningar som ram, och som är d365.se:s bedömning av den svenska marknaden. Projekten ligger normalt på 1,5–10 miljoner kronor och löper över flera år räknat från förstudie till stabil drift. Vi bedömer att det finns i storleksordningen hundra kundkoncerner i Sverige som kör systemet eller dess föregångare, och att det tillkommer i storleksordningen femtio nya affärer per år. d365.se har identifierat fler aktörer med F&SCM-kompetens, men för större svenska flerbolags- eller internationella end-to-end-program bedömer vi att gruppen med tillräcklig kapacitet är ungefär ett tiotal. Siffrorna är vår marknadsbedömning, uppdaterad i september 2026, inte officiell Microsoft-statistik.

Det får en konsekvens som sällan uttalas: rena nyförsäljningsaffärer är ovanliga. Många partners söker sig i stället in i befintliga kunder genom konsultuthyrning, genom ett bättre förvaltningsavtal eller genom att ta över vidareutvecklingen, och breddar sedan uppdraget land för land.

För er som köpare betyder det två saker. Konkurrensen om ert projekt är mindre än ni tror, vilket sänker er förhandlingsposition. Och den partner ni väljer kommer sannolikt att vara kvar hos er i många år, eftersom byte av leverantör mitt i en installation av den här storleken är dyrt och riskabelt. Utvärderingen behöver därför vara skarpare, inte mildare, än vid en mindre upphandling.

En terminologisk sak som påverkar scopet

Finance och Supply Chain Management är två separata applikationer som licensieras var för sig, även om marknaden och de flesta partners talar om dem som ett system. Klargör tidigt vilka av modulerna ni faktiskt ska ha, eftersom det påverkar både licenskostnad och vilken kompetens som behövs i teamet. Detsamma gäller angränsande applikationer som Project Operations och Human Resources, som ofta smyger in i scopet under förstudien.

Steg 1: Utgå från vad ni ska ersätta

Det här är den viktigaste avgränsningen, och den som oftast hoppas över. Kravlistan blir ungefär densamma oavsett utgångsläge, men arbetet som ska utföras skiljer sig fundamentalt, och därmed också vilken partner som passar.

Om ni lämnar AX 2012 eller AX 2009

Det här är det vanligaste utgångsläget i Sverige. AX 2012 ligger sedan flera år utanför Microsofts ordinarie support, och de flesta som fortfarande kör det har skjutit beslutet framför sig av goda skäl: systemet fungerar, det är tungt anpassat och det är djupt integrerat i verksamheten.

För AX 2012 R2 och R3 finns en Microsoft-stödd uppgraderingsväg till Finance and Operations som kan ta med både data och kod. Det betyder däremot inte att allt bör flyttas oförändrat. En central del av förstudien är att avgöra vad som ska uppgraderas, vad som ska byggas om och vilka gamla anpassningar och processer som bör lämnas kvar. AX 2009 följer inte samma stödda upgrade path och ska därför bedömas som ett migrationsscenario med andra förutsättningar.

Det ni ska leta efter är en partner som har gjort just den här resan flera gånger, och som kan visa hur de går tillväga för att avgöra vilka gamla anpassningar som ska med. Ett vanligt och kostsamt misstag är att bygga tillbaka allt som fanns, av rädsla för att någon ska sakna något.

Notera också att lång erfarenhet av AX inte automatiskt är samma sak som djup erfarenhet av dagens Finance och Supply Chain Management. Plattform, extensionsmodell, drift och uppdateringsmodell har förändrats. Värdera därför hur många moderna implementationer, uppgraderingar och go-live personen faktiskt har genomfört, inte bara antalet år i AX.

Om ni lämnar SAP, IFS eller ett annat större ERP

Här finns ingen legacykod att förhålla sig till, vilket låter enklare än det är. Arbetet flyttar i stället till processdesign och till att översätta verksamhetens begrepp till en ny struktur. Kontoplan, produktdata, kundstruktur och lagerlogik ser sällan ut som ni är vana vid, och organisationen kommer att uppleva det.

Partnern behöver här ha erfarenhet av att leda den typen av översättning, inte bara av att konfigurera systemet. Fråga särskilt hur de arbetar med verksamhetens nyckelanvändare under designfasen, och hur mycket av den tiden som ligger hos er.

Om ni konsoliderar flera system i en koncern

Då är det inte ett projekt, det är ett program. Frågan blir vad som ska vara gemensam kärnmall och vad varje bolag får bestämma själv, och det är en styrningsfråga lika mycket som en teknisk fråga.

En partner som ska leverera detta behöver kunna beskriva sin mall- och utrullningsmodell konkret: hur mallen förvaltas, hur avvikelser hanteras, hur lokala krav i olika länder byggs in, och vad ett andra och tredje land faktiskt kostar jämfört med det första. Be om siffror från en tidigare kund, inte om en principbeskrivning.

Om ni tycker att Business Central blivit för litet

Detta är utgångsläget där vi oftast ser fel slutsats. Bristen sitter inte sällan i ett fåtal processer, i integrationer som aldrig blev färdiga, eller i att systemet konfigurerades för en verksamhet som ni sedan växte ifrån.

Ett byte uppåt löser det, men till en helt annan kostnad och komplexitet än att åtgärda det som faktiskt skaver. Den partner ni frågar har normalt ett intresse i svaret. Se därför till att analysen görs av någon som tjänar lika mycket på båda utfallen, eller gör den internt.

Om slutsatsen blir att ni stannar kvar är det i stället partnervalet på den nivån som ska ses över. Vi går igenom det i guiden om hur du hittar rätt partner för Dynamics 365 i Sverige.

Steg 2: Bestäm om det är ett projekt eller ett program

Ett F&SCM-införande i ett bolag och en utrullning över åtta bolag i fem länder är inte samma sak. Ändå upphandlas de ofta likadant, och avvikelserna visar sig först när land nummer två ska igång.

Klargör innan ni går ut:

• Hur många legala enheter och länder omfattas, och i vilken ordning?
• Vad ska vara gemensamt och vad får skilja sig åt mellan bolagen?
• Vem hos er äger mallen efter första go-live?
• Ska partnern leverera alla länder, eller ska ni kunna använda lokala resurser i vissa?

Svaren styr vilken typ av leverantör som är rimlig. En partner utan egen närvaro utanför Norden kan fortfarande leverera en utrullning, men då ska det framgå hur, och vilka de samarbetar med.

Steg 3: Bygg en longlist utan att göra fältet onödigt smalt

Det sägs ofta att F&SCM kräver en av de globala systemintegratörerna. Det stämmer inte för svenska förhållanden. De största aktörerna har djupa resurser och global räckvidd, men det finns också mellanstora nordiska partners med lång F&SCM-historik och betydligt högre andel seniora konsulter i sina team.

Det som verkligen sållar är inte bolagets storlek utan tre saker:

• Antalet go-live på Finance and Operations de senaste tjugofyra månaderna. Inte antalet kunder totalt, och inte AX-historiken.
• Om de har levererat något som liknar ert utgångsläge, alltså samma sorts byte från samma sorts system.
• Om de kan bemanna er med seniora personer utan att tömma ett annat pågående projekt.

Fyra till sex kandidater är ett rimligt utgångsläge. Fler blir svårt att utvärdera på det djup som krävs, och färre ger er ingen jämförelse alls.

Steg 4: Utvärdera teamet, inte bolaget

I ett projekt av den här storleken är det inte leverantören ni köper, det är ett arkitektteam. Skillnaden mellan två partners i samma prisklass sitter nästan alltid i personerna.

Lösningsarkitekten

Projektets viktigaste roll. Arkitekten binder ihop koncernens ekonomiska struktur, alltså koncernredovisning, internprissättning och gemensamma funktioner, med de operativa flödena. Begär CV, fråga vilka av personens senaste projekt som gick i produktion, och tala med arkitekten själv innan ni skriver avtal.

Uppdelningen ekonomi och supply chain

Det är ovanligt att samma konsult är stark i både den avancerade ekonomimodellen och i tung logistik eller produktion. Utvärdera därför teamet som helhet, och begär CV på dem som ska sätta upp de moduler ni faktiskt är beroende av. Har ni avancerad lagerstyrning, produktion eller global inköpslogistik ska det finnas namn kopplade till varje sådant område.

Projektledare och förändringsledare

Projektledaren bör ha drivit minst ett införande av jämförbar storlek hela vägen till stabil drift, inte bara till go-live. Förändringsledningen är inte en mjuk fråga i det här systemet: F&SCM upplevs som komplext av dem som ska arbeta i det dagligen, och adoptionen avgör om investeringen ger något.

Steg 5: Granska leveransmodellen

Nästan alla större partners kombinerar konsulter i Sverige med resurser i andra länder. Det är inte ett problem i sig, och en leverans helt bemannad med svenska seniorkonsulter blir mycket dyr utan att nödvändigtvis bli bättre.

Det som avgör är var i projektet gränsen går. Analys, design och de beslut som formar lösningen bör ligga nära verksamheten och på ett språk där nyanser inte försvinner. Konfiguration, utveckling, datatvätt och testning fungerar väl att lägga hos ett etablerat center i ett annat land.

Fråga rakt ut hur teamet är sammansatt, i vilka tidszoner det arbetar, och vem som skriver kravspecifikationen som utvecklarna sedan bygger efter. Det är i den överlämningen de dyra missförstånden uppstår.

Steg 6: Frågor att ställa, och hur svaren ska läsas

Följande frågor är formulerade för att inte ha ett självklart bra svar. Bedömningen av svaret är minst lika viktig som frågan.

1. Hur många go-live har ni haft på Finance and Operations de senaste två åren?

Detta är den enskilt mest informativa frågan i hela utvärderingen, och den som oftast besvaras svävande.

Bra svar innehåller:

• Ett tal, med kunder som går att namnge och gärna kontakta.
• En åtskillnad mellan nya införanden, utrullningar till ytterligare länder och övertagna förvaltningar.

Varningstecken:

• Svaret glider över i antalet kunder totalt eller i bolagets historik i AX.
• Referenserna ligger flera år tillbaka.

2. Vem blir vår lösningsarkitekt, och får vi träffa hen nu?

Arkitekten är den person vars beslut ni lever med i tio år. Att träffa personen först vid uppstart är för sent.

Bra svar innehåller:

• Ett namn, ett CV och ett möte utan säljare i rummet.
• Besked om hur stor del av sin tid personen har på er, och vad hen gör i övrigt.

Varningstecken:

• Arkitekten tillsätts efter avtalstecknande.
• Personen presenteras som arkitekt men har i huvudsak arbetat i AX.

3. Hur planerar ni datamigreringen, och vem äger den?

Datamigrering är ett eget projekt inuti projektet, och den vanligaste orsaken till att go-live skjuts fram.

Bra svar innehåller:

• En beskrivning av hur många testmigreringar som planeras och när den första sker.
• En tydlig ansvarsfördelning för datakvalitet, där en stor del rimligen ligger hos er.

Varningstecken:

• Migreringen beskrivs som en teknisk aktivitet sent i projektet.
• Ingen skillnad görs mellan saldon, historik och stamdata.

4. Vad blir kärnmall och vad blir lokalt?

Frågan gäller alla koncerner, även de som börjar i ett land, eftersom mallen sätts vid första införandet oavsett om ni kallar den så.

Bra svar innehåller:

• En konkret modell för vad som styrs centralt och vad som får avvika.
• Erfarenhetssiffror på vad ett andra land kostat jämfört med det första hos en tidigare kund.

Varningstecken:

• Frågan besvaras principiellt utan exempel.
• Allt ska vara gemensamt, utan diskussion om vad som händer när ett bolag inte kan följa mallen.

5. Hur ser teamets sammansättning ut mellan länder?

Se avsnittet om leveransmodellen ovan. Frågan ska ställas rakt och besvaras med siffror.

Bra svar innehåller:

• En fördelning per roll och fas, inte bara en total procentsats.
• Besked om vem som skriver kraven som utvecklarna bygger efter.

Varningstecken:

• Andelen lokala konsulter presenteras hög i säljfasen och sjunker i offerten.
• Analysfasen bemannas övervägande med resurser som inte träffar verksamheten.

6. Vilka tilläggsapplikationer föreslår ni, och vem äger relationen?

De flesta F&SCM-lösningar innehåller appar från tredje part för exempelvis lagerstyrning, EDI, skatterapportering eller dokumenthantering.

Bra svar innehåller:

• En lista med vem som är leverantör, vad det kostar löpande och vem ni har avtal med.
• Ett resonemang om vad som händer med appen om ni byter implementationspartner.

Varningstecken:

• Partnerns egna appar presenteras utan prisbild.
• Beroendena framgår först i avtalsbilagorna.

7. Hur ser förvaltningen ut, och vem gör vidareutvecklingen?

Systemet uppdateras löpande av Microsoft, och er lösning behöver följa med. Förvaltningen är den fas ni lever i längst och den där totalkostnaden avgörs.

Bra svar innehåller:

• En skriftlig förvaltningsmodell med namngiven kundansvarig, svarstider och prismodell.
• En plan för hur regressionstestning hanteras vid Microsofts uppdateringar.
• Besked om huruvida förvaltningsteamet är samma personer som projektteamet, och hur överlämningen görs.

Varningstecken:

• Förvaltningsavtalet diskuteras först efter att projektavtalet är påskrivet.
• Vidareutveckling prissätts enbart löpande, utan någon form av prioriteringsprocess.

Meriter och begrepp som mäter något annat än du tror

• FastTrack för Dynamics 365 är Microsofts kundframgångs- och rådgivningsprogram för kvalificerade projekt, levererat tillsammans med implementationspartnern och baserat på Success by Design. Det är inte en partnercertifiering eller partnermerit i sig. Erfarenhet av FastTrack, Implementation Portal och go-live readiness reviews kan däremot vara relevant när ni bedömer partnerns vana vid Microsofts implementationskrav.
• Microsofts partnerbeteckningar bygger sedan 2022 på Solutions Partner-designationer. Begreppet guldkompetens finns inte längre och bör inte förekomma i ett aktuellt underlag.
• Sure Step är avvecklad. Microsofts aktuella implementationsvägledning är strukturerad kring Success by Design. En partner som fortfarande beskriver Sure Step som sin aktuella metodik säger något oavsiktligt om hur ofta materialet ses över.
• Certifieringar är knutna till personer, inte till bolag. Frågan är om de certifierade personerna är de som blir era.
• Antalet konsulter i bolaget säger ingenting om hur många av dem som är tillgängliga när ert projekt startar.

Vad som brukar gå fel i själva urvalet

• Kravspecifikationen görs för detaljerad för tidigt, vilket låser fast lösningen i den gamla världens processer och driver fram anpassningar ni sedan ska förvalta.
• Utvärderingen viktas mot demo och presentation. Alla kandidater i det här segmentet demonstrerar bra.
• Förvaltningsfasen lämnas utanför upphandlingen trots att den utgör större delen av totalkostnaden över tio år.
• Ingen intern ägare utses för mallen, vilket gör att partnern i praktiken bestämmer hur koncernen ska arbeta.
• Tidplanen sätts efter ett datum i verksamheten i stället för efter hur många testmigreringar som faktiskt behövs.
• Beslutsgruppen är inte överens om varför bytet görs, vilket visar sig först under designfasen när prioriteringarna krockar.

En anmärkning om källor

Merparten av det som publiceras på svenska om hur man väljer partner för Dynamics 365 är skrivet av partners. Materialet är ofta kompetent, men det är skrivet av en part med ett intresse i utfallet, och kriterierna hamnar därför gärna nära den egna profilen.

I det här segmentet väger det tyngre än i något annat, eftersom antalet leverantörer är litet och varje enskild upphandling är stor. Läs flera källor, och fråga er vem som har nytta av att just de kriterierna väger tyngst.

Nästa steg

Börja med att skriva ner tre saker innan ni kontaktar någon leverantör: vad ni lämnar, vilka länder och bolag som omfattas i vilken ordning, och vad som ska vara löst om två år. Med de tre svaren på plats blir leverantörssamtalen kortare och betydligt mer upplysande.

På d365.se kan ni jämföra svenska Dynamics 365-partners per applikationsområde, bransch och storlek, och avgränsa fältet innan ni börjar boka möten.

Ska ni samtidigt se över CRM-sidan finns separata guider om Dynamics 365 Sales och Customer Service och Field Service.