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.