toom: Agiler Service Support im ITIL-Umfeld

So sah die Herausforderung bei toom aus

Das Potenzial des Support-Teams ausnutzen  

Der Support-Bereich bei toom befand sich in einer schwierigen Situation: Er bekam sowohl die Kritik der Filialen zu spüren und erhielt gleichzeitig wenig Unterstützung aus dem Unternehmen. Häufige Eskalationen von Problemen und Incidents in das Top-Management schmälerten das Vertrauen in den Support. Support-Mitarbeiter:innen hatten als Schnittstelle zu den Filialen eine bedeutsame Position im Unternehmen, weil sie wie kein anderer Bereich ungeschöntes Feedback zu den Anwendungen erhalten. Dieses Potenzial wollten wir für das Unternehmen nutzbar machen. Da in der jüngeren Vergangenheit bereits vergebliche Versuche unternommen wurden, den Support-Bereich neu aufzustellen, holte Kim Schreiter, Leiterin Service Operations, it-agile mit ins Boot. Gemeinsam formulierten wir 3 übergreifende Ziele:

Die Ziele im Mai 2020

• Größere Zufriedenheit der Märkte mit dem Support
• Weniger Incidents
• Effizientere Arbeitsprozesse (erkennbar an geringeren Lösungszeiten)

Der Auftrag: Support-Mitarbeiter:innen und Management ermöglichen, nachhaltige Verbesserung der Arbeitsprozesse im Sinne dieser Ziele zu erreichen. Mitarbeitende und Management schätzten, dass diese Ziele nur langfristig (>1 Jahr) erreicht werden können.

So konnten wir gemeinsam mit unserem Kunden anpacken

Zusammenarbeit, Transparenz, Fokus und Feedback-Loops

Ein zentrales Problem wurde schnell sichtbar: Die Schwierigkeiten, die vornehmlich die große Zahl an Eskalationen, lange Bearbeitungszeit und geringe Zufriedenheit der Filialen auslösten, lagen nahezu ausnahmslos in den Schnittstellen zwischen dem Support und anderen Bereichen des Unternehmens. Häufig waren zusätzlich Schnittstellen zum Mutterkonzern, der Rewe Systems, betroffen. Ein Ansatz, der sich auf den Service Support beschränkt, würde nahezu keinerlei Auswirkungen haben.


Unsere Empfehlung war daher, ein Vorgehen zu finden, dass

1. eine enge Zusammenarbeit über alle Unternehmensbereiche hinweg ermöglicht,
2. volle Transparenz über den Stand aller Veränderungsmaßnahmen für das gesamte Unternehmen herstellt,
3. klaren Fokus setzt auf die Verbesserungsmaßnahmen, die den größten Kundennutzen versprechen und
4. Feedback-Loops etabliert, um das Problembewusstsein bei allen Betroffenen zu schärfen.

Trotz des deutlichen erweiterten Scopes der Veränderung wurde gemeinsam entschieden, in die Umsetzung zugehen.

Enge Zusammenarbeit über alle Fachbereiche hinweg

• Vorgehen: Wir etablierten ein 2-wöchiges Meeting, zu dem sämtliche Fachbereiche eingeladen wurden. In diesem Meeting wurden die wichtigsten Verbesserungsmaßnahmen gemeinsam priorisiert, es wurde besprochen, wer bei der Lösung involviert sein kann/muss und der Fortschritt der Verbesserungsmaßnahmen wurde gezeigt.
  Eine der priorisierten Verbesserungsmaßnahmen war die Vermeidung von Incidents durch Produktanpassungen durch die Entwicklungsteams. Hier entwickelte das Support Team Ideen, die es mit den Entwicklungsteams besprach und im Nachgang vom Management gegenüber anderen Entwicklungsthemen priorisieren ließ. Einige dieser Ideen wurden daraufhin von den Entwicklungsteams umgesetzt.
