IT-Vertragsmanagement – Geld sparen und Konflikte vermeiden (Teil 1)

Vorüberlegungen: Was bringt ein „guter“ IT-Vertrag?

Wozu ein Rechtsanwalt im IT-Projekt? Diese Frage wird häufig auf Netzwerkveranstaltungen gestellt. Es geht, wie meistens bei anwaltlicher Tätigkeit, um ein höheres Maß an Rechtssicherheit und damit an Verlässlichkeit. Es sind mehrere Ziele in einem IT-Projekt, die mit einem Rechtsanwalt und vor allem mit einem IT-Anwalt umfangreicher und sicherer erreicht werden können. Hier einige Beispiele:

• Es geht zum einen um schlichte Klarheit der Sprache, auch wenn nicht alle Rechtsanwälte dafür bekannt sind. Ein guter IT-Vertrag ist ein solcher, aus dessen Wortlaut sich klar, deutlich, zweifelsfrei ergibt: „Wer macht was?!“ Umso selbstverständlicher es klingen mag, umso schwieriger scheint es zu sein, klar zu formulieren. Dabei helfen viele kleine Kniffe wie kurze und richtig aufgebaute Sätze oder die Vermeidung passiv formulierter Sätze. Fehlt diese sprachliche Klarheit, kann es konfliktträchtig und teuer für den Auftraggebenden sein.
• Es geht zum anderen um Nutzungs- und Verwertungsrechte an der Software. Der Auftraggebende sollte sich niemals mit dem Hinweis des IT-Unternehmens begnügen: „Das sind unsere Standardbedingungen!“ Unbedingt sollte (und muss) der Auftraggebende sorgfältig prüfen, ob die vertraglich eingeräumten Softwarerechte ausreichend sind für das aktuelle Geschäft, für etwaige operative Entwicklungen und auch für besondere Geschäftssituationen. Fehlen solche klaren Regelungen, wird das IT-Unternehmen als Rechteinhaber der Software gegebenenfalls einen Nachschlag verlangen.
• Schließlich geht es darum, den Konfliktfall und eine geplante und auch eine mögliche unplanmäßige Vertragsbeendigung (also ein Scheitern) aktiv zu durchdenken, zu verhandeln und vertraglich zu regeln. Die Projektbeteiligten scheuen sich meist davor, an ein Projektscheitern auch nur zu denken. Zu Unrecht: Diese Situation sollte unbedingt berücksichtigt werden, und zwar anfangs, wenn die Vertragsparteien noch zuversichtlich sind, der Verhandlungston allseits wohlwollend ist und das IT-Unternehmen den Auftrag und den Vertragsabschluss (unbedingt) will. Das ist die beste Ausgangsbasis und Projektzeit für den Auftraggebenden, diese Regelungen zu behandeln. Fehlen solche Regelungen, kann es abermals teuer für den Auftraggebenden werden. Denn die vertraglich bestenfalls zugesicherte Preisstabilität gilt dann nicht mehr, die Preise steigen. Auch die vertraglich bestenfalls zugesicherte personelle Verfügbarkeit ist nicht mehr gegeben, wenn der Vertrag beendet ist. Dann muss der Auftraggebende warten – auch das ist regelmäßig sehr teuer.

Software-/Dienstleisterwahl – Verhandlungsposition bestimmen

Die Auswahl des richtigen IT-Unternehmens ist eine vielschichtige Aufgabenstellung und das IT-Recht mag hier kein Schwerpunkt sein. Themen wie Ist-Zustand bestimmen, IT-Produkte auswählen und GAP-Analyse durchführen, werden in zahlreichen Publikationen zu IT-Projekten bereits hinreichend beschrieben, sodass ich darauf verweisen darf. Aus der Erfahrung als IT-Anwalt sind zwei dieser Themen besonders hervorzuheben:

