Phasenmodell im Projektablauf Dr. Werner H. Born, Mannheim Der IT-Systemvertrag Phasenmodell im Projektablauf Dr. Werner H. Born, Mannheim 2004 © Dr. Werner Born / Kleiner Rechtsanwälte
Nutzung der Standardsoftware Anwendungslösung Nutzung der Standardsoftware Nicht genutzte Anteile der Standardsoftware 2004 © Dr. Werner Born / Kleiner Rechtsanwälte
Aufwand für IT-Projekte 250 Mrd. USD 55.000 Projekt-Crashs Verlust: 80 Mrd. USD 16 % der Projekte erfolgreich; allerdings wiesen nur 7 % die geplanten Funktionalitäten auf. 2004 © Dr. Werner Born / Kleiner Rechtsanwälte
Projekt erfolgreich beendet innerhalb Zeit, Vergütung und Fall 1 Projekt erfolgreich beendet innerhalb Zeit, Vergütung und Leistungsumfang Fall 2 Projekt fehlgeschlagen 94 % Projekt-Neustart Kostenüberschreitung um 89 % Zeitüberschreitung um 122 % 61 % der geplanten Funktionalitäten umgesetzt Fall 3 Projekt erfolglos abgebrochen 2004 © Dr. Werner Born / Kleiner Rechtsanwälte
fehlgeschlagen erfolgreich abgebrochen 2004 © Dr. Werner Born / Kleiner Rechtsanwälte
Anteil der Projekte Grad der Kostenüberschreitung 2004 © Dr. Werner Born / Kleiner Rechtsanwälte
Anteil der Projekte Grad der Zeitüberschreitung 2004 © Dr. Werner Born / Kleiner Rechtsanwälte
Leistungsumfang Vergütung Zeit 2004 © Dr. Werner Born / Kleiner Rechtsanwälte
Pflichtenheft Funktionalität Pflichtenheft vom Anwender geschuldet Abgleich der Ist-Beschaffenheit von der Soll-Beschaffenheit Funktionalität Funktionalität vom ITU geschuldet 2004 © Dr. Werner Born / Kleiner Rechtsanwälte
spezifischen Anwendungslösung? Wie kommt man vom Standard zur spezifischen Anwendungslösung? 2004 © Dr. Werner Born / Kleiner Rechtsanwälte
Anwendungslösung durch Prozessspezifikationen (PS) beschrieben Standardsoftware Anwendungslösung durch Prozessspezifikationen (PS) beschrieben Nutzung des Standardreferenz-modells bzw. best practises Nutzung der Standardsoftware Nicht genutzte Anteile der Standardsoftware 2004 © Dr. Werner Born / Kleiner Rechtsanwälte
Dynamische Vertragsstrukturen 2004 © Dr. Werner Born / Kleiner Rechtsanwälte
Zeitliche Projektstruktur Projektleitung / Qualitätssicherung Reportphase Implementierung Pilotierung und anschließend Rollout Schulung 2004 © Dr. Werner Born / Kleiner Rechtsanwälte
Grob Fein Zeitachse Spezifikationsgenauigkeit Reportphase Implementations- phase Pilotierungs- phase Rollout- phase Fein 2004 © Dr. Werner Born / Kleiner Rechtsanwälte
Grob Fein Zeitachse Spezifikationsgenauigkeit Report mit: Beschreibung Sollprozesse Projekt- und Budgetplan auf Basis Sollprozesse, Bildung der Projektorganisation Grob Reportphase Auftrag zur PS-Erstellung Auftrag zur PS-Realisierung Implementations- phase Übergabe zur Abnahme (Teil)Abnahme Pilotierungs- phase Rollout- phase Fein 2004 © Dr. Werner Born / Kleiner Rechtsanwälte
Prozessspezifikation Zeit Prozessspezifikation PS-Realisierung abgenommen Auftrag zur PS-Erstellung PS-Abnahmezeitraum PS-Erstellung mit Prozessowner auf Basis Standardsoftware und Sollprozessen PS-Realisierungs- übergabe zur Abnahme PS Qualitätssicherung (Tests) auf Basis Testdaten, Testszenarien und use cases Übergabe PS-Dokument Auftrag PS-Realisierung inklusive Testdaten, Testszenarien und use cases, Auftragsbestätigung PS-Realisierung 2004 © Dr. Werner Born / Kleiner Rechtsanwälte
Prozessspezifikationen Zeit Erstellung Realisierung Teilabnahme 2004 © Dr. Werner Born / Kleiner Rechtsanwälte
Teilabnahme der aufgrund der PS 1 realisierten Anpassung Standardsoftware Teilabnahme der aufgrund der PS 1 realisierten Anpassung Teilabnahme der aufgrund der PS n realisierten Anpassung 2004 © Dr. Werner Born / Kleiner Rechtsanwälte
Anwendungslösung durch PS beschrieben Standardsoftware Anwendungslösung durch PS beschrieben Gesamtabnahme Keine Abnahme 2004 © Dr. Werner Born / Kleiner Rechtsanwälte
Change Request Management Angebot zur Überprüfung für Anwender vergütungspflichtig Change Request vom Anw. oder ITU Überprüfung (Projektstillstand oder Weiterlauf) Change Request Management (CRM) PS-Realisierung PS-Erstellung oder PS-Abänderung Aufwand Zeit Vereinbarkeit mit PS Angebot zur PS-Erstellung oder PS-Abänderung Angebot zur PS-Realisierung Zusatzauftrag außerhalb oder innerhalb des Projekts 2004 © Dr. Werner Born / Kleiner Rechtsanwälte
CRM Change Request Management / Priorisierung unabweisbare Änderung z.B. Änderung der betriebswirtschaftlichen Abläufe Priorität 1 notwendig Korrekturen PS sind untauglich, entweder falsche Information des Anwenders oder technische Probleme dringend Priorität 2 verschiebbar Funktionalitäten, die für den Betrieb nicht erforderlich sind wünschenswert Priorität 3 2004 © Dr. Werner Born / Kleiner Rechtsanwälte
CRM CR unzulässig CR zulässig Zeit Change Request Management PS-Realisierung abgenommen Auftrag zur PS-Erstellung CR unzulässig CR zulässig Auftrag PS-Realisierung 2004 © Dr. Werner Born / Kleiner Rechtsanwälte
Grob Fein „IT-Systemvertrag“ Zeitachse Spezifikationsgenauigkeit Programmscheine Grob Auftragsbestätigungen (+ PS) Report-phase Helpdeskvertrag Implemen- tations- phase Escrow-Vereinbarung Pilotierungs- phase Rollout- phase Fein 2004 © Dr. Werner Born / Kleiner Rechtsanwälte
Eventuell iterativ da Mehrphasen Einführung Echtbetrieb Schulungen Abnahme Daten- migration Eventuell iterativ da Mehrphasen Einführung PS realisieren PS erstellen Report Prototyp Sollprozesse 2004 © Dr. Werner Born / Kleiner Rechtsanwälte
§ 1 Projekt Unter Projekt verstehen die Vertragsparteien als Oberbegriff die in einem Report noch zu beschreibende Anwendungslösung für das vom Anwender geplante Vorhaben und die Implementierung der vereinbarten Anwendungslösung auf einem Test/Entwicklungssystem auf der Basis der Standardsoftware in den Anwendungsbereichen: ______________ Das Projekt wird in folgende Phasen unterteilt. Die erste Phase dient der Erstellung eines Reports (Grobkonzept), der eine grobe Beschreibung der Anwendungslösung beinhaltet. Diese Phase dient insbesondere dazu, dem Anwender Gelegenheit zu geben, die Standardsoftware im Detail zu begutachten und sie als für seine Einsatzzwecke auf Tauglichkeit hin zu überprüfen. Der Report beinhaltet im Einzelnen eine Struktur der Prozessspezifikationen und eine grobe Abschätzung des zeitlichen Ablaufs in Form eines Projektplans und eine Abschätzung des Gesamtbudgets. In diese Phase fällt ferner die Erstellung eines Anwenderspezifischen Prototypen für die Durchführung des Lasttestes. Diese Phase wird als Reportphase bezeichnet. In der zweiten Phase werden die Prozessspezifikationen für das Projekt erstellt, die den gesamten möglichen Leistungsumfang der Anpassungen umfassen. Die zur Realisierung beauftragten Prozessspezifikationen bestimmen letztendlich den vom Anwender zu erbringenden Leistungsumfang. Zur zweiten Phase zählen mithin die Beauftragung zur Realisierung der Prozessspezifikationen, deren Teilabnahme und auch die Endabnahme. Die zweite Phase wird Implementationsphase genannt. Ergänzend verstehen die Parteien unter der dritten Phase alle Leistungen, die im Zusammenhang mit dem Rollout stehen (Rolloutphase). Unter dem Begriff Rollout verstehen die Parteien, das Produktivsetzen des Systems und die Aufschaltung der Endanwender. 2004 © Dr. Werner Born / Kleiner Rechtsanwälte
Nicht mehr unter das Projekt fallen Anwendungsbereiche, die nicht im Report aufgeführt sind und/oder zusätzlich beauftragte Anpassungen und sonstige Leistungen, die Funktionalitäten betreffen, die nicht im Report oder den Prozessspezifikationen beschrieben sind (= Zusatzaufträge). Soweit der Anwender Zusatzaufträge erteilt, die separate Anwendungsbereiche betreffen und nicht mit dem vorstehend bezeichneten Projekt zusammenhängen und auch nicht in dem Report aufgeführt werden, bestehen keine technischen, wirtschaftlichen und rechtlichen Abhängigkeiten der Zusatzaufträge von dem Projekt. Nicht mehr unter das Projekt fallen ferner Anforderungswünsche des Anwenders, die eine Prozessspezifikation nach deren Fertigstellung ergänzen oder abändern, es sei denn, es handelt sich um die Beseitigung eines Fehlers. Die Projektleiter können entscheiden, ob die Änderungswünsche als Zusatzauftrag oder Leistungsänderung behandelt werden. Können sich die Projektleiter nicht einigen, werden die Änderungswünsche in der Projektdatenbank gesammelt und die unterschiedlichen Auffassungen der Projektleiter festgehalten. Über die gesammelten Punkte wird dann im Lenkungsausschuss eine Einigung gesucht. Kommt eine Einigung nicht zustande, verbleibt es bei dem bisherigen Projektumfang. Der Anwender ist berechtigt, alle oder einzelne der im Report genannten Prozessspezifikationen zur Erstellung in Auftrag zu geben. Der Report ersetzt alle anderen Dokumente, insbesondere Zwischenstufen, Anforderungskataloge oder Ähnliches. Der Report ist für das Projekt nicht abschließend, wohl aber für die Bestimmung des Umfangs der möglichen Leistungsverpflichtung von ITU zur Anpassung des Standardreferenzmodells. ITU ist nicht verpflichtet, den Report im Ganzen umzusetzen. Der Anwender ist nicht verpflichtet, den gesamten im Report genannten und von ITU für erbringbar erklärten Leistungsanteil in Auftrag zu geben. 2004 © Dr. Werner Born / Kleiner Rechtsanwälte
Der Anwender trägt die Verantwortung, dass sein Bedarf richtig und vollständig an ITU übermittelt worden ist. Für die genannten Anwendungsbereiche werden die Beschaffenheiten der Standardsoftware mit den Anforderungen des Anwenders gemeinsam abgeglichen. Dies geschieht in der Weise, dass ITU den Projektteams des Anwenders im Rahmen der Reportphase die Standardsoftware vorstellen wird, damit die Projektteams des Anwenders in der Lage sind, ihre Erwartungshaltungen mit der Standardsoftware abzugleichen und die aus ihrer Sicht etwaigen erforderlichen Anpassungen des Standardreferenzmodells und/oder der Standardsoftware in Bezug auf die Prozessbeschreibungen und die Dialoge (Masken) mitzuteilen, bzw. eine Übereinstimmung zu signalisieren. Aufgrund dieser Spezifizierung wird ITU prüfen, ob und wenn ja, welche der vom Anwender spezifizierten Abweichungen von der Standardsoftware erfüllt werden können. Das Ergebnis der technisch möglichen Anpassungen wird ITU ausschließlich in einem Report dergestalt festhalten, dass mindestens alle aus Sicht von ITU derzeit technisch durchführbaren Anpassungen erfasst sind. Die technisch möglichen Anpassungen werden thematisch strukturiert. Die Themenkreise werden im Report aufgeführt und zur späteren Identifikation im Projekt mit Nummern versehen. Diese Themenkreise und Nummern stellen die PS-Überschriften und PS-Nummern dar. 2004 © Dr. Werner Born / Kleiner Rechtsanwälte
§ 2 Prozessspezifikationen Unter Prozessspezifikationen (PS) verstehen die Vertragsparteien die Anwenderspezifikation und damit die Beschaffenheitsvereinbarung als eine Feinbeschreibung der im Report bereits genannten Anpassungen von ITU. Soweit zu einzelnen Kapiteln oder Punkten des Reports gleichzeitig oder später eine Prozessspezifikation erstellt wird, ersetzt diese Prozessspezifikation in jedem Fall den Report oder andere Dokumente. Auf der Grundlage des Reports erteilt der Anwender Aufträge zur Erstellung einer PS und gegebenenfalls im Anschluss Aufträge zur Realisierung einer PS. ITU wird die jeweiligen Aufträge mit Auftragsbestätigungen bestätigen. ITU schuldet nur diejenigen Leistungen, die in einer zur Realisierung beauftragten PS beschrieben sind. ITU wird die realisierten PS dem Anwender auf dem mit dem Anwender vereinbarten Test/Entwicklungssystem installiert zur Verfügung stellen. Der Anwender ist für die Dokumentation der Anpassungen verantwortlich. Aufträge zur Realisierung einer PS setzen voraus, dass der Anwender vorab Testdaten, Testszenarien und use cases zur Verfügung gestellt hat. ITU wird die Prozessspezifikation ausschließlich auf ihre technische Realisierbarkeit hin überprüfen und gegebenenfalls notwendige Änderungen vornehmen. Es obliegt allein dem Anwender für ordnungsgemäß gepflegte Testdaten, Testszenarien und use cases und die geeignete Datenverarbeitungsanlage zu sorgen. 2004 © Dr. Werner Born / Kleiner Rechtsanwälte