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.

In der Praxis finden sich oft beliebig verwachsene Gebilde, deren Bedeutung sich erst erschließt nachdem man die Organisationsstruktur und teilweise die historische Entwicklung der IT Organisation kennengelernt hat. Allein schon ein Ausdruck des Kategorienbaums gibt erste Hinweise: Wildes verwachsenes Gebüsch aber auch englischer Vorgarten sind normalerweise alarmierend. Bei der initialen Analyse des Baums sollten auch die Vorfälle (Incidents) pro Unter-Kategorie Beachtung finden. Ich konnte einen Service Desk Leiter nach langem Ringen davon überzeugen seinen „Kategorien-Wald“ auszudünnen nachdem wir festgestellt haben, dass die Mehrzahl seiner Kategorien im letzten Jahr niemals genutzt wurden.

Ziel festlegen: Was muss der Kategorienbaum können? Typische Anforderungen sind: Eine Störung, Ursachenanalyse oder Änderungsantrag den richtigen Support-Teams zuordnen, in Services bzw. Produkte unterscheiden, bei der funktionalen und hierarchischen Eskalation Informationen bereitstellen, Berichte über Service Level Targets, Teams, Zulieferer, Produktqualität, etc. unterstützen, Qualität von größeren Änderungen nach-halten und vieles mehr. Diese Ziele sind nur Beispiele, spätestens bei näherer Betrachtung wird es zwischen den Zielen Konflikte geben, deshalb beim Entwurf von oben nach unten arbeiten. Sollen die Kategorien eine Kommunikation mit dem Endanwender erleichtern und deshalb seine Sprache sprechen? Falls ja, dann wird eine strikte Unterteilung in Produkte oder technische Services nur ein nachrangiges Ziel sein können.

Bleistifte raus: Nachdem verschriftlicht wurde was Ziel der Übung ist, geht es an die Konstruktion. Solche Bäume leben manchmal für die Ewigkeit, da kann eine Orientierung an Fixpunkten helfen. Was wurde in den letzten Jahren verändert, was ist stabil geblieben? Organisationseinheiten werden geändert, Services unterschiedlich vergeben, demnach zu schnell für obere Kategorien. Neue Services kommen hinzu, werden aber oft von existierenden Teams aufgenommen, hier verlangsamt es sich. Werke und Bürogebäude werden anderen Einheiten oder Regionen zugeschlagen, geografisch ändern sie sich jedoch nicht, da gibt die Erdkugel den festen Halt.

Vom Business Service aus gedacht entsteht eine verständliche Sprache für Endanwender und eine Stabilität gegenüber Produkten. Im Notfall kann auch vom Produkt aus gedacht werden, die Verwendung von Begriffen wie „ERP Service“ und „Outlook“ an sich in einer Kategorien-Ebene ist nicht ganz sauber, kann aber im Einzelfall zur Firma passen. Nebengeräusche von Pendanten dürfen kurz betrachtet und dann zu den Akten gelegt werden 🙂

Die Zuordnung einzelner Äste oder Blätter zu Support-Teams sollte je nach festgelegtem Ziel ordentlich strukturiert sein und nach Möglichkeit eher auf Ast als auf Blatt-Ebene geschehen. Das passt vermutlich auch zu der Wirklichkeit, da ein Operations-Team meist eine ähnliche Produktpalette bereut. Falls beim scrollen des Kategorienbaums die Support-Team-Bezeichnungen anfangen zu flackern, nochmal zurück auf Los und die Services ein wenig mehr nach Teams strukturieren.

Wie hast du’s mit der Konsistenz? Nicht um jeden Preis. Der Kategorienbaum sollte zwar nicht aussehen wie ein von Rotwild zerzaustes Gebüsch, aber die Hecke darf dort wo viel Wasser ist höher wachsen, als in dürren Ecken. Auf jeden Fall müssen doppelte Einträge vermieden werden, siehe obiges Beispiel E-Mail. Falls es dazu einen Disput zwischen den Support-Teams gibt mein Rat: Solche Diskussionen werden meist von Anwendungsfällen (Use Cases) genährt, die immer abstrakter und alltagsfremder werden. Deshalb bitte darauf bestehen, dass nur echte Beispiele aus dem letzten Monat als Diskussionsgrundlage genutzt werden dürfen.  Wenn es im letzten Monat einen solchen Fall gar nicht gab, weg mit dem ganzen Ast. Braucht keiner.