• Erstens sollte der passende Dienstleister gut ausgewählt werden und natürlich kein Neuling im konkret geplanten IT-Projekt des Auftraggebenden sein. Es ist darauf zu achten, dass das auszuwählende IT-Unternehmen über ausreichende Erfahrungen, bestenfalls Branchenerfahrungen, und ggf. über gute oder sehr gute Referenzen verfügt. Aber es sollte nicht zu spezifisch gesucht werden. Es sollte eine Balance gefunden werden zwischen diesen projektspezifischen Erfahrungen, aber auch allgemeinen Kompetenzen, sodass das IT-Unternehmen auch zum „Blick über den Tellerrand“ fähig ist. Das tut dem IT-Projekt gut.
• Zweitens und ebenfalls wichtig ist es, aktiv die Verhandlungsposition zu bestimmen. Die meisten Vertragsparteien kümmern sich darum überhaupt nicht, sondern gehen eher nach ihrem Gefühl. Es lohnt sich wirtschaftlich sehr zu durchdenken, wie weit man in den Verhandlungen gehen kann und will. Manchmal lohnt es sich sogar, parallel mit zwei oder mehr IT-Unternehmen gleichzeitig zu verhandeln. Das kostet zwar Aufwand und Geld, schwächt jedoch die Verhandlungsposition des IT-Unternehmens und verbessert die eigene (ausgehend von unseren Erfahrungswerten).

Rechtswahl und Co.

Viele rechtliche Themen werden in den meisten Verträgen am Ende verhandelt und fixiert – im Abschnitt „Schlussbestimmungen“. Diese Themen sind vor allem dann wichtig, wenn es wirklich einmal darauf ankommen sollte. Dazu zählen beispielsweise:

• In IT-Projekten mit einem Auslandsbezug ist eine Rechtswahlklausel (Beispiel: „Es gilt deutsches Recht.“) zwingend. Anderenfalls können Unsicherheiten entstehen, die Konflikte verursachen, Zeit und damit Geld kosten. Dabei spielt die Größe des IT-Projektes keine Rolle. Denn die Rechtswahlthemen stellen sich in größeren und kleineren IT-Projekten gleichermaßen.
• Ein weiteres Thema ist das UN-Kaufrecht (CISG). Bei internationalen Verträgen gilt das UN-Kaufrecht automatisch, kann jedoch vom Auftraggebenden und dem IT-Unternehmen einvernehmlich abbedungen werden, dann würde allein das vereinbarte Recht gelten, z. B. deutsches Recht. Die entsprechende vertragliche Regelung wird aber häufig falsch formuliert. So wählen die Vertragsparteien nicht selten folgenden falschen Satz: „Für diesen Vertrag gilt ausschließlich das Recht der Bundesrepublik Deutschland.“ Falsch ist diese Regelung, weil das UN-Kaufrecht ein Bestandteil des deutschen Rechts ist. Mit dieser Regelung bleibt also das UN-Kaufrecht ein Vertragsbestandteil. Das bedeutet, dass das UN-Kaufrecht ausdrücklich erwähnt und abgeben werden muss, wenn es das Ziel der Vertragsparteien ist. Ein Beispiel: „Für alle vertraglichen und außervertraglichen Ansprüche gilt ausschließlich deutsches Recht unter Ausschluss des UN-Kaufrechts.“
• Die nächste Empfehlung betrifft die Vertragssprache: Bei einem englischsprachigen Vertrag in Verbindung mit vereinbartem deutschen Recht sollten die rechtlichen Fachbegriffe unbedingt auf Deutsch mitgenannt werden. Üblich ist es, hinter dem englischen Wort in Klammern den deutschen Fachbegriff aufzunehmen. Ein Beispiel: Warranty (Gewährleistung, §§ 437 ff. BGB). Diese Klarstellung ist rechtlich zwingend. Denn das englische Wort „Warranty“ bedeutet sowohl „Gewährleistung“ als auch „Garantie“ – zwei rechtlich völlig unterschiedliche Rechtsbegriffe.
• Schließlich der Gerichtsstand, also die Frage, an welchem Ort geklagt werden müsste, wenn es zu einer gerichtlichen Auseinandersetzung kommen sollte. Häufig wird folgender falscher Satz verwendet: „Gerichtsstand ist Köln.“ Unzureichend ist dieser Satz, weil die Vertragsparteien nicht mit der notwendigen Klarheit zum Ausdruck bringen, dass der vereinbarte Gerichtsstand ausschließlich (!) vereinbart werden soll. In einem Prozess hatte ein Gericht bereits geurteilt, dass die Vertragsparteien auf diese Weise allenfalls einen zusätzlichen (!) Gerichtsstand vereinbart haben, was im Zweifel nicht gewollt war. Richtig wäre folglich: „Ausschließlicher Gerichtsstand für alle Streitigkeiten aus diesem Vertrag, im Zusammenhang mit diesem Vertrag oder über sein Zustandekommen oder Bestehen ist Köln; ausschließliche gesetzliche Gerichtsstände bleiben unberührt.“

