Eine Software Due Diligence bringt bei Tech-Targets viel Licht in das Dunkel der ungewohnten Risiken (Teil 1)

Inhaltsverzeichnis

Einleitung

Diese Blogserie ist auch als Artikel in der Ausgabe 11/2020 der deutschen M&A Review erschienen. Die spezifische Ausgabe der M&A Review ist hier zu finden.

Die Blogserie geht auf folgende Aspekte einer Software Due Diligence ein:

1. die Gründe, warum Software-Targets besondere Bewertungsrisiken aufweisen. Und weshalb eine fokussierte Software Due Diligence Voraussetzung ist, um technologische Risiken bei der Akquisition von Software-Unternehmen bewerten zu können,
2. die Untersuchungsfelder einer Software Due Diligence und warum eine Mischung an Tools und Erfahrung dafür nötig ist und
3. dem Ablauf einer Software Due Diligence und dessen Deliverables.

Im folgenden Teil 1 gehen wir auf auf den ersten Punkt der besoneren Bewertungsrisiken von Software-Targets ein.

Die zügig fortschreitende digitale Transformation fordert viele Unternehmen technologisch heraus. Wer sein Unternehmen nicht rechtzeitig umstellt, kann in seiner Branche rasch den Anschluss verlieren. Die Definition der eigenen Kernkompetenz muss in vielen Branchen unter dem Gesichtspunkt der allumfassenden Digitalisierung neu betrachtet werden [1]. Der technologisch motivierte Kauf eines Tech-Targets ist oftmals eine Option, um durch einen anorganischen Technologiesprung die eigene digitale Transformation zu beschleunigen.

Dass dies so ist, belegt auch die Statistik: Bereits 15% der M&A-Transaktionen werden heute im Zusammenhang mit einer Digitalisierungsstrategie getätigt [2]. Ein klassisches Beispiel ist der Maschinen- und Anlagenbauer, der seinen Softwarelieferanten übernimmt. Ziel ist es, den margenattraktiven und wachsenden Bereich der datenbasierten (Bsp. IoT) Serviceleistungen als neue Kernkompetenz weiterzuentwickeln. Es heißt zwar Daten seien das neue Gold – es ist aber die Software, die aus kryptischen Daten überhaupt erst kommerziell verwertbare Informationen macht.

Die Kerntechnologie der Tech-Targets, die hier betrachtet werden, ist deshalb Software. Neben Softwareunternehmen, die bereits etabliert sind, sind oftmals auch Tech-Start-ups interessante Akquisitionsziele. Gemeinsam haben beide, dass bei Software-Assets ein vergleichsweise hohes Investitionsrisiko vorliegt, weil die Produktfunktionalitäten einen kurzen Life-Cycle haben und sich der nachhaltige Wert der Assets nicht offensichtlich erschließt. Es ist ohne Softwarespezialisten und spezielle Tools nicht zu erkennen, ob eine Software noch unreif oder schon veraltet ist oder nur unprofessionell programmiert wurde. 

Sinngemäß gelten die Ausführungen auch für Unternehmen mit umfangreichen Softwareanwendungen, die unternehmensintern entwickelt wurden. Sie stellen einen wichtigen Faktor in der Wettbewerbsdifferenzierung und Profitabilität dar, werden aber nur für den Eigenbedarf eingesetzt. Der Fokus der Darstellung ist auf die Investorenseite ausgerichtet. Einige Hinweise für den Verkäuferseite sind als solche gekennzeichnet.

Software-Targets haben besondere Bewertungsrisiken

Um es vorwegzunehmen, eine Software Due Diligence sollte nicht mit einer IT Due Diligence verwechselt oder als Teil davon betrachtet werden. Die benötigten Tools und Skills sind völlig unterschiedlich. Im Nachfolgenden fokussieren sich die Autoren auf die Software Due Diligence und verweisen für die ebenfalls nützliche IT Due Diligence auf [3].

Tech-Targets mit Software als Produkt oder Kerntechnologie sind hinsichtlich ihrer Bewertung herausfordernde Akquisitionen. Die Bewertung dieser Unternehmen wird sowohl beim Verkäufer als auch beim Investor aus Zukunftsprojektionen abgeleitet, die im Falle von Start-ups oftmals sehr optimistisch sind. Selten basieren sie hingegen auf einer belastbaren historischen Datenbasis in puncto Marktrelevanz, Wettbewerbsvorsprung oder Nachhaltigkeit eines innovativen Einkommensmodells. Ein erfahrener Investor kann diese Informationen hinsichtlich kommerzieller, legaler oder steuerlicher Risiken nach einer Due Diligence einschätzen.

Nur im Ausnahmefall wird aber die Frage adäquat beantwortet, ob der Life-Cycle der Software-Assets nicht schon weitestgehend abgelaufen ist und sie möglicherweise nicht mehr lange mit wirtschaftlich sinnvollem Aufwand an neue Anforderungen angepasst werden können. Offen bleibt zudem die Frage, ob die technologische Basis und die Entwicklungsprozesse für die ambitionierten Investment-Annahmen ausreichend skalierbar oder integrierbar sind. Ebenso nicht beantwortet wird außerdem, ob es Risiken in der Know-how-Verteilung bei den Schlüsselentwicklern oder durch eine fehlende Dokumentation gibt. 

Die Entwicklungsprozesse verdienen dabei besondere Beachtung der Berater, da die digitale Transformation den Anspruch an die Softwareentwicklung grundlegend verändert hat. Es geht nicht mehr nur um das Optimieren oder Stabilisieren. Es geht darum, eine ständig gut gefüllte Pipeline mit Innovationen effizient und zügig zur Marktreife zu entwickeln. Diese Fragen nach den relevanten Qualitäts-, Entwicklungs- und Potenzialmerkmalen einer Software und seiner Entwicklungsprozesse können bei einer geplanten M&A-Transaktion nur durch eine Software Due Diligence beantwortet werden.

