Bürokratie und Regeln weg, oder?

Im Moment hört man oft, dass Bürokratie abgebaut werden muss. Das ist grundsätzlich eine gute Idee. In einem Interview hörte ich jedoch einen Unternehmer, der das Kind mit dem Bade ausschüttete. Er forderte, dass viele Regeln, die seiner Ansicht von Politikern und der EU erfunden wurden, abgeschafft werden sollten, um endlich vernünftig arbeiten zu können. Dabei waren auch wichtige Regeln, die meines Erachtens keine Bürokratie machen, aber eins nach dem anderen.

Ich finde es tatsächlich wichtig, Regeln durch Gesetze oder interne Richtlinien zu haben. Ich wünsche nicht, dass Hotels meine Daten beliebig lange speichern oder dass Unternehmen, die besonders lax mit IT-Sicherheit umgehen, ungeschoren davonkommen, wenn sie meine Daten durch einen Ransomware-Angriff verlieren. Es ist auch für die Wirtschaft schädlich, wenn wir an diesen Stellen keine Basis für Sicherheit haben.

Allerdings ist es entscheidend, dass überall dort, wo Vorschriften Aufwand verursachen, dieser so gering wie möglich gehalten wird. Im Zweifelsfall sollte auf eine Datenerhebung verzichtet werden. Prozesse müssen auf Verschwendung untersucht und das, was übrig bleibt, automatisiert werden. Auch Regeln müssen alle paar Jahre auf ihren Wert überprüft werden. Vielleicht haben andere Regeln die Situation verändert. Auch hier gilt: Im Zweifelsfall die Regelung wegwerfen.

In Unternehmen, aber auch in der öffentlichen Verwaltung wünsche ich mir Pragmatismus, es muss eine Instanz geben, die eine Regel interpretieren und ändern kann. Ich erinnere mich an ein Beispiel vor Jahren, als ich für einen Teil des IT-Betriebs verantwortlich war. Es gab einen Major Incident und wir brauchten wirklich alle Kräfte „Alle Hände an Deck“.

Endlich kam ein externer Techniker für eine Reparatur zum Rechenzentrum und ein Mitarbeiter aus dem Support fragte mich, wen wir jetzt abziehen und mit dem Techniker ins Rechenzentrum gehen lassen. Die von mir vorgeschlagene Auszubildende, die seit 3 Monaten eingestellt war, durfte laut Reglement nicht mitgehen. Meiner Meinung nach, weil so etwas einfach nicht vorgesehen war und die Formulierung im Regelwerk unglücklich war.

Wir haben die Auszubildende gebrieft und sie diese Aufgabe übernehmen lassen. Ich habe die IT-Leitung schriftlich informiert und ein paar Wochen später haben wir das Regelwerk angepasst. Das meine ich mit pragmatisch. Verstehen, was mit der Regel gemeint war und mutig einen Umweg gehen. Regeln haben einen Sinn, sie müssen einfach sein, gelebt und angepasst werden.

Katze und Regeln
Katze und Regeln

IT Service Management ist Rückständig

Manche für IT Service Management beratende Firmen nerven der immer wiederkehrenden Botschaft, wie Rückständig IT Management doch sei. Es mag mich besonders nerven, weil ich genau das Gegenteil glaube. Genauer, ich glaube dass Firmen in den Dingen, die sie produzieren meist ganz gut sind und unterstützende Prozesse seltener im Fokus von Optimierungen stehen.

Ich finde es deshalb sehr interessant im Alltagsleben Prozesse und Abläufe zu beobachten und zu vergleichen bzw. festzustellen, dass es dort nichts gibt. Schön war letztes Jahr eine Baustelle mit Vollsperrung einer Verbindungsstraße, gleichzeitig wurde die Gelegenheit genutzt eine Schienenstrecke zu renovieren, so dass auch der Schienenersatzverkehr durch die verstopfte Umleitung musste. Wäre das ein IT Verbund würden alle fehlendes Change Management bejammern.

Auch spannend ist seinen Alltag mal nach Service Level Targets zu hinterfragen. In welchem Zeitrahmen bekommt man eine Rückmeldung zu seinem Anliegen bei Behörden, Firmen oder Vereinen. Gemeint ist ein garantierter Rahmen in dem auch Vertragsstrafen akzeptiert würden. Da wird es meist dünn, übrig bleiben einige Franchise Restaurantketten bei denen der Burger in 10 min auf dem Tisch steht und sonst Geld zurück angeboten wird.

