Kundensonder-Kaskaden-Erkennung

Das echte Ausmaß des Problems

Sonderanforderungen von Kunden sind keine Ausnahme mehr — sie sind der Alltag. Eine Analyse der Unternehmensberatung TCW GmbH im Sondermaschinenbau zeigt: In Unternehmen mit hohem Anteil an projektbasierten und kundenindividuellen Aufträgen liegt das Optimierungspotenzial allein durch bessere Auftragsabwicklung bei bis zu 14 Prozent des Gesamtumsatzes — gebunden in Prozessineffizienzen, die niemand aktiv verfolgt.

Noch drastischer formulieren es Tacton Systems in ihrer Analyse für produzierende Unternehmen (2024): Zwischen Angebotsstellung und Lieferung verlieren Hersteller im Durchschnitt bis zu 80 Prozent ihrer kalkulierten Marge. Ein Auftrag, der mit 25 Prozent Rohertrag abgeschlossen wurde, landet nach Konstruktionsänderungen, Lieferverzögerungen und Sonderbeschaffung oft bei 3 Prozent — wenn es gut läuft.

Das Problem dabei: Keine der beteiligten Abteilungen sieht das Gesamtbild. Beschaffung bucht den Zusatzaufwand für den Sonderlieferanten. Arbeitsvorbereitung verbringt Zeit mit der Planänderung. Vertrieb behält den Originalrabatt. Und alle arbeiten am gleichen Kunden — ohne dass irgendjemand die Summe zieht.

Was besonders schwer zu erkennen ist: Nicht jeder Sonderwunsch ist ein Problem. Manche Kunden zahlen mehr für Individualisierung und rechtfertigen den Aufwand vollständig. Die gefährliche Gruppe sind die Kaskadenkunden — Kunden, bei denen ein einziger Sonderwunsch systematisch eine Kette von Folgeaufwänden auslöst, ohne dass das Pricing das abbildet.

Typische Kaskade:

1. Kunde fordert eine Materialvariante, die nicht auf Lager ist → Sonderbeschaffung (2–5 Tage Vorlauf, Mindestabnahmemenge)
2. Sonderbeschaffung verzögert den Auftrag → Produktionsplan muss umgebaut werden → Folgeaufträge rutschen
3. Umbau löst Überstunden aus oder verdrängt einen Standard-Auftrag
4. Vertrieb gewährt „Goodwill-Rabatt” wegen der Verzögerung → Preiskorrektur nach unten
5. Beim nächsten Angebot für diesen Kunden: die Originalpreisbasis wird wieder verwendet — und der Kreislauf beginnt von vorn

Erfahrungsgemäß haben produzierende Unternehmen mit 200–800 aktiven Kunden 3–8 Prozent der Kunden, die mehr als 30 Prozent aller operativen Ausnahmen produzieren. Das ist keine exakte Studie, aber eine Beobachtung, die sich quer durch Branchen zieht — und die jeder Ops-Leiter im mittelständischen Fertigungsbetrieb sofort wiedererkennt.

Mit vs. ohne KI — ein ehrlicher Vergleich

Das Ziel ist nicht, Sonderwünsche abzulehnen. Das Ziel ist, sie zu kennen und zu bepreisen.

Einschätzung auf einen Blick

Zeitersparnis — mittel (3/5) Die Zeitersparnis entsteht hauptsächlich beim Ops-Team und in der Arbeitsvorbereitung: weniger Eskalationskonferenzen, weniger manuelle Recherche, wenn es wieder einmal um Nordtec geht. In der Praxis sind das 2–4 Stunden pro Woche für ein Ops-Team mit 5–10 Personen — real, aber nicht die Hauptmotivation für das Projekt. Andere Anwendungsfälle wie automatisierte Berichterstellung sparen mehr Zeit schneller. Hier ist der Zeithebel eher indirekt: weniger Feuerwehreinsätze insgesamt.

