Technische Due Diligence: Worauf Käufer Achten

Technische Due Diligence ist kein Wettbewerb um Codequalität, und Teams, die sich darauf vorbereiten, stecken ihre Zeit meist in die falsche Sache. Niemand, der ein Unternehmen kauft, benotet Ihre Abstraktionen. Die Gegenseite versucht herauszufinden, was der Besitz dieses Systems kosten wird und wie schlimm es schiefgehen kann, nachdem das Geld den Eigentümer gewechselt hat.

Diese Umdeutung ist wichtig, weil sie verändert, was Sie zuerst in Ordnung bringen sollten. Hässlicher Code, der funktioniert, den das Team versteht und den man gefahrlos ändern kann, ist ein kleiner Befund. Eleganter Code, den nur eine einzige Person durchschaut, ist ein schwerwiegender Befund, und es ist der zweite Fall, der den Preis bewegt.

Die Frage hinter jeder Frage: Wenn der Gründungsentwickler in der Woche nach dem Vollzug kündigt, läuft dieses System dann weiter und lässt es sich weiter verändern? Fast jeder Befund, der ein Angebot senkt, ist eine konkrete Antwort darauf. Wissen, das sich auf einen Kopf konzentriert, ein undokumentiertes Deployment, Lizenzen, die nie jemand geprüft hat, Zugangsdaten, die nur eine Person kennt.

Was technische Due Diligence wirklich bewertet

Vier Risiken, ungefähr in der Reihenfolge, in der sie auf die Bewertung durchschlagen.

Schlüsselpersonenrisiko. Ob das System von einzelnen Menschen abhängt statt von dokumentierten Abläufen. Das ist regelmäßig der schädlichste Befund, weil er sich im Nachhinein am schwersten beheben lässt und weil er unmittelbar das bedroht, was gekauft werden soll.

Kosten der Fortführung. Was es kostet, das System zu betreiben und weiterzuentwickeln: Ausgaben für Infrastruktur, Lizenzpflichten, die Größe des nötigen Teams und wie viel der Roadmap von Wartung aufgefressen wird statt von neuer Arbeit.

Haftung. Lizenzen, die mit der kommerziellen Nutzung kollidieren, personenbezogene Daten, deren Verarbeitung eine Beschwerde nicht überstehen würde, Sicherheitslücken und jede regulatorische Pflicht, die das Unternehmen tatsächlich nicht erfüllt.

Veränderbarkeit. Ob neue Funktionen in einem vorhersagbaren Takt ausgeliefert werden können oder ob jede Änderung das Risiko trägt, an ganz anderer Stelle etwas zu zerstören.

Codequalität zählt nur über den vierten Punkt, und genau deshalb verbringt ein Prüfer weniger Zeit mit dem Lesen Ihres Codes, als Gründer erwarten, und mehr Zeit mit der Frage, wie bei Ihnen ein Deployment abläuft.

Die Befunde, die den Preis drücken

Nur eine Person kann deployen. Ein Releaseprozess, der im Kopf eines Menschen oder auf dessen Laptop lebt, gilt als ernstes Betriebsrisiko, ganz gleich wie gut er heute funktioniert.

Keine Testabdeckung auf den Pfaden, die zählen. Gemeint ist keine Prozentzahl, die Prüfer ohnehin weitgehend ignorieren, sondern die Frage, ob sich das System überhaupt mit einem Rest von Zuversicht ändern lässt. Eine Codebasis ohne Tests rund um den Umsatzpfad preist eine langsamere Roadmap ein. Unser Leitfaden zu Strategien für Softwaretests beschreibt, was sich davon wirklich lohnt.

Lizenzkontamination. Copyleft-Code in einem proprietären Produkt ist einer der wenigen Befunde, die eine Transaktion beenden statt sie nur neu zu bepreisen, und ein Scanner findet ihn meist in Minuten.

Personenbezogene Daten ohne belastbare Grundlage. Daten, die ohne klare Rechtsgrundlage erhoben, unbegrenzt aufbewahrt oder an Orten gespeichert werden, die das Unternehmen nicht vollständig aufzählen kann. Die Mechanik der technischen DSGVO-Umsetzung ist genau die, die ein Prüfer nachvollzieht.

Undokumentierte Abhängigkeiten von Personen oder Anbietern. Eine kritische Integration mit einem Lieferanten ohne Vertrag oder Infrastruktur, die in einem privaten Konto liegt: beides liest sich als ungesteuertes Risiko.

Fehlende Sicherheitsgrundlagen. Kein Ergebnis eines Penetrationstests, sondern die Frage, ob Zugangsdaten in der Versionskontrolle liegen, ob Zugriffe entzogen werden, wenn jemand geht, und ob gerade etwas Ungepatchtes aus dem Internet erreichbar ist.

Was Prüfer nicht interessiert

Das gehört gesagt, weil die Vorbereitungszeit knapp ist und meist falsch eingesetzt wird.

Es interessiert niemanden, welches Framework Sie gewählt haben, solange sich dafür Leute einstellen lassen. Architekturmode interessiert ebenso wenig; ein Monolith, der ausliefert, ist kein Befund. Codestil, Namensgebung oder das Fehlen eines Musters, das irgendjemand im Internet empfiehlt, spielen keine Rolle.

