Exitklausuler: din forsikring ved leverandørskift
Exitklausuler regulerer hvad der sker når et IT-samarbejde slutter: overdragelse af kode og dokumentation, videnoverførsel, opsigelsesvarsel og udlevering af data i et maskinlæsbart format. Skrevet rigtigt gør de et fremtidigt leverandørskift udramatisk. Det bedste tidspunkt at forhandle dem er før samarbejdet begynder, for da står du stadig stærkt i forhandlingen.
Ingen skriver under på en udviklingsaftale med tanken om at skifte leverandør. Alligevel er det netop ved underskriften at et fremtidigt skift bliver afgjort, for det er den eneste gang du står stærkt nok i forhandlingen til at gøre det udramatisk. Uden exitklausuler kan et skift blive dyrt, langtrukkent og afhængigt af god vilje hos en leverandør som du måske forlader i utilfredshed. Denne guide gennemgår de klausuler der gør skiftet til en ordnet proces i stedet for en konflikt.
Overdragelse: kode, dokumentation og viden
Kernen i en exitklausul er hvad leverandøren faktisk skal aflevere. Det er ikke nok at aftalen siger at I “ejer koden”. Den skal også regulere at koden bliver overdraget i brugbar stand.
En fuldstændig overdragelse omfatter fire dele:
- Kildekoden, komplet og klar til at blive bygget så en ny leverandør kan tage over uden at mangle dele.
- Dokumentationen, opdateret og tilstrækkelig til at forstå hvordan systemet er bygget og driftes.
- Adgang til konti og miljøer (servere, domæner, tredjepartstjenester) med en ordnet overførsel af ejerskabet.
- Videnoverførsel til det nye team, gerne i form af et aftalt antal timers bistand hvor den afgående leverandør besvarer spørgsmål.
Det sidste punkt er det der oftest bliver glemt. Kode uden viden er som en bygning uden tegninger: Alt er der, men ingen ved hvor ledningerne løber. Et par ugers overlap hvor den gamle leverandør er til rådighed, kan spare den nye for måneders gætteri, men kun hvis det står i aftalen, for i et afsluttet samarbejde er der sjældent velvilje at læne sig op ad.
Opsigelsesvarsel og udlevering af data
To vilkår afgør hvor gnidningsfrit selve frakoblingen går: hvor lang tid I har, og i hvilken stand I får jeres data med.
Opsigelsesvarslet skal være langt nok til at I kan nå at få en ny leverandør på plads og gennemføre en overdragelse, men ikke så langt at I sidder fast i et samarbejde der ikke fungerer. Det bør også være gensidigt og tydeligt så ingen af parterne kan trække processen ud.
Udleveringen af data er mindst lige så vigtig og bliver ofte overset. Jeres data er jeres, men det er ligegyldigt hvis I får dem ud i et format som I ikke kan bruge. Aftalen skal fastslå at data udleveres i et maskinlæsbart, dokumenteret standardformat der kan importeres andre steder, og ikke som et ulæseligt databasedump eller en bunke PDF’er. Et klassisk trick til at låse kunden inde er netop at gøre udleveringen så upraktisk at det føles nemmere at blive. En tydelig klausul lukker den dør.
Hvad der må koste ekstra, og hvad der skal være inkluderet
En rimelig exit er ikke gratis, men den skal heller ikke være en straf der gør et skift urentabelt. Grænsen går mellem faktisk merarbejde og det der burde have været der hele tiden.
| Post ved exit | Rimelig håndtering |
|---|---|
| Jeres egne data | Skal være inkluderet: udleveres i brugbart format uden ekstra gebyr |
| Kildekode I har betalt for | Skal være inkluderet: overdrages komplet uden tillæg |
| Grundlæggende dokumentation | Skal være inkluderet: skal holdes løbende opdateret |
| Timers bistand ved overdragelse | Må faktureres: faktisk udført arbejde til aftalt takst |
| Omfattende specialudtræk | Må faktureres: hvis det går ud over et standardformat |
Princippet er enkelt: Det I allerede har betalt for, skal I have med jer uden løsesum mens nyt arbejde under overgangen med rimelighed kan faktureres. Når grænsen står i aftalen, kan exitomkostningen ikke bruges til at låse jer inde.
Et konkret scenarie
En organisation ville skifte leverandør efter nogle år fordi samarbejdet var kølnet af og prisen steget. I aftalen var der en gennemtænkt exitklausul: tre måneders opsigelsesvarsel, kildekode og dokumentation der skulle overdrages komplet, udlevering af data i standardformat og tyve timers bistand til videnoverførsel.
Skiftet blev udramatisk. Den nye leverandør fik koden klar til at blive bygget, kunne stille spørgsmål til det afgående team under overgangen og importere data uden besvær. Det der uden klausulerne kunne være blevet en månedlang konflikt om hvem der ejede hvad, blev i stedet en planlagt overdragelse på nogle uger. Forsikringen der blev tegnet ved underskriften, viste sig at være langt mere værd end det havde kostet at forhandle den.
Forhandl trygheden på plads før du skriver under
Exitklausuler føles unødvendige i den optimistiske fase hvor en ny aftale bliver skrevet, og det er netop derfor de bliver glemt. Men de koster næsten ingenting at forhandle på det tidspunkt og bliver umulige at få igennem når der først er brug for dem. Se dem som en forsikring: Du håber at slippe for at bruge den, men du vil ikke tegne den når det allerede har brændt.
Hos Weapp arbejder vi for at vores kunder aldrig skal føle sig låst inde, og vi hjælper gerne med at vurdere exitvilkår som en del af vores ydelser. Står I over for at skulle skrive en udviklingsaftale? Kontakt os, så gennemgår vi hvilke klausuler der er værd at få på plads før pennen rammer papiret.
Ofte stillede spørgsmål
Hvad er en exitklausul i en IT-aftale?
En del af aftalen der regulerer hvordan samarbejdet afvikles, og hvad leverandøren skal aflevere når det slutter. Den dækker overdragelse af kode og dokumentation, videnoverførsel, opsigelsesvarsler og hvordan jeres data udleveres. Formålet er at et skift kan ske ordnet uanset om grunden er utilfredshed, prisændringer eller at I er vokset fra leverandøren.
Hvorfor skal man forhandle exit før samarbejdet overhovedet er begyndt?
Fordi det er dér I står stærkest i forhandlingen. Før aftalen underskrives, konkurrerer leverandøren om jeres opgave og er villig til at gå med til rimelige vilkår. Når samarbejdet først er i gang, og I er afhængige af leverandøren, er de samme vilkår meget sværere at få igennem. At regulere exit tidligt er billigst og tryggest, lidt ligesom en forsikring man tegner før det brænder.
Hvad skal indgå i en overdragelse ved leverandørskift?
Kildekoden i komplet stand og klar til at blive bygget, opdateret dokumentation, adgang til konti og miljøer samt videnoverførsel til den nye leverandør. Ofte bør aftalen også angive et antal timers bistand hvor den afgående leverandør besvarer spørgsmål under overgangen. Uden reguleret videnoverførsel kan koden være komplet og alligevel svær for det næste team at overtage.
I hvilket format skal data udleveres ved exit?
I et maskinlæsbart og dokumenteret standardformat så de kan importeres i et nyt system. Et PDF-dump eller en låst database som I ikke kan tolke, er ikke en rigtig udlevering af data. Aftalen bør fastslå at jeres data er jeres, at de udleveres i brugbar stand, og at intet holdes som gidsel for at presse fortsat samarbejde eller ekstra betaling igennem.
Hvad må en exit rimeligvis koste ekstra?
Faktisk udført arbejde under selve overdragelsen kan med rimelighed faktureres, f.eks. timers bistand og et større dataudtræk. Det der ikke skal koste ekstra, er det der burde have været der hele tiden: jeres egne data, den kode I har betalt for, og grundlæggende dokumentation. Aftalen bør trække en tydelig grænse så exitomkostningen ikke bliver en måde at låse jer inde på.