Was Unternehmen bei Verträgen zur Systemintegration beachten müssen

In a nutshell: Systemintegrationsprojekte bringen Technik, Software und Organisation zusammen – aber häufig auch rechtliche Risiken. Dr. Maximilian Dorndorf (Partner, Co-Head Industry Group Mobility & Logistics) und István Fancsik, LL.M. (Senior Associate, Solicitor England & Wales), beide Rechtsanwälte der Luther Rechtsanwaltsgesellschaft mbH, erklären, worauf es in der Praxis ankommt: vom passenden Vertragstyp über saubere Leistungsbeschreibungen bis hin zu messbaren KPIs. Sie zeigen, wie klare Regeln und dokumentierte Prozesse Konflikte vermeiden und Projekte absichern.

even: Bevor wir auf konkrete Herausforderungen eingehen: welche Vertragsarten begegnen Ihnen in der Praxis eigentlich am häufigsten bei Systemintegrationsprojekten? Und wo liegen dabei die größten Unterschiede?

Wie man den Vertrag nennt, ist nicht entscheidend. Maßgeblich ist immer die jeweilige Leistung, die mit dem Vertrag abgebildet werden soll. Systemintegrationsprojekte sind in der Praxis sehr komplex und haben vielfältige Anforderungen. Verträge können je nach Ausgestaltung sowohl werkvertragliche als auch dienstvertragliche Elemente haben, sind aber in der Regel sogenannte typengemischte Verträge, die unterschiedliche Vertragselemente miteinander vereinen.

Ein Werkvertrag verpflichtet den Auftragnehmer, einen bestimmten Erfolg zu erzielen. Der Kunde kann also den Eintritt dieses (Leistungs-)Erfolgs verlangen – etwa bei der Implementierung einer bestimmten Softwarelösung mit definierten Funktionalitäten oder der Integration verschiedener IT-Systeme zu einem funktionsfähigen Gesamtsystem. Das Risiko des Nichterfolgs trägt grundsätzlich der Auftragnehmer. Typisch für einen Werkvertrag ist, dass eine erfolgreiche Abnahme – also ein Funktionstest – erforderlich ist, um die Vergütungsansprüche des Auftragnehmers auszulösen. Zudem hat der Kunde bei Mängeln Gewährleistungsrechte.

Ein weit verbreiteter Irrglaube ist, dass ein Dienstvertrag nur „Mühe geben“ bedeutet. Zwar wird dabei lediglich die Tätigkeit als solche geschuldet, nicht aber ein bestimmter Erfolg. Das Risiko des Nichterreichens eines Leistungsziels trägt somit der Kunde. Dennoch schuldet der Auftragnehmer fachkundige Leistung, und in der Praxis sind diese oft auch mit messbaren Erfolgskriterien verbunden – etwa bei begleitender Beratung, Schulung oder Supportleistungen. Es bestehen jedoch – im Gegensatz zum Werkvertrag – grundsätzlich keine Gewährleistungsrechte. Das heißt aber nicht, dass der Auftragnehmer inakzeptabel schlechte Leistung erbringen darf. In solchen Fällen kann er sich nämlich dennoch schadensersatzpflichtig machen.

Verträge über die Entwicklung und Einführung von Individualsoftware – einschließlich anschließender Wartung und Support – enthalten regelmäßig sowohl werkvertragliche als auch dienstvertragliche Elemente. Somit sind solche Verträge typengemischt. Daneben können auch kaufvertragliche Elemente hinzukommen, wenn der Auftragnehmer etwa zusätzlich Hardware liefert.

Die Abgrenzung zwischen den einzelnen Vertragselementen ist in der Praxis häufig schwierig und hängt maßgeblich von der tatsächlichen Ausgestaltung des Vertrages sowie der Vertragsdurchführung ab. Wichtig ist: Die Bezeichnung des Vertragstyps ist letztlich irrelevant, entscheidend ist der tatsächliche Vertragsinhalt. Diese Einordnung hat erhebliche Auswirkungen auf Haftung, Gewährleistung und Vergütungsansprüche. Eine sorgfältige vertragliche Gestaltung unter Berücksichtigung dieser Kriterien ist daher unerlässlich für eine rechtssichere Durchführung von Systemintegrationsprojekten.