Auch null technische Schulden erwartet niemand. Jedes Unternehmen hat welche, und ihr Vorhandensein ist normal. Entscheidend ist, ob das Team weiß, wo sie liegen, und beziffern kann, was sie kosten. Ein Team, das eine klare Liste seiner eigenen bekannten Probleme vorlegt, wirkt kompetent. Ein Team, das behauptet, es gebe keine, wirkt ahnungslos, und der Prüfer muss die Probleme dann allein finden, was länger dauert und einen schlechteren Bericht ergibt.

Vorbereiten, ohne etwas neu zu schreiben

Das meiste, was hilft, dauert Tage statt Monate, und nichts davon rührt an der Architektur.

Schreiben Sie auf, wie deployt wird. Von der leeren Maschine bis zum laufenden System. Dieses eine Dokument adressiert die schädlichste Kategorie von Befunden und ist an einem Nachmittag geschrieben.

Listen Sie Ihre Abhängigkeiten und deren Lizenzen auf. Werkzeuge erzeugen diese Liste in kurzer Zeit, und die Antwort vor dem Prüfer zu kennen ist deutlich mehr wert als ein sauberes Ergebnis.

Holen Sie Zugangsdaten aus der Versionskontrolle und erfassen Sie, wer worauf Zugriff hat. Entziehen Sie anschließend jedem den Zugriff, der das Unternehmen verlassen hat.

Dokumentieren Sie, was Sie als fehlerhaft kennen. Ein kurzes, ehrliches Register bekannter Probleme mit grob geschätzten Behebungskosten. Dieses Register freiwillig vorzulegen gehört zu den wenigen Dingen, die den Ton eines Berichts verlässlich verbessern.

Stellen Sie sicher, dass die Infrastruktur dem Unternehmen gehört, nicht einem privaten Konto, und dass Domains, Zertifikate und Repositories unter der Kontrolle der Gesellschaft stehen.

Was mit den Befunden geschieht

Sie beenden selten einen Deal. Sie werden zu Bedingungen.

Befunde münden typischerweise in eines von drei Ergebnissen: eine Preisanpassung, die die Behebungskosten abbildet, eine Garantie oder Freistellung im Vertrag, oder eine Bedingung, die vor dem Vollzug zu erfüllen ist. Nur Lizenzkontamination und ernste, ungelöste Datenschutzrisiken bringen Transaktionen regelmäßig ganz zum Erliegen.

Das praktische Ziel ist deshalb kein perfektes System. Es ist ein System, dessen Probleme bekannt, begrenzt und beschreibbar sind, denn ein beziffertes Problem wird eingepreist, während bei einem unbezifferten unterstellt wird, es sei schlimmer als es ist.

Mecanik führt technische Prüfungen dieser Art als Teil unserer Arbeit in der Softwareentwicklung durch, meist auf der Käuferseite. Das Muster ist stabil: Die Systeme, die gut durch eine Prüfung kommen, sind nicht die raffinierten, sondern die, bei denen jemand die Dinge aufgeschrieben hat.

Siehe auch: Software Escrow: Wer es wirklich braucht , Fintech-Softwareentwicklung in UK: FCA, Rails und Kosten , Festpreis oder Time and Materials? und Individualsoftware in UK: Der komplette Einkaufsleitfaden .

Häufig gestellte Fragen

Was ist technische Due Diligence? Eine Bewertung dessen, was der Besitz eines Softwaresystems kosten wird und wie schlimm es nach einer Übernahme oder Investition schiefgehen kann. Geprüft werden das Schlüsselpersonenrisiko, die Kosten der Fortführung, die rechtliche Haftung und die Fähigkeit, das System weiter zu verändern, statt Codequalität um ihrer selbst willen zu benoten.

Welche Befunde drücken den Preis am stärksten? Wissen, das sich auf einzelne Personen konzentriert, insbesondere ein Deployment, das nur ein einziger Mensch ausführen kann. Danach: keine belastbaren Tests auf den umsatztragenden Pfaden, Lizenzkontamination durch Copyleft-Code in einem proprietären Produkt, personenbezogene Daten ohne belastbare Rechtsgrundlage und Zugangsdaten, die in der Versionskontrolle eingecheckt sind.

Interessieren sich Prüfer für meine technischen Schulden? Sie erwarten sie. Jedes Unternehmen hat welche, und ihr Vorhandensein ist kein Befund. Entscheidend ist, ob das Team weiß, wo sie liegen, und beschreiben kann, was ihre Behebung kostet. Ein klares Register bekannter Probleme wirkt kompetent; die Behauptung, es gebe keine, wirkt ahnungslos und macht den Bericht schlechter.

Wie bereite ich mich auf eine technische Due Diligence vor? Schreiben Sie auf, wie das System von einer leeren Maschine aus in Betrieb geht, listen Sie Abhängigkeiten und deren Lizenzen auf, entfernen Sie Zugangsdaten aus der Versionskontrolle, prüfen Sie, wer noch Zugriff hat, stellen Sie sicher, dass Infrastruktur und Domains dem Unternehmen gehören und nicht Einzelpersonen, und erstellen Sie ein ehrliches Register bekannter Probleme mit grob geschätzten Behebungskosten.

Kann ein technischer Befund einen Deal vollständig stoppen? Selten. Die meisten Befunde werden zu Preisanpassungen, zu Garantien im Vertrag oder zu Bedingungen, die vor dem Vollzug zu erfüllen sind. Die Ausnahmen, die Transaktionen tatsächlich stoppen, sind Copyleft-Lizenzkontamination in einem proprietären Produkt und schwerwiegende, ungelöste Risiken beim Datenschutz.