Jusletter IT

Der Mensch standardisiert gerne: Ist eine Technologie den Kinderschuhen entwachsen und über das experimentelle Stadium hinaus gekommen, setzt der Prozess der Standardisierung ein. Während die Standardisierung den Monopolrenten einzelner Marktteilnehmern abträglich sein kann, so ist sie für das Ganze volkswirtschaftlich sinnvoll, da sie die Effizienz erhöht und Transaktionskosten senkt. Dies gilt gerade für den IT-Bereich – ohne (offene) Standards wie etwa TCP/IP oder HTTP hätten sich die Informationstechnologien nicht so entwickeln können, wie sie es getan haben.

Es ist daher naheliegend, auch im Bereich der IT-Verträge eine Standardisierung vorzunehmen. Standardsoftware wird seit Jahrzehnten auf Basis standardisierter Lizenzbedingungen (über deren Geltung sich freilich trefflich streiten lässt – Stichwort shrink wrap licences) vertrieben und Cloud Provider bieten ihre Services auf Basis standardisierter AGB an. Ein individuelles Aushandeln derartiger Lizenz- und Vertragsbedingungen ist mit den Vertriebskonzepten für solche Leistungen nicht vereinbar und würde eine erhebliche Verteuerung bedeuten. Aber auch für individuelle Dienstleistungen haben die IT-Dienstleister (wie auch in anderen Branchen üblich) Vertragsbedingungen entwickelt. Mittelgroße bis große IT-Unternehmen vertrauen dabei auf selbst bzw mit anwaltlicher Unterstützung erstellte AGB, kleine IT-Unternehmen bedienen sich in Österreich vorwiegend der von der Wirtschaftskammer Österreich – Fachverband Unternehmensberater und Informationstechnologie zur Verfügung gestellten «Allgemeinen Bedingungen» (kurz «AB UBIT»). Aber auch die Kundenseite war nicht untätig: Ursprünglich unter Federführung von DI DDr. Walter Jaburek erstellt, kommen – vor allem, aber nicht nur im öffentlichen Bereich – diverse Allgemeine Vertragsbedingungen für Informationstechnologien (kurz «AVB-IT») zum Einsatz.

Die Verwendung Allgemeiner Vertragsbedingungen reduziert die Transaktionskosten der Begründung eines IT-Vertragsverhältnisses, da auf die Erstellung und Verhandlung eines konkreten Vertrages verzichtet wird. Man muss sich dabei jedoch vor Augen halten, dass mit zunehmender Standardisierung bei Beschaffungsvorhaben zwar die Kosten, aber auch die Möglichkeiten der Anpassung an die konkreten Bedürfnisse des Kunden abnehmen.

Mit diesem Beitrag wird anhand einiger Thesen untersucht, inwieweit Allgemeine Vertragsbedingungen für ein IT-Projekt brauchbar sein können und wo ihre Grenzen liegen. In diesem Sinne wird die Abkürzung «AVB» in der Folge als Überbegriff für Allgemeine Vertragsbedingungen verwendet, sei es dass sie von Auftraggeberseite oder von Auftragnehmerseite zum Einsatz kommen.

Nicht Gegenstand dieses Beitrages sind Standardbeschaffungen wie die Lieferung von IT-Endgeräten, die bloße Lizenzierung von Standardsoftware oder die Inanspruchnahme kostengünstiger standardisierter Cloud-Services, bei denen an AVB kein Weg vorbei führt.

Auch wenn man sich als IT-Vertragsverfasser damit ins eigene Fleisch schneidet, muss es gesagt werden: Weitaus wichtiger als ein guter IT-Vertrag ist eine gute Leistungsbeschreibung.¹ Das ABGB ist mit seinem vor kurzem erreichten Alter von 200 Jahren immer noch fit genug, die Rechte und Pflichten in einem komplexen IT-Projekt zu regeln, zur Not würde man daher (wenn auch mehr schlecht als recht) auch ohne einen Vertrag auskommen. Wenn jedoch das Leistungsbild nicht vernünftig definiert ist, hilft der beste Vertrag nicht: Die Risiken auf beiden Seiten und das Konfliktpotential (zumeist entsteht dies durch unterschiedliche Vorstellungen der Vertragspartner, die bei Vertragsabschluss noch verborgen sind und erst im Zuge des Projekts zutage treten) sind in diesem Fall enorm.

