Inhaltsverzeichnis
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:
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.
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.
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.
Zum Schluss seien nachfolgend noch einige der dringenden Fragen, die zum Themenkomplex Technische Schulden gestellt werden sollten, aufgeführt:
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.