Private Equity-partijen en andere software-investeerders maken graag gebruik van onze Technical Due Diligence (TDD). Want bij de voorbereiding van overnames komen ze veel vragen tegen over bruikbaarheid, technische en functionele status en toekomst van softwaretoepassingen. In dit artikel laat ik zien hoe wij die vragen beantwoorden en wanneer het een goed idee is om een ‘TDD’ te laten doen.
Drie aanleidingen voor een Technical Due Dilligence
We zien in de praktijk drie aanleidingen om een Technical Due Dilligence uit te voeren:
- Een private equity-partij wil een nieuw platform op te zetten door een bestaand product uit te breiden met add-ons: de buy & build-strategie. De uitdaging is het vinden van een softwarepartij die aansluit op de beoogde technologie. Het is belangrijk dat andere (nieuwe) ontwikkelteams de software kunnen overnemen, aanpassen en doorontwikkelen. De PE-partij gebruikt de TDD om dit zeker te weten.
- De vraag of een aangekocht of aan te kopen systeem kan worden doorontwikkeld of ingepast in een ander platform.
- Het software-landschap doorlichten van een grotere organisatie, vaak specifiek gericht op (de waarde van) een bepaalde tool. Een goed voorbeeld is een groeiende MKB-partij die een sprong maakt van on-premises software naar een cloud- of SaaS-oplossing.
Uiteindelijk gaat het altijd om een analyse die snel en goed verslag doet van toekomstige mogelijkheden en onmogelijkheden van een stuk software. Met als doel de waarde van de software te bepalen en tijdig de juiste beslissingen te nemen.
Ongezien software overnemen is risicovol, net als het kopen van een gebruikte auto zonder technische keuring. Maar een auto met gebreken kun je nog naar de garage brengen. Een organisatie die met onbruikbare software zit opgescheept is veel moeilijker te repareren, of wordt zelfs een totale ramp. Ons TDD-assessment geeft een duidelijke en goed onderbouwde analyse om te kopen (al dan niet tegen een lagere prijs) of om van de koop af te zien.
Zeven stappen TDD proces
Ons TDD proces bestaat uit de volgende 7 stappen:
In stap 1 stellen we de vraag: ‘wat wil je bereiken?’ Wat is het plan achter de aankoop of investering? De technische eisen die je stelt aan een product, hangen namelijk sterk af van wat je er in de toekomst mee wilt doen. Met deze kennis kunnen we de TDD gericht uitvoeren. Een integratieplatform dat je niet gaat gebruiken, of een mobiele app die uit de lucht moet omdat je al weet dat hij een securityrisico is, slaan we over. Zo concentreren we ons op de belangrijke zaken.
Vervolgens doen we in stap 2 een quick scan van het product. Want zelfs een analyse van openbare bronnen geeft al snel een bruikbaar beeld. We bekijken websites, demo’s, sociale media, nieuwsberichten… Alle publieke informatie die voor handen is. We bekijken ook het bredere kader, zoals de sector of branche waarin het bedrijf actief is en de specifieke uitdagingen en trends die daar spelen. Na deze analyse weten we op welke vragen we in de volgende stappen antwoord moeten krijgen.
Stap 3 is een kick-off met de belanghebbenden van de kopende en de verkopende partij, waaronder beide CTO’s, om het proces toe te lichten en vervolgafspraken te maken.
Hierna volgt stap 4: een technische sessie met de CTO (of iemand in een soortgelijke functie) van de verkopende partij om het applicatielandschap in detail in beeld te krijgen. We maken hiervoor een IRL (Information Request List, een geprioriteerde vragenlijst) met alle informatie die we nodig hebben. Denk aan certificeringen, ISO- en andere keurmerken, specifieke ontwikkelprocessen en alle andere zaken die specifiek zijn voor de software, schaalbaarheid, onderhoudbaarheid en architectuur.
In de vijfde stap interviewen we de CTO, product owner en ontwikkelaars over de software en het ontwikkelproces. We organiseren deze interviews ook om de visie, productfilosofie en roadmap van het bedrijf beter te begrijpen. Op basis van de verzamelde kennis beoordelen bepalen we welke verdiepende informatie we nog nodig hebben.
Stap 6 is de technische analyse van het product op criteria van betrouwbaarheid, onderhoudbaarheid, cybersecurity en compliance. We scannen de broncode uiterst nauwgezet op een aantal eigenschappen. Voor kleine toepassingen is dit overzichtelijk en makkelijk te doen; voor uitgebreide systemen met tientallen applicaties die niet allemaal even belangrijk zijn, is het goed om in de eerste fase prioriteiten te stellen en de focus op de kern van de applicatie te leggen. We geven geen subjectief oordeel maar toetsen aan standaarden die in de markt gelden. Op ieder onderdeel geven we een score van A t/m E.
De laatste en zevende stap is een oplevering van een volledige rapportage van het voorafgaande, voorzien van een advies. De aankopende partij gebruikt rapport en advies om de verdere strategie te bepalen en om met zekerheid en rust beslissingen te nemen over het al dan niet aangaan van grote financiële verplichtingen.
Waarom wij al ruim 50 TDD’s hebben uitgevoerd
Een reden dat tech investeerders bij Blis Digital aankloppen is onze kennis van en ervaring met het bedenken, ontwikkelen en onderhouden van mission critical software. Omdat we hier al ruim 17 jaar dagelijks mee bezig zijn, kennen we de markt en de uitdagingen als geen ander. We weten waar klanten tegen aan gaan lopen als ze besluiten voor doorontwikkeling.
Een Technical Due Diligence betekent niet per se dat wij ook ontwikkeling en onderhoud gaan doen, al is dat meestal wel een optie. We doen een TDD altijd zo, dat hij een hele waardevolle briefing is aan de partij die dit wel gaat doen. Een TDD is wat mij betreft geslaagd als ons rapport zorgt voor inzicht en begrip en de klant en betrokken partijen echt helpt in het beslissingstraject van aankoop of overname, of bij de beoordeling van een applicatie.
Meer weten over Technical Due Diligence?
Investeer je in softwarebedrijven of sta je voor een grote overname? Of wil je weten hoe toekomstbestendig je interne IT-landschap nog is? Wij geven je met deze unieke dienst snel en gedetailleerd antwoord op alle vragen over softwarekwaliteit. Lees hier meer onze TDD aanpak.
