MRP - Übersicht
Im Gegensatz zu APS berücksichtigt MRP keine Termine für Arbeitspläne, Ressourcenkapazitäten oder Schichten. Somit liegt es in der Verantwortung des Planers, sicherzustellen, dass die Werkstatt stets über die erforderlichen Kapazitäten zur Erfüllung des Plans verfügt. MRP generiert geplante Aufträge und Ausnahmemeldungen, um Sie bei der Implementierung eines genauen Plans zu unterstützen.
Verwendete Daten in der MRP-Planung
Die folgenden Daten werden in der MRP-Planung verwendet:
- Low-Level-Codes und Stücklisten:
Jedes Teil verfügt über einen Low-Level-Code, der die unterste Ebene angibt, auf der das Teil in allen aktuellen, Fertigungsauftrags- und Produktionsplan-Stücklisten auftritt. Einem endgültigen Teil ist immer der Low-Level-Code 0 zugeordnet. Teile auf der nächsten Stücklistenebene haben den Low-Level-Code 1, Teile auf der nächsten Ebene den Code 2 usw. Die Reihenfolge der Verarbeitung von Teilen in MRP erfolgt in Übereinstimmung mit diesen Low-Level-Codes. Jedes Teil wird immer nur auf der für das Teil angegebenen untersten Ebene verarbeitet. Aktualisieren Sie die Low-Level-Codes, indem Sie die Aktuelle Stücklistenverarbeitung und die Fertigungsauftrags-/Produktionsplan-Stücklistenverarbeitung vor Ausführung des MRP-Laufs ausführen.
Weitere Informationen finden Sie in der Beschreibung zum Feld Low Level-Code.
- Arbeitspläne:
MRP schlüsselt die Dauer von Arbeitsplänen in seiner Programmlogik nicht direkt auf. Bei der Planung freigegebener Fertigungsaufträge verwendet MRP jedoch das Startdatum eines Arbeitsplans, um eine Rückwärtsplanung für das im Arbeitsgang erforderliche Material durchzuführen, wenn das Feld Material zum Arbeitsgang-Start planen in der Maske Planungsparameter ausgewählt wurde.
Wenn Sie zusätzlich die Zeitbedarfverarbeitung verwenden, um die Zeitbedarfe für Fertigungsteile zu berechnen, werden die innerhalb des Arbeitsgangs vorgesehen Zeiten für Bearbeitung, Weitergabe, Warteschlange, Rüsten und Übergangszeit bei der Berechnung des Zeitbedarfs berücksichtigt. Aus diesem Grund ist die Angabe genauer Daten in den Arbeitsplänen für einen erfolgreiche MRP-Planung von entscheidender Bedeutung.
- Zeitbedarf für Teile:
MRP verwendet den Zeitbedarf für Teile, um die Fälligkeitstermine für geplante Aufträge zu bestimmen, die das System zur Deckung von Bedarfen generiert. Die Erstellung dieser Aufträge erfolgt anhand einer Rückwärtsplanung, die von dem Datum ausgeht, zu dem das Teil benötigt wird. In der Regel wird die Zeitbedarfverarbeitung zur automatischen Berechnung von Zeitbedarfen für Fertigungsteile verwendet. Diese Funktion legt der Berechnung die im Arbeitsplan des Teils angegebenen Daten für Weitergabe, Warteschlange, Rüsten, Bearbeitung und Übergang sowie die durchschnittliche Arbeitszeit pro Arbeitstag zugrunde.
- Verfügbarer Bestand und Eingang:
MRP berechnet die Menge des verfügbaren Bestands (also die für Kundenaufträge reservierte verfügbare Menge) zu Beginn des Prozesses als die Gesamtmenge, die an allen nicht gesperrten Lagerorten in sämtlichen Lagern des Standorts verfügbar ist. Für ein Lager mit dediziertem Bestand ist das Feld Dedizierter Bestand in der Maske Lager ausgewählt.
Eingänge, (die auch als "geplante Deckungen" bezeichnet werden) umfassen erwartete Eingangsmengen aus Fertigungsaufträgen, Produktionsplanfreigaben, HHP-Eingängen, Bestellungen und Umlageraufträgen. Wenn der Planungsparameter Bestellanforderung prüfen ausgewählt ist, werden Bestellanforderungen ebenfalls als Eingänge berücksichtigt.
Das System schließt für die Ermittlung des Nettobedarfs für ein Teil den verfügbaren Bestand und Eingänge ein.
Transit-Lagerorte müssen immer für Umlagerungen zwischen Standorten gesperrt sein. Da standortübergreifende Umlagerungen als Eingänge am Zielstandort erscheinen, muss der Transit-Lagerort gesperrt sein, damit die Menge bei MRP nicht zwei Mal berücksichtigt wird (am Anfang als erwarteter Bestand und als Eingang).
Bei Umlagerungen zwischen Lagern an einem Standort darf der von diesen Lagern verwendete Transit-Lagerort nicht gesperrt sein.
- Unabhängiger Bedarf:
Ein unabhängiger Bedarf ist ein Bedarf für ein Teil, der nicht aus einem anderen Bedarf stammt. Forecasts, Kundenaufträge und Umlageraufträge für Bedarf sind Beispiele für unabhängigen Bedarf. MRP beginnt mit der Planung unabhängiger Bedarfe und generiert "abhängige Bedarfe" für die nächste Ebene der Stückliste des Teils.
- Hauptproduktionsplan:
Mit dem Hauptproduktionsplan (HPP) können Sie die Fertigung wichtiger Endprodukte steuern und so Ihre Planung vor Schwankungen des auftragsbasierten Bedarfs schützen (z. B. Forecasts, Kundenaufträge, übergeordnete Fertigungsaufträge). Bei einem HPP handelt es sich um eine manuell erstellte, voraussichtliche Planung für ein Teil. Er basiert auf Bedarfserwartungen und Ressourcenkapazitätskalkulationen.
Wenn Sie die HPP-Verarbeitung ausführen, werden geplante Aufträge für HPP-Teilebedarfe erstellt, die außerhalb des HPP-Zeitrahmens fällig sind. Für die Komponenten in der Stückliste des HPP-Teils werden jedoch keine Aufträge erstellt. Wenn Sie MRP im Anschluss an den HPP ausführen, erstellt MRP keine geplanten Aufträge für das endgültige HPP-Teil, sondern gibt diesen Bedarf an die Komponenten aus der Stückliste des HPP-Teils in Form von geplanten Aufträgen für Komponenten weiter.
Über die MRP-Planung generierte Daten
Die Ausgabe des MRP-Prozesses umfasst geplante Aufträge, Ausnahmemeldungen und Berichte:
- Geplante Aufträge:
Bei Ausführung eines MRP-Laufs generiert das System geplante Aufträge. Dieser Vorgang wird anhand des nachfolgenden Beispiels dargestellt. Geplante Aufträge stellen die von MRP generierten Vorschläge für die Fertigung und den Einkauf des Teils zur Deckung des bestehenden Bedarfs dar. Ein geplanter Auftrag ist nicht an einen bestimmten Bedarf geknüpft.
Jeder geplante Auftrag muss geprüft und durch Bestätigung zum Beispiel in einen Fertigungsauftrag, eine Bestellung oder einen Umlagerauftrag verwandelt werden. Dabei trifft der Benutzer die endgültige Entscheidung über die Umsetzung der Vorschläge. Das Feld Quelle (dessen Wert in der Maske Teile festgelegt wird) bestimmt, in welchen Eingangstyp der geplante Auftrag nach der Bestätigung umgewandelt wird (Gefertigt = Fertigungsauftrag, Kaufteil = Bestellung, Umgelagert = Umlagerauftrag). Geplante Aufträge können in der Maske Planungsdetail der Materialplanungs-Workbench bestätigt werden.
Hinweis: In der Maske Werkstattsteuerungsparameter können Sie das Feld Geplante Aufträge terminieren auswählen, damit in der Reihenfolgeplanung die von MRP geplanten Aufträge als Bedarfe betrachtet werden, für die eine Ressourcenzuteilung erforderlich ist (dadurch wird eine realistischere Terminierungssimulation erstellt). - Ausnahmemeldungen:
In bestimmten Situationen während des MRP-Prozesses generiert das System Warnungen oder informative Alarmmeldungen, die als Ausnahmemeldungen bezeichnet werden. Eine Ausnahmemeldung wird zum Beispiel zurückgegeben, wenn der verfügbare Bestand unter den Sicherheitsbestand fällt oder wenn ein geplanter Eingang nicht mehr benötigt wird bzw. sein Bedarfsdatum auf einen früheren oder späteren Zeitpunkt verlegt wurde. Sie sollten diese Meldungen stets zur Kenntnis nehmen und anschließend ggf. erforderliche Schritte durchführen. Ausnahmemeldungen können in der Maske Planungsdetail oder in der Materialplanungs-Workbench angezeigt werden.
Eine detaillierte Beschreibung der einzelnen Ausnahmemeldungen, die das System unter gegebenen Umständen generieren kann, finden Sie unter dem Thema "Informationen über Ausnahmemeldungen".
- Berichte:
Nach der Ausführung der MRP-Planung können Sie die Materialplanungs-Workbench oder den Bericht 'Auftragsaktionen' verwenden, um die Fertigungsaufträge und Bestellungen zu ermitteln, die erstellt und freigegeben werden müssen, damit ein bestimmtes Teil zum angeforderten Termin verfügbar ist. Über den Ausnahmebericht können Sie eine Liste aller Teile drucken, für die MRP Ausnahmemeldungen zurückgegeben hat. Über diesen Bericht werden grundsätzlich dieselben Informationen ausgegeben, die auch über die Masken Planungsdetail und Materialplanungs-Workbench angezeigt werden können. Anhand der über den Bericht erstellten Auflistung der Meldungen ist es aber unter Umständen einfacher, die aufgetretenen Ausnahmen abzuarbeiten und die jeweils erforderliche Aktion auszuführen.
MRP-Planung an mehreren Standorten
Das System ist in der Lage, von MRP generierte geplante Umlageraufträge für die Zugangsstandorte in einer Multi-Site-Umgebung zu replizieren.
Es müssen Replizierungsregeln festgelegt werden, damit der Zugangsstandort Bedarfe erkennt, die von dem Standort stammen, der die MRP-Planung gestartet hat.
Weitere Informationen finden Sie unter dem Thema "Einrichten der Replizierung von geplanten Umlageraufträgen".
Arbeitsschritte und tägliche Arbeiten
Weitere Informationen über den allgemeinen MRP-Geschäftsvorgang und dazugehörige Verfahren finden Sie unter dem Thema "MRP-Schritte".
Vergleich mit APS
APS ist ebenfalls ein in SyteLine verfügbarer alternativer Planungsmodus. Im Gegensatz zu MRP berücksichtigt APS bei der Bedarfsplanung Ressourcenkapazität und Schichten. Darüber hinaus plant APS Bedarfe nach einer Auftragspriorität, da ein einzelner Bedarf vollständig über alle Ebenen der relevanten Stückliste geplant wird, und dann erst ermittelt wird, ob die Kapazität zur Planung des nächsten Bedarfs verfügbar ist. APS ist eine genauere und realistischere Planungsmethode als MRP. Die APS-Planung setzt unter Umständen aber umfangreiche Überlegungen darüber voraus, welche Einstellungen für verschiedene zusätzliche Planungsparameter erforderlich sind. Zur Erstellung eines genauen Plans über APS sind zudem exakte Arbeitsplandaten erforderlich.
Unter dem Thema "APS - Übersicht" finden Sie weitere Informationen über den APS-Planungsmodus.
Beispiel: MRP-Plan für das endgültige Teil "Fahrrad"
Zum besseren Verständnis der Methode, die MRP während des Planungsprozesses verwendet, um den Bedarf eines Teils zu decken soll eine einfache Stückliste zur Fertigung eines Fahrrads als Beispiel dienen. In diesem Beispiel wird das endgültige Teil Fahrrad aus den Baugruppen Rahmen, Rad (2 pro Teil), Griffe (2 pro Teil) und Sattel gefertigt. In der grafischen Darstellung unten wird der Low-Level-Code für jede Stücklistenebene anhand der Anzahl der Klammern repräsentiert.
Für dieses Beispiel werden folgende Ausgangsdaten zugrunde gelegt:
- Fester Zeitbedarf für Fahrrad: 3 Tage
- Aktuelles Datum: 05.04
- Verfügbarer Bestand für Fahrrad: 50
- Sicherheitsbestand für Fahrrad: 20
- Forecast für Fahrrad: 500, fällig am 11.04 (in diesem Beispiel wird davon ausgegangen, dass dieses Datum in dem Zeitraum liegt, der anhand der Felder Forecast bis Datum und Forecast ab Datum festgelegt ist.)
- Kundenauftrag 200, fällig am 20.04.
- Bestellung über Griffe: 500, fällig am 06.04.
Bei Ausführung der MRP-Planung führt das System den vollständigen Prozess für ein endgültiges Teil (und alle übrigen endgültigen Teile) durch, und geht erst dann zur nächsten Stücklistenebene über. Das System plant also zunächst alle Teil mit dem Low-Level-Code 0 nach Fälligkeitstermin. anschließend werden alle Teile mit dem Low-Level-Code 1 geplant, dann alle, die über den Low-Level-Code 2 verfügen usw., bis alle vorhandenen Low-Level-Codes geplant wurden. Der Einfachheit halber wird in diesem Beispiel nur der Prozess für die Low-Level-Codes 0 und 1 verfolgt.
Im Folgenden wird die Verarbeitung für Low-Level-Code 0 (Endprodukt) beschrieben:
- Es werden die Forecasts für das Teil mit den Kundenaufträge verglichen, um den tatsächlichen Nettobedarf zu ermitteln. In diesem Beispiel hat der Forecast eine ursprüngliche Menge von 500. Der einzige Kundenauftrag in diesem Beispiel (über eine Menge von 200) „verbraucht“ diesen Bedarf bis auf 300. MRP legt bei der Planung diese Menge als einen unabhängigen Bedarf zugrunde.
- Es folgt die Erstellung des unabhängigen Bedarfs für das endgültige Teil.
- Forecast 300
- Kundenauftrag 200
Hinweis: Dieses Beispiel enthält jeweils nur einen Kundenauftrag und Forecast. Bei einer tatsächlichen Planung würden jedoch auch andere Bedarfe wie Fertigungs- und Umlageraufträge und Projektressourcen berücksichtigt.
- Der zum Planungsstart verfügbare Lagerbestand wird berechnet. In diesem Beispiel beträgt der verfügbare Bestand 50.
- Liegt der verfügbare Bestand - anders als in diesem Beispiel - bei Planungsstart unter dem Sicherheitsbestand, werden folgende Schritte durchgeführt:
- Es wird eine Ausnahmemeldung generiert, die den Benutzer darüber informiert, dass der Lagerbestand niedriger als der Sicherheitsbestand ist.
- Es werden geplante Eingänge (Fertigungsaufträge, Bestellungen usw.) gesucht, die in den Zeitrahmen für die Neuplanung von Fertigungsaufträgen oder den Zeitrahmen für die Neuplanung von Bestellungen fallen, um den Sicherheitsbestand abzudecken und die entsprechende Ausnahmemeldung (je nach Sachverhalt Eingang bzw. Ausgang) zu generieren. Wenn die geplanten Eingänge den Sicherheitsbestand nicht decken, generiert das Systeme einen geplanten Auftrag, dessen Fälligkeitstermin dem Datum entspricht, an dem der Bestand unter den Sicherheitsbestand gefallen ist.
- Es werden alle Bedarfe für das Teil verarbeitet. Für jeden Bedarf wird die Bestellmenge vom Lagerbestand subtrahiert. Handelt es sich bei dem Bedarf um einen Forecast und wurde der Parameter Kundenauftrag oder Forecast? auf Forecast gesetzt, wird die gesamte Forecast-Menge vom Lagerbestand subtrahiert. Wurde dieser Parameter auf Beide gesetzt, wird nur die ausstehende Menge (das heißt, die Menge, die nicht durch Kundenaufträge verbraucht wurde) vom Lagerbestand subtrahiert.
Fällt der Lagerbestand unter den Sicherheitsbestand, nachdem die Menge des angeforderten Bedarfs vom Lagerbestand subtrahiert wurde, werden folgende Schritte durchgeführt:
- Es wird eine Ausnahmemeldung generiert, die den Benutzer darüber informiert, dass der Lagerbestand niedriger als der Sicherheitsbestand ist.
- Das System sucht nach geplanten Eingängen (Fertigungsaufträge, Bestellungen usw.), die in den Zeitrahmen für die Neuplanung fallen, um den Sicherheitsbestand abzudecken. Falls erforderlich, wird eine Ausnahmemeldung generiert. Wenn die vorhandenen Eingängen den Sicherheitsbestand nicht decken, wird ein geplanter Auftrag zur Deckung des Sicherheitsbestand und des ungedeckten Bedarfs generiert. Das System berücksichtigt den geplanten Auftrag als Platzhalter für den Eingang, der später durch die Bestätigung des Planers zum Beispiel in einen Fertigungsauftrag oder eine Bestellung umgewandelt wird. In diesem Beispiel sind keine vorhandenen Eingänge verfügbar, deshalb erstellt das System zwei geplante Aufträge (Planned Order, PLN): einen für die Menge des Forecasts (zuzüglich der Menge für die Abdeckung des Sicherheitsbestandes) und einen zur Erfüllung des Kundenauftrags:
- PLN 1: 270 (300 (Netto-Forecast-Menge) - 50 (Verfügbarer Bestand) + 20 (zur Deckung des Sicherheitsbestands)), fällig am 11.04.
- PLN 2: 200 (zur Deckung des Kundenauftrags), fällig am 20.04.
In der Maske Planungsdetail würde der Plan für das Teil Fahrrad ungefähr folgendermaßen aussehen:
Hinweis: Je nach Fälligkeitsterminen und in Abhängigkeit der Einstellung, die für dieses Teil im Feld „Planungstage“ angegeben wurde, können die geplanten Aufträge PLN 1 und PLN 2 zu einem geplanten Auftrag mit einer Gesamtmenge von 470 konsolidiert werden. - Die geplanten Aufträge für dieses Teil werden an das Komponentenmaterial auf der nächsten Ebene der Stückliste weitergegeben. In diesem Schritt wird der Bedarf für dieses Teil bis zur nächsten Stücklistenebene aufgeschlüsselt, um den abhängigen Bedarf für die Komponenten zu generieren.
- Alle geplanten Aufträge, die im letzten Schritt erstellt oder aktualisiert wurden, werden an die aktuelle Stückliste weitergegeben, um übergeordnete geplante Aufträge (Parent Planned Order, PPLN) für die entsprechenden Komponenten zu erstellen. In diesem Beispiel generiert das System den folgenden Bedarf auf Basis von übergeordneten geplanten Aufträgen:
Komponente Anforderungen Fäll.-Term. Rahmen-Baugruppe PPLN 1: 270 PPLN 2: 200
7.4. 15.4.
Rad-Baugruppe PPLN 1: 540 PPLN 2: 400
7.4. 15.4.
Griffe PPLN 1: 540 PPLN 2: 400
7.4. 15.4.
Sattel-Baugruppe PPLN 1: 270 PPLN 2: 200
7.4. 15.4.
Hinweis: Das Lieferdatum des Komponentenbedarfs entspricht dem Lieferdatum des übergeordneten Bedarfs minus dem Zeitbedarf für das endgültige Teil. Bei dieser Berechnung werden nur die Fertigungstage zugrunde gelegt, die im FTag-Kalender definiert wurden. - Alle Fertigungsauftragseingänge, die in Schritt 5 ermittelt wurden, werden an die FA-Stückliste weitergegeben (sofern vorhanden, ansonsten erfolgt die Weitergabe an die aktuelle Stückliste), um übergeordnete FA-Bedarfe (Parent Job Requirement, PJOB) für die entsprechenden Komponenten zu erstellen. Dieses Beispiel enthält jedoch keine Fertigungsauftragseingänge für das endgültige Teil.
- Alle Produktionsplaneingänge werden an die Stückliste des Produktionsplan weitergegeben (sofern vorhanden, ansonsten erfolgt die Weitergabe an die aktuelle Stückliste), um übergeordnete PP-Bedarfe (Parent Production Schedule, PPS) für die entsprechenden Komponenten zu erstellen. Dieses Beispiel enthält jedoch keine Produktionsplaneingänge für das endgültige Teil.
- Alle geplanten Aufträge, die im letzten Schritt erstellt oder aktualisiert wurden, werden an die aktuelle Stückliste weitergegeben, um übergeordnete geplante Aufträge (Parent Planned Order, PPLN) für die entsprechenden Komponenten zu erstellen. In diesem Beispiel generiert das System den folgenden Bedarf auf Basis von übergeordneten geplanten Aufträgen:
- Die oben aufgeführten Schritte werden zur Planung des nächsten Teils wiederholt. Sobald das letzte Teil mit dem Low-Level-Code 0 geplant wurde, geht das System zur Planung der Teile mit dem Low-Level-Code 1 über.
Im Folgenden wird die Verarbeitung für Teile mit Low-Level-Code 1 beschrieben: Der Einfachheit halber wurde der nachfolgende Prozess für alle Teile, die über den Low-Level-Code 1 verfügen, zusammengefasst. Bei der tatsächlichen Verarbeitung im System würden die unten aufgeführten Schritte nacheinander für jedes Teil mit dem Low-Level-Code 1 separat durchgeführt.
- Es werden die Forecasts für das Teil mit den Kundenaufträge verglichen, um den tatsächlichen Nettobedarf zu ermitteln. Dieses Beispiel enthält keine Forecasts für Teile, die über den Low-Level-Code 1 verfügen.
- Der Bedarf für das Teil wird erstellt. Die Bedarfe für Teile aus der Stückliste wurden ausgehend vom endgültigen Teil weitergegeben. In diesem Beispiel wurden die folgenden Bedarfe weitergegeben:
Komponente Anforderungen Fäll.-Term. Rahmen-Baugruppe PPLN 1: 270 PPLN 2: 200
7.4. 15.4.
Rad-Baugruppe PPLN 1: 540 PPLN 2: 400
7.4. 15.4.
Griffe PPLN 1: 540 PPLN 2: 400
7.4. 15.4.
Sattel-Baugruppe PPLN 1: 270 PPLN 2: 200
7.4. 15.4.
- Der zum Planungsstart verfügbare Lagerbestand wird berechnet. In diesem Beispiel ist für keine der erforderlichen Komponenten Lagerbestand verfügbar.
- Ist der Lagerbestand bei Planungsstart niedriger als der Sicherheitsbestand, generiert das System Ausnahmemeldungen und geplante Aufträge zur Deckung des Sicherheitsbestands wie weiter oben im Abschnitt Verarbeiten von endgültigen Teilen mit dem Low-Level-Code 0 beschrieben.
- Die Verarbeitung der Bedarfe für das Teil erfolgt wie oben im Abschnitt Verarbeiten von endgültigen Teilen mit dem Low-Level-Code 0 beschrieben. Es werden geplante Aufträge zur Deckung ungedeckter Bedarfe erstellt:
Komponente Anforderungen Resultierender PLN Rahmen-Baugruppe PPLN 1: 270 PPLN 2: 200
PLN 3: 270 PLN 4: 200
Rad-Baugruppe PPLN 1: 540 PPLN 2: 400
PLN 5: 540 PLN 6: 400
Griffe PPLN 1: 540 PPLN 2: 400
PLN 7: 40 PLN 8: 400
Sattel-Baugruppe PPLN 1: 270 PPLN 2: 200
PLN 9: 270 PLN 10: 200
Hinweis: Für die Komponente Griffe lautet PLN 7 nur über 40 Stück, da die Bestellung über 500 Stück zur Deckung des PPLN-Bedarfs in Höhe von 500 Stück verwendet wird.In der Maske Planungsdetail würde der Plan für das Teil Rahmen-Baugruppe ungefähr folgendermaßen aussehen:
Der Plan für die Komponente Griffe würde ungefähr folgendem Plan entsprechen:
- Die geplanten Aufträge für dieses Teil werden an das Komponentenmaterial auf der nächsten Ebene der Stückliste weitergegeben. In diesem Schritt wird der Bedarf für dieses Teil über die gesamte Stückliste aufgeschlüsselt, um den abhängigen Bedarf für die Komponenten zu generieren.
- Alle geplanten Aufträge, die im letzten Schritt erstellt oder aktualisiert wurden, werden an die aktuelle Stückliste weitergegeben, um übergeordnete geplante Aufträge (Parent Planned Order, PPLN) für die entsprechenden Komponenten zu erstellen. In diesem Beispiel gibt das System den Bedarf geplanter Aufträge an die Komponenten mit dem Low-Level-Code 2 weiter.
- Alle Fertigungsauftragseingänge, die im vorangegangenen Schritt ermittelt wurden, werden an die FA-Stückliste weitergegeben (sofern vorhanden, ansonsten erfolgt die Weitergabe an die aktuelle Stückliste), um übergeordnete FA-Bedarfe (Parent Job Requirement, PJOB) für die entsprechenden Komponenten zu erstellen. Dieses Beispiel enthält jedoch keine Fertigungsauftragseingänge für Komponenten.
- Alle Produktionsplaneingänge werden an die Stückliste des Produktionsplan weitergegeben (sofern vorhanden, ansonsten erfolgt die Weitergabe an die aktuelle Stückliste), um übergeordnete PP-Bedarfe (Parent Production Schedule, PPS) für die entsprechenden Komponenten zu erstellen. Dieses Beispiel enthält einen Produktionsplan für das Teil Griffe, dieses Teil setzt sich jedoch nicht aus Komponenten zusammen.
- Die oben aufgeführten Schritte werden zur Planung des nächsten Teils wiederholt. Sobald das letzte Teil mit dem Low-Level-Code 1 geplant wurde, geht das System zur Planung der Teile mit dem Low-Level-Code 2 über.