“Aber wir müssen doch erst unsere Probleme in den Griff kriegen…“ antwortete der IT-Leiter dem Berater auf die Empfehlung, den geschäftlichen Nutzen mehr in Betracht zu ziehen.

Der IT-Leiter hatte nichts gegen den Vorschlag. Aber er spürte offensichtlich einen Konflikt zwischen der Problemlösung und einer Nutzen-Orientierung, wie die Redewendung „Aber...erst“ andeutet. Eine Priorisierung im Hinblick auf den geschäftlichen Nutzen schien nicht pragmatisch genug. Die Probleme sollten erst gelöst werden.

Wieso eigentlich? Können wir diese zwei wertvollen Ziele nicht in Einklang bringen?

Diese Szene bildet ein reales Kundengespräch ab, in dem praktische ITIL-Ansätze für die Organisation gesucht werden sollen. Was sind die eigentlichen Probleme? Wenig SLAs, wenig Monitoring von SLA-relevanten Werten, Überlastung der Entstörungsteams, keine strukturierte Lieferantensteuerung, keine unterstützenden OLAs, starke Kopfmonopole und ein mangelhaftes Trouble-Ticket-Tool. Obwohl das Change Management sauber strukturiert ist, führen viele Störungsmeldungen zu Changes, was auf eine fehlende Abgrenzung zwischen Incident und Problem Management hindeutet. Der Problemkatalog ist in der Summe typisch für eine Organisation, die ihre aktuell hohe Kundenzufriedenheit nur durch heldenhafte Taten schafft.

Die Betonung auf Problemen deutet auf eine Überlastung von Mitarbeitern und Manager hin. Um jedoch über Nutzen nachzudenken, muss man erst den Puls wieder herunter fahren. „Helden“ tun dies aber nicht, sie geben immer Vollgas. Wie lange würde diese Situation noch gut gehen? Das war der Anlass für die Beratung.

Warum nicht einfach die Probleme lösen? Das führt doch zu einem Nutzen, oder? Durch eine Root-Cause Analyse /1/ werden ebenfalls methodisch die Kernprobleme identifiziert. Schafft man diese aus der Welt, erreicht man viel.

Analysieren wir allerdings die Probleme der IT-Organisation, bleibt unser Fokus auf der internen Sicht zu Ungunsten des Geschäftsbedarfs der Kunden. Bilden die Lösungen den sinnvollsten Einsatz der Ressourcen ab? Ist die Behebung dieses Problems überhaupt geschäftsrelevant? Vor allem, wie kann ich entscheiden, welche Probleme als erste gelöst werden sollen?

Einfach ausgedrückt: die Nutzenanalyse liefert mir eine Priorisierung in der Problembehebung, die ebenso zukunftsorientiert ist. Ich lösche nicht nur Feuer, sondern ich baue weiter an meinem Haus. Eine Problemanalyse allein hilft mir zwar, das Feuer methodisch zu löschen, aber es bleibt nur beim „Feuerlöschen“.

Es besteht kein Konflikt zwischen Problemlösung und einer Priorisierung nach Nutzen. Das Zusammenbringen der beiden Ansätze ist einfacher als man denkt:

1. Die Probleme auflisten, clustern und ihre Auswirkung einschätzen.
2. Die konkreten Änderungen identifizieren, welche die Probleme lösen können.
3. Den Nutzen im Hinblick auf die strategischen Ziele des Unternehmens identifizieren.
4. Die Änderungen identifizieren, welche diesen Nutzen herbeiführen können.
5. Die Nutzenaspekte und die Änderungen priorisieren.
6. Die konkreten Änderungen aus Punkt 2 und 4 übereinanderlegen. Wo eine Problemlösung keinen Nutzen ergibt, muss man überlegen, ob wirklich ein Problem besteht.

Fazit: Priorisierung durch ein nutzenorientiertes Vorgehen ist immer ein Gewinn!

Wir stehen alle unter Zeit und Ressourcendruck und pragmatisches Problemlösen liefert das Gefühl, etwas Wichtiges geschafft zu haben. Aber es lohnt sich, das Tempo heraus zu nehmen, um den strategischen Blick auf die Zukunft zu richten. Nur mit einer konkreten Vorstellung der nutzenorientierten Ziele kann ich beurteilen, wie ich die Probleme priorisieren soll.

—James Mitchell Lee

30. April 2012

Quellen:

/1/ Es gibt einige Varianten der Root Cause Analysis. Am praxistauglichsten finde ich: Gano, Dean. Apollo Root Cause Analysis: A New Way of Thinking. Apollonian Publications, 1999.

/2/ Ward, John & Daniels, Elizabeth. Benefits Management: Delivering Value from IS and IT Investments. Wiley, 2006.