Optimierungspotenziale

Transkript

1 Optimierungspotenziale im IT-Servicemanagement 24. Internationales Frühjahrssymposium Wien, MASTERS Consulting GmbH Seite 1

2 MASTERS Consulting GmbH Konzeptionen umsetzen IT Strategy Management IT Service Management IT Governance Management MASTERS Consulting Risk & Continuity Management IT Portfolio Management Security Management 2015 MASTERS Consulting GmbH Seite 2

3 Optimierungspotenziale im IT-Servicemanagement Agenda Incident Management Problem Management Change Management 2015 MASTERS Consulting GmbH Seite 3

4 Grundsätzliches Klein beginnen Prozessoptimierungen sollen zu einer Verbesserung der Prozessergebnisse führen Zielsetzungen definieren und festschreiben Mit einigen wenigen Problemstellungen anfangen. Später den Aufgabenbereich ausweiten. Erfolgsmessungen Die ersten Verbesserungen sind mit bloßem Auge zu erkennen. Erst wenn ein kontinuierlicher Verbesserungsprozess aufgesetzt wird, mit KPI- Messungen beginnen. Warum? Lohnt sich der Aufwand?, ist die Gretchenfrage 2015 MASTERS Consulting GmbH Seite 4

5 Grundsätzliches Mission Incident Management Zielsetzungen: Incident Management bildet die Schnittstelle der IT-Organisation zu den Nutzern der IT und setzt deren Anliegen innerhalb der IT-Organisation um. Vision: Der Prozess hat seine Zielsetzungen erreicht, wenn ein IT-Anwender seine Anliegen ohne formale, organisatorische oder zeitliche Hürden an die IT-Organisation melden und sich darauf verlassen kann, dass diese dort effizient und effektiv bearbeitet werden. Effekt: Wenn dies gelingt, werden die IT-Anwender sagen, Unsere IT ist prima, wir können uns auf unsere IT-Kollegen verlassen. BEACHTEN SIE: Die IT wird als gut empfunden, nicht der IT-Support! Mission: Minimierung der Auswirkungen von Störungen auf den Geschäftsbetrieb durch Wiederherstellung beeinträchtigter IT-Services innerhalb des vereinbarten Zeitraums und in vereinbarter Qualität. Schaffen einer hohen Anwenderzufriedenheit durch Unterstützung in allen Belangen der IT-Serviceerbringung MASTERS Consulting GmbH Seite 5

6 Grundsätzliches Incident Management und Request Fulfilment Incident Management und Request Fulfilment oder Request Fulfilment als Prozedur innerhalb des Prozesses Incident Management? Das sagt ITIL (vgl. Service Operation, 4.3.2): Some organizations will be comfortable letting the service requests be handled through their incident management process. but in an organization where large numbers of service requests have to be handled, and where the actions to be taken to fulfil those requests are very varied or specialized, it may be appropriate to handle service requests as a completely separate work stream This may be particularly appropriate if the organization has chosen to widen the scope of the service desk to expand upon just IT-related issues and use the desk as a focal point for other types of service request Für zwei eigenständige Prozesse muss es triftige Gründe geben, und die gibt es meistens NICHT MASTERS Consulting GmbH Seite 6

7 Incident Management und Request Fulfilment Nachteile zweier eigenständiger Managementprozesse Beide Prozesse managen dieselbe Zielgruppe: den Anwender. Erhöhter Verwaltungsaufwand durch zwei eigenständige Prozesse und deren Verwaltung in unterschiedlichen Tools. Schnittstellen sind teuer. Dies gilt auch für Prozessschnittstellen. Letztlich wird die Anwenderzufriedenheit durch den Prozess mit der schlechteren Außenwirkung begrenzt. Anders ausgedrückt: Anwenderzufriedenheit entsteht nur im Zusammenspiel beider Managementthemen MASTERS Consulting GmbH Seite 7

