Warum Beiräte eine Technologie-Due-Diligence brauchen
Finanzen werden geprüft. Verträge werden geprüft. Die Technologie, auf der das ganze Geschäftsmodell steht, wird geglaubt.
Vor jeder größeren Investition, jeder Übernahme, jeder Nachfolgeregelung wird geprüft. Die Zahlen prüft ein Wirtschaftsprüfer, die Verträge prüft eine Kanzlei, das Umweltrisiko prüft ein Gutachter. Das ist Standard, und niemand diskutiert darum.
Die Technologie prüft niemand.
Genauer: Sie wird übersprungen, ausgelagert oder von der falschen Person gemacht. Übersprungen, weil im Gremium niemand die Frage stellen will, deren Antwort er nicht beurteilen kann. Ausgelagert an eine Beratung, die im selben Atemzug die Umsetzung anbietet. Oder gemacht vom CTO des Unternehmens selbst, das gekauft werden soll — der damit sein eigenes Werk bewertet.
Das ist bemerkenswert, weil die Technologie in vielen dieser Unternehmen nicht ein Kostenblock ist, sondern das Geschäftsmodell. Wer eine Software, eine Plattform, eine Sensorik oder eine Fertigungssteuerung kauft, kauft eine Behauptung über deren Zustand. Die Zahlen sagen, was das Ding bisher verdient hat. Sie sagen nichts darüber, ob es die nächsten fünf Jahre trägt.
Was eine echte Prüfung leistet
Eine Technologie-Due-Diligence beantwortet nicht die Frage „ist das gut gemacht?“. Das ist eine Geschmacksfrage, und sie führt zu Architekturdebatten, die ein Gremium nicht entscheiden kann. Sie beantwortet vier andere Fragen, und die sind kaufmännisch:
- Was kostet es, das Bestehende weiter zu betreiben? Nicht die Lizenzkosten — die Personen, die Abhängigkeiten, die aufgeschobenen Modernisierungen.
- Was ist wirklich fertig? Was läuft heute bei einem zahlenden Kunden in Produktion, und was existiert als Prototyp, Demo oder Roadmap-Eintrag?
- Was passiert, wenn drei Leute gehen? In fast jedem technisch getriebenen Mittelständler gibt es eine kleine Zahl von Personen, ohne die das System nicht weiterentwickelt werden kann.
- Welche Entscheidung ist unumkehrbar? Manche technischen Festlegungen lassen sich in einem Quartal korrigieren, andere binden ein Unternehmen für ein Jahrzehnt.
Ein Gutachten, das diese vier Fragen mit Zahlen und Zeiträumen beantwortet, ist für ein Gremium brauchbar, auch wenn niemand darin programmieren kann. Eines, das sie nicht beantwortet, ist es nicht — gleichgültig, wie dick es ist.
Sieben Warnzeichen eines Gefälligkeitsgutachtens
Der praktisch schwierigere Fall ist nicht das fehlende Gutachten. Es ist das vorhandene, das nichts prüft. Daran erkennen Sie es:
-
Es enthält keine einzige unbequeme Aussage.
Kein reales technisches System ist ohne Befund. Ein Bericht ohne einen Satz, der jemandem im Raum unangenehm ist, hat entweder nicht hingeschaut oder nicht geschrieben, was er sah.
-
Es beschreibt die Architektur, statt sie zu bewerten.
Seitenlange Systemdiagramme sind kein Urteil. Die Frage ist nicht, wie es aufgebaut ist, sondern was dieser Aufbau in den nächsten drei Jahren kostet und verhindert.
-
Es unterscheidet nicht zwischen produktiv und geplant.
Wenn Sie im Text nicht bei jeder Fähigkeit erkennen können, ob sie heute bei einem Kunden läuft, ist die Unschärfe kein Versehen. Sie ist das Ergebnis.
-
Es nennt keine Personenabhängigkeiten.
Namen müssen nicht fallen, Rollen schon. Ein Bericht, der nicht sagt, wie viele Personen ein kritisches Teilsystem erklären können, hat das größte Einzelrisiko ausgelassen.
-
Es prüft den Code, aber nicht den Betrieb.
Qualitätskennzahlen aus dem Quelltext sind einfach zu erheben und sagen wenig. Wie oft fällt das System aus, wie lange dauert die Wiederherstellung, wie läuft ein Update — das sagt mehr.
-
Der Prüfer verdient am Zustandekommen der Transaktion.
Wer im Anschluss die Migration, die Modernisierung oder die Integration anbieten möchte, hat ein Interesse an einem anschlussfähigen Ergebnis. Das muss nicht böswillig sein, um die Unabhängigkeit zu beseitigen.
-
Es endet mit einer Ampel statt mit einer Entscheidung.
Grün, Gelb, Rot ist eine Zusammenfassung, keine Entscheidungsgrundlage. Brauchbar wird es erst, wenn dahinter steht, was das jeweils in Euro und in Monaten bedeutet.
Wenn drei dieser Punkte zutreffen, haben Sie kein Gutachten, sondern eine Absicherung. Sie ist für das Protokoll geschrieben, nicht für die Entscheidung.
Die eine Frage
Es läuft am Ende nicht auf Methodik hinaus, sondern auf eine einzige Frage, die jedes Gremium sich selbst stellen kann, ohne Berater und ohne Vorbereitung:
Können wir die Technologie, auf der unser Unternehmen steht, tatsächlich beurteilen — oder verlassen wir uns darauf, dass es jemand anderes getan hat?
Wer die Frage ehrlich mit Nein beantwortet, hat damit schon etwas gewonnen. Die zweite Frage — was daraus folgt — ist deutlich leichter.
Before any major investment, any acquisition, any succession, things get examined. An auditor checks the numbers, a law firm checks the contracts, an assessor checks the environmental risk. That is standard, and nobody argues about it.
Nobody checks the technology.
More precisely: it gets skipped, outsourced, or done by the wrong person. Skipped, because nobody on the board wants to ask a question whose answer they could not judge. Outsourced to a consultancy that offers the implementation in the same breath. Or done by the CTO of the very company being bought — who is thereby assessing his own work.
That is remarkable, because in many of these companies the technology is not a cost centre. It is the business model. Anyone buying a piece of software, a platform, a sensor system or a production control system is buying a claim about its condition. The numbers say what the thing has earned so far. They say nothing about whether it will hold for another five years.
What a real assessment delivers
A technology due diligence does not answer the question “is this well built?” That is a matter of taste, and it leads to architecture debates that no board can settle. It answers four different questions, and they are commercial ones:
- What does it cost to keep running what exists? Not the licence fees — the people, the dependencies, the modernisations that have been deferred.
- What is actually finished? What runs in production today at a paying customer, and what exists as a prototype, a demo or a line on a roadmap?
- What happens if three people leave? In almost every technically driven mid-sized company there is a small number of people without whom the system cannot be developed further.
- Which decision is irreversible? Some technical choices can be corrected within a quarter; others bind a company for a decade.
A report that answers these four questions with figures and timeframes is useful to a board, even if nobody on it can write code. One that does not answer them is not — however thick it may be.
Seven signs of an accommodating report
The harder case in practice is not the missing report. It is the report that exists and examines nothing. Here is how to recognise it:
-
It contains not one uncomfortable statement.
No real technical system is without findings. A report that does not contain a single sentence someone in the room would rather not hear either did not look, or did not write down what it saw.
-
It describes the architecture instead of judging it.
Pages of system diagrams are not a verdict. The question is not how it is built, but what that construction will cost and prevent over the next three years.
-
It does not separate what is live from what is planned.
If you cannot tell, for every capability described, whether it runs at a customer today, the vagueness is not an oversight. It is the result.
-
It names no dependencies on individuals.
Names need not be given; roles do. A report that does not say how many people can explain a critical subsystem has left out the single largest risk.
-
It examines the code but not the operation.
Quality metrics taken from source code are easy to collect and say little. How often the system fails, how long recovery takes, how an update actually goes — that says more.
-
The assessor earns money if the transaction goes ahead.
Anyone hoping to supply the migration, the modernisation or the integration afterwards has an interest in a result that keeps the door open. It need not be ill-intentioned to destroy independence.
-
It ends with a traffic light instead of a decision.
Green, amber, red is a summary, not a basis for a decision. It only becomes useful once it states what each colour means in euros and in months.
If three of these apply, you are not holding an assessment. You are holding a cover note. It was written for the minutes, not for the decision.
The one question
In the end it does not come down to methodology but to a single question, which any board can put to itself without advisers and without preparation:
Can we actually judge the technology our company stands on — or are we relying on the assumption that somebody else has?
Answering that honestly with a no is already worth something. The second question — what follows from it — is considerably easier.