Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

1 2004 © Dr. Werner Born / Kleiner Rechtsanwälte Phasenmodell im Projektablauf Dr. Werner H. Born, Mannheim Der IT-Systemvertrag.

Ähnliche Präsentationen


Präsentation zum Thema: "1 2004 © Dr. Werner Born / Kleiner Rechtsanwälte Phasenmodell im Projektablauf Dr. Werner H. Born, Mannheim Der IT-Systemvertrag."—  Präsentation transkript:

1 © Dr. Werner Born / Kleiner Rechtsanwälte Phasenmodell im Projektablauf Dr. Werner H. Born, Mannheim Der IT-Systemvertrag

2 © Dr. Werner Born / Kleiner Rechtsanwälte Anwendungslösung Nutzung der Standardsoftware Standardsoftware Nicht genutzte Anteile der Standardsoftware

3 © Dr. Werner Born / Kleiner Rechtsanwälte Aufwand für IT-Projekte 250 Mrd. USD Projekt-Crashs Verlust: 80 Mrd. USD 16 % der Projekte erfolgreich; allerdings wiesen nur 7 % die geplanten Funktionalitäten auf.

4 © Dr. Werner Born / Kleiner Rechtsanwälte Fall 3 Projekt erfolglos abgebrochen 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

5 © Dr. Werner Born / Kleiner Rechtsanwälte abgebrochen fehlgeschlagen erfolgreich

6 © Dr. Werner Born / Kleiner Rechtsanwälte Anteil der Projekte Grad der Kostenüberschreitung

7 © Dr. Werner Born / Kleiner Rechtsanwälte Anteil der Projekte Grad der Zeitüberschreitung

8 © Dr. Werner Born / Kleiner Rechtsanwälte Vergütung Leistungsumfang Zeit

9 © Dr. Werner Born / Kleiner Rechtsanwälte Abgleich der Ist-Beschaffenheit von der Soll-Beschaffenheit Pflichtenheft Funktionalität Pflichtenheft vom Anwender geschuldet Funktionalität vom ITU geschuldet

10 © Dr. Werner Born / Kleiner Rechtsanwälte Wie kommt man vom Standard zur spezifischen Anwendungsl ö sung?

11 © Dr. Werner Born / Kleiner Rechtsanwälte Anwendungslösung durch Prozessspezifikationen (PS) beschrieben Nutzung des Standardreferenz- modells bzw. best practises Standardsoftware Nutzung der Standardsoftware Nicht genutzte Anteile der Standardsoftware

12 © Dr. Werner Born / Kleiner Rechtsanwälte Dynamische Vertragsstrukturen

13 © Dr. Werner Born / Kleiner Rechtsanwälte Projektleitung / Qualitätssicherung Reportphase Implementierung Schulung Pilotierung und anschließend Rollout Pilotierung und anschließend Rollout Zeitliche Projektstruktur

14 © Dr. Werner Born / Kleiner Rechtsanwälte Spezifikationsgenauigkeit Zeitachse Reportphase Implementations- phase Pilotierungs- phase Rollout- phase Grob Fein

15 © Dr. Werner Born / Kleiner Rechtsanwälte Spezifikationsgenauigkeit Zeitachse Reportphase Implementations- phase Pilotierungs- phase Rollout- phase Grob Fein Report mit: Beschreibung Sollprozesse Projekt- und Budgetplan auf Basis Sollprozesse, Bildung der Projektorganisation Auftrag zur PS-Erstellung Auftrag zur PS-Realisierung Übergabe zur Abnahme (Teil)Abnahme

16 © Dr. Werner Born / Kleiner Rechtsanwälte Prozessspezifikation Zeit PS-Realisierung abgenommen PS-Realisierungs- übergabe zur Abnahme Auftrag zur PS-Erstellung PS-Erstellung mit Prozessowner auf Basis Standardsoftware und Sollprozessen Übergabe PS- Dokument Auftrag PS-Realisierung inklusive Testdaten, Testszenarien und use cases, Auftragsbestätigung PS-Realisierung PS Qualitätssicherung (Tests) auf Basis Testdaten, Testszenarien und use cases PS- Abnahmezeitraum

17 © Dr. Werner Born / Kleiner Rechtsanwälte Prozessspezifikationen Zeit TeilabnahmeRealisierungErstellung

18 © Dr. Werner Born / Kleiner Rechtsanwälte Standardsoftware Teilabnahme der aufgrund der PS n realisierten Anpassung Teilabnahme der aufgrund der PS 1 realisierten Anpassung

19 © Dr. Werner Born / Kleiner Rechtsanwälte Anwendungslösung durch PS beschrieben Standardsoftware Keine Abnahme Gesamtabnahme

20 © Dr. Werner Born / Kleiner Rechtsanwälte Change Request Management (CRM) Change Request vom Anw. oder ITU Angebot zur Überprüfung für Anwender vergütungspfli chtig Überprüfung (Projektstillstand oder Weiterlauf) Angebot zur PS-Erstellung oder PS- Abänderung Angebot zur PS-Realisierung Zusatzauftrag außerhalb oder innerhalb des Projekts PS-Realisierung PS-Erstellung oder PS-Abänderung Aufwand Zeit Vereinbarkeit mit PS

21 © Dr. Werner Born / Kleiner Rechtsanwälte CRM Change Request Management / Priorisierung Priorität 1 dringend notwendig Priorität 3 unabweisbare Änderung z.B. Änderung der betriebswirtschaftlichen Abläufe wünschenswert Priorität 2 verschiebbar Funktionalitäten, die für den Betrieb nicht erforderlich sind Korrekturen PS sind untauglich, entweder falsche Information des Anwenders oder technische Probleme

22 © Dr. Werner Born / Kleiner Rechtsanwälte CRunzulässig CRunzulässig CRM Change Request Management Zeit PS- Realisierung abgenommen Auftrag zur PS-Erstellung Auftrag PS-Realisierung CRzulässig CRzulässig

23 © Dr. Werner Born / Kleiner Rechtsanwälte Spezifikationsgenauigkeit Zeitachse Report- phase Implemen- tations- phase Pilotierungs- phase Rollout- phase Grob Fein IT-Systemvertrag Programmscheine Auftragsbestätigungen (+ PS) Helpdeskvertrag Escrow- Vereinbarung

24 © Dr. Werner Born / Kleiner Rechtsanwälte PS erstellen PS realisieren Abnahme Daten- migration Schulungen Echtbetrieb Report Eventuell iterativ da Mehrphasen Einführung Prototyp Sollprozesse

25 © 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.

26 © 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.

27 © 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.

28 © 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/Entwicklungs­system 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.


Herunterladen ppt "1 2004 © Dr. Werner Born / Kleiner Rechtsanwälte Phasenmodell im Projektablauf Dr. Werner H. Born, Mannheim Der IT-Systemvertrag."

Ähnliche Präsentationen


Google-Anzeigen