Kosteneinsparung — hoch (4/5) Hier liegt der eigentliche Hebel. Wenn du weißt, welche Kunden systematisch Mehraufwand produzieren, hast du drei Handlungsoptionen: Pricing korrigieren, Sonderwunsch-Protokoll einführen (Aufwand wird vorab bestätigt), oder Gespräch mit dem Kunden über die Beziehungsstruktur. Jede dieser Maßnahmen schützt Marge — und Tacton-Daten zeigen, dass in typischen Fertigungsunternehmen zwischen Angebot und Lieferung bis zu 80 Prozent der kalkulierten Marge verloren gehen kann. Selbst wenn man nur einen Teil der identifizierten Kaskadenkunden korrekt repriced, ist der Hebel erheblich.

Schnelle Umsetzung — niedrig (2/5) Das ist der ehrliche Teil: Diese Lösung braucht strukturierte Daten aus dem ERP — Auftrags-Events mit Zeitstempeln, Ausnahme-Buchungen, Sonderbeschaffungsvorgänge, Preiskorrekturen je Auftrag. Nicht jedes ERP liefert diese Daten in einer Form, die sofort analysierbar ist. In der Praxis vergehen 8–14 Wochen bis zum ersten Pilotbetrieb, wenn die Datenaufbereitung nicht trivial ist. Das ist kein Argument dagegen — aber ein ehrliches Bild des Einstiegsaufwands.

ROI-Sicherheit — hoch (4/5) Was diese Lösung von vielen anderen KI-Projekten unterscheidet: Der Nutzen ist direkt messbar. Du kannst vor und nach der Intervention die Marge auf identifizierten Kaskadenkunden vergleichen. Du kannst zählen, wie viele Sonderbeschaffungen auf diesen Kunden entfallen. Das ist keine indirekte Effektschätzung — es ist ein konkretes Vorher-Nachher auf einem abgrenzbaren Kundensegment.

Skalierbarkeit — mittel (3/5) Der Wert dieser Lösung ist je Kaskadenkunde begrenzt — nicht je Auftragslinie. Wenn du 200 aktive Kunden hast, profitierst du von einer Identifikation von vielleicht 8–15 Problemkunden. Mit 2.000 Kunden sind es 60–150. Das skaliert linear mit der Kundenbasis, aber nicht überproportional. Deshalb ist die Lösung besonders wertvoll für Unternehmen mit einer mittleren bis großen Kundenbasis und gemischtem Auftragsportfolio — bei sehr kleinen Kundenstämmen lohnt sich die Infrastruktur weniger.

Richtwerte — stark abhängig von ERP-Datenqualität, Kundenmix und operativer Komplexität des Unternehmens.

Was eine Kaskade ist — und warum sie so schwer zu sehen ist

Der Begriff klingt technisch, ist aber erschreckend alltäglich. Eine Kundensonder-Kaskade entsteht, wenn ein einziger ungewöhnlicher Kundenwunsch eine Kette von Abweichungen in nachgelagerten Prozessen auslöst — jede davon ist für sich allein handhabbar, aber zusammen entsteht ein Aufwand, der die ursprüngliche Kalkulation aushöhlt.

Was eine Kaskade von einem normalen Sonderwunsch unterscheidet:

• Breadth — sie betrifft mehr als eine Abteilung gleichzeitig (Beschaffung, Arbeitsvorbereitung, Vertrieb)
• Tiefe — sie produziert nachgelagerte Ausnahmen, die nicht im ursprünglichen Auftrag sichtbar sind
• Wiederholung — sie tritt beim gleichen Kunden regelmäßig auf, nicht einmalig
• Unsichtbarkeit — jede Abteilung sieht nur ihre eigene Ausnahme, nicht das Muster

Warum sieht das klassische Reporting das nicht? Weil ERP-Systeme transaktional denken: Ein Auftrag ist ein Datensatz. Eine Sonderbeschaffung ist ein anderer Datensatz. Eine Planänderung ist ein dritter. Dass alle drei auf denselben Kunden zurückgehen, und dass dieser Kunde das jeden dritten Auftrag macht, erscheint in keinem Standard-Report.

Predictive Analytics und Machine Learning verändern das, indem sie nicht Transaktionen auswerten, sondern Muster über Zeit. Die Frage ist nicht: „Was hat dieser Auftrag gekostet?” — sondern: „Welche Kunden produzieren statistisch überdurchschnittlich viele Ausnahme-Events?”