Vertragsgegenstand

In diesem Abschnitt geht es um die Hauptleistungspflicht. Es ist aus der Erfahrung heraus leider nicht selbstverständlich, doch aus dem Vertragstext muss sich klar und deutlich ergeben: Was muss das IT-Unternehmen leisten und für welche Leistung(en) muss der Auftraggebende im Einzelnen welchen Betrag bezahlen? Viel zu häufig lassen sich Auftraggebende durch leicht lesbare, jedoch inhaltlich nichtssagende Formulierungen davon überzeugen, den Auftrag zu erteilen. Und immer passiert es in einem so begonnenen IT-Projekt, dass das IT-Unternehmen später eine Zusatzvergütung für solche Kundenwünsche verlangt, die in der Leistungsbeschreibung nicht enthalten oder allenfalls angedeutet sind.

Sehr häufig werden Diskussionen um die Begriffe Werkvertrag und Dienstvertrag geführt. Zur Erinnerung: Beim Werkvertrag zahlt der Auftraggebende dafür, dass das IT-Unternehmen ein bestimmtes Leistungsergebnis herstellt, also ein Werk, sei es ein funktionierendes ERP-System, eine bestimmte Schnittstelle oder ein anderes vorgegebenes Computerprogramm. Beim Dienstvertrag bezahlt der Auftraggebende das IT-Unternehmen „bloß“ für die reine Arbeitszeit, vergleichbar mit Arbeitnehmenden, die auch arbeiten und dafür eine Vergütung erhalten, aber keine bestimmten Erfolge schulden.
Ob in einem konkreten ERP-Projekt einzelne Leistungen als Dienstvertrag oder als Werkvertrag vereinbart wurden, lässt sich nicht abstrakt beschreiben oder bewerten, sondern muss konkret geprüft, durchdacht und das Wording vereinbart werden. Hier ist neben der oben bereits angemahnten Vertragsklarheit auch die Projekterfahrung erforderlich, um die praktische Bedeutung der (meist vom IT-Unternehmen vorgeschlagenen) Vertragsformulierung einschätzen zu können.

Zur Vollständigkeit sollte der Dienstvertrag näher erläutert werden. Es ist falsch, wenn bei IT-Unternehmen die Erwartung vorherrscht, beim Dienstvertrag eine Vergütung zu verdienen, indem man irgendetwas oder irgendwie arbeitet. Die abgerechneten Arbeiten müssen dennoch nachvollziehbar und erforderlich gewesen sein. Nichtssagende oder abstrakte Formulierungen in den Zeitaufzeichnungen (sogenannte Time Sheets) werden bei Gericht meist dazu führen, dass die Zahlungsklage des IT-Unternehmens insoweit abgewiesen wird. Hier ein negatives Beispiel: „9–16 Uhr: Arbeiten am Backend des Webshops.“ Die Insider werden es wissen: Das Backend ist ein so umfassender Begriff, dass darunter eine kaum darstellbare Anzahl und eine fast endlose Vielfalt der Arbeiten fallen kann. Daher wäre ein solcher Tatsachenvortrag im Gerichtsprozess meist nicht genügend.
Ich persönlich bin überzeugt von Dienstverträgen. Denn zu Beginn eines IT-Projektes sind die Vertragsparteien und vor allem der Auftraggebende, der den Erfolg beim Werkvertrag zu bestimmen hat, nicht in der Lage, eine präzise Beschreibung der später abzunehmenden Software oder eines anderen Projektergebnisses zu formulieren. Bei vereinbarten Dienstverträgen sollten die Auftraggebenden die folgenden zwei Ziele verfolgen: Erstens eine Kostenregelung treffen, die sicherstellt, dass keine überraschend hohen Rechnungen eingehen. Hier wären beispielsweise maximale monatliche Rechnungsbeträge denkbar, aber auch sonst sind viele Controlling-Maßnahmen möglich.

