Was ist Technical Due Diligence (TDD)?

Technical Due Diligence (TDD) ist eine eingehende Analyse des technischen Zustands eines Unternehmens. Dabei werden unter anderem Produkte, technische Infrastruktur und Architektur, Produkt-Roadmap, Services, Praktiken und IT-Mitarbeitende untersucht. Der TDD-Prozess findet in der Regel vor wichtigen Unternehmensereignissen wie Fusionen und Übernahmen (M&A) oder Börsengängen (IPO) statt. TDD wird üblicherweise von Investoren initiiert, ein Unternehmen kann TDD aber auch selbst durchführen, bevor es nach Finanzmitteln oder Investitionen sucht. Die TDD kann vom Investor oder dem internen Team des Unternehmens oder von einer externen Due-Diligence-Agentur durchgeführt werden.

Warum ist Technical Due Diligence wichtig?

Investoren und Käufer nutzen TDD, um vor dem Abschluss eines Geschäfts Antworten auf offene Fragen zu erhalten. Dazu können folgende Fragen gehören:

• Welchen Mehrwert bietet Ihr Unternehmen?

• Wie hoch ist der tatsächliche Wert des Unternehmens?

• Ist das Unternehmen ausreichend aufgestellt, um die gemachten Versprechen einzulösen?

Investoren und Käufer verlassen sich auf TDD, um zu entscheiden, ob sich eine Investition in Ihr Unternehmen lohnt. Sie können Ihr Unternehmen darauf vorbereiten, indem Sie vorab eine vorläufige TDD durchführen, einschließlich interner Bewertung, Audits, Legal Due Diligence (LDD) und Mitarbeiterschulungen. So können Sie:

• Stärken, Schwächen und mögliche Verbesserungsbereiche identifizieren.

• Rechtliche Probleme vermeiden, indem Sie Unternehmensunterlagen zusammentragen und ordnen.

• Mitarbeitende auf Gespräche mit Investoren vorbereiten.

• Engpässe identifizieren, die sich auf das Geschäft auswirken könnten.

Welche Phasen umfasst Technical Due Diligence?

Bevor der TDD-Prozess offiziell beginnt, sollten Unternehmen darauf vorbereitet sein, während des gesamten Prozesses offen und vollkommen transparent zu sein. Die Planung der TDD beginnt in der Regel, sobald Investoren und/oder Geschäftspartner eine vertrauensvolle Beziehung aufgebaut und eine Absichtserklärung unterzeichnet haben.

Sehen wir uns die sechs Phasen der TDD an.

1. Code-Review

In dieser ersten Phase führt der Produktentwickler oder ein Drittanbieter, der die TDD durchführt, ein Code-Review durch. Dabei wird der Code auf Fehler, Ungenauigkeiten und den allgemeinen Programmierstil geprüft. Im Wesentlichen handelt es sich um eine technische Überprüfung des Produkts, mit der die Bereitstellung von Produktfunktionen und der Fortschritt verfolgt werden.

2. Kick-off oder Planung

In dieser frühen Phase der TDD geht es stärker um geschäftliche Aspekte und das Branding des Produkts. Die beteiligten Parteien tauschen Anforderungen und detaillierte Prozessschritte aus und legen einen Zeitplan fest. Ziel dieses Kick-off-Meetings ist es, ein klares Bild von der Produktvision, dem Mehrwert für Kunden und dem Marktpotenzial für Wachstum zu vermitteln. In dieser Phase konzentrieren sich Investoren stärker auf die Geschäftsstrategie, die Einzigartigkeit der Technologie und die Marktkenntnis.

3. Dokumentation und Recherche

Für den TDD-Prozess ist eine gut vorbereitete und konsistente technische Dokumentation erforderlich. Sie sollte alle Details zur Produktarchitektur, zu Prozessen, Infrastruktur, Backup und Wiederherstellung, Integrationen, Servern, Frameworks, Monitoring und allen weiteren wichtigen und daher dokumentationspflichtigen Technologielösungen enthalten. Analysten führen die Due Diligence durch, indem sie die Produktdokumentation prüfen. Je mehr Informationen zum Produkt dokumentiert sind, desto besser fällt die Due-Diligence-Analyse aus.

4. Meeting zur technischen Due Diligence

Investoren vereinbaren Live-Meetings mit dem Entwicklungsteam, um verschiedene Softwarekomponenten des Produkts oder der Services in Echtzeit zu analysieren. Diese Meetings sind unbedingt erforderlich, um die internen Projektdetails kennenzulernen und die Einschätzung des Teams zu den Stärken und dem Potenzial des Projekts zu erfahren. Dabei befragen Investoren technische Führungskräfte und andere wichtige Mitarbeitende zu technischen und nicht technischen Themen.