Wie das System gesunde Individualisierung von schädlichen Mustern unterscheidet

Das ist die entscheidende Feinheit. Nicht jeder Sonderwunsch ist ein Problem — viele Kunden zahlen mehr für Individualisierung und rechtfertigen den Aufwand vollständig. Ein Kunde, der regelmäßig Sonderwünsche stellt, aber dafür erhöhte Preise akzeptiert und nie Lieferterminprobleme produziert, ist kein Kaskadenkunde — er ist ein wertvoller Kunde.

Das System muss folgende Signale trennen können:

Die technische Umsetzung dafür heißt multivariate Mustererkennung: Das System berechnet nicht einfach „Wie viele Sonderwünsche?”, sondern kombiniert mehrere Signale zu einem Gesamtscore je Kunde. Kunden mit hohem Sonderwunsch-Volumen aber niedriger Folgelast werden anders klassifiziert als Kunden, bei denen jeder Sonderwunsch fünf Ausnahme-Events in drei Abteilungen auslöst.

Für die Praxis bedeutet das: Die KI liefert keinen binären „Problemkunde”-Stempel, sondern ein Kaskaden-Risiko-Profil mit den konkreten Treibern. Das erlaubt ein differenziertes Gespräch: „Ihr Sonderwunsch-Anteil ist hoch, aber das Pricing stimmt. Das echte Problem sind die drei Planänderungen im letzten Quartal — können wir das im Angebotsprozess besser verankern?”

Was das System konkret macht

Der technische Kern besteht aus zwei Komponenten:

1. Event-basierte Auswertung je Kunde Aus dem ERP werden alle Ausnahme-Events je Auftrag und Kunde extrahiert: Sonderbeschaffungen, Planänderungen, Lieferverzögerungen, nachträgliche Preiskorrekturen, Gutschriften, manuelle Ausnahme-Genehmigungen. Diese Events werden zu einem Zeitreihenprofil je Kunde zusammengeführt.

2. Anomalieerkennung auf Kunden-Ebene Das System vergleicht das Ausnahme-Profil jedes Kunden mit dem statistischen Durchschnitt der Kundenbasis. Kunden, deren Ausnahme-Rate in mehreren Dimensionen gleichzeitig über dem Durchschnitt liegt, werden als Kaskadenkandidaten markiert.

Dazu braucht das System keine künstliche Intelligenz im wissenschaftlichen Sinne — die Grundversion funktioniert mit gut strukturierten SQL-Abfragen und einem BI-Dashboard. Der Mehrwert von Machine Learning entsteht bei komplexeren Fragen: Welche Auftragsmerkmale (Produktkategorie, Auftragsgröße, Jahreszeit, Verhandlungskontext) erhöhen die Kaskadenwahrscheinlichkeit? Welcher Kaskadenpfad ist am teuersten? Wie viele zukünftige Aufträge werden voraussichtlich betroffen?

Das Ergebnis ist ein Kunden-Dashboard mit drei Ansichten:

• Kaskaden-Watchlist: Kunden, deren Ausnahme-Score in den letzten 90 Tagen überdurchschnittlich gestiegen ist
• Historische Profile: Vollständige Kaskaden-Historie je Kunde, aufgeschlüsselt nach Event-Typ und Abteilung
• Frühwarnung: Alarm, wenn ein laufender Auftrag eines Watchlist-Kunden das erste Ausnahme-Event auslöst

Konkrete Werkzeuge — was wann passt

Die richtige Werkzeugwahl hängt davon ab, wie viele Daten vorhanden sind, wie hoch die technische Kapazität im Unternehmen ist und ob eine sofort nutzbare Ansicht oder eine tief integrierte Lösung gefragt ist.

Power BI — wenn ein BI-Dashboard reicht Für viele Unternehmen ist die erste und effektivste Lösung kein KI-System, sondern ein gut gebautes BI-Dashboard. Wenn das ERP Ausnahme-Events strukturiert exportiert (oder eine Datenbank-Anbindung möglich ist), kann Power BI in 2–4 Wochen ein Kunden-Ausnahme-Dashboard liefern. Kein Machine Learning, aber visuelle Mustererkennung durch das Ops-Team — schnell einsatzbereit, niedrige Kosten (ab 10 €/Person/Monat), EU-Hosting über Microsoft. Ideal als erster Schritt, bevor investiert wird.