Beim IT Service Management gilt der Dreisprung Incident-Problem-Change in etwa als Anfang beziehungsweise als unterste Ebene bei der man noch von Professionalität sprechen darf. Ein ITSM Tool (Ticket Tool) und Service Desk als Single Point of Contact mit einer koordinierten, schriftlich aufgezeichneten Historie von Störungen, Bestellungen, Ursachen und Änderungen. Ein bisschen Kontinuierliche Verbesserung und schon entsteht langsam ein professionelle IT.

In anderen Industriebereichen ist das noch völlig unbekannt. Ein schönes Beispiel kam mir neulich in die Hand: Ein Auto-Katalog in meinem Briefkasten mit einem Anschreiben ich möge doch mal durchblättern, ob ich nicht eine Probefahrt mit einem der Modelle machen möchte.

Die Geschichte dahinter ist einige Jahre her, ein Neuwagen dieser Marke zickte nach ca. 3 Jahren rum. Es kam zu Kabelbrüchen durch Korrosion unter dem linken Scheinwerfer. Störung: Wagen sprang nicht mehr an. Die Reparaturen waren kurz, kostengünstig aber hielten nicht lange.

Leicht genervt bat ich die Werkstatt dieses Problem nun endgültig abzustellen, die Werkstatt könne den Wagen so lange haben wie sie mögen, um eine Nachhaltige Beseitigung der Ursache durchzuführen. Nach der Reparatur übergab mir der Werkstattmeister den Schlüssel mit den Worten: „Jetzt hält es für ein Autoleben“ Pause „vermutlich“. Resultat ca. 6 Monate später wieder ADAC.

Nun wandte ich mich an der Hersteller, dessen Hotline nur allerlei Beruhigungspillen verteilte und mir im Prinzip die letzte Reparatur als Gutschein erstattete. Diesen Gutschein lies ich mir in der Werkstatt ausbezahlen. Der Verkäufer empfahl den Gutschein für die nächste Inspektion einzulösen, woraufhin ich ihm leider mitteilen musste, dass das Auto bereits an den Händler einer anderen Marke in Zahlung gegeben wurde.

Soweit ganz normales Chaos, was eben mal passieren kann, wenn sich keiner zuständig fühlt. Kann einem in einer IT auch passieren, darum geht es nicht. Das interessante kommt in den nächsten Jahren. Das wäre in einer professionellen IT nicht so geschehen.

Ich wurde ca. drei Mal in Abstand von Monaten freundlich vom Hersteller angesprochen einen Fragebogen auszufüllen, ob ich mit meinem Auto nun zufrieden bin. Ich nahm brav teil und verneinte jeweils meine Zufriedenheit und teile auch im Notiz-Feld mit das Auto gar nicht mehr zu besitzen.

Per Post von der Werkstatt wurde ich jährlich an Inspektionstermine und deren Überschreitung erinnert. Nun kam nach Jahren eine Hochglanzbroschüre mit dem Angebot sich ein neues Modell dieser Marke anzusehen.

Sicherlich mag manchen Leser einwenden, dass da jemand seinen Marketingprozess nicht gut im Griff hat und es eigentlich nur eines engagierten Verkäufers braucht, dem auffällt das seit Jahren keine Inspektionen mehr durchgeführt wurden und der simpel mal anruft. Absolut richtig, mitdenkende Menschen sind oft der Kit der brüchige Prozesse zusammen hält.

Aber es geht auch wie in der IT üblich mit einem vernünftigen Incident Prozess, Problem Prozess und einer CMDB. Dort wäre die Störungshistorie nicht nur der Werkstatt sondern auch dem Autohersteller ersichtlich, so dass doch mal Aufwand in einen Tausch eines Teils des Kabelbaums investiert worden wäre.

Auch würde das Auto als Service gesehen, wäre die Störung nicht „Kabelbaum oxidiert“ sondern „Auto springt (auch nach Reparaturen) nicht mehr zuverlässig an“. Es ist ja relativ egal, ob die wieder mal was am Auto flicken. Entscheidend ist die Verfügbarkeit des Service Elements, dass mich nach Hause bringt.

