Der IT-Systemvertrag: Grundlagen und Abgrenzung

Wenn ein Anbieter Hardware liefert, Software bereitstellt, die Einführung begleitet und anschließend den Betrieb übernimmt, reicht ein Blick auf einzelne Bestellungen nicht aus. Entscheidend ist das Zusammenspiel aller Leistungen. Genau dafür wird in der Praxis häufig ein IT-Systemvertrag geschlossen. Er soll sicherstellen, dass du nicht mehrere rechtlich und organisatorisch getrennte Bausteine verwaltest, während am Ende niemand für das funktionierende Gesamtsystem einsteht.

Was einen IT-Systemvertrag ausmacht

Ein IT-Systemvertrag ist keine gesetzlich fest definierte Vertragsart mit einem einheitlichen Pflichtenkatalog. Für Beschaffungen der öffentlichen Hand greifen dafür standardisierte EVB-IT-Verträge. Er beschreibt vielmehr eine Vertragsstruktur: Ein Auftragnehmer schuldet die Lieferung, Einrichtung und gegebenenfalls den Betrieb eines abgestimmten IT Systems. Dazu können Hardware, Standardsoftware, individuelle Anpassungen, Datenübernahme, Schulungen, Projektleistungen, Support und Wartung gehören.

Der Kern liegt in der Systemverantwortung. Der Anbieter soll nicht nur einzelne Komponenten liefern, sondern dafür einstehen, dass diese Komponenten im vereinbarten Umfang zusammenwirken. Für dich als Auftraggeber ist das besonders wichtig, wenn du ein neues ERP System, eine Fachanwendung, eine Infrastrukturplattform oder eine umfassende Digitalisierungslösung einführst.

Ein IT-Systemvertrag beantwortet deshalb nicht nur die Frage, welche Leistungen geliefert werden. Er muss auch festlegen:

• Welchen fachlichen und technischen Zweck das System erfüllen soll.
• Welche Bestandteile zum System gehören.
• Welche Leistungen der Anbieter selbst erbringt und welche durch Dritte erfolgen.
• Welche Mitwirkung du leisten musst.
• Wann das System als abgenommen gilt.
• Wie Fehler, Änderungen und Betriebsleistungen nach der Einführung behandelt werden.
• Wer bei Schnittstellenproblemen oder Verzögerungen verantwortlich ist.

Ohne diese Klammer entstehen in Projekten schnell Lücken. Der Hardwarelieferant verweist auf die Software. Der Softwareanbieter verweist auf die Infrastruktur. Der Implementierungspartner sieht fehlende Daten oder Entscheidungen beim Kunden. Ein guter Systemvertrag reduziert genau diese Ausweichmöglichkeiten.

Welche Leistungen typischerweise gebündelt werden

Der konkrete Leistungsumfang hängt vom Projekt ab. In der Regel umfasst ein Systemvertrag mehrere Leistungsgruppen, die in Anlagen präzise beschrieben werden sollten.

Leistungsbereich	Typische Inhalte	Wichtige Vertragsfrage
Hardware und Infrastruktur	Server, Endgeräte, Netzwerke, Speicher, technische Basisdienste	Wer plant Kapazität, Kompatibilität und Installation?
Software	Standardsoftware, individuelle Anpassungen, Schnittstellen, Lizenzen	Welche Funktionen gehören zum vereinbarten Soll Zustand?
Einführung	Analyse, Konfiguration, Datenmigration, Tests, Schulung, Inbetriebnahme	Welche Ergebnisse sind geschuldet und wie werden sie geprüft?
Projektsteuerung	Projektplan, Statusberichte, Eskalation, Dokumentation	Wer entscheidet bei Konflikten und Änderungswünschen?
Betrieb	Hosting, Überwachung, Sicherung, Wiederherstellung, Benutzerverwaltung	Welche Verfügbarkeit und Reaktionszeiten gelten?
Support und Wartung	Störungsannahme, Fehlerbehebung, Updates, Pflege	Was ist im Preis enthalten, was wird gesondert vergütet?

Wichtig ist: Die Aufzählung allein schafft noch keine Klarheit. Begriffe wie „betriebsbereit“, „voll funktionsfähig“ oder „nach aktuellem Stand der Technik“ klingen umfassend, sind aber ohne Bezug zum Projekt oft zu unbestimmt. Besser ist eine konkrete Leistungsbeschreibung mit Anforderungen, Prozessen, Schnittstellen, Rollen und nachvollziehbaren Abnahmekriterien.

Wenn etwa eine Datenmigration geschuldet ist, sollte nicht nur „Migration der Altdaten“ vereinbart werden. Beschreibe, welche Datenbestände übertragen werden, welche Datenqualität vorausgesetzt wird, welche Prüfungen stattfinden und wer Fehler in Altdaten bereinigt.

Abgrenzung zu Einzelverträgen

