Will der CIO die Kundenzufriedenheit und die Produktivität erhöhen, so spielt in den Service-Support-Prozessen die Musik. Hier liegen die größten Reserven, denn es handelt sich um Basisfunktionen der IT-Organisation, auf die alle Services zugreifen. In Einzelfällen haben sowohl Funktionsanalysen als auch Prozessmetriken gezeigt, dass im Incident- und Change-Management bis zu 30 Prozent der produktiven IT-Mitarbeiter (intern und extern) gebunden sind. Hier gibt es also ungeahnte Möglichkeiten für eine Produktionssteigerung.

Im Service-Support sollte der Reifegrad folgender Prozesse verbessert werden:

• Incident-Management,

• Problem-Management,

• Change-Management,

• Release-Management und

• Konfigurations-Management.

Im Tagesgeschäft tritt der Kunde vor allem dadurch an die IT heran, dass er Störungen meldet oder Änderungswünsche äußert. Hier erlebt er hautnah die IT, deren Kompetenz, Kundenorientierung, Geschäftsverständnis, Kommunikationsstärke und Glaubwürdigkeit. Also muss der Hebel für mehr Anwenderzufriedenheit hier angesetzt werden. Wie das geht, zeigen die folgenden Beispiele.

1. Wenn der First-Level-Support nicht funktioniert

Der erste Fall betraf eine schlechte Kundenbewertung der Kompetenz im Helpdesk. Die möglichen Ursachen dafür spannen sich von der mangelhaften Führung des Helpdesk und seiner Ziele über eine unzureichende Qualifikation der Mitarbeiter bis zum Fehlen von geeigneten Werkzeugen und Informationen spannen.

Um die tatsächlichen Ursachen zu erkennen und an der Wurzel zu packen, sollten sich eigentlich Einzelfälle entlang der Prozesskette zurückverfolgen lassen. Aber leider war nur der Itil-Standardprozess Incident-Management adaptiert und eingeführt worden. Was fehlte, war die aussagenorientierte Vermessung seiner Performance entlang der "Sipoc"-Kette (Supplier, Input, Process, Output, Customer).

Weil eine übergeordnete, integrative Sicht in Form eines Prozess-Management-Systems fehlte (mehr dazu im ersten Teil dieser dreiteiligen Serie), gestaltete sich auch die Diskussion zwischen Helpdesk-Personal und Second-Level-Support schwierig. Die Schnittstellen zwischen Incident- und Problem-Management waren nicht klar geregelt sowie auf unterschiedlichem Detaillierungsgrad beschrieben. Nicht einmal die Dokumentationsform und die Prozesssyntax waren einheitlich. Lediglich das Werkzeug für die Dokumentation hatte man prozessübergreifend bestimmt.

Unterversorgte Know-Error-Datenbank

Durch einen sauber vermessenen Problem-Management-Prozess mit Messwerten entlang der Sipoc-Kette ließ sich die Problemursache aufdecken: Problem-Tickets wurden zwar eröffnet, jedoch nicht zur Analyse und Lösung in die Error-Phase weitergeleitet. Damit blieb die Known-Error-Datenbank unterversorgt, und der Helpdesk hatte zu viel Distanz zu den aktuellen Problemen im Servicebetrieb.

Der Ticket-Stau war offenbar durch fehlerhafte Ressourcenzuordnung ausgelöst, konnte also durch eine Neuzuordnung von Personal aufgelöst werden. Darüber hinaus erhielten die beteiligten Mitarbeiter die Anweisung zur tagesaktuellen Pflege der Known-Error-Datenbank.

Mit einer aussagefähigen und gut gefüllten Datenbank ließen sich dann oft schon bei der Annahme der Incidents die passenden Lösungen anbieten. Mit der First Call Solution Rate stieg die Kundenzufriedenheit, und die Support-Kosten sanken, weil der Incident häufiger im kostengünstigen First-Level-Support gelöst wurde.

2. Wenn eine Störung falsch klassifiziert wird

Ein ähnlicher Fall trat in einer anderen IT-Organisation auf: Im Helpdesk galten Passwort-Resets für den SAP-Service als gelöste Störungen. Das aber war ein Missverständnis in Bezug auf die Itil-Best-Practices, denn das Wiederherstellen eines Passworts behebt keine Störung, sondern erfolgt aufgrund eines Service-Request.

Die Klassifizierung als Störung hatte fatale Folgen: für den Aussagewert von Key-Performance-Indikatoren zur vertraglich zugesicherten SLA-Erfüllung, aber auch für die Prozess-Performance. Weil dieser Service so häufig angefordert wurde, konnten störungsrelevante Geschäftsvorfälle häufig nicht im First-Level-Support bearbeitet werden, sondern wurden an den wesentlich teureren Second-Level-Support verwiesen. Tritt eine Störung wiederholt auf, so kann jedoch eine gut gepflegte Known-Error-Datenbank den First-Level-Support in die Lage versetzen, das Problem direkt zu lösen, anstatt es immer wieder an den Second-Level-Support weiterzuleiten.

In diesem Fall war im unterstützenden Helpdesk-Tool bereits eine differenzierende Check-Box für die Ticket-Annahme vorgesehen. So ließ sich der Fall zügig quantifizieren. Etwa jedes fünfte Ticket bezog sich auf eine wiederkehrende Störung, aber in der Known-Error-Datenbank gab es keinen einzigen Eintrag für SAP-Services.

Wenige Problem-Tickets erreichten die Error-Phase

