Prozesse ohne Leute – Die Hoffnung stirbt zuletzt

Vor Urzeiten habe ich mal bei einer Unix-Firma, die mit dem schönen Logo, angefangen. Bei Konsolidierungsprojekten in denen Windows-Infrastruktur gegen Unix ausgetauscht wurde, galt immer die goldene Regel: Seht zu dass ihr für die alten Administratoren andere Jobs besorgt zum Beispiel im Client-Umfeld. Denn es braucht viel Zeit sich auf andere Herangehensweise, andere Architektur zu gewöhnen und nur allzu leicht gewinnt die „Früher war alles besser“-Fraktion die Oberhand. Dem freundlichen Leser sei es freigestellt für die Platzhalter „Windows“ und „Unix“ zu tauschen oder beliebige andere Dinge einzusetzen, die vom Konzept her unterschiedlich sind und schon hat man eine allgemein gültige Regel.

So ist es nicht weiter erstaunlich, dass diese Regel auch bei „historische Anläufe in der IT“ hin zu „an ITIL® orientierte Vorgehenweisen“ gilt. Das daran wirklich Erstaunliche ist, dass es Personen gibt die aus irgendeinem Grund glauben, dass so etwas funktionieren kann. Nehmen wir als Beispiel einen Bereich in der IT, der laut Benchmark zu fett aufgestellt ist, de facto aber eine Menge Überstunden und gerade so ausreichende Qualität liefert. Das Beispiel ist nicht aus der Luft gegriffen, solche Konstellation finden sich in lange etablierten internen IT Organisationen, in denen verschiedene Kunden Sonderbedingungen ausgehandelt haben. Diese ganzen Eigenheiten haben sich zu einem komplexen Geflecht verwickelt, müssen manuell bedient werden und fressen eine Menge Ressourcen. Aus Unternehmenssicht meist ohne tieferen Sinn.

Eine solche Konstellation ist eigentlich perfekt, um alles in Richtung ITIL zu standardisieren. Es könnten einheitliche OLAs verhandelt werden und Sonderlocken nur noch gegen Sonderzahlungen durchgeführt werden. Ein Change Management würde Änderungen bündeln und priorisieren. Der vormals zu fette Bereich würde nach der Standardisierung Wichtiges von Unwichtigem aus Unternehmenssicht trennen können, würde Änderunegn richtig bewerten, d.h. absprechen und ordentlich kommunizieren. So etwas kann funktionieren und am Ende sogar Geld sparen.

Allzu oft trifft man aber eine Situation an, in der das alte Team nahezu alleine gelassen wird. Ein Berater erklärt ihnen in drei Sitzungen ITIL und vielleicht sogar absolut korrekt die dazu notwendigen Änderungen. In der kurzen Zeit verstehen sie aber nur: „Man will uns ans Leder – Der Berater versteht doch gar nichts von unseren internen Abläufen – Ach du Scheibe, jetzt kommt auch noch Bürokratie“. Je nach Vorgehensweise des eigenen Managements kommt nach anfänglichem Abwehrgefechten des Teams in denen das Management vor allem „Früher war alles besser“ raushört ein Basta, das heißt hoher Druck und Personalkürzungen.

Die Reaktion des alten Team, dass den Sinn von ITIL und Good Practice nicht versteht, wird nun ein sinnfreies Vorgaukeln eines Prozessablaufs sein. In Wahrheit machen sie ihren alten Job. Nur viel schlechter, weil mit weniger Ressourcen und nun auch diese extra „Prozess“-Bürokratie. Absurd wird das Ganze, wenn diese „ITIL Einführung“ mit einem hohen 6-stelligem Betrag designed wird, jedoch zur Umsetzung fast kein Budget mehr vorhanden ist und man deshalb der Einfachheit halber auf die alten Teams setzt und denen im Prinzip nur etwas zum Lesen gibt.

Ich frage mich dann immer, was in den Leuten vorgeht, die ein Service Management Projekt so voranbringen wollen. Das ist im Wesentlichen nichts anderes, als obige Windows-Administratoren mal kurz auf eine Unix-Schulung zu schicken. Beim nächsten Problem stehen die Jungs auf dem Schlauch. Die Brücke von Problem zur Lösung können diese Jungs in ihrer vertrauten Welt geradezu ohne Nachdenken schlagen, mit der neuen Technologie finden sie alles schwer und unlösbar. Warum man dieses blöde Unix will versteht keiner. (Selbstverständlich gilt das auch für Unix-Adminstratoren die auf Windows umsatteln müssen).

Ganz genauso gilt das auch für Betriebsabläufe: Die historisch gewachsenen Prozesse sind vertraut, in einer ITIL-Welt kennt man die erlaubten Vorgehensweisen nicht und tut sich schwer.

Woran das liegt lässt sich am Beispiel eines neuen Mitarbeiters gut beobachten: An seinem ersten Arbeitstag wird der neue Mitarbeiter den bestehenden Ablauf als Komplex, Verworren und Verbesserungsbedürftig empfinden. Nach einem halben Jahr kommt er ganz gut mit dem Chaos zurecht und wird es gar nicht mehr als besonders Kompliziert empfinden. Nach einem Jahr wird er schon so in den Abläufen aufgegangen sein, dass er seine anfänglichen Verbesserungsvorschläge nun alle als zu einfach einstuft, da diese die ganzen Sonderregeln der Kunden gar nicht berücksichtigen.

Das heißt, es wird in bestehenden Strukturen nur wenige Personen geben, die diese sinnvoll abstrahieren und dann noch auf ein neues System abbilden können. Genau diese Personen muss man nutzen und mit ITIL erfahrenen Mitarbeitern oder Beratern zu kommunizieren. Und zwar genau so lange bis für 80% der auftretenden Probleme Alternativen gefunden wurden. Diese Alternativen kommen jedoch von den Experten des neuen Systems. Ein Windows-Administrator wird keine Unix-Lösung entwickeln können. Wenn die Architekten des alten Systems die neue Lösung bauen, bekommt man das Schlimmste beider Welten, nämlich ein Konzept der alten Welt, das mit viel hämmern und basteln auf die neue Welt angewandt wird.

Also liebe Hüter des Budgets, wenn kein Budget mehr für die Umsetzung vorhanden ist, wartet bitte das nächste Geschäftsjahr ab, bevor ihr es dem alten Team aufdrückt und auf ein Wunder hofft.

Die zu Anfang genannte Regel ist im Allgemeinen nicht kommutativ. Personen die mit höher Strukturiertem umgehen können, kommen auch prima mit einfach Strukturiertem klar. Ein durchaus auftretender Fall nach einer Unternehmensakquise. Ist das einfach strukturierte Etwas dann die Hauptbeschäftigung der Personen, so wird man einen Anstieg der Fluktuation messen können 🙂

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Dein Kommentar wird manuell freigeschaltet. Ich bitte um Geduld, das kann manchmal etwas dauern.