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 Transkation 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 weiter betreiben 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 vorgängig 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 Assessment 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. Die Methoden-Kits der klassischen Due Diligence-Anbieter enthalten für die Bewertung solcher Targets nicht die richtigen Werkzeuge.
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 vorgängig 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-Pratices“ 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 „readability 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 gewonnen Erkenntnisse für eine Due Diligence regelmäßig nur begrenzt nützlich.
Code-Stellen zu finden, die einer Überarbeitung bedürfen oder veraltete Bibliotheken aufzuspüren (und das sind die am häufigsten in Assessment-Berichten ausgewiesenen Probleme) ist für die Weiterentwicklung einer Software eine gute Informationsbasis. Das geht 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. Dieser fällt aber auch bei manueller Durchsicht des Programmcode beinahe sofort auf. 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 des Codes Aufschluss. Eine Aussage über Professionalität und Zukunftsfähigkeit der Gesamt-Architektur, des Zusammenspiel des Codes mit der Hosting-Infrastruktur oder zentralen Prozessen, wie beispielsweise dem Desaster 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 statistischen Analysen – sowieso immer manuell zu analysieren.
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 Software-Bibliotheken, die unter der „Gnu Public License“ („GPL“) stehen. Die GPL setzt unter Anderem zwingend voraus, dass der gesamte Quelltext der eigenen Anwendung unter die GPL gestellt öffentlich zugänglich gemacht wird, wenn die Open Source-Bibliothek tief in die eigene Lösung integriert oder angepasst wird („viral strict copyleft license“). Das widerspricht dem Geschäftsmodell der meisten Targets. Große Open Source-Vereinigungen (wie beispielsweise die Free Software Foundation oder die Apache Foundation) gehen gegen solche Rechtsverstöße sehr strukturiert vor und schöpfen hierbei erhebliche Mittel von kommerziellen Unternehmen ab, die gegen die Lizenzen ihrer Open Source-Projekte verstoßen. Auch sehr namhafte Hersteller, wie beispielsweise AVM, haben das in der Vergangenheit bereits erfahren (LG Berlin, 08.11.2011, Az. 16 O 255/10).
Auch schon ein einzelner, fehlender Lizenzvermerk auf eine der eingesetzten Open Source Bibliotheken oder eine eingesetzte, kostenfrei nutzbare Schriftart im Impressum der eigenen Software reicht aus, um gegen die Lizenzbedingungen gängiger Open Source-Projekte 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äßt sich toolbasiert über die Erstellung einer „Software Bill of Materials“ recht einfach aufdecken. Dazu helfen Tools, wie beispielsweise OWASP CycloneDX. Die Bewertung, ob die Nutzung einer Bibliothek mit kritischer Lizenz tatsächlich einen Lizenzverstoß darstellt, ist in der Praxis aber – 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 im Bezug auf das Urheberrecht – mit dem europäischen an etlichen Stellen unvereinbar ist. 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 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 Weiterbetrieb des Target oft kaum darstellbar. Nicht selten sind gerade die Software-Teams mit ihrem Know-How eines der Kern-Assets, die es zu erwerben gilt.
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, zu bewerten. Gerade dieses Know-How 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 Head-Hunter, 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 Assessment sollte daher auf die Identifizierung der Key-Know-How-Träger im Target und der 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 detektivische, 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 während Assessments erschreckend oft vernachlässigter Aspekt sind gesammelte Daten. Solche Daten können gut sichtbar in Form von Data-Warehouses oder -Lakes vorliegen. Dann stellen 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. 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 ergibt daher ein sehr verlässliches Bild und kann ein guter Anhaltspunkt zur objektiven Validierung zentraler Aussagen des Target im Rahmen eines Due Diligence Prozesses sein.
