A. Einführung Begriff des IT-Projekts 29 Software nimmt heute einen unverzichtbaren Bestandteil eines jeden Unternehmens ein. Sämtliche Unternehmen verwenden Software, um damit ihren betrieblichen Alltag bewältigen zu können. Wird ein Unternehmen neu gegründet, ein bestehendes System umgestellt oder ein neuer Prozess in die Unternehmenslandschaft eingeführt, hat das betreffende Unternehmen in aller Regel eine Software anzuschaffen. Für manche Fälle reicht bereits eine Standardsoftware wie etwa ein Office-Programm aus. Häufig wird aber auch die Anpassung einer Standardsoftware an die betrieblichen Bedürfnisse des Unternehmens erforderlich sein. Darüber hinaus gibt es Fälle, in denen eine Software individuell auf die spezifischen Bedürfnisse des Betriebs hin entwickelt werden muss. Da sowohl die Anpassung als auch die Erstellung von Software eine gewisse Zeit in Anspruch nimmt, bezeichnet man diese auch als Softwareanpassungs- bzw. Softwareerstellungsprojekte. Vertraglich stehen sich meist zwei Parteien gegenüber, nämlich das Unternehmen, welches die Software benötigt, sowie ein Softwarehaus, das den Auftrag ausführt. Unter Umständen begleitet dabei den Unternehmer auch noch ein gesondert beauftragter Berater. Um ständige Wiederholungen in der Formulierung zu vermeiden, wird nachfolgend auch einerseits von Auftraggeber, Anwender oder Besteller gesprochen sowie andererseits von Auftragnehmer, Software(h)ersteller oder Anbieter. Softwareprojekte beinhalten meistens eine große wirtschaftliche Bedeutung für den Auftraggeber. Außerdem bergen sie ein hohes Risiko zu scheitern. Aufgrund häufig fehlender vertraglicher Vereinbarungen und unzureichender gesetzlicher Regelungen treten eine Vielzahl von tatsächlichen wie auch rechtlichen Fragestellungen auf. Ein Teil dieser Fragen steht im Zusammenhang mit der Leistungsbeschreibung, die auch als Lasten- bzw. Pflichtenheft bezeichnet wird. In ihr sind vereinfacht ausgedrückt die Eigenschaften und Funktionen der gewünschten Software detailliert festgehalten. Die vorliegende Arbeit befasst sich zwar ausschließlich mit der Leistungsbeschreibung bei Softwareerstellungsprojekten. Die hierbei erarbeiteten Grundlagen können allerdings auch weitgehend auf Projekte über die Anpassung von Software übertragen werden. Schwerpunkte dieser Arbeit bilden insbesondere die folgenden Problemfelder: Umstritten ist bereits, welchem Vertragstyp der Softwareerstellungsvertrag zuzuordnen ist. Besteht noch weitgehend Einigkeit darüber, die Erarbeitung des Lastenbzw. Pflichtenhefts grundsätzlich in den Verantwortungsbereich des Auftraggebers zu stellen, hat sich bisher hinsichtlich der Frage, ob und inwieweit den An-
30 Einführung bieter dabei Informations- und Mitwirkungspflichten treffen, noch keine einheitliche Linie herausgebildet. Die Rechtsansichten gehen hierbei weit auseinander. Unklar ist ferner, ob und inwieweit dem einen Vertragspartner eine Prüfungspflicht des vom anderen Teil erstellten Lasten- bzw. Pflichtenhefts obliegt. Weiter umstritten ist, ob der Anbieter die Leistungsbeschreibung nachliefern muss, wenn er deren Erarbeitung zwar vertraglich übernommen hat, jedoch ohne Lastenheft mit der Realisierung der Software beginnt. Ein weiterer kritischer Bereich liegt in Leistungsänderungen nach Vertragsabschluss, etwa, weil sich die Vorstellungen des Bestellers während des Projekts ändern. Hier ist zu entscheiden, ob und wann der Anbieter diesen Wünschen nachkommen muss. Nach einer allgemein gehaltenen Wiedergabe des Ablaufs von Softwareerstellungsprojekten (B.), einer Klärung der Terminologie (C.) und Funktionen des Lasten- bzw. Pflichtenhefts (D.) werden noch ergänzend für ein besseres Fallverständnis die unterschiedlichen Vertragskonstellationen näher dargestellt (E.), die im Rahmen eines Softwareerstellungsprojekts in Betracht kommen. Daran reihen sich die einzelnen, zum Teil bereits oben angesprochenen Problembereiche an (F.-L.). Sie werden zwar in gesonderten Gliederungspunkten abgehandelt, sind jedoch oft stark miteinander vernetzt. Bei der Lösung der angesprochenen Fallgestaltungen hilft ein Rückgriff auf das Gesetz nur sehr eingeschränkt weiter. Daher hat die Rechtsprechung vielfach allgemeine Rechtsgrundsätze herangezogen und auf den Softwarebereich übertragen. Die juristische Literatur lässt in diesem Zusammenhang eigenständige Denkansätze häufig vermissen. Sie beschränkt sich überwiegend auf die unkommentierte Wiedergabe der vorhandenen Rechtsprechung. Aus diesem Grund wird im Rahmen dieser Arbeit insbesondere die einschlägige Rechtsprechung eingehender auf ihre Schlüssigkeit hin untersucht und einer kritischen Prüfung zugeführt. Danach werden in eigenen Denkansätzen neue Lösungsmöglichkeiten vom Verfasser aufgezeigt, die den Strukturveränderungen des Marktes im Umgang und der Anschaffung von Software Rechnung tragen.
Begriff des IT-Projekts 31 B. IT-Projekte aus DV-technischer Sicht Das Lasten- bzw. Pflichtenheft stellt lediglich einen Bestandteil eines Softwareerstellungsprojekts dar. Um seine Bedeutung verstehen zu können, ist einleitend zunächst der Ablauf eines solchen Projekts in groben Zügen zu erläutern. I. Begriff des IT-Projekts Einleitend sind die Begriffe IT-Projekt sowie Software zu beschreiben: 1. IT-Projekt Der Begriff des Projektes findet sich nicht nur im Zusammenhang mit Informationstechnologie (IT), sondern ebenso in vielen anderen Bereichen. Projekte sind Aufgaben, Vorhaben und Aufträge, die wesentlich durch folgende Merkmale bestimmt werden 1 : klare Ziele, zeitliche Begrenzung durch definierte Start- und Endtermine, Lösung von neuen und unbekannten Problemen und damit Einmalig- und Neuartigkeit, limitiertes Budget, Notwendigkeit einer interdisziplinären Zusammenarbeit. Projekte sind also Vorhaben, die einer besonderen organisatorischen Gestaltung bedürfen und an deren Ende das Erreichen eines bestimmten Ergebnisses (Projektziel) steht. Im Gegensatz dazu stehen Regeltätigkeiten, also permanent durchzuführende, sich wiederholende (operative) Prozesse (eines Unternehmens) ohne eindeutig definierte Start- und Endtermine. 2 IT-Projekte beschäftigen sich mit der Entwicklung und/oder Veränderung von Informations- und Kommunikationssystemen, wozu auch die Neuentwicklung von Software zu zählen ist. 2. Software Softwareerstellungsprojekte befassen sich mit Software. Hierbei kann zwischen Standard- und Individualsoftware unterschieden werden: 1 Helmke/Höppner/Isernhagen, Einführung in die Software-Entwicklung, S. 168. 2 Wieczorrek/Mertens, Management von IT-Projekten, S. 8 f.
32 IT-Projekte aus DV-technischer Sicht a. Standardsoftware Unter Standardsoftware versteht man Software, die bereits vorgefertigt und dabei sehr allgemein gehalten ist. Sie ist nicht auf Bedürfnisse einzelner Nutzer abgestimmt, sondern soll eine möglichst große Zahl von Anwendern ansprechen. Sofern die Prozesse und Anforderungen der Anwender identisch sind, können die Software-Programme unverändert übernommen werden. Es gibt aber auch Standardsoftware, die an die individuellen, organisatorischen Gegebenheiten der Anwender anzupassen ist. 3 Praktisch jede Standardsoftware bietet bereits im Programm vorhandene Grundeinstellungen, um in einem gewissen Rahmen an die Kundenwünsche und betrieblichen Anforderungen angepasst werden zu können. Besonders häufig wird Standardsoftware daher in Bereichen eingesetzt, in denen die Geschäftsabläufe unterschiedlicher Unternehmen überwiegend identisch sind, etwa bei Verwaltungs- und Abrechnungsaufgaben. Der Einsatz einer Standardsoftware bietet gegenüber einer Individualsoftware eine Reihe von Vorteilen. Die Software ist bereits entwickelt, weshalb sie in kurzer Zeit einsetzbar ist. Die Entwicklungskosten müssen nicht von einem einzigen Auftraggeber getragen werden, sondern sind auf viele Schultern verteilt. Aus diesem Grund kann eine Standardsoftware um ein Vielfaches günstiger erworben werden als eine Individualsoftware. Dies führt folglich zu einem schnelleren Return of Investment. In der Regel ist eine Standardsoftware zudem gegenüber einer Individualsoftware auch weniger fehleranfällig, da eine ständige Überarbeitung und Weiterentwicklung der Software stattfindet. Der Auftraggeber wird daher zunächst den Markt analysieren und nach Anbieteren suchen, deren Standardsoftware seine Anforderungen abdecken kann. Manchmal kann es auch sinnvoll sein, im Rahmen des Möglichen die betrieblichen Geschäftsprozesse umgekehrt an eine Standardsoftware anzupassen. Im Rahmen der Anpassung von Software an die betrieblichen Bedürfnisse der Anwender kommen verschiedene Möglichkeiten in Betracht. Als Oberbegriff allgemein für die Anpassung von Software an Kundenwünsche und betriebliche Anforderungen wird häufig der Begriff Customizing verwendet. 4 Im Regelfall erfolgt die Anpassung von Standardsoftware durch eine Abstimmung von im 3 Etwa länderspezifische Einstellungen wie Sprache oder Währung, die Abbildung von betrieblichen Organisations-, Funktions- und Datenstrukturen oder die Abbildung (und evtl. auch Anpassung) betrieblicher Prozesse. So wird beispielsweise ein Anwender ein ERP-System (Enterprice Ressource Planning; Planung der Unternehmensressourcen) kaum unverändert übernehmen können. 4 Koch, ITRB 2004, 13; Hoeren, IT-Vertragsrecht, Rn. 356; anders aber etwa die Begriffsbestimmung in den EVB-IT System (siehe hierzu S. 59 ff.), wonach Customizing nicht die Anpassung auf Quellcodeebene erfassen soll.
Begriff des IT-Projekts 33 Programm bereits enthaltenen Einstellungsmöglichkeiten ohne eine Änderung des Programmcodes (uneinheitlich als Parametrisierung oder auch Konfigurierung bezeichnet). Die Anpassung erfolgt also durch das Drehen an Stellschrauben, die die Software bereits zur Verfügung stellt. b. Individualsoftware Da sich die Bedürfnisse einer Branche nur zu einem gewissen Grad vereinheitlichen lassen und die Anpassungsmöglichkeiten einer Standardsoftware begrenzt sind, kann ein Unternehmen auf eine Software angewiesen sein, die auf seine individuellen Bedürfnisse maßgeschneidert wird. Dies kann durch eine besondere Unternehmensstruktur ebenso veranlasst sein, wie durch die Entwicklung neuer Techniken, für die bisher keine Softwarelösungen zur Verfügung stehen. Durch den Einsatz einer Individualsoftware kann der Anwender sich aber auch Marktvorteile versprechen, indem er durch den Einsatz einer Individualsoftware innovative Lösungen verwirklichen kann, die ihn gegenüber anderen (Konkurrenz-) Unternehmen bevorteilen. Die Anschaffung einer Individualsoftware muss dabei nicht unbedingt die Erstellung einer von Grund auf neuen Software bedeuten. Heute erfolgt die Erstellung einer Individualsoftware zum großen Teil auch auf Basis einer bereits vorhandenen Standardsoftware (z.b. Bibliotheksprogrammen), deren Quellcode in großem Umfang geändert und ergänzt wird. 5 Je nach Umfang der Anpassung wird aus der Standardsoftware dann eine Individualsoftware. Dem Vorteil einer individuell erstellten Softwarelösung stehen allerdings auch einige Nachteile gegenüber. Der Auftraggeber hat gegenüber einer Standardlösung mit erheblich höheren Kosten zu rechnen. Daneben ist auch die Pflege einer Individualsoftware aufwändiger als bei einer Standardlösung. Ein weiterer Nachteil besteht darin, dass die Entwicklung einer Individualsoftware in der Regel mehr Zeit beansprucht als die Anpassung einer Standardsoftware. Ferner muss ein Auftraggeber die Möglichkeit des Scheiterns eines Softwareerstellungsprojekts berücksichtigen, das im schlimmsten Fall bedeuten kann, dass er nach Jahren der Entwicklung überhaupt keine Software in den Händen hält. 5 Redeker in: Schneider/v. Westphalen, Software-Erstellungsverträge, D. Rn. 43; derselbe, IT-Recht, B. Rn. 288.
34 IT-Projekte aus DV-technischer Sicht II. Scheitern von IT-Projekten Bei Softwareerstellungsprojekten besteht eine sehr hohe Gefahr des Scheiterns. 6 Als erfolgreich gilt ein Projekt, wenn die Projektziele innerhalb der vorgegebenen Zeit erreicht werden und das vorgegebene Budget nicht überschritten wird. 7 Im Umkehrschluss ist von einem Scheitern des Projektes auszugehen, wenn einer dieser drei Faktoren eklatant überschritten wird. Denn auch ein technisch überragendes Projektergebnis hat in der Regel für den Auftraggeber nicht den gewünschten Nutzen, wenn es seine finanziellen Mittel übersteigt. Man wird wohl davon ausgehen können, dass große Projekte proportional weit häufiger scheitern als kleinere Projekte, aber dennoch seltener vor Gericht gebracht werden. 8 Überragend hoch ist daher die Anzahl der gescheiterten Projekte. Der Beratungsfirma IAG Consulting zufolge seien noch immer 68% aller IT-Projekte als gescheitert zu betrachten. 9 Nach einer Umfrage der Standish Group im Jahr 2000 sollen sogar nur 28% der Projekte den versprochenen Leistungsumfang zum geplanten Zeitpunkt, im geplanten Budget und mit der spezifizierten Qualität erreicht haben. 10 III. Ablauf eines Softwareerstellungsprojektes Um der Gefahr eines Projektscheiterns entgegen zu wirken, sind verschiedene systematische Methoden zur Vorgehensweise entwickelt worden. Denn um ein durchschnittliches oder komplexes Projekt zum Erfolg zu führen, ist ein planmäßiger Projektablauf unerlässlich, wohingegen bei kleinen Projekten eher die Qualifikation der einzelnen Programmierer über einen erfolgreichen Projektabschluss entscheidet. Häufig wird die Komplexität der Projekte unterschätzt und auf ein systematisches Vorgehen verzichtet. 11 Daraus folgt regelmäßig ein Scheitern des Projektes. Im Interesse aller Beteiligten sollte das Projekt daher 6 Zu den Gründen des Scheiterns ausführlich etwa Zahrnt, CR 2000, 402 ff.; Koch, IT- Projektrecht, Rn. 378 ff.; zu Risikominimierung durch vertragliche Regelungen: Müller-Hengstenberg, CR 2005, 385 ff.; vgl. auch derselbe, CR 1995, 198 ff. 7 Wieczorrek/Mertens, Management von IT-Projekten, S. 18. 8 Schneider, Handbuch des EDV-Rechts, D. Rn. 13. 9 Schmitt, 68 Prozent aller IT-Projekte scheitern, Blog vom 17.12.2008, abrufbar unter: www.silicon.de/ cio/strategie/0,39038989,39200412,00/68_prozent_aller_it_projekte_ scheitern.htm. 10 Koch, IT-Projektverträge rechtssicher gestalten, S. 41, Skript, abrufbar unter: www.anwaltskanzlei-koch.info/it-projektvertrage_rechtssicher_gestalten.pdf; zur Sanierung von zum Scheitern drohenden IT-Projekten siehe ausführlich: Streitz, IT- Projekte retten. 11 Brössler/Siedersleben, Softwaretechnik, S. 290.
Ablauf eines Softwareerstellungsprojektes 35 zunächst ausführlich und detailliert geplant werden. Einer Untersuchung von Zahrnt zufolge sollen 39,9 % der Ursachen für ein Scheitern bereits bei Vertragsschluss gesetzt werden, von denen die Hälfte auf unklare Ziele und Aufgabenstellungen zurückzuführen sei. 12 1. Vorgehensmodelle Der Ablauf eines IT-Projekts muss nicht bestimmten festgelegten Vorgaben folgen. Letztlich liegt es im Ermessen der Projektleitung, die Projektdurchführung zu organisieren. Im Laufe der Zeit haben sich jedoch Leitfaden-Modelle entwickelt, die die Durchführung eines Projektes erleichtern und die Chancen eines erfolgreichen Abschlusses verbessern sollen. Man spricht in diesem Zusammenhang von sogenannten Vorgehensmodellen. Unter einem Vorgehensmodell versteht man einen zeitlich und sachlich ausgefeilten Plan, der die Reihenfolge einzelner Schritte sowie deren jeweilige Ergebnisse festlegt und an dem sich die Mitarbeiter des Projekts orientieren. Das Vorgehensmodell regelt, wer wann was zu tun hat. Das IT-Projekt wird hierdurch in überschaubare, zeitlich und inhaltlich begrenzte Aktivitäten gegliedert (sog. Phasen). 13 Dadurch soll eine weitgehende Planbarkeit und Kontrollierbarkeit des Projektes sowie eine höhere Qualität der Projektergebnisse gewährleistet werden. Es gibt eine Vielzahl unterschiedlicher Modell-Typen, die alle ihre Vor- und Nachteile haben. Welches Modell das richtige ist, hängt vom jeweiligen Projekt und den daran beteiligten Personen ab. Hat sich der Projektleiter für ein Modell entschieden, ist er nicht einer statischen und eindimensionalen Bindung unterworfen. 14 Häufig kann es sinnvoll sein, von den Vorgaben des Vorgehensmodells abzuweichen, indem bestimmte Teilschritte ausgelassen oder hinzugefügt werden, um es an die spezifischen Erfordernisse des Projektes anzupassen (sog. Tailoring). 15 Aufgrund der Vielzahl unterschiedlicher Vorgehensmodelle und ihrem jeweiligen Tailoring seien beispielhaft folgende Modelle kurz angesprochen: Viele Vorgehensmodelle bauen auf dem sog. Phasenmodell auf. Dieses gliedert den Projektverlauf inhaltlich sowie zeitlich und verschafft ihm damit eine bessere Übersicht und Transparenz. In den einzelnen Phasen wird festgelegt, wann welche konkreten Ergebnisse erreicht werden sollen (sog. Milestones). Zur nächsten Phase kann erst übergegangen werden, wenn das Ergebnis 12 Zahrnt, CR 2000, 402, 405. 13 Helmke/Höppner/Isernhagen, Einführung in die Software-Entwicklung, S. 170. 14 Helmke/Höppner/Isernhagen, Einführung in die Software-Entwicklung, S. 170. 15 Wieczorrek/Mertens, Management von IT-Projekten, S. 51.