• Wirkung: Zum Ende der Zusammenarbeit waren die ersten Themen umgesetzt und live geschaltet. Das Support-Team hatte eine Reduktion der Incident-Zahlen von ca. 5% durch die Maßnahmen vorausgesagt. Eine Überprüfung dieser Schätzung konnte im Rahmen der Zusammenarbeit nicht mehr stattfinden. Zusätzlich zu dem Effekt auf die Zahl der Incidents, hatte diese Maßnahme einen kulturellen Effekt: die Mitarbeiter des Supports, die zuvor eher als „Handlanger” der Entwicklungsteams gesehen wurden, hatten nun eine Position als Stakeholder.
• Ausblick: Im folgenden muss dieses Vorgehen verstetigt werden: In regelmäßigen Abständen (z. B. alle 3 Monate) liefert das Support Team Ideen, durch welche Maßnahmen die Entwicklungsteams zu einer Verringerung der Incident-Zahlen beitragen können, bespricht diese mit den Entwicklungsteams und sorgt für die Priorisierung gegenüber anderen Entwicklungs-Aufgaben.

Volle Transparenz und klarer Fokus

• Problem: Bislang wurde an Verbesserungsmaßnahmen von den Mitarbeitern im Support unter Hochdruck gearbeitet, jedoch konnte nur wenig fertiggestellt werden. Wir bemerkten, dass Mitarbeiter im Support und in den Märkten, das Management und andere Stakeholder viele Verbesserungsideen hatten und sich je nach aktueller Entwicklung der Fokus der Beteiligten wöchentlich, manchmal täglich verschob. Hierdurch verschoben auch die Support-Mitarbeiter ihren Fokus in der Arbeit und starteten neue Themen, ohne alte abzuschließen.
• Vorgehen: Im Rahmen des zentralen Meetings etablierten wir ein simples Kanban-Board, das nur 4 Spalten enthielt: Ideenpool, Next, Doing, Done. Die letzte Spalte, Done, enthielt alle abgeschlossenen Themen. Die dritte Spalte, Doing, enthielt alle Verbesserungsideen, an denen gerade gearbeitet wurde und war streng begrenzt auf 10 Themen. D. h. zu keinem Zeitpunkt waren mehr als 10 Themen gleichzeitig in Bearbeitung. War ein Thema einmal in Bearbeitung, wurde es entweder bis zu einem ausreichenden Fertigstellungsgrad umgesetzt oder komplett verworfen (z. B. weil eine nähere Betrachtung gezeigt hatte, dass die Idee nicht umsetzbar ist oder weniger wertvoll als ursprünglich angenommen). Die zweite Spalte, Next, enthielt einige wenige (3-5) Verbesserungsideen, die wir gemeinsam mit den Stakeholdern als besonders zentral erachteten. Diese waren klar priorisiert, d. h. das wichtigste Thema stand ganz oben, das zweitwichtigste Thema stand an zweiter Stelle u.s.w. Wurde in der Spalte Doing etwas fertiggestellt und somit ein Platz frei, wurde die am höchsten priorisierte Verbesserungsidee aus der Spalte Next nachgezogen und in Bearbeitung genommen. In der ersten Spalte, Ideen, sammelten wir alle Verbesserungsideen, die von den verschiedenen Beteiligten in allen möglichen Kontexten geäußert wurden. Diese Spalte wuchs schnell auf über 100 Einträge.
• Wirkung: Themen, an denen gearbeitet wurde, wurden mit Fokus und Konzentration bearbeitet. Der ständige Fokuswechsel wurde deutlich reduziert. Das führte dazu, dass Themen in der Regel innerhalb von wenigen Wochen fertiggestellt werden konnten. Während vorher unklar war, an welchen Themen überhaupt noch aktiv gearbeitet wurde, herrschte durch das Board eine vollständige Transparenz über alle Fachbereiche hinweg. Zusätzlich war es möglich, in etwa abzuschätzen, wann ein neues Thema von der Prioritätenliste (Next-Spalte) in Arbeit genommen werden kann. Mit Stakeholdern, die neue Verbesserungsideen einbrachten und deren Dringlichkeit verdeutlichten, konnten wir fruchtbare Diskussionen führen und die neuen Ideen mit anderen Themen in der Next-Spalte vergleichen. Manchmal stellte sich heraus, dass die neue Idee in Spalte 1, im Ideenpool, am besten aufgehoben war, da die erwarteten Effekte weniger groß sein würden, als die der anderen priorisierten Themen. In anderen Fällen priorisierten wir die neuen Ideen in der Next-Spalte ein und schätzten grob ab, wann eine Bearbeitung in etwa starten könnte. Ging es nicht schnell genug, führten wir ein Gespräch darüber, wie der Stakeholder uns beim schnelleren Abschluss der Themen im Doing unterstützen könnte, um schneller Platz für das neue Thema zu schaffen.
• Ausblick: Die Limitierung der Themen im Doing auf nur 10 Themen, die gleichzeitig bearbeitet werden, ist zentral. Gleichzeitig erfordert dies konstante Pflege und Aufmerksamkeit: Sich auf wenige Dinge zu fokussieren fällt uns allen schwer und erfordert oft harte Entscheidungen. Alle Beteiligten sind inzwischen für das Thema sensibilisiert, dennoch wird es anspruchsvoll, die Limitierung beizubehalten.