5. Nachbesprechung

Nach dem ersten Meeting zur technischen Due Diligence bitten Investoren möglicherweise um ein weiteres Meeting, um zusätzliche Fragen zu klären. Nach Abschluss aller oben genannten Schritte übermitteln die Investoren ihr Feedback zum gesamten Due-Diligence-Prozess.

6. Bericht

In der letzten Phase des Technical-Due-Diligence-Prozesses wird ein ausführlicher Bericht erstellt, der alle Ergebnisse der Dokumentenprüfung und des Code-Reviews sowie der Meetings mit Investoren, Product Ownern und technischen Führungskräften enthält. Der Abschlussbericht beschreibt die Geschäftsstrategie des Start-ups, Vor- und Nachteile, aufgedeckte Mängel, mögliche Risiken und geplante Updates. Abschließend wird darin beurteilt, ob das Produkt oder der Service als technisch zuverlässig eingestuft wurde.

Wichtige Aspekte der Technical Due Diligence

Bei einer technischen und rechtlichen Due Diligence können je nach Größe des Unternehmens und der Investition nur ein Dutzend oder auch Hunderte von Prüfpunkten angefordert werden. Daher konzentrieren wir uns auf vier Hauptkategorien.

Erläutern Sie die Technologie

Bei der Technical Due Diligence ist Ihre Technologie natürlich einer der grundlegendsten und wichtigsten Aspekte. Sie sollten daher darauf vorbereitet sein, Ihre Technologie vorzustellen, zu erläutern und zu beschreiben sowie eine umfassende technische Dokumentation bereitzustellen. Diese Dokumentation sollte Folgendes enthalten:

• Architekturdiagramme

• Leistungskennzahlen

• Bewertung der Skalierbarkeit des Produkts

Sie sollten außerdem Ihre gesamte Infrastruktur und die Gründe für die Wahl der Programmiersprache, Cloud-Plattformen, Datenbanken und anderer Softwarekomponenten oder Tools Ihres Produkts erläutern können. Darüber hinaus sollte Ihre Dokumentation Kennzahlen zur Codequalität wie die Codeabdeckung enthalten. Dieser gesamte Prozess gibt Investoren und Käufern die Sicherheit, dass sie künftig keine Probleme mit der Integrität oder Sicherheit des Produkts haben werden.

Außerdem müssen Sie anhand fundierter Fakten und Statistiken erläutern können, wie Ihre Technologie im Vergleich zur Konkurrenz abschneidet. Das ist entscheidend, denn es zeigt, dass Sie Ihre Marktforschung gründlich durchgeführt haben und genau wissen, wo Sie stehen.

Um sich darauf vorzubereiten, sollten Sie relevante Dokumente archivieren, darunter Unterlagen zum Produktdesign, zur API, zu POC-Ergebnissen, Architektur und weiteren Betriebskennzahlen.

Software von Drittanbietern scannen und prüfen

Ein weiterer wichtiger Schritt der TDD besteht darin, Ihre Codebasis umfassend zu scannen und eine Liste aller Abhängigkeiten des Produkts von Drittanbieter- und Open-Source-Software zu erstellen. Diese Liste sollte auch weitere Metadaten enthalten, zum Beispiel:

• Softwareinformationen wie Paketname, Anbieter, Version und Autor

• Softwarelizenzen

• Abhängigkeitspfade

• Alle weiteren relevanten Informationen

Da Open-Source-Softwarekomponenten F&E-Teams dabei helfen, schneller und häufiger einen höheren Mehrwert zu schaffen und bereitzustellen, prüfen Investoren oft genau, wie Sie Open-Source-Komponenten verwalten. Auch Software von Drittanbietern sollte gut dokumentiert sein.

Heute verwenden die meisten Unternehmen Tools zur Software-Composition-Analyse (SCA) wie Snyk Open Source, um eine Software-Stückliste (SBOM) zu erstellen. Dieser wichtige Bericht hilft Ihnen dabei, alle Software-Assets aufzulisten und diesen Punkt auf Ihrer TDD-Checkliste abzuhaken.

Sie können auch mit einem Unternehmen wie Snyk zusammenarbeiten, das Open-Source-Audit-Services anbietet. Snyk bietet Blind Audits an, bei denen der Quellcode des Zielunternehmens weder offengelegt noch irgendwo hochgeladen werden muss. So werden die Anforderungen an die Datensicherheit erfüllt.