8 Incident Management und Request Fulfilment Best Practice Ein Managementprozess für Störungen und Serviceanfragen Unterschiedliche Prozeduren für Störungen und Serviceanfragen Incident Incident melden Anwender Incident erfassen 1st Level Support Störung kategorisieren 1st Level Support Serviceanfrage kategorisieren 1st Level Support Störung bearbeiten 1st Level Support Serviceanfrage bearbeiten 1st Level Support Alle Supportteams für alle Arten von Anwenderanfragen unter zentraler Federführung 2015 MASTERS Consulting GmbH Seite 8

9 Single Point of Contact Ist der kritische Erfolgsfaktor für das Incident Management Hat viele Vorteile: Zentrale Anlaufstelle für Anwender Zentrale Informationsquelle für Anwender Zentrale Erfassungsstelle für alle Störungen und Serviceanfragen Effizientes Ressourcenmanagement durch Trennung in 1st und 2nd Level Support ABER beachten Sie beide Seiten der Medaille: Bevor alle Anwenderanfragen auf eine zentrale Annahmestelle geleitet werden, muss diese Annahmestelle auf den erforderlichen Durchsatz optimiert werden. Wenn heute z. B. 50% der Tickets außerhalb des Service Desk angenommen werden und Sie verlangen, dass ab morgen alles über den zentralen Service Desk läuft. Na dann herzlichen Glückwunsch! 2015 MASTERS Consulting GmbH Seite 9

10 Gestalten eines Self-Service-Portals ITIL empfiehlt die Einrichtung des Self-Service-Portals für Service Requests Portal für Serviceanfragen Service Desk Standardanfragen Freitext-Anfragen Passwort vergessen Wie funktioniert das? Arbeitsplatz einrichten Wir ziehen um Quellen für Fehldesigns Ab heute darf der Service Desk nur noch bei Störungen kontaktiert werden, denn Serviceanfragen sollen ausschließlich über das Serviceportal übermittelt werden 2015 MASTERS Consulting GmbH Seite 10

11 Best Practices zur Gestaltung eines Self-Service-Portals Vergessen Sie Ihre Zielsetzungen nicht: Der Prozess hat seine Zielsetzungen erreicht, wenn ein IT-Anwender seine Anliegen ohne formale, organisatorische oder zeitliche Hürden an die IT-Organisation melden und sich darauf verlassen kann, dass diese dort effizient umgesetzt werden. Sind Sie sicher, dass die Anwender in das Freitextfeld keine Störungen eintragen? Können Anwender zwischen Störungen und Serviceanfragen unterscheiden? Interessiert sie das? Was machen Sie, wenn über das Serviceportal aus Versehen eine Störung gemeldet wird? 2015 MASTERS Consulting GmbH Seite 11

12 Best Practice zur Gestaltung eines Self-Service-Portals Können Sie sicher zwischen Störungsmeldungen und Serviceanforderungen unterscheiden? Ich habe mein Passwort vergessen Ich habe die falschen Zugriffsrechte und kann deshalb meine Arbeit nicht verrichten Ich habe aus Versehen eine Datei gelöscht. Bitte spielen Sie das Restore ein. Ich habe aus Versehen alle Kundenstammdaten gelöscht. Bitte spielen Sie das Restore ein. Ich habe letzte Woche eine Störung gemeldet. Wie ist der Bearbeitungsstand? Ich habe erfahren, dass meine Störungsmeldung noch immer nicht bearbeitet wird. Ich möchte mich beschweren. Wir sollten unsere Anwender wirklich nicht zwingen, solche Fallunterscheidungen vorzunehmen MASTERS Consulting GmbH Seite 12

13 Best Practice zur Gestaltung eines Self-Service-Portals Störungen + Serviceanforderungen Störungen + Serviceanforderungen Portal für Meldungen an die IT Standardanfragen Freitext-Meldungen Passwort vergessen Service Desk (Single point of contact) Wie funktioniert das? Arbeitsplatz einrichten Wir ziehen um Störung kategorisieren Serviceanfrage kategorisieren 2015 MASTERS Consulting GmbH Seite 13

