Vendor lock-in: Sådan holder du døren åben
Vendor lock-in opstår sjældent gennem aftaleteksten, men gennem praksis: udokumenteret kode, konti og nøgler som leverandøren ejer, og løsninger bygget på proprietære platforme. Beskyt dig ved selv at eje repo og konti, kræve dokumentation og undgå unødvendige afhængigheder. Test situationen årligt med et enkelt spørgsmål: Kan vi skifte leverandør inden for seks måneder hvis vi bliver nødt til det?
Vendor lock-in er den ubehagelige opdagelse at du ikke kan forlade en leverandør selv om du vil: Et skifte ville blive så dyrt, langsomt eller risikabelt at du hellere holder det ud. Mange tror at beskyttelsen ligger i aftalen, i en opsigelsesklausul. Men lock-in opstår sjældent i det juridiske. Den bygges op i praksis, én bekvemmelighed ad gangen, indtil døren er lukket uden at nogen besluttede at lukke den. Her er de mest almindelige mekanismer og hvordan du holder døren åben.
Lock-in bygges i praksis, ikke i aftalen
Det afgørende at forstå er at de fleste aftaler faktisk kan opsiges. Alligevel sidder virksomheder fast. Forklaringen er at den reelle afhængighed er teknisk og praktisk, ikke juridisk.
Hvis koden er udokumenteret og kun leverandørens team forstår den, hvis cloudkontoen og domænet står i leverandørens navn, hvis løsningen hviler på deres egne værktøjer, så hjælper ingen opsigelsesret i verden. I har retten til at gå, men ikke evnen. Derfor bekæmpes lock-in ikke i første omgang med bedre aftaletekst, men med praktiske modtræk der giver jer evnen til at flytte.
De fem mest almindelige mekanismer
Fem former for lock-in går igen, og de forstærker ofte hinanden. Genkender du dem, kan du imødegå hver enkelt.
| Mekanisme | Modtræk |
|---|---|
| Udokumenteret kode | Kræv løbende dokumentation, skrevet ind i Definition of Done |
| Konti ejet af leverandøren | Hav repo, cloudkonto og domæne i jeres eget navn, og inviter leverandøren ind |
| Proprietære platforme | Undgå unødvendige afhængigheder af leverandørens egne værktøjer |
| Viden i enkelte hoveder | Kræv dokumentation der kan overdrages, og spred viden |
| Fastlåste data | Sørg for at data kan eksporteres i åbne, brugbare formater |
Den mest lumske er infrastruktur som leverandøren ejer fordi den ofte opstår “for nemheds skyld” tidligt i et projekt. At lade leverandøren sætte alt op på sin egen konto sparer en time i starten og koster en forhandling fra en svag position senere. Reglen er enkel: Alt det der ville være smertefuldt at miste, skal stå i jeres navn fra start, med leverandøren inviteret som gæst.
Sund kontinuitet kontra usund afhængighed
Pointen er ikke at undgå lange leverandørrelationer. De er ofte værdifulde. Pointen er at skelne mellem to ting der ser ens ud udefra, men er helt forskellige indeni.
- Sund kontinuitet er når I gerne fortsætter med en leverandør der leverer godt. I bliver fordi I vælger det, og I kunne gå hvis I ville.
- Usund afhængighed er når I bliver fordi I ikke kan gå. Valget er væk, og det ved leverandøren godt.
Forskellen mærkes først den dag noget skurrer. En god relation kan godt tåle at I har evnen til at skifte. Den hviler på at samarbejdet fungerer, ikke på at I sidder fast. Målet er altså ikke at skifte ofte, men altid at bevare muligheden.
Et scenarie: to virksomheder, samme leverandør
To virksomheder hyrede det samme bureau. Den ene lod bureauet eje repo, konti og al viden, “fordi det var nemt”. Den anden insisterede på selv at eje infrastrukturen, krævede løbende dokumentation og undgik bureauets mest proprietære værktøjer.
Da begge nogle år senere overvejede et skifte, var oplevelsen helt forskellig. Den første virksomhed fik at vide at en flytning ville tage måneder og koste betragteligt, og fortsatte modvilligt. Den anden konstaterede at et skifte ville tage nogle uger, og valgte at blive alligevel, men nu fordi de ville og ikke fordi de var nødt til det. Samme bureau, samme tid, modsat frihed.
Det årlige lock-in-tjek
Lock-in sniger sig ind, så tjek det regelmæssigt. Stil en gang om året det enkle spørgsmål: Kan vi skifte leverandør inden for seks måneder hvis vi bliver nødt til det?
For at svare gennemgår du tre ting. Ejer I selv repo, cloudkonto og domæne? Er dokumentationen god nok til at et nyt team kan tage over uden den nuværende leverandør? Kan løsningen og dataene flyttes uden urimeligt arbejde? Kan I svare ja med rimelig sikkerhed, er døren åben. Kan I ikke det, ved I nu hvor arbejdet skal lægges mens det stadig er en planlagt indsats og ikke en krise.
Vil du have en uafhængig vurdering af hvor låst I er, eller bygge det næste projekt så døren holdes åben fra start, hjælper vi hos Weapp gerne, og en teknisk gennemgang giver hurtigt svar på hvor frie I faktisk er i dag.
Ofte stillede spørgsmål
Opstår lock-in ikke primært gennem aftalen?
Sjældent. De fleste aftaler kan opsiges. Den reelle afhængighed sidder i praksis. Hvis koden er udokumenteret, kontiene ejes af leverandøren og løsningen hviler på deres egne værktøjer, betyder opsigelsesretten ikke meget, for I kan alligevel ikke flytte. Lock-in er som regel en teknisk og praktisk tilstand, ikke en juridisk klausul. Derfor bekæmpes den med praktiske modtræk.
Hvilke lock-in-mekanismer er de mest almindelige?
Fem går igen: udokumenteret kode som kun leverandøren forstår, konti og infrastruktur som leverandøren ejer, afhængighed af deres egne proprietære platforme, viden der kun findes i deres hoveder, og data i formater der er svære at få ud. Hver af dem binder jer på sin måde, og de forstærker ofte hinanden. Modtrækket mod dem alle er indsigt og eget ejerskab fra start.
Er al afhængighed af en leverandør af det onde?
Nej. Skellet går mellem sund kontinuitet og usund afhængighed. At man gerne vil fortsætte med en leverandør der fungerer godt, er kontinuitet: I bliver fordi I vælger det. Usund afhængighed er når I bliver fordi I ikke kan gå. Målet er ikke at undgå lange relationer, men altid at have evnen til at skifte hvis I skulle få brug for det.
Hvordan tjekker vi hvor låst vi er?
Stil en gang om året det enkle spørgsmål: Kan vi skifte leverandør inden for seks måneder hvis vi bliver nødt til det? Gennemgå om I ejer repo og konti, om dokumentationen er god nok til at en anden kan tage over, og om løsningen kan flyttes. Kan I ikke svare ja med rimelig sikkerhed, ved I hvor arbejdet skal lægges før behovet bliver akut.