It Projekte

IT - Projektrisiko

U. Schrader

Arten des Scheiterns

Erforderliche Funktionalität fehlt Kostenrahmen gesprengt Zeitrahmen gesprengt

Gescheiterte Projekte

USA 72% im Jahr 2000 mit abnehmender

Tendenz bei Großunternehmen (Standish Group)

UK 80% im Zeitraum 1994-1995

(OASIG-Studie) Anstieg in Richtung 90% für 2000 und

2001 (Silicon)

Gescheiterte Projekte

D zwei Drittel der Unternehmen mit einem

durchschnittlichen Umsatz von € 1,02 Mrd. geben an, eBusiness-Projekte bringen weder Senkung der Kosten noch Steigerung des Unternehmenserfolges(Cap Gemini und Universität Trier)

CH Scheiterquote über 50% in 2000 steigend

(Schweiz. Bundesamt f. Berufsbildung und Technologie)

Hauptauswahlkriterien beiIT-Projekten

0 10 20 30 40 50 60 70

Risikoverteilung/Projektrisiko

Technologisches Risiko

Kosten

Technischer Fit

Abhäng. m. a. Projekten

Strategisches Fit

Nutzen

Return of Investment (ROI)

Quelle: Bearingpoint Umfrage zitiert in Computer Zeitung 32-33/2003

%

Kosten IT

70% Wetware Menschen (Entscheidungsunterstützung,

Planung, Einkauf, Schulung, Support, Einführung, Fehlersuche, Fehlbedienung, Fehlerfolgen)

20% Hardware 10% Software Schätzung Gardner

(15000 $/a pro Arbeitsplatz, for-profits, ca. Mitte 1990)

Plan

Analysieren

Entwickeln

KaufenImplementieren

In Betriebhalten

Problem zu lösenProblem überflüssig

Ähnliches Problem

Neue Lösung für dasselbe ProblemIst-Analyse und

AnforderungskatalogBeseitigen von

Implementierungsfehlern

RISIKO PHASE 1

RISIKO PHASE 2RISIKO PHASE 3

RISIKO PHASE 4

nach Whitten JL, Benthley LD. Systems and design methods. McGraw-Hill, 1998

Plan

Analysieren

Entwickeln


In Betriebhalten


Ähnliches Problem




RISIKO PHASE 1


RISIKO PHASE 4


Plan

Analysieren

Entwickeln


In Betriebhalten


Ähnliches Problem


Anforderungskatalog

Beseitigen vonImplementierungsfehlern

RISIKO PHASE 1


RISIKO PHASE 4


Plan

Analysieren

Entwickeln


In Betriebhalten


Ähnliches Problem




RISIKO PHASE 1


RISIKO PHASE 4


Software - Lebenszyklus

Phase 1 Ist-Analyse, Soll-Konzept

Verzeichnis der Anforderungen Phase 2

Beschaffung/Realisierung eines Produktes Phase 3

Einführung/Implementierung/Parametrisierung Phase 4

Aufrechterhaltung des laufenden Betriebs

Literatur (1)

Ammenwerth, E.; Eichstädter U.; Schrader, U.: EDV in der Pflegedokumentation – Ein Leitfaden für Praktiker. Schlüterscher Verlag, Hannover 2003.

GMDS, ADS, AKI, DBfK. Checkliste für die Projektierung eines DV-gestützten Pflegeinformationssystems. Eigenverlag: Köln, Eschborn, Göttingen. http://www.health-informatics.de/gmds_ni.

Hacker, W.; Scheuch, K.; Kunath, H.; Haux, R.: Computer in der Krankenpflege. Roderer, Regensburg 1999.

Hannah, K.J.; Ball, M.J.; Edwards, M.J.A.; Hübner, U.: Pflegeinformatik. Springer, Heidelberg 2002.

Literatur (2) Haux, R.; Lagemann, A.; Knaup, P.; Schmücker, P.;

Winter, A.: Management von Informationssystemen. Teubner-Verlag, Stuttgart 1998.

Goossen, W.T.F.: Pflegeinformatik. Ullstein Medical, Wiesbaden 1998.

Peltzer M.: Unternehmenserfolg und Informationsmanagement: Wettbewerbsvorteile durch Interaktionsfähigkeit und Prozessgestaltung. Addision-Wesley, Bonn 1992.

Trill R.: Informationstechnologie im Krankenhaus: Strategien, Auswahl, Einsatz. Luchterhand, 2002.

Erfolgreiche IT-Projekte

Die Abhängigkeiten

Die einzelnen Schritte

Die beliebtesten Fehler

Wie bekommt man ein Projekt?

Abhängigkeiten

IT-ProjektVorhandeneHardware

VorhandeneProgramme

Organisatorische Strukturen