14 Teamregeln im Incident Management Der SPoC wird umgangen Warum nehmen denn die Administratoren die Tickets an? Sie sollten den Anrufer fragen: Haben Sie schon eine Ticket-ID? Nein? Dann rufen Sie bitte beim Service Desk an. Dort wird Ihnen dann auch ein Bearbeiter zugewiesen. Unterschiedliche Wahrnehmung der Erstlösungsrate Der Leiter des Service Desk ist der Meinung, dass seine Erstlösungsrate gut ist Die nachgelagerten Support-Teams finden, dass der Service Desk viel zu wenig Anfragen selbst löst Kann man diese unterschiedliche Wahrnehmung quantifizieren? Ja, man kann! 2015 MASTERS Consulting GmbH Seite 14

15 Best Practice: Erstlösungsrate optimieren Nach jedem Ticket, das vom 2nd Level Support bearbeitet wurde, soll der 2nd Level Supporter drei Fragen beantworten: War das ein Fall, der vom 1st Level Support hätte gelöst werden müssen? Wenn diese Frage bejaht wird, geht der Fall an den Leiter Service Desk mit der Frage, warum das nicht geschehen ist. War das ein Fall, der künftig vom 1st Level Support gelöst werden sollte? Wenn diese Frage bejaht wird, geht der Fall an den Leiter der eigenen Abteilung mit der Frage, wie der 1st Level Support dazu befähigt werden kann. Ist das ein Fall, der auch künftig nicht vom 1st Level Support bearbeitet werden soll? Wenn diese Frage bejaht wird, bleibt alles wie es ist MASTERS Consulting GmbH Seite 15

16 Best Practice: Was tun, wenn eine Störung nicht gelöst werden kann? Erste Untersuchung 1st Level Support nicht gelöst Untersuchung & Diagnose 2nd Level Support gelöst gelöst nicht gelöst Untersuchung & Diagnose 3nd Level Support gelöst nicht gelöst Untersuchung & Diagnose 3nd Party Support gelöst nicht gelöst und nun? gelöst (Hurra) 2015 MASTERS Consulting GmbH Seite 16

17 Best Practice: Was tun, wenn eine Störung nicht gelöst werden kann? Erste Untersuchung 1st Level Support nicht gelöst Untersuchung & Diagnose 2nd Level Support gelöst gelöst nicht gelöst Untersuchung & Diagnose 3nd Level Support gelöst nicht gelöst Untersuchung & Diagnose 3nd Party Support Nein gelöst nicht gelöst und Problem nun? Management gelöst (Hurra) 2015 MASTERS Consulting GmbH Seite 17

18 Best Practice: Was tun, wenn eine Störung nicht gelöst werden kann? Erste Untersuchung 1st Level Support nicht gelöst Untersuchung & Diagnose 2nd Level Support gelöst gelöst nicht gelöst Untersuchung & Diagnose 3nd Level Support gelöst nicht gelöst Untersuchung & Diagnose 3nd Party Support gelöst nicht gelöst und Task nun? Force (ggf. massiv ersetzen) gelöst (Hurra) 2015 MASTERS Consulting GmbH Seite 18

19 Die Potenziale der Incident-Datenbank nutzen Incident-Datenbank als Plattform für statistische Auswertungen: Sie unterstützt nicht nur die Support-Teams, sondern viele nachgelagerte Prozesse: Problem Management: Gibt es Störungsquellen, die beseitigt werden sollten? Change Management: Wie oft gibt es Folgestörungen nach Changes? Configuration Mgmt.: Gibt es gestörte Komponenten ohne Eintrag in der CMDB? Release Management: Welche Release-Komponenten sind besonders anfällig? Service Level Mgmt.: Auswirkungen von Störungen auf Services. Availability Management: Gibt es Ausfall-Trends, die ein Re-Design erfordern? Capacity Mamagement: Gibt es Engpass-Trends, die ein Re-Design erfordern? Security Management: Wo und wie oft gibt es Sicherheitsstörungen? Continuity Management: Gibt es Störungen, die sich zu Notfällen ausweiten können? Mindestens neun Prozesse brauchen Auswertungen aus der Incident-Datenbank! 2015 MASTERS Consulting GmbH Seite 19