Wieso führen nun AVB zu einer schlechten Leistungsbeschreibung? Die gewissenhafte Erstellung eines IT-Vertrages geht immer mit einer gewissenhaften Prüfung der Leistungsbeschreibung einher:

Ist der Zeitplan konsistent mit dem Zahlungsplan?

Stehen den Zahlungen entsprechende nutzbare Arbeitsergebnisse gegenüber?

In welchen Projektabschnitten steckt die meiste Arbeit, muss der Auftragnehmer hohe Summen vorfinanzieren?

Wann müssen test- und abnahmereife Leistungen vorliegen?

Wo liegen die Projektrisiken, welcher Vertragspartner schultert welche Risiken und ist die Risikoverteilung konsistent mit dem Vertrag?

Wie konkret sind die einzelnen Leistungsbereiche definiert?

Was lässt die Leistungsbeschreibung offen bzw vertagt «zur näheren Definition» in das Projekt?

Was gilt, wenn man sich im Projekt nicht einigen kann?

Die Erstellung eines Projektvertrages zwingt die Vertragspartner dazu, sich mit diesen und einer Reihe weitere wesentlicher Fragen – die obige Aufzählung bildet nur einen kleinen Ausschnitt der Fragestellungen ab – auseinanderzusetzen. Werden dem Vertragsverhältnis unreflektiert AVB zugrunde gelegt, besteht das Risiko, dass diese Fragen unbeantwortet bleiben. Ein plakatives Beispiel dafür bietet die Entscheidung OGH 23.10.2012, 5 Ob 111/12b:² Die jenem IT-Projekt zugrunde liegenden AGB hatten die Vereinbarung eines Pflichtenheftes zwar vorgesehen, nur ist es nicht geschehen³ und zeigte sich dann im Prozess, dass die Parteien sehr unterschiedliche Vorstellungen vom Leistungsinhalt hatten.

Betrachtet man den Punkt 2.3 der AB UBIT Projekt, in dem sich folgender Passus findet:⁴

«Grundlage für die Erstellung von Individualprogrammen ist die schriftliche Leistungsbeschreibung, die der Auftragnehmer gegen Kostenberechnung aufgrund der ihm zur Verfügung gestellten Unterlagen und Informationen ausarbeitet bzw. der Auftraggeber zur Verfügung stellt. Diese Leistungsbeschreibung ist vom Auftraggeber auf Richtigkeit und Vollständigkeit zu überprüfen und mit seinem Zustimmungsvermerk zu versehen.»

unter diesem Gesichtspunkt, so zeigt sich, welch umfangreiche und für das Gelingen des Projekts wesentliche Leistungen ungeregelt bleiben, wenn man sich IT-vertragstechnisch auf die Zugrundlegung von AVB beschränkt.

Legt man einem Vertragsverhältnis AVB zugrunde, so kann man sie entweder unverändert belassen oder sie auf das Projekt abstimmen. Wenn auch die letztere Vorgehensweise zu begrüßen ist, führt sie zu einer Unübersichtlichkeit der Vertragsbestimmungen, da zumeist ein zusätzliches Dokument mit den abweichenden Regelungen zu den AVB erstellt wird. Das Risiko von Inkonsistenzen zu den weiteren Unterlagen, die das Vertragsverhältnis definieren, steigt damit ebenso wie die Komplexität der Aufgabe, Widersprüche anhand der Priorität der Geltung der Vertragsunterlagen aufzulösen.

Auch kann unklar sein, welche Teile der AVB überhaupt auf das konkrete Vertragsverhältnis anzuwenden sind, und zwar beispielsweise dann, wenn AVB unterschiedliche Regelungen für Standardsoftware und Individualsoftware vorsehen und im Projekt jedoch eine Standardsoftware (unter anderem) mittels Individualprogrammierung angepasst wird. Gerade in dieser Konstellation kann sich zudem die Frage stellen, welche AVB überhaupt gelten bzw zugrunde zu legen sind: So gelten die AVB IT Software Version 01/11 des Bundes nur für Projekte, bei denen nicht in den Source Code der Standardsoftware eingegriffen wird, wohingegen die AVB IT Projekt Version 01/11⁵ nur für die Beschaffung von Individualsoftware gelten.

