Da die wenigsten Gesch\u00e4ftsmodelle heute noch rein \u201eauf Papier\u201c ablaufen, h\u00e4ngt der Erfolg einer Unternehmenstransaktion oder eines Asset-Deals heute fast immer auch von der in einer IT-Due-Diligence gepr\u00fcften Qualit\u00e4t und Ordnungsm\u00e4\u00dfigkeit der IT-Systeme und insbesondere der Software des gekauften Unternehmens bzw. Assets ab. Als unabh\u00e4ngige IT-Sachverst\u00e4ndige untersuchen wir bei Unternehmenstransaktionen eine Vielzahl von Faktoren, die im Folgenden dargestellt werden.<\/p>\n
Insbesondere bei Asset-Deals (d.h. Transaktionen, in denen nicht das ganze Unternehmen, sondern nur bestimmte Aktiva, z.B. ein Softwaresystem an den K\u00e4ufer \u00fcbertragen wird) stellt sich die Frage, welche Rechte an genau welchen Softwarebestandteilen \u00fcbertragen werden m\u00fcssen. Oft ben\u00f6tigt ein modernes Softwaresystem \u201eunter der Motorhaube\u201c eine Vielzahl von Komponenten, die bez\u00fcglich Ihrer Benennung ggf. nichts mit dem aus kaufm\u00e4nnischer Sicht zu erwerbenden System zu tun haben. Auch kommt es vor, dass wesentliche Teile der Software \u00fcberhaupt nicht dem verkaufenden Unternehmen geh\u00f6ren, sondern als Dienst (\u201eSoftware as a Service\u201c) bei einem Dritten eingekauft werden.<\/p>\n
An dieser Stelle ist eine strukturelle Bestandsaufnahme<\/em> der notwendigen IT-Landschaft wichtig, um im Kaufvertrag unmissverst\u00e4ndlich definieren zu k\u00f6nnen, was nun Teil des Deals ist und was nicht. Bei der Bestandsaufnahme sollten auch pro Softwarekomponente die f\u00fcr eine weitere rechtliche Betrachtung wichtigen Aspekte gekl\u00e4rt werden, n\u00e4mlich die genaue Herkunft der jeweiligen Komponente (Entwicklung durch Freiberufler, Angestellte oder Gesch\u00e4ftsf\u00fchrer? Nutzung von Open Source? Nutzung von kommerziellen Lizenzen?), Abh\u00e4ngigkeiten zu Fremdfirmen (z.B. kein Zugriff auf Sourcecode), Laufzeitabh\u00e4ngigkeiten von Drittdiensten (z.B. Bonit\u00e4tschecks) etc. Damit ist die Strukturanalyse die Basis f\u00fcr alle weiteren m\u00f6glichen Elemente der IT-Due-Diligence.<\/p>\n 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\u00e4ftszweck vertr\u00e4gliche Open-Source-Lizenz zugrunde liegt. Im Rahmen einer technischen IT-Due-Diligence sollte f\u00fcr jeden Bestandteil der Software genau gekl\u00e4rt werden, ob ggf. vorhandene fremde Rechte den Erfolg der Transaktion gef\u00e4hrden k\u00f6nnen. Eine rein rechtliche Absicherung durch eine Zusicherung im Kaufvertrag ist aus praktischer Sicht oft nicht hilfreich, da die Verk\u00e4ufer im Ernstfall (d.h. wenn der K\u00e4ufer wegen einer Urheberrechtsverletzung angegangen wird) oft nicht mehr greifbar sind bzw. den entstandenen Schaden nicht kompensieren k\u00f6nnen.<\/p>\n Die technische IT-Due-Diligence sollte im Rahmen der Strukturanalyse also die Grundlagen f\u00fcr 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\u00fchzeitig aufgedeckt, k\u00f6nnen sie meistens noch in einer Form behoben werden, die die wirtschaftliche Grundlage des Deals nicht gef\u00e4hrdet.<\/p>\n Informationstechnologie ist st\u00e4ndig im Fluss. Unternehmenssoftware wird st\u00e4ndig an neue bzw. ge\u00e4nderte Anforderungen angepasst. Teilsysteme werden neu entwickelt, um innovative Fachfunktionen einzuf\u00fchren oder auch nur eine Modernisierung der Technologie zu erreichen.<\/p>\n Im Rahmen einer IT-Due-Diligence sollte auch die zuk\u00fcnftige Weiterentwickelbarkeit der \u00fcbernommenen Systeme betrachtet werden. Starke Abh\u00e4ngigkeiten von Zulieferfirmen, im Scheitern oder in Verzug befindliche Projekte oder auch Verwendung von veralteten Technologien k\u00f6nnen die strategischen Ziele einer Akquisition gef\u00e4hrden.<\/p>\n Im Rahmen der Projekt- und Organisationsanalyse k\u00f6nnen die beschriebenen Risiken aufgedeckt werden, so dass bereits im Prozess der Integrationsplanung entsprechende Gegenma\u00dfnahmen entwickelt und ber\u00fccksichtigt werden k\u00f6nnen. Beispielsweise kann zur Reduzierung der Abh\u00e4ngigkeiten von Drittunternehmen eine Sourcecode-Hinterlegung (Escrow) als Teil des Deals vereinbart werden.<\/p>\n Vielfach basiert die kaufm\u00e4nnische Logik eines Deals auf der Integration eines innovativen Gesch\u00e4ftsmodells in die vertrieblichen Strukturen eines wesentlich gr\u00f6\u00dferen Unternehmens. Aus technischer Sicht stellt sich dabei eine Reihe von Fragen, beispielsweise zu den folgenden Punkten:<\/p>\n Auch grunds\u00e4tzliche Qualit\u00e4tsfragen zu Geschwindigkeit, Benutzbarkeit oder auch IT-Sicherheit spielen bei der \u00dcbernahme von \u201eIT-haltigen\u201c Unternehmen und Assets eine wichtige Rolle. Im Rahmen der IT-Due-Diligence sollten also die f\u00fcr den strategischen Erfolg des Deals wichtigsten Qualit\u00e4tsfaktoren \u00fcberpr\u00fcft werden. Festgestellte Defizite k\u00f6nnen ggf. behoben werden, die entsprechenden Kosten (Stichwort: Ert\u00fcchtigungskosten) k\u00f6nnen allerdings einen Einfluss auf den Kaufpreis haben.<\/p>\n In vielen Transaktionen stellt sich die Frage nach dem \u201emake-or-buy\u201c, d.h. der K\u00e4ufer 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 \u00fcbertragbar sind). Je nach Situation kommen ganz unterschiedliche Wertbegriffe zum Tragen, beispielsweise der Verkehrswert, Erstellungswert oder auch der Ertragswert einer Software.<\/p>\nHerkunftsanalyse bei der Due-Diligence: Aufdeckung m\u00f6glicher urheberrechtlicher Probleme mit der Software<\/h2>\n
Projekt- und Organisationsanalyse bei der Due-Diligence: Abh\u00e4ngigkeiten und Risiken in laufenden Projekten und Wartungsvorhaben aufdecken<\/h2>\n
IT-Qualit\u00e4tsanalyse: Gen\u00fcgen die \u00fcbernommenen Systeme den zuk\u00fcnftigen Anforderungen?<\/h2>\n
\n
Wertgutachten: Ist das IT-System sein Geld wert?<\/h2>\n