IT-Assessments werden regelmäßig nicht nur im Rahmen des Verkaufes von Unternehmen, als Teil der (Pre Merger-)Due Diligence, durchgeführt. Auch in Restrukturierungs- oder Integrations-Projekten (Post-Merger-Integration) oder als Ausgangspunkt für Strategieprojekte liefert eine Bestandsaufnahme durch unternehmensfremde Personen objektive Fakten als Ausgangspunkt angestrebter Veränderungen.
Umfang und Detailtiefe der Betrachtung variieren zwischen Pre- und Post-Merger-Assessments ebenso wie die Art der Durchführung. Im Rahmen eines typischen Pre-Merger-Due-Diligence-Prozesses ist – nicht nur aus Gründen der Vertraulichkeit des Vorgangs – beispielsweise nur begrenzter Zugriff auf Mitarbeiter und Assets des untersuchten Unternehmens möglich. Die inhaltlichen Kern-Fragestellungen aber sind bei Pre- und Post-Merger-Assessments nahezu identisch.
Strategische Ziele beim Unternehmenserwerb
Eine zentrale Frage beim Erwerb eines Unternehmens ist, was im Kern der Transaktion steht. Welcher Teil des Unternehmens, welches Asset, bildet den wichtigsten Wert, der erworben werden soll? Das kann durchaus das Gesamt-Unternehmen sein – gerade, wenn es nach dem Kauf eigenständig weiterbetrieben werden soll. Öfter, als man denkt, ist dieses Kern-Asset aber nur ein – oft relativ kleiner – Teil des Ziel-Unternehmens. Das können eine Marke, bestehende Kundenbeziehungen, spezielle Produkte oder bestimmte Teams mit ihrem Know-how sein. In diesem Fall ist im Rahmen der Transaktion meist die Integration des Target in das Käufer-Unternehmen, eine Aufteilung oder ein späterer Weiterverkauf von Teilen des Target an Dritte angestrebt.
Im Rahmen einer Due Diligence ist – schon aus zeitlichen Gründen – keine vollständige Analyse des Zielunternehmens in beliebiger Detail-Tiefe möglich. Kern-Asset und Ziel der Transaktion vorab klar zu identifizieren, um sich im Analyse-Prozess auf damit im Zusammenhang stehende Themen zu fokussieren, ist daher zentral für eine erfolgreiche Due Diligence. Im Verlauf des Assessments ist dann ein fortwährender Abgleich von Strategie und Zielen des Erwerbers mit den vorgefundenen Tatsachen unerlässlich.
IT-Due-Diligence in Software-Targets
Unternehmen wie in obigem Beispiel, deren Kern-Wertschöpfung und damit Geschäftsmodell auf einer selbst entwickelten Software basiert („Software-Targets“), erfordern ein angepasstes Vorgehen im Rahmen einer Due Diligence. Klassische IT-Assessments setzen bei ihnen regelmäßig die falschen Schwerpunkte und erfassen für die Bewertung wesentliche Fakten nicht.
Erfolgreiche, mittelständische Software-Targets haben dafür zu unterschiedliche Wertschöpfungsmodelle: Sie besetzen enge Markt-Nischen mit hoch spezialisierten Leistungen, digitalisieren bisher analoge Angebote oder schaffen völlig neue, digitale Lösungen mit ihrer Software. Nicht selten handelt es sich im weitesten Sinne um E-Commerce-Portale, Online-Marktplätze oder SaaS-/Cloud-Angebote zur Abbildung von Prozessen, für die bisher lokal selbst betriebene Software genutzt wird.
Die Vielzahl und Unterschiedlichkeit der Wertschöpfungsmodelle birgt ein hohes Risiko, dass standardisierte Bewertungsmodelle – und mit ihnen Due-Diligence-Prozesse – das Kern-Asset nicht ausreichend in den Fokus nehmen. Standardisierte Methoden-Kits klassischer Due-Diligence-Anbieter sind stark bei gut vergleichbaren Prüfobjekten. Für die Bewertung mittelständischer Software-Targets mit ausgefallenen Wertschöpfungsmodellen fehlt genau diese Vergleichbarkeit.
Statische Code-Analysen
Eines der zentralen Assets, die während der IT-Due-Diligence eines Software-Targets zu betrachten sind, ist die im Unternehmen entwickelte Software. In der Praxis stellt das eine größere Herausforderung dar, als es zunächst scheinen mag.
Nicht selten handelt es sich eben nicht um eine homogene Software-Lösung. Vielmehr findet man oft heterogene, zerklüftete Software-Landschaften vor. Etliche, oft nur unternehmensintern sichtbare bzw. eingesetzte, selbst entwickelte Werkzeuge im Hintergrund sind in vielen Targets zu finden. Beispiele sind Administrations-Lösungen zur Verwaltung der eigenen Produkte und Kundenverträge, selbst entwickelte Prüf- oder Auswertungslösungen (beispielsweise zur Qualitätssicherung oder Vertriebssteuerung) oder eigenentwickelte, komplexe Abrechnungs- und Kundenverwaltungsmodule. Diese Tools sind dem Erwerber vorab in aller Regel nicht bekannt, für die Wertschöpfung im Target aber oft zentral.
Auch Produkte aus ganz unterschiedlichen Technologie-Generationen, die zwar als eine Lösung vermarktet werden, technisch aber nicht viel miteinander gemein haben, sind eher die Regel als die Ausnahme. All das wurde oft von verschiedenen „Generationen“ von Software-Entwicklern geschaffen, von denen meist nur noch die letzte im Unternehmen ist. Die Folge sind viele getrennte, technisch unterschiedliche Software-Module (nicht selten basierend auf völlig unterschiedlichen Technologien), die es in der knappen Zeit einer Due Diligence zu analysieren gilt.
Hierfür wird – gerade in standardisierten Due-Diligence-Prozessen – häufig mit einer werkzeugbasierten, statischen Code-Analyse gearbeitet. Dabei wird der Quelltext der Target-Lösung durch eine Prüfsoftware analysiert. Die verwendeten Analysetools können dabei die verschiedensten Programmiersprachen/Technologien prüfen und liefern schnell Auswertungen auch über sehr umfangreiche Software-Portfolios. Die Analysen, die heutige Prüfsoftware dabei vollautomatisch ausführt, sind umfangreich. Geprüft werden die Code-Struktur, die Programmiermethoden werden mit gängigen „Best Practices“ abgeglichen, der Code wird auf (leicht erkennbare) Sicherheitslücken hin untersucht, es wird geprüft, ob verwendete Bibliotheken und Module von Drittanbietern aktuell sind, und es wird versucht, die Code-Qualität mit KPIs wie einem „Maintainability Index“ zu bewerten.
Auch wenn die automatisch erstellten Auswertungen professionell aussehen und – das ist bei großen zu analysierenden Software-Plattformen fast unvermeidlich – immer das eine oder andere gefundene Problem auswerfen, sind die damit real gewonnenen Erkenntnisse für eine Due Diligence regelmäßig nur begrenzt nützlich.
Code-Stellen zu finden, die einer technischen Überarbeitung bedürfen (der am häufigsten in Assessment-Berichten ausgewiesene Befund), ist für die Weiterentwicklung einer Software eine gute Informationsbasis. Als Bewertungsgrundlage geht das jedoch am Ziel einer Due Diligence vorbei. Hier geht es um die Bewertung der Werthaltigkeit der Lösung, um eine Prüfung, ob sie als Basis für eine zukünftige Weiterentwicklung dienen kann (Bewertung der Tragfähigkeit) oder auch darum, sich ein Bild davon zu verschaffen, ob ein professioneller und sicherer Unternehmensbetrieb mit dieser Plattform umsetzbar ist. Dafür statisch analysierte Code-Struktur-, Best-Coding-Practice- oder Programming-Pattern-Analysen heranzuziehen, mag auf den ersten Blick nachvollziehbar (weil faktenbasiert) wirken. Real stellt das zur Beantwortung derartiger zentraler Fragen aber eben gerade keine belastbare Informationsbasis dar.
Solche statischen Analysen können besonders schlechten Programmcode durchaus aufdecken. Diese Information an sich ist aber keine tragfähige Aussage. Darüber, ob eine Code-Basis für die Zukunft tragfähig ist oder wie professionell sie gestaltet ist, geben am Ende nur manuelle Inaugenscheinnahmen und eine daraus folgende Bewertung des Codes Aufschluss. Eine Aussage über Professionalität und Zukunftsfähigkeit der Gesamt-Architektur, des Zusammenspiels des Codes mit der Hosting-Infrastruktur oder zentralen Prozessen, wie beispielsweise dem Disaster Recovery oder Support-Prozessen, das Identifizieren der für das Geschäftsmodell zentralen Software-Bestandteile oder eine Bewertung des Codes im Kontext des Wettbewerbes und der zu erwartenden technologischen Entwicklungen sind für die Gesamtbewertung von viel wesentlicherer Bedeutung.
Um solche Aspekte zu beleuchten, sind intensive Gespräche mit den leitenden Entwicklern der beste Einstieg, um einen schnellen Überblick über die Architektur zu erhalten. Die dort gesammelten Aussagen und die darauf basierenden Erkenntnisse gilt es dann faktisch zu validieren. Dafür können Aussagen aus Einzelinterviews wichtiger Team-Mitglieder miteinander abgeglichen werden. Auch technische Auswertungen z. B. der Commit-Historie oder Analysen der Infrastruktur-Protokolle sind hierfür nützlich. Die Software-Architektur und zentrale Code-Stellen sind im Zuge der Validierung – ganz unabhängig von Interviews oder statischen Analysen – sowieso immer manuell zu analysieren.
Fragen zur IT-Due-Diligence? Gesprächstermin buchen, anrufen (+49 211 97 26 55 44) oder Anfrage senden.
Rechtsverletzungen
Eines der größten Risiken bei Software-Targets ist das (nicht nur monetäre) Risiko, das aus potenziellen Rechtsverstößen erwächst, die in der Softwarelösung des Targets begründet sind. Hier geht es in erster Linie um Lizenzverstöße oder um Patentverletzungen. Diese Risiken haben ökonomisch meist eine kritische Dimension.
Das Aufdecken von Patentverletzungen ist ein zeitaufwändiger Prozess und liegt in aller Regel außerhalb dessen, was in einer Pre-Merger-Due-Diligence geleistet wird. Hierfür sind umfangreiche Markt- und Patent-Recherchen, das Hinzuziehen spezialisierter Fachanwälte und intensive, manuelle Analysen des Software-Quelltextes und der dahinterstehenden Algorithmen nötig. Oft muss auch der historische Entstehungs- und Entwicklungsprozess rekonstruiert werden, um die Herleitung einer Lösung belegen zu können. Das übersteigt den Rahmen von Pre-Merger-Betrachtungen bei Weitem. Pre-Merger wird das daher nur analysiert, wenn bereits Indizien für Probleme in diesem Bereich vorliegen (z. B. anhängige Patentstreitigkeiten) oder wenn es bei der Transaktion im Speziellen um den Erwerb eines bestimmten Algorithmus geht.
Das Risiko von (in der Praxis merklich häufiger vorkommenden) typischen Lizenzverstößen kann und sollte dagegen im Rahmen einer Due Diligence mindestens rudimentär betrachtet werden. Solche Verstöße entstehen beispielsweise, indem im eigenen Code Bibliotheken Dritter genutzt werden, deren Lizenzbedingungen mit dem eigenen Anwendungsfall oder Geschäftsmodell nicht vereinbar sind.
Ein häufiges Beispiel dafür ist die Nutzung von (meist kostenfreien) Open-Source-Lösungen, die unter der weit verbreiteten „GNU General Public License“ („GPL“) oder der „GNU Affero General Public License“ („AGPL“) stehen. Einbindung oder Integration einer solchen Lösung in das eigene Produkt kann – je nach Lizenz und Art der Integration – leicht zur Folge haben, dass die eigene Anwendung selbst der entsprechenden Open-Source-Lizenz unterworfen wird. Eine mögliche Folge davon kann sein, dass der Quelltext des eigenen Produktes weitergegeben werden muss („viral strict copyleft license“). Das widerspricht dem Geschäftsmodell der meisten Targets. Je nach Lizenzmodell kann schon das Bereitstellen oder Zugänglichmachen einer Open-Source-Lösung über das Netz genügen, um derartige Folgen auszulösen. Weit verbreitete Open-Source-Produkte wie Grafana, MinIO oder Nextcloud stehen unter entsprechenden Lizenzen.
Verstöße bleiben nicht auf Dauer folgenlos. Organisationen wie die Free Software Foundation oder die Software Freedom Conservancy verfolgen sie strukturiert. Auch namhafte Hersteller hat es bereits getroffen. So wurde beispielsweise D-Link wegen entsprechender GPL-Verstöße verurteilt (LG Frankfurt a. M., 06.09.2006, Az. 2-6 O 224/06). Selbst Großkonzerne wie Orange mussten schon hohe, sechsstellige Summen zahlen (Entr’ouvert ./. Orange, Cour d’appel de Paris, 14.02.2024).
Auch schon ein einzelner fehlender Lizenzvermerk zu einer der eingesetzten Open-Source-Bibliotheken in der eigenen Software oder eine in unerlaubtem Rahmen eingesetzte Schriftart reicht aus, um gegen die Lizenzbedingungen eines Open-Source-Projektes zu verstoßen.
Ein solcher Verstoß passiert meist aus reiner Nachlässigkeit während der Software-Entwicklung. Programmierer sehen eher die weite Verbreitung einer Bibliothek in Open-Source-Kreisen und die daraus resultierende Ausgereiftheit der Funktionalität und legen beim Einsatz häufig kein besonderes Augenmerk auf die Lizenzbedingungen.
Welche Bibliotheken verwendet werden und unter welchen Lizenzen diese stehen, lässt sich toolbasiert über die Erstellung einer „Software Bill of Materials“ recht einfach aufdecken. Dazu helfen Werkzeuge wie Syft, cdxgen oder Trivy, die eine SBOM in etablierten Formaten wie CycloneDX (ein OWASP-Projekt, seit 2024 als Ecma-424 standardisiert) erzeugen. Lösungen wie ScanCode Toolkit (nexB), OSS Review Toolkit (ORT) oder SCANOSS erlauben noch deutlich tiefer gehende Analysen rein mit Open-Source-Werkzeugen. Die Bewertung, ob die Nutzung einer Bibliothek mit kritischer Lizenz tatsächlich einen Lizenzverstoß darstellt, ist in der Praxis – selbst für Fachjuristen – oft merklich komplexer, als es scheint. Nicht nur, weil die meisten Open-Source-Lizenzen auf dem angloamerikanischen Rechtssystem basieren, das – speziell in Bezug auf das Urheberrecht – vom europäischen an etlichen Stellen grundlegend abweicht. Oft spielt die Bewertung der genauen Art der Nutzung, Einbindung oder Anpassung einer solchen Open-Source-Bibliothek eine zentrale Rolle für die Bewertung der Frage nach dem lizenzkonformen Einsatz.
Wurde letztendlich ein potenzieller Lizenzverstoß ausgemacht, gilt es (oft der eigentlichen Due Diligence nachgelagert) zu bewerten, mit welchem Aufwand sich der Verstoß beheben lassen würde. Dazu ist beispielsweise zu prüfen, welche alternativen Bibliotheken mit vergleichbarer Funktionalität, aber unschädlichem Lizenzmodell existieren und wie tief die betroffene Bibliothek in das Produkt des Target integriert ist. Daraus ergibt sich eine Abschätzung, wie aufwändig eine Behebung des Missstandes für die Zukunft wäre. Weiterhin gilt es zu prüfen, welche (in der Regel finanziellen) Risiken sich aus dem Fehler der Vergangenheit ergeben und wie diese mitigiert werden könnten.
Das IT-Team als zentrales Asset
Bei mittelständischen Software-Targets ist das Team des Unternehmens ein regelmäßig unterschätztes Asset. Auch wenn sich der Personalmarkt im IT-Bereich in der letzten Zeit wieder etwas beruhigt und normalisiert hat, sind gut qualifizierte IT-Kräfte (speziell mit Know-how aus Softwarehäusern) nach wie vor extrem nachgefragte Mitarbeiter. Ohne ihr Fachwissen ist der ökonomische (Weiter-)Betrieb des Target oft kaum darstellbar. Nicht selten gehören gerade die Software-Teams mit ihrem Know-how zu den Kern-Assets, die der Käufer erwerben möchte.
Ein Eigentümerwechsel bringt unvermeidlich Unsicherheit und damit Unruhe in jedes Team. Im Rahmen der Due Diligence gilt es daher, die zentralen Know-how-Träger zu identifizieren und das Risiko eines Abgangs bzw. die Bedingungen, die zu einem Verbleib des betreffenden Mitarbeiters im Unternehmen führen würden, abzuschätzen. Das Know-how dieser Kern-Mitarbeiter hat das Target in die Position gebracht, die es für den Erwerb interessant macht. Genau dieses Know-how gilt es daher zu sichern.
Ein – in der Praxis gar nicht so selten eintretendes – Worst-Case-Szenario ist der Abgang ganzer Software-Teams kurz nach oder schon im Rahmen der Übernahme. Der Erwerber müsste in so einem Fall das gesamte technische Know-how im laufenden Betrieb neu aufbauen – was in der Realität selten in wirtschaftlich darstellbarem Zeitrahmen möglich ist. Spätestens mit dem Beginn der Vollzugsphase der Unternehmensübernahme wird die Transaktion in der Regel öffentlich bekannt. Es gibt nicht wenige Headhunter, die sich genau darauf spezialisiert haben, die daraus entstehende Phase der Unsicherheit bei den Mitarbeitern abzupassen, um gezielt komplette Software-Teams abzuwerben.
Im Rahmen des Assessments sollte daher auf die Identifizierung der Key-Know-how-Träger im Target und die Bewertung ihrer Bedeutung für das Unternehmen Wert gelegt werden. Die in M&A-Projekten gebotene Vertraulichkeit erlaubt aber ausführliche Einzelinterviews mit allen betroffenen Personen eher selten. Dann sind stattdessen akribische technische Analysen erforderlich, um – beispielsweise aus Datenbeständen, wie der Commit-Historie des Software-Quelltextes – die erforderlichen Informationen ohne direkte Ansprache der Mitarbeiter zu rekonstruieren.
Unterschätzte Daten-Schätze
Ein weiterer während IT-Assessments erschreckend oft vernachlässigter Aspekt sind gesammelte Daten des Target. Solche Daten können gut sichtbar in Form von Data-Warehouses oder -Lakes vorliegen. Dann stellen sie eine eigene Asset-Klasse dar, die Gegenstand des Erwerbes ist.
Daneben gibt es aber auch eine Vielzahl von Daten in Form von zum Beispiel Audit-Protokollen, die in vielen verschiedenen Systemen verteilt vorliegen. Auch CRM-, Kundensupport- oder Ticket-Systeme bilden einen wertvollen Pool an Daten. Solche Daten sind ein zentrales Element zur objektiven Validierung von Aussagen der Mitarbeiter über Infrastruktur, Produkte und Prozesse.
In den meisten Unternehmen eingesetzte Standard-Lösungen wie Office 365 oder das ERP- bzw. FiBu-System schreiben ebenso ausführliche Protokolle wie die in fast allen Software-Targets eingesetzten Entwickler-Dienste wie GitHub oder Azure DevOps. Auch aus der IT-Infrastruktur lassen sich, mit etwas Aufwand, merklich mehr Betriebsdaten gewinnen, als allgemein bekannt ist. Microsofts Active Directory, Cloud-Storage-Dienste wie Google Drive oder Hosting-Umgebungen wie Amazon Web Services sind dafür prominente Beispiele.
Aus diesen Daten lässt sich viel über die Geschäftstätigkeit des Unternehmens und seiner Mitarbeiter ablesen. Es lässt sich beispielsweise erkennen, seit wann und wie regelmäßig an einem Thema gearbeitet wird und welcher Mitarbeiter bestimmte Themen oder Prozesse bearbeitet.
Software-Targets sammeln in aller Regel im Verlauf ihrer Geschäftstätigkeit auch etliche Daten über das Verhalten ihrer Endanwender und ausgeführte Transaktionen. Diese Daten geben objektiven Aufschluss über die Entwicklung des Unternehmens, die Akzeptanz seiner Produkte am Markt oder die Zufriedenheit der Kunden.
Diese Daten stammen dabei regelmäßig aus sehr unterschiedlichen Quellen. Sie liegen an unterschiedlichen Stellen und in unterschiedlichen Formaten vor. Alle Daten dieser verschiedenen Quellen zu einem einzelnen Geschäftsvorfall müssen inhaltlich zueinander passen. Derartige Daten in allen Quellen stimmig zu verändern, ist technisch meist so aufwändig, dass es in der Realität fast als unmöglich angesehen werden kann. Eine Analyse eben dieser Datenbestände und eine Korrelation der Daten aus den verschiedenen Quellen gegeneinander ergeben daher ein sehr verlässliches Bild und können gute Anhaltspunkte zur objektiven Validierung zentraler Aussagen des Target im Rahmen eines Due-Diligence-Prozesses sein.
Update 2026
KI-gestützte Code-Analyse. Große Sprachmodelle erfassen Quelltext im Zusammenhang und erschließen gewachsene Codebasen in Stunden statt Tagen. Zwei Einschränkungen bleiben: Der Quelltext eines Targets gehört nicht ohne Weiteres in fremde Dienste, und die Analyse ist nur so tragfähig wie der mitgelieferte Kontext. Der Fokus verschiebt sich damit mehr denn je weg von der effizienten Durchführung einer Due Diligence hin zu einer inhaltlich fundierten Beurteilung der Findings. Die richtigen Fragen zu stellen, ist heute wichtiger denn je. Die Toolauswahl rückt weiter in den Hintergrund. Die wichtigste Frage beantwortet auch die stärkste KI nicht: Ob die Software das Geschäftsmodell des Käufers in fünf Jahren noch trägt.
KI-generierter Code im Target. Kaum betrachtet wird bisher die andere Seite derselben Entwicklung: Ein wachsender Teil des bewerteten Codes ist heute selbst mit KI entstanden. Seine Herkunft lässt sich kaum zweifelsfrei nachweisen. Gleichzeitig gibt es immer mehr Code im Produkt, den nie ein Mitarbeiter vollständig gelesen oder gar verstanden hat. Das Team kann vollzählig an Bord bleiben und sein eigenes Produkt trotzdem nicht mehr erklären. Wer ein Software-Target kauft, muss deshalb fundierter denn je die Frage beantworten, wie zukunftsfähig das Gespann aus eingekaufter Technologie und dem dazugehörenden Team wirklich ist.