Von Michael Bartsch*

Gute ERP-Verträge werden nicht mit Schere und Leim aus Vorlagen zusammengestellt. Um mit überschaubarem Aufwand zu einem vernünftigen Vertrag zu kommen, müssen die Projektverantwortlichen einige Grundregeln beachten.

Nutzung von Allgemeinen Geschäftsbedingungen (AGB)

Auftragnehmer eines ERP-Projektes versuchen häufig, den Vertrag ihren allgemeinen Lieferbedingungen zu unterwerfen. Große Unternehmen haben ihrerseits allgemeine Einkaufsbedingungen für IT-Leistungen. Derjenige, dem fremde AGB gestellt werden, hat mehrere Handlungsoptionen:

AGB akzeptieren

Die Akzeptanz der fremden AGB ist die richtige Entscheidung, wenn Auftragswert und Risiko gering oder Krisen unwahrscheinlich sind, so dass sich Verhandlungen nicht lohnen. Gleiches gilt, wenn die fremden AGB akzeptabel sind oder Verhandlungen wegen der unterschiedlichen Marktmacht der Beteiligten von vornherein keine Aussicht auf Erfolg versprechen.

Neu verhandeln - gesamten Vertrag oder nur Details?

Es gibt zwei Wege die allgemeinen Geschäftsbedingungen zu ändern: Die umfassende Verhandlung des gesamten Vertrags und die teilweise Verhandlung nur über die kritischen Klauseln.

Verhandelt das Anwenderunternehmen umfassend, hält es am Ende einen Individualvertrag in Händen. Das hat Nachteile, denn der gesetzliche Schutz des AGB-Rechts geht auch für jene Klauseln verloren, die im Zuge der Verhandlungen unverändert bleiben.

Für denjenigen, dem die AGB gestellt wurden, ist die nur teilweise Verhandlung daher in der Regel günstiger. Sie sollte sich auf nachteilige wirksame (oder möglicherweise wirksame) Klauseln beschränken. Dafür muss man allerdings die Klausel rechtlich analysieren. Hierfür ist die Hilfe eines IT-Rechtsexperten notwendig.

Eigene Bedingungen entgegenstellen

Stellt der Verhandlungspartner den fremden AGB eigene gegenüber, so sind alle Klauseln beider AGB-Texte unwirksam, die nicht übereinstimmen. Wo nur ein AGB-Text eine Frage regelt, ist diese Regelung wirksam, es sei denn, der andere AGB-Text enthält eine Kollisionsklausel, wonach fremde AGB nicht gelten. An die Stelle unwirksamer Klauseln treten, soweit vorhanden, die Regelungen des Gesetzes.

Individuelle Vertragsgestaltung

Einen individuellen Vertrag zu entwerfen ist schwieriger und aufwändiger, als auf fertige Formulare zurückzugreifen. Individuelle Verträge bieten jedoch beiden Parteien die Möglichkeit, das wirtschaftlich-technisch Gewollte konkret zu regeln. In manchen Fällen kann man sich an den etablierten Standardverträgen orientieren. Beispiele hierfür sind EVB (Ergänzende Vertragsbedingungen für die Beschaffung von IT-Leistungen) und BVB (Besondere Vertragsbedingungen für die Beschaffung von DV-Leistungen), die jedoch beide zu Lasten von Auftraggebern ungewöhnlich weitgehende Haftungsbeschränkungsklauseln enthalten.

Beide Parteien sollten den Aufwand der Vertragsgestaltung an die Bedeutung und das wirtschaftliche Risiko des Projekts anpassen.

Ausgangspunkt einer individuellen Vertragsgestaltung ist die Position des Auftraggebers. Er muss klären, welche organisatorischen Ziele und wirtschaftlichen Verbesserungen er mit der Software erreichen will. Daraus lassen sich Maßnahmen ableiten. Diesem Wunschkatalog müssen Einschränkungen durch Zeitplan, Finanzen, Stand der Technik und Marktgegebenheiten entgegengestellt werden. Daraus ergibt sich das Pflichtenheft. Nach verbreiteter Auffassung ist ein Pflichtenheft Teil des Softwareprojekts, fällt also zumindest in seinem technischen Aspekt in den Verantwortungsbereich der Softwarefachleute und nicht, wie manche meinen, der Juristen. Aus den technischen Vorgaben sind die rechtlichen Regelungen des Vertrags abzuleiten.

Brennpunkte der Vertragsgestaltung

Beauftragt ein Unternehmen ein Softwarehaus damit, ein ERP-System zu liefern, anzupassen und zu installieren, so steht die Lösung bei Auftragserteilung meist noch nicht in allen Einzelheiten fest. Das endgültige Softwaresystem entsteht erst in Form eines verbindlichen Feinkonzepts und ist Teil des Projekts. Es sind daher Verfahrensregeln im Vertrag erforderlich, die nicht klären, was die Parteien schaffen, sondern wie sie kooperieren wollen.

Projektorganisation

