1.
IT - Projektrisiko U. Schrader

2.
Arten des Scheiterns <ul><li>Erforderliche Funktionalität fehlt </li></ul><ul><li>Kostenrahmen gesprengt </li></ul><ul><li>Zeitrahmen gesprengt </li></ul>

3.
Gescheiterte Projekte <ul><li>USA </li></ul><ul><ul><li>72% im Jahr 2000 mit abnehmender Tendenz bei Großunternehmen (Standish Group) </li></ul></ul><ul><li>UK </li></ul><ul><ul><li>80% im Zeitraum 1994-1995 (OASIG-Studie) </li></ul></ul><ul><ul><li>Anstieg in Richtung 90% für 2000 und 2001 (Silicon) </li></ul></ul>

4.
Gescheiterte Projekte <ul><li>D </li></ul><ul><ul><li>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) </li></ul></ul><ul><li>CH </li></ul><ul><ul><li>Scheiterquote über 50% in 2000 steigend (Schweiz. Bundesamt f. Berufsbildung und Technologie) </li></ul></ul>

5.
Hauptauswahlkriterien bei IT-Projekten Quelle: Bearingpoint Umfrage zitiert in Computer Zeitung 32-33/2003 %

6.
Kosten IT <ul><li>70% Wetware </li></ul><ul><ul><li>Menschen (Entscheidungsunterstützung, Planung, Einkauf, Schulung, Support, Einführung, Fehlersuche, Fehlbedienung, Fehlerfolgen) </li></ul></ul><ul><li>20% Hardware </li></ul><ul><li>10% Software </li></ul><ul><li>Schätzung Gardner (15000 $/a pro Arbeitsplatz, for-profits, ca. Mitte 1990) </li></ul>

7.
Plan Analysieren Entwickeln Kaufen Implementieren In Betrieb halten Problem zu lösen Problem überflüssig Ähnliches Problem Neue Lösung für dasselbe Problem Ist-Analyse und Anforderungskatalog Beseitigen von Implementierungsfehlern RISIKO PHASE 1 RISIKO PHASE 2 RISIKO PHASE 3 RISIKO PHASE 4 nach Whitten JL, Benthley LD. Systems and design methods. McGraw-Hill, 1998

8.
Plan Analysieren Entwickeln Kaufen Implementieren In Betrieb halten Problem zu lösen Problem überflüssig Ähnliches Problem Neue Lösung für dasselbe Problem Ist-Analyse und Anforderungskatalog Beseitigen von Implementierungsfehlern RISIKO PHASE 1 RISIKO PHASE 2 RISIKO PHASE 3 RISIKO PHASE 4 nach Whitten JL, Benthley LD. Systems and design methods. McGraw-Hill, 1998

9.
Plan Analysieren Entwickeln Kaufen Implementieren In Betrieb halten Problem zu lösen Problem überflüssig Ähnliches Problem Neue Lösung für dasselbe Problem Ist-Analyse und Anforderungskatalog Beseitigen von Implementierungsfehlern RISIKO PHASE 1 RISIKO PHASE 2 RISIKO PHASE 3 RISIKO PHASE 4 nach Whitten JL, Benthley LD. Systems and design methods. McGraw-Hill, 1998

10.
Plan Analysieren Entwickeln Kaufen Implementieren In Betrieb halten Problem zu lösen Problem überflüssig Ähnliches Problem Neue Lösung für dasselbe Problem Ist-Analyse und Anforderungskatalog Beseitigen von Implementierungsfehlern RISIKO PHASE 1 RISIKO PHASE 2 RISIKO PHASE 3 RISIKO PHASE 4 nach Whitten JL, Benthley LD. Systems and design methods. McGraw-Hill, 1998

