it projekte
Post on 01-Dec-2014
3.235 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
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
KaufenImplementieren
In Betriebhalten
Problem zu lösenProblem überflüssig
Ähnliches Problem
Neue Lösung für dasselbe ProblemIst-Analyse und
Anforderungskatalog
Beseitigen vonImplementierungsfehlern
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
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
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
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
top related