AVB sind idR sehr einseitig formuliert, da mit ihnen die Absicht verfolgt wird, die zivilrechtlich vorgesehene Teilung von Rechten und Pflichten möglichst weit zugunsten einer Vertragspartei zu verschieben. Das führt dazu, dass dem Vertragspartner zusätzliche Risiken aufgebürdet werden. Kommen AVB auf Kundenseite zum Einsatz, haben sie zur Folge, dass sorgfältig kalkulierende Anbieter für diese Risiken entsprechende Aufschläge in ihre Angebotspreise einkalkulieren. Ist dies – beispielsweise aufgrund der Wettbewerbssituation im Vergabeverfahren – nicht möglich, so ist vom Vertragspartner aggressives Claim Management zu erwarten, um das Projekt über die Geltendmachung von Nachtragsforderungen in der Gewinnzone zu halten.

AVB, die nicht auf das konkrete IT-Projekt abgestimmt werden, bieten regelmäßig keine praktikablen Lösungen für Fragestellungen und Differenzen, die sich aus dem Projekt ergeben. Dies hat oft zur Folge, dass diese AVB bei der Projektumsetzung überhaupt ignoriert werden und erst im (seltenen) Streitfall vor dem Richter wieder eine Rolle spielen. Es kommt beispielsweise regelmäßig vor, dass eine vertraglich vorgesehene Source Code-Hinterlegung⁶ nicht erfolgt, womit dem Kunden auch im Herausgabefall der Zugriff verwehrt bleibt.⁷

Zweck eines IT-Vertrages sollte jedoch der Projekterfolg sein, sei es, dass unterschiedliche Interessenlagen und mögliche Differenzen schon im Zuge der Verhandlungen zu Tage treten und für beide Seiten akzeptable Regelungen gefunden werden, sei es, dass der Vertrag im Falle von Differenzen so klare Regelungen bereit hält, dass sich die Rechtslage beiden Vertragspartnern eindeutig darstellt.

Individualsoftwareentwicklung erfolgt zunehmend nicht mehr nach dem klassischen Wasserfallmodell, bei dem zunächst ein Pflichtenheft erstellt und nach dessen Abnahme die Software implementiert, getestet und abgenommen wird, sondern nach iterativen Vorgehensmodellen. Bei diesen Methoden der Softwareentwicklung wird zunächst ein rudimentärer Prototyp entwickelt, der dann in enger Zusammenarbeit mit dem Kunden in Entwicklungszyklen verbessert und erweitert wird. Dieses Vorgehen reduziert bestimmte Projektrisiken (beispielsweise ermöglicht sie eine bessere Projektsteuerung), eröffnet jedoch zusätzliche Risiken (zB das der nie erfolgenden abschließende Definition, sondern uferlosen Ausweitung des Scopes). Wird ein solches Vorgehensmodell gewählt, sind die vertraglichen Bestimmungen darauf abzustimmen.

AVB, die von einem Wasserfallmodell ausgehen, regeln die nach einem solchen Vorgehensmodell bestehenden wechselseitigen Rechte und Pflichten nicht adäquat. Aber auch die Ergänzung der AVB um Regelungen zur iterativen Softwareentwicklung ist aufgrund der Vielfalt dieser Vorgehensmodelle ein komplexes Unterfangen und stößt rasch an Grenzen.

Auch hier muss wieder die Entscheidung OGH 23.10.2012, 5 Ob 111/12b als Negativbeispiel herhalten. Die jenem Vertragsverhältnis zugrunde liegenden AGB hatten vorgesehen, dass dem Kunden die Auswahl der Software und die Erteilung der notwendigen Informationen oblag. Der OGH hat diese vom IT-Dienstleister relevierte Bestimmung mit dem Verweis verworfen, dass AVB nicht das vorvertragliche Schuldverhältnis regeln und die daraus erwachsenden Aufklärungsverpflichtungen des IT-Dienstleisters daher nicht vermindern können.

