step2.at

Mit der SAP Netweaver BPM Suite ist der größte ERP Software Hersteller seit einiger Zeit auch am BPM Tool Markt aktiv. Die bereits vor einigen Jahren angekündiget Lösung für prozess- bzw. modell basiertes Customizing könnten in Zeiten von BPMN, Web Dynpros, Web Services und XML endlich Wirklichkeit werden.

Wie integriert sind Ihre (SAP-) Abläufe wirklich? Wo nicht gibt es immer noch eMails oder Telefon-Anrufe, um die Prozesse am Laufen zu halten. Speziell bei den Kernprozessen, die direkt über unternehmerischen Erfolg oder Misserfolg entscheiden, sind solche “Medienbrüche” besonders störend.

Ob die SAP Lösung mit den Branchen Größen wirklich mithalten kann, bleibt noch zu beweisen.

Weitere Infos zur Lösung sind  hier zusammengefasst!

Ich möchte in diesem Beitrag ein bekanntes Thema etwas vertiefen. Incident Management ist der am weitesten verbreitete Prozess im ITIL-Umfeld. Damit einher geht auch das entsprechende Incident Reporting - also die Auswertung von bearbeiteten Support Calls und die daraus resultierenden Erkenntnisse und Verbesserungs-Ansätze.

Die einfachste Form des Reporting ist die Auswertung und Darstellung von Zeitreihen bezogen auf Call-Volumina (siehe unten). Einfach zu erstellen, ist diese Form der Auswertung fast überall anzutreffen. Alleine die daraus ableitbaren Aussagen sind sehr eingeschränkt. Ein vernünftiges Incident Reporting muss weiter, tiefer gehen und zumindest in Ansätzen die Prozess- und die Service-Qualität berücksichtigen.

Volumina – Wie viele Calls je Typ, je Kategorie, je Priorität etc. ? … Gut, es werden Calls erfasst und abgearbeitet; und es gibt Services/Produkte, die mehr oder weniger Calls verursachen - so weit, so gut! Es können aber nur bedingt Aussagen zur Prozess- bzw. Service-Qualität getroffen werden.

Prozess Qualität - Wie gut ist der Incident Management bzw. der Support Prozess selbst? - Messung der Qualität der angebotenen Support-Dienstleistung. Klassische Auswertungen hier betreffen u.a.

• Erreichbarkeit (meist in Zusammenhang mit dem ServiceDesk als Single Point of Contact - SPOC, durchschnittliche Wartezeit von Anrufern, wie viele Anrufe werden nicht entgegen genommen, etc.)
• Lösungsraten (Erstlösungsrate im ServiceDesk, Häufigkeit von Vor-Ort Service, Lösungsraten im Second und Third Level)
• Bearbeitungszeiten (Reaktionszeiten der einzelnen Level, durchschnittliche Störungsdauer, Downtime, Wiederherstellungszeit, Mean Time To Repair MTTR etc.)
  (mehr Details z.B. im DITY Newsletter)
• Kosten (z.B. Kosten je Störung)

(Quelle: DITY Newsletter)

Die Auswertung der Prozess Qualität liefert Erkenntnisse für die kontinuierliche Verbesserung (KVP) des Support Prozesses!

Service Qualität - Wie viele Störungen gibt es bei den angebotenen Services / eingesetzten Produkten - Messung der Qualität der angebotenen Dienstleistungen. Maßgeblich hierfür sind die mit dem Kunden vereinbarten Services bzw. Service Levels (in SLAs), Störungs-Häufungen & Schnittstelle zum Problem Management (z.B. in bezug auf Configruation Items), Mean Time Between Failure (MTBF), etc.

Die Auswertung der Service Qualität liefert Erkenntnisse für die kontinuierliche Verbesserung (KVP) des Leistungsangebotes / der angebotenen Services - alles mit dem Ziel die Verfügbarkeit der Services zu erhöhen.

Weitere Aspekte im Incident Reporting könnten sein:

