Opdager I efter et virksomhedskøb, at softwaren ikke er, som sælger beskrev den, er det første skridt at dokumentere, ikke at rette. Fastlås, hvad I fik at se før handlen, og hvordan softwaren faktisk ser ud nu. Find samtidig fristerne i overdragelsesaftalen frem. Mange aftaler kræver, at køberen giver sælger skriftlig besked inden for en bestemt periode, og den kan være kortere, end I tror.
Artiklen er til den nye ejer, direktøren og den IT- eller udviklingsansvarlige i den købte virksomhed, når der er opstået tvivl om det, der blev købt. Den handler om tvisten, der kan følge. Den generelle overtagelse af adgange er beskrevet for sig. → Efter overtagelsen: den tidligere ejer har stadig adgang
Typiske afvigelser
- Funktioner, der blev vist i en demonstration, findes ikke eller virker kun delvist.
- Produktet bygger på komponenter med licenser, der ikke tillader den måde, det sælges på.
- Koden kan ikke bygges eller udrulles uden en bestemt udvikler, der er stoppet.
- Sikkerhedsforhold er dårligere end beskrevet, eller der har været hændelser, som ikke blev oplyst.
- Kunderne bruger en anden version end den, der blev præsenteret.
- Nøglekunder har problemer, som ikke fremgik af supportoversigten.
Ofte er det ikke én stor opdagelse, men en række små, der efter nogle måneder tegner et mønster. Begynd at notere dem, så snart den første dukker op, også selv om I endnu ikke ved, om det bliver til noget. Nogle afvigelser er forventelige i enhver handel. Andre kan være omfattet af sælgers garantier i aftalen. Hvad der er hvad, er en juridisk vurdering, som kræver et teknisk grundlag.
Det første, I gør
- Stop større ændringer i koden og opsætningen, indtil afvigelsen er dokumenteret.
- Sikr datarummet. Find jeres kopi af datarummet fra handlen, med log og spørgsmål og svar. Har I den ikke, så bed rådgiverne eller datarumsudbyderen om den nu.
- Saml det, sælger præsenterede. Præsentationer, demoer, produktbeskrivelser, svar på spørgsmål og mails.
- Fastlås softwarens tilstand. Tag en kopi af hele kodens versionsstyring med historik, konfiguration og dokumentation på en bestemt dato.
- Notér afvigelserne konkret med dato, eksempel og henvisning til det, der blev oplyst.
- Find fristerne frem i overdragelsesaftalen og giv advokaten besked med det samme.
Hvad blev der sagt, og hvad er der nu?
Tvisten handler om forskellen mellem to billeder: det, sælger viste og sagde før handlen, og det, I fandt bagefter. Begge billeder skal dokumenteres.
- Datarummets indhold og log · Kopi af koden med historik
- Præsentationer og demoer · Skærmoptagelser af de faktiske funktioner
- Svar på købers spørgsmål · Fejllister og supportsager
- Garantier og bilag i aftalen · Beskrivelse af hver afvigelse med eksempel
- Mails og mødereferater · Erklæringer fra medarbejdere, der kender systemet
Var der en demonstration, så find ud af, hvilket miljø og hvilken version der blev vist. Det kan være en særlig demoversion, der aldrig blev sat i drift. Optagelser fra præsentationen eller skærmbilleder i mails kan være vigtige.
→ Virksomhedsoverdragelse: datarum og garantibrud
Pas på jeres egne ændringer
Den største risiko i den første tid er, at I selv forandrer det, der skal vurderes. Nye udviklere retter fejl, opdaterer biblioteker og omskriver dele af koden. Det er naturligt, men det gør det sværere at vise, hvordan softwaren så ud ved overtagelsen.
Kodens versionsstyring gemmer historikken, men kun hvis den ikke bliver omskrevet. Sørg for, at ingen sletter grene eller omskriver historikken, og tag en fast kopi med kontrolværdier på et tidspunkt tæt på overtagelsen. → Kildekode og Git som bevis
Driften skal også fortsætte. Kunderne skal have rettelser, og sikkerhedshuller skal lukkes, selv om de er en del af tvisten. Lav derfor en simpel regel: dokumentér først, ret bagefter, og notér hver rettelse med dato og årsag.
Medarbejdere fra den gamle ejer
De udviklere og driftsfolk, der fulgte med virksomheden, kender systemet bedst. De kan også være loyale over for den tidligere ejer, eller de kan have været med til at give de oplysninger, der nu er omstridte. Tal med advokaten om, hvordan og hvornår de skal interviewes. Bed dem ikke om at skrive vurderinger af sælger. Bed dem beskrive systemet, som det er. → Medarbejdere skal afgive forklaring
Sælger skal have besked
Mange overdragelsesaftaler kræver, at køberen giver sælger skriftlig meddelelse om et krav inden for en frist og med en vis beskrivelse. Advokaten formulerer meddelelsen, men I skal levere indholdet: hvad er afvigelsen, hvordan viser den sig, og hvad bygger I det på. Jo mere konkret, jo bedre. Henvis til bestemte funktioner, filer eller hændelser. Generelle klager over “dårlig kode” er svære at bruge.
Opgør konsekvenserne løbende
Et krav mod sælger skal typisk kunne opgøres. Notér derfor fra starten, hvad afvigelsen koster jer: ekstra udviklingstimer, eksterne konsulenter, licenser, der skal købes, kunder, der får kompensation, og salg, der bliver udskudt. Skriv for hver post, hvilken afvigelse den skyldes, og gem fakturaer og timeregistreringer. Bland ikke almindelig videreudvikling sammen med udbedring af afvigelser. Det er netop den sondring, sælger vil udfordre.
Er der aftalt earn-out eller udskudt betaling, kan afvigelsen også påvirke den opgørelse. Tal med advokaten, før I modregner noget.
Hvem gør hvad
- Ny ejer og direktør · Beslutter, om der skal rejses krav
- IT- eller udviklingsansvarlig · Fastlåser koden og beskriver afvigelser
- Økonomi · Opgør konsekvenser, fx ekstra udviklingsomkostninger
- Advokat · Vurderer garantier, frister og meddelelse til sælger
- IT-sagkyndig · Vurderer de tekniske forhold uvildigt
Det må I ikke gøre
- Ændre store dele af koden, før tilstanden er fastlåst.
- Konfrontere sælger mundtligt uden at have talt med advokaten.
- Lade datarummet lukke ned uden at have en kopi.
- Overse fristerne, fordi I først vil være sikre på omfanget.
- Blande forventelige fejl og egentlige afvigelser i samme liste. Skil dem ad.
Hvornår skal I have hjælp udefra?
Når afvigelsen kan føre til et krav mod sælger. Advokaten skal vurdere garantierne og fristerne. En uvildig IT-sagkyndig kan vurdere de tekniske forhold: hvordan softwaren faktisk er, hvordan det kan dokumenteres, og hvordan det forholder sig til det, der blev oplyst. Den sagkyndige skal ikke have bindinger til hverken sælger eller køber, hvis vurderingen skal holde i en tvist. Nielco IT er uvildig, sælger ikke produkter og tager ikke opgaver for modparten i samme tvist. → IT-skøn i tvister om IT-projekter og software
Læs også: Leverandøren går konkurs midt i projektet: kildekode, data og escrow · Open source-licensen er brudt: tvisten om jeres produkt
→ Tvist med en IT-leverandør eller en kunde · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
