Diese Blogs entstehen als Nebenprodukt unseres Seminars „Projekte für Softwareerstellung und Anpassung von Software, Support und Wartung“ [Link].
In den Blogs über Projektverträge geht es thematisch erstmal um die Fragestellung, wie die Risiken, die sich aus dem Scheitern von Projekten ergeben, durch eine Planung gemindert werden können. Mit dem Terminus „Haftung“ wird – und das entspricht nicht der juristischen Terminologie – ein Sachverhalt verstanden, in dem das IT-Unternehmen aus der Eingehung eines Vertrags über die Erstellung oder Anpassung von Software einen finanziellen Verlust erleidet.
Der Sachverhalt, um den es hier geht lautet:
Fall 1: Frustrierte Erwartung
Kunde MaschBauKomplett (Abgekürzt MBK) – ein Maschinenbauer alten Kalibers – ist verärgert. Der Vertrieb des IT Unternehmens SolveITAll (Abgekürzt SITA) hat ihm viele Präsentationen gezeigt, die seine bestehenden Probleme beim Betrieb der aktuellen Software lösen könnte – und nach den markigen Worten des Vertriebs auch sollte. A wendet ein, viele der Funktionen und Eigenschaften, die ein Unternehmen seiner Branche typischerweise brauche, fehlten in der von SITA gelieferten Lösung. SITA hat zwar angeboten, die monierten Funktionen zu programmieren: Aber nur als Change, gegen erhöhte Vergütung. MBK schaltet Anwälte ein, SITA wird mit dem Rücktritt vom Vertrag bedroht. SITA wendet ein, viele der jetzt aufgetretenen Wünsche des MBK seien nicht bekannt gewesen. MBK erwidert, SITA habe schließlich mit Branchenerfahrung geworben und deshalb den Auftrag erhalten, nun stelle man fest, MBK habe nur den Auftrag haben wollen. Nach langem Hin- und her einigen sich die Parteien und SITA muß viele der Funktionen für weniger Geld erstellen. MBK droht damit, auf der nächsten Messe alle Wettbewerber über das Verhalten der SITA zu unterrichten, wenn jetzt nicht schnell alles so realisiert wird, wie man es sich vorgestellt habe.
Was kann SITA in Zukunft besser machen?
Ganz grob gesagt, gibt es zwei Bereiche, aus denen sich für die Softwarebranche Haftungsrisiken ergeben können: Die Einführung von Software (einschließlich Changes) und der Betrieb von Software. Während sich während des Betriebs tatsächlich technische Fehler als Hauptquelle von Haftungsrisiken ergeben, steht im Bereich der Einführung von Software die Gruppe „Frustrierte Kundenerwartung“ an erster Stelle. Diese Gruppe kann auch umschrieben werden mit dem Merkmal „Kunde ist nicht zufrieden mit dem Produkt, das er erhalten hat.“ Technische Fehler, die im Bereich der Einführung von Software wirklich zu Haftungsfällen führen, sind dagegen viel seltener anzutreffen.
In den Seminaren lehren wir immer wieder, daß IT-Unternehmen Haftungsrisiken auf vier verschiedenen Wegen reduzieren können:
– Dem juristischen Weg, in dem entsprechende Verträge geschlossen werden.
– Dem versicherungsrechtlichen Weg, in dem Versicherungen abgeschlossen werden, die die Haftungsrisiken möglichst effizient absichern.
– Durch Erstellung von Leistungsbeschreibungen, in dem der Kunden darüber informiert wird, welche Eigenschaften und Funktionen das Produkt hat (und auch nicht hat).
– Durch technische Maßnahmen, die auftretende technische Fehler in ihrer Wirkung so weit als möglich reduzieren.
Wenn man sich diese Wege anschaut, wird sehr schnell klar, daß zwei Wege keinen Erfolg versprechen, wenn es darum geht, die Risiken aus der Erstellung und Anpassung von Software zu reduzieren. Als grundsätzlich wenig geeignet erweisen sich Versicherungen. Hat die Software nicht die Funktionen und Eigenschaften, die der Kunde erwartet, wird die Versicherung häufig einwenden, sie würde für den „Erfüllungsschaden“ nicht einstehen. So nennen die Versicherungen die Haftung, die sich daraus ergibt, daß das gelieferte Produkt nicht oder nicht so wie vertraglich vereinbart geliefert wird. Ebenso wenig decken die meisten Versicherungen den sogenannten Verzugsschaden ab, der dadurch entsteht, daß das versprochene Produkt zu spät ausgeliefert wird. Schauen Sie sich ihre Versicherungsbedingungen einmal an und untersuchen Sie die Frage, was eigentlich geschieht, wenn der Kunde von einem Vertrag über die Einführung der wegen Nichterfüllung kündigt.
Technische Maßnahmen können nur greifen, wenn das System einmal in Betrieb genommen wurde.
Juristische Maßnahmen zur Minderung der Haftungsrisiken in Form von Haftungsbegrenzungsklauseln werden in Form von AGB´s nicht zu realisieren sein. Natürlich können sich SITA und MBK im Rahmen von Individualvereinbarungen auf die Geltung von Regelungen zur Begrenzung von Schadensersatz- und Aufwendungsersatzansprüchen einigen. Nur stellt sich die Frage, ob die Kunden der SITA einen solchen Weg auch gehen wollen. Es wirkt wenig vertrauenserweckend, wenn SITA auf der einen Seite damit wirbt, Projekte zur Zufriedenheit des Kunden realisieren zu können und auf der anderen Seite auf Regelungen zur Begrenzung eines Risikos besteht.
Der beste Weg besteht in der vertraglichen Etablierung von Verfahrensregelungen, die das Projekt steuern. Wie erfolgt die Planungsphase, wie erfolgt die Realisierungsphase? Natürlich kommt es in erster Linie auf die Kompetenzen des ITlers zur Realisierung des Projekts an. Aber daß die Vereinbarung vernünftiger Regelungen zur Planung und Realisierung des Projekts mit dem Kunden als bester Weg zur Minimierung der Risiken aus dem Projektgeschäft erscheint, wird kaum auf Widerspruch stoßen. Daß diese Regelungen dann auch gelebt werden müssen, bedarf keiner weiteren Ausführung.
