Technical Due Diligence bei Startups

In meiner Tätigkeit als CTO werde ich häufiger von Investoren gefragt, ob ich sie bei Technical Due-Diligence-Prüfungen unterstützen kann. Diese Prüfungen werden im Rahmen einer Akquise oder Ausbau einer Beteiligung durchgeführt.

Die Technische Due Diligence soll insbesondere Divergenzen aufzeigen, die die die weitere Skalierung beeinflussen könnten, und Einblicke in die Integrität des Systems und der Prozesse bieten. In den meisten Startups ist die Technologie und damit die Systeme und Teams dahinter der entscheidende werttreibende Faktor.

Während es für andere Prüfungen, beispielsweise die rechtliche und finanzielle Due-Diligence diverse Standard-Frameworks und Methoden gibt hat sich bei der technischen Due-Dilligence kein Vorgehensmodell etabliert. Demzufolge hat das zu prüfende Unternehmen meist kaum die Gelegenheit sich, neben dem eigentlichen operativen Geschäft, auf die Prüfung vorzubereiten.

Auf Basis meiner Erfahrung habe ich eine standartisierte Herangehensweise entwickelt, wie ich Tech Due-Diligences durchführe und welche Prüfbereiche ich mir dabei genauer anschaue.

Dieser Beitrag soll sowohl Investoren als auch Unternehmen helfen eine Prüfung besser vorzunehmen bzw. sich auf eine solche vorzubereiten.

Inhalte

Welche Bereiche sollten also im Rahmen einer technischen Due-Diligence-Prüfung abgedeckt werden?

In der Regel teile ich meine Analyse in folgende auf:

  • System- und Software-Architektur
  • Code-Qualität & Aufbau der Infrastruktur
  • Entwicklungs-, Test- und Deploymentprozess
  • Informationssicherheit & Datenschutz
  • Teamaufbau & Zusammenarbeit
  • Produkt Roadmap & Vision

System- und Software-Architektur

Eine High-Level-Übersicht der gesamten Systemlandschaft und im Detailgrad der einzelnen Komponenten gibt einen Überblick über die vorhandene Anwendungslandschaft. Damit lässt sich erkennen, inwieweit die Systeme und Anwendungen miteinander verknüpft sind und inwieweit diese zur Gesamtstrategie des Unternehmens passen. Dieses gibt insbesondere bei stark gewachsenen Unternehmen Rückschlüsse darauf, ob die Architektur und die Systeme auch im Kontext mitgewachsen sind. Folgende beispielhaften Fragestellungen ergeben sich hier:

  • Passt die Architektur zu dem Vorhaben des Unternehmens?
  • Sind die Komponenten dokumentiert?
  • Gibt es eine komplett dokumentierte API?
  • Nach welchem Muster werden Architekturentscheidungen getroffen?
  • Wie werden/ lassen sich externe Systeme in die Architektur integrieren?

Code-Qualität & Aufbau der Infrastruktur

Die Qualität zeichnet sich dadurch aus, dass die konkrete Anwendungsarchitektur und der darunterliegende Code leicht verständlich und nach gewissen Standards strukturiert ist. Hierbei kommt es nicht zwingend darauf an, dass ein bestimmter Standard verwendet wird, jedoch ist es wichtig, dass wenn man sich auf einen Standard festgelegt hat, dieser auch durchgezogen wird. Eine statische Code-Analyse (SCA) kann einen ersten Eindruck geben.

  • Welche Programmiersprachen & Frameworks werden eingesetzt?
  • Welcher Code- und Architekturstandard wird verwendet?
  • Welches Tooling wird genutzt?
  • Wie erfolgt das Hosting?
  • Welche Datenbank kommt zum Einsatz?
  • Wie ist das Monitoring aufgesetzt?

Entwicklungs-, Test- und Lieferprozesse

Ein besonderes Augenmerk liegt auf dem Grad der Automatisierung des gesamten Entwicklungs-, Test- und Deploymentprozesses. Heutzutage ist eine komplette Automatisierung für den Entwicklungsprozesses schon allein aus Effizienzgründen unabdingbar. Der aufgesetzte Prozess hier zeigt auch, wie fortschrittlich und integriert die Software-Entwicklung im Unternehmen erfolgt.

  • Wie erfolgt die gemeinschaftliche Entwicklung?
  • Wie eroflt die Source-Code Verwaltung?
  • Wie werden Änderungen zusammengeführt?
  • Lassen sich Änderungen auf Basis von Ticket/ User Stories zurückführen?
  • Wie erfolgt ein Deployment?
  • Wie wird mit Bugs und Support umgegangen?