even: Viele Streitigkeiten entstehen ja, weil Erwartungen nicht klar geregelt sind. Wie lässt sich der Leistungsumfang eines Projekts so definieren, dass es später keine Missverständnisse gibt, zum Beispiel zwischen Projekt, Support und Service?

Der Leistungsumfang in Systemintegrationsverträgen lässt sich abgrenzen, indem der Leistungsgegenstand so eindeutig und vollständig wie möglich beschrieben wird und ebenso klar geregelt wird, was nicht geschuldet ist. Idealerweise vereinbaren die Parteien den Leistungsgegenstand verbindlich in einer Leistungsbeschreibung, die Bestandteil des Vertrags wird.

Die häufige Unterteilung in „Lastenheft“ und „Pflichtenheft“ ist rechtlich eher wenig hilfreich und führt häufig zu Verwirrung. In der Praxis werden Elemente beider meist in einem Dokument zusammengeführt, das als Leistungsbeschreibung in den Gesamtvertrag aufgenommen wird. Diese Leistungsbeschreibung dient auch der klaren Zuweisung von Verantwortlichkeiten und minimiert Interpretationsspielräume.

Daher sollte in der Leistungsbeschreibung – im Sinne von Klarheit und Zuordnung zu einem Vertragstyp – explizit eine Trennung von Projekt-, Support- und Serviceleistungen erfolgen. Eine präzise Leistungsbeschreibung ist nicht nur für die Vertragserfüllung, sondern auch für Haftungsfragen und die Begrenzung von Schäden entscheidend.

Zudem sollte die Verantwortlichkeit einzelner Projektbeteiligter im Vertrag klar geregelt werden. Wichtig ist auch, dass für Änderungen des Leistungsumfangs klare Regeln vereinbart werden – meist über ein vertraglich festgelegtes, strukturiertes Change-Request-Verfahren.

even: Und wenn es dann trotzdem zu Konflikten kommt: Welche Streitpunkte sehen Sie in der Praxis immer wieder und wie ließen sich die eigentlich vermeiden?

In Systemintegrationsverträgen kommt es häufig zu Streit über unklare Leistungsbeschreibungen, also darüber, was genau geschuldet ist oder welche Mitwirkungspflichten bestehen.

Ein weiterer häufiger Streitpunkt betrifft das Qualitätsmanagement: Oft fehlen klare Regeln zur Qualitätssicherung – etwa dazu, wie Leistungsergebnisse getestet werden sollen. Selbst wenn der Vertrag klare Leistungsbeschreibungen enthält, verlieren diese an Wert, wenn nicht festgelegt ist, wie die Parteien testen und sicherstellen können, dass das System tatsächlich das kann, was es nach der Leistungsbeschreibung können soll.

Ein drittes Problem betrifft das Projektmanagement und die operative Umsetzung: Selbst bei rechtlich gut funktionierenden Verträgen halten sich die Parteien im Projektalltag häufig nicht an die vertraglichen Vereinbarungen. Das ist auch ein häufiger Grund, warum IT- oder Automatisierungsprojekte scheitern oder kostenmäßig aus dem Ruder laufen.

even: In vielen Projekten sind Hersteller, Integrator und Betreiber involviert. Wer trägt im Zweifel die Verantwortung, wenn etwas schiefläuft?

Wenn mehrere Parteien beteiligt sind, haften sie grundsätzlich dann, wenn sie den Schaden verschuldet haben – etwa durch eine fehlerhafte Leistung. Der Integrator haftet etwa für Fehler bei der Zusammenführung der Komponenten, der Betreiber für Fehler im laufenden Betrieb.

Der Hersteller wiederum haftet für einen vom Produkt verursachten Schaden, und zwar unabhängig davon, ob er den Schaden verschuldet hat. Wenn mehrere Parteien haften, kann sich der Geschädigte grundsätzlich an jeden von ihnen wenden und den vollen Schaden ersetzt verlangen.

