Jeg opplever stadig oftere det samme i ERP-prosjekter: Valg av kontraktstype og leveransemetode henger ikke sammen. På papiret ser alt riktig ut. Kunden føler trygghet. Rådgiver har brukt en etablert mal. Det er struktur, det er tydelige formuleringer, og det ser gjennomarbeidet ut. Men i praksis opplever jeg ofte det motsatte – at kontrakten i realiteten skaper mer usikkerhet enn trygghet.
Én kontrakt – flere virkeligheter
La oss starte med det grunnleggende: Hvordan leveres egentlig et moderne ERP-prosjekt i dag? I de aller fleste tilfeller er dette en sammensatt leveranse:
- Programvaren leveres som SaaS av en tredjepart
- Plattform, drift og SLA ligger hos programvareleverandør
- Implementeringen gjennomføres av en partner
- Videreutvikling og forvaltning skjer løpende etter go-live
Dette er fire ulike dimensjoner – med ulikt ansvar, ulik kontroll og ulik risiko. Likevel ser jeg ofte at dette forsøkes samlet i én kontrakt, gjerne basert på modeller som i utgangspunktet er laget for leveranser hvor én leverandør kontrollerer hele tjenesten. Det er her utfordringen starter.
Når kontrakten beskriver en annen virkelighet enn prosjektet
Når kontrakten ikke speiler hvordan leveransen faktisk gjennomføres, oppstår det en mismatch. Konsekvensene er veldig konkrete:
- Implementeringspartner får ansvar for forhold de ikke styrer
- Kunden får en forventning om at “én part eier alt”
- Avhengigheter til tredjepart blir underkommunisert
- Endringer blir vanskeligere å håndtere
I praksis betyr dette at kontrakten beskriver en ideell verden – mens prosjektet må gjennomføres i den virkelige.
Risikoen forsvinner ikke – den flytter på seg
Risiko kan ikke kontraktsfestes bort. Den kan bare flyttes. Når jeg som implementeringspartner blir pålagt ansvar jeg ikke kan kontrollere, må jeg håndtere det:
- Jeg priser inn usikkerhet
- Jeg blir mer rigid i endringshåndtering
- Jeg beskytter meg gjennom forbehold
Kunden betaler dermed for risiko – ikke nødvendigvis for mer verdi.
Kontrakten påvirker adferd – på begge sider
En kontrakt setter ikke bare juridiske rammer – den påvirker hvordan prosjektet faktisk gjennomføres. Når ansvaret legges tungt på implementeringspartner, ser jeg ofte:
- Mindre eierskap hos kunden
- Svakere behovsavklaring
- Utsatte beslutninger
- Lavere kvalitet i test
Men: ERP-implementeringer lykkes ikke uten aktivt eierskap fra kunden. Dette må reflekteres i avtalen.
Leveransemetode er ikke tilfeldig – den er trent og bygget opp over tid
Dette er et punkt jeg mener er helt avgjørende – og som ofte undervurderes: Som implementeringspartner leverer vi ikke tilfeldig. Vi leverer basert på en metodikk vi er trent på, organisert rundt og har bygget erfaring på over tid. Det inkluderer:
- Hvordan vi gjennomfører behovsavklaring
- Hvordan vi strukturerer faser og milepæler
- Hvordan vi håndterer endringer
- Hvordan vi jobber med test og godkjenning
- Hvordan vi sikrer fremdrift
Når vi får levere innenfor denne modellen, vet vi hva som fungerer. Men når kontrakter eller kundespesifikke krav “tvinger” oss til å levere på en annen måte:
- Brytes etablerte arbeidsprosesser
- Roller og ansvar blir uklare
- Tempo og kvalitet påvirkes
- Risikoen øker – for begge parter
Resultatet kan fort bli det motsatte av det man ønsket å oppnå.
Hvorfor rådgivere ofte lander feil
Jeg opplever ofte at rådgivere har gode intensjoner:
- De ønsker struktur
- De ønsker forutsigbarhet
- De ønsker å beskytte kunden
Men når standardmaler brukes uten å tilpasses leveransemodellen, ser vi ofte:
- Utvidet rådgivningsplikt
- Ansvar utover implementeringsrollen
- Svekket endringsmekanisme
- Urealistiske forventninger
Det ser bra ut på papiret – men er krevende å gjennomføre i praksis.
En god avtale er gjensidig – ikke ensidig
For meg er dette et grunnprinsipp: En god avtale må være balansert.
- Ansvar plasseres der det kan styres
- Risiko fordeles realistisk
- Begge parter har tydelige forpliktelser
- Begge parter må bidra aktivt
ERP er ikke noe du kjøper ferdig. Det er noe du lykkes med – sammen.
En mer robust tilnærming
Det som fungerer best i praksis: La kontraktsstrukturen speile leveransemodellen.
- Egen avtale for programvare
- Egen for implementering
- Egen for support
- Egen for forvaltning
Dette gir:
- Klar ansvarsdeling
- Riktig risikobilde
- Bedre håndtering av endringer
- Lavere konfliktnivå
Og viktigst: bedre gjennomføring.
Det største paradokset
Jo mer man forsøker å sikre seg gjennom kontrakten, jo større risiko kan man introdusere i praksis. Ekte trygghet ligger ikke i å flytte ansvar – men i å etablere en modell som faktisk fungerer.
Til slutt
For meg handler dette ikke bare om kontrakt. Det handler om å legge til rette for å lykkes.
Og kanskje det viktigste spørsmålet er: Er denne avtalen laget for å støtte leveransemodellen – eller motarbeide den?