Der Auftraggeber sollte den an der Kooperation beteiligten Menschen besondere Aufmerksamkeit widmen. Ratsam ist, im Vertrag die zuständigen Personen und ihre jeweiligen Funktionen zu benennen und zu regeln, wie Teammitglieder ausgetauscht werden können. Gleiches gilt für die Qualifikationen der Mitarbeiter. Es kann beispielsweise wichtig sein, dass es sich um Angestellte des Softwarehauses handelt (schon wegen der bei freien Mitarbeitern unklaren Zuordnung der Rechte am Arbeitsergebnis). Wichtige Entscheidungen, insbesondere die Eskalation von Streitfragen, werden bei umfangreicheren Projekten in der Regel durch Projektgremien (Projektleitung, Lenkungsausschuss) entschieden.

Doch auch der Auftraggeber muss qualifiziertes, engagiertes und mit der notwendigen Zeit ausgestattetes Personal für das Projekt bereitstellen. Softwarehäuser sollten hier genaue Vorgaben machen.

Einvernehmen über erbrachte Leistungen

Projekte sind in zeitliche Abschnitte einzuteilen, die wohldefinierten Leistungspunkten (Meilensteinen) entsprechen. An diesen Zeitpunkten findet eine Rückschau ("Haben wir das Richtige erreicht?") und eine Vorschau ("Was soll nun geschehen?") statt. Das Softwarehaus braucht Einvernehmen im Sinne von Freigaben in bezug auf die erbrachten Leistungen. Solche Freigaben sind allerdings keine Abnahmen im rechtlichen Sinne. Der Vorbehalt, dass der Auftraggeber bei einer solchen Prüfung nicht alle Details erkennen kann und nur als Laie prüft, bleibt stets offen.

"Wer schreibt, der bleibt"

Alle Besprechungen und sonstigen für das Projekt relevanten Sachverhalte sind zu protokollieren. "Wer schreibt, der bleibt" ist eine alte Weisheit aus der Projektführung. Es empfiehlt sich, solche Protokolle verbindlich zu machen, indem man sie dem Vertragspartner zuschickt und ihm für eventuelle Einwendungen eine Frist (beispielsweise eine Woche) setzt.

Zumutbare Änderungen

Der Auftraggeber braucht ein Recht, Änderungen und Ergänzungen der Leistungen zu verlangen. Natürlich nicht unbegrenzt, sondern in einem für das Softwarehaus zumutbaren Rahmen. Doch Vorsicht: Für diesen häufig "Change Request" genannten Vorgang gibt es oft Regelungen, die darauf hinauslaufen, dass es bei den alten Gegebenheiten bleibt, wenn die Parteien sich nicht auch über einen neuen Zeitplan und eine Vergütung für die neuen Anforderungen einigen. Das ist für den Auftraggeber unzumutbar, denn damit würde bewusst unpassende Software erstellt. Über die Vergütung kann notfalls später bei Gericht entschieden werden. Darum sollte das Änderungsrecht des Auftraggebers im Kern unangetastet bleiben.

Rechte an der Software

Der Auftraggeber erwirbt mit der Kopie der Software das Recht, diese in seinem Unternehmen, gegebenenfalls auch im Konzern, zu nutzen. Häufig ist der Umfang der Nutzung begrenzt, etwa durch Festlegung der Anzahl oder Größe der Rechner, auf denen die Software laufen darf, oder der Anzahl der Nutzer, die mit der Software arbeiten dürfen (Concurrent-User- oder Named-User-Lizenzen). AGB-rechtlich und urheberrechtlich sind diese Klauseln nicht ohne Probleme. Bei ihrer Formulierung ist besondere juristische Vorsicht geboten.

Die in vielen Softwareverträgen anzutreffende langatmige, juristische Umschreibung der Rechte des Auftraggebers an der Software erweist sich oft als untauglich. Besser ist es, der Anregung des Gesetzes zu folgen und lediglich den Nutzungszweck, die in Paragraf 69 d Abs. 1 Urheberrechtsgesetz (UrhG) genannte "bestimmungsgemäße Nutzung", zu definieren. Diese Definition kann umgangssprachlich, konkret auf den Lebenssachverhalt bezogen, erfolgen. Der Erwerber bekommt dann alle die Rechte, die er benötigt, um das Produkt zu nutzen.

Abnahme und Werklohn

Die Abnahme ist eine rechtlich und wirtschaftlich bedeutsame Zäsur im Rahmen der Projektrealisierung. Bei der Abnahme erklärt der Auftraggeber, dass er das Leistungsergebnis als im Grundsatz vertragsgemäß billigt. Mit der Abnahme wird der Werklohn fällig und beginnt die Gewährleistungszeit. Es ist für beide Vertragspartner sachgerecht, das Verfahren der Abnahme zu formalisieren.

Gewährleistung

Unter dem Begriff Gewährleistung werden die Pflichten des Auftragnehmers im Falle von Sach- und Rechtsmängeln nach Abnahme zusammengefasst.

Kauf- oder Werkvertrag?

