De toegevoegde waarde van software bij M&A

De businesscase voor de M&A-transactie combineert een grondige technische analyse met het commerciële perspectief van de software.

Door Erik Oltmans en Sander van Weele, associate partners bij EY-Parthenon

Software is eating the world, zei ondernemer Marc Andreessen al in 2011. De Amerikaanse ondernemer, investeerder en software engineer voorspelde dat de leidende internetbedrijven de traditionele ‘brick and mortar’-winkels zouden verdrijven. Andreessen gaf Amazon als voorbeeld. Het bedrijf dat vrijwel alles verkoopt en geen fysieke winkels meer nodig heeft. ‘Clicks’ maken ‘bricks’ overbodig. Andreessen’s uitspraak is al haast een cliché, met de uitzondering die de regel bevestigt: uitgerekend Amazon nam winkelketen WholeFoods over.

Toch zien we de laatste jaren talloze bedrijven met een sterk digitaal gedreven businessmodel concurreren met traditionele bedrijven. Mede dankzij hun focus op software en data kunnen die nieuwkomers zich onderscheiden, en verstoren ze de gevestigde orde met hun exponentiële groei. 

Software als belangrijke asset

Software is dan ook een belangrijke asset, die de basis vormt voor cashflow-genererende activiteiten. Heel anders dan de IT-systemen die voornamelijk dienen om bestaande processen te stroomlijnen - en die hooguit leiden tot minder fouten, minder dubbel werk, minder tijdrovend werk en daarmee tot lagere kosten. De software die 'de wereld opeet' draagt werkelijk bij tot de differentiatie en waardecreatie van een bedrijf. Daarmee zijn softwareproducten en de onderliggende technologie steeds belangrijker voor de businesscase bij een investering of overname, en is een zorgvuldige analyse ervan belangrijker geworden.

Met dergelijke analyses houden wij ons bij de Software Strategy Group (SSG) van EY-Parthenon bezig. We voeren strategische analyses uit in de context van investeringen en bedrijfsovernames (due diligence) en we geven strategisch advies over hoe bedrijven software nog beter kunnen inzetten om te groeien (value creation). 

Analysemethodiek

Er is steeds meer behoefte om vanuit een technisch perspectief te kijken naar een bedrijf en de software waarmee omzet wordt gegenereerd. We doen dat altijd met een multidisciplinair team van drie tot vijf mensen, die in een paar weken de software doorlichten op zowel de technische als de bedrijfskundige aspecten. We werken samen met het technische team van de klant, bestaande uit de CTO, architecten en softwareontwikkelaars, en ook met de sales- en productmanagers en de CFO. Het resultaat van ons onderzoek is een combinatie van commerciële en financiële inzichten enerzijds, en technische analyses anderzijds. Precies in die combinatie ligt de grootste meerwaarde. 

We hebben begrip van de techniek, architectuur en broncode van software en vertalen dit naar concrete implicaties voor de business en groeiplannen. Deels vanuit een technische invalshoek - wat doet de software, werkt het zoals het zou moeten, is het schaalbaar en worden moderne software ontwikkelmethoden toegepast - en deels vanuit een commerciële invalshoek - hoe draagt de software bij aan onderscheid in de markt, op welke aspecten zijn concurrenten sterker en waar vragen klanten om. 

Software due diligence in 5 stappen

Een product & technologie due diligence legt de technische volwassenheid en de flexibiliteit om de software op te schalen bloot. Een typisch traject bestaat in de regel uit vijf 'bouwblokken'.

1. Markt en positionering. Hoe past een software product binnen de waardeketen waarin een bedrijf opereert en hoe verhoudt dit zich tot wat de concurrentie aanbiedt. We brengen daarbij onder meer markttrends, positionering, marktaandelen en lock-in van het klantenbestand in kaart.
2. Product en de roadmap. Wat zijn de huidige features van een product, hoe goed zijn die, wat denkt het bedrijf daar in de toekomst aan toe te voegen?
3. Technologie en architectuur. Dan duiken we de techniek in, en kijken we naar zaken als de kwaliteit van de broncode.
4. Research en developmentorganisatie. Wie ontwikkelt de software? Hoe stabiel is dat team? Op wat voor manier werken ze samen? Welke processen hanteren ze?
5. Hosting en security. Dan gaat het om beantwoording van vragen als: Hoe efficiënt is de (cloud) infrastructuur waar vandaan de software wordt geleverd? Hoe is de continuïteit in het kader van cyber security en data privacy geborgd? 

Belangrijkste uitdagingen

Alles valt of staat met een goed begrip van de techniek. Je moet daarvoor alles snappen van de software, tot aan de onderliggende programmeercode toe. Ook moet je inzicht hebben in wat de mensen die het product maken precies doen. Wij nemen deze hindernis onder andere door de ontwikkelaars te interviewen over hun werk - en bekijken dan niet alleen wat ze maken, maar ook hoe ze het werk hebben georganiseerd: Welke manier hebben jullie om te testen? Welke methodes hebben jullie om de kwaliteit te waarborgen? Hoe integreren jullie het werk van de ene programmeur met dan van een ander? Uiteraard is dat soort vragen ook van belang. Denk alleen al aan de mogelijke gevolgen als een belangrijke ontwikkelaar wegvalt. Als het werk goed georganiseerd is, is rekening gehouden met deze afhankelijkheid van personen, maar dat is niet vanzelfsprekend.

Dan komt de eigenlijke grootste uitdaging: het vertalen van deze technische inzichten naar financiële implicaties, en naar inzichten die een rol spelen in de investment thesis. Wat betekent een lage softwarekwaliteit voor de transactie? Welke financiële risico’s ontstaan door de aanwezigheid van veel legacy software? Wat zijn de investeringen die nodig zijn om een haperend testproces te verbeteren? Dat zijn de typische vragen die wij voor investeerders beantwoorden.

Omdat we zoveel van dit soort trajecten doen, kunnen we de softwarekwaliteit ook benchmarken en uitdrukken in een getal op een schaal van 0 tot 10. Er zit natuurlijk een element van subjectiviteit in zo'n cijfer. Maar we doen dit aan de hand van methoden die zich internationaal hebben bewezen, wat de acceptatie door alle betrokken partijen vergemakkelijkt.

Er zijn ook situaties waarin we het bedrijf niet van binnen kunnen bekijken, zoals wanneer een potentiële 'target' nog niet op de hoogte is van de interesse van een investeringsmaatschappij of nog niet meewerkt. Wij kunnen dan een outside-in analyse uitvoeren op grond van informatie uit publieke bronnen. Ook kunnen we die informatie verrijken - zodat we er bijvoorbeeld achter kunnen komen met wat voor ontwikkelsoftware een bedrijf werkt, ook al zegt het daar zelf niets over.

Standaardsoftware vs maatwerksoftware

Met de opkomst van cloudsoftware zien we dat de standaardisatie van software is toegenomen en ook is er tegenwoordig veel tooling om het aantal programmeerfouten te beperken. Ook bieden de cloud dienstverleners allerlei voorzieningen om gemakkelijk eigen software te bouwen, onderhouden en hosten.

Toch bestaat er nog veel maatwerk en het belang om te snappen hoe die maatwerksoftware onder de motorkap werkt is enkel toegenomen. Wij vermoeden dat software juist een steeds belangrijker onderscheidend kenmerk zal zijn, en dat het dus uitermate relevant is om die ‘asset’ te beoordelen bij de waardering van een onderneming.