Geld $$

Zieleder Einrichtung

IT Infrastruktur

VorgehensweisenRichtlinienStandards

Menschen

ArbeitsabläufeDatenfluß

Zeitplan

Verkäufer

Produkte

Anwender

1. Beginnen

Aufbau einer Projektgruppe Finden einer gemeinsamen Vision Informationssammlung

Existierende Systeme, Richtlinien, Standards, Datenfluß, Arbeitsabläufe

Stärken und Schwächen der gegenwärtigen Lösung Was soll erhalten, geändert, automatisiert oder eliminiert werden

Funktionelle Anforderungen Erwartungen formen - Jeden informieren! Untersuchung des Marktes

Literaturstudium, Vergleiche, Firmeninformationen, Kollegen

Beauftragung externer Experten, Berater?

Aufbau einer Projektgruppe

Kompetente Mitarbeiter Ausreichend freigestellt für die Mitarbeit Projektarbeit muß hohe Priorität haben Rollen und Verantwortlichkeiten müssen

definiert werden Berechtigt Entscheidungen zu treffen

Den vollständigen Prozeß repräsentieren!

• Vor der Auswahl und Einführung von EDV stellen sich eine Reihe von Fragen:

• Wie sind die derzeitigen Abläufe in der Praxis? • Was sind derzeitige Schwachstellen?• Welche Probleme kann man mit einem EDV-System

lösen?• Brauche ich überhaupt eine EDV-System?• Was sollte das EDV-System können?• Welche EDV-Kenntnisse haben die Pflegekräfte?• Welche EDV-Ausstattung ist schon vorhanden?• .....

Systemanalyse – Wozu?

Nach E. Ammenwerth

• Viele dieser Fragen kann man nur Vor Ort beantworten.

• Daher wird (mehr oder weniger systematisch) immer eine Vor-Ort-Erhebung („Systemanalyse“) durchgeführt.

• Die Systemanalyse sollte gut vorbereitet sein und zielgerichtet erfolgen!• Klärung der Bereiche bzw. Aufgaben, die man sich näher

anschauen möchte. • Aufstellen einer Liste von Fragen, die beantwortet werden

sollen.

Systemanalyse – Wozu?

Nach E. Ammenwerth

Mündliche Befragungen (Interview)Zeitaufwändig, gibt aber oft einen vertieften Einblick in die Praxis und ermöglicht Nachfragen.

Schriftliche Befragungen (Fragebögen)Ermöglicht die gleichzeitige Befragung einer größeren Anzahl an Personen, erlaubt nur vorbereitete Fragen.

Eigene BeobachtungenZeitaufwändig, ermöglicht dafür aber einen eigenen Eindruck von der Praxis, kann gut mit Interviews verbunden werden.

Systemanalyse – Methoden

Nach E. Ammenwerth

In der Regel werden die verschiedenen Methoden miteinander verbunden, also z.B.:

• Derzeitige Abläufe: Beobachtungen + Interviews.• Aktuelle Schwachstellen: Interviews.• EDV-Kenntnisse und Schulungsbedarf: Fragebögen.• EDV-Ausstattung: Beobachtung.

Systemanalyse – Methoden

Nach E. Ammenwerth

• Die Ergebnisse einer Systemanalyse sollten schriftlich festgehalten werden.• Als Basis für den weiteren Projektverlauf.• Als Informationsquelle für alle Beteiligten.

• Die Darstellung kann als Text erfolgen, häufig ist aber eine zusätzliche grafische Aufbereitung hilfreich.

Systemanalyse: Ergebnisse

Nach E. Ammenwerth

Daten- und InformationsflussFormularanalyseFormularname:

Person/Rolle Person/Rolle Person/Rolle Person/Rolle Person/RolleBedeutung/Zweck

Feld 1

Feld 2

Feld 3

Feld 4

Zweck:

Bemerkung:

(E)rfassen, (L)esen, (Ä)ndern, (L)öschen, Sonstig

Nach E. Ammenwerth

Sekretariat

„Postraum“

Oberarztzimmer

Brief diktieren Assistenzarzt Kassette 1. VersionKrankenakteArztzimmer

Kassette ins Fach legen

Kassette abholen

schreiben/ändern/speichern

Brief in Arzt-Fach legen

Brief in OA-Fach legen

2.-4. Version

Endversion

PC

Brief (Papier)

Brief (Papier)

Brief drucken

kontrollieren

kontrollieren

Brief unterschreiben

Brief in Arzt-Fach legen

Brief unterschreiben

Brief Sekretariat geben

Sekretärin

Assistenzarzt

Oberarzt

Assistenzarzt

Sekretärin

Arztzimmer

„Postraum“

„Postraum“

Arztzimmer

„Postraum“

