Viele Wirtschaftlichkeitsrechnungen (oder Business Cases) zu Projekten im Service Management beruhen auf Opportunitätskosten. Da diese sich in unbekannter Auslastung, vermuteten Einsparungen durch vereinheitlichte Vorgehensweisen oder Reduktion von Qualitätsmängeln schon jahrelang versteckt haben, wird es dem Projekt nur schwer gelingen dies in den Griff zu bekommen. Der sicherste Weg in vielen Organisationen ist die ganze Zeit wirre Schätzungen einzutragen und zum Projektende den Erfolg zu berichten.
Für die Projektleiter, die wollen: Es findet sich ein Weg zu messen. Wenn es nicht gerade um offensichtliche Qualitätsmängel geht, muss gemessen werden um überhaupt einen Unterschied bzw. den Zuwachs im Projektverlauf bewerten zu können. Es gibt genügend Projekte, nach deren Abschluss sich eine Schatten IT ausprägt. Von Kosteneinsparungen ist dann nicht mehr zu reden. Die richtigen Parameter und die richtige Messmethodik zu finden, dürfte nicht ganz leicht fallen. Wenn in der Vergangenheit gemessen worden wäre, gäbe es das Projekt nicht. Jede Abteilung könnte klare Zahlen über die Auslastung der Mitarbeiter abgeben und freie Ressourcen erkennen.
Nehmen wir folgendes Szenario: Lokale Support Mitarbeiter „Hey Joes“ sollen durch einen zentralen Service Desk und einen zentral gesteuerten Break&Fix-Prozess ersetzt werden. Selbstverständlich haben die Hey Joes je nach Standort unterschiedliche zusätzliche Aufgaben. Betreuung des Netzwerkes, Drucker, Telefonanlage, Produktionssysteme, uvm. Auch sind die IT Aufgaben in der Vergangenheit nicht klar definiert worden, sondern haben sich lokal entwickelt. Ein ITSM Tool aka Ticket Tool gibt es zur Zeit nicht.
Zentraler Kostenfaktor ist was die Hey Joes alles an Support-Aufgaben übernehmen und wie viel Arbeitszeit dies kostet. Also entscheidet das Projekt, jeder Hey Joe schreibt ab sofort auf, was er im Bereich IT Support tut und wie lange dies dauert. Das Resultat wird unterschiedliche Qualität haben, von dem sorgfältigen Hey Joe, der detailliert anfängt und dann strandet bis zum IT Held der am Ende der Woche eine Liste voller Heldentaten abliefert und 42 Arbeitsstunden kalkuliert, jedoch nur 36,6 Stunden eingestempelt hat.
Über die ungenauen bis unehrlichen Angaben verärgert, beschließt der listige Projektleiter in den nächsten Wochen nach den anderen Aufgabenbereichen wie Netzwerk, Drucker, etc. zu fragen und wird am Ende herausbekommen, dass alles Zusammengerechnet der Großteil der Hey Joes 60,3 Stunden pro Woche arbeiten.
Was ist bei der Messung schief gegangen? Die Messung hat systematische Fehler. Zu Benennen und Quantifizieren, was man in den letzten 8 Stunden gemacht hat, ist schwer. Dazu ist die menschliche Erinnerung denkbar ungeeignet. Vermutlich wird ein Held unterschätzen, dass er 2 Stunden mit einem Desktop Problem verbracht hat. Eine gut vorbereitete Messung, die Kategorien vorgibt und das punktweise Messen mit der Stoppuhr empfiehlt wird für etwas Verbesserung sorgen.
Erschweren wir das Szenario um die Tatsache, dass die Hey Joes abgebaut werden sollen und die meisten Mitarbeiter nichts Genaues über ihre Zukunft im Unternehmen wissen. Mit großer Sicherheit wird dies ein Eigenleben entwickeln und Statistiken verfälschen. Mit rein empirischen Methoden wird das Schwierig.
Systematische Fehler haben das Problem, dass sie sich nicht aufheben und einen zu hohen oder zu niedrigen Messwert erzeugen. Würde es um die Frage gehen, ob die Hey Joes nach dem Rollout eine höhere Arbeitsbelastung haben, könnte man obigen systematischen Fehler so lassen und die Differenz vor und nach Rollout messen. Systematische Fehler sind je nach Typ durchaus kontollier- bzw. akzeptierbar.
Viel leichter in den Griff zu bekommen sind zufällige Fehler, auch wenn Menschen nicht so empfinden. Zufällige Fehler heben sich bei genügend häufiger Messung auf bzw. die Abweichung vom tatsächlichen Wert ist berechenbar. Taschenrechner raus und Los. Während der Aufnahme der verschiedenen Standorte, geht ein Projektmitglied zwei Mal am Tag zu einem Hey Joe und fragt strukturiert nach, was und wie lang in der letzten Stunde gearbeitet wurde. Nach einer Woche wurde 10-mal die letzte Stunde analysiert von 40 Arbeitsstunden der Woche. Der Hey Joe hat stets Angaben zu seiner IT Arbeitszeit gemacht, nur als Beispiel: Die Auswertung zeigt 24 Stunden und 35 Minuten IT Support. Wie genau ist dieser Wert nach 10 Befragungen?
Die Antwort ist verblüffend +/- 22 Minuten bei einem Vertrauensniveau von 95%. Bei 100 Befragungen kommen wir runter bis auf +/- 6 Minuten. Schon bei 10 Messungen liegt das Ergebnis weit besser als bei obiger Wochenliste zu vermuten ist.
Sicher gibt es auch bei dieser Messung systematische Fehler, keine Frage. Auch sollte diese Methode nicht ohne gutes Konzept genutzt werden, da sie platt angewandt nach Überwachung aussieht. Kombiniert mit fachlichen Fragen und Aufgaben des Hey Joes im Projekt kann dies jedoch ganz gut gelingen.
Generell sollten beim Messen von Unbekanntem verschiedene Methoden nach und nach angewandt werden. Selbst wenn alle Projektbeteiligten davon überzeugt sind keine Daten zu haben. Es lohnt sich immer die Aufgabe in Teile zu zerlegen und zu prüfen welche Daten man schon hat. An dieser Stelle möchte den Beitrag zum zufälligen Fehler beenden, mit dem Hinweis. Vorsicht bei existierenden Daten, die sind manchmal konstruierter als man denkt. Aber dazu später mal ein Artikel.