11.
Software - Lebenszyklus <ul><li>Phase 1 </li></ul><ul><ul><li>Ist-Analyse, Soll-Konzept Verzeichnis der Anforderungen </li></ul></ul><ul><li>Phase 2 </li></ul><ul><ul><li>Beschaffung/Realisierung eines Produktes </li></ul></ul><ul><li>Phase 3 </li></ul><ul><ul><li>Einführung/Implementierung/Parametrisierung </li></ul></ul><ul><li>Phase 4 </li></ul><ul><ul><li>Aufrechterhaltung des laufenden Betriebs </li></ul></ul>

12.
Literatur (1) <ul><li>Ammenwerth, E.; Eichstädter U.; Schrader, U.: EDV in der Pflegedokumentation – Ein Leitfaden für Praktiker. Schlüterscher Verlag, Hannover 2003. </li></ul><ul><li>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. </li></ul><ul><li>Hacker, W.; Scheuch, K.; Kunath, H.; Haux, R.: Computer in der Krankenpflege. Roderer, Regensburg 1999. </li></ul><ul><li>Hannah, K.J.; Ball, M.J.; Edwards, M.J.A.; Hübner, U.: Pflegeinformatik. Springer, Heidelberg 2002. </li></ul>

13.
Literatur (2) <ul><li>Haux, R.; Lagemann, A.; Knaup, P.; Schmücker, P.; Winter, A.: Management von Informationssystemen. Teubner-Verlag, Stuttgart 1998. </li></ul><ul><li>Goossen, W.T.F.: Pflegeinformatik. Ullstein Medical, Wiesbaden 1998. </li></ul><ul><li>Peltzer M.: Unternehmenserfolg und Informationsmanagement: Wettbewerbsvorteile durch Interaktionsfähigkeit und Prozessgestaltung. Addision-Wesley, Bonn 1992. </li></ul><ul><li>Trill R.: Informationstechnologie im Krankenhaus: Strategien, Auswahl, Einsatz. Luchterhand, 2002. </li></ul>

14.
Erfolgreiche IT-Projekte Die Abhängigkeiten Die einzelnen Schritte Die beliebtesten Fehler

15.
Wie bekommt man ein Projekt?

16.
Abhängigkeiten IT-Projekt Vorhandene Hardware Vorhandene Programme Organisatorische Strukturen Geld $$ Ziele der Einrichtung IT Infrastruktur Vorgehensweisen Richtlinien Standards Menschen Arbeitsabläufe Datenfluß Zeitplan Verkäufer Produkte Anwender

17.
1. Beginnen <ul><li>Aufbau einer Projektgruppe </li></ul><ul><li>Finden einer gemeinsamen Vision </li></ul><ul><li>Informationssammlung </li></ul><ul><ul><li>Existierende Systeme, Richtlinien, Standards, Datenfluß, Arbeitsabläufe </li></ul></ul><ul><ul><li>Stärken und Schwächen der gegenwärtigen Lösung </li></ul></ul><ul><ul><li>Was soll erhalten, geändert, automatisiert oder eliminiert werden </li></ul></ul><ul><li>Funktionelle Anforderungen </li></ul><ul><li>Erwartungen formen - Jeden informieren! </li></ul><ul><li>Untersuchung des Marktes </li></ul><ul><ul><li>Literaturstudium, Vergleiche, Firmeninformationen, Kollegen </li></ul></ul><ul><li>Beauftragung externer Experten, Berater? </li></ul>

18.
Aufbau einer Projektgruppe <ul><li>Kompetente Mitarbeiter </li></ul><ul><li>Ausreichend freigestellt für die Mitarbeit </li></ul><ul><li>Projektarbeit muß hohe Priorität haben </li></ul><ul><li>Rollen und Verantwortlichkeiten müssen definiert werden </li></ul><ul><li>Berechtigt Entscheidungen zu treffen </li></ul><ul><li>Den vollständigen Prozeß repräsentieren! </li></ul>

