In mehreren Beiträgen habe ich dargelegt, daß und warum ich kein Anhänger des V Models bin. Zusammenfassend kann man sagen, daß das V Model Lastenheft – Pflichtenheft – Abnahme mit dem deutschen Werkvertragsrecht eine unglückliche Verbindung darstellt. Das Werkvertragsrecht besagt – und der BGH hat dies in vielen Entscheidungen unterstrichen – daß die Dokumentationen, die den fachlichen Sollzustand beschreiben (also welche Funktionen und Eigenschaften müssen in welcher Systemumgebung vorliegen) durch den Auftraggeber zu erstellen sind. In der Regel werden diese aber durch den Auftragnehmer erstellt. Das Werkvertragsrecht besagt, daß die Mängel der Dokumentation über den fachlichen Sollzustand durch den zu tragen sind, der die Dokumentation erstellen muß. Das kann aber außerhalb der rein technischen Gewerke nicht richtig sein.
1.) Immer wieder ist auf die Bedeutung des § 633 II BGB hinzuweisen. Primär maßgeblich für die Mängelfreiheit ist die vertragliche Beschaffenheit. Nur insofern diese nicht vorhanden ist, haftet der Auftragnehmer für das Fehlen von Funktionen und Eigenschaften, wenn diese dazu führen, daß das Werk sich nicht für den vorausgesetzten Zweck eignet oder die Eigenschaften aufweist, die man von Gewerken dieser Art üblicherweise übersetzen kann. In die Welt der Softwareprojekte übersetzt: Wenn Funktionen und Eigenschaften nicht im Pflichtenheft beschrieben sind, wird das dann zum Problem, wenn der Auftraggeber deshalb meint, mit der Software nicht arbeiten zu können oder das Vorhandensein solcher Funktionen und Eigenschaften bei anderen Softwareanbietern selbstverständlich ist. Das IT Unternehmen möchte erreichen, daß alle Funktionen und Eigenschaften, die nicht explizit im Pflichtenheft beschrieben sind, nicht vertraglich geschuldet ist. Der Auftraggeber möchte, daß auch solche Eigenschaften geschuldet sind, die nicht im Pflichtenheft aufgeführt wurden, wenn man sonst nicht wie gewünscht mit der Software arbeiten kann.
2.) Das ist die Ausgangslage, die in Debatten über unechte Changes führt (also darüber, ob bestimmte Funktionen und Eigenschaften nun vertraglich geschuldet sind oder nicht). In der Praxis werden kaufmännische Lösungen gesucht (also Vergleiche geschlossen). Aber es bleibt immer ein Risiko. Irgendwann meint das IT Unternehmen nicht richtig bezahlt zu werden und der Kunde meint, für Zeit und Geld nicht das gewünschte Produkt erhalten zu haben.
3.) Die systematische Ursachen sind mehrere:
a.) Zum einen kann der nur der Auftraggeber wissen, wie seine Angestellten an deren Arbeitsplatz mit der Software arbeiten. Der Auftragnehmer kann im Rahmen einer Fit Gap Analyse Aussagen darüber treffen, welche Funktionen und Eigenschaften im Rahmen der Standardsoftware vorhanden sind oder welche Ressourcen für die Erstellung neuer, gewünschter Funktionen und Eigenschaften erforderlich sind. Aber die betriebswirtschaftliche Verantwortung dafür, wie am Platz der Angestellten gearbeitet wird oder wie gearbeitet werden soll, kann er nicht übernehmen. Trocken gesagt arbeiten Unternehmenberatungen nicht auf der Basis des Werkvertragsrechts: Und das mit guten Gründen.
b.) Zum anderen bestehen Dokumentationen zu großen Teilen aus Sprache und diese hat ihre Tücken. Wörter haben Begriffshöfe, lassen sich unterschiedlich auslegen. Menschen können unterschiedliche Begriffe unterschiedlich besetzen. Und dann: Dokumentationen veralten. Die Technik ändert sich und Menschen erlangen neue Erkenntnisse über den gewünschten SOllzustand der Software. Noch wesentlicher: Die Lust der Parteien zur Anfertigung einer Dokumentation, die so präzise ist, wie es das Werkvertragsrecht eigentlich erfordert, ist der Praxis kaum jemals vorhanden. Ich habe mit Ausnahme technischer Gewerke keine Pflichtenhefte gesehen, aus denen sich wirklich wie in einer Exceltabelle ersehen lässt, welche Funktionen und Eigenschaften in welcher Systemumgebung vorhanden sein müssen. Natürlich ist es unsinnig, wenn jetzt Juristen sagen, daß die IT so wie vom Gesetz gefordert arbeiten sollen. Aber umgekehrt lässt sich natürlich auch bissig fragen, warum die IT ein Projektmodel einsetzt, das nicht konsequent realisiert wird.
c.) Der dritte Punkt: Projektverträge sind Verträge, bei denen die notwendige Planung für den Sollzustand bei Vertagsabschluß nicht abgeschlossen ist. Wenn das so ist, muß die Planung nach dem Vertragsabschluß realisiert werden. Die Handlungen des Kunden für die Erstellung des Pflichtenhefts sind so wichtig wie die Erstellung der Software selbst. In der Praxis aber sagen viele Auftragnehmer, daß sie selbst die Pflichtenhefte erstellen und daß die Handlungen des Kunden zur Erstellung des Pflichtenhefts Mitwirkungspflichten sind. Pflichtschuldig: Auch in meinen älteren Verträgen ist solches zu lesen. Wen es betrifft: Wir haben neue Releases für unsere Verträge, bitte melden Sie sich.
4.) Schlußfolgerungen
a.) Der Kunde ist für die Erstellung einer Dokumentation über den fachlichen Sollzustand verantwortlich. Das IT Unternehmen muß beratend tätig sein. Wenn eine Standardsoftware vorhanden ist, muß anhand einer FIT GAP Analyse erkannt werden, wo die Kundenwünsche über den Standard hinausgehen. Das IT Unternehmen muß Auskunft darüber geben, welche Resourcen an Zeit und Geld eingesetzt werden müssen. Aber der Kunde selbst trägt die Verantwortung für die Vollständigkeit und Richtigkeit des Pflichtenhefts.
b.) Daraus folgt auch, daß die Arbeiten des Kunden zur Realisierung der Planung keine Mitwirkungspflichten, sondern Hauptleistungspflichten sind. Es ist etwas anderes, ob der Access zur kundeneigenen IT nicht vorhanden ist oder ob die richtigen Personen bei der Erstellung des Pflichtenhefts schlicht nicht mitwirken.
b.) Damit soll der immanente Mangel, der mit der Erstellung von Dokumentationen einhergeht, nicht einseitig verlastet werden. Wenn man davon ausgeht, daß Dokumentationen immer mangelhaft sind, ist der einzige Weg aus dem Problem der Verzicht auf Dokumentationen. Es muß eine Konsolidierungsphase geben, anhand derer der Kunde unter Verwendung selbst entwickelter Testcases nach der Realisierung der Software aber noch vor Durchführung der Abnahme noch einmal überprüft, ob die Software richtig funktioniert. Das ist auch deshalb sinnvoll, weil eben diese Testcases zur Validierung der Funktionsfähigkeit der Software nach der Durchführung eines technischen Changes verwendet werden können.
