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.

 

Umkrempeln in Other Practices

Wenn Dinge seit Jahren auf eine bestimmte Art erfolgreich betrieben wurden, fehlen den verantwortlichen Betreibern oft Ideen welche Best Practices einen Quantensprung bedeuten könnten. Die Dinge sind seit Jahren entwickelt worden, Kosten reduziert, Services modernisiert, alles fühlt sich gut an. Der Sprung aus dem lokalen Maximum fällt internen Mitarbeitern schwer.

In diesem Beispiel geht es um ein Team guter Mitarbeiter, verantwortlich für IT Grundservices die seit Jahr und Tag pauschal abgerechnet wurden. Dabei wurden alle anfallenden Kosten, Mitarbeiter, Infrastruktur und Zulieferungen in eine Position Grundservice zusammengerechnet. Ein neuer Mitarbeiter bedeutete eine Erhöhung der Pauschale. In Summe kam es selten großen zu Erhöhungen, da im Laufe der Jahre viele Dinge in die Gundservices eingerechnet wurden. Steigerungen wurden dadurch kaschiert, dass entweder Service Elemente die wenige Kunden benötigen aus der Pauschale herausgenommen wurden oder Services die mittlerweile sehr verbreitet waren nun auf alle Kunden umgelegt wurden und in die Pauschale eingerechnet wurden.

Somit hatte man gut begründbare Erhöhungen der Pauschale oder einen gleichbleibenden Preis für die Mehrzahl an Benutzern. Im Laufe der Zeit führte dies zu einem Inhaltlich sehr undurchsichtigen IT Grundservice. Auch war zu vermuten, dass der Grundservice recht preis-intensiv war, da hier zu guten wie in schlechten Zeiten Mitarbeiter aufgebaut bzw. gehalten werden konnten. Das Team war recht gut vernetzt und konnte auch oft mit Ressourcen aushelfen.

Die Ergebnisse, die von den Mitarbeitern geliefert wurden, hatten Hand und Fuß, nur war so Einiges von dem Thema Grundservice oft weit entfernt.
Ernsthaftige SLAs bzw. OLAs hatte der Grundservice auch nicht zu bieten, da es ein Konglomerat aus allem Möglichen war und eben nicht in technische Services geschnitten war.

Dieses Vorgehen ging einige jahre gut. Bis irgendwann schlechte Geschäftsentwicklung und der mittlerweile hohe Preis aufeinander trafen, was den IT Grundservice hell auf dem Optimierungsradar leuchten lies. Auch waren die Anforderungen an das Einsparpotential nicht mehr durch die Optimierungen der letzten Jahre zu befriedigen. Dem Team wurde die Aufgabe gegeben den IT Grundservice zu verschlanken und in die bereits gewachsene Servicelandschaft einzugliedern.

Nach Wochen stellte sich heraus, dass das Team mit der Optimierungsaufgabe hoffnungslos überfordert war. Die vielfach guten Vorgehensweisen und Optimierungsstrategien der letzten Jahre waren nicht ausreichend. Ein lokales Maximum schien erreicht. Die größte Herausforderung war jedoch, dass alle Teammitglieder in diese Art der Serviceerbringung hineingewachsen waren und deshalb wenig über die Alternativen wussten.

Eine Aufteilung in technische Services wurde mit der Anforderung, dies auch in der Teamorganisation umsetzten zu müssen, verwechselt. Auch galt es als kaum einschätzbares Risiko, dass nun Kunden nur noch Teile der Services kaufen könnten und bei falscher Preisgestaltung, nicht genug Einnahmen zur Erhaltung des Teams da sind.
Mögliche zu liefernde Service Level Targets wurden vom Team selbst eingebracht, trotzdem aber maßlos überbewertet und resultierten im Business Case in zusätzlichen Investitionen.
Last but not least war das Team dafür bekannt gerne Kompromisse einzugehen und viele Dinge mit aufnehmen zu können. Die nun geforderte Stringens bei der Auflösung der IT Grundservices war nicht zu finden, stattdessen wurden Meetings erweitert oder wegen Zuständigkeiten mit anderen Teilnehmern neu einberufen.

