IT-Vertrag sichert Projekterfolg

Wie entstehen eigentlich Konflikte

Konflikte bei IT-Projekten entstehen immer dann, wenn zwischen Anbieter und Kunde unterschiedliche Auffassungen zu Leistungsumfang, Qualität, Mitwirkungspflichten, Nutzungsrechten, Budgetreue und Leistungsterminen bestehen. Beispiel: Die Einführung des neuen ERP-Systems verzögert sich um sechs Monate und hat bereits 130 Prozent des vereinbarten Budgets gekostet. Der CIO des Kunden stellt alle weiteren Zahlungen an den Anbieter ein, weil er der Meinung ist, der Anbieter hat die Verzögerungen und die Budgetüberschreitung zu vertreten. Der Geschäftsführer des Anbieters droht daraufhin, alle seine Leute vom Projekt abzuziehen. Nach seiner Auffassung hat der Kunde durch seine ständigen Änderungswünsche die Verzögerungen und den Mehraufwand selbst verschuldet und ist daher zur weiteren Zahlung verpflichtet.

Das Problem in solchen Situationen: Jede der Parteien glaubt Recht zu haben. Dabei weicht die “gefühlte” Rechtsposition nicht selten von der tatsächlichen Position erheblich ab. Wenn beide Parteien sich dann so richtig in ihre jeweilige Sichtweise und Verärgerung hineingesteigert haben, wird es schwer, noch einen gemeinsamen Einigungshorizont zu finden, insbesondere dann, wenn die jeweils Verantwortlichen gegenüber Aufsichtsrat oder Vorgesetzten zugeben müssten, vielleicht selbst einen Fehler gemacht zu haben.

Wo liegt das besondere Konfliktpotenzial bei IT-Projekten

Auch wenn man eine ERP-Standardsoftware kauft, ist das kein Serienprodukt, das man wie eine Kaffeemaschine im Internet oder Laden erwirbt, auspackt, an die Steckdose anschließt, Kaffe und Wasser einfüllt und schon läuft sie, wie im Prospekt beschrieben. Oft weichen die in der ERP-Standardsoftware hinterlegten Geschäftsprozesse von jenen Geschäftsprozessen ab, die gerade den Wettbewerbsvorteil des Kunden ausmachen. Selten ist die Systemlandschaft der jeweiligen Kunden heterogen und vergleichbar mit jener Systemlandschaft aller anderen Kunden. Die Schnittstellen, die zu anderen Systemen hergestellt werden müssen, können daher von Installation zu Installation anders und sehr individuell sein. Die jeweiligen Alt-Daten, die in das neue ERP-System übernommen werden sollen, liegen in verschiedenen Datenbanken mit unterschiedlichsten Datenformaten und sehr unterschiedlicher Datenqualität.

Und doch kaufen viele Kunden komplexe Enterprise-Standardsoftware immer noch wie Serienprodukte ein und wundern sich dann, wenn ihre Erwartungen enttäuscht werden. Dabei haben sie ihre jeweiligen Erwartungen jedoch nie klar spezifiziert, kommuniziert und für beide Parteien verständlich und nachprüfbar dokumentiert. Die unterschiedlichen Sichtweisen und Erwartungen treten deshalb dann erst im Projektverlauf zu Tage, meist unter Zeit- und Budgetdruck, wo es dann schwierig ist, die erforderlichen Einigungen noch nachzuholen. Der Konflikt ist in einer solchen Drucksituation bereits vorprogrammiert.

Kann man sich denn nicht aufs Gesetz verlassen

Leider nein. Die gesetzlichen Vertragstypen, die das BGB (Bürgerliches Gesetzbuch) für IT-Projekte vorsieht, sind Kaufvertrag, Werkvertrag, Dienstvertrag und evtl. noch Mietvertrag, wenn Liefergegenstände nur befristet überlassen werden. Ein spezielles gesetzliches IT-Vertragsrecht gibt es nicht. Vielmehr ist es Aufgabe der Gerichte und Anwälte, IT-rechtliche Fragestellungen mit dem Tool-Set, das das BGB auch für andere Geschäfte des täglichen Lebens anbietet, zu lösen. Die für einen Kaufvertrag nach dem Gesetz geltenden Regelungen sind stets die Gleichen, egal ob man ein Brötchen oder eine komplexe Enterprise Software kauft. Die sich daraus ergebenden Regelungslücken (z.B. welche Performance muss eine ERP-Standardsoftware haben, welche Mitwirkungsleistungen kann der Anbieter vom Kunden bei der Implementierung einer ERP-Software erwarten oder welche Nutzungsrechte sind denn im Preis enthalten) muss man entweder durch einen Vertrag regeln oder im Konfliktfalle hoffen, dass man mit dem Vertragspartner eine Einigung findet. Alternativ bleibt nur der Weg vors Gericht und das kann auch nur auf das BGB zurückgreifen.