19.
<ul><li>Vor der Auswahl und Einführung von EDV stellen sich eine Reihe von Fragen: </li></ul><ul><ul><li>Wie sind die derzeitigen Abläufe in der Praxis? </li></ul></ul><ul><ul><li>Was sind derzeitige Schwachstellen? </li></ul></ul><ul><ul><li>Welche Probleme kann man mit einem EDV-System lösen? </li></ul></ul><ul><ul><li>Brauche ich überhaupt eine EDV-System? </li></ul></ul><ul><ul><li>Was sollte das EDV-System können? </li></ul></ul><ul><ul><li>Welche EDV-Kenntnisse haben die Pflegekräfte? </li></ul></ul><ul><ul><li>Welche EDV-Ausstattung ist schon vorhanden? </li></ul></ul><ul><ul><li>..... </li></ul></ul>Systemanalyse – Wozu? Nach E. Ammenwerth

20.
<ul><li>Viele dieser Fragen kann man nur Vor Ort beantworten. </li></ul><ul><li>Daher wird (mehr oder weniger systematisch) immer eine Vor-Ort-Erhebung („Systemanalyse“) durchgeführt. </li></ul><ul><li>Die Systemanalyse sollte gut vorbereitet sein und zielgerichtet erfolgen! </li></ul><ul><ul><li>Klärung der Bereiche bzw. Aufgaben, die man sich näher anschauen möchte. </li></ul></ul><ul><ul><li>Aufstellen einer Liste von Fragen, die beantwortet werden sollen. </li></ul></ul>Systemanalyse – Wozu? Nach E. Ammenwerth

21.
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 Beobachtungen Zeitaufwändig, ermöglicht dafür aber einen eigenen Eindruck von der Praxis, kann gut mit Interviews verbunden werden. Systemanalyse – Methoden Nach E. Ammenwerth

22.
<ul><li>In der Regel werden die verschiedenen Methoden miteinander verbunden, also z.B.: </li></ul><ul><li>Derzeitige Abläufe: Beobachtungen + Interviews. </li></ul><ul><li>Aktuelle Schwachstellen: Interviews. </li></ul><ul><li>EDV-Kenntnisse und Schulungsbedarf: Fragebögen. </li></ul><ul><li>EDV-Ausstattung: Beobachtung. </li></ul>Systemanalyse – Methoden Nach E. Ammenwerth

23.
<ul><li>Die Ergebnisse einer Systemanalyse sollten schriftlich festgehalten werden. </li></ul><ul><ul><li>Als Basis für den weiteren Projektverlauf. </li></ul></ul><ul><ul><li>Als Informationsquelle für alle Beteiligten. </li></ul></ul><ul><li>Die Darstellung kann als Text erfolgen, häufig ist aber eine zusätzliche grafische Aufbereitung hilfreich. </li></ul>Systemanalyse: Ergebnisse Nach E. Ammenwerth

24.
Daten- und Informationsfluss Nach E. Ammenwerth

25.
Sekretariat „ Postraum“ Oberarztzimmer Brief diktieren Assistenzarzt Kassette 1. Version Krankenakte Arztzimmer 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) Änderungen Person Krankenakte Endversion Nach E. Ammenwerth

26.
Kunde Technik Kunde Technik Auftrag geben Auftrag annehmen Recherche/ Bearbeitung Feedback geben Lösung mitteilen Technik Kunde Lösung testen Feedback bearbeiten Technik Technik Auftrag prüfen Lösungsweg bereitstellen Technik Wissens- speicher Orga Kunde = Auftraggeber Technik = Einheit des Auftragnehmer

27.
Kunden- auftrag Auftrag Sammlung der Lösung Feedback Recherche Lösung Auftrag abgeben Auftrag annehmen Lösung bearbeiten Lösung übermitteln Feedback erhalten Sammlung/ Redaktionelle Bearbeitung