Julius AI — für explorative Erstanalyse ohne Techniker Wer wissen will, ob das Kaskadenphänomen in seinen Daten überhaupt existiert, bevor er in Infrastruktur investiert, kann mit Julius AI starten: ERP-Export als CSV oder Excel hochladen, in natürlicher Sprache auswerten lassen — „Welche Kunden haben im letzten Jahr die meisten Planänderungen ausgelöst?” Kostenlos bis 100 Credits/Monat für erste Analysen. Kein EU-Hosting — nur für anonymisierte Exportdaten verwenden.

KNIME — für die eigene ML-Pipeline On-Premise KNIME ist die richtige Wahl, wenn das Unternehmen die Kaskadenerkennung dauerhaft intern betreiben will, sensible Auftragsdaten nicht in die Cloud geben kann und einen technisch versierten Anwender hat. Visueller Workflow-Builder für Datenpipelines, kostenlos in der Desktop-Version, on-premise betreibbar, gute SAP-Konnektoren. Aufbau eines ersten Anomalieerkennungs-Workflows dauert 4–6 Wochen für einen Einsteiger.

Celonis — wenn Process Mining und ERP-Integration Priorität haben Für Unternehmen mit SAP S/4HANA und einem echten Process-Mining-Bedarf ist Celonis die mächtigste Option. Celonis kann Ausnahme-Events direkt aus dem SAP-Event-Log lesen, Kaskadenpfade automatisch visualisieren und Root-Cause-Analysen durchführen. Einschränkung: Einstieg ab ca. 50.000–100.000 € — nur sinnvoll, wenn das Unternehmen bereits mit Celonis arbeitet oder die Investition für ein breiteres Process-Mining-Projekt rechtfertigt.

SAP IBP — wenn Supply-Chain-Planung im Mittelpunkt steht Wer die Kaskadenerkennung direkt in die Produktionsplanung integrieren will (nicht nur als Reporting-Schicht), kommt mit SAP IBP in die richtige Richtung: Das System kann Sonderbeschaffungs-Events und Planabweichungen direkt in die Kapazitätsplanung einbeziehen. Hohe Implementierungskosten (ab 50.000 €/Jahr Lizenz), langer Rollout — nur für Unternehmen sinnvoll, die SAP-Ökosystem bereits nutzen.

Zusammenfassung: Wann welcher Ansatz

• Erste Analyse, kleine Datenmenge → Julius AI (exportierte CSV/Excel, anonymisiert)
• Schnelles Dashboard ohne IT-Aufwand → Power BI
• On-Premise ML-Pipeline, sensible Daten → KNIME
• SAP-Umgebung, tiefer Process-Mining-Ansatz → Celonis
• Supply-Chain-Integration in SAP → SAP IBP

Integrations-Realität: Was aus dem ERP wirklich kommt

Das ist der Teil, den Anbieter-Demos gerne überspringen.

Ein typisches ERP-System eines mittelständischen Fertigungsbetriebs erfasst Sonderbeschaffungen, Planänderungen und Preiskorrekturen — aber selten so, dass sie direkt für Musteranalysen verwendbar sind. Konkrete Hürden in der Praxis:

Ereignisse sind nicht als Ausnahmen markiert. Eine Sonderbeschaffung sieht im ERP aus wie eine normale Bestellung — nur an einem anderen Lieferanten, mit einer anderen Lieferzeit. Es gibt kein Feld „Sonderbeschaffung: Ja/Nein”. Du musst dieses Signal aus Kombination anderer Felder ableiten (z.B. Lieferant nicht in der Lieferantenliste, Bestelldatum nach Auftragsbestätigung, Menge unter Mindestabnahme).

Planänderungen sind nicht strukturiert protokolliert. Viele ERP-Systeme loggen Fertigungsplanänderungen nicht mit Zeitstempel und Auslöser. Sie überschreiben den Plan. Was vorher war, ist weg. Für historische Analysen fehlt die Grundlage.