Anhand von Metriken, die den Bearbeitungsfortschritt eines Tickets betreffen, ließ sich feststellen, dass im Problem-Mangement nur wenige Tickets die Error-Phase nach Itil erreichten. Zwar wurde bei Vorliegen einer unbekannten Störung prozesskonform ein Problem-Ticket eröffnet, aber nach der Problemanalyse weder ein Workaround erarbeitet noch ein Change-Request gestellt. Mit anderen Worten: Die Störanfälligkeit der Services blieb hoch. Anstatt sich mit der Lösung bekannter Serviceprobleme zu beschäftigen, arbeitete das Team lieber an Neuentwicklungen. Auch hier ließ sich die Fehlentwicklung durch Neuzuordnung von Ressourcen lösen.

Potenziell können auch für einen SAP-Support-Service 15 bis 20 häufig wiederkehrende Störungen oder Probleme direkt im First Level gelöst werden. So lassen sich Doppelarbeit vermeiden, günstigere Ressourcen verwenden und aus Kunden motivierte Partner der IT machen.

3. Wenn das Change-Management keines ist

Ein drittes Fallbeispiel, das den Nutzen einer übergreifenden Prozesssicht belegen soll, drehte sich um das Change-Management. In einem internationalen Unternehmen wurde der über alle Länder Europas standardisierte SAP-Service innerhalb von nur drei Jahren wieder landesspezifisch verwässert. Die daraus resultierende Komplexität führte zu Budgetüberschreitungen für Changes und zu einer ansteigenden Fehlerquote. Die Termintreue bezüglich der zugesagten Verfügbarkeiten von Änderungen im Produktivsystem war zu schwach, die Kunden fühlten sich schlecht bis gar nicht informiert.

Diese Situation verweist auf eine schwache Governance, einen mangelhaft eingeführten Itil-Prozess sowie das Fehlen von verbindlich geregelten Rollen und Verantwortlichkeiten. Zudem wird hier die integrative Sicht auf den Change-Management- und den Release-Management-Prozess schmerzlich vermisst.

Die Change-Governance sollte eine saubere Kategorisierung von Change-Requests sowie deren konforme Erfassung im Prozess vorantreiben. Nur so lässt sich die Wurzel des strategischen Problems schnell ausfindig machen. In diesem Fall waren trotz zentralisierter IT und eines aus strategischen Gründen gewollten Standards rund 75 Prozent aller Change Requests (CRs) landesspezifisch. Durch eine Adaption der Verrechnungs- und Budgetrichtlinien ließ sich der Trend umkehren.

Es gab mehr Incident- als Problem-Tickets

Anhand des Inputs zum Change-Prozess wurde dann die Herkunft der CRs gemessen. Es gab mehr Incident-Tickets, die einen Change Request auslösten, als Problem-Tickets. Nach Itil kann aber berechtigterweise nur ein Problem-Ticket einen CR aus dem Service-Support in Gang setzen. Im Klartext heißt das: Man änderte mal schnell den Quellcode, um Störungen zu beseitigen, ohne zuvor das Problem systematisch untersucht und dokumentiert zu haben. Dieses Vorgehen aber sollte höchstens erlaubt sein, um wohlbekannte und fest definierte "Standard-Changes" effizienter zu machen.

Nach der Korrektur dieses Prozessfehlers und Behebung der damit einhergehenden Ineffizienzen konnte sich das Team auf weitere Schwächen im Change-Prozess konzentrieren. Zunächst wurde die Anzahl der Change Requests verringert. Dann ging es darum, die Termintreue zu verbessern.

Im Fokus des Prozessteam stand nun die Planungsqualität des Forward Schedule of Change (FSC). Anhand von Stichproben wurde klar: Der offiziell kommunizierte Plan, nach dem die Change Requests abgearbeitete wurden, war allenfalls ein "Best Guess". Der Versuch, Zuverlässigkeit und Ressourceneffizienz unter einen Hut zu bringen, wurde durch fehlende Prozessdisziplin, nicht implementierte Richtlinien, fehlende Governance und einen eingeschränkten Blick auf die Schnittstelle zum Release-Management zunichtegemacht.

Beispielsweise wurden "Emergency Changes", eigentlich für existentielle Geschäftsprobleme gedacht, missbraucht, um Änderungen zu beschleunigen. Das selbstverständlich in der Überzeugung, kundenorientiert zu agieren, wobei in Wahrheit die Zuverlässigkeit und Professionalität der IT beim Kunden in Misskredit gebracht wurde. Zudem gab es Transporte außerhalb des Release-Kalenders. Eine Änderung des FSC wurde den Antragstellern nicht zeitnah mitgeteilt - geschweige denn zuvor mit ihnen abgestimmt. Durch eine ganzheitliche Betrachtung der Change-Management-Prozesse veränderten sich die kritischen Werte positiv.

4. Wenn mangelhafter Service für Ärger sorgt

Der letzte Fall vereint Probleme mit der Servicestabilität, sinkende Kundenzufriedenheit wegen mangelhafter Zuverlässigkeit und hohen Change-/Release-Aufwand. Das alles ging einher mit einer unklaren Situation im Produktivsystem hinsichtlich Problembehandlung und Eskalation.

Wie die zu aussagefähigen Messwerten entlang der Sipoc-Kette im Release-Management konsolidierten Betriebsdaten zeigten, durften zu viele autorisierte Mitarbeiter SAP-Releases transportieren. Die Entwicklung arbeitete nicht im Einklang mit dem offiziellen FSC. Das Verhältnis von geplanten Change Requests für einen Release im Vergleich zu den tatsächlich transportierten CRs war wegen häufiger Repriorisierungen nur noch halb so groß wie der aktuelle Zielwert. Die anderen zugesagten CRs wurden häufig verschoben. Die Konsequenz war eine sinkende Glaubwürdigkeit beim Kunden. Ein systematisches Prozess-Management schaffte Abhilfe.