A. Begriff

Zunächst einmal mehr darauf hinzuweisen, daß es in der Branche keinen einheitlichen Sprachgebrauch für das gibt, was man unter einem Pflichtenheft versteht. Zwar kann man unter Rückgriff auf die DIN 66231 (Programmentwicklungsdokumentation) oder DIN 69901 (Projektwirtschaft) eine Reihe von Anhaltspunkten gewinnen, was Inhalt eines Pflichtenhefts sein sollte. Das Problem an allen DIN´s im Bereich der IT ist stets zu beantworten,  ob diese tatsächlich noch modern sind – sic. dem anerkannten und bewährten Stand der Technik entsprechen – und zweitens ob deren Geltung für den Einzelfall vereinbart wurde.

B. Problemlage

Ich kann mit dem Begriff der DIN deshalb nichts anfangen, weil er versucht, verschiedene Funktionen miteinander zu verbinden. Was aber ein Pflichtenheft inhaltlich ist, bemisst sich danach, welche Projektmethodik angewendet wird. Schaut man sich die aus dem englischen stammenden Begrifflichkeiten an – requirement specification, functional specification, technical specification – wird klar, daß der deutsche Begriff dazu verwendet wird, eine Vielzahl von Funktionen zu erfassen, die sich bestimmt inhaltlich überschneiden, sich aber modellhaft voneinander abgrenzen lassen. Die Verwirrung, die ob der Frage herrscht, wer nun für die Erstellung eines Pflichtenhefts die Verantwortung trägt, wer für Lücken die Verantwortung trägt, lässt sich vor dem Hintergrund verstehen, daß man den Begriff des Pflichtenhefts nicht funktional begreift, wie es im englischen der Fall ist.

1.) Ein Begriff

Das Pflichtenheft beinhaltet den Sollzustand, den die Software zum Zeitpunkt der Abnahme haben soll. Macht man sich einmal von allen technischen Erkenntnissen frei, dann kann man auf dem Weg zu Software drei Phasen unterscheiden:

2.) Rein Funktionale Anforderungen

a.) Sachlage

Software muß rein funktionalen Anforderungen entsprechen. Bevor man dazu übergeht zu hinterfragen, was auf welche Weise programmiert und in die technische Welt umzusetzen ist, muß man erst einmal wissen, welche Funktionen und Eigenschaften die Software idealtypisch haben sollte. Welche Prozesse sollte sie abbilden, welche Eingaben sollten wo stattfinden, welche Resultate sollten wann errechnet werden, welche Eigenschaften sollte die Software hinsichtlich Lastverhalten und Kapazität, hinsichtlich Datensicherheit und Verfügbarkeit haben? Diese Punkte sind im Grundsatz alle diejenigen, die der Kunde völlig ohne Zutun eines IT Unternehmens wird beschreiben können. Im Grunde ist die Erstellung des Funktionalen Anforderungsprofils – so nenne ich diesen Sollzustand – eine Aufgabe für einen Unternehmensberater oder eine Aufgabe, die der Kunde selbst erfüllen kann.

Das ist deshalb von großer Bedeutung, weil viele IT-Unternehmen genau diese Funktion übernehmen. Sie beraten den Kunden über die oben genannten Punkte und übernehmen damit eine Aufgabe, die typischerweise diejenige ist, die ein Unternehmensberater im Rahmen eines Dienstvertrags erfüllt. Aus der rechtlichen Sicht aber ist es sehr wichtig zu wissen, daß diese Aufgabe eine Aufgabe des Kunden ist. Der Kunde muß sagen, was die Software können soll, der ITler muß die Frage beantworten ob und mit welchen Mitteln die von ihm angebotene Softwarelösung in der Lage ist, die Wunschvorstellung des Kunden in die Realität umzusetzen und mit welchen Resoourcen das möglich ist. Die Wahrheit ist – und aus meinen Gesprächen mit Kunden und Seminarteilnehmern weiß ich das inzwischen recht genau – daß die ITler den Kunden sehr, sehr häufig auch bei der Frage der Erstellung des Funktionalen Anforderungsprofils beraten. Das ist für sich betrachtet kein Problem. Nur tendieren die Kunden dazu, die Leistungen des ITlers insgesamt als Werkverträge zu betrachten. Mängel des funktionalen Anforderungsprofils sind damit nicht mehr Sache des Kunden – was sie nach dem Gesetz aber sind – und Leistungen des ITlers sind damit oft als Mängel qualifiziert, die zu dem Regime des Werkvertragsrechts gehören – was auch nicht überzeugt: Warum sollte ein Unternehmensberater nach Dienstvertragsrecht haften und ein ITler, der die gleiche Aufgabe wahrnimmt, nach dem umgemein schärferen Werkvertragsrecht?

