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 🙂

Zeitmanagement nützt nicht, ich kann ja nicht delegieren

Im IT Service Geschäft geht es nicht nur um technische Architekturen und Interfaces, sondern zu ganz großen Anteilen um soziale Konstellationen und Schnittstellen. Technische Arbeit gibt es immer und es findet sich eigentlich immer ein Kollege oder Nachbarabteilung, die eigentlich das Problem haben und es bitteschön lösen müssen. „Zeitmanagement nützt nicht, ich kann ja nicht delegieren“ weiterlesen

Issue: Incident and Problem

ITIL® provides a set of good practices which is a kind of general direction. In ITIL there are processes and roles that need to be provided. How exactly is a matter of the individual organization. In the ITIL books you will also find remarks, anecdotes or even sometimes (inappropriate) generalizations that give a good indication of how processes and functions are implemented in reality. A very common question of ITIL beginners is, how an incident becomes a problem. The short answer is: „Never“. The full answer is as follows …

[Link to German version]

„Issue: Incident and Problem“ weiterlesen

Messen im Schatten des Business Case

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. „Messen im Schatten des Business Case“ weiterlesen

Support aus Qatar

Ich hatte für die deutsche Tochter eines amerikanischen Unternehmens gearbeitet, deshalb hatte ich doch ein gewisses Verständnis für die Nöte lokaler Dependancen. Wenn man fern-ab von der Hauptniederlassung arbeitet, fallen einem manche Dinge leichter, die meisten Sachen jedoch schwerer.

Viele Vorfälle im Support lassen sich Remote per Fernwartungssoftware oder ganz simpel per Web-Videokonferenz lösen. Bei dieser Lösung gibt es einen Nachteil für den lokalen Support. Remote Management bedeutet ist eine große Qualitätseinbuße im Wissenstransfer. Auch ist es in vielen Projekten sinnvoll in heißen Phasen von PreSales oder Go-Live einen Support-Mitarbeiter vor Ort zu haben. Dieser schafft Vertrauen und kann ganz nebenbei lokale Mitarbeiter des Partners Hands-On trainieren.

Da Aufträge bei den meisten Organisationen die Eigenschaft haben plötzlich und unerwartet zu kommen, war es eine deutliche Herausforderung passendes Training und Support immer via Headquarter zu stemmen.

Was lag da näher, als über lokale Support Organisationen nachzudenken? Soweit bestand auch Einigkeit, nur das wie, darüber wurde heftig diskutiert. Wir brauchten aber Geschwindigkeit. Also haben ein toller Kollege aus dem Vertrieb und ich gemeinsam einen Business-Plan entwickelt, die Genehmigung der Geschäftsleitung erhalten und das Supportkonzept innerhalb eines halben Jahres umgesetzt.

Die meiste Arbeit war intern. Im Projekt selber definierte sich das Supportkonzept aus den Anforderungen, die von vielen Seiten über Monate und Jahre gefordert wurden. Das war einfach. Die Schwierigkeit war einen flexiblen Vertrag zu definieren, der eine wilde Unterstützung aller Projekte einschränkte, aber genug Spielraum zum wachsen hatte.

Nach einem knappen halben Jahr konnten wir zum ersten Referenzbesuch aufwarten. In der Werkstatt konnte man vom Boden essen, so sauber war es. Die erste Statistik war auf Basis von Excel. Ein Punkt, der uns leichte Sorgen gemacht hat war: Mittags zeigte das Autothermometer 50° Außentemperatur an. Wir erkundigten uns nach den lokalen Gepflogenheiten zur Klimaanlagen-Wartung. Alles in Ordnung 🙂