IT-Verträge: Wie man Fußangeln vermeidet

20.03.2006 von Frank Koch
Vereinbarungen über Entwicklungs- und Outsourcing-Projekte müssen verständlich formuliert sein, damit in Problemfällen einvernehmliche Lösungen gefunden werden können.

Die IT-Verträgen zwischen Dienstleistern und Anwendern enthalten gerne bestimmte technische Begriffe und Beschreibungen von Abläufen, ohne dass diese vorher ausreichend definiert werden.

Hier lesen Sie …

  • welche Änderungen ein Dienstleister im Rahmen des Change-Managements leisten muss;

  • wie lange Applikationen vom Anbieter gewartet werden müssen;

  • welche Pflichten Anwender in Projekten haben;

  • wie sich die problemlose Rückübertragung der Datenbestände bei Vertragsende regeln lässt.

Die Rechtsprechung verpflichtet Dienstleister dazu, Software fünf Jahre lang zu warten, definiert die Aufgaben aber nicht. Verträge zwischen Anbieter und Anwender sollten daher Klarheit schaffen.

Solche Unklarheiten führen immer wieder zu Streit und Prozessen, die die angestrebten Einsparungen gefährden und verhindern können. Einige Beispiele sollen verdeutlichen, wie sich solche Probleme vermeiden lassen.

Change-Management: Wie teuer sind Änderungen?

IT-Projekte werden gegenüber dem ursprünglichen Plan oft geändert und ergänzt. Der Umgang mit derartigen Abweichungen wird in Verträgen unter der Bezeichnung "Change Management" erfasst. Allerdings fehlt in solchen Klauseln zumeist eine klare Unterscheidung zwischen zwei Arten von Änderungen, nämlich Mängeln, die der Anbieter kostenfrei beheben muss, und echten und damit kostenpflichtigen Leistungsänderungen beziehungsweise -erweiterungen, die der Auftraggeber wünscht. Ohne entsprechende Differenzierung kann der Anbieter sich im ungünstigen Fall auf die Position zurückziehen, sämtliche Änderungen dem Kunden in Rechnung zu stellen. Damit käme es zu der paradoxen Situation, dass der IT-Dienstleister mit selbst verschuldeten Mängeln zusätzlichen Umsatz generieren könnte. Im Interesse des Kunden sollte deshalb klar geregelt sein, dass der Anbieter fehlerhafte Implementierungen auf eigene Rechnung berichtigen muss.

Für echte Erweiterungen hingegen sollten Partner die Kostenfrage frühzeitig klären. Allerdings sind die Projekte zu Beginn oft nicht eindeutig abschätzbar, so dass Umfang und Verlauf unklar sind. In gewissem Rahmen muss der Anbieter mit Änderungen rechnen und sie in seiner Kalkulation berücksichtigen. Das hat das Kammergericht Berlin in einem Urteil bestätigt, ohne allerdings die zumutbaren Abweichungen genau zu benennen (siehe Kasten "Die Urteile", Kammergericht Berlin). Damit bleibt für Kunden die Unsicherheit, in welchem Umfang sie für ergänzende Leistungen mit zusätzlichen Kosten rechnen müssen. Es empfiehlt sich daher, die Änderungen zu dokumentieren.

Lifecycle: Fünf Jahre Wartungspflicht

Die Softwareentwicklung verläuft typischerweise und analog zur ISO-Norm 12207 in den Phasen Analyse, Entwurf, Codierung, Test und Wartung (siehe Grafik "Die Lebenszyklen einer Software"). Zusammen bezeichnen Anbieter das als "Lifecycle". Die Rechtsprechung erlegt den Anbietern eine umfangreiche Bereitschaft zur Pflege der Programme auf (siehe Kasten "Die Urteile", Landgericht Köln). Selbst ohne ausdrückliche vertragliche Vereinbarungen besteht ab Installa- tion fünf Jahre eine Pflicht zur Wartungsbereitschaft. Das gilt auch dann, wenn in der Zwischenzeit bereits Folgeversionen entworfen wurden. Allerdings sollten Kunden, die eine langfristige Pflege ihrer Applikationen wünschen, nicht auf diesen Richterspruch vertrauen, da er weder den ISO-Normen noch der gängigen Vertragspraxis entspricht. Sinnvoller ist es, in den Verträgen ausdrücklich die Dauer der Wartungsbereitschaft zu vereinbaren.

Die Urteile

  • Kammergericht Berlin, Urteil vom 1.6.1990, Computer und Recht (CR) 1990, S. 768;

  • Landgericht Köln, Urteil vom 16.10.1997, CR 1999, S. 218;

  • Oberlandesgericht München, Urteil vom 22.4.1999, CR 1999, S. 484;

  • Landgericht München I, Urteil vom 10.3.1994, Betriebsberater Beilage 14/1994, S. 12;

  • Bundesgerichtshof, Urteil vom 4.11.1992, CR 1993, S. 203.

