Zehn bis zwanzig Aktenordner füllt ein gut ausgearbeiteter Outsourcing-Vertrag, wenn man ihn ausdruckt. Weil er bis in die hinterste Ecke erklärt, was wer wann zu tun hat. So sieht für den IT-Rechtsexperten Thomas Jansen der Idealfall aus - doch der ist ihm in seinen 16 Berufsjahren zu selten begegnet.
Foto: DLA Piper
"Es ist oft einfacher, einen Pudding an die Wand zu nageln als aus den Beschreibungen der Anbieter herauszulesen, wer wann was schuldet und zu welchem Preis", sagt der promovierte Jurist, der das Münchner Büro der internationalen Wirtschaftssozietät DLA Piper leitet. Das kann teuer enden, vor allem für den Anwender. Jansen rät deswegen sowohl Anbietern als auch Anwendern dringend, alle wesentlichen Aspekte eines Outsourcing-Vertrages, insbesondere den Leistungsumfang, das Monitoring und Szenarien für den Ernstfall vertraglich genau festzulegen.
"Zu häufig eine Bauchentscheidung"
1. Die Ausschreibung: So konkret wie möglich muss die Ausschreibung die Anforderungen und Ziele eines IT-Projektes beschreiben, und glasklar verständlich. Das zwinge die Anbieter, ein ebenfalls schon sehr detailliertes Angebot zu schreiben. Voraussetzung ist: Die Projektverantwortlichen müssen sich darüber klar werden, "welche Leistungen aus technischer, prozessökonomischer und wirtschaftlicher Sicht bezogen werden sollen, um betriebliche Prozesse zu beschleunigen, deren Qualität zu verbessern oder ökonomischer zu gestalten".
2. Den richtigen Partner finden: Die Wahl des Anbieters ist für den Juristen Jansen zu "häufig eine Bauchentscheidung". Ist er überhaupt der richtige, kann er die Leistungen tatsächlich stemmen? Die eigenen Anforderungen mit den Möglichkeiten und Angeboten verschiedener Anbieters zu matchen, etwa mithilfe eines entsprechenden Software-Tools, dafür sollte der Projektplan genügend Zeit einräumen - bei großen Projekten auch Monate. Wichtig ist, dass der Anwender weiß, was er will und dies auch in einem entsprechenden Lastenheft definiert hat. Die vom Anbieter erstellte Leistungsbeschreibung sollte die Anforderungen des Lastenheftes widerspiegeln.
Von der IT über die Finanzleute bis zu den Hausjuristen sollten alle Projektbeteiligten in die Entscheidungsfindung eingebunden sein. Wichtig ist es, in dieser Zeit offen mit dem Anbieter zu kommunizieren - und genau hinzuhören. Beantwortet er alle Fragen? Bessert er bei Unklarheiten nach und versteht er wirklich, was gewünscht ist?
3. Lasten und Pflichten genau festlegen: "Eine detaillierte Leistungsbeschreibung entscheidet maßgeblich über den Erfolg eines Outsourcing-Vertrages", sagt Jansen. "Auf keinen Fall sollte man sich auf die vom Anbieter zur Verfügung gestellten Beschreibungen verlassen. Denn er wird in aller Regel die kritischen Punkte nicht adressieren." Und die wenigsten Anbieter würden den erheblichen Aufwand, der für eine ausführliche Ausarbeitung der Leistungsbeschreibung notwendig sei, selbst tragen wollen.
Alles entscheidend ist die Leistungsbeschreibung
Hinein müssen alle Lasten und Pflichten für das Projekt. Wer sie zusammenstellt, sollte laut Jansen darauf achten, dass der Zusammenhang zwischen Leistung, Preis und Service Level abgebildet wird. Dass auch das Prozedere einer späteren Vertragsänderung berücksichtigt wird. Und dass - für den Fall der Fälle - der Outsourcing-Partner auch zur Unterstützung verpflichtet wird, sollte man sich frühzeitig trennen.
4. SLAs - das Fieberthermometer beim Outsourcing: Service Level Agreements definieren Kriterien, um die erbrachten Leistungen zu messen (KPI) - und was passiert, wenn der Anbieter nicht liefert, wie er soll. "Ein reiner Strafkatalog wird der Lebenswirklichkeit nicht gerecht, weil bei der Nicht- oder Schlechterfüllung von SLAs im Zweifel das Geschäft stillsteht", argumentiert Anwalt Jansen. "Ich muss also ständig überprüfen können, ob der Motor läuft. Denn bis so ein Rechtsstreit durchgezogen ist, kann das Unternehmen insolvent sein."
SLAs mit Zuckerstück und Peitsche
Trotzdem sollte das SLA Sanktionen enthalten - "um den Druck auf den Anbieter zu erhöhen". Statt nur mit der Peitsche zu drohen, könnten Kunden aber auch Zuckerstückchen bieten. Zum Beispiel Benefits, wenn der Dienstleister die vereinbarten 99,8 Prozent Systemverfügbarkeit noch übertrifft.
5. Vergütungsregeln - oder das liebe Geld: Leistung und Bezahlmodell müssen zueinander passen, ob nun "Pay per Use" oder ein Festpreis vereinbart wird - oder beide Varianten kombiniert werden. Aber das ist längst nicht alles: Sind Preisanpassungen möglich, wenn ein Projekt über mehrere Jahre läuft und die Hardware-Kosten sich verändern? Wie geht man mit Budgetüberschreitungen um? Und was kosten Extrawünsche? Denn die kommen mit Sicherheit, wenn das Projekt erstmal läuft.
6. Benchmarking - denn die Technik ändert sich: "So ein Projekt lebt", gibt Jansen zu bedenken. Ein typischer Vertrag läuft über fünf, manchmal auch zehn Jahre. Eine Zeit, in der Hardware mehrere Produktzyklen durchleben kann. Darauf müsse auch der Vertrag reagieren - und mit einem standardisierten Benchmarking-Verfahren den veränderten Rahmenbedingungen angepasst werden. Wie, das hält die Benchmarking-Klausel fest. Auch ein Verfahren zur Streitbeilegung zu definieren, kann nicht schaden.
Jansen rät, Außenstehende für das Benchmarking ins Boot zu holen. "Schließlich begibt der Kunde sich in eine Abhängigkeit. Ein unabhängiger Dritter kann sagen, ob das Projekt auf dem Stand der Technik und die vom Kunden gezahlten Preise angemessen oder etwa völlig überhöht sind."
Grobe Fahrlässigkeit darf kein Grund für Haftungsausschluss sein
7. Fingerspitzengefühl bei der Haftungsklausel: Hier ist Uneinigkeit fast programmiert. Der Dienstleister will das eigene Risiko so gering wie möglich halten und die eigene Haftung deswegen so gut es geht begrenzen - und der Auftraggeber will genau das Gegenteil. Dafür gibt es Industriestandards, wie eine Haftungsbegrenzung, die einem auszuhandelnden Prozentsatz des Auftragswertes entspricht. Klare Ausnahmefälle, die es festzuhalten gilt, sind für Jansen aber Vorsatz, Personenschäden sowie die Verletzung geistiger Eigentumsrechte und der Geheimhaltungspflicht.
"Anbieter fordern zunehmend häufiger eine Haftungsbegrenzung für grob fahrlässiges Handeln", berichtet der IT-Anwalt. "Und das wird von den Kunden häufig akzeptiert." Weil die Zeit drängt und man sich längst für diesen Anbieter entschieden hat. "Aber was bedeutet grob fahrlässig? Der Anbieter hätte bei entsprechender Sorgfalt erkennen können und müssen, dass ein Schaden entstehen kann. Deswegen sollte man diese Forderung auf keinen Fall akzeptieren."
Für die Haftung ist es eine wichtige Frage, in welchem Rechtsraum der Vertrag angesiedelt ist. Das Gesetz in angelsächsischen Ländern, etwa den USA und UK, unterscheidet nicht nach dem Grad des Verschuldens - also vorsätzlich oder grob fahrlässig. Für die dortigen Richter ist die Art des Schadens entscheidend: direkt oder indirekt. "Ein typischer US-Anbieter will nur für direkte Schäden haften." Hat er einen defekten Rechner aufgestellt, tauscht er ihn aus. Für indirekte Schäden, wie durch den kaputten Rechner verursachte Verluste, will er aber nicht aufkommen. Jansen betont: "Das ist mit dem deutschen Recht in aller Regel nicht vereinbar."
8. Geistiges Eigentum schützen: "Das ist alles andere als trivial", sagt IT-Rechtsexperte Thomas Jansen, "gerade im 21. Jahrhundert." Der Kunde sollte nicht dafür haften, wenn die vom Anbieter zur Verfügung gestellte Software Rechte Dritter verletzt, etwa wegen der unberechtigten Nutzung fremder Codes. "Den Programmierern fehlt oft das Bewusstsein dafür", sagt Jansen. Wenn der Anbieter zum Beispiel Codes aus Open Source Programmbibliotheken verarbeitet, muss er für sicherstellen, dass die Lizenz auch seinem Kunden die Nutzung erlaubt.
Die Firmengeheimnisse schützen
Für den Kunden oft noch kritischer ist, wenn das eigene geistige Eigentum betroffen ist. So der Fall, wenn im Laufe eines Projektes neue Software entsteht." Ein Anbieter lernt die Prozesse beim Kunden sehr genau kennen. Wenn er speziell dafür ein neues Tool entwickeln kann, wird er damit oft auf offene Ohren treffen." Aber wenn er das Programm für Daimler schreibt, will der Autobauer sicher nicht, dass sein Partner mit dem Programm zu BMW rennt.
9. Die richtige Exit-Strategie: Im schlimmsten Fall trennen die Partner sich, bevor sie ihr Projekt vollendet haben. Um dafür vorzusorgen, rät Jansen zu einem Exit-Plan. Er definiert, was der Anbieter noch zu erledigen hat, wenn er aus dem Projekt aussteigt: Dass er zum Beispiel Trainings für die Mitarbeiter des neuen Partners durchführt, oder das Verträge mit Subunternehmern zum neuen Anbieter übertragen werden. Auch wie dies im Einzelnen zu vergüten ist, regelt ein Exit-Plan.