Bestellanforderung oder Bestellung

Zwischen dem Warenkorb und der Bestellung gibt es ein drittes Dokument. Zu verstehen, was es ist — und mit Absicht, was es nicht ist —, erklärt das meiste Verhalten in diesem Bereich, einschließlich der Teile, die Kunden überraschen.

Die drei Dokumente

Eine Bestellanforderung ist das interne Dokument des kaufenden Unternehmens: Wir beabsichtigen, das zu kaufen, vorbehaltlich Freigabe. Im deutschen Einkauf ist das die BANF, und jeder, der mit SAP gearbeitet hat, kennt das Objekt. Sie hat einen Anforderer, einen Wert, eine Kontierung und eine ausstehende Entscheidung. Sie ist keine Verpflichtung Ihnen gegenüber, dem Lieferanten, und sie darf sich nicht wie eine verhalten.

Eine Bestellung ist die Verpflichtung. Sie hat eine Nummer, die beide Seiten zitieren, sie erscheint in Ihrer Abwicklungs-Warteschlange, sie verbraucht Bestand, und sie wird irgendwann eine Rechnung.

Die Regel, die daraus folgt

Die Bestellung entsteht erst, wenn die letzte Unterschrift steht.

Das ist die wichtigste Designentscheidung in diesem Bereich, und es lohnt sich, deutlich zu sagen, warum die naheliegende Alternative verworfen wurde.

Die naheliegende Alternative: die Bestellung sofort in einem Status requested anlegen und bei Freigabe auf placed stellen. Das sieht einfacher aus und ist falsch, aus vier Gründen, die alle in Produktion auftauchen:

• Ihre Bestellliste füllt sich mit Dingen, die keine Bestellungen sind. Jede Zählung, jedes Dashboard, jeder Export muss daran denken, zwei Status auszuschließen. Irgendwann vergisst es jemand, und eine Umsatzzahl enthält 80.000 € an Anforderungen, die nie freigegeben wurden.
• Bestand. Eine Bestellung reserviert Bestand. Eine Anforderung, die Bestand reserviert, lässt einen Einkäufer ohne Befugnis Ihre letzten sechs Spindeln eine Woche festhalten — mit einer Anforderung, die niemand freigeben wird.
• Nummernkreise. Eine Bestellnummer wird auf Lieferscheinen und Rechnungen zitiert. Bestellnummern für abgelehnte Anforderungen zu verbrennen hinterlässt dauerhafte Lücken, nach denen der Prüfer Ihres Kunden fragt.
• Es sickert in Ihr ERP. Was eine Bestellung anlegt, synchronisiert sie irgendwann. Eine Anforderung geht niemanden etwas an außer das kaufende Unternehmen.

Deshalb hat die Orders-App keinen Status requested und keinen declined. Der Lebenszyklus einer Bestellung ist pending → placed → in_fulfillment → completed, oder cancelled, und jeder davon bedeutet, dass eine echte Bestellung existiert. Siehe Die drei Bestellstatus.

Was die Anforderung trägt

Die Bestellanforderung spiegelt die Form einer Bestellung: dieselbe Positionsstruktur, dieselben Mengen, dieselben Preise, dieselben Adressen, dieselbe Kostenstelle je Position. Sie hat eine eigene Nummer aus einem eigenen Kreis, und sobald die Bestellung existiert, verweisen beide in beide Richtungen aufeinander.

Das Spiegeln ist Absicht. Es bedeutet, dass ein Freigeber genau das ansieht, was bestellt wird, und dass die Umwandlung bei der letzten Freigabe eine Kopie ist statt einer Übersetzung — es gibt kein Feld, das auf dem einen existiert und auf dem anderen nicht, damit es jemand vergessen könnte.

Es bedeutet auch: Die Anforderung ist ein Schnappschuss. Was die Frage aufwirft, die alle als zweites stellen.

Was, wenn der Preis sich ändert, während sie wartet?

Das kann passieren. Eine am Donnerstag freigegebene Anforderung wurde am Montag bepreist. Drei Dinge können sich bewegt haben: die Preisliste, die Gültigkeit einer Aktion, und der Bestand.

Der Schnappschuss ist das, wofür der Freigeber unterschrieben hat, also wird die Bestellung daraus erzeugt. Hat sich ein Preis in der Zwischenzeit wesentlich bewegt, ist das ein kaufmännisches Gespräch — nichts, was das System still lösen sollte, indem es hinter dem Rücken des Freigebers neu bepreist. Ein Freigeber, der 4.200 € unterschreibt und 4.600 € auf der Rechnung findet, benutzt den Shop nicht wieder.

