Seminar tu do-20090625_3 [kompatibilitätsmodus]

  • 375 views
Uploaded on

Partizipatives Design mit Metasonic

Partizipatives Design mit Metasonic

More in: Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
375
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
6
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Betriebliches Kommunikationsmanagement im Kontext von IT-Service-Management (ITSM) © Logica 2009. All rights reserved Kontext von IT-Service-Management (ITSM) Erhebungs- und Analysemethoden / Partizipatives Design 25. Juni 2009 Dr. rer. pol. MSc. Leonhardt Wohlschlager Certified ITIL Service Manager leonhardt.wohlschlager@logica.com Tel. 0173 8895 171
  • 2. Gliederung Erhebungs- und Analysemethoden1 Partizipatives Design2 State-of-the-Art Business Process Management3 S. 225 Juni 2009 Seminar Technische Universität Dortmund
  • 3. Definition Erhebungs- und Analysemethode (= Survey technique) Erhebung ist das […] Ermitteln oder Erfassen von Daten über jemanden oder über etwas und die systematische Ordnung und Dokumentation der ermittelten oder erfaßten Daten. (S. 10) Eine Methode ist ein auf einem System von Regeln aufbauendes Problemlösungsverfahren […], das im Grenzfall entweder ein Algorithmus oder eine Heuristik ist. (S. 10) No. 325 Juni 2009 Seminar Technische Universität Dortmund Quelle: Heinrich, Roithmayer: Wirtschaftsinformatik-Lexikon München 1998. Breite und Tiefe der Erhebung richten sich nach dem Untersuchungszweck, der sich nicht auf die Erhebung selbst beschränkt, sondere letztlich auf eine Entwurfsaufgabe und die ihr vorgelagerte Analyseaufgabe ausgerichtet ist. Erhebungsgegenstand (S. 196)? − Anforderungen (= survey of requirements) Anforderungsanalyse − Ist-Zustand (= survey of current system) Istzustandserfassung …
  • 4. Erhebung, Analyse und Design im Vorgehensmodell Systemimplementierung Qualitätssicherung Lenkung der Entwicklung Erhebungs-, Analyse- und Entwurfsaktivitäten finden vor allem in den Frühphasen der Systementwicklung statt. No. 425 Juni 2009 Seminar Technische Universität Dortmund Initialisie- rung Initialisie- rung VorstudieVorstudie Ganzheit- licher Grob- entwurf Ganzheit- licher Grob- entwurf Organisa- tions- entwurf Organisa- tions- entwurf Software- entwurf Software- entwurf Personeller Entwurf Personeller Entwurf Ganzheit- liche Integration Ganzheit- liche Integration Ganzheitliche Erprobung und Konsoli- dierung Ganzheitliche Erprobung und Konsoli- dierung Übergabe zum Betrieb Übergabe zum Betrieb Ganzheit- licher Feinentwurf Ganzheit- licher Feinentwurf Realisierung organisato- rischer Komponente n Realisierung organisato- rischer Komponente n Realisierung der Software- komponenten Realisierung der Software- komponenten Realisierung personeller Komponen- ten Realisierung personeller Komponen- ten Vorprojekt Hauptprojekt Quelle: Vorgehensmodell in Anlehnung an Seibt /Wirtschaftsinformatik 2002/ 171. •Analyse •Design
  • 5. Subjekte, Objekte und Tätigkeiten in der Erhebung und Analyse •Business Analysten •Consultants •Change Manager •Prozessdesigner •… Erhebungs- und Analysesubjekte Erhebungs- und Analyseobjekte 25 Juni 2009 Seminar Technische Universität Dortmund •Betrieb •Organisation •Aufgaben •Aufgabenbereich/Organisationseinheit •Aufgabenteilung •Prozesse •Personal •… •Erfassen •Beobachten •Fragebogen konstruieren •Dokumentieren (Handbücher, Arbeitsanweisungen, Organisationspläne, Stellenbeschreibungen, Datenflußpläne, Struktogramme1) •… Erhebungs- und Analysetätigkeiten No. 5 1 Quelle: Steinbuch: Betriebliche Informatik. Ludwigshafen 1998
  • 6. Arten von Erhebungs- und Analysemethoden Direkte Erhebung • Interviewmethode Direkte Erhebung • Interviewmethode Indirekte ErhebungIndirekte Erhebung No. 625 Juni 2009 Seminar Technische Universität Dortmund • Interviewmethode • Beobachtung • Interviewmethode • Beobachtung Indirekte Erhebung • Fragebogenmethode • Selbstaufschreibung • Dokumentenauswertung Indirekte Erhebung • Fragebogenmethode • Selbstaufschreibung • Dokumentenauswertung Quelle: Heinrich, Roithmayer: Wirtschaftsinformatik-Lexikon München 1998, S. 10.
  • 7. Fragebogenmethode – Zufriedenheitserhebung nach Reorganisation No. 725 Juni 2009 Seminar Technische Universität Dortmund Quelle: aus der Projektakte eines Kunden, 2009
  • 8. Fragebogenmethode – Begriffserhebung für ein DWH-Design Status Dateiname GF T y p ID Bezeichnung Definition Anmerkun g Entität Attribut Abgestimmt im WS WS-UB3- BEGRIFFE- 20080116_v0 GPM 0.17.xls UB III K 69679Anzahl Versicherungsverträge Anzahl Verträge zwischen einem Versicherungsunternehmen und Versicherungsnehmer über die Gewährung von Versicherungsschutz gegen Beitragszahlung. Versicherungs nehmer KV müssen separierbar sein Abgestimmt im WS WS-UB3- BEGRIFFE- Merkmale UB III M 60175Außenstelle Außenstelle, der ein Vertrag zugeordnet ist Ausprägung beschrieben in TA0264 VTP_VERTR AG Merkmale 20080212_v0 Toolinput.xls in TA0264 bzw. TA0265, es gibt auch Fälle mit Ausprägung ‚000‘ (in der Emulation blank) Abgestimmt im WS WS-IKS_SAS- 20070917_v0( DB)van Bonn2007121 4.xls UB III A 60499Beitragszahler(akademi scher Titel) Akademischer Titel des Partners mit der Rolle Beitragszahler Schlüsselums etzung zum Beispiel: Dr., Prof., … PARV_NAT Titel Abgestimmt im WS WS-IKS_SAS- 20070917_v0( DB)van Bonn2007121 4.xls UB III A 60498Beitragszahler(Anrede) Anrede des Partners mit der Rolle Beitragszahler im Klartext, z.B. Herr, Frau, Firma Schlüssel 01 = Herr, … PARV_ALLG EM Anrede No. 825 Juni 2009 Seminar Technische Universität Dortmund Quelle: Auszug aus einem Glossar aus der Projektakte eines Kunden, 2008
  • 9. Design Entwurf einer Software-technischen Lösung (Systemarchitektur) auf Basis der im Fachkonzept festgelegten Systemanforderungen. − Unter Berücksichtigung Hardware- und Software-technischer Restriktionen werden exakte Vorgaben für die anschließende Programmierung erstellt. − Angestrebt wird vor allem eine Reduzierung der Komplexität des gesamten Projekts durch Zerlegung in leichter lösbare Teilkomplexe. Hierbei wird ein DV-Konzept erstellt, das als Grundlage für die Implementierung des Systems dient.1 Servicedesign − Unter Servicedesign versteht man gemäß ITIL v3 den Entwurf innovativer Servicelösungen, des Serviceportfolios, der technologischen Architekturen, des Managementsystems, der Prozesse und der Messsysteme, Methoden und Metriken. 2 No. 925 Juni 2009 Seminar Technische Universität Dortmund 1 Quelle: Gabler (Hrsg.): Wirtschaftsinformatik –Lexikon. Wiesbaden 1997, 188 f. 2 Quelle: Vgl. OGC (Hrsg.). ITIL Version 3 Service Design. 54 3 Quelle: Siehe hierzu z.B. den Detailentwurf in der Präsentation vom 30.04.2009, 15 Messsysteme, Methoden und Metriken. 2 Funktionsdesign − beinhaltet eine systematische Untergliederung der Problemstellung in Teilprobleme, die Strukturierung der erforderlichen Systemkomponenten in Hierarchien (d.h. Serialisierung der in der Analysephase modellierten Prozesse) und Bestimmung der Wechselwirkungen zwischen einzelnen Komponenten. − Dabei müssen insbesondere eine Konkretisierung des Funktions- und Leistungsumfangs, d.h. eine Definition der benötigten Module sowie die Spezifizierung der erforderlichen Benutzerschnittstellen erfolgen […]. 1 Bei Entwürfen über die Funktionen stehen Funktionen bzw. Prädikate stärker im Vordergrund. Datenbankdesign − In dem datenorientierten Programmierparadigma stehen die Objekte bzw. Daten im Mittelpunkt des Entwurfs. 3 Prozessdesign − Dieser Entwurf beinhaltet als Strukturelemente im wesentlichen die Aktivität. Prozesse können z.B. als Programmablaufplan oder als eEPK entworfen werden. ARIS, Visio und Adonis sind bekannte Tools für den Prozessentwurf.
  • 10. Merkmale partizipativen Designs Entwurfs- tätigkeiten unter Beteiligung von Personen, d.h. in Kommunikation mit anderen repräsentiert eine Phase im ist keine Planung, 25 Juni 2009 Seminar Technische Universität Dortmund Partizipatives Design eine Phase im Vorgehens- modell erfolgt vor und nach der Analyse ist eine Tätigkeit im Business Process (Re-) Engineering Planung, sondern eine „kreative“ Aktivität No. 10
  • 11. Problemskizzierung (1/2) Bei der Erhebung, Analyse und beim Design von IT-Service-Management- (ITSM-)Prozessen fehlt die Berücksichtigung der Kommunikationsprozesse unter den Beteiligten. In der betrieblichen Praxis werden die Kommunikationsprozesse im Kontext des IT- Service-Management oft nicht oder nur unvollständig erhoben. Meist wird nur erhoben, was an welchem Objekt getan wird, aber nicht wer etwas tut. No. 1125 Juni 2009 Seminar Technische Universität Dortmund Insbesondere wird nicht oder nur unvollständig erhoben, wer innerhalb kollaborativer Aktivitäten kommuniziert. Ausserdem ist der Entwurf von IT-Service-Management-Prozessen meist zu grob für eine maschinelle Ausführung. Eine Erhebung wäre jedoch besonders in den kommunikationsintensiven Planungs-, Steuerungs- und Kontrollprozessen des ITSM sinnvoll. Man trägt dem Umstand zu wenig Rechnung, dass das Design eines ITSM-Prozesses in einem Kommunikationsprozess unter Partizipation entsteht.
  • 12. Folgen Die IT-Service-Management-Prozesse können nur schwer „greifbar“ gemacht werden. Da die ITSM-Prozesse nicht oder nur unvollständig erhoben werden, können sie auch nicht oder nur unvollständig analysiert werden. Da die Kommunikation in dem zu erhebenden Prozess selbst nicht erhoben wird und/oder die Beteiligten nicht am Design partizipieren, können Verbesserungs- potenziale nicht realisiert werden. No. 1225 Juni 2009 Seminar Technische Universität Dortmund nicht oder nur unvollständig analysiert werden. Da der ITSM-Prozess nur bis zu einem bestimmten Granularitätsgrad erhoben wird, können die Verbesserungspotenziale, die aus einem Vergleich eines detaillierteren Ist- Prozesses mit einem Soll-Prozess auf demselben Detaillierungsniveau beruhen, nicht realisiert werden. Da die Ist-ITSM-Prozesse unzureichend detailliert, nicht oder nur unvollständig erhoben und analysiert werden, können Verbesserungspotenziale nicht realisiert werden, die aus einem Vergleich mit einem Soll-Prozessentwurf resultieren.
  • 13. Problemskizzierung (2/2) Da die am Prozess Beteiligten nicht am Design eines Geschäftsprozesses partizipieren, wissen sie auch nicht, wie sie beteiligt sind. Oft werden die entworfenen Prozesse nicht sofort verstanden. Prozesse werden zu kompliziert beschrieben. Prozesse werden nicht sofort getestet und ausgeführt. No. 1325 Juni 2009 Seminar Technische Universität Dortmund Prozesse werden nicht sofort getestet und ausgeführt. Prozesse werden dokumentiert, aber nicht sofort mit den Systemen verbunden.
  • 14. Partizipatives Design am Beispiel von jCOM1 • Subjektorientierte Methodik, basiert auf Prozessalgebra zur Modellierung paralleler Prozesse mit Subjekten • Orientiert an natürlicher Sprache, d.h. an der Standardsatzgrammatik „Subjekt, Prädikat, Objekt“ Erhebungs-, Analyse- und Modellierungsmethodik für Geschäftsprozesse • Einfach: z.B. graphische Notation (Symbolik) Eigenschaft jCOM1 ist eine Geschäftsprozessmodellierungsmethode und ein Werkzeug. No. 1425 Juni 2009 Seminar Technische Universität Dortmund • Einfach: z.B. graphische Notation (Symbolik) • Sofort: z.B. sofort ausführbare Geschäftsprozesse (Test, Validierung, Ausführung) • Integriert: z.B. Java • Kommunikationssicht: Nachrichtenaustausch der Subjekte • Internes Verhalten: Zustände des Subjekts: Senden, Empfangen und Interne Funktion (Prädikat) • Automation: z.B. durch Wegfall der Dokumentation Prozessbeschreibung/Tool • Prozessalgebra zur Modellierung paraller Prozesse mit Subjekten (Quellen: Milner, R.: Calculus of Communicating Systems. Berlin u.a. 1980; Hoare, C.:Communicating Sequential Processes. New Jersey 1985 Theoretischer Hintergrund
  • 15. Modellierungssprachen und Modellierungskonsequenzen No. 1525 Juni 2009 Seminar Technische Universität Dortmund Quelle: Schmidt; Fleischmann; Gilbert: Subjektorientiertes Geschäftsprozessmanagement. In: HMD 266, S. 52 - 62
  • 16. Modellierung eines Prozesses Modellierung des Prozesses 1. Identifikation der Subjekte und Interaktionen (ausgetauschte Nachrichten inkl. Geschäftsobjekte) − Subjektinteraktionsdiagramm (SID) 2. Definition des Subjektverhaltens als streng sequentielle Reihenfolge ihrer Tätigkeiten und Interaktionen mit Hilfe von Zuständen und Zustandsübergängen − Subjektverhaltensdiagram (SVD) Während der Sende- und Empfangszustand jeweils lediglich die Prädikate Senden und Empfangen zur Subjektinteraktion vorsieht, kann ein Subjekt in einem Funktionszustand No. 1625 Juni 2009 Seminar Technische Universität Dortmund Empfangen zur Subjektinteraktion vorsieht, kann ein Subjekt in einem Funktionszustand beliebige andere Prädikate (Aktionen) ausführen. Den Prädikaten werden Services als klare fachliche Bedeutung eines Schritts in einem Subjektverhalten zugeordnet (z.B. Berechnung, Benutzerinteraktion zur Eingaben von Werten in Bildschirmformular). Zustandsübergänge (Transition) geben jeweils Auskunft über das Ergebnis des vorherigen Zustands (z.B. „Bestellung ausgefüllt“ nach Funktionszustand „Bestellung ausfüllen“). In der Architektur von jCOM1 geschieht dies im Modul jPASS!. Quelle: Schmidt; Fleischmann; Gilbert: Subjektorientiertes Geschäftsprozessmanagement. In: HMD 266, S. 56
  • 17. Implikation aus der Vorgehensweise der Prozessmodellierung Im Mittelpunkt der Betrachtung stehen die Subjekte als an einem Prozess beteiligte Akteure. Die Sicht eines Aktionsträgers in einem Prozess kann unter seiner Mitwirkung einfach entworfen werden. Der Aktionsträger versteht den Prozess, da er seine Sicht gewissermaßen „subjektiv“ niederlegen kann. „Er sieht sich in dem Prozess wieder.“ No. 1725 Juni 2009 Seminar Technische Universität Dortmund Die Modellierung motiviert den Aktionsträger im Prozess zur Beteiligung. Die ITSM-Prozesse werden vollständig erhoben und können daher auch vollständig analysiert werden.
  • 18. Partizipatives Design am Beispiel „Service Level Management“ Die am Prozess partizipierenden Subjekte stellen ihre prozessspezifischen Rollen und Interaktionsbeziehungen in einem Subjektinteraktionsdiagramm dar. No. 1825 Juni 2009 Seminar Technische Universität Dortmund
  • 19. Subjektverhaltensdiagramm am Beispiel des Subjekts „Lager“ Funktionszustand Transition No. 1925 Juni 2009 Seminar Technische Universität Dortmund Sendezustand Empfangszustand
  • 20. Validierung des Prozesses Durch ein IT-gestütztes Rollenspiel kann ein subjektorientiertes Prozessmodell sofort interaktiv auf seine Korrektheit aus Sicht der partizipierenden Aktionsträger getestet werden. Dies ist möglich, weil der vorgestellten grafischen Notation mit der oben angesprochenen, weiterentwickelten Prozessalgebra von Milner eine formal klare Semantik und damit maschinell interpretierbare Darstellung mit allen Satzteilen zugrunde liegt. Quelle: Schmidt; Fleischmann; Gilbert: Subjektorientiertes Geschäftsprozessmanagement. In: HMD 266, S. 56 Quelle: Schmidt; Fleischmann; Gilbert: Subjektorientiertes Geschäftsprozessmanagement. In: HMD 266, S. 56 No. 2025 Juni 2009 Seminar Technische Universität Dortmund Implikation: Prozesse können sofort und durch die Fachabteilung getestet werden. Durch die Validierung des Designs lassen sich durch die aktive Partizipation frühzeitig und verlässlich Fehler und Unzulänglichkeiten in der Modellierung erkennen und beseitigen, mit dem Vorteil geringer Entwicklungskosten und verbesserter Qualität. In der Architektur von jCOM1 geschieht dies im Modul jLIVE!.
  • 21. Relative Kosten der Fehlerbehebung in Abhängigkeit von der Phase $15.000 RelativeKosten,umDefectzubeheben oderMissverständnis(Logarithmisch) No. 2125 Juni 2009 Seminar Technische Universität Dortmund $200 $500 $1.200 $5.000 $15.000 RelativeKosten,umDefectzubeheben oderMissverständnis(Logarithmisch) Quelle: in Anlehnung an William Perry: Effective Methods for Software Testing. John Wiley & Sons, Inc. New York u.a. 1995, S. 57, dort aus: B. Boehm: Software Engineering. In: IEEE Transactions on Computer, Dec. 1976 (Summary of IBM, GTE, adn TRW Survey)
  • 22. Organisatorische Implementierung des Prozesses Um den Prozess organisatorisch zu implementieren, müssen die Subjekte des Prozesses den Aufgabenträgern im Organigramm zugeordnet werden. Dies kann z.B. über ein bereits vorhandenes Unternehmensverzeichnis erfolgen, in denen User in Gruppen definiert sind (z.B. SAP, LDAP oder Active Directory). Durch Import der User und Gruppen können die User und Gruppen den Rollen/Subjekten zugeordnet werden. In der Architektur von jCOM1 geschieht dies im Modul jCAST!. User-Änderungen in LDAP können synchronisiert werden, so dass der Wartungsaufwand zur Benutzerverwaltung in jCOM1 sehr eingeschränkt ist. No. 2225 Juni 2009 Seminar Technische Universität Dortmund Benutzerverwaltung in jCOM1 sehr eingeschränkt ist. Implikation: Die im Prozess durch die Aktionsträger definierten Subjekte und Rollen können den bestehenden Usern und deren organisatorischen Gruppen zugeordnet werden. Hierdurch können sich die nicht am Prozessdesign Partizipierenden dennoch im Prozess orientieren. Quelle: Schmidt; Fleischmann; Gilbert: Subjektorientiertes Geschäftsprozessmanagement. In: HMD 266, S. 56
  • 23. Technische Implementierung des Prozesses Abbildung des Subjektverhaltens Die Implementierung muss also eine Ablaufsteuerung erzeugen (z.B. mit Java) und Anwendungen bzw. Services einbinden, die die nötige fachliche Funktionalität liefern (z.B. mit Business Process Execution Language [BPEL]). Services lassen sich durch Verlinkung, als Portlet, durch Methodenaufruf oder als Webservice integrieren. Auf diesem Weg werden bei Bedarf auch die menschlichen Benutzer in den Workflow einbezogen, indem Services zur Darstellung von Benutzerschnittstellen angestoßen werden, etwa um die Eingabe von Daten in ein Geschäftsobjekt zu erledigen. No. 2325 Juni 2009 Seminar Technische Universität Dortmund werden, etwa um die Eingabe von Daten in ein Geschäftsobjekt zu erledigen. Abbildung der Subjektinteraktionen Subjekte interagieren und synchronisieren sich durch Nachrichtenaustausch. Jedes Subjekt besitzt dazu einen Inputpool, in dem Sendersubjekte Nachrichten ablegen können. Ein Inputpool ist ein parametrisierbarer Servicebaustein (Webservice) mit Einfüge- und Entnahmeoperationen zur Nutzung durch die Subjekte. Implikation: Ähnlich wie bei einer Vorgangssteuerung, welche auch über einen Eingangs-Postkorb verfügt, kann die Zusammenarbeit unter den Beteiligten synchronisiert werden. Quelle: Schmidt; Fleischmann; Gilbert: Subjektorientiertes Geschäftsprozessmanagement. In: HMD 266, S. 57
  • 24. Sofort ausführbare Geschäftsprozesse No. 2420 December 2011 Quelle: Logica 2009
  • 25. Beispiel „Erstellung Datenverlagerungsplan“ An Erstellung Datenverlage- rungsplan G e s a m t p r o z e s s „R e o r g a n i s a t i o n“ Im Rahmen des Gesamtprozesses „Reorganisation“ wurde im Bereich des Access Managements die Aktivität „An Erstellung Datenverlagerungsplan mitwirken“ unter Beteiligung der Aktionsträger entworfen: rungsplan mitwirken Reorg SPOC Fach- abteilungs- SPOC Trigger-Email Fach- abteilungs- Know How Träger Trigger-Email mit Anleitung Datenverlagerungsplanung Liste G:-Laufwerke Liste G:- Laufwerke Beratung zu Laufwerksstrukturen Liste O:/H:-LaufwerkeListe O:/H:-Laufwerke Liefert Info zu Laufwerken No. 2525 Juni 2009 Seminar Technische Universität Dortmund Eine Dokumentation ist obsolet und findet im Model Manager von jPASS! selbst statt.
  • 26. Umgebung jPASS! - Prozesssicht No. 2625 Juni 2009 Seminar Technische Universität Dortmund Betonung auf Objektfluss ähnlich wie bei eEPK in ARIS oder Adonis!
  • 27. Umgebung Model Manager von jPASS! - Subjektinteraktionsdiagramm No. 2725 Juni 2009 Seminar Technische Universität Dortmund Betonung auf Subjektsicht!!!
  • 28. Validierung in jLIVE! nach Start des Tomcat-Servers No. 2825 Juni 2009 Seminar Technische Universität Dortmund
  • 29. Nach Prozessstart durch Eingabe einer beliebigen Session-ID No. 2925 Juni 2009 Seminar Technische Universität Dortmund
  • 30. Aufruf des Subjekts „SPOC Reorganisation“ No. 3025 Juni 2009 Seminar Technische Universität Dortmund
  • 31. Nach Bestätigung der Nachricht an SPOC Fachabteilung No. 3125 Juni 2009 Seminar Technische Universität Dortmund
  • 32. Mit Bestätigung jeder Transitionen wird ein neuer Zustand … 1 2 3 No. 3225 Juni 2009 Seminar Technische Universität Dortmund 4 5 6
  • 33. … hergestellt. 7 8 No. 3325 Juni 2009 Seminar Technische Universität Dortmund
  • 34. Dabei können auch Zustände bei 2 Subjekten simultan übergehen. 99 No. 3425 Juni 2009 Seminar Technische Universität Dortmund
  • 35. Die Zustände der Subjekt werden im Cockpit angezeigt. 10 No. 3525 Juni 2009 Seminar Technische Universität Dortmund
  • 36. Auch Auswahlabfragen können eingebaut werden. 11 No. 3625 Juni 2009 Seminar Technische Universität Dortmund
  • 37. Schließlich wird die Laufwerksinfo erstellt und versendet. 1213 No. 3725 Juni 2009 Seminar Technische Universität Dortmund
  • 38. Weitere Literatur (1) Werner Schmidt, Albert Fleischmann, Oliver Gilbert: Subjektorientierties Geschäftsprozessmanagement. In: HMD 266, S. 52-62 (2) Albert Fleischmann: Subjekt, Prädikat, Objekt in der Grammatik der Software Adobe Acrobat Document Adobe Acrobat Document No. 3825 Juni 2009 Seminar Technische Universität Dortmund
  • 39. Backup No. 3925 Juni 2009 Seminar Technische Universität Dortmund
  • 40. Service Desk • Störungen • Service Requests • Anfragen, Beschwerden, Wünsche, Reklamationen, Anmerkungen und Anforderungen der Anwender • Requests for Change Input No. 4025 Juni 2009 Seminar Technische Universität Dortmund • Requests for Change • Standard Changes • Echte Changes • Aktualisierung und Dokumentation der Incidents • Information des Anwenders und des Kunden • Workarounds, Lösungen • Standard-Changes • Managementinformationen (Berichte) Output Quelle: ITIL 2009
  • 41. Incident Management • Detaillierte Incident-Beschreibung • Einzelheiten zur Konfiguration aus der CMDB • Information über ähnliche Incidents/Problem/Known Errors aus CMDB bzw. Known Error DB • Einzelheiten zur Behebung Input No. 4125 Juni 2009 Seminar Technische Universität Dortmund • Einzelheiten zur Behebung • Lösungsbeschreibung aus existierenden RfCs • RfC zur Störungsbehebung • Aktualisierter Störungs-Record (inkl. Behebung u./o. Workarounds) • Behobene Störungen / abgeschlossene Störungsvorgänge • Mitteilung an Anwender • Managementinformationen (Berichte) Output Quelle: ITIL 2009
  • 42. Problem Management • Störungsdetails aus dem Incident Management • Configuration-Details aus der CMDB • Alle definierten Umgehungslösungen Input No. 4225 Juni 2009 Seminar Technische Universität Dortmund • Lösungen • Bekannte Fehler • RfC • Aktualisierter bzw. abgeschlossener Problem-Record • Information für das Management Output Quelle: ITIL 2009
  • 43. Configuration Management • Geschäftliche Anforderungen / Anforderungen der anderen Service Management Prozesse • Daten zu neu autorisierten Configuration Items (CIs) • Änderungen an CIs / Daten außer Betrieb genommenen CIs • Technische und logische Beziehungen zwischen den CIs Input No. 4325 Juni 2009 Seminar Technische Universität Dortmund • Technische und logische Beziehungen zwischen den CIs • CMDB mit Datenmodell und definierter CI-Struktur (Detaillierungsgrad) • Configuration Management Plan • Definierte Sichten auf Daten • Statusinformation der CIs • Managementinformationen • Informationen zu fehlerhaften CIs Output Quelle: ITIL 2009
  • 44. Relative Kosten der Fehlerbehebung in Abhängigkeit von der Phase No. 4425 Juni 2009 Seminar Technische Universität Dortmund Quelle: William Perry: Effective Methods for Software Testing. John Wiley & Sons, Inc. New York u.a., S. 57
  • 45. Das Service V-Modell • Das Service V-Modell Das V-Modell als das grundlegende Basiskonzept (Key Principle) im Bereich der Service Transition- Phase. Die linke Seite zeigt die Spezifikation auf Basis der Service Requirements auf. Sie wird weiterführend auf Basis des Service Design detailliert aufgearbeitet. 7 45Seminar 2401, 1.1.088 aufgearbeitet. Die rechte Seite fokussiert die Validierungsmaßnahmen, die notwendig sind, um eine grundlegende Abnahme und damit eine Überführung in den Betrieb zu erlangen. Was stellt das "Service V Modell" dar? Verschiedene Testebenen, die benötigt werden, um Servicepotenzial zu liefern Quelle: ITIL 2009