Kundenbezug ist inkonsistent. Ein Kunde kann in verschiedenen Auftragsperioden unter verschiedenen Kundennummern auftauchen (Fusionen, Tochtergesellschaften, verschiedene Einkäufer). Ohne manuelle Bereinigung oder Stammdatenharmonisierung liefert die Analyse verzerrte Ergebnisse.

Was das bedeutet für die Projektvorbereitung: Vor dem Start sollte eine ehrliche Datenbestandsaufnahme gemacht werden: Welche Ausnahme-Events sind im ERP strukturiert erfasst? Über welchen Zeitraum? Sind Kundenstammdaten konsistent? Eine solche Bestandsaufnahme dauert 2–4 Wochen und verhindert, dass das Implementierungsprojekt an der Datenqualität scheitert.

Erfahrungsgemäß gilt: Wer sauber strukturierte ERP-Daten über mindestens 18 Monate hat, kann direkt mit der Analyse starten. Wer das nicht hat, muss mit einem Datenbereinigungsprojekt beginnen — das ist kein Rückschlag, sondern der normale Weg.

Datenschutz und Datenhaltung

Kundensonder-Kaskaden-Erkennung arbeitet mit Auftragsdaten, Kundenhistorien und Preisdaten — alles intern, in der Regel keine personenbezogenen Daten im DSGVO-Sinne. Trotzdem gibt es relevante Datenschutzaspekte:

Auftragsdaten mit Kundenbezug: Wenn Kundennamen oder Kundennummern in die Analyse einfließen, handelt es sich je nach Datenstruktur um Geschäftsdaten von juristischen Personen (B2B) — für die die DSGVO nur begrenzt gilt. Bei natürlichen Personen als Kunden (seltener im Fertigungsbereich, aber möglich) gelten die normalen DSGVO-Anforderungen.

Cloud vs. On-Premise: Wenn die Auftragsdaten in einer Cloud-Plattform analysiert werden, muss mit dem Anbieter ein Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO abgeschlossen werden — auch wenn es technisch keine personenbezogenen Kundendaten sind, schon allein wegen der möglichen internen Personaldaten in Buchungen (wer hat die Planänderung genehmigt?). EU-konforme Optionen:

• Power BI: EU-Hosting über Microsoft Azure EU-Rechenzentren, AVV inklusive
• KNIME: Vollständig on-premise betreibbar, keine Daten verlassen das Unternehmensnetzwerk
• Julius AI: US-Hosting — nur mit anonymisierten Exports verwenden
• Celonis: EU-Datenhaltung auf Anfrage konfigurierbar

Vertraulichkeit von Kunden-Profilen: Die erstellten Kaskaden-Profile enthalten oft sensible kommerzielle Einschätzungen über Kunden („Kaskadenkunde”, Ausnahme-Score, Margenbewertung). Diese Dokumente sollten intern als vertraulich behandelt und nicht in offenen Systemen gespeichert werden.

Was es kostet — realistisch gerechnet

Einmalige Einrichtungskosten

• Datenbestandsaufnahme und ERP-Analyse: intern 2–4 Wochen, oder extern ca. 3.000–8.000 €
• Dashboard-Entwicklung (Power BI): intern 1–3 Wochen oder extern ca. 2.000–5.000 €
• ML-Modellentwicklung (KNIME): intern 4–8 Wochen oder extern ca. 5.000–12.000 €
• Celonis-Integration: nur mit Systemintegrator, Projektkostenbereich 20.000–60.000 €

Laufende Kosten (monatlich)

• Power BI Pro: ~10 €/Person/Monat (für das Ops-Team, ca. 3–5 Personen: 30–50 €/Monat)
• Julius AI (Erstanalyse): kostenlos bis 100 Credits/Monat
• KNIME (On-Premise Desktop): kostenlos für Einzelnutzer, Hub-Pläne auf Anfrage
• Celonis: Enterprise-Preise, ab ca. 50.000–150.000 €/Jahr

