Ja. AI påverkar både vad ett företag bör köpa från en ERP-leverantör och hur avtalet bör utformas. När den egna IT-avdelningen kan utveckla fler funktioner med AI-stöd behöver affärssystemet kunna kompletteras och omfattningen förändras. Ett avtal på sju till tio år bör därför bedömas utifrån både dagens behov och värdet av framtida handlingsfrihet.

Vid en ERP-upphandling ligger mycket fokus på funktioner, implementation, licenspriser och driftsäkerhet. Det är nödvändiga frågor. Men inför ett långsiktigt åtagande behöver ledningen också ta ställning till en annan fråga: vad vill vi fortfarande köpa från samma leverantör om fem år?

Det går inte att förutse exakt hur AI kommer att utvecklas. Därför bör upphandlingen göra det möjligt att anpassa systemlandskapet när förutsättningarna förändras.

Två olika sätt som AI påverkar affärssystemet

AI kan påverka ERP-inköpet genom att hjälpa IT-avdelningen att utveckla programvara. Det kan exempelvis handla om kod, tester, integrationer och användargränssnitt. Den färdiga lösningen behöver inte själv innehålla AI.

AI kan också bli en del av den löpande verksamheten, exempelvis som handläggarstöd, dokumenttolkning eller en agent som initierar åtgärder i affärssystemet. Då tillkommer frågor om modellkvalitet, behörigheter, kontroll och användningsbaserade kostnader.

I upphandlingen behöver båda perspektiven finnas med: möjligheten att utveckla runt ERP-systemet och villkoren för att använda AI tillsammans med det.

Ska vi köpa ERP-systemet eller utveckla själva?

Ett komplett affärssystem kräver mycket mer än fungerande kod. Redovisning, transaktionshantering, behörigheter, spårbarhet, integrationer och långsiktig förvaltning måste fungera tillsammans.

David Klotz analyserar hur agentisk AI påverkar beslutet mellan köp och egenutveckling i en konceptuell forskningsartikel från 2026. Han argumenterar för att reglerade och verksamhetskritiska kärnsystem fortsatt ofta lämpar sig för köp, medan egenutveckling kan bli mer attraktiv för avgränsade och verksamhetsspecifika applikationer. Artikeln är publicerad som preprint och ska läsas som ett analytiskt ramverk, inte som ett empiriskt bevis för en viss besparing. Läs forskningsartikeln på arXiv.

Vår rekommendation är att pröva köp och egenutveckling per funktion. Det kan vara rimligt att köpa en stabil kärna för ekonomi, order och lager och samtidigt utveckla egna rapporter, kundgränssnitt eller arbetsflöden.

Jämförelsen behöver även ta hänsyn till leverantörens utveckling. Om ERP-leverantören förbättrar standardfunktionerna kan det vara mer fördelaktigt att använda dessa. Egenutveckling är ett alternativ som ska utvärderas, inte ett mål i sig.

Skilj mellan användningstid och ekonomisk bindning

Att ett ERP-system ska användas i tio år innebär inte automatiskt att alla licenser, moduler och konsulttjänster bör bindas under samma period.

En lång bindning kan ge prisfördelar och förutsägbarhet. Samtidigt kan den göra det dyrt att anpassa lösningen. Be därför leverantören prissätta olika alternativ: en kortare initial period med förlängningar och en längre period med avtalade möjligheter till nedskalning.

Var tydlig med vad en förlängningsoption innebär. Att kunna diskutera en förlängning är inte samma sak som att kunden har rätt att förlänga till på förhand bestämda villkor.

Även en omförhandlingspunkt behöver få en konkret innebörd. Om parterna inte kommer överens, fortsätter då hela betalningsåtagandet? Får kunden minska en modul? Finns en bestämd ersättning vid förtida utträde? En skyldighet att mötas ger i sig ingen ekonomisk flexibilitet.

API behöver fungera både tekniskt och kommersiellt

API är gränssnitt som låter andra system kommunicera med ERP-systemet. Att sådana finns är en början. Upphandlingen behöver också visa vilka funktioner de täcker och hur de får användas.

