Da die wenigsten Geschäftsmodelle heute noch rein „auf Papier“ ablaufen, hängt der Erfolg einer Unternehmenstransaktion oder eines Asset-Deals heute fast immer auch von der in einer IT-Due-Diligence geprüften Qualität und Ordnungsmäßigkeit der IT-Systeme und insbesondere der Software des gekauften Unternehmens bzw. Assets ab. Als unabhängige IT-Sachverständige untersuchen wir bei Unternehmenstransaktionen eine Vielzahl von Faktoren, die im Folgenden dargestellt werden.

Strukturanalyse bei der Due-Diligence: Welche technischen Komponenten gehören überhaupt zum verkauften IT-System?

Insbesondere bei Asset-Deals (d.h. Transaktionen, in denen nicht das ganze Unternehmen, sondern nur bestimmte Aktiva, z.B. ein Softwaresystem an den Käufer übertragen wird) stellt sich die Frage, welche Rechte an genau welchen Softwarebestandteilen übertragen werden müssen. Oft benötigt ein modernes Softwaresystem „unter der Motorhaube“ eine Vielzahl von Komponenten, die bezüglich Ihrer Benennung ggf. nichts mit dem aus kaufmännischer Sicht zu erwerbenden System zu tun haben. Auch kommt es vor, dass wesentliche Teile der Software überhaupt nicht dem verkaufenden Unternehmen gehören, sondern als Dienst („Software as a Service“) bei einem Dritten eingekauft werden.

An dieser Stelle ist eine strukturelle Bestandsaufnahme der notwendigen IT-Landschaft wichtig, um im Kaufvertrag unmissverständlich definieren zu können, was nun Teil des Deals ist und was nicht. Bei der Bestandsaufnahme sollten auch pro Softwarekomponente die für eine weitere rechtliche Betrachtung wichtigen Aspekte geklärt werden, nämlich die genaue Herkunft der jeweiligen Komponente (Entwicklung durch Freiberufler, Angestellte oder Geschäftsführer? Nutzung von Open Source? Nutzung von kommerziellen Lizenzen?), Abhängigkeiten zu Fremdfirmen (z.B. kein Zugriff auf Sourcecode), Laufzeitabhängigkeiten von Drittdiensten (z.B. Bonitätschecks) etc. Damit ist die Strukturanalyse die Basis für alle weiteren möglichen Elemente der IT-Due-Diligence.

Herkunftsanalyse bei der Due-Diligence: Aufdeckung möglicher urheberrechtlicher Probleme mit der Software

Auch vermeintlich eigenentwickelte Software besteht aus technischer Sicht zumeist zu >90% aus Fremdbestandteilen. Das ist kein Problem, wenn diese korrekt kommerziell lizensiert sind bzw. eine mit dem weiteren Geschäftszweck verträgliche Open-Source-Lizenz zugrunde liegt. Im Rahmen einer technischen IT-Due-Diligence sollte für jeden Bestandteil der Software genau geklärt werden, ob ggf. vorhandene fremde Rechte den Erfolg der Transaktion gefährden können. Eine rein rechtliche Absicherung durch eine Zusicherung im Kaufvertrag ist aus praktischer Sicht oft nicht hilfreich, da die Verkäufer im Ernstfall (d.h. wenn der Käufer wegen einer Urheberrechtsverletzung angegangen wird) oft nicht mehr greifbar sind bzw. den entstandenen Schaden nicht kompensieren können.

Die technische IT-Due-Diligence sollte im Rahmen der Strukturanalyse also die Grundlagen für die rechtliche Bewertung schaffen. Dabei kann insbesondere eine genaue Analyse des Sourcecodes und der von dort aufgerufenen Dritt-Bibliotheken (Libraries) sinnvoll sein, um problematische Fremdbestandteile wie z.B. unter einer AGPL- oder GPL-Lizenz stehende Komponenten zu erkennen. Werden solche Probleme frühzeitig aufgedeckt, können sie meistens noch in einer Form behoben werden, die die wirtschaftliche Grundlage des Deals nicht gefährdet.

Projekt- und Organisationsanalyse bei der Due-Diligence: Abhängigkeiten und Risiken in laufenden Projekten und Wartungsvorhaben aufdecken

Informationstechnologie ist ständig im Fluss. Unternehmenssoftware wird ständig an neue bzw. geänderte Anforderungen angepasst. Teilsysteme werden neu entwickelt, um innovative Fachfunktionen einzuführen oder auch nur eine Modernisierung der Technologie zu erreichen.

Im Rahmen einer IT-Due-Diligence sollte auch die zukünftige Weiterentwickelbarkeit der übernommenen Systeme betrachtet werden. Starke Abhängigkeiten von Zulieferfirmen, im Scheitern oder in Verzug befindliche Projekte oder auch Verwendung von veralteten Technologien können die strategischen Ziele einer Akquisition gefährden.

Im Rahmen der Projekt- und Organisationsanalyse können die beschriebenen Risiken aufgedeckt werden, so dass bereits im Prozess der Integrationsplanung entsprechende Gegenmaßnahmen entwickelt und berücksichtigt werden können. Beispielsweise kann zur Reduzierung der Abhängigkeiten von Drittunternehmen eine Sourcecode-Hinterlegung (Escrow) als Teil des Deals vereinbart werden.

IT-Qualitätsanalyse: Genügen die übernommenen Systeme den zukünftigen Anforderungen?

Vielfach basiert die kaufmännische Logik eines Deals auf der Integration eines innovativen Geschäftsmodells in die vertrieblichen Strukturen eines wesentlich größeren Unternehmens. Aus technischer Sicht stellt sich dabei eine Reihe von Fragen, beispielsweise zu den folgenden Punkten:

  • Skalierbarkeit: Kann die gekaufte IT die erwartete Mehrlast in der neuen Umgebung mit linearen Kosten verarbeiten (z.B. Einsatz von Startup-Software in einem Großkonzern)?
  • Wartbarkeit: Kann man die Software im neuen Einsatzkontext noch ökonomisch weiterentwickeln?
  • Multi-site-Fähigkeit: Kann man die Software in mehrere, internationale Tochtergesellschaften ausrollen und dann noch wartbar anpassen?

Auch grundsätzliche Qualitätsfragen zu Geschwindigkeit, Benutzbarkeit oder auch IT-Sicherheit spielen bei der Übernahme von „IT-haltigen“ Unternehmen und Assets eine wichtige Rolle. Im Rahmen der IT-Due-Diligence sollten also die für den strategischen Erfolg des Deals wichtigsten Qualitätsfaktoren überprüft werden. Festgestellte Defizite können ggf. behoben werden, die entsprechenden Kosten (Stichwort: Ertüchtigungskosten) können allerdings einen Einfluss auf den Kaufpreis haben.

Wertgutachten: Ist das IT-System sein Geld wert?

In vielen Transaktionen stellt sich die Frage nach dem „make-or-buy“, d.h. der Käufer steht vor der Alternative, ein fertiges IT-Asset zu kaufen, oder ein vergleichbares IT-System selbst zu erstellen bzw. erstellen zu lassen. Vielfach stellt sich im Rahmen der Transaktion auch heraus, dass ein Teil der zu kaufenden IT-Landschaft gar nicht verkauft werden kann (z.B. weil die entsprechenden Lizenzen nicht übertragbar sind). Je nach Situation kommen ganz unterschiedliche Wertbegriffe zum Tragen, beispielsweise der Verkehrswert, Erstellungswert oder auch der Ertragswert einer Software.

Details zu den verschiedenen Wertarten finden Sie im Bereich Wertgutachten.