Wie du den Nutzen tatsächlich misst Die einfachste Messung: Identifiziere die 5–10 Kunden mit dem höchsten Kaskaden-Score. Führe nach drei Monaten gezielter Maßnahmen (Pricing-Gespräch, Sonderwunsch-Protokoll, Änderungsaufwand-Pauschale) einen Vorher-Nachher-Vergleich der Ausnahme-Events und der Bruttomarge je Auftrag für diese Kunden durch.

Was du dagegenrechnen kannst Ein produzierendes Unternehmen mit 500 aktiven Kunden und einem Umsatz von 15 Millionen Euro hat erfahrungsgemäß 15–40 Kunden mit signifikantem Kaskadeneffekt. Wenn ein Kaskadenkunde durchschnittlich 2 Ausnahme-Events pro Auftrag und 3–4 Aufträge pro Jahr auslöst, entstehen 6–8 außerplanmäßige Prozessunterbrechungen. Bei einem internen Aufwand von 4–8 Stunden je Unterbrechung und einem Stundensatz von 60–100 € ergeben sich: ca. 1.400–6.400 € je Kaskadenkunden pro Jahr allein an direktem Ausnahme-Aufwand. Nicht gerechnet: Margenverluste durch nachträgliche Rabatte und Goodwill-Korrekturen.

(Orientierungswerte aus operativem Controlling-Erfahrungsschatz in Fertigungsbetrieben — keine repräsentative Studie.)

Drei typische Einstiegsfehler

1. Mit dem ERP-Export starten, ohne Datenqualität zu prüfen. Der häufigste Fehler: Das Ops-Team exportiert Auftragsdaten und beginnt zu analysieren — ohne zu prüfen, ob Planänderungen tatsächlich mit Zeitstempel protokolliert wurden, ob Kundenstammdaten konsistent sind und ob Sonderbeschaffungen als solche erkennbar sind. Das Ergebnis ist eine Analyse, die keine verwertbaren Muster zeigt — nicht weil das Konzept falsch ist, sondern weil die Daten das Konzept nicht tragen. Lösung: 2 Wochen Datenbestandsaufnahme vor dem Projektstart.

2. Alle Kunden mit überdurchschnittlichen Sonderwünschen als Kaskadenkunden markieren. Das führt zu einem System, das jeden zweiten Kunden flaggt — und damit nutzlos wird. Alert-Fatigue ist das größte Risiko für diese Lösung: Wenn das System zu viel meldet, hört das Team nach drei Wochen auf zuzuhören. Lösung: Score nur auf Kunden mit Multidimensionalität (Ausnahmen in mehreren Abteilungen gleichzeitig). Lieber 8 präzise Treffer als 40 Kandidaten, die alle geprüft werden müssen.

3. Die Erkenntnisse als Anklagepunkte verwenden. Kaskaden-Profile können interne Schuldzuweisungen auslösen: „Ihr habt dem Kunden zu oft nachgegeben.” Das ist der falsche Umgang. Die Profile sind Verhandlungsgrundlagen, keine Urteile. Ein Kaskadenkunde ist nicht unbedingt ein schlechter Kunde — er ist ein Kunde, mit dem das Unternehmen das Pricing-Gespräch noch nicht geführt hat. Das erfordert ein klares Kommunikationsprotokoll für das Vertriebsteam: Was tun wir mit dieser Information? Wie führen wir das Gespräch?

4. Das System läuft, aber niemand ist zuständig. Nach drei Monaten Betrieb hat das Kaskaden-Dashboard 12 aktuelle Kandidaten. Aber wer ist dafür verantwortlich, dass daraus Maßnahmen folgen? Wenn die Antwort „alle” oder „niemand konkret” ist, wird die Liste länger und niemand handelt. Lösung: Eine namentlich benannte Person (Operations Manager oder Key-Account-Verantwortliche:r) prüft das Dashboard wöchentlich und trägt Maßnahmen ins CRM ein.

Was mit der Einführung wirklich passiert — und was nicht

Die Technik ist handhabbar. Die Herausforderung ist organisatorisch.

