Inhalte
Wie Stammdaten mit jeder Nutzung besser werden – und warum „mehr sichtbare Probleme“ ein gutes Zeichen ist.
TL;DR
In der operativen Planung/Steuerung entscheidet Stammdatenqualität über Machbarkeit, Termine, Ressourcen und Kosten.
In diesem Case haben wir SAP ISI (führendes ERP) und DFS (operative Planung/Steuerung) so verbunden, dass eine Single operational truth je Vorgang entsteht – und ein Datenqualitäts-Feedbackloop (INQA Dashboard/Board/Assistent) die Produktstammdaten in SAP ISI schrittweise aufwertet, damit sie in Planung und Steuerung besser nutzbar werden.
Setup‑Scope
Das Setup wurde vorerst für zwei Instandhaltungswerke der FZI aufgebaut. Parallel wurde es so gestaltet, dass es rollout‑fähig ist – perspektivisch auch für weitere Geschäftsfelder wie DB Regio und DB Cargo.
Ausgangslage: Wenn Planung nach Bauchgefühl riecht, sind Daten meist der Grund
Wer schon mal in einem Werk, einer Werkstatt oder einer stark getakteten Operative gearbeitet hat, kennt das Muster:
- Das Tagesgeschäft drückt. Pflege wird „später“ gemacht.
- Standards sind nicht wirklich klar – oder sie sind klar, aber werden im Stress anders gelebt.
- Rückkopplung fehlt: Fehler zeigen sich erst, wenn es kracht (Konflikt in der Planung, Abbruch in der Ausführung, hektische Umplanung).
- Und dann passiert das, was Organisationen fast automatisch tun: Selbstschutz durch Workarounds. Excel-Listen, Zurufe, Nebenwege. Kurzfristig hilfreich – langfristig teuer.
Das Ergebnis ist nicht „schlechte Menschen machen schlechte Daten“, sondern:
Daten entstehen entlang realer Arbeit. Wenn es keinen stabilen Qualitätsrahmen gibt, werden sie zwangsläufig widersprüchlich, unvollständig oder veraltet.
Der Knackpunkt: Stammdatenqualität ist kein Projekt – sie ist ein Feedbackloop
Der häufigste Denkfehler: „Wir machen jetzt mal Datenqualität und dann ist das Thema erledigt.“
In der Realität ist Stammdatenarbeit operativ mitlaufend.
Jede Änderung, jede Rückmeldung, jede Ausführung ist ein Moment, in dem Daten besser werden könnten – oder eben schlechter.
Darum war das Ziel nicht: ein neues Regelwerk.
Sondern: ein lernender Loop, der Datenqualität sichtbar, priorisierbar und bearbeitbar macht – direkt im Arbeitsfluss.
Zielbild: Daten als Wertschöpfung – nicht als Dokumentation
Das Zielbild war erstaunlich simpel formuliert:
Jede Eingabe/Änderung verbessert die Datenbasis messbar – statt sie nur „zu nutzen“.
Konkret bedeutet das:
- Planung und Steuerung werden kontinuierlich solider, weil Daten nicht „liegen bleiben“.
- DFS kann mehr automatisieren, weil Konflikte früher erkannt und Regeln stabiler werden.
- SAP ISI und DFS bleiben konsistent, statt auseinanderzulaufen.
Was wir gebaut haben
1) System- und Datenfluss-Architektur: „Single operational truth“ je Vorgang
DFS macht operative Planung/Steuerung. SAP ISI bleibt ERP und bildet die Klammer.
Entscheidend war die saubere Übergabe:
- geplante und befundete Arbeiten inkl. Echtzeit-Arbeitsständen
- Synchronisation bis auf Vorgangsebene
- klare Wahrheit pro Vorgang: wer weiß was – und wann?
Das klingt technisch – ist aber vor allem organisatorisch. Denn „wahr“ ist nicht nur eine Frage von Schnittstellen, sondern von Verantwortung.
2) INQA Toolset: Qualität sichtbar machen, damit sie steuerbar wird
INQA Dashboard (DB 360)
Macht Schwachstellen, Muster und Hotspots sichtbar. Nicht als Reporting-Spielzeug, sondern als Steuerungsinstrument:
Wo brennt es wirklich? Was ist nur Rauschen? Was wiederholt sich?
INQA Board
Hier wird aus Erkenntnis Arbeit: Hotspots werden priorisiert – als Backlog.
Wichtig: nicht „alles auf einmal“, sondern das, was operativ den größten Hebel hat.
INQA Assistent (KI-gestützt)
Der Assistent liefert Vorschläge für Stammdatenpflege – basierend auf einem wachsenden Katalog aus Regeln, Heuristiken und Erfahrungswissen.
Das Entscheidende: Board ↔ Assistent sind gekoppelt.
Aus Hotspots werden Vorschläge. Aus Bearbeitung wird Lernen.
So wird Qualität nicht „kontrolliert“, sondern verbessert.
3) Operative Automatisierung in DFS: weniger Last, mehr Flow
Zwei Dinge haben besonders stark gewirkt:
- Konfliktprüfung auf Vorgangsebene: Widersprüche und Unplausibilitäten werden früh sichtbar.
- Teilautomatische Reihung von Plan- und Aplan-Anteilen: mehr Durchsatz, weniger Dispo-Last, weniger Fehlplanung.
Der Effekt ist wie bei einem guten Navigationssystem:
Es fährt nicht das Auto – aber es verhindert, dass alle gleichzeitig in die Sackgasse abbiegen.
4) Datenqualitäts-Feedbackloop: Lernen aus Nutzung (und Aufwertung in SAP ISI)
Damit DQM nicht „nur“ ein Dashboard bleibt, muss der Loop geschlossen werden: Erkenntnisse müssen zurück in die Stammdatenpflege – und zwar so, dass es im Arbeitsfluss funktioniert.
Hier war entscheidend:
- Konflikte und Auffälligkeiten werden in DFS sichtbar (operativer Schmerzpunkt)
- Hotspots werden priorisiert (Board)
- Vorschläge werden erstellt (Assistent)
- Änderungen werden in SAP ISI zurückgeschrieben (Stammdaten-Aufwertung)
Damit entsteht ein Kreislauf: Nutzung → Feedback → Verbesserung → bessere Nutzung.
Der Weg dahin: OKR + Scrum als Betriebsmodus
Wir haben zwei Dinge konsequent zusammengebracht:
- OKR-Klarheit (Wirkung zuerst, nicht Aktivität)
- Scrum-Rhythmus (klein starten, schnell lernen, stabil liefern)
OKR: Was soll am Ende anders sein?
Objective:
Der Auftragsservice (operative Planung) erkennt Engpässe in der Instandhaltungsplanung, bevor sie entstehen.
Key Results (praxisnah formuliert):
- Automatische Konfliktprüfung auf Vorgangsebene weist Anwendende früh auf Engpässe bei Infrastruktur und Qualifikation hin (Wo kann die Arbeit stattfinden? Wer darf sie wann ausführen?).
- Der Automatisierungsgrad bei der Plan/Aplan-Reihung steigt (mit klaren Leitplanken, damit es im dynamischen Umfeld nicht „blind automatisiert“).
- Datenqualität wird für alle Stakeholder transparent messbar: Vollständigkeit, Aktualität, Konsistenz, Eindeutigkeit.
- Der Assistent generiert Vorschläge zur Stammdatenpflege über Machine Learning aus überarbeiteten Datensätzen, sodass sich die künftige Überarbeitungszeit spürbar reduziert (Richtwert: halbiert).
Scrum: Wie kommen wir dahin, ohne den Betrieb zu überfahren?
- Start mit einem spitzen Anwendungsfall: Werk + Prozessmoment (Planung & Steuerung schwerer Instandhaltung) + Datenobjekt (Arbeitspläne)
- 3‑wöchiger Rhythmus: Transparenz → Priorisierung → Umsetzung → Review
- Reviews als Wirkungscheck: Was hat geholfen? Was war nur Aktivität?
Kurz gesagt:
Wir liefern nicht „DQM“, wir liefern Verbesserungen im Arbeitsfluss – messbar und für die Operative spürbar. ✅ Wir liefern nicht „DQM“, wir liefern Verbesserungen im Arbeitsfluss. ✅
Operating Model: Ownership, die trägt (ohne Bürokratie)
Damit es skaliert, braucht es dezentrale Verantwortung – aber mit Leitplanken.
- Data Owner je Geschäftsfeld, als Wirkungseinheit über jeweils 2 Standorte
- Befähigung in den INQA Tools: eigenständig Hotspots priorisieren und verbessern
- Keine zentrale Datenpolizei – sondern Selbstorganisation mit Transparenz und klarer Messlogik
Routinen, die sich bewährt haben:
- wöchentlich: Board‑Triage (Top‑Hotspots → nächste Arbeit)
- zweiwöchentlich: Review (Wirkung + Lernschritte)
- monatlich: DQ‑Health‑Check (Trends, neue Muster, Governance‑Entscheidungen)
Skalierung: erst stabilisieren, dann ausrollen
Im Pilot wurde bewusst fokussiert gearbeitet (zwei FZI‑Instandhaltungswerke), um Wirksamkeit schnell zu stabilisieren. Gleichzeitig wurde die Lösung so aufgesetzt, dass sie für den Rollout vorbereitet ist – auch für weitere Geschäftsfelder wie DB Regio und DB Cargo.
Als Blaupause wurden Referenzstandorte genutzt (z.B. Dessau & Nürnberg).
Das Prinzip: erst Wirksamkeit stabilisieren (Toolset + Rollen + Loop), dann skalieren – z.B. auf weitere Standorte/Geschäftsfelder.
Das klingt langsam, ist aber in Wahrheit schneller, weil es Rework vermeidet.
Was sich verändert hat (die „spürbaren“ Effekte)
Was die Konflikte typischerweise auslöst
In diesem Setup kamen Konflikte vor allem aus zwei Quellen:
- Engpass Infrastruktur: Wo werden die Arbeiten verrichtet – und welche technische Ausstattung ist verfügbar?
- Engpass Qualifikation: Wer darf welche Arbeit wann ausführen?
Zentrale KPI: WAZ (Werkstattaufenthaltszeit)
Die Durchlaufzeit wurde über die WAZ betrachtet. Ziel war weniger „kürzer um jeden Preis“, sondern verlässlicher – damit angrenzende Stakeholder (z.B. Einsatz-/Betriebsplanung) stabil darauf aufbauen können, wann ein Fahrzeug wieder verfügbar ist.
Automatisierung – bewusst mit Augenmaß
Die Domäne ist hoch komplex und dynamisch. Deshalb wurde Automatisierung nicht als Selbstzweck verstanden, sondern als Assistenz:
- Frühzeitiger Check in der Operative, ob eine Planung auf Konflikte läuft
- Unterstützung bei der Produktstammdatenpflege: Zuordnung von Abhängigkeiten (benötigte Infrastruktur/technische Ausstattung und Qualifikation je Arbeit)
Je nach Umfeld zeigen sich die Effekte in zwei Ebenen:
1) Messbar
- weniger Konflikte durch Vorgangs-Konfliktprüfung
- mehr Automatisierung durch Plan/Aplan-Reihung
- Hotspots sind transparent (statt Bauchgefühl)
- Assistent-Vorschläge werden treffsicherer, Nacharbeit sinkt
- ein nachweisbarer Lernzyklus: Feedback → Regeln → bessere Daten → bessere Steuerung
2) Spürbar
- weniger „Überraschungen“ im Betrieb
- weniger Abstimmungschaos
- mehr Ruhe in der Planung
- mehr Fokus auf echte Engpässe statt auf Symptome
Ein ehrlicher Moment: Am Anfang wurden es „mehr Probleme“ 😄
Ein schöner Nebeneffekt (und manchmal ein kleiner Schock):
Sobald das Dashboard sauber zeigt, was los ist, wirken Themen zunächst größer.
Das ist kein Rückschritt.
Das ist das erste Mal, dass das System die Wahrheit sagt – und damit wird sie bearbeitbar.
Oder anders:
Was sichtbar wird, kann priorisiert werden. Was priorisiert wird, kann verbessert werden.
Stimme aus der Operative
„Durch das Setup brauche ich die Excel-Lösungen nicht mehr – denn ich kann schon weit im Voraus (bis zu 18 Monate) aus dem führenden System die Arbeitspläne in das operative Tool (DFS) übernehmen und entlang dieser die Kapazitäten verplanen. Das war vorher nicht möglich: wir hatten maximal wenige Wochen Vorlauf – und das auch immer nur als Blitzlicht, weil nach der Planung im nächsten Moment die Excel-Tabellen schon wieder obsolet waren. Auch die Abstimmung mit der Vielzahl der Kolleginnen und Kollegen aus der Fertigung war höchst aufwendig.“
So könnt ihr starten
Wenn ihr eine ähnliche Situation habt, funktioniert dieser Einstieg fast immer:
- Quickscan (90 Minuten): Systemfluss + 1–2 Hotspots + Ownership klären
- Pilot spitz schneiden: ein Datenobjekt, ein Prozessmoment, eine Rolle, ein Standort‑Paar
- 4 Wochen liefern: Dashboard → Board → erste Regeln/Vorschläge → Review → nächste Iteration
Ergebnis: ein „kleiner“ Start, der schon nach kurzer Zeit sichtbare Wirkung erzeugt.
Vorgehen als Agile Coach
Drei Eckpunkte haben den Unterschied gemacht:
- Raum für ein Hochleistungsteam schaffen Ein theoretisches Konstrukt (Datenstrategie) wurde mit einem greifbaren Praxisanwendungsfall verbunden, der spürbaren Mehrwert in der Operative erzeugt.
- Ein cross-funktionales Team fasilitieren Beteiligte aus Operative, Governance sowie Technik/IT wurden so zusammengebracht, dass ein gemeinsames Verständnis entsteht – und der Datenqualitäts-Feedbackloop tragfähig umgesetzt werden kann.
- Vision skizzieren, die anschlussfähig bleibt Das Setup wurde als Pilot wirksam (zwei FZI-Instandhaltungswerke) und gleichzeitig so aufgesetzt, dass es für den Rollout in weitere Geschäftsfelder anschlussfähig ist (u.a. DB Regio und DB Cargo).