Die praktische Konsequenz: Freigabelatenz ist ein kaufmännisches Risiko, und sie ist ein weiteres Argument dafür, Schwellen so zu setzen, dass die meisten Bestellungen gar nicht warten. Bei volatilen Sortimenten — Stahl, Kupfer, alles Indizierte — schreiben Sie das in die Richtlinie des Kunden und halten Sie das Eskalationsfenster kurz.

Bestand: wann reserviert?

Nicht auf der Anforderung. Es gibt nichts, wogegen reserviert werden könnte: Noch existiert keine Bestellung, und die Inventory-App handelt mit Bestellungen.

Das ist die ehrliche Antwort und die richtige, aber sie hat eine Konsequenz, die Sie Kunden sagen sollten, bevor sie sie entdecken: Eine Anforderung ist keine Verfügbarkeitsgarantie. Eine dreitägige Freigabe auf ein Teil mit zwei Stück im Lager kann mit einer freigegebenen Anforderung und ohne Ware enden. Behandeln Sie das wie jede Bestellung mit langer Vorlaufzeit — siehe Bestand und Standorte und Teillieferungen.

Budget dagegen wird ab dem Moment des Einreichens gehalten. Geld und Bestand verhalten sich hier mit Absicht verschieden: Das Budget ist die eigene Zahl des kaufenden Unternehmens, und es zu reservieren kostet Sie nichts — der Bestand ist Ihrer, und ihn für eine nicht freigegebene Anforderung zu reservieren kostet Sie einen Verkauf.

Die Budgetbewegung

Vier Operationen, und die Anforderung treibt drei davon.

Jede davon schreibt einen Eintrag ins Budgetjournal. Nichts überschreibt eine Summe. Siehe Das Budgetjournal lesen.

Die Reservierung hängt an der Anforderung, und das macht ein wiederholtes Einreichen sicher: Ein Einkäufer, der doppelklickt, oder eine Mobilfunkverbindung, die mitten in der Anforderung abbricht, kann keine zwei Anforderungen erzeugen, die das Budget doppelt halten.

Eine laufende Anforderung ändern

Eine Anforderung in der Entscheidung ist nicht eingefroren, aber Ändern ist auch nicht kostenlos. Zwei Arten von Änderung, und sie verhalten sich verschieden:

• Verringern — eine Position entfernen, eine Menge kürzen. Der Wert fällt, die Reservierung wird nach unten angepasst, und die Anforderung kann jetzt unter eine Schwelle fallen, die sie vorher überschritt.
• Erhöhen — eine Position hinzufügen, eine Menge anheben, auf eine teurere Variante wechseln. Der Wert steigt, und die Regeln müssen neu ausgewertet werden, denn ein Betrag, der eine Unterschrift brauchte, kann jetzt zwei brauchen.

Das sichere Denkmodell: Jede Änderung wiederholt die Auswertung. Bereits gegebene Entscheidungen auf einer wesentlich geänderten Anforderung werden nicht übernommen — ein Freigeber, der für 900 € unterschrieben hat, hat nicht für 9.000 € unterschrieben. Rechnen Sie damit, dass eine geänderte Anforderung erneut zur Unterschrift geht.

Ablehnung und erneutes Einreichen

Eine abgelehnte Anforderung ist abgeschlossen. Sie wird nicht wiedereröffnet, nicht in einen neuen Versuch umgeschrieben und nicht wiederbelebt — sie bleibt als Beleg, dass dies angefragt und abgelehnt wurde, mit Grund und Person daran. Dieser Beleg ist die Audit-Kontrolle, und das Bearbeiten abgelehnter Dokumente zerstört sie.

Stattdessen beginnt der Einkäufer eine neue Anforderung, meist mit der abgelehnten als Vorlage. Das ist keine Reibung um ihrer selbst willen: Ablehnungen im B2B-Einkauf heißen fast nie „nein", sie heißen „nicht diese Menge", „nicht dieser Lieferant", „nicht dieses Quartal". Eine frische Anforderung mit der Korrektur und einem Verweis auf das Abgelehnte ist ohnehin das, was der Freigeber sehen will.

Weiter

• Der Weg des Einkäufers — eine einreichen.
• Der Weg des Freigebers — über eine entscheiden.