Auch der Kunde hat Pflichten

Nicht nur dem Anbieter, auch dem Kunden werden im IT-Vertrag Pflichten auferlegt. Die Zahlungspflichten sind in den Kontrakten zumeist klar geregelt. Dagegen bleiben die Angaben zu den Mitwirkungspflichten in vielen Fällen vage. Die Anbieter sind oftmals auf die Hilfe der Kunden angewiesen, wenn etwa das Pflichtenheft ausgearbeitet oder Altdaten zur Konvertierung übergeben werden müssen. Kommt der Anwender seiner Aufgabe nicht nach, wird der Dienstleister Probleme haben, nachzuweisen, wann der Kunde welche Mitwirkungsleistungen zu erbringen gehabt hätte. Ebenso unbefriedigend ist eine unzureichende vertragliche Klärung auch für die Anwenderunternehmen. Sie finden sich in einer unsicheren Rechtssituation wieder, wenn nicht klar ist, in welchem Maße sie mithelfen müssen und wann sie ihre Aufgaben zu erledigen haben. Der Vertrag sollte daher diese Pflichten vollständig und präzise definieren. Daraus muss das Anwenderunternehmen erkennen können, wann welche Aufgaben anfallen. Außerdem sollte es sich vom Anbieter bestätigen lassen, dass es die jeweiligen Aufgaben erfüllt hat. Dies dient zugleich der vom Anbieter geschuldeten Aufklärung und Beratung des Anwenderunternehmens, denn der muss den Kunden auf seine Verantwortlichkeiten hinweisen. Beispiele sind erforderliche Mitarbeiterschulungen oder die rechtzeitige Einbindung des Betriebsrats.

Datenübergabe bei Vertragsende

Endet ein Wartungs- oder auch ein Outsourcing-Vertrag, benötigt der Kunde seine Daten rechtzeitig vor Vertragsende, um etwa den Servicepartner nahtlos wechseln zu können. Zwar bejaht die Rechtsprechung den Anspruch auf rechtzeitige Rückübertragung vor Vertragsende, die konkrete Ausgestaltung spart sie sich jedoch (siehe Kasten "Die Urteile"; OLG München). Dies kann zu erheblichen Verzögerungen im Migrationsprojekt führen, so dass es ratsam ist, im Vertrag den passenden Zeitpunkt und die Formalitäten der Rückgabe näher zu beschreiben. Sinnvoll ist außerdem, eine Funktionsprüfung zu vereinbaren, um zu klären, ob die Daten verarbeitungstauglich sind. Keinen Gerichtsentscheid gibt es zudem in der Frage, in welchem Format und Modell der Anbieter die Daten übergeben muss. Auch hier lohnt eine genaue Beschreibung, die schon vor Projektbeginn formuliert wird.

Ein digitales Handbuch reicht nicht

Nicht selten werden schriftliche Benutzerdokumentationen von Systemen oder Software durch eine Benutzerführung am Bildschirm oder Download-Angebote ersetzt. Das Interesse der Anbieter ist klar: Sie wollen die zuweilen nicht unbeträchtlichen Druckkosten sparen und schnell aktuelle Texte zur Verfügung stellen. Die Rechtsprechung verlangt in der Regel aber weiterhin die Übergabe einer schriftlichen Dokumentation, insbesondere dann, wenn ausdrücklich von einem "Handbuch" die Rede ist (siehe Kasten "Die Urteile", Landgericht München I). Das ist nachvollziehbar, eine Bildschirmdokumentation hilft dem Anwender wenig, wenn etwa das System abgestürzt ist.

Da es unterschiedliche Formen der Dokumentation wie zum Beispiel Benutzer- und Entwicklungshandbücher gibt, ist eine klärende Vereinbarung über alle zu übergebenden Unterlagen samt spätestem Übergabezeitpunkt unabdingbar. Ausdrücklich vereinbart werden sollte weiter eine Verpflichtung des Anbieters, auch alle während der Implementierung noch erforderlichen Änderungen zu dokumentieren. Liefert der Anbieter die vereinbarte schriftliche Dokumentation nicht, nur auf Datenträger oder einer Website, erfüllt er seine entsprechende vertragliche Hauptleistungspflicht zumindest teilweise nicht. Fehlt etwa das für die Programmanwendung erforderliche Benutzerhandbuch, kann der Kunde die Abnahme sowie Zahlung der Software verweigern (siehe Kasten "Die Urteile", BGH). (jha)