• Wirksamkeit der IT Organisation = Kundenzufriedenheit
• Auslastung der Support Mitarbeiter - Call Volumen je Mitarbeiter
• Sicherheitsbeeinträchtigung (Security Issues)

Auf Basis dieser Grundansätze kann ein erstes Incident Reporting relativ einfach aufgebaut werden. Im Rahmen der laufenden Prozess Management Aufgabe des Incident Managers muss dieses kontinuierlich verbessert, ausgebaut bzw. geschärft werden.

ACHTUNG! Bei Kennzahlen-Systemen und Reporting ist man oft verleitet alles bzw. zu viel auszuwerten! Wesentlich sind einige wenige Kennzahlen, die valide Rückschlüsse auf den Zustand der Prozesse und Services bieten.

Großspurig habe ich in meinem letzten Blogpost die Aktualisierung meiner Homepage verkündet. Das war Mitte Oktober 2008 – das ist dann wohl ca. ½ Jahr her!

Ich bin aus der Versenkung wieder auferstanden! – Welcome back!

In der Zwischenzeit war ich aber nicht untätig. U.a. habe ich mich in meinen Projekten mit folgenden Themen beschäftigt, die sicherlich den einen oder anderen zukünftigen Post beeinflussen werden:

Governance & Strategie

• Entwicklung von Business Strategien, Balanced Scorecard, Kernkompetenzen (Core Competencies), Erfolgsfaktoren (Success Factors), etc.
• Erarbeitung und Umsetzung von IT Strategien

Prozesse

• Ansätze für ein BusinessProcessManagement
• Effizienz-Steigerung und Kosten-Optimierung in der IT
• Prozess Orientierung in IT Organisationen
• Incident & Problem Management – Aufgaben eines Incident Managers, Incident Management Reporting
• Change Request Management & Release Management
• SCRUM, Agiles Projekt Management/Agile Software Entwicklung
• SW Test Management / TPI - Test Prozess

Web & Personal Efficiency

• GTD, Evernote
• Microsoft SharePoint
• Wordpress v2.7, Themes, Plug-in
• etc.

Einige Ideen für Posts schlummern auch noch in meinen Entwürfen - also Happy Posting in der Zukunft!

Vielen ist es in der Vergangenheit aufgefallen - meine Homepage/mein Blog war nicht komplett. So etwas wie eine Vision bzw. eine Philosophie war zwar im Menü vorgesehen - “jedoch war nix dahinter”. Auch was meine angebotenen Dienstleistungen nun sind, war nur schwer zu erfahren.

Die endgültige Version ist das nun auch noch nicht, aber zumindest kann man erahnen was dahinter steckt und wofür ich stehe.

In einem Satz ist das ganz einfach zusammen gefasst: “Kundenorientierung in der IT!” - Mein Ziel ist es, IT Abteilungen zu modernen, kundenorientierten Dienstleistern hin zu entwickeln. Einige meiner Posts beschäftigen sich auch geanu damit.

Auch die Kernaussagen der  beiden neuen Seiten lassen diesen Schluss m.M. zu!

Meine Philosophie

Meine Dienstleistungen

… to be continued !

Hier ein anschauliches Beispiel wie Vor-Ort Support funktioniert. Bitte speziell auch darauf achten, wie Benutzer/Menschen an alten erprobten Gewohnheiten festhalten (wollen). IT hat immer mit Veränderung zu tun – ob es in diesem Fall zum Besseren, soll jeder  selbst beurteilen.

Das Problem ist erfasst - die Ursache ist untersucht und im besten Fall auch gefunden. - Und nun?

Workaround

Wenn im ersten Schritt keine vollständige Lösung gefunden werden kann, so soll zumindest ein Workaround definiert werden. Dies gilt insbesondere bei Störungen und daraus abgeleiteten Problemen - dh. die Störung möglichst schnell beheben - auch mit einem Workaround.

• Workaround im Problem Record vermerken.
• Das Problem bleibt aber weiterhin offen.
• Weiter, tiefer suchen, um eine Lösung zu finden.

