# Dynamischer Sicherheitsbestand: Service schützen, ohne Liquidität zu binden
Ein Puffer, der sich nach Signalen anpasst … oder eine teure Ausrede, um das eigentliche Problem zu vermeiden.
Ich höre oft: „Wir brauchen Bestand, sonst sind wir ausgeliefert.“
Die Absicht ist richtig. Das Problem beginnt, wenn dieses „Kissen“ zur Gewohnheit wird: Es wächst, keiner hinterfragt es – und dennoch gibt es Fehlteile. Dann tritt das gefährlichste Doppel-Symptom auf:
-
- Kritisches fehlt (und die Ausführung bricht)
-
- Unwichtiges stapelt sich (und Liquidität wird gebunden).
Wenn Fehlteile und Überbestand gleichzeitig existieren, wird Bestand zu Rauschen: Er versteckt die Wahrheit, verzögert Entscheidungen und erhöht die stillen Kosten von Dringlichkeit.
Das ist keine Schritt-für-Schritt-Anleitung für „perfekte Berechnung“. Die gibt es im echten Leben nicht. Hier geht es darum: Erkennen, ob Sicherheitsbestand gesteuert ist (und Service wirklich schützt) oder ob er nur Chaos kaschiert.
Komplette Implementierung (Regeln, Segmentierung, Taktung, Ownership, Automatisierung) erfolgt nur im Rahmen einer Diagnose.
## Grundfehler: Fixe Zahl in variabler Welt
Viele definieren: „X Stück“, „Y Tage“. Das funktioniert nur bei stabilem Risiko.
In der Realität ändert sich Risiko: Verbrauchsvariabilität, reale Lead Times, Lieferantenverlässlichkeit, Projektmix, Kapazität, Früherkennung von Ausnahmen.
Dynamisch heißt:
Puffer muss sich ändern, wenn sich Risiko ändert.
## Was Sicherheitsbestand in Wahrheit kompensiert
Driftende Lead Times, schlechte Verbrauchserfassung, improvisierte Substitutionen, inkonsistente Produktdaten, reaktive Beschaffung, wechselnde Prioritäten, unklare Kritikalität.
Ohne Governance kauft mehr Bestand „Ruhe“… und Opazität.
## Warnsignale
-
- Lager voll, aber Dauer-Feuerwehr.
-
- Disposition nach Gefühl.
-
- Theorie-Lead-Time ≠ reale Lead-Time.
-
- Alles ist „dringend“.
-
- Daten optional.
-
- „Unerwartete“ Fehlteile, die danach offensichtlich sind.
## Dynamisch = gesteuert
-
- Risiko messbar (auch als Bandbreiten)
-
- Puffer passt sich an
- klares Ownership.
## Das Dreieck: Service, Liquidität, Stabilität
Ohne klare Entscheidungen wird’s emotional. Ich will: Welches Risiko decken wir – und warum?
## Was das Modell bricht
Wachstum vs Variabilität verwechseln, „schöne“ statt echte Verbräuche, kritisch vs bequem nicht trennen, Lead-Time-Streuung ignorieren, kein Ausnahmensystem.
## Der Wechsel: Über „Puffer“ sprechen
Service-Puffer, Lead-Time-Puffer, Verbrauchs-Puffer, interne Entkopplung. Nicht jeder Puffer verdient zu existieren.
## Taktung statt Aberglaube
Eine kurze Routine: Risikoänderungen, priorisierte Ausnahmen, Beinahe-Fehlteile, wachsender Überbestand, Entscheidungen ohne Owner.
## Angst vor falscher Anpassung
Reife heißt nicht Liquidität „zur Sicherheit“ zu binden, sondern: frühe Signale, klare Priorität, schnelle Aktionen bei Ausnahmen.
## Das Dashboard, das ich sehen will
Risiko nach Kritikalität, Überbestand mit Trend, verschlechterte reale Lead Times, erratische Verbräuche, Entscheidungen ohne Owner.
## Muster, das Marge zerstört
Dringlichkeit + Substitution + Schweigen → System lernt falsch → Wiederholung. Systemproblem, kein Lagerproblem.
## Diagnosefragen
Beinahe-Fehlteile, Kritikalität nach Versprechen, Lead-Time-Streuung, Datendisziplin, Anteil „Urgency-Dispo“, Überbestand durch Trägheit, Ownership, Frühwarnsignale.
## Checkliste
Wenn 3+ Punkte fehlen, ist der Puffer wahrscheinlich eine Wette.
## Abschluss
Wenn du willst, helfe ich dir zu klären, ob dein Sicherheitsbestand Service schützt oder Liquidität bindet, und welche Mindest-Signale du brauchst, um ihn ohne Improvisation zu steuern.
Diagnóstico express