28.
Kundenauftrag Ticket Annahme des Auftrags Kunde Mitarbeiter Feedback Lösungs- Mitteilung Kunde Feedback Lösungsdokument FAQ Ergebnis Vorschlag Vorschlag Vorschlag Vorschlag Daten Problemdaten Recherche Problem bearbeiten www FAQ Literatur VOS PEP Problemdaten Daten Lösungsweg Problemmeldung Telefon Anrufbeantworter Helpdesk FAX

29.
Hotline AB Auftrag aufgeben Kunde Bedarf aufgetreten helpdesk Email Kunden- auftrag Auftrag angekommen Auftrag prüfen Technik Hotline AB helpdesk Geprüfter Auftrag Auftrag angenommen Recherche Bearbeitung Technik FAQ WWW Literatur VOS PEP PC Lösungen Lösung nicht gefunden Lösung gefunden Lösung Mitteilung fertig stellen helpdesk Email Telefon Technik Lösung testen Kunde Lösungs- übermittlung Feedback erstellen Kunde Hotline AB helpdesk Email Feedback bearbeiten Feedback geben Technik FAQ akt. Lösung funktioniert Mitteilung fertig stellen Technik Doku Lösungweg Ergebnisse Redaktionell bearbeiten Orga Wissens- weitergabe Auftrag nicht angenommen Email Dienstleister Kein Anspruch auf den Service

30.
<ul><li>Das Sollkonzept beschreibt den gewünschten Zustand nach EDV-Einführung. </li></ul><ul><ul><li>Welche Ziele werden mit der EDV-Einführung verfolgt? </li></ul></ul><ul><ul><li>Wie sollen die Abläufe in Zukunft aussehen? </li></ul></ul><ul><li>Als Basis dienen die Ergebnisse der Systemanalyse (aktueller Zustand). </li></ul><ul><li>Inhalte </li></ul><ul><ul><li>Gewünschter zukünftiger Ablauf </li></ul></ul><ul><ul><li>Hierfür notwendige EDV-Funktionen </li></ul></ul>Sollkonzept Nach E. Opitz

31.
<ul><li>Das Pflichtenheft (Lastenheft, Anforderungskatalog) beschreibt detailliert die Anforderungen an das geplante EDV-System. </li></ul><ul><li>Übliche Untergliederung: </li></ul><ul><ul><li>Funktionale Anforderungen </li></ul></ul><ul><ul><li>Nicht-funktionale Anforderungen </li></ul></ul><ul><li>Das Pflichtenheft ist die Grundlage von Angeboten von Herstellern. </li></ul>Pflichtenheft

32.
<ul><li>Um einen Vergleich von Angeboten zu ermöglichen, sind die Anforderungen und die Antwortmöglichkeiten jeweils einheitlich zu strukturieren. </li></ul><ul><li>Beispiel: KAS Arbeitsgruppe der GMDS </li></ul><ul><li>Die Vergabe von Prioritäten kann sinnvoll sein: </li></ul><ul><ul><li>K.O.-Kriterium (Ausschlusskriterien) </li></ul></ul><ul><ul><li>Oder noch feiner, z.B. Prioritäten 1 (K.O.-Kriterium) bis 3 (Wunschkriterium) </li></ul></ul><ul><ul><li>„ Schwere“ Entscheidungsfindung </li></ul></ul>Pflichtenheft

33.
<ul><li>Pflichtenhefte sind häufig sehr umfangreich, ihre Erstellung kann sehr aufwändig sein. </li></ul><ul><li>Empfehlungen: </li></ul><ul><ul><li>Wiederverwendung früherer Pflichtenhefte. </li></ul></ul><ul><ul><li>Besuche anderer Häuser und Marktübersicht, um Ideen zu bekommen. </li></ul></ul><ul><ul><li>Intensive Kommunikation mit allen Beteiligten und zukünftigen Benutzergruppen. </li></ul></ul><ul><ul><li>Je detaillierter, desto besser abprüfbar, aber um so aufwändiger für alle. </li></ul></ul><ul><ul><li>Das (ausgefüllte) Pflichtenheft sollte Bestandteil des Vertrags mit dem Lieferanten werden. </li></ul></ul>Pflichtenheft: Fazit