Ziel des Problem Management ist die vollständige Behebung des Problems - also kann ein Workaround nur ein Zwischenstep sein.

Known Error

Wenn die Ursache des Problems gefunden wurde und u.U. auch ein Workaround gefunden wurde, kann das Problem als Known Error gekennzeichnet werden. Diese Informationen werden zur schnelleren Abwicklung für zwischenzeitlich auftretende Störungen und Probleme verwendet.

Der genaue Zeitpunkt wann ein Known Error erfaßt wird, hängt von der konkreten Situation ab (kann aus Informations-Gründen auch vor dem Finden der kompletten Ursachen erfolgen)

!! >> Werden neue Funktionen trotz bekannter Fehler produktiv genommen (z.B. weil ein Release trotzdem innerhalb des Zeitplan durchgehen soll), so sollten diese Fehler bereits als Known Errors mit Workaround erfasst werden. Dies wirkt sich im Nachhinein positiv auf die Supportaufwände aus.

Problem Lösung

Im besten Fall wird durch das Problem Management die Lösung zu dem Problem gefunden. Dies wird in den meisten Fällen eine Änderung nach sich ziehen, dh. es ist ein Request for Change zu erstellen.

Die Umsetzung des Changes erfolgt entsprechend den Definitionen im Change bzw. Release Management. Dies kann eine zeitliche Verzögerung bedeuten. Handelt es sich aber um ein signifikantes Problem, so kann ggf. eine Notfall Änderung angestoßen werden.

Egal ob der Change sofort umgesetzt wird oder nicht, die Lösung ist auf jeden Fall im Problem bzw. Known Error Record zu vermerken

Problem Abschluss

Nachdem der angeforderte Change umgesetzt und überprüft wurde, kann das Problem und alle verknüpften Records (z.B. Incidents) abgeschlossen werden. Alle relevanten Dokumentationen, Known Error, Wissensdatenbank, etc. sollen abschliessend noch auf den aktuellsten Stand gebracht werden.

Dies ist das vorläufige Ende meiner Serie zum ITIL Problem Management Prozess - weitere Serien werden folgen!  ;->

Einfach den Feed abonnieren 

Das Erkennen und Registrieren eines Problems ist die eine Seite - die viel wichtigere ist aber, die Ursache zu finden und eine Lösung zu erarbeiten.

Es ist davon auszugehen, daß du Ursache bei Problemen nicht ohne weiteres zu finden ist (denn ansonsten wäre das Problem schon lange gelöst). Es gilt also, spezielle Techniken und Tools anzuwenden, um eine möglichst effektive und effiziente Ursachen-Analyse durchzuführen.

Entsprechend der nachfolgenden Grafik befinden wir uns im Schritt “Problem Control” mit dem Ziel eine Ursache für das Problem zu finden.

Vortrag während der itSMF Fusion 2008 von Jay Long (gesehen im Blog IT´s About Uptime)

Oft verwendete Hilfsmittel zur Ursachen-Ermittlung:

• Recherche in den vorhandenen Wissendatenbanken (u.a. in Incidents und Known Errors)
• Fehler chronologisch nachstellen (im Detail inkl. Ablauf-Protokoll), um die Ursache besser eingrenzen zu können
• Brarinstorming - kein Kommentar ;–> Wikipedia
• “Pain Value” Analyse - (aus ITIL v3) berücksichtigt mehrerer Faktoren (Anzahl betroffene User, Dauer des Ausfalls, Kosten des Ausfalls, etc.) und versucht so die Priorisierung zu verfeinern (behandelt also nur indirekt die Ursache) –> Link
• “Kepner & Tregoe” Methode - Problem definieren, im Detail beschreiben, mögliche Ursache identifizieren, was ist wahrscheinlich, überprüfen. –> Wikipedia, dazu im Problem Mgmnt Blog, itsmsolutions Beitrag, kepner-tregoe.com
• Ursache-Wirkung (Ishikawa)-Diagram - kein Kommentar
  ;–> Wikipedia, itsmsolutions Beitrag