Informationssicherheit & Datenschutz

Die Sicherheit von Informationssystemen ist ein großes Thema für sich. Innerhalb einer Due Diligence sollten unterschiedliche Punkte abgefragt werden, um ein Bild davon zu erhalten, wie mit diesem Thema im Unternehmen umgegangen wird:

  • Wird nach gängigen Sicherheitscode-Standards gearbeitet?
  • Wie sind Authentifizierungsmechanismen implementiert?
  • Werden regelmäßig interne und externe Penetrationstest durchgeführt?
  • Findet eine regelmäßige externe Datenschutzprüfung statt?
  • Wie wird mit Sicherheitsvorfällen umgegangen?

Teamaufbau & Zusammenarbeit

Bei den meisten Investitionen soll das vorhandene Team weiter bestehen und sogar erweitert werden. Insbesondere im Bereich der Softwareentwicklung ist es schwer gute Leute zu finden und diese auch mit den Systemen vertraut zu machen. Bei der Zusammensetzung der Teams ergeben sich folgende Fragen:

  • Wie sind die Teams strukturiert?
  • Wer leitet die Teams an?
  • Wer trifft Entscheidungen innerhalb der Teams?
  • Inwieweit erfolgt die Kommunikation zwischen Business/ Product/ Tech
  • Wie erfolgt das Recruiting? Wer entscheidet über Neueinstellungen?
  • Wie hoch ist die Abwanderquote?
  • Wie ist die Zusammensetzung zwischen Senior- und Junior-Entwicklern?

Produkt Roadmap & Vision

Neben den technischen Aspekten erfolgt auch ein Augenmerkt auf das Produkt-Team, welches sich meist durch Business- oder Product-Owner widerspiegelt. Folgende Fragen sind hier relevant:

  • Wie wird das Produkt/ die Produkte entwickelt? Welche KPIs liegen dieser zu Grunde?
  • Welche Fähigkeiten sind in der Product Unit vorhanden?
  • Ist eine Roadmap vorhanden?
  • Wie läuft die Roadmap-Planung? Inwieweit sind die technischen Teams hier involviert?
  • Wie viel Einfluss haben technische Teams auf die Roadmap?

Ablauf

Eine Tech DD unterläuft folgenden Phasen:

  • Sich mit dem Geschäftsmodell vertraut machen
  • Tech DD Informationen sammeln
  • Fragen & Antworten (Q&A)
  • Finaler Report & Beurteilung

Sich mit dem Geschäftsmodell vertraut machen

Grundkenntnisse über das Unternehmen um dem Geschäftsmodell sind essenziell um die Antworten der Due Diligence einwerten zu können. So sollten beispielsweise Architekturentscheidungen maßgeblich vom Sinn und Zweck des Unternehmens getroffen werden. Eine klassische Unternehmenspräsentation oder ein Gespräch mit dem CEO helfen bei der Einwertung.

Informationen sammeln

Über einen standardisierten Fragekatalog, welcher die oberen Bereiche abdeckt hat das zu prüfende Unternehmen die Gelegenheit alle relevanten Informationen intern zu sammeln und diese gesammelt zur Verfügung zu stellen

Fragen & Antworten (Q&A)

Spezifische Fragen bzw. Fragen, welche sich aus dem Fragekatalog ergeben werden in einer gesonderten Q&A-Liste beantwortet. Diese Q&A Session ist in der Regel zeitlich begrenzt.

Finaler Report & Beurteilung

Der finale Report wird den Investor zur Verfügung gestellt. In diesem Report findet die Einwertung zu den Fragen aus den oberen Bereichen und weiteren Fakten statt. Diese erfolgt auf Basis folgender Klassifizierung:

  • Red Flag Item
  • Potential Risk Item
  • Post Closing Item
  • Information only Item

Neben einer Einzelbewertung erfolgt auch noch eine gesamthafte Bewertung und eine Management-Summary.

Falls Du weitere Infos zu einer technischen Due Diligence brauchst oder als Investor eine durchführen möchtest findest du unter https://alex-bierhaus.de/technical-due-dilligence/ meine Kontaktdaten

Entrepreneur — technologist — passionate leader

Entrepreneur — technologist — passionate leader