Etablierung von Feedback-Loops

• Problem: Im zentralen Meeting stellten wir fest, dass wir den Fokus der Diskussion immer wieder aktiv auf die Mitarbeiter in den Märkten (Kunden des Supports) lenken mussten. Dadurch, dass die Markt-Mitarbeiter nicht selbst mitdiskutierten, wurden häufig IT-interne Unzufriedenheiten höher bewertet. Da es uns nicht praktikabel erschien, die Mitarbeiter aus den Baumärkten selbst mit in das Meeting zu holen, wollten wir andere Wege finden, ihre Bedürfnisse im Meeting sichtbar zu machen.
• Vorgehen: Um dies zu erreichen, führten wir ein Bewertungssystem ein, bei dem die Märkte ihre Zufriedenheit mit der Bearbeitung eines Incidents angeben konnten.
• Wirkung: Zum Ende unserer Zusammenarbeit war das Bewertungssystem etabliert und erste Antworten der Märkte lagen vor. Diese Antworten waren erwartungsgemäß wenig positiv und der Support scheute sich davor, die Bewertungen in einem so zentralen Meeting allen Fachbereichen zur Verfügung zu stellen.
• Ausblick: Zumindest Teile des Feedbacks aus den Märkten müssen ihren Weg in das zentrale Meeting finden, um hierdurch den Fokus der Diskussionen in Richtung Kundenzentralität zu verschieben. Die Informationen aus den Feedbacks der Märkte sind wertvoll, um bessere Priorisierungen im Sinne der Kunden vornehmen zu können und ggf. sogar, um ganz neue Ansätze zur Prozessverbesserung zu entwickeln.

• Problem: Eine Erkenntnis aus den Feedbacks der Märkte war, dass die Nachrichten, die die Mitarbeiter in Märkten zum Stand oder zur Lösung ihrer Incidents bekamen, keine Informationen über den Incident selbst enthielten. Dadurch mussten die Mitarbeiter sich zunächst an stationären Computern im Markt in das Incident Management System einloggen, über die Incident ID den Ursprünglichen Incident aufrufen und wussten erst dann, welches Anliegen gelöst wurde.
• Vorgehen und Wirkung: Das Support Team fand einen einfachen Fix für das Problem. Innerhalb von 2 Wochen nach Eingang des Feedbacks war die Änderung implementiert. Durch den engen, fachbereichsübergreifenden Austausch im zentralen Meeting, wurden die Märkte über wöchentliche Gespräche mit dem Vertriebsteam über die Änderung informiert. 

• Problem: Eine große Zahl von Incidents wartete bei Entwicklungsteams oder in Fachbereichen auf Bearbeitung. Je nach Team und Fachbereich war das Bewusstsein über die Menge an Incidents und deren Dringlichkeit sehr unterschiedlich ausgeprägt.
• Vorgehen: Um das Problem für Entwicklungsteams und Fachbereiche spürbar zu machen, führten wir ein Tracking-System ein, mit dem wir die Zahl der Incidents je Team, sowohl in der IT als auch außerhalb, übersichtlich auf einer Seite sichtbar machen konnten. Wir etablierten “Ops-Days” in der IT (ca. 1 x pro Quartal), die genutzt wurden, um die Incidents abzuarbeiten.
• Wirkung: Die Zahl der offenen Incidents im Gesamtsystem wurde um ca. 15% reduziert. Ausblick: Das Konzept war so beliebt bei den Teams in der IT, dass zum Ende der Zusammenarbeit Pläne diskutiert wurden, Ops-Days im gesamten Unternehmen, also auch für die Fachbereiche, auszurollen.