34.
<ul><li>Nach Abschluss von Systemanalyse, Sollkonzeption und Pflichtenhefterstellung liegen vor: </li></ul><ul><ul><li>Beschreibung der Ist-Situation (Systemanalyse) </li></ul></ul><ul><ul><li>Beschreibung der zukünftigen Situation (Sollkonzept) </li></ul></ul><ul><ul><li>Detaillierte Anforderungen an die neue Software (Pflichtenheft) </li></ul></ul><ul><li>Nächste Schritte: </li></ul><ul><ul><li>Ausschreibung + Auswahl </li></ul></ul><ul><ul><li>Einführung </li></ul></ul><ul><ul><li>Betrieb </li></ul></ul>Fazit

35.
Folgen der Informationssammlung <ul><li>Prozeßreengineering erforderlich </li></ul><ul><ul><li>Datenfluß </li></ul></ul><ul><ul><li>Arbeitsabläufe </li></ul></ul><ul><ul><li>Standards, Richtlinien </li></ul></ul><ul><li>IT-Lösung unterstützt den optimierten Prozeß </li></ul><ul><li>Neue Aufgaben für das Projekt-Team! </li></ul><ul><li>Zeitplan wird verändert! </li></ul>

36.
2. Auswahlkriterien festlegen <ul><li>Gewünschte Fähigkeiten/Funktionalitäten </li></ul><ul><li>Systemarchitektur </li></ul><ul><ul><li>Datenbank, HW, SW, Netzwerk, Betriebssystem,Schnittstellen </li></ul></ul><ul><li>Eigenschaften </li></ul><ul><ul><li>Bedienoberfläche </li></ul></ul><ul><ul><li>Datenschutz, Datenintegrität, Datensicherheit </li></ul></ul><ul><ul><li>Flexibilität (Anwender-parametrisierbar - Programmierbar) </li></ul></ul><ul><ul><li>Dokumentation </li></ul></ul><ul><li>Kosten </li></ul><ul><ul><li>Investition, Wartung, laufende Kosten </li></ul></ul><ul><li>Verkäufer/Hersteller </li></ul><ul><ul><li>Stabilität, Erfahrung, Referenzen, Bereitschaft/Interesse </li></ul></ul>

37.
3. Gewichten der Kriterien <ul><li>“ Muß haben” oder “Schön zu haben” </li></ul><ul><ul><li>Falls erforderlich Gewichte quantifizieren </li></ul></ul><ul><li>Entwickeln von Bewertungshilfen </li></ul><ul><ul><li>Demonstration </li></ul></ul><ul><ul><li>Besuchen vor Ort </li></ul></ul><ul><ul><li>Antworten auf Ausschreibung </li></ul></ul>Funktion Gewicht Anbieter 1 Anbieter 2 Anbieter 3 Drucke Arbeitsliste Muß Infusionen in Kurve 0.8

38.
4. Evaluieren der Produkte <ul><li>Auswahlkriterien </li></ul><ul><ul><li>Schriftliche Unterlagen </li></ul></ul><ul><ul><li>Informationsmaterial </li></ul></ul><ul><ul><li>Ausschreibung </li></ul></ul><ul><ul><li>Demonstrationen (Szenarien?) </li></ul></ul><ul><ul><li>Messen, Anbieterveranstaltungen </li></ul></ul><ul><li>Besuch des Anbieters </li></ul><ul><ul><li>Neue Entwicklungen </li></ul></ul><ul><ul><li>Zukünftige Trends </li></ul></ul><ul><li>Gespräche mit anderen Anwendern </li></ul><ul><ul><li>Telefon </li></ul></ul><ul><ul><li>Besuche vor Ort </li></ul></ul>

