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
Die Beschreibung der DIN ist deshalb unglücklich, weil sie 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 „Pflichtenheft“ dazu verwendet wird, eine Vielzahl von Funktionen zu erfassen, die sich bestimmt inhaltlich überschneiden, sich aber 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.
