I. Die Planung des Sollzustands ist immer auch Sache des Auftraggebers
Das Vorurteil – und das ist sicher nicht von der Hand zu weisen – lautet, dass viele IT-Unternehmen in den Ausschreibungsverfahren vieles versprechen und nur wenig davon halten. Immer wieder heißt es, dass der Auftraggeber zu einem bestimmten Zeitpunkt enttäuscht feststellt, dass er keine Software erhalten hätte, die seinen Erwartungen entspräche. Solche Befunde sind meistens das Resultat mangelhafter Planung. Über 33% der Projekte scheitern. Das Scheitern wird weniger durch einen Mangel in der technischen Fähigkeit des beauftragten IT-Unternehmens verursacht, als vielmehr durch Mängel in der Planung. Mit Planung meine ich nicht nur die Aufgabenstellung, wie eine Software in ein Unternehmen eingeführt wird, sondern hauptsächlich die Fragestellung, welche Funktionen und Abläufe eine Software überhaupt erfüllen sollte.
Grundsätzlich gilt, dass die Festlegung, welche Eigenschaften und Funktionen eine Software haben sollte, dem Auftraggeber obliegt. Einer der großen Unterschiede zwischen dem Kauf- und dem Werkvertragsrecht besteht darin, dass im Kaufrecht der Verkäufer – also das IT-Unternehmen eine Leistungsbeschreibung erfüllen muss, die es selbst erstellt hat. Jeder, der einmal einen Fernseher gekauft hat, weiß dass die Versprechungen des Prospektkatalogs einzuhalten sind. Im Werkvertragsrecht fehlen entsprechende Regelungen, weil es meistens keinen Katalog gibt, wenn Dinge neu herzustellen sind. Hier ist es Sache des Auftraggebers, detaillierten Zustand des Sollzustandes zu machen. Die Umsetzung des Sollzustands in den technischen Istzustand ist Sache des Auftragnehmers. Vereinfacht kann man sagen: Das „was“ kommt vom Auftraggeber, das „wie wird es technisch umgesetzt“ vom Auftragnehmer.
Soweit die Theorie. Diese geht aus zwei Gründen oft an der Praxis vorbei. Zum einen wird Software heutzutage nur noch in den seltensten Fällen neu hergestellt. Schon aus Zeit und Kostengründen werden regelmäßig IT-Unternehmen beauftragt, die bereits branchennahe Standardlösungen in Petto haben, die dann im Auftrag des Kunden an seine Bedürfnisse angepasst werden (Customizing). Der Sollzustand, dem die Software entsprechen soll, entstammt damit natürlich nicht allein dem Auftraggeber. Der Auftragnehmer hat eine Leistungsbeschreibung des Standards. Das Delta zu den Wünschen des Auftraggebers stellt die eigentliche Planungsunterlage dar. Der Sollzustand der Software besteht beim Customizing (und nebenher gesagt, ebenso bei der Parametrisierung) aus der Summe von Standardleistungsbeschreibung und dem Sollzustand für die abweichenden oder zusätzlichen Funktionen oder Eigenschaften.
Die Erstellung dieser Planungsunterlagen für das Delta zwischen gewünschten und bereits vorhandenen Istzustand sollte wie gesagt im Prinzip vom Auftraggeber kommen. In der Praxis wird hier häufig unsauber gearbeitet. Unter Zeit- wie Kostendruck stehend, einigen sich die Parteien häufig auf einen Minimalstatus, der zu erreichen ist, das Weitere werde dann schon „im Projekt“ klargestellt.
Zum anderen bieten die IT-Unternehmen bei der Erstellung der Planung ganz häufig ihre Beratungsleistungen an. Das aber ist aus meiner Erfahrung ein zweischneidiges Schwert. Es sind zwei Beratungsfelder streng zu unterscheiden: Erstens ist da das unmittelbare Feld der Unternehmensberater, die sich mit der Erfassung und Verbesserung von Funktionen und Prozessabläufen innerhalb von Unternehmen befassen. Zweitens sind dort IT-Unternehmen, die über den sinnvollen Einsatz der IT beraten. Beide Bereiche vermengen sich immer mehr, aber offen gestanden kann und muss man kritisch hinterfragen, ob ein IT-Unternehmen der richtige Ansprechpartner ist, wenn es darum geht, unternehmenseigene Prozesse und Funktionen zu erfassen und besser zu verteilen. Meines Erachtens ziehen viele IT-Unternehmen hier Kompetenzen an sich, die sie besser mieden.
Häufig, um nicht zu sagen sehr häufig, sind es Mängel der Planung, die aus diesen beiden Umständen entstehen – eine defizitäre Planung am Beginn des Projekts und eine unzureichende Kompetenz bei der Planung -, die später zu Problemen führen.
Der Ratschlag an den Auftraggeber lautet deshalb: Zu irgendeinem Zeitpunkt ist der Auftraggeber gefordert, bis in die Details an der Planung des Sollzustands mitzuwirken oder diese zu bewirken, sei es vor dem Start des Projekts oder während des Projekts selbst. Es erscheint nicht klug, davon aus Kosten- oder Zeitgründen abzusehen. Insider gehen davon aus, dass der Aufwand, den ein Auftraggeber bei der Einführung von Software zu tragen hat, dreimal höher ist das derjenige, den das IT-Unternehmen zu vollziehen hat. Und man sollte sich immer überlegen, wer die Kompetenz zur Planung wirklich besitzt. Unternehmenseigene Mitarbeiter sollten freigestellt werden oder man sollte diese Aufgaben tatsächlich an Unternehmensberater vergeben.
II. Welche Methode auf dem Weg zur konkreten Planung?
Es wäre nun ganz praxisfremd zu verlangen, den Sollzustand für das Delta zunächst komplett zu fixieren, bevor mit der Arbeit begonnen wird. So arbeitet die Praxis nicht und für den Juristen ist das auch nicht tragisch. Das Schuldrecht – also auch das Werkvertragsrecht – verlangt nicht, dass beim Abschluss eines Vertrags alle Details geklärt wären. Es reicht, dass sie konkretisierbar sind.
Man hat lange nach dem Planungsmodell Lastenheft-Pflichtenheft-Realisierung gearbeitet. Darüber, was ein Lasten- und was ein Pflichtenheft ist, entscheidet keine allgemein gültige Norm – die DIN oder ISO werden meistens schon deshalb nicht angewendet, weil sie veraltet sind – sondern zumeist die Festlegung der Parteien. In meiner Diktion beinhaltet das Lastenheft die groben Inhalte, Ziele und Mittel des Projektes, während das Pflichtenheft die verfeinerte Variante dieser Planung darstellt. In vielen Fällen wird das Lastenheft im Rahmen eines Workshops vor dem eigentlichen Vertragsabschluss erstellt – quasi als Draufgabe für den Kunden – während das Pflichtenheft gegen das Lastenheft realisiert wird. Im letzten Schritt wird die Software gegen das Pflichtenheft erstellt. Dabei ist es eine Frage des Geschmacks, ob allein gegen das Pflichtenheft abgenommen wird oder ob eine Verweigerung der Abnahme auch dadurch begründet werden kann, dass Vorgaben des Lastenhefts nicht eingehalten werden.
Diesem Modell werden zunehmend „Agile“ Projektmethodiken gegebenüber gestellt.
