Wenn Unternehmen über Daten sprechen, sagen sie oft das Richtige: «Wir brauchen mehr Transparenz.» «Wir müssen schneller reagieren.» «Wir wollen bessere Forecasts.»
Und dann passiert etwas Typisches: Es entsteht eine Liste mit 20–50 Use Cases. Alles klingt plausibel. Nichts bewegt sich.
Der Grund ist selten fehlender Wille. Es ist meistens fehlende Entscheidungslogik. Ein Use Case ist nicht «ein Dashboard». Ein Use Case ist eine wiederkehrende Entscheidung, die heute zu langsam, zu unsicher oder zu teuer getroffen wird. Data-driven Decision Making beginnt genau dort: Welche Entscheidung wird künftig datenbasiert getroffen – und was ändert sich dadurch im Betrieb?
Damit Sie nicht im Post-it-Chaos landen, kommt hier ein praxistauglicher Ansatz: vier Branchen-Use Cases, jeweils mit dem, was in der Realität zählt:
- Welche Entscheidung wird besser?
- Welche Daten braucht es wirklich?
- Welche KPIs zeigen Wirkung?
- Welche Fallen killen Adoption und Vertrauen?
Wie Sie Use Cases auswählen, die nicht nach dem Pilot sterben
Bevor wir in Branchen gehen, ein kurzer Realitätscheck: Use Cases scheitern fast immer an einem von drei Punkten:
- Impact bleibt vage.
«Mehr Transparenz» ist kein Outcome. «Weniger Stillstandstunden pro Woche» ist ein Outcome. - Daten sind vorhanden, aber nicht betrieblich.
Eine Demo klappt, weil man Daten manuell zusammenzieht. Im Betrieb bricht es, weil Quellen wechseln, Definitionen fehlen, Qualität schwankt. - Adoption wird unterschätzt.
Ein Report ersetzt keine Entscheidung. Er muss in eine Routine passen (Meeting, Trigger, Verantwortungen, Massnahmen).
Ein einfacher Auswahlrahmen hilft: Bewerten Sie jeden Use Case entlang von drei Achsen:
- Wirkung: Wie hoch ist der Nutzen, wie häufig tritt die Entscheidung auf?
- Machbarkeit: Sind Datenquellen erreichbar, Definitionen klärbar, Owner benennbar?
- Adoption: Gibt es einen klaren Ort im Betrieb, an dem die Erkenntnis zur Massnahme wird?
Wenn eine Achse fehlt, wird es teuer – nicht technisch, sondern organisatorisch.
Branchen-use cases
OEE/Stillstände so steuern, dass es nicht bei «Erklären» bleibt
Die Entscheidung, um die es wirklich geht: In vielen Industrien wird OEE oder Stillstand «gemessen» – aber nicht konsequent «gesteuert». Der entscheidende Frage lautet:
Welche konkreten Störungsursachen priorisieren wir nächste Woche – und welche Massnahmen setzen wir an welcher Linie um?
Das ist Data-driven Decision Making: Nicht «wir sehen Stillstand», sondern «wir entscheiden über Massnahmen aufgrund konsistenter Ursachenlogik».
Daten, die Sie brauchen (und die oft getrennt liegen)
- Maschinen-/Sensorikdaten (Zustände, Takte, Alarme)
- Störgrund-Codes aus MES/Shopfloor-Systemen
- Schicht-/Auftragsdaten (Welche Produkte liefen wann?)
- Qualitätsdaten (Ausschuss, Nacharbeit, Reklamationen)
- Wartungsdaten (wann wurde was gemacht, welche Teile, welche Intervalle)
KPIs, die im Betrieb funktionieren
- Stillstandminuten je Linie/Schicht/Produktgruppe
- Top-3 Störgründe je Woche (mit Trend, nicht nur Status)
- MTBF/MTTR (wenn vorhanden)
- Ausschussquote nach Störgrund-Klassen (zeigt, ob es nur «Stopp» oder auch «Qualität» ist)
- «Time-to-Decision»: wie schnell wird aus Störung eine Massnahme?
Typische Fallen (und wie Sie sie vermeiden)
- Störgrund-Codes sind Müll.
Wenn Codes inkonsistent sind, wird jede Analyse zur Meinungsfrage. Lösung: wenige, klare Klassen + Stewardship (nicht 200 Codes). - Zeiten stimmen nicht (Schicht, Zeitzone, Maschinenclock).
Ohne sauberen Zeitbezug stimmen Korrelationen nicht. Lösung: Zeitsynchronisation + klare Periodenlogik. - Es wird nur berichtet, nicht entschieden.
Wenn das Ergebnis nicht in ein wöchentliches Shopfloor-Review mit Massnahmenliste fliesst, ist es BI, nicht Decision Making.
Warum dieser Use Case oft schnell zieht:
Weil er eine klar wiederkehrende Routine hat (Shopfloor/Produktionsmeeting) und der Effekt messbar wird, ohne dass Sie «alles» integrieren müssen.
Projektcontrolling, das nicht erst am Monatsende merkt, dass es kippt
Die Entscheidung, um die es wirklich geht: Im Bau scheitert Steuerung oft nicht an fehlenden Daten, sondern an verspäteten Signalen. Die entscheidende Frage lautet:
Welche Projekte kippen (Kosten, Termin, Nachträge) – und welche Massnahmen greifen wir diese Woche?
Data-driven Decision Making heisst hier: Früher entscheiden, bevor Abweichungen irreversibel werden.
Daten, die Sie brauchen (und die oft über Tools verteilt sind)
- Projektstruktur (WBS/Leistungspositionen, Gewerke, Phasen)
- Kalkulation vs. Ist-Kosten (ERP/Finanzsystem, Projekttool)
- Fortschritt (Mengen, Meilensteine, Bautagebuch)
- Lieferstatus/Material (Bestellungen, Liefertermine, Lager/Logistik)
- Nachträge/Claims (inkl. Status, Ursache, Durchlaufzeit)
- Optional: Ressourcen (Subunternehmer, Verfügbarkeit, Geräte)
KPIs, die im Bau wirklich hilfreich sind
- Earned Value/Abweichungstrend (vereinfacht, wenn EVM zu komplex ist)
- Cost-to-Complete vs. Budget (Trend)
- Terminabweichung in Tagen je kritischem Pfadabschnitt
- Nachtragsdurchlaufzeit (von Erkennung bis Freigabe)
- «Störungssignale»: Material fehlt, Planrevisionen, Subunternehmer-Ausfälle
Typische Fallen
- Fortschritt ist nicht objektiv.
Wenn Fortschritt nur «gefühlte Prozent» sind, wird Steuerung politisch. Lösung: Mengenbasierte Fortschrittslogik, wo möglich. - Nachträge sind getrennt von Ursachen.
Ohne Ursachenklassifikation lernen Sie nicht. Lösung: einfache Kategorien (Planung, Ausführung, Lieferant, Wetter, Kunde). - Reporting ohne Entscheidungsroutine.
Das Projektboard muss Massnahmen und Verantwortungen definieren, sonst bleibt es Statusshow.
Warum dieser Use Case oft schnell zieht:
Weil Bauprojekte starke Routinen haben (zum Beispiel Jour fixe oder Baustellenbesprechungen). Wenn die Daten dort konsistent sind, können Entscheidungen schneller und weniger emotional getroffen werden.
Promotion- und Bestandssteuerung ohne «Rabatt-Reflex»
Die Entscheidung, um die es wirklich geht und die im Handel oft zu den teuersten gehört: Welche Promotion machen wir, wo, zu welchem Preis – und was tun wir, wenn Bestand und Nachfrage nicht zusammenpassen?
Viele Promotionen wirken «gefühlt», aber nicht messbar – weil Daten getrennt sind. Data-driven Decision Making bedeutet hier: Promotionen nicht nach Bauchgefühl, sondern nach Nettoeffekt steuern.
Daten, die Sie brauchen
- Abverkauf POS + Online (täglich, idealerweise intraday)
- Preis-/Promotionskalender (Start/Ende, Mechanik, Kanal)
- Bestand (Filiale, Zentrallager, in Transit)
- Retouren (vor allem online)
- Produktstammdaten (Kategorie, Attribute, Varianten)
- Optional: Wetter/Region, Wettbewerbsindikatoren (falls vorhanden)
KPIs, die wirklich die Wahrheit sagen
- Uplift vs. Baseline (vorher/nachher, saisonal bereinigt, so weit möglich)
- Marge nach Promotion (nicht nur Umsatz)
- Abschriften/Markdowns nach Promotion
- Out-of-Stock-Rate während Promotion (zeigt, ob Sie Umsatz verschenken)
- Retourenquote nach Promotion/Produktgruppe (zeigt Nebenwirkungen)
Typische Fallen
- Baseline fehlt
Ohne Vergleichslogik sieht jede Aktion «gut» aus. Lösung: einfache Baseline-Regel (historisch, vergleichbare Wochen) und konsequent anwenden. - Kanalbrüche verzerren
Wenn Online und Filiale getrennt sind, sehen Sie keine echten Effekte. Lösung: einheitliches Produkt-/Kundenmodell (mindestens Golden Record für Produkte). - Preis- und Bestandsteuerung sind getrennt
Promotion ohne Bestand ist Lottospiel. Lösung: Promotions nur dort, wo Supply mitgedacht ist.
Warum dieser Use Case oft schnell zieht:
Weil Sie die Wirkung sehr schnell sehen – wenn Daten zusammenlaufen. Und weil die Entscheidung (Promotion ja/nein, Mechanik, Filialcluster) klar ist.
Chargen- und Qualitätsentscheidungen, die auditierbar sind
Die Entscheidung, um die es wirklich geht: In regulierten Umfeldern geht es nicht nur um Effizienz, sondern um Nachweisbarkeit. Die Kernfrage lautet:
Welche Charge ist betroffen, welche Massnahme ist notwendig, und wie belegen wir die Entscheidung?
Data-driven Decision Making heisst hier: Qualität und Compliance werden nicht durch manuelle Recherche «gerettet», sondern durch verknüpfte Datenflüsse.
Daten, die Sie brauchen
- Chargen-/Lot-Daten entlang der Prozesskette
- Qualitätsdaten (Labor, Inline-Messungen, Abweichungen)
- Prozessparameter (Batch Records, MES, Produktionssysteme)
- Freigabe-/Abweichungsworkflow (Status, Ursachen, CAPA)
- Lieferkette (Rohstoffe, Lieferanten, Transport)
KPIs, die im Alltag helfen
- Zeit bis zur Ursachenklärung (Deviation-to-Root-Cause)
- Wiederholte Abweichungen nach Ursache/Anlage
- Ausschuss / Rework pro Charge/Produktlinie
- Audit-Nachweiszeit (wie schnell können Sie Herkunft/Lineage zeigen?)
Typische Fallen
- Daten sind da, aber nicht verknüpft.
Ohne konsistente IDs (Charge, Material, Anlage) bleibt es Recherche. Lösung: Identitätslogik und Mapping sauber definieren. - Abweichungen werden nicht klassifiziert.
Dann gibt es keine Lernkurve. Lösung: wenige Kategorien, konsequent gepflegt. - Compliance wird als reines Dokumententhema gesehen.
In Wahrheit ist es Prozess- und Datenbetrieb.
Warum dieser Use Case oft schnell zieht:
Weil der Nutzen nicht nur «Effizienz» ist, sondern Risiko- und Audit-Entlastung – und weil die Entscheidungskette klar dokumentierbar sein muss.
der 90-Tage-Start: vom use case zum betrieb
Um zu vermeiden, dass der Artikel zur Roadmap-Werbung wird, hier nur die Essenz: Wert entsteht, wenn Sie einen Use Case so gestalten, dass er betrieblich genutzt werden kann.
Tag 1-30
- Entscheidung und KPI-Definitionen klären
- Datenquellen realistisch prüfen
- Ownership festlegen
Tag 31-60
- Datenfluss automatisieren (1-2 Kernquellen)
- erstes nutzbares Modell/Report
- Qualitätschecks
Mehr nicht. Der entscheidende Punkt ist: Use Case = Entscheidung + Routine + Datenbasis, nicht «Dashboard».
Was Sie explizit nicht tun sollten
- Nicht mit 10 Use Cases parallel starten. Sie verlieren Adoption und Governance.
- Nicht «Datenplattform zuerst» bauen, wenn die Entscheidung noch unklar ist.
- Nicht Wirkung behaupten, ohne Baseline und Messlogik.
