Prof. Dr. Marc Strittmatter, Manuel Treiterer — Eine ERP-Einführung ist für die meisten Unternehmen eine der größten IT-Investitionsentscheidungen überhaupt. Der Auswahlprozess wird entsprechend sorgfältig vorbereitet: Anforderungen werden erhoben, Anbieter verglichen, Business Cases gerechnet, das Projekt auf der Zeitachse geplant. Und häufig wird ein Vertragswerk unterschrieben, das mit alldem oft nur begrenzt zu tun hat.

Genau hier entstehen die Konflikte, die Projekte später teuer machen. Aus einer großen Zahl begleiteter Verhandlungsprozesse mittlerer bis großer IT-Projektverträge, mit Projektvolumina zwischen 100.000 Euro und 50 Millionen Euro, lassen sich einige Erfolgsfaktoren benennen, von denen ich die aus meiner Erfahrung wichtigsten fünf kurz darstelle.

1. Die zentrale Frage vor jeder Unterschrift: Trägt der Vertrag die Investitionsentscheidung?

Der Business Case unterstellt einen Go-live-Termin, einen bestimmten Grad an Standardnutzung, einen kalkulierten internen Aufwand, einen Nutzen im Unternehmen. Tragen die Verträge diese Annahmen, auf denen die Investitionsentscheidung beruht? Das ist die Kernfrage, und sie ist überraschend selten sauber beantwortet. Wenn diese Annahmen im Vertrag nicht wiederkehren, existieren sie rechtlich nicht. Der Vertrag folgt dem Business Case, nicht umgekehrt.

Praktisch heißt das: Die tragenden Annahmen vor der Verhandlung schriftlich festhalten und anschließend Position für Position prüfen, ob sie vertraglich abgesichert sind. Eine saubere rechtliche Sachverhaltsermittlung bedeutet, dass man das Projektvorhaben danach analysiert. Wir arbeiten dazu mit Termsheets, die einige hundert Vertragsdatenpunkte abfragen.

2. Scope matters: Woran Projekte tatsächlich scheitern

Der häufigste Streitpunkt in ERP-Projekten ist nicht z.B. die Haftungsbegrenzungsklausel, sondern die Frage, was eigentlich geschuldet ist. Leistungsbeschreibungen entstehen aus Angeboten, Präsentationen und Workshop-Notizen, idealerweise aber aus einem strukturierten und detaillierten Lastenheft. Die Unterlagen sind oft umfangreich, aber selten eindeutig. Was im Vertriebsgespräch plausibel klang, lässt im Streitfall meist mehrere Lesarten zu.

Fünf Fragen, die vor Vertragsschluss beantwortet sein sollten:

• Welche Prozesse und Module sind Gegenstand der Einführung und welche ausdrücklich nicht?
• Wer verantwortet die Projektführung? Hilfe zur Selbsthilfe oder Führung des Anbieters?
• Wo verläuft die Grenze zwischen Standardfunktionalität und kostenpflichtiger Anpassung?
• Welche Mitwirkungsleistungen erwartet der Anbieter vom Kunden und in welchem Umfang?
• Wer verantwortet Datenmigration, Schnittstellen und Testdurchführung?

Ein gutes ERP-Vertragswerk liest sich streckenweise wie eine Bedienungsanleitung für den Ablauf des Projekts: Es beschreibt, wer was bis wann liefert und wie mit Abweichungen umgegangen wird. Verträge, die das leisten, werden im Projekt tatsächlich genutzt statt abgeheftet. Wer annimmt, dass Verträge für die „Schublade“ sind und nur im Streitfall hervorgeholt werden, vergibt sich ein effektives Steuerungsinstrument.

3. §§ = €€: Jede Klausel trägt ein Preisschild

In einem ERP-Einführungsvertrag ist nahezu jede Regelung preisschildfähig. Wer engere Termine, weitergehende Gewährleistungen oder höhere Haftungsgrenzen durchsetzt, verschiebt Risiko auf den Anbieter. Das ist ein Problem, wenn diese Optimierung zu einseitig ausfällt. Wird sie aber eingepreist, offen über den Preis oder verdeckt über Puffer im Aufwand, kann der Anbieter damit umgehen.

Daraus folgt kein Verzicht auf Absicherung, sondern Priorisierung. Bewährt hat sich eine klare Strukturierung der Verhandlungspunkte:

• A-Punkte: tragend für den Business Case. Ohne sie erreicht das Projekt seine Ziele voraussichtlich nicht.
• B-Punkte: wirtschaftlich erheblich, aber kompromissfähig.
• C-Punkte: üblich und wünschenswert, aber nicht um jeden Preis durchzusetzen.

Showstopper gehören an den Anfang der Verhandlung, nicht ans Ende. Wer sie aufschiebt, verhandelt später unter Zeitdruck. Die Ergebnisse dieser Verhandlung sind zufällig oder davon abhängig, wer zu einem bestimmten Zeitpunkt mehr Abschlussdruck hat. Und schließlich gilt es, den schmalen Grat zwischen Absicherung und Bürokratie zu halten: Ein Vertrag, der jede Eventualität regelt, wird im Projektalltag unpraktikabel. Je näher die Vertragssprache an der Projektrealität verläuft, desto nützlicher ist der Vertrag.

4. 80 Prozent eines IT-Vertrags sind kein Jura

