In unseren Seminaren verwenden wir immer wieder viel Zeit für das Thema Haftung. Und wir erklären immer wieder, dass die rein juristischen Maßnahmen zur Begrenzung des „Haftungsrisikos“ relativ beschränkt sind. Aufgrund der strengen Anforderungen der Gesetze und der darauf basierenden Rechtsprechung sind die Möglichkeiten, die Haftung für Schadensersatz und Aufwendungsersatzansprüche in AGB zu reduzieren wirklich eng begrenzt, man kann auch sagen: Was wirtschaftlich vernünftig scheint, lässt sich mit AGBs nicht realisieren. Geht man wirklich mit dem Kunden in Verhandlungen, erzielt man wirklich eine Individualvereinbarung, die von Juristen nicht als AGB qualifiziert wird, dann ist dies ein aufwändiger Prozess, den nicht jeder vollziehen kann oder will.
Als Wege zur Begrenzung der Haftung bleiben mithin noch Versicherungen, eine gute Leistungsbeschreibung oder eben faktische Maßnahmen zur Begrenzung des Risikos. Um diese geht es in diesem Blog.
Entweder die IT arbeitet nicht oder sie erzielt falsche Ergebnisse.
A. Redundanz
I. Redundanz aufgrund technischer Fehler
Absicherungen von technischen Fehlern durch Redundanz gehören inzwischen für jeden zum Alltag, der mit der IT lebt und von ihr abhängig ist. In erster Linie kann man Datensicherungen erstellen, die die betroffenen Daten, Datenbanken und Programme sichern. Erforderlich sind solche Datensicherungen zum einen, um an den Status quo ante zu gelangen, der vor dem Eintritt des technischen Problems bestand. Eine große Vielzahl – wenn nicht zwei Drittel aller technischen Störungen von IT-Systemen – werden durch Inkompatibilitäten zwischen den einzelnen Teilen verursacht. Das neue Release der Software X verträgt sich nicht mit dem Release Y des ERP Systems auf dessen Funktion der Kunde lebensnotwendig angewiesen ist. Beinhaltet die Datensicherung den letzten Stand vor dem Einspielen des Releases, so kann die Datensicherung helfen, die Funktionsfähigkeit schnell wieder zu erlangen. Und dass es wichtig ist, Daten und Datenbänke regelmäßig zu sichern, um die Früchte der eigenen Arbeit zu schützen, bedarf keiner Erwähnung.
Die Frage „wie oft müssen Daten eigentlich gesichert werden“ kann nur unter Berücksichtigung der besonderen Umstände des Einzelfalles beantwortet werden. Es gibt hier kein grundsätzliches „Täglich“. Die eigentliche Frage lautet eher: Was geschieht, wenn die gesicherten Daten dem Kunden nicht zur Verfügung stehen oder gar endgültig verloren gehen? Die zweite Frage lautet: Falls es durch die Nichtverfügbarkeit des technischen Systems zu einer Betriebsunterbrechung kommt, wie lange dauert es, bis die Betriebsunterbrechung beendet ist?
In Beantwortung dieser Fragen ist auch zu beantworten, welche Form der Datensicherung die richtige ist. Sicherheit kostet Geld und jeder Zugewinn an Sicherheit kostet mehr Geld.
SLA
Und ganz wichtig ist es, die Qualität der Datensicherung von Zeit zu Zeit zu überprüfen. Hier sind vor allem die Kunden angesprochen. Werden die richtigen Daten gesichert? Und wie lange dauert es, bis die Systeme wieder verfügbar sind und man wieder produktiv mit den Daten arbeiten kann? Kunden, für die die Funktion einer Software lebensnotwendig ist, sollten sich überlegen, Notfallpläne zu erstellen, anhand derer die Qualität und die Zeit eines Restores überprüft werden und diese Leistungen mit einem SLA zu regeln. Es reicht manchmal eben nicht, dass der Kunde „so schnell wie möglich“ wieder arbeiten kann, sondern dies muss innerhalb eines klaren zeitlichen Intervalls wieder geschehen. Wird dieses Intervall verfehlt, müssen sich rechtliche Konsequenzen anschließen – oder man muss anders planen.
IT-Infrastruktur
Das gleiche gilt auch für die IT-Infrastruktur. Auch hier stellt sich die Frage, ob und welche Redundanz zu realisieren ist, um die Zeiten der Betriebsunterbrechung so gering wie möglich zu halten und das Risiko des endgültigen Verlustes von Daten zu beseitigen.
B. Überprüfung der Ergebnisse der Software
Auch das kostet viel Geld, ist aber nach meiner Ansicht zwingend erforderlich, wenn der Kunde von den Leistungen der Software abhängig ist. Wenn bei Abnahmen die Funktionen und Eigenschaften einer Software überprüft werden, warum geschieht das nicht jedes Mal dann, wenn ein technischer Change realisiert wird? Die Antwort ist: Weil es zu viel kosten würde. Aber: Wie bei jeder Grenznutzenbetrachtung sollten Sie auch hier überlegen, wie häufig Sie im Laufe eines Jahres wieder anhand von Testcases überprüfen, ob die Software auch das rechnet, was sie soll.
C. Organisatorische Maßnahmen – Desaster Management
Notfallplanungen – wer macht im Falle eines kritischen Fehlers, eines Ausfall eines Systems was mit welchen Mitteln – sind wirksame Methoden zur Begrenzung von Schäden. Aber auch hier gilt, dass viele Dinge sich erst dann zeigen, wenn der Notfall eingetreten ist. Und tun Sie sich einen Gefallen und überlegen Sie in Abständen von einem oder zwei Jahren, ob die Notfallpläne nicht mit einem Change geändert werden müssen.
