Von der ITIL-Theorie zur Praxis, Teil 2
Der Prozess
Bei der Einführung von Prozessen im Unternehmen gilt es zunächst, eine gemeinsame Sprache zu schaffen: Was ist ein Prozess, wie ist er definiert? Auf die Analyse kann dann die Optimierung der Prozesse folgen. Pragmatische Teilschritte ("Quick Wins") können hilfreiche Meilensteine sein.
Eine sorgfältige Analyse ist der erste unabdingbare Schritt bei der Einführung von Prozessen. Hier geht es zunächst darum, die im Unternehmen bereits existenten Prozesse zu verstehen. Hilfreich ist die Herangehensweise mittels Fragen wie: Welche Prozesse habe ich bereits? Wie gut sind sie? Wo fehlen Prozesse? Die Antworten lassen sich gut in eigens dafür angesetzten Workshops erarbeiten (siehe Teil 1 dieser Serie, "Der Faktor Mensch",
www.lanline.de/kn31708487). Dieses Vorgehen ist Usus; interessant wird es oft, wenn Fragen gestellt werden, die vermeintlich längst geklärt scheinen: "Ist in Ihrem Bereich jemals hinterfragt worden, warum man Prozesse einführt?" Fragen dieser Art sollten immer konstruktiv formuliert und niemals als Vorwurf gefasst sein.
Selbst wenn alle Beteiligten fortwährend von Prozessen sprechen, ist keinesfalls gewährleistet, dass die Kernbegriffe tatsächlich hinreichend verstanden sind. Ein eleganter Ausweg aus dieser insbesondere für Führungskräfte oft peinlichen Situation liegt im Angebot einer Zusammenfassung (Executive Summary) für alle Beteiligten. Auch hier eignen sich die folgenden, einleitenden Fragen ideal zur gemeinsamen Erarbeitung der Begrifflichkeiten: Was ist ein Prozess, wie ist er definiert? Wie ist der Begriff Rolle definiert? Wie unterscheidet sich eine Rolle von einer Tätigkeit und von einer Stelle? Was ist ein Workflow? Existieren Definitionen oder Synonyme zu diesem Begriff? Wie unterscheidet sich ein Prozess von einem Workflow?
Ein nicht minder wichtiges Ziel einer solchen Veranstaltung ist die Heranführung an eine gemeinsame Sprache aller Beteiligten. Um dies nachhaltig sicherzustellen, ist es angebracht, die so erarbeiteten Begriffe und Definitionen schriftlich zu fixieren und allen Teilnehmern zeitnah zukommen zu lassen. Diese sollte man darauf verpflichten, die Begriffe in der täglichen Praxis konsistent zu verwenden.
Erst nach erfolgreicher Analyse kann man die Optimierung der Prozesse angehen. Gemeint sind bereits existente wie auch zur Neueinführung vorgesehene Prozesse. Es wäre falscher Ehrgeiz, hier Innovation um jeden Preis zu erzwingen. Denn es kann durchaus angebracht sein - auch in Einklang mit Best-Practice- oder Good-Practice-Methoden - ganze Prozesse davon auszunehmen.
Zweifelsohne ist die Best-Practice-Sammlung ITIL (IT Infrastructure Library) die Referenz. Umso wichtiger ist aber auch hier eine sorgfältige Abwägung. Die Tatsache, dass ein Prozess neu entworfen oder optimiert wird, sagt noch nichts über den tatsächlich entstehenden Aufwand aus. Man muss sich hier zwischen Reengineering, Optimierung oder möglicherweise auch "Nichtstun" entscheiden - wobei das eine nicht mehr oder weniger Aufwand als das andere ist. Im letzteren Fall kann vermehrter Aufwand in den angrenzenden Prozessen entstehen, was jedoch unter den jeweils individuellen Rahmenbedingungen auch eine durchaus tolerable oder anzustrebende Lösung darstellen kann.
Ist die Entwicklung von Prozessen in ausgewählten Bereichen beschlossen, sollte man stets bemüht sein, sich dabei auch am tatsächlichen, zuvor aufgedeckten Bedarf auszurichten. Mittels geeigneter Assessments kommt man diesem Ziel näher. Bezieht man hierbei sowohl IT- als auch Business-Verantwortliche mit ein, fördert man gleichzeitig die notwendige Entwicklung eines gemeinsamen Verständnisses der Materie. Dieses gemeinsame Verständnis ist unabdingbar, um vorhandene Ressourcen im Rahmen der eigenen Möglichkeiten optimal zu nutzen.
Nachdem ein Unternehmen Prozesse identifiziert hat, die es neu einzuführen, zu optimieren, wegzulassen oder gar abzuschaffen gilt, folgt die Umsetzung. Besondere Bedeutung erlangt dabei die Reihenfolge der Einführung von Prozessen. Bei besonders kritischen Prozessen können schnelle, pragmatische Teilrealisierungen - oft als "Quick Wins" bekannt - erste Verbesserungen schaffen, noch bevor man die komplette Umsetzung angeht. Bei dringendem Handlungsbedarf ist dies ein absolut empfehlenswertes Verfahren. Die Anwendung von Quick Wins enthebt jedoch nicht von der Notwendigkeit, den Prozess anschließend gemäß Good-Practice- oder ITIL-Standards anzugehen.
Wie in allen komplexen Systemen sollten Unternehmen auch berücksichtigen, dass Änderungen an einer Stelle nicht ohne Konsequenzen für den Rest des Systems bleiben. So kann es ganz im Sinne einer kontinuierlichen Prozessverbesserung vorteilhaft sein, einzelne Prozesse während ihrer Einführung sukzessive zu entwickeln und nicht gleich in ihrer vollen Reife zum Einsatz zu bringen. Dies klingt zunächst paradox, wird aber für alle Beteiligten verständlich, wenn die allumfassenden Auswirkungen eines Prozesses zum Beispiel in einer Simulation durchgespielt werden.
Besonders gut verdeutlichen lässt sich dies mit der beispielhaften Betrachtung des Incident-Management-Prozesses, der durch die ganze IT greift. So ist fast jeder - besser gesagt, jeder IT-Mitarbeiter in seiner jeweiligen Funktion und/oder Rolle - bewusst oder unbewusst in den Incident-Management-Prozess involviert. Dies zieht sich, angefangen vom First über Second zum Third Level Support, die jeweils mit dem Incident und seinen Folgen befasst sind, über weitere Prozesse (Configuration-, Change- und Release-Management) bis hin zur Ebene des Business-Managements und zu Personenkreisen, die eine von der IT-Sicht losgelöste, rein betriebswirtschaftliche Sichtweise bei der Interpretation der jeweiligen Prozess-Reports anlegen. Bei nicht sorgfältiger Vorbereitung könnte dies zum Ausstieg des Sponsors und damit zum Scheitern der Prozesseinführung beitragen, hervorgerufen durch unvollständige Berücksichtigung der IT-Geschäfts- und Reporting-Prozesse und falscher Interpretation von Kennzahlen.
Besonderes erinnert werden soll hier an den Faktor Mensch. Wie im Teil 1 dieser Reihe beschrieben, sind zusätzlich zu technischen Faktoren bei der Planung und der Umsetzung die betroffenen Mitarbeiter intensiv einzubeziehen. Dies berücksichtigt nicht nur Zeit und Aufwand für Schulung, Umstellung oder Gewöhnung an neue oder veränderte Prozesse. Auch die Durchsetzbarkeit der für richtig befundenen Maßnahmen unterliegt einer gewissen Latenz, die beim Prozessdesign und der anschließenden Umsetzung gern unterschätzt wird. Ebenfalls gern übersehen wird die Tatsache, dass akribische Dokumentation oft mit Ignoranz und allen damit verbundenen Konsequenzen belohnt wird. Zweifelsohne müssen schriftliche Dokumentation erstellt werden. Jedoch ist zu beachten, dass je nach Rolle und Funktion auch die Dokumentation in Inhalt und Umfang unbedingt angemessen sein muss. Hier bedeutet weniger Umfang oft mehr Umsetzungswahrscheinlichkeit: Service Level Agreements mit einem Umfang von 100 Seiten sind für die meisten Prozessbeteiligten nicht zu bewältigen und erst recht nicht zu befolgen.
Prozessreife kann und sollte man auch nach außen signalisieren. Oft erreicht man damit sogar ein besonderes Alleinstellungsmerkmal gegenüber seinen Mitbewerbern. Wie weit sollte man hier gehen? Die Antwort erhält man mittels ISO 20.000, denn dieser Standard liefert eine gut überschaubare Richtlinie für das Erreichen und Messen eines definierten Prozessreifegrads.
Dies sollte jedoch nicht zu der Annahme verleiten, man könnte mit ISO 20.000 allein die Prozesseinführung nach ITIL ersetzen. Eine nach außen verifizierte und dokumentierte Zertifizierung muss noch lange nicht heißen, dass die Prozesse die Anforderungen des Unternehmens tatsächlich erfüllen oder die IT wirklich hinreichend performant ist. Folgende Analogie verdeutlicht das: Einem Auto, das nach bestandener Prüfung die TÜV-Plakette erhält, wird die Konformität gemäß genau definierter Sicherheitsanforderungen bescheinigt. Damit ist jedoch keinesfalls gesagt, dass es sich auch um ein "gutes" Auto handelt: Zuverlässigkeit, Robustheit und Performance, aber auch Komfort und Status werden maßgeblich durch andere Parameter bestimmt. Ein Unternehmen kann streng genommen dem Standard ISO 20.000 genügen und eine gute Prozessreife aufweisen, ohne dass ITIL zur Anwendung kommen muss. Für ein Unternehmen ist dies nicht problematisch - ein Auto ohne TÜV-Plakette hingegen lässt sich nur schwer verkaufen.
Lesen Sie mehr zum Thema