• Problem: Durch die Transparenz, die das Tracking-System schuf, wurde ein weiteres Problem sichtbar: die beiden Fachbereiche mit der größten Zahl an offenen Incidents waren bislang weder Teil unserer zentralen Meetings, noch waren sie an das Incident Management System angeschlossen.
• Vorgehen: Aufgrund der Vielfältigkeit der Teilnehmer am zentralen Meeting konnten wir beide Bereiche von mehreren Seiten ansprechen. Zum einen aus dem Management heraus, um die Dringlichkeit des Themas zu verdeutlichen, zweitens auf einer Systemebene, um schnell Anschluss an das Incident Management System herzustellen, drittens auf der operativen Ebene, um praktische Unterstützung bei der Abarbeitung der Incidents zu liefern.
• Wirkung: Zum Ende der Zusammenarbeit waren beide Fachbereiche an das Incident Management System angeschlossen und hatten mit der Bearbeitung ihrer Incidents begonnen.
• Ausblick: Der Effekt dieser Maßnahme auf die Zahl der Incidents und die Bearbeitungszeit muss überprüft werden. 

• Problem: Wir wussten durch die Transparenz des Tracking-Systems, wie viele offene Incidents jedes Team hatte. Jedoch war noch unklar, wie viele Incidents im Service Support jedes (Entwicklungs- und Infrastruktur-)Team durch fehlerhafte Einführung von Hard- und Software verursachte.
• Vorgehen: Den Feedback-Loop hierfür stellten wir her, indem wir begannen, im Service Support Incidents konsequent größeren Problems zuzuordnen. Die Zahl der Incidents in Problems stieg durch dieses Vorgehen um das 5-fache. Wir zeigten in unserem zentralen Meeting jeweils die Problems, die in den letzten 2 Wochen am häufigsten vorgekommen waren und besprachen mit den Anwesenden, welche Schritte sie zur Lösung der Probleme eingeleitet hatten.
• Wirkung: Dieses Vorgehen etablierten wir zum Ende unserer Zusammenarbeit. Die Gespräche im zentralen Meeting und der Blick auf das Problem aus verschiedenen Bereichen heraus brachten oft neue Lösungsoptionen hervor.
• Ausblick: Der Effekt dieser Maßnahme auf die Zahl der Incidents, die Bearbeitungszeit und die Zufriedenheit der Märkte muss überprüft werden.

• Problem: Die Bearbeitungszeiten je Incident schwankten stark und von den Mitarbeitern in den Märkten wurde bemängelt, dass zu häufig die leicht umsetzbaren Incidents sehr schnell bearbeitet wurden, während dringliche Incidents lange liegen blieben.
• Vorgehen: Wir werteten Bearbeitungszeiten verschiedener Incident-Typen aus und begannen, Service Level Agreements für die Bearbeitungsdauer auf Basis dieser historischen Daten auszuarbeiten. Diese Ausarbeitung geschah in enger Zusammenarbeit mit den Mitarbeitern in Service Desk und 1st Level Support und wurde so gewählt, dass die Mitarbeiter von der Machbarkeit dieser Service Levels überzeugt waren.
• Ausblick: Die Implementierung der Service Level Agreements ist noch nicht vollständig erfolgt. Auch fehlt noch eine Besprechung der Service Level Agreements mit ausgewählten Markt-Leitern. Unsere Erwartung ist, dass insbesondere die Kommunikation über Service Level Agreements mit Marktleitern einige Unzufriedenheiten mit dem Status Quo zutage fördern wird und uns konkrete Anhaltspunkte gibt, für welche Incident-Typen eine kürzere Bearbeitungsdauer erfolgskritisch ist. Die Prozessverschlankung rund um die so identifizierten Incident-Typen können dann im zentralen Meeting gegen andere Maßnahmen priorisiert werden.