Das zweite Ziel ist eine derart gute Arbeitsqualität, dass das Bezahlen für das „bloße Arbeiten“ sich dennoch lohnt. Hier könnten z. B. Regelungen zu einer bestimmten Qualifikation des Projektteams getroffen werden oder vereinbart werden, dass die Einarbeitung von neuen Mitgliedern des Projektteams stets auf Kosten des IT-Unternehmens erfolgt. Schließlich können die Vertragsparteien eines Dienstvertrages auch dafür sorgen, dass beim Dienstvertrag die Programmierleistungen technisch eine bestimmte Güte und Qualität aufweisen, z. B. indem konkrete Anforderungen an die Programmierung vereinbart werden.

Abrechnung und Preisanpassung

Ein zentraler Aspekt bei der Abrechnung ist es, Überraschungen und eine Selbstbedienung durch den IT-Unternehmer zu vermeiden. Dazu nachfolgend einige Ideen:

Zunächst sollte der Auftraggebende, aber auch das auf zufriedene Kunden Wert legende IT-Unternehmen, für ein möglichst hohes Maß an Transparenz sorgen. Daher sollte sich der Auftraggebende nicht mit der kurzen Regelung zufriedengeben, dass die Rechnung binnen 30 Tagen fällig ist. Es sollte immer ein Tätigkeitsnachweis gefordert werden; das diszipliniert erfahrungsgemäß auch das IT-Unternehmen bei der Rechnungsstellung. Ein Beispiel: „Zahlungen sind innerhalb von 30 Tagen nach Rechnungseingang ohne Abzug (wie Skonto) und erst nach Zugang einer detaillierten und prüffähigen Leistungsaufstellung fällig.“

Besondere Vorsicht ist bei verlockenden oder verlockend klingenden Vergütungsvorschlägen geboten, die auf den ersten Blick besonders arbeitgeberfreundlich wirken, sich bei genauerem Hinsehen allerdings nachteilig für den Auftraggebenden auswirken können.

Bei Preisanpassungen sollten „Einbahnstraßen“ vermieden werden, bei denen also der Vertrag ausschließlich Preiserhöhungen vorsieht. Eine solche Regelung wäre ohnehin unwirksam, denn sie verstößt gegen das Preisklauselgesetz. Nach § 2 Abs. 3 Nr. 1 PrKG sind Preisanpassungsregelungen unwirksam, wenn sie so formuliert sind, dass „ein Preis- oder Wertanstieg [eines Index] eine Erhöhung, nicht aber ein Preis- oder Wertrückgang [eines Index] eine entsprechende Ermäßigung des Zahlungsanspruchs bewirkt“.

Unglücklich sind auch Formulierungen, die eine Preisanpassung an vermeintlich objektive Faktoren knüpfen, wie Einkaufskosten, Personalkosten oder Leistungsumfang. Die meisten IT-Unternehmen übersehen dabei, dass sie dadurch möglicherwiese gezwungen sein könnten, ihre Kalkulation offenzulegen. Verlangt ein Lieferant eine Preiserhöhung etwa um 4 %, weil seine Personalkosten um 4 % gestiegen sind, dann genügt es nicht, dies bloß zu behaupten. Vielmehr muss der Lieferant vortragen und bei Gericht auch beweisen, welche Personalkosten er zum Zeitpunkt des Vertragsabschlusses hatte und welche er aktuell hat. Gleiches gilt auch für die behauptete Erhöhung der Einkaufspreise, auch hier müsste Transparenz geschaffen werden. Das ist in den allermeisten Fällen nicht gewollt.

Abnahme

