Table Of Contents
Einleitung
Technologische Due Diligence ist einer der folgenreichsten Schritte bei einer Private-Equity- oder Venture-Capital-Transaktion. Eine gründliche Tech-DD kann Risiken aufdecken, die die Deal-Konditionen ändern, Chancen identifizieren, die das Wertschöpfungspotenzial erhöhen, oder bestätigen, dass die Technologie genau dem entspricht, was man von außen erwarten würde.
Ich habe Buy-Side-Tech-Due-Diligence für PE-Firmen durchgeführt und war auch auf der anderen Seite – als Leiter von Technologieorganisationen durch Akquisitionsprozesse. Diese doppelte Perspektive prägt meinen Ansatz bei der DD: was wirklich wichtig ist, was Rauschen ist und wie man Erkenntnisse in einen umsetzbaren Plan verwandelt.
Was Tech Due Diligence tatsächlich umfasst
Eine umfassende Tech-DD bewertet fünf Dimensionen:
1. Architektur & Technology Stack
Hier beginnen die meisten Tech-DDs, aber hier verbergen sich selten die größten Risiken. Die Fragen, die zählen:
- Skalierbarkeit: Kann die aktuelle Architektur das Wachstum bewältigen, das die Investitionsthese impliziert? Wo liegen die Skalierungsgrenzen, und was würde es kosten, sie zu überwinden?
- Technical Debt: Wie viel angehäufte Schulden gibt es, und konzentrieren sie sich auf kritische Systeme? Nicht alle Tech Debt ist schlecht – manche ist strategisch. Entscheidend ist, ob sie gemanagt oder ignoriert wird.
- Sicherheitslage: Gibt es grundlegende Sicherheitsprobleme (ungepatchte Systeme, hardcodierte Credentials, keine Verschlüsselung at rest), die ein regulatorisches oder geschäftliches Risiko darstellen?
- Abhängigkeitsrisiko: Ist das System von veralteten Technologien, einzelnen Anbietern oder Open-Source-Projekten mit ungewisser Zukunft abhängig?
- Datenarchitektur: Wie werden Daten gespeichert, verarbeitet und geschützt? Gibt es ein klares Datenmodell, oder ist es organisch gewachsen?
2. Teambewertung
Das Team ist oft das wertvollste – und fragilste – Asset in einem Technologieunternehmen. Eine gründliche Teambewertung evaluiert:
- Kompetenzen und Lücken: Hat das Team die Fähigkeiten, die für die Post-Akquisitions-Roadmap benötigt werden? Wo gibt es Lücken?
- Key-Person-Risiko: Sind kritische Systeme oder Wissen auf wenige Personen konzentriert? Was passiert, wenn sie gehen?
- Fluktuationsrisiko: Wie hoch ist die Abwanderungsrate? Sind die Vergütungsniveaus wettbewerbsfähig? Gibt es bekannte Abwanderungsrisiken?
- Führungskapazität: Kann die aktuelle Engineering-Führung den Wertschöpfungsplan umsetzen, oder müssen Änderungen vorgenommen werden?
- Kultur und Moral: Wie steht das Team zur Akquisition? Gibt es kulturelle Probleme, die die Abwanderung beschleunigen könnten?
3. Lieferfähigkeit
Dies ist die Dimension, die am meisten für die Wertschöpfung zählt. Kann dieses Team tatsächlich Software liefern?
- Liefergeschwindigkeit: Wie schnell gelangt Code von der Idee in die Produktion? Wie lang ist die Zykluszeit für ein typisches Feature?
- Qualität: Wie hoch ist die Fehlerquote? Wie oft verursachen Deployments Incidents? Gibt es eine Teststrategie?
- Prozesse: Gibt es definierte Prozesse für Planung, Entwicklung, Review, Testing und Deployment? Oder ist es ad hoc?
- DevOps-Reifegrad: CI/CD-Pipelines, automatisiertes Testing, Infrastructure as Code, Monitoring, Alerting – die Grundlagen moderner Softwarelieferung.
4. Kostenstruktur
Das Verständnis der tatsächlichen Kosten des Technologiebetriebs ist entscheidend für die Finanzmodellierung:
- Infrastrukturkosten: Cloud-Ausgaben, Hosting, Drittanbieterdienste. Sind die Kosten optimiert, oder gibt es erhebliche Verschwendung?
- Lizenzkosten: Software-Lizenzen, SaaS-Abonnements, Support-Verträge. Stehen Verlängerungen mit Preisrisiko an?
- Personalkosten: Voll belastete Kosten pro Ingenieur, einschließlich Benefits, Tools und Overhead. Wie verhält sich das zu Marktpreisen?
- Behebungskosten: Was würde es kosten, die in der DD identifizierten Risiken zu beheben? Das ist die Zahl, die Boards am meisten interessiert.
5. Strategische Ausrichtung
Unterstützt die Technologie die Investitionsthese?
- Product-Market Fit: Löst die Technologie die richtigen Probleme? Ist sie auf die Marktentwicklung ausgerichtet?
- Wettbewerbsdifferenzierung: Welche technologischen Vorteile bestehen? Sind sie verteidigbar?
- Wachstumstreiber: Welche Technologieinvestitionen würden das im Wertschöpfungsplan angestrebte Wachstum freischalten?
Wie ich eine Tech-DD strukturiere
Ein typisches Engagement folgt diesem Muster:
Woche 1: Discovery
- Management-Interviews: CTO, VP Engineering, Architekten, Teamleiter. Das Narrativ verstehen, dann verifizieren.
- Dokumentationsprüfung: Architekturdiagramme, technische Roadmaps, Incident Reports, Postmortems, Einstellungspläne.
- Codebase-Zugang: Repository-Struktur, Commit-Muster, Testabdeckung, CI/CD-Konfiguration prüfen.
- Infrastruktur-Walkthrough: Cloud-Architektur, Deployment-Topologie, Monitoring-Setup.
Woche 2: Deep Dive
- Code-Qualitätsanalyse: Automatisiertes Scanning plus manuelle Prüfung kritischer Komponenten.
- Architekturbewertung: Skalierungsgrenzen, Single Points of Failure und Sicherheitsbedenken identifizieren.
- Teambewertung: Kompetenzmapping, Key-Person-Analyse, Bewertung des Fluktuationsrisikos.
- Finanzanalyse: Aufschlüsselung der Kostenstruktur, Kostenoptimierungsmöglichkeiten, Schätzung der Behebungskosten.
Woche 3: Synthese & Reporting
- Risikoregister: Kategorisierte Ergebnisse mit Schweregrad, Wahrscheinlichkeit und Kosten/Aufwand zur Behebung.
- Wertschöpfungs-Roadmap: Priorisierte Technologieinitiativen, die die Investitionsthese unterstützen.
- Executive Summary: Board-reife Ergebnisse mit klaren Empfehlungen.
Der genaue Zeitrahmen variiert mit Umfang und Komplexität. Kleinere Zielunternehmen können in 2 Wochen bewertet werden; komplexe Multi-Entity-Gruppen können 4–6 Wochen benötigen.
Häufige Ergebnisse
Nach der Durchführung mehrerer DD-Bewertungen treten bestimmte Muster wiederholt auf:
- Undokumentierte Architekturentscheidungen, die es schwer machen zu verstehen, warum Systeme auf eine bestimmte Weise gebaut wurden
- Key-Person-Abhängigkeiten, bei denen kritisches Wissen in den Köpfen von ein oder zwei Ingenieuren lebt
- Aufgeschobene Sicherheitsarbeit, die unter neuer Eigentümerschaft Compliance-Risiken schafft
- Übertechnisierte Infrastruktur, die deutlich mehr kostet als nötig
- Unrealistische technische Roadmaps, die den Aufwand zur Behebung bestehender Schulden nicht berücksichtigen
Nichts davon ist für sich genommen ein Deal-Breaker. Die Frage ist immer: Was kostet die Behebung, und hält die Investitionsthese trotzdem stand?
Von der DD zur Umsetzung
Die beste Tech-DD ist wertlos, wenn die Ergebnisse in der Schublade liegen. Ich sehe zunehmend, dass PE-Firmen die DD direkt mit den ersten 100 Tagen der Post-Akquisitions-Umsetzung verbinden.
Wenn ich eine DD durchführe, die zu einem operativen Engagement führt, ist der Übergang nahtlos: Das Risikoregister wird zum Remediation Backlog, die Wertschöpfungs-Roadmap wird zur Technologiestrategie, und die Teambewertung fließt in die ersten Einstellungs- und Organisationsentscheidungen ein.
Für mehr darüber, wie ich bei der Umsetzungsphase helfe, siehe Post-Acquisition Execution.
Fazit
Tech Due Diligence ist keine Pflichtübung zum Abhaken. Richtig gemacht, ist sie ein strategisches Werkzeug, das direkt die Deal-Konditionen, die Wertschöpfungsplanung und die ersten 100 Tage der Eigentümerschaft beeinflusst.
Wenn Sie eine Technologie-Akquisition bewerten und eine unabhängige, erfahrene Bewertung brauchen – lassen Sie uns sprechen.
Weitere Details finden Sie auf meiner PE/VC Tech Due Diligence Service-Seite.