Nächste Gretchenfrage: Darf es eine Kategorie „Diverses“ („Misc“ oder „Others“) geben?  Ich meine „Ja“, bin aber auch mit „Nein“ einverstanden. Eine Kategorie „Diverses“ muss streng überwacht werden. Sie ist kreativer Quell für Verbesserungen an der Baumstruktur und ein guter Indikator für Trainingsmängel im Support Team. Wenn sich in der Praxis niemand darum kümmert wird daraus zu 100% eine Müllhalde und ein Hort für schlampige Leute. Falls es nichts „Diverses“ geben darf, dann muss täglich ein Teammanager bereitstehen und Zweifelsfälle entscheiden, sonst entsteht eben irgendwo eine Dreckecke.

In dem Zusammenhang rate ich auch dazu ein Konzept für Projekte einzuplanen. Während des Piloten und Rollouts können so viele Vorfälle auftauchen, dass sich eine Unterkategorisierung lohnt. Diese müssen unbedingt aus dem Baum verschwinden, sobald das Projekt beendet ist. Wenn dort kein Konzept definiert wurde, hat der Service Desk Chef nachher seine liebe Mühe mit dem Service Manager zu diskutieren. Die Argumentation läuft dann ungefähr so:
„Aber die Unterkategorisierung war doch ganz nützlich!“
„Ja, im Projekt hatten wir 150 Incidents und nun haben wir 5 Incidents pro Monat in 10 Unterkategorien“
„Okay, aber es könnte doch auch mal mehr werden!“
Werden die Unterkategorien mitgeschleppt, hat ein neu eingestellter Service Desk Agent keine Chance die 10 Unterkategorien (pro Projekt) zu beherrschen. Aus dem Hubschrauber betrachtet ergibt es auch keinen Sinn im Reporting 0,1 und 2 als Werte zu betrachten.

Wo wir nun schon mal bei Konzept sind, das Design des Kategorienbaums sollte auch außerhalb des Ticket Tools ordentlich dokumentiert sein. Insbesondere welche Änderungen erlaubt sind und wie diese in das System kommen. Nun zum nächsten wichtigen Gestaltungsprinzip: Die erlaubte Tiefe des Kategorienbaums und die Bedeutung der oberen beiden Ebenen gilt es festzulegen. Hier gilt nun wirklich weniger ist mehr. In einem Projekt habe ich schon einmal die Regelung durchgesetzt, dass tiefere Ebenen zugelassen werden, diese ohne Ausnahme explizit für Support-Team-Interna bestimmt sind. Bedingung war, dass beim Weiterleiten von Tickets an andere Support-Teams diese Team-Ebene entfernt wird und auch im zentralen Reporting nicht auftauchen darf.

Meine letzte Anmerkung zur Struktur des Kategorienbaums bezieht sich auf die Möglichkeit verschiedene Bäume für Incident Management, Request Fulfilment, Change Management, uvm. anzulegen. Hier habe ich eine Tendenz zur Vereinheitlichung. Es gibt aber auch gute Gründe zum Beispiel den Baum für Refest Fulfillment stringent nach Services aufzubauen, wenn sich die Teams zu den Service-Erbringern unterscheiden.

Eine radikale Idee zum Schluss, denkt doch mal darüber nach. In gewachsenen Strukturen können viele Dinge nicht sauber neu aufgesetzt werden, auch wenn sich alle Beteiligen aus der alten Struktur gelernt haben und sich einig sind, dass etwas Neues besser funktionieren würde. Wie so oft in der angewandten Informatik wurden im Laufe der Zeit Dinge aneinander-gebastelt die danach einen Wust darstellen, mit dem keiner mehr glücklich ist.

Wie wäre es damit im ITSM Tool bei Incident, Problem und Change eine Art Jahresabschluss vorzusehen. In der Weihnachtspause werden alle Transaktionen abgeschlossen, archiviert und nur wenige in das neue Jahr übertragen. Aufräumarbeiten a la Kategorienbaum, aber auch Service Level Targets, Prioritäten, Change Modells, etc. können fortan in der Weihnachtspause radikaler und somit sauberer implementiert werden. Daraus resultierendes Reporting existiert dann immer konsistent für ein Jahr. Ich kenne kaum Anwendungsfälle in denen detaillierte Statistiken über mehrere Jahre hinweg gepflegt werden müssen. Die wichtigsten KPIs behält man ohnehin bei. Beziehungsweise, brauchen wir die eigentlich?

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.