Wer die Kosten letztlich trägt, hängt davon ab, wer den Fehler hauptsächlich verursacht hat. Das wird intern zwischen den Beteiligten geregelt. In der Regel auf Grundlage der bestehenden Verträge, die meist spezielle Haftungsregeln enthalten.

In der Praxis lässt sich eine klare Verantwortung häufig nicht ermitteln – das ist ähnlich wie bei komplexen Bauprojekten. Deshalb ist es umso wichtiger, dass im Projekt gut dokumentiert wird.

even: Kommen wir zu einem Punkt, der in fast jedem Projekt eine Rolle spielt: KPIs. Wie konkret müssen Leistungskennzahlen formuliert sein, damit sie nicht nur steuernd wirken, sondern auch rechtlich belastbar sind?

Einfach und für Nicht-Juristen messbar, also idealerweise mit Kalender und Taschenrechner und, wo möglich, mit einer Beispielsrechnung im Vertrag. KPIs sind vertraglich vereinbarte Leistungskennzahlen und ein wesentliches Element für Steuerung, Kontrolle und Sanktionierung der Leistungserbringung im IT-Projekt. Sie müssen deshalb so formuliert sein, dass sie für alle Beteiligten klar, verständlich und messbar sind.

Besonders wichtig ist: KPIs müssen so genau beschrieben werden, dass sie objektiv messbar und technisch nachvollziehbar sind. Dazu gehören auch Parameter, wie die Messgröße sowie deren Einheit (zum Beispiel durchschnittliche Zahl an Mängeln pro System bzw. Teilsystem innerhalb eines bestimmten Zeitraums), das Messverfahren (zum Beispiel Ermittlung aufgrund dokumentierter Fehlerberichte), ein Referenzzeitraum (etwa monatlich oder quartalsweise) sowie Verantwortlichkeiten, etwa für die Erhebung und Dokumentation von Leistungskennzahlen.

Zudem müssen im Vertrag auch die Folgen einer KPI-Unterschreitung oder ggf. -Übererfüllung geregelt werden – etwa durch Sonderkündigungsrechte, Vertragsstrafen oder Bonus-/Malus-Regelungen. Sofern solche Regelungen in Standardverträgen verwendet werden, sollten dabei AGB-rechtliche Themen unbedingt mitbedacht werden, um eine Unwirksamkeit zu vermeiden.

even: Und was gehört aus Ihrer Sicht zu den Mindestanforderungen, damit KPIs im Zweifel gerichtsfest werden?

Unklare oder schwammig formulierte KPI-Regelungen bergen das Risiko, dass sie rechtlich nicht durchgesetzt werden können. Eine einfache Sprache und konkrete Beispiele helfen, Missverständnisse zu vermeiden. Einerseits müssen KPIs also präzise und verständlich beschrieben sein, andererseits müssen die Messergebnisse im Streitfall beweisbar sein.

Dazu muss festgelegt und dokumentiert werden, was gemessen wird, wie die Messung abläuft und wer dafür sowie für die Dokumentierung verantwortlich ist. Ein häufiger Fehler besteht darin, dass die Messung nicht nur die Anlage selbst, sondern zusätzliche Faktoren – etwa den Faktor Mensch – erfasst.

Deshalb sollten die Parteien objektiv nachvollziehbare, nicht manipulierbare Messmethoden vereinbaren, etwa durch automatisierte Messprotokolle. Am besten orientiert man sich an anerkannten technischen Standards wie DIN- oder ISO-Normen. Außerdem sollten die Parteien Abweichungen von den vereinbarten Messzielen sofort dokumentieren und einander kommunizieren, um Gegenmaßnahmen schnellstmöglich einleiten zu können. Wichtig ist auch, dass Messergebnisse über einen angemessenen Zeitraum, in der Regel mindestens bis zum Ablauf der gesetzlichen Verjährungsfristen, aufbewahrt werden. Dies ermöglicht den Nachweis, sollte es zum Streitfall kommen.

