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

Einleitung

Im folgenden zweiten Blog der Dreier-Reihe gehen wir auf auf den zweiten Punkt, die Untersuchungsfelder einer Software Due Diligence, ein.

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.

In Teil 1 geht es um die Gründe, warum Software-Targets besondere Bewertungsrisiken aufweisen. Der dritte, letzte Blog, wird den Ablauf einer Software Due Diligence und dessen Deliverables behandeln.

Die Untersuchungsfelder erfordern Tools und Erfahrung

Das besondere an Software als Asset ist, dass die relevanten Eigenschaften der Anwendung sehr regelmäßig erneuert und erweitert werden müssen, um sich der Weiterentwicklung der Benutzer oder Kunden anpassen zu können. Eine zusätzliche Verantwortung hat der Anbieter dafür, dass die Software für seine Kunden über eine nicht einfach durch andere Anbieter zu ersetzende Funktion erfüllt. Die Kundenbasis vertraut darauf, dass die Software noch lange weiterentwickelt und aktualisiert wird. Eine Software muss also so offen gestaltet sein, dass sie morgen um Antworten auf Fragen erweitert werden kann, die heute noch nicht gestellt werden. 

Das Hauptziel einer Software Due Diligence ist es deshalb, dass vom Verkäufer dargelegte Potenzial der Software mit der technischen Realität der Code-Architektur und insbesondere der Qualität des Entwicklungsprozesses zu korrelieren. Die technologische Basis der Software – als auch die erforderlichen Entwicklungs-, Qualitätssicherungs- und Abnahmeprozesse – sollte in der Lage sein, der Dynamik der Anforderungsveränderungen folgen zu können. Dies ist erforderlich, um die notwendigen Updates, Upgrades und neuen Funktionalitäten in einer marktgerechten Time-to-Market bereitzustellen. Die Software Due Diligence ist im Gegensatz zu anderen Due-Diligence-Gewerken hochgradig automatisiert. Anders lassen sich hunderttausende oder auch Millionen von Codezeilen nicht analysieren. Abb. 1 zeigt, wie sich die Aufgaben der Berater und die der eingesetzten Analysewerkzeuge in den einzelnen Untersuchungsfeldern ergänzen. 

Abb. 1: Einsatzgebiete der Tools und Berater in einer Software Due Diligence

Die relevanten Entwickler einer Softwarefunktionalität werden beispielsweise direkt im Code ausgelesen. Die Relevanz dieses Codeabschnittes und damit des verantwortlichen Entwicklers stellt aber erst der Berater mit Hilfe weiterer Analyseergebnisse und mit Hilfe von Interviews her. Dabei ist gewährleistet, dass die Kennzeichnung der Schlüsselentwickler anonymisiert und damit DSGVO-konform erfolgt (z. B. Entwickler 1). Technische Schulden, eine lückenhafte Dokumentation oder die Wissensverteilung im Entwicklerteam werden ebenfalls direkt im Code durch die Analyse-Software identifiziert. Die Fehlerintensität einzelner Funktionalitäten wird aus einem Bugtracker ausgelesen und mit kritischen Codestellen in Verbindung gesetzt. Die Qualitäts- und Entwicklungsprozesse haben einen initialen Input aus der Softwareanalyse, müssen aber durch Interviews und Erfahrungen der Berater ergänzt werden. Die Qualität der Code-Architektur zu beurteilen, ist eine Aufgabe für die Berater. Die Beurteilung basiert aber nicht nur auf der persönlichen Expertise, sondern berücksichtigt maßgeblich Daten aus der Analyse.

In Abb. 2 sind generisch die möglichen Untersuchungsfelder einer Software Due Diligence aufgelistet. In der Praxis beschränkt man sich aus Zeit- und Budgetgründen auf den Code (1), das Schlüsselpersonal (2) und den Entwicklungsprozess (3). Diese drei Themenkomplexe bestimmen im Wesentlichen, ob das Unternehmen sich technologisch erfolgreich weiterentwickeln kann und sind entsprechend risikobehaftet. Bei den Themen Werkzeuge (4) und Anwendung (5) sind die Risiken aus technologischer Sicht eher gering und es genügt ggf. eine sehr kurze Betrachtung oder sie sind Gegenstand der anderen Due-Diligence-Work-Streams. Die Beurteilung der funktionalen Eigenschaften der Software im Vergleich zu Markt und Wettbewerb sind nicht Gegenstand einer Software Due Diligence und sollten in der Commercial Due Diligence betrachtet werden.