Ort Prozess Hilfsmittel (Medien) ÄnderungenPerson

Krankenakte Endversion

Nach E. Ammenwerth

Kunde Technik

Kunde

Technik

Auftraggeben

Auftragannehmen

Recherche/Bearbeitung

Feedbackgeben

Lösungmitteilen

Technik

Kunde

Lösungtesten

Feedbackbearbeiten

Technik

Technik

Auftragprüfen

Lösungswegbereitstellen

Technik

Wissens-speicher

Orga

Kunde = Auftraggeber Technik = Einheit des Auftragnehmer

Kunden-auftrag

Auftrag

Sammlungder Lösung

Feedback

Recherche

Lösung

Auftragabgeben

Auftragannehmen

Lösungbearbeiten

Lösungübermitteln

Feedbackerhalten

Sammlung/RedaktionelleBearbeitung

Kundenauftrag Ticket

Annahme des Auftrags

KundeMitarbeiter

Feedback

Lösungs- Mitteilung

Kunde

Feedback

Lösungsdokument FAQ

Ergebnis

Vorschlag

Vorschlag

Vorschlag

Vorschlag

Daten

Problemdaten

Recherche

Problembearbeiten

www FAQ

Literatur

VOS

PEP

Problemdaten

Daten

Lösungsweg

Problemmeldung

Telefon

Anrufbeantworter

Helpdesk FAX

HotlineAB

Auftragaufgeben

Kunde

Bedarfaufgetreten

helpdesk Email

Kunden-auftrag

Auftragangekommen

Auftragprüfen

Technik

HotlineAB

helpdesk

GeprüfterAuftrag

Auftragangenommen

RechercheBearbeitung

Technik

FAQWWWLiteratur

VOSPEP

PC Lösungen

Lösung nichtgefunden

Lösung gefunden

Lösung

Mitteilungfertig stellen

helpdeskEmailTelefon

Technik

Lösungtesten

Kunde

Lösungs-übermittlung

Feedbackerstellen

Kunde

HotlineAB

helpdesk Email

Feedbackbearbeiten

Feedbackgeben Technik

FAQ akt.

Lösung funktioniert Mitteilung

fertig stellen

Technik DokuLösungweg

ErgebnisseRedaktionellbearbeiten

Orga

Wissens-weitergabe

Auftrag nichtangenommen

Email

Dienstleister

Kein Anspruchauf den Service

• Das Sollkonzept beschreibt den gewünschten Zustand nach EDV-Einführung. • Welche Ziele werden mit der EDV-Einführung verfolgt?• Wie sollen die Abläufe in Zukunft aussehen?

• Als Basis dienen die Ergebnisse der Systemanalyse (aktueller Zustand).

• Inhalte• Gewünschter zukünftiger Ablauf• Hierfür notwendige EDV-Funktionen

Sollkonzept

Nach E. Opitz

• Das Pflichtenheft (Lastenheft, Anforderungskatalog) beschreibt detailliert die Anforderungen an das geplante EDV-System.

• Übliche Untergliederung:• Funktionale Anforderungen• Nicht-funktionale Anforderungen

• Das Pflichtenheft ist die Grundlage von Angeboten von Herstellern.

Pflichtenheft

• Um einen Vergleich von Angeboten zu ermöglichen, sind die Anforderungen und die Antwortmöglichkeiten jeweils einheitlich zu strukturieren.

• Beispiel: KAS Arbeitsgruppe der GMDS

• Die Vergabe von Prioritäten kann sinnvoll sein:• K.O.-Kriterium (Ausschlusskriterien) • Oder noch feiner, z.B. Prioritäten 1 (K.O.-Kriterium) bis 3

(Wunschkriterium)• „Schwere“ Entscheidungsfindung

Pflichtenheft

• Pflichtenhefte sind häufig sehr umfangreich, ihre Erstellung kann sehr aufwändig sein.

• Empfehlungen:• Wiederverwendung früherer Pflichtenhefte. • Besuche anderer Häuser und Marktübersicht, um Ideen zu

bekommen. • Intensive Kommunikation mit allen Beteiligten und

zukünftigen Benutzergruppen. • Je detaillierter, desto besser abprüfbar, aber um so aufwändiger

für alle. • Das (ausgefüllte) Pflichtenheft sollte Bestandteil des Vertrags

mit dem Lieferanten werden.

Pflichtenheft: Fazit

• Nach Abschluss von Systemanalyse, Sollkonzeption und Pflichtenhefterstellung liegen vor:

• Beschreibung der Ist-Situation (Systemanalyse)• Beschreibung der zukünftigen Situation (Sollkonzept)• Detaillierte Anforderungen an die neue Software

(Pflichtenheft)

