Leverantörsinlåsning – så håller du dörren öppen

Av Weapp · Uppdaterad

Leverantörsinlåsning uppstår sällan genom avtalstext utan genom praktik – odokumenterad kod, konton och nycklar som ägs av leverantören och lösningar byggda på proprietära plattformar. Skydda dig genom att äga repo och konton själv, kräva dokumentation och undvika onödiga beroenden. Testa läget årligen med en enkel fråga: kan vi byta leverantör inom sex månader om vi måste?

Leverantörsinlåsning är den obehagliga upptäckten att du inte kan lämna en leverantör även om du vill – att bytet skulle bli så dyrt, långsamt eller riskabelt att du hellre står ut. Många tror att skyddet ligger i avtalet, i en uppsägningsklausul. Men inlåsning uppstår sällan i juridiken. Den byggs upp i det praktiska, en bekvämlighet i taget, tills dörren är stängd utan att någon bestämde sig för att stänga den. Här är de vanligaste mekanismerna och hur du håller dörren öppen.

Inlåsning byggs i praktiken, inte i avtalet

Det avgörande att förstå är att de flesta avtal faktiskt går att säga upp. Ändå sitter bolag fast. Förklaringen är att det verkliga beroendet är tekniskt och praktiskt, inte juridiskt.

Om koden är odokumenterad och bara leverantörens team begriper den, om molnkontot och domänen står i leverantörens namn, om lösningen vilar på deras egna verktyg – då hjälper ingen uppsägningsrätt i världen. Ni har rätten att gå men inte förmågan. Därför bekämpas inlåsning inte med bättre avtalstext i första hand, utan med praktiska motmedel som ger er förmågan att flytta.

De fem vanligaste mekanismerna

Fem former av inlåsning återkommer, och de förstärker ofta varandra. Känner du igen dem kan du kontra var och en.

MekanismMotmedel
Odokumenterad kodKräv dokumentation löpande, inskriven i Definition of Done
Leverantörsägda kontonÄg repo, molnkonto och domän i eget namn – bjud in leverantören
Proprietära plattformarUndvik onödiga beroenden av leverantörens egna verktyg
Kunskap i enskilda huvudenKräv överlämningsbar dokumentation och sprid kunskapen
Inlåst dataSäkra att data går att exportera i öppna, användbara format

Den mest lömska är den leverantörsägda infrastrukturen, eftersom den ofta uppstår “för enkelhetens skull” tidigt i ett projekt. Att låta leverantören sätta upp allt i sitt eget konto sparar en timme i början och kostar en förhandling i underläge senare. Regeln är enkel: allt som skulle vara smärtsamt att förlora ska stå i ert namn från start, med leverantören inbjuden som gäst.

Sund kontinuitet kontra osunt beroende

Poängen är inte att undvika långa leverantörsrelationer – de är ofta värdefulla. Poängen är att skilja på två saker som ser lika ut utifrån men är helt olika inuti.

  • Sund kontinuitet är när ni gärna fortsätter med en leverantör som levererar bra. Ni stannar för att ni väljer det, och ni skulle kunna gå om ni ville.
  • Osunt beroende är när ni stannar för att ni inte kan lämna. Valet är borta, och leverantören vet om det.

Skillnaden märks först den dag något skaver. En bra relation tål att ni har förmågan att byta – den vilar på att samarbetet fungerar, inte på att ni är fast. Målet är alltså inte att byta ofta, utan att alltid ha kvar möjligheten.

Ett scenario: två bolag, samma leverantör

Två bolag anlitade samma byrå. Det ena lät byrån äga repo, konton och all kunskap, “för att det var smidigt”. Det andra insisterade på eget ägande av infrastrukturen, krävde dokumentation löpande och undvek byråns mest proprietära verktyg.

När båda några år senare övervägde ett byte var upplevelsen helt olika. Det första bolaget fick veta att en flytt skulle ta månader och kosta rejält, och stannade motvilligt. Det andra konstaterade att ett byte hade tagit några veckor – och valde att stanna ändå, men nu för att de ville, inte för att de måste. Samma byrå, samma tid, motsatt frihet.

Den årliga inlåsningskontrollen

Inlåsning smyger sig på, så kontrollera den regelbundet. En gång om året, ställ den enkla frågan: kan vi byta leverantör inom sex månader om vi måste?

För att svara går du igenom tre saker. Äger ni repo, molnkonto och domän själva? Räcker dokumentationen för att ett nytt team ska kunna ta över utan den nuvarande leverantören? Går lösningen och datan att flytta utan orimligt arbete? Kan ni svara ja med rimlig säkerhet är dörren öppen. Kan ni inte det, vet ni nu var arbetet behöver läggas – medan det fortfarande är en planerad åtgärd och inte en kris.

Vill du få en oberoende bedömning av er inlåsningsgrad, eller bygga nästa projekt så att dörren hålls öppen från start, hjälper vi på Weapp gärna till – och en teknisk genomgång ger snabbt svar på hur fri ni faktiskt är i dag.

Vanliga frågor

Uppstår inlåsning inte främst genom avtalet?

Sällan. De flesta avtal går att säga upp – det verkliga beroendet sitter i praktiken. Om koden är odokumenterad, kontona ägs av leverantören och lösningen vilar på deras egna verktyg spelar uppsägningsrätten liten roll, för ni kan ändå inte flytta. Inlåsning är oftast ett tekniskt och praktiskt tillstånd, inte en juridisk klausul. Därför bekämpas den med praktiska motmedel.

Vilka är de vanligaste inlåsningsmekanismerna?

Fem återkommer: odokumenterad kod som bara leverantören förstår, konton och infrastruktur som ägs av leverantören, beroende av deras egna proprietära plattformar, kunskap som bara finns i deras huvuden, och data i format som är svåra att få ut. Var och en binder er på sitt sätt, och de förstärker ofta varandra. Motmedlet mot samtliga är insyn och eget ägande från start.

Är allt beroende av en leverantör av ondo?

Nej. Skillnaden går mellan sund kontinuitet och osunt beroende. Att gärna vilja fortsätta med en leverantör som fungerar bra är kontinuitet – ni stannar för att ni väljer det. Osunt beroende är när ni stannar för att ni inte kan lämna. Målet är inte att undvika långa relationer, utan att alltid ha förmågan att byta om ni skulle behöva.

Hur kontrollerar vi vår inlåsningsgrad?

Ställ en gång om året den enkla frågan: kan vi byta leverantör inom sex månader om vi måste? Gå igenom om ni äger repo och konton, om dokumentationen räcker för att någon annan ska ta över, och om lösningen går att flytta. Kan ni inte svara ja med rimlig säkerhet vet ni var arbetet behöver läggas innan behovet blir akut.