Warum Kunden die Verfügbarkeitsberechnung in Business Central oft „nicht mögen“

Wer Microsoft Dynamics 365 Business Central einführt oder optimiert, stößt früher oder später auf ein Thema, das in fast jedem Projekt Diskussionen auslöst:

Die Verfügbarkeitsberechnung.

Viele Key-User sind nach den ersten Tests enttäuscht. Aussagen wie …

• „Das stimmt doch alles nicht.“
• „Das System zeigt falsche Zahlen.“
• „Wir können damit nicht arbeiten.“
• „Warum gibt es fünf verschiedene Verfügbarkeiten?!“

… sind in der Praxis absolut typisch.

Und das Spannende ist:

In den meisten Fällen ist die Verfügbarkeitslogik nicht falsch – sie ist nur radikal konsequent.

In diesem Artikel schauen wir uns an, warum Kunden die Verfügbarkeitsfunktion oft ablehnen, welche Herausforderungen dahinterstecken und wie man sie in Projekten sauber adressiert.

1) Verfügbarkeit ist in Business Central kein „Lagerbestand“

Eine der größten Missverständnisse entsteht direkt am Anfang.

Viele Anwender erwarten, dass „Verfügbarkeit“ bedeutet:

„Was liegt aktuell im Lager?“

Business Central unterscheidet jedoch klar zwischen:

• physischem Bestand (was tatsächlich gebucht ist)
• geplanter Verfügbarkeit (Bestand + erwartete Zugänge − erwartete Abgänge)

Das bedeutet:

Sobald Verkaufsaufträge, Einkaufsbestellungen, Produktionsaufträge oder Umlagerungen im Spiel sind, ist Verfügbarkeit nicht mehr nur ein Lagerwert, sondern eine Planungssicht.

Für Kunden, die eher operativ arbeiten („Wir schauen morgens ins Lager und liefern“), fühlt sich das oft wie unnötiger Overhead an.

2) Die Berechnung ist extrem datenabhängig – und das ist für viele ungewohnt

Business Central ist gnadenlos datumsgetrieben.

• Verkaufsaufträge reduzieren Bestand am Shipment Date
• Einkaufsbestellungen erhöhen Bestand am Expected Receipt Date
• Produktion, Umlagerung, Komponentenverbrauch: ebenfalls datumsabhängig

Das Problem:

In vielen Firmen werden diese Datumsfelder nicht sauber gepflegt.

Oft sind sie:

• grobe Schätzwerte
• Standardwerte
• „wird später angepasst“
• oder werden von Anwendern ignoriert

Dann passiert etwas, das in Workshops immer wieder vorkommt:

Business Central berechnet korrekt – aber auf Basis falscher Daten.

Und damit fühlt sich das Ergebnis für Kunden „falsch“ an.

3) Reservierungen: der Punkt, an dem die Stimmung kippt

Wenn es einen Mechanismus gibt, der in Business-Central-Projekten regelmäßig für Frust sorgt, dann sind es Reservierungen.

Viele Unternehmen haben folgende Erwartung:

„Wenn 10 Stück da sind, können wir 10 Stück verkaufen.“

Business Central kann aber (je nach Setup und Prozess) folgendes tun:

• Bestand wird für Auftrag A reserviert
• Auftrag B sieht diesen Bestand nicht mehr
• oder BC zeigt Auftrag B als „nicht lieferbar“

Für Anwender fühlt sich das so an:

• „BC blockiert uns.“
• „Das System macht Dinge, die wir nicht wollen.“
• „Warum kann ich nicht einfach liefern?“

Das eigentliche Problem ist dabei selten die Reservierung selbst – sondern eine fehlende Reservierungsstrategie:

• Reservieren wir automatisch oder manuell?
• Nur für wichtige Kunden?
• Nur für bestimmte Artikel?
• Oder gar nicht?

Wenn diese Fragen nicht geklärt sind, wird Verfügbarkeit für Anwender schnell unberechenbar.

4) Die Periodenansicht ist logisch – aber nicht intuitiv

Business Central bietet verschiedene Ansichten wie:

• Verfügbarkeit nach Ereignissen
• Verfügbarkeit nach Periode
• Verfügbarkeit nach Lagerort
• Verfügbarkeit nach Variante