Begär besked om läs- och skrivåtkomst, kapacitetsgränser, avgifter, versionshantering och möjligheten att ansluta egna applikationer eller externa AI-tjänster. Låt IT-avdelningen prova ett representativt arbetsflöde före avtalstecknande.

Avtalet behöver dessutom klargöra licenskraven för indirekt åtkomst. Ett eget gränssnitt eller en AI-agent betyder inte automatiskt att bakomliggande användarlicenser kan tas bort.

Säkerställ att mindre omfattning kan ge lägre kostnad

Ett hypotetiskt exempel: ett företag köper ERP-system och en separat rapportmodul. Efter fyra år utvecklar företaget ett eget rapporteringsstöd som passar verksamheten bättre. Den tekniska övergången fungerar, men rapportmodulen ingår i ett paket som måste betalas i ytterligare sex år.

Företaget har då fått en ny funktion och en ny förvaltningskostnad, samtidigt som den gamla avgiften består.

Begär därför separat prissättning där det är möjligt och reglera när moduler eller volymer får minskas. Kontrollera också om en minskning höjer priset på återstående tjänster, tar bort rabatter eller påverkar minimiåtaganden. Det är nettokostnaden efter förändringen som avgör värdet.

Utvärdera hela kostnaden för egenutveckling

En kalkyl för en egen lösning behöver omfatta kravarbete, utveckling, testning, integration, säkerhet, drift, support, uppdateringar och avveckling. Om lösningen använder AI i drift tillkommer exempelvis modellkostnader och kvalitetsuppföljning.

Beräkna även risken att lösningen blir beroende av ett fåtal medarbetare eller en specifik AI-plattform. Dokumentation, ägande av kod och möjlighet att byta modell eller utvecklingspartner bör ingå i bedömningen.

Jämför gärna tre scenarier över samma tidsperiod: att fortsätta köpa funktionen, att utveckla den själv och att kombinera leverantörens kärnfunktion med en egen tillämpning. Använd ett begränsat pilotprojekt för att pröva antagandena om kostnad och förvaltningsbehov.

Dataexport är en del av en fungerande exit

Ett leverantörsbyte kräver mer än en fil med kundregister och transaktioner. Det kan också behövas bilagor, historik, databeskrivningar, kundspecifika konfigurationer och dokumentation av integrationer.

Identifiera vilka delar kunden äger och vilka nyttjande- och överföringsrättigheter som behöver avtalas. Tillgång till kunddata innebär inte automatiskt rätt till leverantörens källkod eller immateriella rättigheter.

EU Data Act innehåller regler om byte mellan databehandlingstjänster, inklusive relevanta molntjänster. För ett SaaS-ERP behöver tillämpningen bedömas för den aktuella tjänsten. Reglerna bör inte tas som ett generellt löfte om kostnadsfri uppsägning av ett långt avtal. EU-kommissionens vägledning om Data Act.

En exitplan bör ange leveranser, format, tidsramar, ansvar och kostnader samt hur dataexporten ska provas under avtalstiden.

Förhandla om handlingsfriheten innan beroendet växer

Inför ett långt ERP-avtal bör inköp, IT, ekonomi, verksamhet och juridik gemensamt besvara följande frågor:

  • Vilka funktioner behöver vi köpa långsiktigt, och vilka kan förändras snabbare?
  • Vilka rättigheter och kostnader gäller för egenutveckling, integrationer och AI-agenter?
  • När får vi minska omfattningen, och hur ändras den totala avgiften?
  • Vad händer om vi inte kommer överens vid en omförhandling?
  • Kan vi genomföra en stegvis övergång till en annan lösning?

För IJMO Consulting är utgångspunkten att framtida handlingsfrihet ska värderas i inköpsbeslutet. En rabatt för lång bindning bör vägas mot kostnaden för outnyttjade funktioner och möjligheten att välja bättre alternativ senare.

AI gör den avvägningen mer angelägen. Ett genomtänkt ERP-inköp ska ge stabilitet i verksamheten och utrymme att utveckla den.