|
Dieser Beitrag
unterliegt dem Urheberrecht!
Investitionsschutz
So sichern Sie sich über einen
Vertrag bei Softwareprojekten richtig ab
Internet World Business, 15/07, S. 27
Nicht selten investieren Unternehmen sechs- bis
siebenstellige Beträge für die (An-)Schaffung einer Softwarelösung. So werden
regelmäßig ERP-Systeme (Enterprise Resource Planning) auf Basis von
Standardsoftware eingerichtet oder durch zusätzliche, individuell programmierte
Module auf die Anforderungen des Kunden hin angepasst. Zum Einsatz kommen somit
Standardsoftwareprodukte, deren Funktionsfähigkeit mit Blick auf die getätigte
Investition auch langfristig sicherzustellen ist. Häufig übernimmt das
Unternehmen ein solches Softwareprojekt nicht selbst, sondern beauftragt ein
externes Systemhaus damit. Neben der Festlegung essenzieller Fragen in einem
Projektvertrag wie Leistungsinhalte, Nutzungsrechte, Haftung, Change-Requests,
Vergütung sowie Meilensteine nebst Exit-Klauseln bei deren Nichterreichen, gilt
es, die dadurch erreichten Ziele auch langfristig zu sichern. Für den
Investitionsschutz sind hier mehrere Eckpfeiler maßgeblich
Service Level Agreements
Zunächst hat das
Unternehmen im Rahmen des Risikomanagements für geschäftskritische Anwendungen
deren Lauffähigkeit sicherzustellen (unter anderem in Hinblick auf § 91 Abs. 2
Aktien-Gesetz, § 43 GmbH-Gesetz). Dies bedeutet insbesondere, dass Fehler an
der Software kurzfristig beseitigt werden. Da das gesetzliche Gewährleistungsrecht
zum einen hierfür nur eine "angemessene" Frist vorsieht, zum anderen
– in AGB regelmäßig vereinbart – im kaufmännischen Bereich nur eine einjährige
Sachmängelhaftungsverjährung greift, bedarf es hier einer ergänzenden Unterstützung
durch das Systemhaus.
Diese Unterstützung wird
regelmäßig in sogenannten Pflege- und Supportverträgen oder auch Service
Level Agreements (SLA) gefasst und dient der schnellen Wiederherstellung der
Funktionsfähigkeit. Zu unterscheiden ist hier zwischen sogenannten Maintenance
Agreements zum einen, bei denen es im Wesentlichen um (vorbeugende)
Fehlerbeseitigung und Funktionsverbesserungen durch Patches, Bugfixes oder neue
Releasestände geht, und zum anderen SLAs, bei denen (auch) eine telefonische
Hotline vorgehalten wird. Deren genaue Verfügbarkeit sollte zunächst
vertraglich vereinbart werden, ebenso die nächste Eskalationsstufe über die
sogenannte "First Level Fixing Rate" hinaus: Das Problem wird an den
Systemprogrammierer beziehungsweise Softwarehersteller weitergegeben, um eine möglichst
schnelle Fehlerbehebung zu erreichen.
Für das Unternehmen ist
es hier wichtig, den Unterschied zwischen Reaktionszeit und Fehlerbehebungszeit
zu kennen. Während die erste Variante nur ein Tätigwerden ohne einen
geschuldeten Erfolg meint, garantiert eine Fehlerbeseitigungsfrist zu einem
bestimmten Zeitpunkt nach Öffnung eines "Fehler-Tickets" die
Fehlerbehebung. Wegen der vorzuhaltenden Manpower ist für den Dienstleister die
zweite Variante naturgemäß die kostenintensivere. Allerdings muss das
Unternehmen kalkulieren, wie hoch die Opportunitätskosten im Falle eines
Stillstands über mehrere Stunden oder gar einen Tag zu Buche schlagen.
Anpassung an Veränderungen
Ist die Software nebst
Anpassung und Zusatzmodulen erfolgreich installiert, gilt es für die nächsten
Jahre dieses Ergebnis bestmöglich zu bewahren. Gleichzeitig ist die Anpassung
an gesetzliche und regulative Vorgaben (Stichwort Compliance) sicherzustellen.
Da in den letzten Jahren
Implementationsleistungen für Standsoftware mit Zusatzmodulen als Folge des
zunehmenden Wettbewerbs häufig günstig verhandelt werden konnten, versuchen
Dienstleister nicht selten über SLAs, Änderungsverlangen (Change Request) oder
die preisliche Neufestlegung von SLA-Konditionen wieder Geld einzuspielen.
Das Unternehmen hat daher
mit Blick auf den Investitionsschutz durch vertragliche Festlegungen darauf zu
achten, dass ein Anbieter die Pflegekonditionen nicht nach eigenem Belieben
festsetzen kann. Das kann zum Beispiel passieren, wenn ein SLA-Vertrag eine
Laufzeit von drei Jahren hat und danach vom Systemhaus gekündigt wird. Wenn die
Applikation als geschäftskritisch einzustufen ist, ist das Unternehmen auf
weitere Pflege angewiesen und hat dann keine andere Wahl, als nahezu jede
Preiskondition zu akzeptieren.
Kein Kontrahierungszwang
Allerdings besteht in der
Regel kein Kontrahierungszwang, das heißt, ein Systemhaus muss keinen
Anschlussvertrag zu "angemessenen Konditionen" abschließen. Ausnahmen
sind allenfalls aus kartellrechtlichen Gründen denkbar. Für Unternehmen gilt
deshalb, hier frühzeitig Vorsorge zu treffen. Dies sollte noch zu einem
Zeitpunkt erfolgen, zu dem es das Unternehmen aufgrund der
Verhandlungskonstellation in der Hand hat, auch hier für sich günstige
Konditionen zu verhandeln.
Beispielsweise kann
verhandelt werden, dass für die Festsetzung der SLA-Vergütung (nur) eine
Preisindizierung erfolgt und im Rahmen des SLA gleichzeitig das ordentliche Kündigungsrecht
des SLA-Erbringers ausgeschlossen wird; auch kann eine solche Indexklausel nach
oben beschränkt werden.
Eine Alternative hierzu
ist die Vereinbarung einer Benchmarkingklausel, wonach die Angemessenheit der
Bepreisung der Services durch einen neutralen Sachverständigen festgelegt wird.
Diese Klausel hat den Vorteil einer besseren Dynamik in der Anpassung,
gleichzeitig aber den Nachteil der Kosten für den Benchmarker von nicht selten
10.000 bis 20.000 Euro aufwärts. Letzterer lohnt sich daher nur bei größeren
Vertragsvolumina.
Ein Unternehmen kann sich
auch dadurch vor Ungemach schützen, dass für den Fall, dass das Systemhaus die
Pflege nicht zu angemessenen Konditionen anbietet, das Unternehmen einen
Anspruch auf Herausgabe des (gut kommentierten) Quellcodes hat, sodass eine
Pflege selbst erfolgen kann.
Quellcodehinterlegung
Ganz wichtig und nach der
neueren Rechtsprechung des BGH zu berücksichtigen ist ein Investitionsschutz,
indem eine Quellcodesicherungs-/Hinterlegungsklausel aufgenommen wird, wonach
das Unternehmen unter bestimmten Voraussetzungen den Quellcode zur Bearbeitung,
aber auch zur Fortentwicklung erhält.
Geht nämlich
beispielsweise ein Dienstleister, der eine proprietäre Softwareanwendung oder
eine individuelle Zusatzprogrammierung auf Objektcodebasis geliefert hat, in
Insolvenz, wird diese Firma gegebenenfalls durch den Insolvenzverwalter
liquidiert. Erfolgt auch keine Übertragung der Softwarerechte auf Dritte, endet
die Pflege des Softwareprodukts (End-of-Life) mit dem Ergebnis, dass das
Unternehmen früher oder später die Software nicht mehr nutzen kann; Gleiches
gilt für die generelle Einstellung der Softwarepflege.
Vertragstechnisch löst
man diese Problematik dadurch, dass für bestimmte Fälle der Schlechtleistung
und Schlechterbringung, End-of-Life sowie auch für den Fall der Insolvenz ein
Anspruch auf Herausgabe des bei einem Escrow-Agenten hinterlegten Quellcodes
besteht. Dieser Escrow-Agent tritt als Treuhänder auf und übergibt den
Quellcode erst dann, wenn bestimmte vertraglich fixierte Bedingungen eintreten.
Gleichzeitig muss bereits ein dingliches Anwartschaftsrecht durch aufschiebend
bedingte Herausgabe des Quellcodes und Einräumung entsprechender Bearbeitungs-
und Fortentwicklungsrechte für den Hinterlegungsfall vereinbart werden, um eine
Insolvenzfestigkeit dieser Regelung zu erreichen. Häufig wurden in der
Vergangenheit vor der Rechtsprechung des BGH vom 17.11.2005 (Az.: IX ZR 162/04)
eher schuldrechtliche Ansprüche auf Herausgabe des Quellcodes vereinbart, die
mangels dinglicher Wirkung nicht insolvenzfest waren.
Da es sich beim Quellcode
um ein Kern-Know-how handelt, tun sich Softwareunternehmen schwer, eine solche
Klausel zu akzeptieren. Bei näherer Erläuterung der Situation und des
Investitionsschutzes, insbesondere der Entscheidung für eine proprietäre und
gegebenenfalls nur von einem kleineren Unternehmen angebotenen Anwendung, dürfte
hier regelmäßig professionelles Verständnis zu erwarten sein.
Zusammenzufassen ist,
dass die Entscheidung über die Anschaffung einer Software nicht allein mit
deren Implementierung erledigt ist. Vielmehr muss sich ein Unternehmen bereits
vor Abschluss eines Projektvertrags mit der Frage auseinandersetzen, wie es die
Investition geschäftskritischer IT-Anwendungen langfristig schützt.
|