Eine besondere Fallkonstellation möchte ich in diesem Abschnitt hervorheben, den sogenannten Abbruch der Abnahmeprüfung. Stellen Sie sich vor: Ein Auftraggebender lässt ein ERP-System erstellen. Das IT-Projekt dauert über zwei Jahre und kostet ca. 3 Mio. Euro zzgl. ERP-Softwarelizenzen. Das IT-Unternehmen meldet „Fertigstellung, bitte abnehmen“. Hierfür planen die Vertragsparteien einen Monat. Der Auftraggebende engagiert dafür zwei IT-Sachverständige. Die Kosten hierfür liegen bei 3.000 Euro pro Tag. Nach ca. einer Woche und damit ca. 15.000 Euro haben die IT-Sachverständigen ca. 25 % des ERP-Systems geprüft und so viele Fehler festgestellt, dass jetzt schon feststeht, dass das ERP-System nicht abgenommen werden wird. Diese Situation löst zahlreiche Fragen aus: Darf die kostspielige Aufnahmeprüfung abgebrochen oder muss sie fortgesetzt werden? Wer trägt die Kosten dieser und der wiederholten Abnahmeprüfung? Gelten die noch nicht geprüften, aber wegen des Abbruchs der Abnahmeprüfung fehlerhaften Bestandteile des IT-Systems als abgenommen oder sogar als mangelfrei? Liegt eine Teilabnahme vor? Beginnt die Verjährung für einen Teil des ERP-Systems?

Das Ziel eines guten IT-Vertrages ist es, alle diese Fragen zu antizipieren und vorab zu regeln, sodass sich in einem Streitfall die Lösung idealerweise in einer solchen Klarheit aus dem Vertrag ergibt, dass ein Gerichtsverfahren oder bestenfalls sogar die Hinzuziehung von IT-Anwälten überflüssig wird. Daher sollten im ERP-Vertrag alle oben aufgeworfenen Fragen verarbeitet und einer Regelung unterzogen werden. Auch im Übrigen gibt es viele zu vereinbarende Abnahmethemen, hier nur einige wenige exemplarisch aufgezählt:

• Abnahme sollte nur mit einem Protokoll erfolgen; dies dient der Dokumentation und der Beweiserleichterung im Falle einer streitigen oder sogar gerichtlichen Auseinandersetzung.
• Vorsicht vor einer konkludenten (= stillschweigenden) Abnahme, die durch eine rügelose Ingebrauchnahme sozusagen automatisch eintritt. Es sollten entsprechende Erklärungen abgegeben werden, wie eine ausdrückliche endgültige oder vorläufige Abnahmeverweigerung, um einen ungewollten Zustand der Abnahme zu vermeiden.
• Auch Regelungen zur Abnahmefiktion sollten sorgsam durchdacht werden. Aus Sicht des IT-Unternehmens sollte vor allem die Frist nicht zu kurz sein, ansonsten geht das IT-Unternehmen das Risiko ein, dass diese Vertragsregelung unwirksam wird.
• Schließlich sollte auch ausdrücklich über Teilabnahmen nachgedacht und diese nicht einer kaum vorhersehbaren rechtlichen Bewertung in einem Gerichtsverfahren überlassen, sondern ausdrücklich geregelt werden. Teilabnahmen können ausdrücklich ausgeschlossen oder zugelassen werden. Sollten sie zugelassen werden, müssten auch die Folgen mitbedacht und geregelt sein, wie die Verjährung, die bestenfalls für sämtliche Leistungen in einem ERP-Projekt einheitlich beginnt und endet, um keinen rechtlichen und organisatorischen Prüfungs- und Überwachungsapparat aufbauen zu müssen. Ausnahmsweise könnte eine Abnahme auch gänzlich ausgeschlossen werden. Das wird vor allem in gemeinsamen Entwicklungsprojekten der Fall sein, in denen es einen Finanzierungspartner aus der Zielbranche und einen Entwicklungspartner (IT-Unternehmen) gibt.

Der Artikeltitel entspricht dem gleichnamigen Workshop des Autors zum Thema IT-Vertragsgestaltung. Die entsprechenden Veranstaltungsfolien stehen zur Verfügung auf: https://www. werner-ri.de/team/partner/roman-pusep