Am Ende ist es ganz Einfach, es geht um den Geschäftswert der mit so einem Auto erzielt wird. Da sind in meinem Beispiel der Hersteller, der Händler (mit Werkstatt) und ich als Kunde. Eigentlich liefert der Prozessablauf alle Daten die benötigt sind.

Die richtigen Schlüsse daraus werden aber nicht gezogen. Egal wie die lauten, etwa „Stellt eine Lösung für das Problem (Ursache) zur Verfügung“ oder „Verkauft dem Kunden ein neues Auto mit Nachlass“. Stattdessen arbeitet jeder an seinen Aktivitäten: Die Herstellerhotline reagiert auf eine Beschwerde zu einer „100€“-Reparatur, die Werkstatt repariert nach Vorgabe, Kunde kauft sich ein anderes Auto.

Was bei mir bleibt ist der Eindruck, dass viele andere Industrien sich im Service Management mal anschauen sollten, was die IT dort macht und vor allem auch was in den letzten 10 Jahren dort gelernt wurde.

In der Herstellung von Produkten sind traditionelle Managementmethoden, wie zum Beispiel Lean oder Six-Sigma absolut etabliert und funktionieren prima. Ich glaube IT Service Management ist ein lohnenswerter Baukasten auch in anderen Industrien sobald ein Produkt in der Hand eines Kunden ist. Denn dann hat auch das simpelste Produkt oft Serviceeigenschaften.

Schaut Euch mal an, ob die IT Service Management Methoden was für Euch sind. Ich glaube es ist lohnenswert, zumindest aber mal spannend über den Tellerrand zu schauen.

Standardisierung ohne Gleichmacherei

Größere Unternehmen mit diversen Geschäftsbereichen tun sich oft schwer bei dem vereinheitlichen des IT Managements. Eine Grundversorgung, die alles enthält was gemeinsam benötigt wird und ein Zusatzangebot abgeschotteter Individuallösungen, wäre ein Effizienzvorteil, der schon bei kleinen Firmengrößen leicht als Business Case zu rechnen ist. Diese Standardisierung könnte durch eine gut etablierte externe Beratung oder Mitarbeiter, die von effizienteren Firmen kommen, erfolgreich implementiert werden. Mit Erfolg meine ich nicht Papierware sondern ein Effizienzvorteil ohne Nebenwirkungen oder Mogeleien mit Eh-da-Kosten und Auslastungssümpfen. „Standardisierung ohne Gleichmacherei“ weiterlesen

Kategorienbaum: Weglassen und Flexibel bleiben

Bei Einführung, Umstrukturierung oder Effizienzsteigerung von IT Service Management haben heutzutage schon viele Firmen ein ITSM Tool aka Ticket Tool. Nehmen wir als  Beispiel für eine anstehende Veränderung Outsourcing einiger IT Services. Bei den meisten Firmen führt das Hinzufügen von Services oder Providern zu einem neuen Ast im Kategorienbaum und einigen neuen Blüten, die sich im Laufe der nächsten Monate in veritable Blätter ausdehnen.

Der vernünftige Umgang mit einem Kategorienbaum ist eigentlich auch nur ein Beispiel für den vernünftigen Umgang mit Funktionen zur Verwaltung von Ordnung. Starten die Verantwortlichen nicht ab und zu Mal ihren Hubschrauber und betrachten den schützenswerten Informationsgewinn von oben, kommt es zur Zunahme von Entropie. Statt Komplexität nach Belieben zuzulassen und somit im Praxiseinsatz Unordnung und Verwirrung zu schaffen, gilt hier die Regel: Erst wenn nichts mehr weggelassen werden kann ist es perfekt. „Kategorienbaum: Weglassen und Flexibel bleiben“ weiterlesen

Release Management

Bei der Einführung eines neuen Tools zur Softwareverteilung kam es zu größeren Zwischenfällen, die Antwort vieler IT Verantwortlicher an dieser Stelle ist: Das Tool beziehungsweise die Third-Party Tool ist der Schuldige. Diese Aussage ist zwar richtig, hilft bei dem Problem kaum. Ich war der Meinung: Release Management wird helfen die entschiedenen Baustellen zur richtigen Zeit anzugehen. „Release Management“ weiterlesen