Das Problem mit dem Problem!
Problem-Management findet jeder gut - trotzdem funktioniert es in nur wenigen IT-Abteilungen. Warum das so ist und wie es funktionieren kann, mag ich Dir heute erzählen.
Du kennst die Situation bestimmt: Du triffst auf einer Konferenz oder Barcamp Menschen, die sich mit IT-Service-Management beschäftigen. Ihr kommt ins Gespräch und irgendwann fragt einer der Gesprächspartner: „Welche Prozesse habt Ihr implementiert?“ Der Andere antwortet meist wie aus der Pistole geschossen: „Incident, Problem und Change.“ „Echt?“, fragt der erste überrascht, „funktioniert bei Euch Problem-Management wirklich?“ – Darauf folgt meist eine Antwort in Richtung „Naja, auf dem Papier schon, aber so richtig gelebt wird es nicht.“
Kennst Du, oder?
Ich habe das Gefühl, dass es sich beim Problem-Management ähnlich verhält wie beim Holzfäller, der in den Wald geht und keine Zeit hat, seine Axt zu schärfen.
Im Buch „Perspektivwechsel im IT-Service-Management“ hat es Simon Kahnert mit seiner Geschichte „Das Gleichnis der Hühner oder Problem Management, eine Odyssee“ perfekt getroffen. Die Geschichte habe ich Dir im Blog verlinkt, sie gibt es als Leseprobe. Kurz zusammengefasst, geht die Geschichte so:
Die Krieger im alten Griechenland sind damit beschäftigt Hühner einzufangen, die immer wieder durch Löcher im Zaun ausreisen. Das beschäftigt die Krieger so, dass sie keine Zeit für Verteidigung und Angriff haben. Der hohe Rat nimmt das als gegeben hin, denn es ist die Natur der Hühner. Nur einer hat die Idee, dass man lieber nach den Löchern im Zaun suchen sollte. Alle sind skeptisch und können dennoch überzeugt werden.
Was in der Geschichte gut ausgeht, ist in der Wirklichkeit viel schwerer. Wobei, jeder zustimmt, dass Problem-Management sinnvoll ist. Nur hilft das leider nicht.
Problem-Management, wie es sein soll
Lass uns mal kurz auf die Theorie schauen: Das Ziel des Problemmanagements ist das Finden der Ursache von einer oder mehrerer Störungen, die Beseitigung dieser Ursache oder Entwicklung eines Workarounds sowie das Vermeiden von Störungen. Problem-Management hat eine reaktive und eine proaktive Komponente.
Klingt soweit gut, oder?
Jetzt treffen in der Realität zwei Dinge ein:
- Es wird ein ausgefeilter Problem-Management-Prozess definiert, ein Problem-Manager ernannt, Probleme identifiziert …. dann passiert lange Zeit nichts
- Die IT-Service-Feuerwehr (also Service-Desk und Incident-Management) wirft bei jeder Störung alles in die Bresche, damit auch gleich die Ursache der Störung beseitigt wird. Dass die Störungsbearbeitung dadurch länger dauert und der Nutzer nicht oder eingeschränkt arbeiten kann, ist dabei zweitrangig.
Das Ziel des Incident-Managements ist die schnellstmögliche Wiederherstellung des vereinbarten Service. Auch wenn es uns schwer fällt, wir dürfen wirklich unterscheiden zwischen Arbeitsfähigkeit wiederherstellen und dem Finden sowie Beseitigen der Ursache. Das ist eine der schwierigsten Aufgabe für Führungskräfte, wenn Du mich fragst. Ich zumindest habe dafür immer mehrere Anläufe benötigt.
Die Sensibilisierung darauf, was in der jeweiligen Situation wichtig ist, was dem Kunden am meisten nutzt, das ist ganz wichtig.
Wahrscheinlich wirst Du dann auch das Argument hören, dass der Problem-Management-Prozess nicht funktioniert. So ein verkopfter und regulierter Prozess kann auch gar nicht funktionieren, wenn Du mich fragst.
Am Anfang werden die Problemkandidaten noch brav markiert und der Problem-Manager macht auch brav seine Analysen. Dann steht er nach den ersten zwei Monaten vor einem sprichwörtlichen Berg von Problemen. Den kann er natürlich nur mit einem eigenen Team abarbeiten, die sich nur um das Problem-Management kümmern. Damit ist der Prozess dann meist gestorben, weil zu aufwändig und eigentlich nur was für große Organisationen, die sich das leisten können.
pragmatisches Problem-Management
Wir dürfen uns dem Punkt anders nähern: Wer hat denn ein Interesse daran, dass Probleme beseitigt oder vermieden werden? Ich meine wirkliches Interesse, weil ihm dadurch das Leben erleichtert wird. Das ist der Service-Owner. Der Service-Owner ist Ende-zu-Ende verantwortlich für seinen Service.
Je weniger Störungen das Team zu bearbeiten hat, umso mehr kann es an der Weiterentwicklung des Service arbeiten oder den Service optimieren. Ein funktionierendes Problem-Management schlägt sich also direkt beim Service-Owner und dem Service-Team nieder.
Genau an der Stelle kannst Du ansetzen: Ich würde kein zentrales Problem-Management etablieren. Wenn Du das Problem-Management als Verantwortung für den Service-Owner definierst, dann ist es aus meiner Sicht genau an der richtigen Stellen.
Nun steht der Service-Owner vor einem kleineren Berg der sprichwörtlichen Probleme. Wenn Du den tollen Problem-Management-Prozess jetzt nicht wegwirfst, dann wird sich an der Situation nichts verbessern.
Was Du brauchst sind ein paar Regeln und Routinen. Mit den Regeln meine ich das Mindestmaß an Aktivitäten im Problem-Management, was jedes Team durchführen muss. Folgendes kann ich mir dazu vorstellen:
- mögliche Probleme müssen auf Basis der Incidents und Monitoringdaten identifiziert werden
- Probleme, die bearbeitet werden, sind im Tool XYZ zu registrieren
- Bekannte Fehler und Workarounds werden über die Knowledge-Base dem Support und dem Nutzer zur Verfügung gestellt
Um jetzt mal drei zu nennen.
Routinen schaffen
Wichtig finde ich die Routinen: Als Service-Owner schaffst Du Dir Gewohnheiten, die es Dir erleichtern, echtes Problemmanagement zu betreiben. Wäre ich Service-Owner, würde ich das wie folgt gestalten:
Ich würde einmal pro Woche mir die Tickets anschauen und diejenigen identifizieren, die ich für problematisch halte. Das sind Störungen die häufiger auftreten, eine große Auswirkung hatten oder nach längerer Zeit mal wieder für Unruhe sorgen. Diese Problemkandidaten kann ich dann in der nächsten Woche verifizieren, ob sie sich weiter auffällig zeigen oder nicht.
Dann würde ich einmal pro Monat mit meinem Team die Liste der Problemkandidaten durchgehen. Das Ziel ist, dass das Team mindestens ein Problem in die aktive Bearbeitung nimmt. Ich würde zusätzlich eine Höchstgrenze setzen – also maximal drei in meinem Fall.
Hier ist es ganz wichtig, dass die Zahlen realistisch sind. Also Dein Team wirklich, wirklich die Chance hat, die Probleme zu analysieren und zu beseitigen. Weniger ist hier wirklich mehr. Du und Dein Team brauchen Erfolgserlebnisse. Ihr müsst am eigenen Leib erfahren, dass Problem-Management funktioniert. Mit diesem positiven Feedback, läuft die Routine bald von selbst und das ist das Ziel!
Nach dem Meeting bleibt eine Liste von Problemkandidaten übrig. Die würde ich entweder ganz wegwerfen oder auf maximal ein oder zwei eingrenzen. Sonst wächst sie wieder zu diesem problematischen Berg von Problemen. Eines ist sicher: nächsten Monat gibt es wieder Probleme.
Wir brauchen nicht den Anspruch, dass wir jedes Problem lösen. Es bringt viel mehr, wenn einzelne Probleme wirklich gelöst werden!
Wenn das funktioniert, würde ich in meine monatliche Routine zusätzlich das proaktive Problem-Management einbinden. Also auf Basis der vorhandenen Daten schauen, wo sich ggf. Probleme zusammenbrauen können.
Auch bei uns in der IT gilt der alte Spruche „Vorbeugen ist besser als heilen“. Ich würde ich auch mindestens einen dieser Problemkandidaten in die Bearbeitung mit einbeziehen. Damit bist Du dann bei zwei und wenn Du die regelmäßig erfolgreich abarbeitest, dann hast Du viel mehr gekonnt, als mit einem zentralen, ausgefeilten Problem-Management. Denn die anderen Service-Teams machen das genauso.
Die Zahlen und das Vorgehen skalieren – wenn Du mehr Personal hast, kannst Du auch mehr Probleme bearbeiten. Doch Vorsicht: das kann eine falsche Annahme sein! Es lohnt sich hier auf jeden Fall zu messen. Wie hoch ist die Durchlaufzeit, wo gibt es Bootlenecks. Das könnte ein wunderbarer Anwendungsfall für ein Kanban-Board sein.
Was hältst Du von der pragmatischen Idee für das Problem-Management? Ich freue mich auf Deine Mails und Kommentare! Bin gespannt, welche Erfahrung Du gemacht hast. Berichte bitte auch gern, wie Problem-Management bei Dir funktioniert.