Will man den Ausgang eines IT-Projekts planbar gestalten, hat der IT-Vertrag eine zentrale Bedeutung als Rechtsgrundlage für die Festlegung von Leistung und Gegenleistung. Bildlich gesprochen legt der IT-Vertrag rechtsverbindlich fest, ob der Kunde für den vereinbarten Preis einen Polo oder einen Porsche mit Vollausstattung verlangen kann.

Wie entstehen gute IT-Verträge

Gute IT-Verträge sind der Business-Plan des IT-Projekts. Ihre Aufgabe ist es, die kaufmännischen, technischen und organisatorischen Vorgaben für ein IT-Projekt in eine rechtliche Form zu gießen und so zu regeln, dass beide Parteien mit dem abgebildeten Geschäftsmodell zufrieden sind.

Verträge, die extrem einseitig sind oder durch trickreiche juristische Formulierungen die andere Vertragspartei benachteiligen, sind sicherlich nicht dazu geeignet, konfliktarme Geschäftsbeziehungen aufzubauen. Mit ihnen erreicht man in aller Regel das Gegenteil.
Interessenskonflikte in einer Kunden-Lieferanten-Beziehungen sind normal und mit der entsprechenden Erfahrung sind die kritischen Punkte, die üblicherweise bei IT-Projekten zu Konflikten führen, auch vorhersehbar. Deshalb ist es Aufgabe der Anwälte, zusammen mit den zuständigen Kaufleuten und Technikern, die Projektziele, den Projektablauf, die Projektorganisation und die Projektrisiken zu analysieren und dann gemeinsam jene kaufmännischen, technischen und juristischen Vorgaben zu definieren, die vom Juristen im Vertrag abzubilden sind.
Da jedes IT-Projekt seine eigenen Rahmenbedingungen hat, kann man existierende Vertragsmuster sicherlich als Checkliste und Gedächtnisstütze benutzen. Aber jedes IT-Projekt in ein und demselben Vertragsmuster abzubilden, ist ungefähr vergleichbar mit dem Versuch, alle Branchen und alle Unternehmen in ein und demselben ERP-Modul abzubilden.

Wird der Vertrag vom Vertragspartner gestellt, hat der Anwalt zusammen mit den zuständigen Kaufleuten und Technikern die im Vertrag abgebildeten kaufmännischen, technischen und juristischen Vorgaben daraufhin zu analysieren, ob sie mit der Erwartungshaltung der eigenen Firma übereinstimmen. Wenn nicht, sind die entsprechenden Punkte erst einmal inhaltlich mit der anderen Vertragspartei zu verhandeln, bevor dann noch über etwaige Formulierungsänderungen verhandelt wird.

Wie detailliert müssen Verträge sein

Das was im Gesetz steht, muss nicht nochmals im Vertrag geregelt werden. Nur dort, wo das Gesetz Lücken enthält oder abweichende Regelungen zulässt, sollte man vertragliche Regelungen im gewünschten Sinne formulieren. In welcher Regelungstiefe man die jeweiligen Rechte und Pflichten ausformuliert, hängt davon ab, wie konfliktträchtig die jeweils nicht geregelten Punkte sind und wie weit die beschriebenen Abläufe auch organisatorisch umsetzbar sind. Es macht z.B. keinen Sinn, ein ausgefeiltes Service-Level-System für die Fehlerbehebung der Standardsoftware zu spezifizieren, wenn der Anbieter die im Vertrag beschriebenen Prozesse in seiner Supportorganisation überhaupt nicht abbilden kann.

Lassen sich Punkte, die konfliktträchtig sind, nicht detailliert regeln, sollte der Vertrag Verfahrensregelungen vorgeben, wie im Streitfalle eine verbindliche Festlegung erfolgen kann. Dabei sollte man nicht vergessen, zu regeln, welche Entscheidungsinstanz die Festlegung vornimmt und mit welchen Funktionsträgern sie besetzt sein muss, damit eine nachhaltig Entscheidung, die von beiden Parteien akzeptiert wird, auch zustande kommt.

Welchen Nutzen bringen gute Verträge

Verträge die so, wie hier beschrieben, erstellt und verhandelt werden, sorgen dafür, dass beide Parteien mit demselben Erwartungshorizont an den Projektstart gehen. Alle erfolgskritischen Punkte werden bereits im Rahmen der Vertragsverhandlung besprochen und einer von beiden Parteien akzeptierten Regelung zugeführt. Darüber hinaus schaffen sie auf beiden Seiten Rechtssicherheit, und zwar auch dann, wenn im Projektverlauf Ansprechpartner ausgetauscht werden oder sich die Geschäftspolitik (z.B. nach Firmenübernahme) ändert.