Der erkennende Senat hätte dies im Falle eines ausgehandelten Vertrages wohl nicht anders gesehen. Hätten die Parteien jedoch über die Vertragsbedingungen verhandelt, wäre ihnen die Problematik wahrscheinlich vor Vertragsabschluss bewusst geworden und es zu einer entsprechenden Aufklärung des Kunden gekommen (siehe die These unter Punkt 2.1).

Die Zugrundelegung von AVB ist zumeist Ausfluss von Marktmacht, sei es auf Seiten des IT-Dienstleisters (Beispiel SAP), sei es auf Seiten des Kunden (Beispiel Bundesbeschaffung GmbH). Verkaufs- bzw Einkaufsmacht verleitet dazu, AGB sehr einseitig zu formulieren und Vertragsbedingungen darin aufzunehmen, die den Vertragspartner gröblich benachteiligen. Das besondere Risiko besteht dabei darin, dass ein und dieselbe Vertragsbestimmung nicht in jedem Vertragsverhältnis gröblich benachteiligend sein muss, sondern sich nur in einem bestimmten Kontext – zB in Zusammenspiel mit einer bestimmten Leistungsbeschreibung – als gröblich benachteiligend herausstellen kann, zumal das Gericht bei der Prüfung eine umfassende, die Umstände des Einzelfalls berücksichtigende Interessensabwägung vorzunehmen hat.⁸ Bei Erkennbarkeit eines entsprechenden hypothetischen Parteiwillens bleibt eine bloß teilweise unzulässige Vertragsklausel mit ihrem zulässigen Inhalt aufrecht (geltungserhaltende Reduktion), wozu die allgemein üblichen salvatorischen Klauseln beitragen sollen.⁹

Weiter steigt mit zunehmender Abstraktion das Risiko, dass eine Vertragsbestimmung im Falle einer Auseinandersetzung als «undeutliche Äußerung» qualifiziert wird, die nach § 915 ABGB zum Nachteil desjenigen ausgelegt wird, der sich ihrer bedient hat. Diese Regelung hat gerade bei Allgemeinen Geschäftsbedingungen große praktische Bedeutung.¹⁰

Im IT-Projektgeschäft können AVB die Ausgangsbasis für einen guten Vertrag bilden, nicht aber der Vertrag selbst sein. Gute Vertragsbedingungen, die nicht gröblich benachteiligend oder sittenwidrig sind, sind als Bausteine für die Erarbeitung eines auf die Anforderungen des Projekts abgestimmten IT-Vertrags nützlich. Denn auch IT-Projektverträge entstehen nicht aus dem Nichts, sondern basieren auf vorhandenen Vertragsmustern. Mit der unreflektierten Zugrundelegung von AGB legt man jedoch keine gute Grundlage für sein IT-Projekt.

Allgemeine Bedingungen der Wirtschaftskammer Österreich – Fachverband Unternehmensberater und Informationstechnologie für IT-Leistungen, abrufbar unter www.wko.at

Allgemeine Vertragsbedingungen der Republik Österreich für IT-Leistungen (AVB-IT), abrufbar unter www.bbg.gv.at

Holzinger, Beurteilung von Softwarequalität im Hinblick auf Vertragserfüllung und Gewährleistung, EDVuR 1994, 38

Jaburek, Handbuch der EDV-Verträge Band 1³ (2000)

Koziol/Bydlinski/Bollenberger, Kommentar zum ABGB³ (2010)

Staudegger, Software-Erstellung: Vertragstyp und Quellcodeherausgabe, JBl 2006, 195

Staudegger, Rechtsfragen bei Individualsoftware (1995)

OGH 23.10.2012, 5 Ob 111/12b: Softwareanpassung – vorvertragliche Aufklärungspflicht des Auftragnehmers, Medien und Recht 7-8/12

 

---

 

Ralf Blaha, Rechtsanwalt, Heid Schiefer Rechtsanwälte

 

---