Der Vertrieb wird nervös. Wenn das System zeigt, dass Kunde X ein Kaskadenkunde ist, steht der Vertrieb vor einer unangenehmen Frage: Soll er das Gespräch suchen? Und riskiert dabei, dass der Kunde abwandert? In der Praxis gibt es erhebliche Berührungsangst, Erkenntnisse aus dem Kaskaden-Dashboard in Kundengespräche zu überführen. Die Lösung ist kein Tool-Feature, sondern ein klarer interner Prozess: Ab welchem Score wird wer informiert? Wer führt das Gespräch? Mit welchem Argumentationsrahmen?

Die Ops-Leitung wird das System umarmen — und gleichzeitig blockieren. Erfahrungsgemäß sind Operations-Manager begeistert, wenn sie die Profile sehen: „Endlich Zahlen für das, was ich seit Jahren beschreibe.” Gleichzeitig entsteht der Reflex, die Profile als Beweismittel für Budget- und Personalentscheidungen zu verwenden — was die politische Dynamik verkompliziert. Empfehlung: Das Dashboard in der ersten Phase intern halten und erst nach Abschluss der ersten Maßnahmen-Runde mit der Geschäftsführung teilen.

Was konkret hilft:

• Kick-off mit Ops, Vertrieb und Geschäftsführung gemeinsam — alle sehen dieselben ersten Profile gleichzeitig
• Klares Protokoll: Was passiert wenn ein Kunde den Score X überschreitet? (Kein Graubereich)
• Erste drei Maßnahmen werden intern begleitet — mit Lernen, nicht mit Druck

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände — und was dahintersteckt

„Wir wissen schon, welche Kunden schwierig sind.” Vielleicht. Aber „wissen” und „messen” sind zwei verschiedene Dinge. Wenn du nicht weißt, wie viele Ausnahme-Events ein bestimmter Kunden tatsächlich ausgelöst hat, hast du keine Grundlage für ein Pricing-Gespräch. Bauchgefühl überzeugt weder die Geschäftsführung noch den Kunden. Ein Kaskaden-Profil mit konkreten Zahlen ist ein anderes Gespräch.

„Unsere Kunden sind alle individuell — das ist unser Geschäftsmodell.” Richtig — und das spricht nicht gegen diese Lösung. Die Frage ist nicht, ob es Individualisierung gibt, sondern ob du weißt, welche Individualisierung du wie bepreist. Wenn alle Kunden individuell sind und alle denselben Preis zahlen, geht die Marge bei den aufwändigen Kunden verloren und subventioniert die weniger aufwändigen. Das ist selten die Absicht.

„Das sind doch zu wenige Kunden, um KI einzusetzen.” Stimmt teilweise. Für die reine Mustererkennung auf 200–500 Kunden mit 3–4 Aufträgen pro Jahr brauchst du kein ML. Ein gut gebautes BI-Dashboard mit Power BI reicht für den Anfang vollkommen. Die KI-Ebene (Vorhersagemodelle, automatische Event-Klassifikation) kommt erst, wenn das Grundprinzip validiert und der Nutzen erwiesen ist.

Woran du merkst, dass das zu dir passt

• Dein Unternehmen fertigt auf Auftrag — kein reines Serienproduktionsgeschäft, sondern ein Anteil von mindestens 20–30 Prozent Sonder- und Projektaufträgen
• Du hast 100+ aktive Kunden — genug Grundgesamtheit, um statistische Muster sichtbar zu machen
• Im Ops-Team gibt es konkrete Namen, wenn die Sprache auf „schwierige Kunden” kommt — das Muster existiert schon als Wissen, fehlt aber als Zahl
• Preiskorrekturen nach Auftragsstart sind im Unternehmen üblich — das ist ein klares Signal, dass Kalkulation und tatsächlicher Aufwand auseinanderfallen
• Du hast strukturierte ERP-Daten über mindestens 12–18 Monate — ohne historische Daten gibt es kein Muster, das man erkennen könnte

Wann es sich (noch) nicht lohnt — drei harte Ausschlusskriterien:

1. Weniger als 80–100 aktive Kunden oder weniger als 150–200 Aufträge pro Jahr. Bei kleineren Kundenstämmen sind die Kaskadenmuster mit dem bloßen Auge erkennbar — du brauchst kein System, um die drei Problemkunden zu identifizieren, die du ohnehin kennst. Der Einrichtungsaufwand für das Dashboard übersteigt den Mehrwert.