• Nächste Schritte:• Ausschreibung + Auswahl• Einführung• Betrieb

Fazit

Folgen der Informationssammlung

Prozeßreengineering erforderlich– Datenfluß

– Arbeitsabläufe

– Standards, Richtlinien

IT-Lösung unterstützt den optimierten Prozeß

Neue Aufgaben für das Projekt-Team! Zeitplan wird verändert!

2. Auswahlkriterien festlegen

Gewünschte Fähigkeiten/Funktionalitäten Systemarchitektur

Datenbank, HW, SW, Netzwerk, Betriebssystem,Schnittstellen

Eigenschaften Bedienoberfläche Datenschutz, Datenintegrität, Datensicherheit Flexibilität (Anwender-parametrisierbar - Programmierbar) Dokumentation

Kosten Investition, Wartung, laufende Kosten

Verkäufer/Hersteller Stabilität, Erfahrung, Referenzen, Bereitschaft/Interesse

3. Gewichten der Kriterien

“Muß haben” oder “Schön zu haben” Falls erforderlich Gewichte quantifizieren

Entwickeln von Bewertungshilfen Demonstration Besuchen vor Ort Antworten auf Ausschreibung

Funktion Gewicht Anbieter 1 Anbieter 2 Anbieter 3Drucke Arbeitsliste MußInfusionen in Kurve 0.8

4. Evaluieren der Produkte

Auswahlkriterien Schriftliche Unterlagen Informationsmaterial Ausschreibung Demonstrationen

(Szenarien?) Messen,

Anbieterveranstaltungen

Besuch des Anbieters Neue Entwicklungen Zukünftige Trends

Gespräche mit anderen Anwendern Telefon Besuche vor Ort

5. Auswählen des Produkts

Verwenden der Bewertungshilfe Komplette Nutzwertanalyse falls erforderlich

Analyse möglicher Vorteile (Vorhersage) Qualitätsverbesserung, internes Budgetieren, Forschung

Bericht an Vorgesetzte Vertragsverhandlungen

Was passiert bei Versagen des Anbieters? Was passiert bei Ausscheiden des Anbieters? Was passiert bei Zeitverzug?

6. Installation

Information vor Installation Infrastruktur abklären Ausreichende Anwenderschulung

Intern/extern Just in time!

Betreuung nach der Installation Hotline Häufige Besuche Vorgehensweise bei Anregungen/Beschwerden festlegen

Anwenderschulung

Anwenderexperten - normale Anwender Geben Anwendungskenntnisse weiter (Schneeballsystem) Können die meisten Probleme vor Ort lösen

Jeden schulen, der geschult werden will Schulung erfolgt in der Dienstzeit

Schulung am Arbeitsplatz / in Schulungszentren Neue Mitarbeiter müssen auch geschult werden Kurse zum Auffrischen/Erweitern des Wissens

Die beliebtesten Fehler (1)

nach Judy Murphy, 1996

"Verliebt sein"/Sympathie/

"Vertrau uns"

Der Prototyp wirdfür das fertige Produkt

gehalten..

UmfangreicheInvestitionen vor

Einführung.

Fehlende Unter-stützung aller

Projektpartner.

Produkt erfüllt nicht dieErwartungen

Beschaffung einesunvollständigen Produktes,aufwendige Entwicklung

noch erforderlich.

Hohe Kosten ohne das ein Nutzen daraus

gewonnen wird.

Ablehnung durch wichtigeBeteiligte, Projektversagen

oder -verzögerung.

Sorgfältige Evaluation desProdukts selbst bei

sympathischen Anbietern.

Besuche vor Ort undPrüfung der Referenzen,Produkt selber austesten.

Anfänglich nur geringeInvestitionen. Aus Fehlern

lernen.

Unterstützung sicherstellen,Anwender und

Management einbinden.

Fehler Folge Lösung

Die beliebtesten Fehler (2)

nach Judy Murphy, 1996

Projektumfang, -ziele nicht festgelegt. UnterschiedlicheErwartungen.

Vernachlässigung derfunktionalen Anforderungin der Ausschreibung

Fehlende Schnitt-stellenanforderungen inder Ausschreibung

Unzufriedene Anwender, nichterfüllte Ziele, mögliches

Projektversagen.

Deutliche Produktmängelund teuere

Nachbesserungen.

Teure Schnittstellen-entwicklung nachträglichunter Einbindung internerund externer Ressourcen

Projektumfang vom Beginnan festlegen. Informiere überMöglichkeiten des Marktes.

Ausführliche Ausschreibung,gründliche Auswahl,

notwendige Entwicklungensind Vertragsbestandteil.

Schnittstellenbeschreibungin der Ausschreibung,

Anbietererfahrung berück-sichtigen und im Vertrag

Fehler Folge Lösung