De waarde van je bedrijf verhogen? Houd rekening met due diligence van je platform

De staat van je platform en applicaties heeft veel invloed op de waarde van je bedrijf en de uiteindelijke deal die je kunt sluiten. Als de koper zelf nog uitgebreid moet sleutelen aan de software zal hij de hiermee gemoeide kosten van de overnameprijs aftrekken. Goed voorbereid zijn op een technische due diligence loont dan ook en verhoogt de waarde van je platformen en IT-assets.

Maar waar wordt op gelet bij een due diligence van je codebase en platform? En hoe krijg jij je software zo voor elkaar dat je helemaal klaar bent als je ooit een DD krijgt? Lees verder voor de antwoorden.

Due diligence en IT: wat komt allemaal aan bod?

Tijdens een due diligence-onderzoek naar een digitaal platform komen diverse zaken aan bod. Om tot een afgewogen oordeel te kunnen komen, zijn er namelijk heel wat zaken die de verkopende partij graag wil weten. We geven je een overzicht van de belangrijkste dingen waar op wordt gelet.

Overzicht van de software

IT-technische due diligence van een platform begint met een overzicht van de software. Uit welke software-onderdelen bestaat het platform? Wat doen die componenten precies en wat zijn de onderlinge afhankelijkheden? Uit welke onderdelen is de codebase samengesteld?

Het volgende aandachtspunt is het krijgen van een algehele indruk van de werking van het platform. Welke functionaliteiten heeft het platform? Voor welke processen en werkzaamheden is het van belang? En hoe zit het met de performance? Voldoet het platform op het gebied van snelheid, functionaliteit en aanpasbaarheid aan de eisen van de moderne tijd?

Ook de ontstaansgeschiedenis en de manier waarop een platform wordt gehost spelen een rol bij due diligence. Uit de ontstaansgeschiedenis kan bijvoorbeeld blijken dat het platform is gebouwd met verouderde technologie en naar de toekomst toe niet of heel lastig aanpasbaar of uitbreidbaar is. Ook de vraag of het platform in de cloud of on-premises staat, heeft invloed op de waarde. Een platform dat in de cloud staat of makkelijk en goedkoop om te bouwen is naar een cloudversie, is in het tijdperk van cloudcomputing natuurlijk waardevoller dan een oplossing die helemaal ingesteld is op on-premise gebruik.

De gebruikte techniek

Ook de gebruikte techniek speelt een rol. Denk aan de gebruikte programmeertaal. Gebruik je bijvoorbeeld Java voor het ontwikkelen of doorontwikkelen van een platform? Dan is het voor de koper belangrijk om te weten met welke versie (een oude of de laatste nieuwe) je werkt.

Andere technische aandachtspunten zijn het aantal en type koppelingen. Heb je te maken met een monolithische, weinig flexibele legacy-applicatie die in de loop van de jaren uitgegroeid is tot een complex vlechtwerk van koppelingen en uitbreidingen? Of is er sprake van een modulair platform dat gebruikmaakt van API’s en microservices? Het laatste type is makkelijker over te nemen en toekomstbestendiger, waardoor het meer waarde vertegenwoordigt.

Ook de uniciteit van de techniek achter een platform heeft gevolgen voor de waarde. Een maatwerk platform dat baanbrekende functionaliteiten levert, is meer waard dan een generiek platform dat makkelijk en tegen relatief lage kosten na te bouwen is.

Het ontwikkelproces

De kopende partij zal bij een DD-onderzoek ook kijken naar de manier waarop je een platform hebt ontwikkeld. Welke ontwikkelmethode is gehanteerd? Welk scrumteams hebben eraan gewerkt? Is er sprake van een goede source control, waarbij wijzigingen in de broncode goed en consequent zijn gedocumenteerd? En hoeveel aandacht is er besteed aan het test- en deploymentproces? Al deze zaken zeggen iets over hoe zorgvuldig een organisatie het bouwen van een platform heeft aangepakt.

Hosting, performance en veiligheid