Eine Methode die von vielen Praktikern favorisiert wird ist die “5 Whys” Methode - übersetzt 5 x Warum. Es ähnelt ein klein wenig an Kindererziehung, aber das Ziel ist event. das gleiche - Finde heraus was wirklich dahinter steckt! Hier einige Referenzen dazu: wie immer gibt es alles bei Wikipedia, aber auch Hank Marquis von itsmsolution hat eine kurze Zusammenfassung, genauso wie Dennis Powell im StockSafe Blog.

!! >> Für eine möglichst effiziente Recherche in bereits bekannten Themen ist die laufende Pflege der Wissendatenbanken bzw. der Known Error Datenbank wichtit. Darauf ist bei der Umsetzung der Prozesse zu achten.

!! >> Um Problem nachvollziehen zu können ist meist ein Test-System hilfreich (ähnlich wie auch beim Test von Changes). Daraus  ergibt sich, bei so vielen Systemen wie möglich, zumindet eine 2-System Landschaft.

!! >> Ziel ist es Ursachen zu finden und Probleme zu lösen - immer die für die Organisation und das Problem geeignete Methode auswählen. Auf keinen Fall mit blindem Aktionismus an das Thema ran gehen.

weitere Referenzen:

• Problem Management Blog von Ronald Bartels

Bleiben Sie up-to-date und lesen Sie auch die nächsten Folgen! Einfach den Feed abonnieren 

Der Einstiegspunkt in den Problem Management Prozess ist die erste Hürde. Diese Schnittstelle zu z.B. Incident und Availability Management und der Ankerpunkt für alle Beteiligten (im Sinne des KVP) muss klar definiert und gut kommuniziert sein.

Allen Beteiligten muss bewusst sein, dass es im ersten Schritt lediglich um das Erkennen und Registrieren eines Problems geht - es geht noch nicht um die Lösung. (Motto: “Wer was sieht, der  schreibt es auf!“) Oft liegt ein Hindernis darin, dass sofort versucht wird, das Problem zu lösen. Da dies aber in vielen Fällen nicht sofort möglich ist, wird von einer Erfassung des Problems abgesehen.

Wo und wie können Probleme erkannt werden:

Erkennung durch den Service Desk (reaktiv)

Störungen, …
- die nur mit einem Workaround vorläufig gelöst wurden
- bei denen die wirkliche Ursache nicht gefunden wurde
- die immer wieder auftreten
- die ein Major Problem verursacht haben

Den Service Desk Mitarbeitern muss klar sein, in welchen Fällen ein Problem anzulegen ist.

Die gleiche Festlegung muss auch für die Mitarbeiter des Second Level (und alle weiteren IT Mitarbeiter) gelten, dh. es muss klar sein wann und wie Probleme anzulegen sind.

Hinweis von Dritten, Partnern oder Herstellern verwendeter HW od. SW (reaktiv)

Jeder Partner der IT Abteilung kann Hinweise zu möglichen Problemen geben. Dies kann aktiv durch den Partner erfolgen oder reaktiv durch Prüfung von Knowledge Base Einträgen o.ä.

Klar regeln, wer intern für die Erfassung solcher Probleme zuständig ist (z.B. alle Kontakte über Service Desk, Problem Manager, Partner Manager) - am besten der direkte Kontakt.

Erkenntnisse aus der Analyse der Incidents (proaktiv)

Sowohl Incident Manager als auch Problem Manager haben die Aufgabe durch laufendes Monitoring des Service Support-Geschehens Erkenntnisse zur Verbesserung der Prozess- und der Service-Qualität zu gewinnen.

Diese Aufgabe muss dem Incident und dem Problem Manager bewusst sein. (z.B. in die laufende Management-Tätigkeit mit einbauen oder als fixe Termine im Kalender vorsehen)

Bei der Definition der Kategorien bereits auf diese Aufgabe achten. Reports  und Trend-Analysen entsprechend definieren. (periodisch, automatisiert aufrufbar)

Jeder kann ein Problem erkennen (proaktiv)