Normal haftet ein Unternehmensberater nach Dienstvertragsrecht, also nicht erfolgsbezogen. Realisiert ein ITler die Aufgaben, besteht immer die Versuchung des Kunden, den ITler im Rahmen des Werkvertragsrechts- und damit quasi im Rahmen einer Garantiehaftung – für das Fehlen bestimmter Funktionen oder die falsche Auwahl von Prozessen verantwortlich zu machen. Die Personalunion von Unternehmensberater und ITler birgt damit große Gefahren für den ITler und den Kunden, der letztlich nicht das bekommt, was er haben will.

b.) Verantwortlichkeiten

Verantwortlich für die Erstellung des Funktionalen Anforderungsprofils ist primär der Kunde. Er haftet für Ungenauigkeiten und Fehler. Leistungen des ITlers sollten in dieser Phase als Dienstleistungen qualifiziert werden.

2.) Das Pflichtenheft als Ergebnis eines Selektionsprozesses

Grau ist alle Theorie und grün des Leben güldner Baum. In der Theorie müsste diese Phase eigentlich dadurch gekennzeichnet sein, daß der ITler ein funktionales Anforderungsprofil des Kunden daraufhin prüft, welche Funktionen und Eigenschaften mit welchen technischen Mitteln mit welchen zeitlichen, finanziellen und sonstigen Resourcen realisiert werden können. In Wirklichkeit berät ein Itler auch über rein funktionale Elemente und in Wirklichkeit müssen schon im Hinblick auf Zeit und Preise und technische Möglichkeiten immer Abstimmungen zwischen dem Kunden und dem Itler erfolgen, was nun eigentlich mit welchen Mitteln realisiert werden soll. Insofern bezeichne ich das Pflichtenheft gerne als das Ergebnis eines Auswahlprozesses.Aber nach wie vor muß a.) der Kunde sagen, was die Software können soll und b.) der ITler, ob er das aa.) überhaupt und bb.) mit welchen Mitteln und cc.) in welcher Zeitspanne realisieren kann.

a.) Grundsätzliche Verantwortlichkeiten

Bei rein funktionaler Betrachtung fällt es hier aber leicht zu bestimmen, wer welche Veranwortung nach welchen Rechtsregime hat.

Nach der richtigen Beratung über die technische Realisierbarkeit und die hierzu erforderlichen Resourcen trifft der Kunde die Auwahl darüber, was realisiert werden soll. Der ITler trägt die Veranwortung dafür, daß die Auswahl sich so realisieren lässt. Und dafür “haftet” er im Rahmen des Werkvertragsrechts. Denn nur er kann wissen, ob die Dinge sich auch so wie beraten realisieren lassen.

b.) Ausnahme: Evidente Planungsfehler des Kunden.

In der Literatur geistern noch ältere Entscheidungen herum, nach deren Inhalt es Sache des ITlers ist, sich mit den Produktionserfordernissen des Anwenders vertraut zu machen (LG Düsseldorf CR 87, 292ff.). In Literatur und Rechtsprechung ist immer wieder zu lesen, daß der ITler dafür haftet, daß der ITler im Rahmen des Werkvertragsrecht dafür haftet, den Kunden nicht darauf aufmerksam gemacht zu haben, wenn evidente Fehlvorstellungen und Planungsmängel im Hinblick auf das funktionale Anforderungsprofil bestehen (so Marly. Praxishandbuch Softwarerecht, 5.A.Rn.1305). Das bedeutet nach dem hier vertretenen Ansatz: Sofern der ITler im Rahmen des Selektionsprozesses hätte erkennen müssen, daß der Kunde Funktionen und Eigenschaften auswählt, die für das Erreichen des Vertragszwecks schlechthin ungeeignet sind, haftet er selbst dafür, den Kunden nicht rechtzeitig gebremst und aufgeklärt zu haben.