Gerade „nach Periode“ sorgt oft für Stirnrunzeln, weil Kunden erwarten:

„Sag mir einfach, ob ich liefern kann.“

Stattdessen sehen sie eine Tabelle mit:

• Wochen
• Summen
• geplanten Zugängen und Abgängen

Das ist fachlich korrekt – aber viele Anwender arbeiten nicht in Wochenperioden, sondern in konkreten Aufträgen.

Wenn die Oberfläche nicht zur Denkweise passt, wird sie abgelehnt.

5) Lagerort, Variante, Charge: die Realität ist komplizierter als „100 Stück“

Ein weiterer Klassiker:

Ein Artikel hat 100 Stück Bestand.

Aber:

• verteilt auf mehrere Lagerorte
• teilweise als Variante
• teilweise mit Charge / Seriennummer
• teilweise gesperrt oder in Qualitätsprüfung

Business Central kann dann völlig korrekt sagen:

„Für diesen Auftrag am Lagerort X ist der Artikel nicht verfügbar.“

Für Kunden wirkt das aber wie ein Fehler.

Das ist ein typisches Gap zwischen:

• Gesamtbestand
• und verwendbarem Bestand im konkreten Kontext

6) Business Central rechnet sauber – viele Firmen arbeiten „situativ“

Business Central ist ein System, das Planung belohnt.

Viele Firmen sind aber in der Realität so unterwegs:

• Liefertermine sind flexibel
• Wareneingänge sind unsicher
• Produktionszeiten sind optimistisch
• man „organisiert“ Dinge im Tagesgeschäft

Das führt zu einem kulturellen Konflikt:

Business Central erwartet saubere Prozesse.
Viele Unternehmen arbeiten aber mit Erfahrungswissen und Bauchgefühl.

Und genau da wirkt Business Central plötzlich „zu streng“.

7) Zu viele Zahlen – zu wenig Klarheit

Ein sehr praktisches Problem:

Business Central zeigt oft mehrere Kennzahlen nebeneinander:

• Inventory
• Qty. on Sales Order
• Qty. on Purch. Order
• Available Inventory
• Projected Available Balance

Für erfahrene Consultants ist das logisch.

Für viele Anwender wirkt es so:

„Warum gibt es sechs verschiedene Wahrheiten?“

Wenn ein User nicht genau weiß, welche Zahl für seine Rolle relevant ist, verliert er das Vertrauen in das System.

Warum wir nicht empfehlen, eine eigene Verfügbarkeitslogik „drüber“ zu bauen

Wenn Kunden mit der Standard-Verfügbarkeit unzufrieden sind, kommt fast immer irgendwann der Vorschlag:

„Dann bauen wir halt unsere eigene Verfügbarkeitsberechnung.“

Das klingt im ersten Moment sinnvoll – ist in der Praxis aber fast immer ein riesiges Risiko.

1) Eigene Logik kann sich mit dem Standard in die Quere kommen

Business Central hat sehr viele Stellen, an denen Verfügbarkeit indirekt eine Rolle spielt:

• Reservierungen
• Planungsvorschläge
• Auftragsbestätigungen
• Liefervorschläge
• Artikelverfolgung
• Lagerprozesse

Wenn man „eine zweite Wahrheit“ einführt, entstehen schnell widersprüchliche Aussagen:

• Standard sagt: lieferbar
• Custom sagt: nicht lieferbar

Und spätestens dann ist das Vertrauen der User endgültig weg.

2) Du musst wirklich ALLES berücksichtigen – überall

Eine Verfügbarkeitsberechnung ist nicht nur:

Bestand − Verkaufsaufträge + Einkaufsbestellungen

In echten Kundenprozessen musst du u. a. berücksichtigen:

• Verkaufsaufträge
• Einkaufsbestellungen
• Produktionsaufträge
• Umlagerungen
• Montageaufträge
• Rahmenaufträge / Abrufe
• Rücklieferungen
• Lagerplatzsysteme
• Reservierungen (und deren Prioritäten)

Und das nicht nur in einer Seite – sondern in:

• Pages
• Reports
• APIs
• Job Queue
• Power Automate
• Planungsläufen
• und ggf. mobilen Scannern

Das ist ein gigantischer Scope.

3) Es gibt extrem viele Spezialfälle, die man leicht vergisst

Hier ein kleiner Ausschnitt von typischen Cases, die Standard-BC bereits abdeckt:

• Fixtermine (Requested Delivery Date vs. Shipment Date)
• Warenausgänge, die schon existieren (Warehouse Shipment / Picks)
• Komplett- vs. Teillieferungen
• freigegebene Bestellungen / nicht freigegebene Bestellungen
• Lieferungen auf mehrere Lagerorte
• gesperrte Artikel / gesperrte Lagerorte
• Artikel mit Charge / Seriennummer
• Substitute Items
• Mindestbestände / Sicherheitsbestände

Diese Liste wird in echten Projekten schnell sehr lang.

4) Die Logik ist komplex, fehleranfällig und hoch riskant

Verfügbarkeit ist einer der sensibelsten Bereiche im ERP.

Wenn hier ein Fehler drin ist, sind die Auswirkungen sofort spürbar:

• falsche Lieferzusagen
• verpasste Liefertermine
• falsche Bestellungen
• Überbestand oder Fehlbestand
• operative Eskalationen im Tagesgeschäft

Und das größte Problem:

Die meisten Fehler treten nicht im Test auf – sondern erst nach Monaten, wenn seltene Sonderfälle eintreten.

5) Automatische Terminverschiebungen machen es noch gefährlicher

Besonders kritisch wird es, wenn eine eigene Logik nicht nur „berechnet“, sondern auch automatisch eingreift, z. B.:

• Shipment Dates nach vorne ziehen
• Delivery Dates nach hinten verschieben
• Bestelltermine automatisch umplanen

Dann bist du plötzlich nicht mehr in einer „Info-Logik“, sondern in einem System, das aktiv die Realität verändert.

Und damit steigt das Risiko massiv:

• Folgeprozesse laufen falsch
• Reservierungen werden unlogisch
• Lagerprozesse kollidieren
• Planungs- und Dispositionslogik wird unzuverlässig

Fazit dieser Sektion

Eine eigene Verfügbarkeitslogik ist oft eine „schnelle Idee“, aber:

Sie ist fast immer teurer, riskanter und langfristig schlechter wartbar als die Optimierung des Standards.

In den meisten Projekten ist der bessere Weg:

• Standard verstehen
• Daten und Prozesse sauber machen
• Reservierungsstrategie definieren
• User-Views vereinfachen (z. B. Ampel-Logik)
• und die richtigen BC-Ansichten schulen

Was bedeutet das für Projekte?

Die wichtigste Erkenntnis:

Verfügbarkeitsprobleme sind meistens keine Business-Central-Probleme.

Sie sind ein Mix aus:

• Datenqualität
• fehlender Prozessdefinition
• falscher Erwartungshaltung
• und einer UI, die nicht „entscheidungsorientiert“ ist

Wie man das in Projekten besser macht (kurz & pragmatisch)

Hier ein paar Ansätze, die sich in der Praxis bewährt haben:

1) Eine klare Reservierungsstrategie definieren

Nicht „irgendwie“, sondern bewusst.

2) Datumsfelder verpflichtend machen

Oder zumindest Prozesse schaffen, die sie zuverlässig pflegen.

3) Anwender nicht mit Zahlen erschlagen

Lieber eine reduzierte Sicht:

• Lieferbar: Ja/Nein
• Lieferdatum
• Engpassgrund

4) Verfügbarkeit auf die Rolle zuschneiden

Einkauf braucht andere Informationen als Verkauf oder Lager.

Fazit

Business Central liefert eine sehr leistungsfähige Verfügbarkeitsberechnung – aber sie ist:

• prozessabhängig
• datenabhängig
• und für viele Anwender nicht intuitiv

Wenn Kunden „die Verfügbarkeit nicht mögen“, dann ist das meistens kein Zeichen, dass Business Central schlecht ist.

Es ist ein Zeichen, dass:

Business Central ein Planungssystem ist – und das Unternehmen (noch) nicht sauber genug plant.