even: Ein weiteres zentrales Thema sind Abnahmen und Tests. Wie lassen sich solche Prozesse (z.B. FAT/SAT) im Vertrag so verankern, dass sie auch tatsächlich verbindliche Meilensteine darstellen?

Test- und Abnahmeprozesse dienen der Qualitätssicherung. Sie sind daher ein unerlässlicher Bestandteil jedes komplexeren Projekts, egal ob Intralogistiksystem, IT-System oder bauliche Anlage. Sie sichern nicht nur die Erreichung von Projektmeilensteinen, mit denen das Projekt operativ in die nächste Phase gebracht wird, sondern lösen auch Zahlungspflichten aus. Zudem stellen regelmäßige und formal dokumentierte Tests auch die Qualität und Funktionalität des Systems sicher.

Abnahmebedingungen sollten daher im Vertrag klar geregelt und mit den vereinbarten Leistungsspezifikationen verknüpft werden. Nur so kann sichergestellt werden, dass das System die vereinbarten Qualitätskriterien erfüllt und hieran geknüpfte Meilensteine erreicht werden.

Damit Meilensteine verbindlich sind, muss deren Erreichung eindeutig und objektiv beschrieben werden. Die Abhängigkeit von einer gemeinsamen Bestätigung beider Parteien ist keine gute Idee, wenn kein objektives Lösungsverfahren, etwa eine Prüfung durch einen Sachverständigen, vorgesehen ist.

even: Und wenn es um Bonus- oder Malus-Regelungen geht: welche Formulierungen haben sich in der Praxis bewährt?

Je einfacher und mathematischer, desto besser, also am besten mit Zahlen und Berechnungen statt nur mit reiner Sprache. Wichtig ist, dass Bonus-/Malus-Regelungen klar und verständlich formuliert sind. Die Berechnung sollte transparent und nachvollziehbar sein, durch feste Formeln und idealerweise mit Beispielsrechnungen.

Bei Mehrfachverwendung in Standardverträgen ist darauf zu achten, dass die Klauseln dem AGB-Recht standhalten. Überraschende, unangemessene oder unklare Formulierungen können sonst unwirksam sein. In der Praxis bewährt haben sich Formulierungen, die sowohl technische als auch wirtschaftliche Ziele einbeziehen, aber auch Sonderfälle, wie höhere Gewalt berücksichtigen.

even: Gibt es bei Vertragsstrafen oder Boni rechtliche Grenzen, die Unternehmen kennen sollten?

Einerseits müssen in Standardverträgen die Beschränkungen des AGB-Rechts beachtet werden. Andererseits dürfen die Parteien einander keine derart übertriebenen oder einseitigen Pflichten auferlegen, die rechtlich als sittenwidrig gelten könnten. Wichtig ist außerdem: Vertragsstrafen können unter Kaufleuten nicht einfach auf Angemessenheit reduziert werden, wenn dies nicht ausdrücklich vereinbart ist.

even: Zum Abschluss: Wie lassen sich Zahlungen sinnvoll an messbare Projektergebnisse koppeln?

Vergütung ist häufig die beste Motivation. Dabei sollte zwischen der Projektphase – also der Integration des Systems – und der Betriebsphase unterschieden werden. Die Erreichung eines Zahlungsmeilensteins muss eindeutig messbar sein. In der Regel vereinbaren die Parteien die erste Teilzahlung bei Unterzeichnung des Projekts, weitere Teilzahlungen erfolgen beispielsweise aber erst bei Abnahme bestimmter Systemelemente oder des Gesamtsystems nach erfolgreichem Integrationstest und Hochlauf.

In der Betriebsphase wird die Vergütung in der Regel laufend fällig, zum Beispiel für Supportleistungen. Zusätzlich können außerplanmäßige Zahlungen entstehen, etwa bei Bonus- oder Malus-Regelungen im Zusammenhang mit KPI-Ergebnissen.

Auf der Suche nach einer passenden Lösung für deine Logistik? Hier geht’s zur Vergleichsplattform, die dir die Suche erleichtert.