De drie-eenheid hosting, performance en veiligheid is eveneens belangrijk bij een DD-onderzoek. Hoe wordt het platform gehost en wat zijn de mogelijkheden? En hoe zit het met de schaalbaarheid? Is het platform makkelijk uit te breiden als de kopende organisatie snel groeit en meer resources, functionaliteiten en rekenkracht nodig heeft?

In een tijd waarin cyberrisico’s een onvermijdelijk onderdeel zijn van digitaal ondernemen, is veiligheid natuurlijk een ding. Hoe zit het met de veiligheid van de broncode? Beschikt een platform over goede en beproefde veiligheidstools en zijn veiligheidsupdates altijd correct en consequent doorgevoerd? En zijn er zowel lokale back-ups als back-ups op afstand beschikbaar van belangrijke data en platform onderdelen?

Personen

Ook het menselijke element speelt een (soms verrassend) grote rol bij due diligence in de IT-wereld. Welke personen zijn verantwoordelijk voor het beheren van het platform en de codebase? En hoe is dat binnen de verkopende organisatie geregeld? Een belangrijk punt is kennisdeling. Idealiter zijn er meerdere mensen binnen de organisatie met kennis van zaken. Stel jezelf altijd de volgende vraag: is het een onoverkomelijk probleem als een bepaalde technische man, vrouw of derde partij (bijvoorbeeld een bureau dat het platform beheert) wegvalt of zijn er anderen die het werk moeiteloos kunnen overnemen?

Technical debt

De ‘technische schuld’ (technical debt) is medebepalend voor de waarde van een platform en de bijbehorende codebase. Met de technical debt doelen we op de dingen die de kopende partij nog moet verbeteren aan een platform of code. Hoe langer die lijst is, hoe groter het deel is dat van de koopprijs afgaat. De koper moet namelijk extra kosten maken om het platform af te stemmen op en helemaal geschikt te maken voor zijn business.

Due diligence met Oberon

Zoals je ziet, passeren er aardig wat punten de revue bij een DD-onderzoek. Een grondige voorbereiding is dan ook geen overbodige luxe als je de hoofdprijs wilt binnenhalen voor je IT-assets. Oberon doet veel van dit soort DD-trajecten. We richten ons daarbij op de onderstaande punten:

We beginnen met het doornemen van alle beschikbare informatie over je platform en de bovengenoemde deelonderwerpen.

Vervolgens stellen we een gestructureerde lijst op met extra vragen over belangrijke onderwerpen als techniek, veiligheid en persoonsgegevens. Die leiden tot een nog completer beeld van de sterktes en zwaktes van het platform.

We vragen de klant om te laten zien wat de software precies doet en kan. Vervolgens verzoeken we de organisatie om ons toegang te verlenen, zodat we zelf door het platform kunnen klikken en onder water kunnen kijken. Zo’n frisse blik van buiten levert vaak waardevolle nieuwe inzichten op.

Op basis van alle antwoorden, de demo en eigen onderzoek maken we in een dataroom (beveiligde omgeving) een lijst met vervolgvragen. Die komen meestal ook als bewijsmateriaal bij de bewijsstukken.

We schrijven een rapport met alles wat wij gehoord en gezien hebben en onze conclusies. Vaak komen daar ook nog antwoorden op vragen vanuit de koper bij. Dit rapport gaat dan naar onze klant (de koper) zodat die dit kan gebruiken in de verdere onderhandelingen.

Juist omdat we zelf DD-trajecten uitvoeren, weten wij als geen ander hoe je een goed digitaal platform bouwt. De platformen die wij bouwen voldoen aan de eisen die in een DD-traject worden gesteld, waardoor je dus altijd voorbereid bent op de toekomst.

Meer weten?

Wil je ook digitale platforms bouwen met een eventuele exit in het achterhoofd en goed voorbereid zijn op een toekomstige technische due diligence? En zoek je een partij die op dit vlak van wanten weet? Neem dan gerust contact op met Oberon.