Einzelverträge sind keineswegs falsch. Sie passen gut, wenn Leistungen klar voneinander getrennt sind und du die Koordination selbst übernehmen kannst oder willst. Kaufst du beispielsweise Standardhardware bei einem Lieferanten und nutzt eine bereits eingeführte Software unabhängig davon, kann ein eigenständiger Kaufvertrag sinnvoll sein.

Der IT-Systemvertrag wird relevant, wenn die Komponenten funktional voneinander abhängen. Dann reicht es nicht, nur Liefergegenstände zu definieren. Du brauchst eine Regelung für das Zusammenspiel.

Bei Einzelverträgen können unterschiedliche Vertragslogiken nebeneinanderstehen. Für Hardware gelten oft kaufrechtliche Elemente. Bei der Erstellung oder Anpassung von Software kommt es häufig auf werkvertragliche Ergebnisse und eine Abnahme an. Laufender Support oder Betrieb enthält dienstvertragliche Elemente, weil nicht ein einmaliger Erfolg, sondern die fortlaufende Tätigkeit geschuldet sein kann.

Ein Systemvertrag verbindet diese Elemente. Das ist praktisch, aber anspruchsvoll. Du solltest nicht pauschal festhalten, dass für den gesamten Vertrag nur eine Vertragsart gilt. Sinnvoller ist eine klare Zuordnung nach Leistungsphasen und Leistungstypen.

Die entscheidende Frage: Wer schuldet den Projekterfolg?

Die Abgrenzung hängt vor allem von der Verantwortung ab. Ein Anbieter, der nur Softwarelizenzen überlässt, schuldet nicht automatisch die erfolgreiche Einführung in deinem Unternehmen. Übernimmt derselbe Anbieter jedoch Konzeption, Anpassung, Integration, Migration und Inbetriebnahme, liegt eine umfassendere Verantwortung nahe.

Prüfe deshalb vor Vertragsschluss:

• Hat der Anbieter die Gesamtarchitektur geplant oder nur vorgegebene Komponenten geliefert?
• Trägt er die Verantwortung für Schnittstellen zu Drittsystemen?
• Ist ein bestimmter produktiver Einsatz vereinbart?
• Muss das System konkrete Geschäftsprozesse unterstützen?
• Wer koordiniert weitere Dienstleister?
• Wer trägt das Risiko, wenn einzelne Komponenten technisch nicht zusammenpassen?

Je stärker der Anbieter diese Verantwortung übernimmt, desto wichtiger werden belastbare Regeln zu Systemintegration, Abnahme und Mängelrechten.

Die Leistungsbeschreibung ist dein Steuerungsinstrument

In vielen Vertragsentwürfen steht die eigentliche Leistung nur in einem kurzen Hauptvertrag, während die Details in Angeboten, Präsentationen, Workshops oder E Mails verteilt sind. Das ist riskant. Im Streitfall stellt sich schnell die Frage, welche Aussagen wirklich Vertragsinhalt geworden sind.

Ordne die Unterlagen deshalb in einer eindeutigen Rangfolge. Zum Beispiel kann die Leistungsbeschreibung Vorrang vor allgemeinen Vertragsbedingungen haben, während ein Projektplan für Termine und Meilensteine gilt. Widersprüche müssen ausdrücklich geregelt werden.

Eine belastbare Leistungsbeschreibung enthält mindestens:

1. Den fachlichen Zweck und die vorgesehenen Nutzergruppen.
2. Die Systemarchitektur einschließlich Schnittstellen und Drittkomponenten.
3. Konkrete Funktionen, Prozesse und Qualitätsanforderungen.
4. Liefergegenstände wie Dokumentation, Konfigurationen und Zugangsdaten.
5. Testfälle und Abnahmekriterien.
6. Mitwirkungspflichten auf deiner Seite.
7. Annahmen und ausdrücklich ausgeschlossene Leistungen.

Besondere Aufmerksamkeit verdienen Schnittstellen. Formulierungen wie „Anbindung an vorhandene Systeme“ reichen nicht. Benenne die betroffenen Systeme, Datenformate, Übertragungswege, Verantwortlichkeiten und Testszenarien. Wenn ein Drittanbieter beteiligt ist, muss klar sein, ob dein Vertragspartner die Integration schuldet oder lediglich Unterstützung nach Aufwand leistet.

Einführung und Abnahme sauber trennen

Die Einführung ist die Phase mit dem höchsten Konfliktpotenzial. Hier treffen Terminziele, fachliche Erwartungen, Datenqualität und technische Abhängigkeiten aufeinander. Der Vertrag sollte deshalb nicht nur ein Enddatum nennen, sondern realistische Meilensteine und überprüfbare Ergebnisse vorsehen.

Typische Meilensteine sind die Fachkonzeption, Bereitstellung der Testumgebung, Abschluss der Migration, Integrationstest, Schulung und produktive Inbetriebnahme. Entscheidend ist jeweils, was objektiv geprüft wird und welche Folgen eine Verzögerung hat.