20 Die Potenziale der Incident-Datenbank nutzen Wie macht man die Incident-Datenbank auswertungsfähig? => Kategorienkonzept Das haben alle: Aber daran denkt kaum jemand: Notebooks Server Sony Vaio VGN-SZ61MN Ausfall (Verfügbarkeitsstörung) Leistungsengpass (Kapazitätsstörung) Folgestörung nach Change Sicherheitsstörung Notfall HP ProLiant ML 350p Gen8 Netzwerk Switch Cisco SG500X-48P 2015 MASTERS Consulting GmbH Seite 20

21 Die Potenziale der Incident-Datenbank nutzen Wirkungskategorie Das Symptom, das der Nutzer meldet (z. B.: geht nicht) Wird bei der Annahme des Tickets erfasst Lösungskategorie Was hat tatsächlich zu der Störung geführt? (z. B.: Netzwerkausfall) Wird beim Abschluss des Tickets erfasst Ein Anwender ruft an und meldet einen -Ausfall Über welche Kategorie recherchiert der Supporter? Der Leiter Netzwerke möchte wissen, wie viele Netzwerkstörungen es letzten Monat tatsächlich gegeben hat. Über welche Kategorie recherchiert er? 2015 MASTERS Consulting GmbH Seite 21

22 Optimierungspotenziale im IT-Servicemanagement Agenda Incident Management Problem Management Change und Configuration Management 2015 MASTERS Consulting GmbH Seite 22

23 Grundsätzliches Mission Problem Management Zielsetzungen: Problem Management beseitigt Bugs an Systemen im operativen Einsatz, damit diese Systeme zuverlässig und fehlerfrei funktionieren. Problem Management hat keinen institutionalisierten Kontakt zu Anwendern. Vision: Der Prozess hat seine Zielsetzungen erreicht, wenn das Störungsaufkommen nachhaltig reduziert werden kann. Effekt: Wenn dies gelingt, werden die IT-Anwender den Service Desk vermissen die Support- Teams entlastet und die Betriebskosten gesenkt. Mission: Langfristige Stabilisierung der IT-Infrastruktur und damit der IT-Servicefähigkeit durch nachhaltige Beseitigung der Ursachen von Störungen an den zu erbringenden IT-Dienstleistungen MASTERS Consulting GmbH Seite 23

24 Incident Management versus Problem Management Support-Strukturen abseits von ITIL Was sagen die anderen? Arbeiten Sie nicht nur reaktiv an der Störungsbehebung Hinterfragen und beseitigen Sie die Quellen von Störungen Andernfalls gerät ihr Help Desk über kurz oder lang außer Kontrolle, da die gelösten Störungen wieder auftreten und neue Störungsquellen dazukommen Support-Organisation Help Desk (reaktiv) Back Office (proaktiv) Incidents 2015 MASTERS Consulting GmbH Seite 24

25 Incident Management versus Problem Management Support-Strukturen von ITIL Wie macht es ITIL? Trennung von Störungsbearbeitung (reaktiv) und Problembehebung (proaktiv) Grund: Unterschiedliche Zielsetzungen, Arbeitsverfahren und Zeitläufe Wenn man Störungsbearbeitung und Problembehebung vermischt, bleibt am Ende nur Störungsbearbeitung übrig Support-Organisation Incident Management (reaktiv) Problem Management (proaktiv) Incidents Was übergeben? 2015 MASTERS Consulting GmbH Seite 25

26 Was soll übergeben werden? Was soll übergeben werden? Keine offenen Störungen Eine Störung, die nicht gelöst werden kann, ist kein Problem Nur Fälle mit starken geschäftlichen Auswirkungen Nur Fälle mit komplexen, nicht offensichtlichen Ursachen Effekt: Wenige, aber relevante Arbeitsaufträge 2015 MASTERS Consulting GmbH Seite 26