Dies entspricht u.a. dem klassischen KVP (Kontinuierlicher Verbesserungs-Prozess). Jeder Mitarbeiter ist aufgefordert seinen Beitrag zur Verbesserung des Gesamt-Systems zu leisten.

Wichtig ist, die Kultur in diese Richtung zu verändern. Fehler und Probleme sind Chancen zur Verbesserung.

Das Verfahren, um Verbesserungs-Vorschläge platzieren zu können, muss so einfach wie möglich sein. (z.B. als Link auf einer zentralen Intranet Seite)

Dokumentieren des Problems

In allen oben beschriebenen Fällen, wo ein Problem erkannt wurde, muss ein sog. Problem Record angelegt werden. Dies dient zur Strukturierung und Sammlung aller weiteren Aktivitäten rund um das spezifische Problem.

Kategorisieren und Priorisieren

Um die gegenseitige Referenzierung zu vereinfachen gelten für die Kategorisierung und Priorisierung die gleichen Definitionen, wie im Incident Management.

Die Ursachen-Analyse kann zu einer Verfeinerung der Kategorisierung führen (u.a. für spätere Auswertbarkeit) - ist aber meist abhängig vom Tool.

Wenn die Prioritäten grundsätzlich gleich zum Incident Management gewählt werden sollen, so sollten die entsprechenden Bearbeitungszeiten u.U. etwas weiter gewählt werden. (z.B. im Wochen-Takt)

 Bleiben Sie up-to-date und lesen Sie auch die nächsten Folgen! Einfach den Feed abonnieren 

Wie im Titel erwähnt gibt es zwei grundsätzlich unterschiedliche Ansätze für das Problem Management:

Re-aktiv

• als Folge von Störungen und deren Behebung
• ausgelöst meist durch den Service Desk

Pro-aktiv

• abgeleitet aus der laufenden Verbesserung

Beide Aspekte müssen entsprechend umgesetzt werden, wobei der proaktive besonders zu beachten ist.

Schnittstellen Problem Management - in / out

• Change Management
  - an ChM: Übergabe von notwendige Änderungen
  - von ChM: Status und Feedback während der Entwicklung
• Configuration Management
  - von CMDB: Daten über betroffen CIs
• Release Management
  - an RM: über das Change Management

weitere:

• Availability Management
• Capacity Management
• Continuity Management
• Service Level Management
• Financial Management

Bleiben Sie up-to-date und lesen Sie auch die nächsten Folgen! Einfach den Feed abonnieren 

Das Problem Management versucht, wiederkehrende Störungen einer endgültigen Lösung zuzuführen. Es versucht in seiner proaktiven Ausprägung bereits zu reagieren, bevor etwas passiert. Das Problem Management ist damit Kernelement einer stetigen Verbesserung der IT Dienstleistungen und aus dieser Sicht ist es auch wichtiger als die reine Störungsbehebung (die ausschließlich reaktiv agiert).

Durch die  tiefergreifende Analyse von Problemen entsteht auch ein großer Beitrag zum Wissensaufbau in der IT. (siehe Known Error Datenbank, Wissensdatenbank, etc.)

Zusammenfassend steht das Problem Management für:

• Stabilisierung der IT-Services,
• Vermeidung von Störungen (Incidents),
• proaktive Optimierung der IT-Infrastruktur
• durch Ursachenanalyse, Erarbeitung von Lösungswegen, etc.

Prozess-Schritte

Der Prpblem Management Prozess besteht grob aus folgenden Schritten:

• Problem identifizieren / erkennen
• Problem dokumentieren / erfassen
• Problem klassifizieren & priorisieren
• Problem untersuchen (Ursachen-Analyse)
  ggf. Workaround dokumentieren
  ggf. Known Error dokumentieren
  ggf. Change anstossen
• Lösung
• Abschluss

Details zur Umsetzung der einzelnen Prozess Schritte in den nächsten Posts dieser Serie!

Bleiben Sie up-to-date und lesen Sie auch die nächsten Folgen! Einfach den Feed abonnieren