Die Lösung kam tatsächlich erst durch externe Beratung zustande, obwohl man intern sehr viel von den umgebenden Services bzw. deren Managern hätte ableiten können. Die externe Beratung hat den zusätzlichen Vorteil gehabt, übliche Serviceschnitte und deren Marktpreise zu kennen.

Zudem hat der Berater sehr stingend das Projekt als Continual Service Improvement (CSI) aufgesetzt. Die IT Grundservices wurden tatsächlich von Heute auf Morgen, sprich zum neuen Geschäftsjahr völlig neu aufgesetzt. Der Hauptvorteil des CSI Ansatzes war, dass Risiken sehr gut finanziell bewertet werden konnten, so dass weder eine Unterdeckung noch eine zusätzliche Investiotion in die Infrastruktur getätigt werden mussten.

So ganz radikal war es dann doch nicht. Die geplanten Service Level Targets wurden im ersten Jahr nur gemessen und erst danach zur Effizienzsteigerung genutzt. Auch gab es für die sich angesammelten „Dinge“, damit meine ich Services und Infrastruktur für kleine Abnehmerkreise bzw. gute Kunden eine Art Exil. Diese Services wurden von einer Stabskostenstelle finanziert und mussten innerhalb von zwei Jahren abgestellt oder in einen eigenständigen Service überführt werden.

Die Quintessenz ist, dass Dinge die einmal gut waren sich im Laufe der Zeit zu renovierungsbedürftigen Teilen entwickeln können. Ohne das es einem bösen oder dummen Willen bedarf.

Gerade wenn Services industrialisiert oder nach Best Practices ausgerichtet werden sollen, fehlt es den bisherigen Servicelieferanten an Erfahrung und damit an Mut ihre Services umzustellen. Auch wenn es noch so oft von Anderen in der Praxis optimal gezeigt wurde.
Mit ein wenig externen Wissen, dem Lehrbuchmäßigen Anwenden von Verbesserungsprozessen und vielleicht einer kleinen Absicherung, gelingt das Vorhaben.

Den Mut der Beteiligen benötigt es dennoch. Und bitte nicht den Eindruck entstehen lassen, dass die frühere Art zu lieferen schleicht war – es sei denn sie war es wirklich 🙂

Transformation: There are no easy answers

Sometimes the need to improve is a well known fact in an IT organization. In such cases the desire for change is powered by a large base of employees. No doubt, we are not talking about a coordinated focused movement – a lot of players will have their very special views on areas of improvement. Problems massed up due to the fact that changes in organization, operations, sourcing, etc. were not commonly designed. For sure the usual game of circumvention of a central architecture by some operational teams is also a source of inefficiency.

[Link to German version]

„Transformation: There are no easy answers“ weiterlesen

Transformation: There are no easy answers

Vielfach kommt der Wunsch nach Veränderung oder sagen wir besser der Zwang zur Verbesserung einer IT Organisation von Innen. Fast alle Beteiligten leiden unter der aktuellen Situation und haben ihre Ansichten zu Dingen die verbessert werden können. Oftmals liegt es daran, dass über Jahre sich die Serviceerbringung zwar verändert hat eine durchgestochene Anpassung der Organisation, Abläufe, Sourcing, etc. von Management bis hin zur Operation nicht vorgenommen wurde. Die auf dem Weg aus der Not vorgenommenen lokalen, kleinen oder kompromissbeladenen, großen Änderungen haben sich zu einem aufwändigen Szenario entwickelt aus dem auch so schnell kein Entkommen ist. Ich meine die Betonung liegt auf: „so schnell“. Mit Bedacht, sorgfältiger Planung und etwas Durchhaltevermögen ist das zu schaffen. Einfache Antworten sind da meiner Meinung nach nicht gefragt. „Transformation: There are no easy answers“ weiterlesen