Die Abnahme ist dabei keine bloße Projektformalität. Sie kann den Übergang von der Einführungsphase in Gewährleistung, Betrieb oder Support markieren. Lege fest:

• Welche Leistungen abgenommen werden, das Gesamtsystem oder einzelne Teilabschnitte.
• Welche Tests durchgeführt werden.
• Welche Fehler eine Abnahme verhindern.
• Wie mit geringfügigen Mängeln umgegangen wird.
• Welche Frist für die Abnahmeprüfung gilt.
• Ob und wann eine produktive Nutzung als Abnahme gewertet werden kann.

Vorsicht bei pauschalen Abnahmefiktionen. Wenn das System wegen Zeitdruck produktiv genutzt wird, bedeutet das nicht zwingend, dass alle Anforderungen erfüllt sind. Eine Regelung sollte daher zwischen einer vorläufigen Nutzung und einer rechtsverbindlichen Abnahme unterscheiden.

Betrieb, Support und Service Level nicht vermischen

Nach der Einführung verändert sich die Vertragsbeziehung. Statt Projektleistungen stehen Verfügbarkeit, Störungsbearbeitung, Sicherheitsvorgaben und Änderungen im Vordergrund. Diese Betriebsphase braucht eigene Regelungen, auch wenn sie Teil desselben Systemvertrags ist.

Ein Service Level Agreement, kurz SLA, sollte mindestens festlegen, wann Support erreichbar ist, wie Störungen klassifiziert werden, welche Reaktionszeiten gelten und in welchem Zeitraum eine Lösung oder ein belastbarer Workaround erwartet wird. Reaktionszeit und Behebungszeit sind nicht dasselbe. Wenn du beides brauchst, muss der Vertrag beide Begriffe definieren.

Auch Wartung ist konkret zu beschreiben. Kläre insbesondere, ob Updates, Sicherheitskorrekturen, Versionswechsel, Anpassungen wegen geänderter Schnittstellen und gesetzlicher Anforderungen enthalten sind. „Wartung“ kann je nach Anbieter sehr unterschiedliche Leistungen meinen.

Passende Seminare und Termine findest du bei uns auf cmt.de.

Haftung, Mitwirkung und Änderungen realistisch regeln

Ein Systemprojekt scheitert selten an einer einzigen Vertragsklausel. Häufig führen unklare Zuständigkeiten dazu, dass Probleme zu spät sichtbar werden. Deshalb gehören Mitwirkungspflichten nicht als Nebenpunkt ans Ende des Vertrags. Benenne Ansprechpartner, Entscheidungswege, Bereitstellung von Testdaten, Zugängen und fachlichen Ressourcen.

Gleichzeitig darf eine Mitwirkungsklausel nicht jede Verantwortung auf dich verlagern. Wenn der Anbieter Verzögerungen geltend macht, sollte er diese konkret anzeigen, die Auswirkungen erläutern und Vorschläge zur Abhilfe machen.

Für Änderungen brauchst du ein geregeltes Verfahren. Ein „Change Request“ sollte beschreiben, was geändert werden soll, welche Auswirkungen auf Kosten, Termine, Architektur und Betrieb entstehen und wer die Änderung freigibt. Ohne Freigabe sollte keine kostenpflichtige Zusatzleistung beginnen, außer es handelt sich um zuvor definierte dringende Maßnahmen.

Bei Haftung und Risiken kommt es auf die Gesamtschau an. Prüfe Haftungsbegrenzungen, Ausschlüsse, Regelungen zu Datenverlust, Sicherheitsvorfällen, Schutzrechten und eingesetzten Subunternehmern. Besonders kritisch sind Klauseln, die eine weitgehende Systemverantwortung versprechen, die Haftung dafür aber praktisch vollständig ausschließen.

Checkliste vor der Unterschrift

Gehe vor Vertragsabschluss diese Punkte durch:

• Ist der geschuldete Systemerfolg verständlich und überprüfbar beschrieben?
• Sind alle Komponenten, Schnittstellen und Drittleistungen erfasst?
• Gibt es eine eindeutige Rangfolge der Vertragsunterlagen?
• Sind Einführung, Abnahme und Betriebsbeginn sauber voneinander getrennt?
• Kennst du deine Mitwirkungspflichten und verfügst du intern über die nötigen Ressourcen?
• Sind Support, Wartung und Service Level für den späteren Betrieb ausreichend konkret?
• Gibt es ein verbindliches Verfahren für Änderungen?
• Ist klar geregelt, wer bei Integrationsproblemen verantwortlich ist?
• Passen Haftung, Gewährleistung und Sicherheitsanforderungen zum Projektrisiko?

Ein IT-Systemvertrag schafft Struktur, wenn er die technischen und organisatorischen Abhängigkeiten deines Projekts sichtbar macht. Er ersetzt keine sorgfältige Projektsteuerung, gibt dir aber den Rahmen, um Erwartungen, Verantwortlichkeiten und Risiken vor dem Start verbindlich zu klären.