Werft alte Zahlen weg!

Ich war nun ein paar Mal daran beteiligt, wenn IT Organisationen reinen Tisch machen wollten und eine grundsätzliche Neuaufstellung (in Bereichen) anstrebten, sei es durch große Joint-Ventures, Akquisen oder einfach weil das Business in einer Krise steckte.

Vielfach sind mir dort IT Organisationen begegnet, die durchaus wussten das einige Dinge deutlich in Schieflage waren oder einfach alles nur historisch gewachsen sind und jedwede Struktur zu hinterfragen war.

Was mich allerdings wundert ist, dass vielfach die neue Architektur auf bestehende Reports bzw. Zahlen aufgebaut werden sollte. Damit meine ich, das sehr früh noch bei der grundsätzlichen Planung des Veränderungsprozesses vorhandene Reports als Zahlengrundlage genutzt werden sollten.

Es kommen in solchen Veränderungsprozessen nur ganz wenige Beteiligte auf den Gedanken, dass das die Nutzung bestehender KPIs ein Fehler mit möglicherweise immensen Auswirkungen ist. Es liegt auf der Hand, dass die historische Organisation, also die Organisation die in Schieflage gekommen ist, mit diesen Zahlen und Berichten gesteuert hat.

Nur sehr wenige Zahlen in Reports sind objektiv. Die bisherige Organisation dürfte einige KPIs geschaffen haben, an denen Bereiche gemessen wurden, die jetzt angeschlagen dastehen. Natürlich werden KPIs fast immer interpretiert, getuned oder aufgehübscht. Die Messzahlen in vielen Organisationen müssen von Jahr zu Jahr in die gewünschte Richtung wachsen, also tun sie das auch.

Selbst bei Zahlen die mit guter Absicht designed wurden, sind Messpunkte, Konsolidierungen und Abschätzungen zur Berechnung gesetzt worden, dieses Design und seine Kompromisse sollte man sich stets genau ansehen. Viele Dinge sind gar nicht eindeutig oder gar leicht zu messen, also wird ein Stück interpretiert, das ist ganz normal.

Ich wäre sehr vorsichtig und würde nur überprüft saubere Rohdaten heranziehen. Bestehende Reports können eventuell dazu nützlich sein, die alte Organisation zu verstehen und Fehlerursachen bzw. Fehlleitungen zu ergründen.

  • Die meisten Reports werden Aussagelos sein, die wurden irgendwann mal auf dem grünen Tisch entwickelt und seitdem jeden Monat abgeheftet. Specht mit den Verantwortlichen welche Reports die nutzen, was sie daran nutzen und was sie zur Lenkung eingesetzt haben.
  • Bei manchem unsauberen Report ergibt das Monat zu Monat Delta eine brauchbare Aussage. Steigen die Einnahmen bei virtuellen Servern oder fallen diese, auch wenn die Gesamtsumme in Euro nicht mit dem Financial Reporting übereinstimmt. Bitte mit Vorsicht nutzen, manchmal sind Lücken enthalten die einen auf einem Auge Blind machen.
  • Apropos Übereinstimmung: Versucht doch einmal die selbe Zahl (KPI, PI) über verschiedene Business-Unit-Reports zu ermitteln. Anzahl der virtuellen Server einer BU aus den Daten der BU-Reports, CMDB und dem IT Monatsbericht. In einem der letzten Unternehmen waren die so zu ermittelten Abweichungen oft bei bei 15%-20%!
  • Zahlen die durch Interpolation hochgerechnet werden sind in dieser Form irreführend und lohnen keines Blickes. Fehler finden sich zum Beispiel in der Form, dass Zahlen von Hauptstandorten genutzt werden, um auf das Gesamtunternehmen mit einigen großen und vielen kleinen Standorten hochzurechnen. Kleine Standorte funktionieren aber oftmals anders. Sie haben bestimmte Services nicht, diverse Services mit zusätzlichem Aufwand oder ganz simpel eine Shadow IT.

Kurz und gut: Wenn ihr an Bord kommt, um ein auf Grund gelaufenes Schiff wieder in die Fahrrinne zu bekommen. Schmeißt die alten Karten weg und nutzt eure neuen Seekarten. Die alten Karten lassen sich ganz eventuell hernehmen, um die Ursache der Havarie zu ermitteln.

 

Projekte scheitern an „Jetzt mal offen und ehrlich“

Kommunikation in Projekten kann gut uns schlecht laufen. Wenn Projektbeteiligte nicht offen und transparent informiert werden geht das selten auf lange Sicht gut. Die Zeit bringt die Wahrheit ans Licht. Immer. Es gibt aber auch Projektteilnehmer, die allerlei Unsinn treiben falls man sie ungefiltert informiert. Nehmen wir mal die Ampeln in den Wochenreports als Beispiel wie „ehrlich“ in Projekten kommuniziert wird. Diese zeigen sehr schön wie in Projekten kommuniziert werden kann. Eigentlich dient die Ampel dazu dem Management zu signalisieren: „Projekte scheitern an „Jetzt mal offen und ehrlich““ weiterlesen