Sucess Story toom

toom: Agiler Service Support im ITIL-Umfeld

Gasunie: Scrum-Pilot mit it-agile

Um welchen Kunden geht es?

toom Baumarkt GmbH

Mit mehr als 300 Märkten, über 15.000 Beschäftigten und einem Bruttoumsatz von über 2,6 Milliarden Euro zählt toom zu den führenden Anbietern der deutschen Baumarktbranche. Das Unternehmen gehört zur REWE Group. toom belegte bei der Wahl zum „Händler des Jahres 2017- 2018” wiederholt den ersten Platz in der Kategorie „Baufachmärkte”. 

  • toom Baumarkt GmbH
  • über 15.000 Beschäftigte
  • mehr als 300 Märkte in Deutschland
  • etwa 2,6 Milliarden Euro Bruttoumsatz

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.

Das sagt unser Kunde zum Einsatz

Mit it-agile haben wir [...] unsere Support-Prozesse so umgestellt, dass Kunden-Feedback für einen kontinuierlichen Verbesserungsprozess über Fachbereichsgrenzen hinaus genutzt wird.

Thomas Schwachenwalde

(Bereichsleiter IT)

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.

Was haben wir zusammen mit unserem Kunden gelernt?

Empfehlungen für Unternehmen in ähnlichen Situationen

  • Etablieren Sie zunächst ein zentrales Meeting und ein Board, das die Veränderungsmaßnahmen im Service Support visualisiert. Starten Sie mit Mitarbeiter:innen des Service Supports, Vertretern der Entwicklung und einigen wenigen Fachbereichen. Im Laufe der Zeit können sich die Teilnehmer ändern.
  • Achten Sie darauf, die Zahl der Veränderungsmaßnahmen, die gleichzeitig in Bearbeitung sind, zu begrenzen. Das ist zentral, um für einen raschen Abschluss der Themen zu sorgen.
  • Machen Sie die einzelnen Veränderungsmaßnahmen so klein wie möglich, um schnell Erfolge sehen und häufig neu priorisieren zu können. So stellen Sie sicher, dass Sie flexibel bleiben.
  • Verknüpfen Sie den erwarteten Effekt der Veränderungsmaßnahmen mit den Zielen, die Sie sich gesetzt haben. Überprüfen Sie den Effekt einer Maßnahme nach deren Umsetzung. Das hilft Ihnen, eng an den Zielen zu arbeiten und über die Wirksamkeit der Maßnahmen in Bezug auf die Ziele zu lernen.
Erfolgreich Agil zusammenarbeiten

Möchten Sie auch eine Success Story erleben?

* Benötigte Angaben

Hier zeigen wir Wirkung

Ausgewählte Success Storys

Scrum-Pilot übernimmt Prozess-Redesign fürs Neusystem

Um neuartige Transportprozesse in der Gaswirtschaft unterstützen zu können, sollte das Bestandssystem durch eine neue (Standard-)Software abgelöst werden. Das Altsystem hatte an Wartbarkeit verloren und die abgebildeten Prozesse galten als zu ineffizient. Mit dem Zweck, die tatsächlich gelebten Prozesse aus den verschiedenen Unternehmensbereichen zusammen mit den neuen Anforderungen für die Neuentwicklung mit einzubeziehen, kam als Entwicklungsansatz Scrum zum Einsatz. Eine besondere Herausforderung des Projekts war, dass der laufende Betrieb sichergestellt werden musste.

Agile Entwicklung einer ganzheitlichen Sachbearbeitung für HDI

Um eine ganzheitliche Sachbearbeitung für herausragende Kundenzufriedenheit zu ermöglichen, bedurfte es eines neuen Systems. Dieses System sollte Daten und Funktionen aus bestehenden Systemen integrieren und eine einheitliche Oberfläche bieten. Mit dieser Oberfläche sollte es dem Sachbearbeiter möglich werden, komplette Geschäftsvorfälle mit wenig Aufwand zu bearbeiten.

Scrum-Einführung bei 1&1

Zwei intern laufende Projekte mit festen Release-Terminen waren schwer vorab planbar. Die Anforderungen mehrten sich und wurden zum Teil unklar, wollte man doch auf neue Umstände schnell und angemessen reagieren. So wurde Scrum als Framework für die agile Softwareentwicklung eingeführt und weiterentwickelt.

eXtreme Programming und Scrum für die Berliner Wasserbetriebe

Eine überalterte Zählerlager-Software und die Erfassung von Wechselscheinen im SAP-System verlangten zu viel manuelles und teilweise doppeltes Zuarbeiten. Ein neues System musste her. Man entschied sich für die Kombination aus einem Standard-SAP-System und der Entwicklung eines integrierten technischen Lagerverwaltungssystems.

Scrum bei der ISIOS GmbH

Um Wissen untereinander möglichst gut zu streuen arbeiteten zwei gemischte Teams, jeweils drei Entwickler von ISIOS und it-agile, an einem großen Release. Beide Teams gingen mit verschiedenen agilen Herangehensweisen an die Arbeit. Beide Teams machten unterschiedliche Erfahrungen.

Leadership, Management und Alignment in einem wachsenden Unternehmen

Jimdo hatten sich vorgenommen, innerhalb kurzer Zeit stark zu wachsen. Wie sie dabei dennoch ihre lockere Unternehmenskultur beibehalten und zudem Transparenz, Kommunikation und Austausch innerhalb der Mitarbeitenden fördern konnten, darüber hat Arne Roock einen ausführlichen Bericht verfasst.

Erfolgreiche Scrum Einführung

Während die nativen Windfinder-Apps für iPhone, Android und Windows-Phones sich wegen der einfachen Benutzung großer Beliebtheit erfreuten, berücksichtigte die existierende mobile Webseite von Windfinder.com aktuelle Smartphones noch nicht und war auf ältere Mobiltelefone optimiert. Mit Scrum lieferte das Entwicklungsteam ein vollständig fertiggestelltes Software-Inkrement an Windfinder.com.

Grün und agil - Greenpeace Energy lernt im Leuchtturmprojekt, wie agile Produktentwicklung funktioniert

Innerhalb von acht Wochen in einem Team trotz wechselnder Besetzung mit agiler Vorgehensweise einen Produktumfang entwickeln und einen Messeauftritt vorbereiten - kein Spaziergang, aber machbar!

Mit Zusammenarbeit und Feedback-Loops zu weniger Incidents

Als große Schnittstelle zu den verschiedensten Bereichen im Unternehmen wollte das Support-Team an Vertrauen gewinnen und eine größere Zufriedenheit bei den Märkten erreichen. Man entschied sich dafür, eine transparente und feedbackorientierte Zusammenarbeit zwischen den Schnittstellen im Support-Team und den Fachbereichen zu etablieren. So konnte die Anzahl an Incidents gesenkt und das volle Potenzial des Support-Teams als fachübergreifendes Bindeglied erkannt werden.

it-agile Newsletter

Sichern Sie sich monatlich Neuigkeiten, Inspiration und Tipps zu agiler Arbeit, Konferenzen, aktuelle Termine und vieles mehr.

Zur Anmeldung