Snyk-Services können Ihnen außerdem helfen, Probleme mit der Lizenzkonformität auf Snippet-Ebene sowohl in verwaltetem als auch in nicht verwaltetem Code zu erkennen. Open-Source-Lizenzen bringen in der Regel bestimmte Pflichten mit sich, die bei der Weitergabe von Code erfüllt werden müssen. Ein Beispiel ist die GNU General Public License (GNU GPL), die vorschreibt, dass abgeleitete Werke oder Kombinationen ebenfalls unter derselben Lizenz bereitgestellt werden müssen. Dadurch entsteht das Risiko einer IP-Kontamination im Quellcode. Andere Lizenzen verlangen bestimmte Hinweise in der Dokumentation oder schränken ein, wie das Produkt beworben werden darf.

Werden die Pflichten aus Open-Source-Lizenzen nicht erfüllt, kann das zu Rechtsstreitigkeiten, kostspieliger Neuentwicklung, Produktrückrufen und negativer Publicity führen. Daher ist es wichtig, die Lizenzbedingungen einzuhalten und Probleme mit der Lizenzkonformität während der Technical Due Diligence zu erkennen.

Organisationsstruktur

Jede einzelne Person im Unternehmen wirkt sich auf den Produkterfolg aus, der von ihrer Leistung in der jeweiligen Rolle abhängt.

Investoren fordern in der Regel ein Organigramm mit Angaben zu Abteilungen, Mitarbeitenden, Auftragnehmern und ausgelagerten Ressourcen. Darin sollten die Rollen und Verantwortlichkeiten wichtiger Personen wie CTO und CIO sowie weiterer Mitarbeitender aus Support, Entwicklung, Testing, Produktmanagement und Personalwesen hervorgehoben werden.

Organigramme sollten stets aktuell sein und alle Auftragnehmer und Mitarbeitenden übersichtlich aufführen. Ergänzend sollten Lebensläufe, Verträge und zugehörige Kosten angegeben werden.

Organigramme helfen dabei, die Workflows der Software- und Produktentwicklung zu steuern und wichtige Leistungskennzahlen des Entwicklungsteams zu analysieren.

Produkt- und Technologie-Roadmap

Eine Technologie-Roadmap hilft potenziellen Investoren, die Details Ihres aktuellen Produktangebots und Ihre Zukunftspläne zu verstehen. Sie zeigt den langfristigen Plan des Unternehmens und wie die Technologie bestehende und zukünftige Produktinitiativen unterstützt. Daher ist die Bewertung der Produkt- und Technologie-Roadmap für Investoren wichtig, um das Potenzial des Unternehmens einzuschätzen.

Eine detaillierte Roadmap definiert:

• Den Technologie-Stack, einschließlich Programmiersprachen, Frameworks, Datenbanken, Servern und technischen Komponenten, die für die Entwicklung und Bereitstellung des Produkts erforderlich sind.

• Kennzahlen zur Skalierbarkeit und Verfügbarkeit des Anwendungssystems.

• Betriebssysteme, Disaster Recovery, Diagnose-Monitoring, Daten-Repositories, Lasttests und mehr.

Mithilfe einer Technologie-Roadmap werden die Produkte und Services des Zielunternehmens anhand der folgenden Kriterien geprüft:

• Fortschritt bei Produkten, die sich in der Entwicklung befinden, und solchen, die bereits auf dem Markt sind

• Mit den einzelnen Produkten erzielte Umsätze

• Unterscheidungsmerkmale der Unternehmensprodukte im Vergleich zu Konkurrenzprodukten auf dem Markt

• Mögliche Auswirkungen der Marktbedingungen auf das Marktwachstum und den Umsatz des Zielunternehmens

• Der aktuelle adressierbare Gesamtmarkt des Produkts und Pläne für seine Weiterentwicklung

• Ressourcen und Kosten im Zusammenhang mit Produkten in der Entwicklung

Bereiten Sie sich auf die TDD vor

Technical Due Diligence ist für jedes Unternehmen wichtig, das eine Investition, Übernahme oder Fusion anstrebt. Die TDD kann oft über den Erfolg oder das Scheitern des Geschäfts entscheiden. Selbst wenn Sie derzeit keine Investitionen oder Übernahmen planen, ist es ratsam, sich frühzeitig auf zukünftige Möglichkeiten vorzubereiten. Eine vollständige Dokumentation, die Ergebnisse Ihrer POCs und aktuelle Softwarelizenzen erleichtern eine Technical Due Diligence erheblich, falls eine TDD erforderlich wird.

Snyk-Tools wie Snyk Open Source und Snyk Code können während des gesamten TDD-Prozesses eingesetzt werden, um die Einhaltung von Sicherheits- und Compliance-Standards sicherzustellen.