2. ERP-Daten strukturell ungeeignet. Wenn Planänderungen im ERP nicht protokolliert werden, Sonderbeschaffungen nicht von regulären Beschaffungen unterscheidbar sind oder Kundenstammdaten stark fragmentiert sind (mehrere Nummern für denselben Kunden), ist das Fundament für die Analyse nicht vorhanden. Erst Stammdatenqualität herstellen, dann Kaskadenanalyse.

3. 100-Prozent-Sondermaschinenbau ohne Standard-Baseline. Wenn das gesamte Geschäftsmodell auf maximaler Individualisierung beruht und es keinen Standard-Auftrag gibt, fehlt der Vergleichsmaßstab für „außergewöhnlich”. Was ist eine Kaskade, wenn jeder Auftrag einzigartig ist? In diesem Fall hilft eine relative Analyse (Vergleich von Aufwand je Auftragswert), aber die klassische Musterkennung funktioniert nur, wenn es eine erkennbare Abweichung von einem Normalzustand gibt.

Das kannst du heute noch tun

Exportiere aus deinem ERP alle Aufträge der letzten 18 Monate mit folgenden Feldern: Kundennummer, Auftragsdatum, Auftragswert, Anzahl der Auftragsänderungen, ob Sonderbeschaffung erfolgt ist (Ja/Nein, oder indirekt über Lieferantenliste), Lieferverzögerung in Tagen, ob eine nachträgliche Preiskorrektur erfolgt ist.

Wenn dein ERP das nicht direkt kann: Lass das Ops-Team die letzten 30 Aufträge manuell mit diesen Feldern befüllen — das reicht für eine erste Plausibilitätsprüfung.

Lade diesen Export in Julius AI (kostenlos, anonymisiert — Kundennummern sind keine personenbezogenen B2B-Daten) und stelle die folgende Frage:

Quellen & Methodik

• TCW GmbH, „Herausforderungen in der Auftragsabwicklung im Sondermaschinenbau”: Unternehmensberatungsbericht der TCW Transfer-Centrum GmbH & Co. KG, München. Identifiziertes Optimierungspotenzial von ca. 14 % des Gesamtumsatzes durch bessere Auftragsabwicklung in projektbasierten Fertigungsbetrieben. Quelle: tcw.de/news/herausforderungen-in-der-auftragsabwicklung-im-sondermaschinenbau-779
• Tacton Systems, „The CFO’s Guide to Protecting Profit Margins in Manufacturing” (2024): Analyse zu Margenverlusten in der Fertigungsindustrie. Kernaussage: Hersteller können bis zu 80 % ihrer kalkulierten Marge zwischen Angebotsstellung und Lieferung verlieren; konkretes Beispiel: 25 % kalkulierte Marge → 3 % nach Design-Änderungen, Verzögerungen, Garantiefällen und Overhead. Quelle: tacton.com/cpq-blog/cfo-guide-protecting-profit-margins-in-manufacturing
• Kaskadeneffekte in Lieferketten: Wissenschaftliche Grundlage zu Kaskaden-Propagation in produzierenden Unternehmen: ScienceDirect, „Exploring cascading failures in supply chain risk management” (2025).
• Operative Erfahrungswerte: Schätzungen zu Kaskadenkundenprozentsatz (3–8 %), direktem Ausnahme-Aufwand je Kunde und ERP-Datenqualitätsproblemen basieren auf Erfahrungsberichten aus dem produzierenden Mittelstand, keine repräsentative Studie.
• Tool-Preisangaben: Power BI (ab 10 €/Person/Monat), Julius AI (Freemium, ab 0 USD), KNIME (kostenlos Desktop), Celonis (ab ca. 50.000 €) basieren auf veröffentlichten Tarifen der Anbieter (Stand April 2026).

Du willst wissen, ob deine ERP-Daten für diese Analyse geeignet sind und was die ersten konkreten Schritte für euer Unternehmen wären? Meld dich — das klären wir gemeinsam in einem kurzen Gespräch.