27 Zweistufiges Arbeitsverfahren Incident M. I.-DB Auswirkung P.-DB Problem Management Fehlerursache ermitteln KEDB Einzig möglicher Ausstiegspunkt Lösungskonzept erstellen RfC Change M. Post Implementation Review (PIR) Known Errors und Work-arounds Häufigkeit 2015 MASTERS Consulting GmbH Seite 27

28 Störungen einem Problem zuordnen Fehldesigns: Status eines Incidents auf Problem ändern Falsch: Aus einer Störung wird nie ein Problem Problemdatensatz anlegen und zugehörige Störungen mit der Maus zuordnen Falsch: Was, wenn wir tausende Tickets in der Incident-Datenbank haben? Incident in Problemdatenbank kopieren. Man erspart sich Doppelerfassung und alle offenen Incidents sind schon zugeordnet Falsch: Auch bereits geschlossene Incidents müssen zugeordnet werden Die korrekte Zuordnung der relevanten Incidents kann sehr zeitaufwändig sein Die korrekte Zuordnung der relevanten Incidents ist aber erforderlich, um ein verlässliches Fehlerbild zu erhalten Die korrekte Zuordnung der relevanten Incidents ist ein kritischer Erfolgsfaktor 2015 MASTERS Consulting GmbH Seite 28

29 Störungen einem Problem zuordnen Problem Management Incident M. I.-DB P.-DB Fehlerursache ermitteln KEDB Lösungskonzept erstellen RfC Change M. Post Implementation Review (PIR) Known Errors und Work-arounds CMDB Gruppe: Sony Notebook Vaio VGN-SZ61MN, user: Markus Lindinger Vaio F11N1L2EP, user: Ulrich Peters Vaio F1521A7EB, user: Vladimir Merkel 2015 MASTERS Consulting GmbH Seite 29

30 Wozu dient der Post Implementation Review? Problem Management P.-DB Fehlerursache ermitteln KEDB Lösungskonzept erstellen RfC Change M. Post Implementation Review (PIR) Wurden die Änderungen an allen CIs durchgeführt? Wenn ja: KEDB aufräumen Known Errors und Work-arounds Nach jeder Problembearbeitung durchführen 2015 MASTERS Consulting GmbH Seite 30

31 Vom Umgang mit Work-arounds Fundstellen für Work-arounds: Störungs- und Lösungsbeschreibungen I.-DB Incidents mit Work-arounds (nicht verifiziert) Known Errors und Work-arounds KEDB Known Errors mit Work-arounds (verifiziert) Soll der Supporter wirklich in zwei Datenbanken suchen? Nein! Aber wie sieht eine integrierte Lösung aus? 2015 MASTERS Consulting GmbH Seite 31

32 Vom Umgang mit Work-arounds Die Lösung: Problem Management Störungsbeschreibungen Workflow: Work-arounds prüfen Known Errors RfC Change M. I.-DB KEDB Incidents Known Errors Work-arounds (verifiziert) (verifiziert) (verifiziert) 2015 MASTERS Consulting GmbH Seite 32

33 Optimierungspotenziale im IT-Servicemanagement Agenda Incident Management Problem Management Change Management 2015 MASTERS Consulting GmbH Seite 33

34 Grundsätzliches Mission Change Management Zielsetzungen: Change Management steuert Änderungen an Produktivsystemen unter dem Gesichtspunkt der Risikominimierung. Change Management ist Anwalt für den operativen Betrieb und für die geschäftlichen Belange der IT-Kunden. Vision: Der Prozess hat seine Zielsetzungen erreicht, wenn autorisierte Änderungen zeit- und kostengerecht sowie in der erwarteten Qualität umgesetzt werden können. Effekt: Wenn dies gelingt, wird bei allen Parteien ein Konsens über die Qualitätsanforderungen sowie eine verlässliche Ergebnisqualität bei der Umsetzung von Änderungen erreicht. Mission: Sicherstellen, dass Änderungen am IT-Betrieb unter dem Aspekt der Risikominimierung effizient und mit möglichst geringen negativen Auswirkungen auf die Qualität der IT-Serviceerbringung durchgeführt werden MASTERS Consulting GmbH Seite 34