39.
5. Auswählen des Produkts <ul><li>Verwenden der Bewertungshilfe </li></ul><ul><ul><li>Komplette Nutzwertanalyse falls erforderlich </li></ul></ul><ul><li>Analyse möglicher Vorteile (Vorhersage) </li></ul><ul><ul><li>Qualitätsverbesserung, internes Budgetieren, Forschung </li></ul></ul><ul><li>Bericht an Vorgesetzte </li></ul><ul><li>Vertragsverhandlungen </li></ul><ul><ul><li>Was passiert bei Versagen des Anbieters? </li></ul></ul><ul><ul><li>Was passiert bei Ausscheiden des Anbieters? </li></ul></ul><ul><ul><li>Was passiert bei Zeitverzug? </li></ul></ul>

40.
6. Installation <ul><li>Information vor Installation </li></ul><ul><li>Infrastruktur abklären </li></ul><ul><li>Ausreichende Anwenderschulung </li></ul><ul><ul><li>Intern/extern </li></ul></ul><ul><ul><li>Just in time! </li></ul></ul><ul><li>Betreuung nach der Installation </li></ul><ul><ul><li>Hotline </li></ul></ul><ul><ul><li>Häufige Besuche </li></ul></ul><ul><ul><li>Vorgehensweise bei Anregungen/Beschwerden festlegen </li></ul></ul>

41.
Anwenderschulung <ul><li>Anwenderexperten - normale Anwender </li></ul><ul><ul><li>Geben Anwendungskenntnisse weiter (Schneeballsystem) </li></ul></ul><ul><ul><li>Können die meisten Probleme vor Ort lösen </li></ul></ul><ul><li>Jeden schulen, der geschult werden will </li></ul><ul><ul><li>Schulung erfolgt in der Dienstzeit </li></ul></ul><ul><li>Schulung am Arbeitsplatz / in Schulungszentren </li></ul><ul><li>Neue Mitarbeiter müssen auch geschult werden </li></ul><ul><li>Kurse zum Auffrischen/Erweitern des Wissens </li></ul>

42.
Die beliebtesten Fehler (1) nach Judy Murphy, 1996 &quot;Verliebt sein&quot;/ Sympathie/ &quot;Vertrau uns&quot; Der Prototyp wird für das fertige Produkt gehalten.. Umfangreiche Investitionen vor Einführung. Fehlende Unter- stützung aller Projektpartner. Produkt erfüllt nicht die Erwartungen Beschaffung eines unvollständigen Produktes, aufwendige Entwicklung noch erforderlich. Hohe Kosten ohne das ein Nutzen daraus gewonnen wird. Ablehnung durch wichtige Beteiligte, Projektversagen oder -verzögerung. Sorgfältige Evaluation des Produkts selbst bei sympathischen Anbietern. Besuche vor Ort und Prüfung der Referenzen, Produkt selber austesten. Anfänglich nur geringe Investitionen. Aus Fehlern lernen. Unterstützung sicherstellen, Anwender und Management einbinden. Fehler Folge Lösung

43.
Die beliebtesten Fehler (2) nach Judy Murphy, 1996 Projektumfang, -ziele nicht festgelegt. Unterschiedliche Erwartungen. Vernachlässigung der funktionalen Anforderung in der Ausschreibung Fehlende Schnitt- stellenanforderungen in der Ausschreibung Unzufriedene Anwender, nichterfüllte Ziele, mögliches Projektversagen. Deutliche Produktmängel und teuere Nachbesserungen. Teure Schnittstellen- entwicklung nachträglich unter Einbindung interner und externer Ressourcen Projektumfang vom Beginn an festlegen. Informiere über Möglichkeiten des Marktes. Ausführliche Ausschreibung, gründliche Auswahl, notwendige Entwicklungen sind Vertragsbestandteil. Schnittstellenbeschreibung in der Ausschreibung, Anbietererfahrung berück- sichtigen und im Vertrag Fehler Folge Lösung