Zusätzlich ist zu beachten, dass die untersuchte Software im Zeitraum zwischen Due Diligence und Closing weiterentwickelt und verändert wird. Je nach Dauer der Vertragsverhandlungen können diese Veränderungen (Fehlerbehebungen, Marktanforderungen, R&D-Roadmap) durchaus wesentlich, aber auch wichtig und sinnvoll sein. Die Autoren empfehlen einen Vorher-Nachher-Vergleich der Software-Assets im Vertrag aufzunehmen. Damit ist gewährleistet, dass der erfolgreiche Investor validieren kann, ob bei der zum Zeitpunkt des Übergangs veränderten Software keine neuen Risiken zu Tage treten. Mithilfe des initialen Einsatzes und eines erneuten Laufs der Analyse-Software reichen den Beratern dafür wenige Tage Aufwand.

Ein Investor sollte die Technischen Schulden der Software kennen

Eine besondere Herausforderung für den kommerziellen Erfolg einer Software sind die sogenannten Technischen Schulden (Technical Debt). Diese entstehen zum Beispiel in der agilen Softwareentwicklung durch die methodenspezifische Fokussierung auf die Funktionalität der Software – am Ende jedes Sprints (Teilentwicklung) muss ein Produkt mit neuen Features stehen, ohne dass explizit Zeit für Qualitätsverbesserung eingeräumt wird. Entwickler, die durch ein knappes Budget, Zeitdruck oder unklare Anforderungen schon gefordert sind, fällen wissentlich oder unwissentlich suboptimale Entscheidungen, um die Projektvorgaben einhalten zu können [4]. Das Ergebnis ist eine Code-Basis, die von Anfang an mit Altlasten („Code Smells“) belastet ist. 

Technische Schulden sind dennoch in jeder Software unvermeidlich und sollten auch im Fokus regelmäßiger Wartungsarbeiten stehen. Zu hohe Technische Schulden haben allerdings zur Folge, dass der Aufwand für Wartung oder für die Umsetzung neuer Anforderungen und Funktionalitäten mit der Zeit immer größer wird. Wird eine Software also nicht methodisch und strukturiert aufgebaut, qualitätsgesichert und weiterentwickelt, bauen sich mit jeder Änderung und jedem Release neue Technische Schulden auf. Diese nehmen eher früher als später ein Ausmaß an, das eine Weiterentwicklung der Software unwirtschaftlich werden lässt. Die Alternative ist dann nur noch, die Software von Grund auf neu zu entwickeln. Diese Erkenntnis könnte einen potenziellen Dealbreaker für den Investor darstellen. Ziel der Software Due Diligence ist es, das Niveau der Technischen Schulden einzuschätzen, die problematischen Bereiche im Code zu identifizieren und den Aufwand zur Behebung als kritisch oder unkritisch zu kategorisieren. 

Anmerkung für Verkäufer: Es in der Vorbereitung des Unternehmens/des Bereichs für einen Verkauf sinnvoll, seine Technischen Schulden durch eine Software Vendor Due Diligence detailliert zu kennen. Damit besteht die Möglichkeit, die größten Baustellen in der Software vor der Vermarktung zu beheben und damit den Verkaufsprozess zu entlasten und den Verkaufserlös zu optimieren.

Dringende Fragen bezüglich Technischer Schulden

Zum Schluss seien nachfolgend noch einige der dringenden Fragen, die zum Themenkomplex Technische Schulden gestellt werden sollten, aufgeführt: 

• Werden Anforderungen, Funktionalitäten und Fehler strukturiert aufgenommen, geplant und deren resultierende Code-Änderungen erfasst?
• Kann ein neuer Versionsstand technisch in kürzester Zeit erstellt, getestet und ausgerollt werden? 
• Kann jeder Versionsstand technisch bezüglich der geplanten und tatsächlich ausgerollten Funktionalitäten transparent nachverfolgt werden? 
• Sind die Technischen Schulden bekannt und mit vernünftigem Aufwand zu beheben? 
• Wie weit ist der Benutzer oder der Kunde in den Fehlererfassungsprozess integriert, um eine zeitnahe und umfassende Berichterstattung des Fehlers zu gewährleisten? 
• Wie weit sind Update- und Upgrade-Mechanismen in der Software automatisiert?

Ausblick

Teil 2 der Dreier-Reihe geht auf die Untersuchungsfelder einer Software Due Diligence und warum eine Mischung an Tools und Erfahrung dafür nötig ist.

Hatten Sie schon mal mit Software-Assets bei einer M&A Transkation zu tun? War diese erfolgreich? Welche Herausforderungen gab es in Ihrem Fall? Zögern Sie nicht, uns Ihre Erfahrungen dazu mitzuteilen.

Referenzen

1. R. Uhlaner, W. Rehm: Reflections on digital M&A, McKinsey & Company, 2017, podcast transcription digital M&A
2. SNP SE, Investor Relations, company presentation July 2020, Accelerated Data Transformation, S. 15
3. R. Bartels, L. Deiseroth, T. Fischer: IT-Due Diligence. In W. Berens, H.U. Brauner, T. Knauer, & J. Strauch, Due Diligence bei Unternehmensakquisitionen (S. 583), 8 Aufl., Stuttgart, Schäffer-Poeschel Verlag, 2019. 
4. C. Lilienthal: Langlebige Software-Architekturen – Technische Schulden analysieren, begrenzen und abbauen. 3. Auflage, dpunkt.verlag GmbH, Heidelberg, 2019