Besonderes Augenmerk gilt hier der Art, wie der Vertrag zum Kauf- oder Werkvertragsrecht zugeordnet wird. Bei komplexen Softwareprojekten wie einer ERP-Einführung tun die Parteien regelmäßig gut daran, die Gewährleistungsregeln (Abnahme, Verjährung, Nachbesserung und Nachlieferung) an den gesetzlichen Bestimmungen des Werkvertragsrechts zu orientieren. Ob dies jedoch in allen Fällen der AGB-Kontrolle standhält, ist offen.

Untersuchungs- und Rügepflicht

Das Kaufrecht sieht für Kaufleute in Paragraf 377 des Handelsgesetzbuchs (HGB) eine Untersuchungs- und Rügepflicht vor. Für ERP-Projekte ist eine solche Untersuchungs- und Rügepflicht ungeeignet, da sie den Auftraggeber dazu zwingt, pausenlos vermeintliche Mängel zu rügen, um seine Gewährleistungsrechte nicht zu verlieren. In der Praxis schafft dies aber nur Streit. Eine Einschränkung der Untersuchungs- und Rügepflicht ist in Individualverträgen uneingeschränkt, in AGB begrenzt möglich.

Gewährleistungsfrist

Für Sachmängel ist die gesetzliche Verjährungsfrist von zwei Jahren angemessen. Bei Rechtsmängeln (Beispiel: Der Lieferant hat die urheberrechtlichen Befugnisse nicht, die er vertragsgemäß auf den Auftraggeber übertragen soll) ist diese Frist unzureichend. Auftraggeber tun gut daran, eine angemessene Verlängerung dieser Frist zu verlangen.

Die Klauseln in Formularverträgen der Softwarehäuser zur Verkürzung der Gewährleistungszeit sind zumeist unwirksam.

Reaktionszeiten und Verfügbarkeit

Sobald der Auftraggeber die Software operativ nutzt, legt er großen Wert auf deren Verfügbarkeit. Damit Mängel rasch beseitigt werden, können Reaktionszeiten (Zeit, die zwischen einer Fehlermeldung und dem Beginn der Fehlerbehebungsmaßnahmen verstreicht) und die Verfügbarkeiten (Anteil eines Zeitraumes, während dessen die Software funktionieren muss) vereinbart werden.

Sinnvollerweise wird man die Softwarefehler in Fehlerklassen einteilen (etwa in betriebsverhindernde, betriebsbehindernde und sonstige Fehler) und die Gewährleistungspflichten des Auftragnehmers danach richten. Vereinbaren beide Seiten Verfügbarkeitsquoten, so ist es sinnvoll, zusätzlich die längste zugelassene Ausfallzeit festzulegen, um unangemessen lange Ausfallzeiten zu vermeiden. Gibt der Hersteller beispielsweise eine Verfügbarkeitszusage von 97,5 Prozent pro Jahr ab, kann die Software mehr als neun Tage am Stück stillstehen.

Haftung

Bei allen Vertragsverhandlungen gibt es Debatten über die Haftung. Softwarehäuser können eine wirksame Begrenzung der Haftung nur durch individuelle Vereinbarung erreichen; eine wirtschaftlich relevante Haftungsbegrenzung in AGB scheitert an den engen Grenzen des AGB-Rechts. Softwarehäuser sollten daher keine Haftungs-AGB vorgeben. Sie sollten lediglich einen Formulierungsrahmen zur Verfügung stellen, der in der Verhandlung ausgefüllt werden muss. Dies kann ein einfacher Haftungshöchstbetrag sein (außerhalb der Fälle, in denen zwingend darüber hinaus gehaftet werden muss) oder eine nach Art des Schadens und Grad des Verschuldens differenzierte Vereinbarung.

Pflegeverträge

Auftraggeber sollten die Pflegeverträge parallel mit den Lieferverträgen verhandeln und abschließen. Nur vor Abschluss des Liefervertrages hat der Auftraggeber eine hinreichend starke Verhandlungsposition.

Die Bedeutung des Pflegevertrages ist für den Auftraggeber größer als für den Auftragnehmer. Für das Softwarehaus ist dieser Pflegevertrag ein Vertrag unter vielen, für den Kunden dagegen das unersetzliche Mittel, um auf Dauer den Nutzen aus der hohen Softwareinvestition zu ziehen. Dem sollte bei der Festlegung der Laufzeiten des Pflegevertrages Rechnung getragen werden. Ob nur der Auftragnehmer oder beide Parteien langfristig vertraglich gebunden sein sollen, ist Verhandlungssache. Zu denken ist auch an eine Hinterlegung des Quellcodes für den Fall, dass der Auftragnehmer seinen Pflichten aus dem Pflegevertrag nicht mehr nachkommen kann oder will.

Schlichtungsverfahren

Eine gute Hilfe im Falle von Projektkrisen ist das Schlichtungsverfahren der Deutschen Gesellschaft für Recht und Informatik e. V. (www.dgri.de). Es besteht seit 1988 und konnte in vielen Fällen zur Wiederaufnahme des Projekts oder zu einer raschen außergerichtlichen Lösung beitragen. (fn)