Entdecken Sie maßgeschneiderte Software-Due-Diligence-Strategien für kleine Start-ups und etablierte Unternehmen. Für Startups bewerten wir Skalierbarkeit, F&E-Roadmaps und technische Risiken, um die Vereinbarkeit mit den Erwartungen der Investoren sicherzustellen.

Große Unternehmen profitieren von eingehenden Bewertungen der technischen Schulden, der Nachhaltigkeit der Architektur und der Entwicklungsprozesse. Mithilfe ausgefeilter Tools wie DETANGLE® werten unsere Experten die Analyse aus und liefern umsetzbare Erkenntnisse.

Mit unserem umfassenden Ansatz können Sie die Herausforderungen von Fusionen und Übernahmen meistern, selbst in sensiblen Szenarien, in denen der Zugang zum Code eingeschränkt ist. Unterstützen Sie Ihre Investitionsentscheidungen mit klaren, datengestützten Einblicken in die Skalierbarkeit, Risiken und Chancen von Software.

Kleine/Start-Up Software Unternehmen

Diese Unternehmen/Start-Ups werden häufig noch von den Gründern geführt, die mit einem kleinen Team eine innovative Software entwickelt haben und teilweise schnell gewachsen sind. Ein Investor wird oft aktiv gesucht und soll das weitere Wachstum ermöglichen.

Die Vorgehensweise bei der Due Diligence muss sensibel sein, da das Team oft "idealistisch" und mit wenig Vorgaben geführt wird. Für administrative Tätigkeiten werden oft zu wenig Kapazitäten bereitgestellt. Die überwiegend technischen Mitarbeiter identifizieren sich stark mit dem Unternehmen und sind stolz auf ihre Arbeitsergebnisse. Es bestehen Vorbehalte, wie sich dies mit einem Investor an Bord ändern würde. Sympathie und das richtige technische Verständnis können eine wichtige Rolle bei der Entscheidung des Verkäufers für einen Investor spielen. Wir haben mehrfach die Erfahrung gemacht, dass die Akzeptanz auf technischer Ebene der Schlüssel für eine erfolgreiche abgeschlossene M&A-Transaktion war.

Eine Herausforderung für die automatisierte Analyse der Codebasis ist häufig die uneinheitliche Nutzung von Entwicklungswerkzeugen wie Code Repositories und Issue Trackern. Erfahrene Berater müssen die Daten aus diesen Informationsquellen aufbereiten, bevor Analysewerkzeuge eingesetzt werden können. Wenn die meisten Entwickler von zu Hause aus und über Ländergrenzen hinweg arbeiten, müssen auch die Prozesse zur Zusammenführung und Dokumentation der Arbeitsergebnisse und die Dokumentation selbst überprüft werden.

Der Fokus der Software Due Diligence liegt bei kleinen bzw jungen Unternehmen auf der Bewertung der Skalierbarkeit von Technologie, Entwicklungsprozessen und Mitarbeitern (inkl. mögliche Risiken durch Abhängigkeiten von einzelnen Entwicklern). Die F&E-Roadmap sollte den aktuellen Gegebenheiten im Entwicklungsbereich entsprechen. Der Bericht konzentriert sich nicht nur auf die Substanz, sondern auch auf das technische Potenzial der bestehenden Lösung und Entwicklung. Diese werden je nach Fragestellung des Investors zusätzlich durch szenariobasierte Interviews evaluiert und mit den qualitativen, tool-basierten Ergebnissen abgeglichen. Wir haben regelmäßig die Erfahrung gemacht, dass unsere Befunde und ggfs. Verbesserungsvorschläge vom Verkäufer positiv aufgenommen wurden.

Etablierte/Große Software Unternehmen

Große bzw. etablierte Software-Targets verfügen oft über stabile Prozesse, in denen einheitlich State-of-the-Art Entwicklungswerkzeuge genutzt werden. Die Software-Suite ist meist umfangreich und über viele Jahre gewartet und erweitert worden. Der Investor braucht zur Beurteilung dieser technologischen Komplexität und ob die Software seine strategischen und finanziellen Ziele unterstützen wird, einen Berater, der diese Komplexität entschlüsselt und damit die möglichen Risiken und Chancen verständlich und nachvollziehbar aufzeigen kann. Dazu muss der Berater tief in den Code, die Architektur und in die Entwicklungsprozesse eintauchen können.

Diese großen M&A Targets werden überwiegend in einem eng getakteten Bieterverfahren vermarktet. Das erzeugt Zeitdruck und erfordert einen klaren Fokus in der Software Due Diligence auf folgende Risiken: 

• Ausmaß und Trend der technischen Schulden als Risiko für erhöhte Wartungskosten oder einen verkürzten Lebenszyklus, 
• Zukunftsfähigkeit der Softwarearchitektur als Risiko, technischen- oder Markttrends nicht mehr mit normalem Aufwand folgen zu können
• Qualität der Entwicklungsprozesse als Risiko für die Innovationsfähigkeit und das Time-to-Market 
• Wissensverteilung in den Projekten als Termin-, Qualitäts- und Fluktuationsrisiko
• Abhängigkeit von einzelnen Mitarbeitern als Risiko, dass der Weggang weniger Mitarbeiter zu einem grundlegenden Know-how-Verlust führen kann. 
• Qualität und Schnittstellen zu externen Entwicklungsdienstleistern als Risiko, dass das eigentliche Know-how nicht im Target liegt.
• IP Risiken durch den Einsatz von Opensource Software

Der Aufwand für die Software Due Diligence nimmt theoretisch mit der Größe des Unternehmens/der Applikation überproportional zu, da größere Anwendungen in der Regel eine komplexere Architektur, mehr Codezeilen und umfangreiche Abhängigkeiten haben. Zur Begrenzung des Aufwandes bei großen Applikationen fokussieren sich die Due Diligence Berater auf die Kernapplikation(en) und die technologischen Hauptrisiken. Mögliche Restrisiken versucht der Investor über eine geeignete Vertragsgestaltung abzuschwächen. 

Für eine effiziente Analyse der Software in einer Due Diligence, hat sich der Einsatz einer Analysesoftware wie z.B. DETANGLE® und der Analysefokus auf die Kernapplikationen bewährt. Ein einziger Codescan liefert bereits Daten und Informationen, die die Mehrzahl der o.g. Fragen beantworten kann. Für die Detailinterpretation führen erfahrene Berater zusätzlich Interviews mit den wichtigsten Stakeholdern in der Softwareentwicklung durch. Ergänzend werden eventuelle Helpdeskaktivitäten und -prozesse und deren Automatisierungsgrad mitbetrachtet und ausgewertet.

Sonderfall

Der Einsatz einer Analyse Software wird vom Verkäufer nicht zugelassen:

Wenn der Käufer ein direkter Wettbewerber und/oder die Technologie extrem innovativ ist, kommt es vor, dass der Verkäufer einen direkten Zugang zum Code verweigert. Dazu verweisen wir auf Teil 2 unserer Blogs “Grundlagen des IP-Schutzes für den Verkäufer bei der Analyse der Software-Assets”. 

Links

[0] Photo by Monstera Production

[1] Übersicht zur Blogreihe