Abb. 2: Untersuchungsfelder einer Software Due Diligence

Die vielfach von industriellen Investoren gestellte Frage „was kostet es denn, wenn wir das selbst entwickeln“ führt zur Frage nach dem Wert der Software (6). Eine Wertermittlung von Software ist komplex und die verschiedenen Methoden sind nicht unumstritten. Als Berechnungsansätze, die eine gewisse Verbreitung gefunden haben, seien die Function-Point-Analyse-Verfahren (FPA) und die Cocomo II Methode erwähnt. /1,2/ Beide ermitteln mittels aufwändiger Algorithmen Herstellkosten und Projektdauer der untersuchten Software. Das Ergebnis ist durch die Wahl der Parameter in weiten Grenzen beeinflussbar und damit nur begrenzt belastbar, um für den Investor als Vergleichsbasis in einer M&A-Transaktion zu dienen.

Anmerkung für Verkäufer: Der Einsatz dieser Verfahren macht Sinn in einer Vendor Due Diligence, um die Frage, ob eine Eigenentwicklung nicht günstiger ist, proaktiv mit einer Kosten- und Aufwandschätzung zu beantworten und die Preisvorstellung zu untermauern.

Für eine ganzheitliche Analyse muss beachtet werden, dass Software ein „fluides“ Produkt ist, das in seinem innovativen und wettbewerbsintensiven Marktumfeld ständig und oftmals in kurzen Zyklen angepasst werden muss. Da eine Software-Version zum Zeitpunkt der Analyse im Prinzip stets in ihrem Life-Cycle mehr oder weniger fortgeschritten ist, sollten auch die aktuellen Projekte für Updates und neue Funktionalitäten vom Verkäufer offengelegt werden. Dabei gilt es festzustellen, ob die Arbeiten im Plan und im Budget liegen und für wann der Launch terminiert ist. Zusammen mit der im ersten Blog vorgeschlagenen Vergleichsanalyse der in der Due Diligence untersuchten Software-Version mit der zum Closing übernommenen Version, kann festgestellt werden, wie gut die Software-Engineering Prozesse wirklich funktionieren. Ebenso sollten Fragen zu den aktuellen Fehlern sowie den Maßnahmen und Prozessen zur Behebung gestellt werden. Tauchen zu diesem Themenkomplex zu viele Fragen auf, ist die ganze Transaktion gefährdet. Nachfolgend sind einige der Fragen aufgelistet, die durch Analyse und Interviews positiv beantwortet werden sollten:

• Ist die Wartbarkeit für einen weitgehend störungsfreien Betrieb zu normalen Kosten gewährleistet?
• Unterstützt die technische Basis die einfache Erweiterbarkeit der Software um neue Funktionalitäten?
• Ist die Interoperabilität und Integrationsfähigkeit in die eigene Software-Produktpalette möglich?
• Ist die Softwarearchitektur skalierbar und geeignet, um den aktuellen Trends zu folgen (z. B. Cloud)
• Sind die Entwicklungsprozesse in der Organisation etabliert und State-of-the-Art?
• Ist die Anzahl der Fehler normal und konnten diese zeitnah und mit normalem Aufwand behoben werden?
• Wer sind die relevanten Entwickler und sind sie Teil der Transaktion?

Hatten Sie schon mal mit Software-Assets bei einer M&A Transakation zu tun? Was waren die Untersuchungsfelder in Ihrem Fall? Welche sollten aus Ihrer Sicht zusätzlich berücksichtigt werden?

Referenzen

1. B. Poensgen: Function-Point-Analyse. Ein Praxishandbuch. 2. Auflage. dpunkt.verlag GmbH, Heidelberg 2012,
2. B. Boehm, et al.: Software cost estimation with COCOMO II . One Lake Street Upper Saddle River, NJ:Prentice-Hall, 2009