Upload
carl-blitz
View
109
Download
1
Embed Size (px)
Citation preview
2004 © Dr. Werner Born / Kleiner Rechtsanwälte 1
Phasenmodell im Projektablauf
Dr. Werner H. Born, Mannheim
Der IT-Systemvertrag
2004 © Dr. Werner Born / Kleiner Rechtsanwälte 2
Anwendungslösung
Nutzung der Standardsoftware
Standardsoftware
Nicht genutzte Anteile der Standardsoftware
2004 © Dr. Werner Born / Kleiner Rechtsanwälte 3
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 4
Fall 3 31%
Fall 1 16%
Fall 2 53%
Fall 3 Projekt erfolglos abgebrochen
Fall 1 Projekt erfolgreich beendetinnerhalb Zeit, Vergütung
undLeistungsumfang
Fall 2Projekt fehlgeschlagen94 % Projekt-NeustartKostenüberschreitung um 89 % Zeitüberschreitung um 122 % 61 % der geplanten Funktionalitätenumgesetzt
2004 © Dr. Werner Born / Kleiner Rechtsanwälte 5
31
53
16
4033
27 28
46
2623
49
28
%
%
%
%
%
%
%
1994 1996 1998 2000
abgebrochen
fehlgeschlagen
erfolgreich
2004 © Dr. Werner Born / Kleiner Rechtsanwälte 6
Anteilder Projekte
0%
5%
10%
15%
20%
25%
30%
35%
bis 20% 21-50% 51-100% 101-200%
201-400%
über400%
Grad der Kostenüberschreitung
2004 © Dr. Werner Born / Kleiner Rechtsanwälte 7
0%
5%
10%
15%
20%
25%
30%
35%
bis20%
21-50% 51-100%
101-200%
201-400%
über400%
Anteilder Projekte
Grad der Zeitüberschreitung
2004 © Dr. Werner Born / Kleiner Rechtsanwälte 8
Vergütung
Leistungsumfang
Zeit
2004 © Dr. Werner Born / Kleiner Rechtsanwälte 9
Abgleich der Ist-Beschaffenheit von der Soll-Beschaffenheit
PflichtenheftPflichtenheft
FunktionalitätFunktionalität
Pflichtenheft vom Anwender geschuldet
Funktionalität vom ITU geschuldet
2004 © Dr. Werner Born / Kleiner Rechtsanwälte 10
Wie kommt man vom
Standard
zur
spezifischen Anwendungslösung?
2004 © Dr. Werner Born / Kleiner Rechtsanwälte 11
Anwendungslösung durch Prozessspezifikationen (PS) beschrieben
Nutzung des Standardreferenz-modells bzw. best practises
Standardsoftware
Nutzung der Standardsoftware
Nicht genutzte Anteile der Standardsoftware
2004 © Dr. Werner Born / Kleiner Rechtsanwälte 12
Dynamische
Vertragsstrukturen
2004 © Dr. Werner Born / Kleiner Rechtsanwälte 13
Projektleitung / QualitätssicherungProjektleitung / Qualitätssicherung
ReportphaseReportphase ImplementierungImplementierung
SchulungSchulung
Pilotierung undanschließendRollout
Pilotierung undanschließendRollout
Zeitliche Projektstruktur
2004 © Dr. Werner Born / Kleiner Rechtsanwälte 14
SpezifikationsgenauigkeitZeitachse
Reportphase
Implementations-phase
Pilotierungs-phase
Rollout-phase
Grob
Fein
2004 © Dr. Werner Born / Kleiner Rechtsanwälte 15
SpezifikationsgenauigkeitZeitachse
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
2004 © Dr. Werner Born / Kleiner Rechtsanwälte 16
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ätigungPS-Realisierung
PS Qualitätssicherung (Tests) auf Basis Testdaten, Testszenarien und use cases
PS-Abnahmezeitraum
2004 © Dr. Werner Born / Kleiner Rechtsanwälte 17
ProzessspezifikationenZeit
TeilabnahmeRealisierungErstellung
2004 © Dr. Werner Born / Kleiner Rechtsanwälte 18
Standardsoftware
Teilabnahme der aufgrund der PS n realisierten Anpassung
Teilabnahme der aufgrund der PS 1 realisierten Anpassung
2004 © Dr. Werner Born / Kleiner Rechtsanwälte 19
Anwendungslösung durch PS beschrieben
Standardsoftware
Keine Abnahme
Gesamtabnahme
2004 © Dr. Werner Born / Kleiner Rechtsanwälte 20
Change Request Management
(CRM)
Change Request vom Anw. oder ITU
Angebot zur Überprüfung für Anwender vergütungspflichtig
Überprüfung(Projektstillstand oder Weiterlauf)
Angebot zur PS-Erstellung oder PS-Abänderung
Angebot zur PS-RealisierungZusatzauftrag außerhalb oder innerhalb des Projekts
PS-Realisierung
PS-Erstellung oder PS-AbänderungAufwandZeitVereinbarkeit mit PS
2004 © Dr. Werner Born / Kleiner Rechtsanwälte 21
CRM Change Request Management / Priorisierung
Priorität 1
dringend
notwendig
Priorität 3
unabweisbare Änderungz.B. Änderung der betriebswirtschaftlichen Abläufe
wünschenswert
Priorität 2
verschiebbarFunktionalitäten, die für den Betrieb nicht erforderlich sind
KorrekturenPS sind untauglich, entweder falsche Information des Anwenders oder technische Probleme
2004 © Dr. Werner Born / Kleiner Rechtsanwälte 22
CRunzulässigCRunzulässig
CRMChange Request Management
Zeit
PS-Realisierung abgenommen
Auftrag zur PS-Erstellung
Auftrag PS-Realisierung
CRzulässig
CRzulässig
2004 © Dr. Werner Born / Kleiner Rechtsanwälte 23
SpezifikationsgenauigkeitZeitachse
Report-phase
Implemen-tations-phase
Pilotierungs-phase
Rollout-phase
Grob
Fein
„IT-Systemvertrag“
Programmscheine
Auftragsbestätigungen(+ PS)
Helpdeskvertrag
Escrow-Vereinbarung
2004 © Dr. Werner Born / Kleiner Rechtsanwälte 24
PS erstellen
PS realisieren
Abnahme
Daten-migration
Schulungen
Echtbetrieb
Report
Eventuell iterativ
da Mehrp
hasen Einführu
ng
PrototypSollprozesse
2004 © Dr. Werner Born / Kleiner Rechtsanwälte 25
§ 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 26
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 27
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 28
§ 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.