Leverandørinnlåsing: Slik holder du døren åpen
Leverandørinnlåsing oppstår sjelden gjennom avtaleteksten, men i praksis: udokumentert kode, kontoer og nøkler som eies av leverandøren, og løsninger bygget på proprietære plattformer. Beskytt deg ved å eie repo og kontoer selv, kreve dokumentasjon og unngå unødvendige avhengigheter. Test situasjonen årlig med et enkelt spørsmål: Kan vi bytte leverandør innen seks måneder hvis vi må?
Leverandørinnlåsing er den ubehagelige oppdagelsen at du ikke kan forlate en leverandør selv om du vil. Et bytte ville bli så dyrt, tregt eller risikabelt at du heller holder ut. Mange tror at beskyttelsen ligger i avtalen, i en oppsigelsesklausul. Men innlåsing oppstår sjelden i det juridiske. Den bygges opp i det praktiske, én bekvemmelighet om gangen, til døren er lukket uten at noen har bestemt seg for å lukke den. Her går vi gjennom de vanligste mekanismene og hvordan du holder døren åpen.
Innlåsing bygges i praksis, ikke i avtalen
Det avgjørende er å forstå at de fleste avtaler faktisk kan sies opp. Likevel sitter selskaper fast. Forklaringen er at den reelle avhengigheten er teknisk og praktisk, ikke juridisk.
Hvis koden er udokumentert og bare leverandørens team forstår den, hvis skykontoen og domenet står i leverandørens navn, og hvis løsningen hviler på leverandørens egne verktøy, hjelper ingen oppsigelsesrett i verden. Dere har retten til å gå, men ikke evnen. Derfor bekjempes innlåsing ikke først og fremst med bedre avtaletekst, men med praktiske mottiltak som gir dere evnen til å flytte.
De fem vanligste mekanismene
Fem former for innlåsing går igjen, og de forsterker ofte hverandre. Kjenner du dem igjen, kan du motvirke hver enkelt.
| Mekanisme | Mottiltak |
|---|---|
| Udokumentert kode | Krev løpende dokumentasjon, skrevet inn i Definition of Done |
| Leverandøreide kontoer | Ha repo, skykonto og domene i eget navn, og inviter leverandøren inn |
| Proprietære plattformer | Unngå unødvendige avhengigheter av leverandørens egne verktøy |
| Kunnskap i enkeltpersoners hoder | Krev dokumentasjon som kan overleveres, og spre kunnskapen |
| Innlåste data | Sørg for at dataene kan eksporteres i åpne, brukbare formater |
Den mest lumske er den leverandøreide infrastrukturen fordi den ofte oppstår «for enkelhets skyld» tidlig i et prosjekt. Å la leverandøren sette opp alt i sin egen konto sparer en time i starten og koster en forhandling fra en svak posisjon senere. Regelen er enkel: Alt som ville være smertefullt å miste, skal stå i virksomhetens eget navn fra start, med leverandøren invitert som gjest.
Sunn kontinuitet kontra usunn avhengighet
Poenget er ikke å unngå lange leverandørrelasjoner. De er ofte verdifulle. Poenget er å skille mellom to ting som ser like ut utenfra, men som er helt forskjellige på innsiden.
- Sunn kontinuitet er når dere gjerne fortsetter med en leverandør som leverer godt. Dere blir fordi dere velger det, og dere kunne ha gått hvis dere ville.
- Usunn avhengighet er når dere blir fordi dere ikke kan gå. Valget er borte, og leverandøren vet det.
Forskjellen merkes først den dagen noe skurrer. En god relasjon tåler at dere har evnen til å bytte: Den hviler på at samarbeidet fungerer, ikke på at dere sitter fast. Målet er altså ikke å bytte ofte, men alltid å beholde muligheten.
Et scenario: to selskaper, samme leverandør
To selskaper engasjerte det samme byrået. Det ene lot byrået eie repo, kontoer og all kunnskap, «fordi det var praktisk». Det andre insisterte på å eie infrastrukturen selv, krevde løpende dokumentasjon og unngikk byråets mest proprietære verktøy.
Da begge noen år senere vurderte et bytte, var opplevelsen helt forskjellig. Det første selskapet fikk vite at en overgang ville ta måneder og koste mye, og ble motvillig værende. Det andre konstaterte at et bytte ville ha tatt noen uker, og valgte å bli likevel, men nå fordi de ville, ikke fordi de måtte. Samme byrå, samme tid, motsatt frihet.
Den årlige innlåsingskontrollen
Innlåsing sniker seg inn, så sjekk den regelmessig. Still én gang i året det enkle spørsmålet: Kan vi bytte leverandør innen seks måneder hvis vi må?
For å svare går du gjennom tre ting. Eier dere repo, skykonto og domene selv? Er dokumentasjonen god nok til at et nytt team kan ta over uten den nåværende leverandøren? Kan løsningen og dataene flyttes uten urimelig mye arbeid? Kan dere svare ja med rimelig sikkerhet, står døren åpen. Kan dere ikke det, vet dere nå hvor arbeidet må gjøres mens det fortsatt er et planlagt tiltak og ikke en krise.
Vil du få en uavhengig vurdering av hvor innlåst dere er, eller bygge neste prosjekt slik at døren holdes åpen fra start, hjelper vi i Weapp gjerne til, og en teknisk gjennomgang gir raskt svar på hvor fri dere faktisk er i dag.
Ofte stilte spørsmål
Oppstår ikke innlåsing først og fremst gjennom avtalen?
Sjelden. De fleste avtaler kan sies opp. Den reelle avhengigheten ligger i praksis. Er koden udokumentert, eies kontoene av leverandøren og hviler løsningen på leverandørens egne verktøy, betyr oppsigelsesretten lite, for dere kan uansett ikke flytte. Innlåsing er som regel en teknisk og praktisk tilstand, ikke en juridisk klausul. Derfor bekjempes den med praktiske mottiltak.
Hva er de vanligste innlåsingsmekanismene?
Fem går igjen: udokumentert kode som bare leverandøren forstår, kontoer og infrastruktur som eies av leverandøren, avhengighet av leverandørens egne proprietære plattformer, kunnskap som bare finnes i hodene til leverandørens folk, og data i formater som er vanskelige å få ut. Hver av dem binder dere på sin måte, og de forsterker ofte hverandre. Mottiltaket mot alle fem er innsyn og eget eierskap fra start.
Er all avhengighet av en leverandør av det onde?
Nei. Skillet går mellom sunn kontinuitet og usunn avhengighet. Å ønske å fortsette med en leverandør som fungerer godt, er kontinuitet: Dere blir fordi dere velger det. Usunn avhengighet er når dere blir fordi dere ikke kan gå. Målet er ikke å unngå lange relasjoner, men alltid å ha evnen til å bytte hvis dere skulle trenge det.
Hvordan sjekker vi hvor innlåst vi er?
Still én gang i året det enkle spørsmålet: Kan vi bytte leverandør innen seks måneder hvis vi må? Gå gjennom om dere eier repo og kontoer, om dokumentasjonen er god nok til at noen andre kan ta over, og om løsningen kan flyttes. Kan dere ikke svare ja med rimelig sikkerhet, vet dere hvor arbeidet må gjøres før behovet blir akutt.