Der größte Teil eines ERP-Vertrags ist Fachlichkeit: Prozessbeschreibungen, Mengengerüste, Rollenmodelle, Migrationskonzepte, Testverfahren. Das kann kein Anwalt aus sich heraus beurteilen. Fachberater sind deshalb zentral, sie kennen Prozesse, Markt und Anbieterlandschaft. Dazu korrelieren die Vergütungsmodelle: Kostendach, Festpreis, t&m, agiler Festpreis und die Frage, was eine Anforderungsänderung ist und was zum vereinbarten Scope gehört: Hier sollte die meiste Arbeit investiert werden und nicht in das Ausschmücken der „what if´s“ wie z.B. die Unterfallgruppen bei der Freistellung von Ansprüchen Dritter im Falle einer IP-Verletzung. In meinem ganzen Berufsleben bin ich keinem einzigen ERP-Anbieter begegnet, der zerknirscht zu seinem Kunden gehen musste, weil ein Dritter an der Software, die er dem Kunden überlassen hatte, Rechte geltend machte oder auch Softwareanbieter die direkt auf die Kunden zukamen, sodass das Thema Freistellung überhaupt relevant wurde. Natürlich kann das passieren, aber Stunden für die Verhandlung der Freistellungsklausel aufzuwenden, die besser in die Beschreibung von Leistung und der Vergütung dafür geflossen wären, ist bei einem begrenzten Kosten- und Zeitbudget wenig unternehmerisch gedacht.

Die juristische Begleitung ergänzt die fachlich-kommerzielle Perspektive: Sie überführt fachliche und kommerzielle Ergebnisse in belastbare Vertragssprache. Der Fachberater bleibt fachlicher Ansprechpartner, ohne als Rechtsberater zu haften.

Entscheidend ist auch der Zeitpunkt. Wer die juristische Seite erst einbindet, wenn der Anbieter feststeht und der Vertragsentwurf vorliegt, verhandelt über ein Dokument mit bereits festgelegter Grundstruktur und verschenkt einen erheblichen Teil des Spielraums.

5. Cloud-Verträge: Passen sie zum Projekt?

ERP-Einführungen laufen zunehmend in Cloud-Modellen. Neben Einführungs- und Dienstleistungsvertrag treten Subskriptions- und Serviceelemente, die stark standardisiert sind.

Die Frage ist, ob diese zum konkreten Projekt passen:

• Bilden die Service-Level die betriebliche Kritikalität des Systems ab, etwa bei Verfügbarkeit und Reaktionszeiten?
• Passen Laufzeit, Verlängerung und Kündigung zur geplanten Nutzungs- und angenommener Amortisationsdauer?
• Welche Preisanpassungsmechanismen greifen über die Laufzeit?
• Wie sind Datenzugang, Datenherausgabe und ein späterer Anbieterwechsel geregelt?
• Was passiert, wenn die Subskription bereits läuft, das System aber noch gar nicht produktiv ist? Gibt es ein ramp-up/ staged buying Modell?

Der letzte Punkt wird häufig übersehen und ist wirtschaftlich einer der unangenehmsten: Verzögert sich der Go-live, laufen die Lizenzkosten weiter, ohne dass ihnen ein Nutzen gegenübersteht. Ob und wie sich das vertraglich abfedern lässt, hängt vom Anbietermodell und der Verhandlungssituation ab.

Und nach der Unterschrift: vertragsnahes Projektmanagement

Ein Vertrag nützt nur, wenn er angewendet wird. In vielen Projekten kennen die operativ Verantwortlichen die Fristen, Abnahmeverfahren und Change-Request-Prozesse jedoch nur in Grundzügen. Sinnvoll sind daher eine Vertragsschulung zu Projektbeginn, das konsequente Nachhalten von Mitwirkungsleistungen und Meilensteinen sowie die schriftliche Dokumentation jeder Änderung am Leistungsumfang. Auch das finanzielle Controlling (Fortschritt gegen Leistungsnachweise gegen Budget) ist unabdingbar. Das ist zwar aufwändig, verbessert die Position aber erheblich, sollte es später zu Diskussionen kommen.

Fazit

Rechtliche Begleitung bei ERP-Projekten ist keine Formalie am Ende des Auswahlprozesses, sondern ein Instrument der Risikosteuerung. Ihre Wirkung entfaltet sie vor allem dann, wenn sie früh einsetzt, idealerweise bereits in der Auswahlphase. Kein Vertragswerk kann sämtliche Risiken einer ERP-Einführung ausschließen. Es kann aber dafür sorgen, dass Abweichungen früh sichtbar werden und im Zweifel klar ist, wer wofür einzustehen hat.

Im nächsten Beitrag dieser Reihe geht es um den Fall, den niemand einplant: Was tun, wenn das ERP-Projekt in Schieflage gerät, bei Verzögerungen, Mehrkosten und Streit über den Leistungsumfang?

Haben Sie Fragen?

Wenn Sie eine ERP-Einführung planen, mitten im Auswahlprozess stehen oder prüfen möchten, ob die vorliegenden Vertragsentwürfe die Annahmen Ihres Business Case tatsächlich absichern, unterstützen wir Sie gerne. Wir begleiten Unternehmen bei Vertragsanalyse und Anbietervergleich, bei der Verhandlung von ERP-, Cloud- und Implementierungsverträgen sowie bei der vertragsnahen Projektbegleitung bis zum Go-live.

Für Fragen zu ERP- und IT-Projektverträgen stehen Ihnen Prof. Dr. Marc Strittmatter und Manuel Treiterer zur Verfügung.

Einen Überblick über unsere Beratung finden Sie auf unserer Seite zu IT-Verträgen.