Der Service funktionierte. Nur nicht als System.
Ein Störfall. Vier Abteilungen. Drei Systeme. Und ein Kunde, der eigentlich nur wissen wollte: Wann läuft meine Anlage wieder?
Für einen deutschen Hersteller automatisierter Verpackungs- und Förderanlagen haben wir den technischen Kundendienst nicht einfach digitalisiert. Wir haben ihn als zusammenhängendes Service-System neu gebaut – von der ersten Meldung bis zum abgeschlossenen Einsatz.
So sieht ein Systemproblem aus, wenn es sich als Alltag tarnt.
Keiner der Beteiligten arbeitete schlecht. Vertrieb, Serviceleitung, Disposition, Techniker und Ersatzteillager hatten jeweils ihre eigene Aufgabe im Griff. Das Problem entstand dazwischen.
Beim Kunden zählt jede Minute. Intern startet gleichzeitig die Suche nach Zuständigkeit, Vertrag, Fehlerbild und Verfügbarkeit.
Vertrieb kennt den Kunden. Disposition kennt die Ressourcen. Beide optimieren sinnvoll – nur nicht gegen dieselbe Entscheidungslogik.
Nicht zu wenige Techniker. Nicht die Software. Sondern fehlende gemeinsame Regeln zwischen Kundenversprechen, Dringlichkeit, Qualifikation, Weg, Teil und Kapazität.
Bis dahin liefen Telefonate, Rückfragen, ERP-Suche, CRM-Notizen und eine private Excel-Liste parallel.
Alles war digital. Nur nicht miteinander.
Das bestehende Setup hatte kein offensichtliches „kaputtes“ System. Es hatte mehrere funktionierende Systeme, zwischen denen Menschen permanent übersetzten.
- Kundewartet auf eine Zusage
- Dispositionsucht freie Ressourcen
- ERPkennt Auftrag und Vertrag
- Ersatzteileliegen im eigenen System
- Technikkennt das Fehlerbild
Die Informationen sind vorhanden. Ihre Verbindung entsteht erst durch Rückfragen.
Wir haben nicht gefragt, welches Tool fehlt.
Zuerst musste klar werden, warum vernünftige Menschen mit vernünftigen Systemen trotzdem immer wieder unnötig komplizierte Arbeit erzeugen. Genau hier greifen die fünf IDEACTORY-Perspektiven ineinander.
Beobachtung der realen Arbeit, nicht der Sollbeschreibung.
End-to-End vom Kundenanruf bis zum Abschluss.
Entscheidungsrechte, Prioritäten und Eskalationen.
Informationsarchitektur für eine echte Stresssituation.
ERP, CRM, Lager und Disposition verbinden statt ersetzen.
Aus fünf Sichtweisen wurde eine gemeinsame Service-Logik.
Ein Vorgang. Eine Logik.
Der neue Prozess startet nicht in einer Abteilung, sondern beim Kundenereignis – und endet erst, wenn die technische und kaufmännische Arbeit abgeschlossen ist.
Die Entscheidung bekommt eine Oberfläche.
Nicht noch ein System. Eine Arbeitsoberfläche, die vorhandene Daten dort zusammenführt, wo entschieden wird.
Nicht ein Tool. Ein funktionierendes Zusammenspiel.
Service Operating Model
End-to-End-Prozess, Rollen, Entscheidungspunkte, Eskalationen und klare Übergaben.
Priorisierungsmatrix
Dringlichkeit entsteht aus Kundenwirkung, SLA, Technik, Qualifikation, Weg und Teilelage.
Service-Cockpit
Ein Arbeitsbild für Disposition und Serviceleitung statt fünf paralleler Informationsquellen.
Systemschicht
CRM, ERP, Lagerbestand und Disposition liefern Daten in denselben Vorgang.
Techniker-Flow
Mobile Einsatzinformation, Dokumentation und Rückmeldung ohne Medienbruch zurück in den Fall.
Service-Dashboard
Offene Fälle, SLA-Risiken, First-Time-Fix und Engpässe werden steuerbar statt nachträglich berichtet.
Dann wurde gebaut.
Die kreative Phase war vorbei. Ab hier zählte, ob der neue Service unter echten Bedingungen funktioniert.
Prozesslogik, Cockpit und Schnittstellen zunächst für eine Pilotregion.
Keine Großmigration. Die vorhandene IT blieb – die fehlende Verbindung wurde gebaut.
Störfälle, geplante Einsätze, fehlende Teile und Ausnahmen liefen durch denselben Pilot.
Regeln, Interface und Verantwortungen wurden gemeinsam ausgerollt und nachgeschärft.
Die Zahlen waren gut. Die Ruhe im Raum war besser.
Median vom Eingang bis zur belastbaren ersten Kundenzusage.
Telefonate und Statusnachfragen zwischen beteiligten Bereichen.
Pilotregion während der ersten zehn Wochen.
Fälle mit geklärter Ersatzteillage vor der finalen Disposition.
„Früher habe ich für einen dringenden Fall drei Leute angerufen, bevor ich überhaupt planen konnte. Heute sehe ich zuerst, was ich wissen muss.“Miriam* · Disposition
„Das Beste ist nicht die App. Das Beste ist, dass der Kunde nicht mehr drei verschiedene Antworten von uns bekommt.“Thomas* · Serviceleitung
„Wenn ich losfahre, weiß ich jetzt häufiger schon, ob das Teil wirklich da ist. Klingt banal. Ist es nicht.“Timo* · Servicetechnik
* Namen der zitierten Personen geändert.
Ein Service. Von der Meldung bis zum Einsatz.
Aus Einzelwissen wird eine gemeinsame Entscheidung.
- KundeMeldung und Vertrag
- ERPAuftrag und Anlagenbestand
- ErsatzteileBestand und Verfügbarkeit
- TechnikFehlerbild und Aufwand
Service-Cockpit
Ein Fall verbindet Kundenereignis, Priorität, Teilelage und verfügbare Ressourcen.
- DispositionEinsatz und Ressourcen
- ServicetechnikVorbereiteter Auftrag
- KundeBelastbare Zusage
- 01Meldung qualifizieren
- 02Priorität entscheiden
- 03Einsatz vorbereiten
- 04Rückmeldung verbinden
Wenn drei Systeme alles wissen und trotzdem jemand telefonieren muss, ist der Prozess noch nicht fertig.
Genau dort wird es für IDEACTORY interessant: an den Stellen, an denen Menschen, Abläufe, Struktur, Technologie und Gestaltung gemeinsam eine bessere Antwort brauchen.