Pegging-Intervall
Definition
Zeitabschnitt um einen Bedarfstermin, in dem die Zugangselemente liegen, die das System beim dynamischen Pegging einem Bedarf zuordnen darf.
Zugangselemente, deren Verfügbarkeitstermine außerhalb des Pegging-Intervalls liegen, darf das System dem Bedarf nicht zuordnen. Dynamische Pegging-Beziehungen werden also nur innerhalb des Pegging-Intervalls hergestellt.
Verwendung
Idealerweise sollten Verfügbarkeits- und Bedarfstermin identisch sein. Dies lässt sich i.a. in der Planung nicht durchgängig erreichen, d.h. Verfügbarkeitstermine können früher oder später als der Bedarfstermin liegen. In einem gewissen Rahmen sind Abweichungen häufig zulässig. Ein zu später Verfügbarkeitstermin kann allerdings z.B. zu Problemen mit fehlendem Material oder mit der Einhaltung von Kundenauftragsterminen führen, ein zu früher Verfügbarkeitstermin ist wirtschaftlich nicht sinnvoll oder bringt z.B. Lagerungsprobleme mit sich. Zu späte oder zu frühe Zugänge können Sie über das Pegging-Intervall ausschließen. Für die Anzeige von Alerts spielt das Pegging-Intervall folgende Rolle:
Termin-Alerts und Pegging-Intervall
Termin-Alerts kann das System nur für Bedarfe und Zugänge erzeugen, die durch eine Pegging-Beziehung verknüpft sind, die also im Pegging-Intervall liegen. Im Lokationsproduktstamm können Sie festlegen, ab welchen zeitlichen Abweichungen zwischen Bedarfs- und Verfügbarkeitstermin das System Termin-Alerts erzeugen soll. Dabei müssen die Alert-Schwellen im Pegging-Intervall liegen; wenn die Alert-Schwellen außerhalb des Pegging-Intervalls liegen, erzeugt das System nie Alerts, da es zwischen einem Bedarf und außerhalb des Pegging-Intervalls liegenden Zugängen nie dynamische Pegging-Beziehungen herstellt.
Empfehlung
Stimmen Sie das Pegging-Intervall und die Alert-Schwellen für die Termin-Alerts sorgfältig auf Ihre Planungsanforderungen ab. Es kann z.B. sinnvoll sein, ein relativ großes Pegging-Intervall zu definieren, das auch die Verknüpfung eines Bedarfs mit verspäteten Zugängen zulässt ("Rückwärts-Pegging"), und sich durch an die Planungsanforderungen angepasste Alert-Schwellen auf die Terminprobleme aufmerksam machen zu lassen. Um bedeutungslose Alerts zu vermeiden, sollten die Alert-Schwellen nicht zu klein sein: Wenn z.B. Verspätungen bis zu sechs Stunden für Sie kein Problem darstellen, das ein planerisches Eingreifen erfordert, sollten Sie nicht eine Alert-Schwelle von einer Stunde definieren.
Mengen-Alerts und Pegging-Intervall
Wenn die Mengen der im Pegging-Intervall liegenden Zugänge nicht zur Deckung eines Bedarfs ausreichen, liegt für den Bedarf eine Unterdeckung vor. Zugänge, die das System nicht durch eine dynamische Pegging-Beziehung mit einem Bedarf verknüpfen kann, erzeugen einen Überschuss. Beachten Sie: Die primäre Ursache eines Mengen-Alerts sind fehlende Pegging-Beziehungen zwischen Bedarfen und Zugängen. Mengen-Alerts können auf tatsächlich fehlende oder überschüssige Zugänge, aber auch auf ein zu kleines Pegging-Intervall zurückzuführen sein, das die Verknüpfung ausreichend vorhandener Zugänge mit den Bedarfen verhindert. Die Summe der Zugänge kann z.B. mit der Summe der Bedarfe übereinstimmen, und trotzdem können Mengen-Alerts auftreten. Es kann daher sinnvoll sein, das Pegging-Intervall nicht zu klein zu definieren.
Das System kann bei der Einplanung von Aufträgen, die es bei der automatischen Planung neu anlegt, das Pegging-Intervall beachten und damit Unterdeckungs- und Überschussprobleme vermeiden. Ob das System die Aufträge so anlegen muss, dass die Verfügbarkeitstermine im Pegging-Intervall und (möglichst pünktlich) vor dem Bedarfstermin liegen, legen Sie in der Feinplanungsstrategie fest (siehe Beachten von Pegging-Beziehungen ).
Hinweis
Die Optimierung von Verspätungen führt das System auf der Basis von Pegging-Beziehungen durch. Wenn zwischen einem Zugang und dem verursachenden Bedarf (z.B. einem Kundenauftrag) keine Pegging-Beziehung existiert, können bei der Optimierung die Kundenauftragstermine nicht berücksichtigt werden.
Struktur
Das Pegging-Intervall legen Sie im Lokationsproduktstamm fest. Sie definieren es über die maximal erlaubten Abweichungen des Verfügbarkeitstermins vom Bedarfstermin (maximal erlaubte Verfrühung eines Zugangs und maximal erlaubte Verspätung eines Zugangs).
Beispiel
Sie haben im Lokationsproduktstamm festgelegt,
dass das System nur dann eine dynamische Pegging-Beziehung herstellen darf, wenn der Verfügbarkeitstermin eines Produkts frühestens drei Tage vor und spätestens einen Tag nach dem Bedarfstermin für das Produkt liegt
dass das System einen Alert erzeugen soll, wenn der Verfügbarkeitstermin mehr als einen Tag vor dem Bedarfstermin liegt, oder wenn er nach dem Bedarfstermin liegt
Folgende Grafik zeigt ein Beispiel für eine Planungssituation. Das Pegging-Intervall ist aus der Sicht eines Bedarfselements (gelb markiert) dargestellt, d.h. bezogen auf einen bestimmten Bedarfstermin. In dieser Sicht heißt die Frage: Welche Zugangselemente darf das System zur Deckung dieses Bedarfs verwenden?. Antwort: Das System kann dem Bedarfselement die Zugangselemente a , b oder c zuordnen. Welche der möglichen Zuordnungen das System wählt, hängt von der eingestellten Pegging-Strategie ab. Wenn das System die Zugangselemente a oder c zuordnet, erzeugt das System einen Alert für einen zu frühen bzw. für einen zu späten Zugang. Nur die Zuordnung von b ist alert-frei.
Pegging-Intervall aus der Sicht eines Bedarfselements
Das Pegging-Intervall kann auchwie in der folgenden Grafik dargestelltaus der Sicht eines Zugangselements (gelb markiert) betrachtet werden, d.h. bezogen auf einen bestimmten Verfügbarkeitstermin. In dieser Sicht heißt die Frage: Welchen Bedarfen darf das System das Zugangselement zuordnen? Antwort: Das System darf das Zugangselement den Bedarfen A , B oder C zuordnen. Wenn das System das Zugangselement den Bedarfen A oder C zuordnet, erzeugt das System eine Alert für einen zu späten bzw. zu frühen Zugang. Die Zuordnung zu B ist alert-frei.
Pegging-Intervall aus der Sicht eines Zugangselements