35 Grundsätzliches Kernelemente des Change Management CAB RFC prüfen Autorisierung Notfall-Changes Change Management ECAB Reduzierte Qualitätssicherung realisieren, testen Abnahmeerklärung Dokumentation Betriebsbereitschaft Nutzer-Schulung Testergebnisse Rückfallplan Review implementieren Freigabe 2015 MASTERS Consulting GmbH Seite 35

36 Langsam anfangen Change Management hat ein Problem: es wird leicht zum Bremsklotz für den Betrieb Der Change Manager soll mit den Leitungsfunktionen vereinbaren, welche (wichtigen) Changes er sehen möchte Beschränken Sie sich zunächst auf wenige, risikobehaftete Changes Besser wenige Changes richtig, als viele Changes gar nicht bearbeiten Welche Aussage ist besser? Unser Change Management bearbeitet zwar nicht alle Changes, aber die Wichtigsten oder Unser Change Management bearbeitet zwar alle Changes, aber kriegt nichts auf die Reihe 2015 MASTERS Consulting GmbH Seite 36

37 Vorautorisierung reduziert Arbeitslast Erklären Sie bei der ersten Inbetriebnahme des Change Management alle Änderungen für vorautorisiert, mit Ausnahme der mit den Verantwortlichen vereinbarten wichtigen Changes (Positivliste) Nehmen Sie bewusst in Kauf, dass Ihnen am Anfang u. U. risikobehaftete Changes durch die Lappen gehen Behalten Sie sich das Recht vor, Vorautorisierungen zurückzunehmen Vorautorisierte Changes heißen auch Standard-Changes. Arbeiten Sie darauf hin, dass Standard-Changes mit der Zeit über hinterlegte Standardverfahren bearbeitet werden Wenn Ihr Prozess einen höheren Reifegrad erreicht hat, sollte gelten: Vorautorisierung nur gegen Standard-Bearbeitungsverfahren Wenn Ihr Prozess einen noch höheren Reifegrad hat, sollten alle Standardverfahren in einem allgemein zugänglichen Betriebsführungshandbuch hinterlegt sein 2015 MASTERS Consulting GmbH Seite 37

38 Die Potenziale des CAB nutzen Das CAB macht aus Ihrem Change Management in eine Erfolgsgeschichte Laden Sie ein wen Sie brauchen ohne Rücksicht auf Rang und Namen IT-Kunden IT-Nutzer IT-Entwickler IT-Betrieb Sourcing-Partner Über das CAB gestalten Sie Kommunikationskanäle zu Ihren Kunden und Lieferanten 2015 MASTERS Consulting GmbH Seite 38

39 Die Potenziale des CAB nutzen Das CAB macht aus Ihrem Change Management in eine Erfolgsgeschichte Das CAB schafft Klarheit und Konsens Koordinieren Sie darüber alle Terminpläne Wunschtermine der Kunden im RFC Release-Termine, Termine der Software-Entwickler Beschaffungstermine Projekttermine Testtermine Implementierungsfenster im Betriebskalender 2015 MASTERS Consulting GmbH Seite 39

40 Optimierungspotenziale im IT-Servicemanagement Weiterführende Informationen finden Sie in Oliver Bartsch / Markus Lindinger (Hrsg.) IT-Servicemanagement Compliance und Wirtschaftlichkeit in der IT TÜV Rheinland DIN A5, 2 Ordner + CD-ROM oder als Onlinelösung 4 Ergänzungen jährlich MASTERS Consulting GmbH Seite 40

41 Danke für Ihre Aufmerksamkeit Und so erreichen Sie uns MASTERS Consulting GmbH Am Sandtorkai Hamburg Tel.: Fax: Mail: Web: MASTERS Consulting GmbH Seite 41