Der Auftrag ist bestätigt, die Werkstatt hat Zeit und die meisten Teile liegen bereit. Trotzdem steht die Montage, weil eine kleine Unterbaugruppe fehlt. Für einen Fertigungs- oder Handwerksbetrieb im Kreis Göppingen ist eine digitale Materialplanung deshalb vor allem eine Organisationsaufgabe: Sie muss zeigen, was für einen konkreten Auftrag tatsächlich verfügbar ist und wann der Rest benötigt wird.
Eine volle Lagerhalle beantwortet diese Frage nicht. Entscheidend sind Stücklisten, verwendbare Bestände, Reservierungen und bestätigte Liefertermine. Der folgende Beispielauftrag ist frei gewählt. Er erklärt die Rechenschritte, ohne ein bestimmtes Produktionssystem oder eine lokale Firma als Referenz zu behaupten.
Die Stückliste ist die Grundlage, nicht der Server
Ein gemeinsam genutztes Planungssystem kann auf einer lokalen Plattform laufen. Wer dabei nach „tower server“ sucht, sollte zuvor Benutzerzahl, Datenbank und benötigte Verfügbarkeit festlegen. Ein Tower benötigt kein klassisches Rack, aber einen geeigneten Aufstellplatz. Fehlerhafte Mengen in der Stückliste bleiben unabhängig von der Hardware fehlerhaft.
ERPNext beschreibt eine Bill of Materials als Liste von Teilen und Unterbaugruppen mit den jeweils benötigten Mengen. Das System unterstützt auch mehrstufige Stücklisten. Diese Grundidee ist produktunabhängig nützlich: Eine Baugruppe kann selbst aus weiteren Teilen bestehen, deren Bedarf bis zur tatsächlich beschafften Komponente aufgelöst werden muss.
Eine gemeinsame Komponente über alle Ebenen zählen
Angenommen, ein Auftrag umfasst zwölf Einheiten. Jede benötigt zwei Halterungen. Jede Halterung benötigt drei Schrauben. Der Auftrag erzeugt damit einen Bedarf von 24 Halterungen und 72 Schrauben für diese Unterbaugruppen. Vier direkt im Endprodukt verbaute Schrauben je Einheit erhöhen den Gesamtbedarf um weitere 48 auf 120 Stück.
Wer nur die oberste Ebene betrachtet, sieht möglicherweise die Halterungen und die direkten Schrauben, aber nicht deren inneren Bedarf. Umgekehrt darf der Bedarf einer bereits vollständig verfügbaren Unterbaugruppe nicht beliebig nochmals als Einzelteilentnahme verbucht werden. Planung und tatsächliche Verbrauchsbuchung müssen dieselbe Fertigungslogik abbilden.
Der Test beginnt mit einer überschaubaren Baugruppe, die sich von Hand nachrechnen lässt. Ein Mitarbeiter aus der Fertigung bestätigt Mengen und Einheiten. Erst danach wird eine größere Stückliste eingelesen. Ein technisch erfolgreicher Import ist kein Beweis, dass der Inhalt fachlich stimmt.
Physischer Bestand und verfügbarer Bestand unterscheiden
Für die benötigten Schrauben seien 90 Stück im Lager erfasst. Davon sind 20 für einen anderen bestätigten Auftrag reserviert und zehn gesperrt. Dann stehen 60 zur Verfügung. Gegenüber dem Bedarf von 120 fehlen 60. Die Aussage „90 auf Lager“ würde die Situation zu günstig darstellen.
Eine angekündigte Lieferung von 100 Stück hilft nur, wenn sie rechtzeitig eintrifft und für diesen Bedarf verfügbar ist. Der Status „bestellt“ ist deshalb nicht mit „verwendbar“ gleichzusetzen. Im System werden erwarteter Eingang, bestätigter Termin und tatsächlicher Wareneingang getrennt geführt.
Auch Rückläufer oder Teile in Prüfung dürfen nicht automatisch als frei verfügbar gelten. Die Statusregeln sollten wenige, eindeutige Kategorien verwenden. Wenn gesperrte Ware nur in einem Freitextkommentar erwähnt wird, kann die Bedarfsrechnung sie weiterhin fälschlich einplanen.
Einheiten und Verpackungen ausdrücklich abbilden
Der Einkauf bestellt Schrauben vielleicht in Packungen zu 100 Stück, die Fertigung verbraucht einzelne Stück. Der Beschaffungsvorschlag für 60 fehlende Schrauben kann dann eine Packung sein. Eine zweite Multiplikation beim Wareneingang würde aus 100 plötzlich 10.000 Stück machen. Die Umrechnung gehört deshalb in eine kontrollierte Stammdateneinstellung.
Bei Material nach Länge oder Gewicht kommen andere Regeln hinzu. Meter, Millimeter und Stück sind nicht austauschbar. Für jede Position wird festgelegt, in welcher Einheit die Stückliste rechnet und wie Einkaufs- und Lagereinheit zusammenhängen. Rundungen erfolgen an der sachlich richtigen Stelle, etwa auf eine lieferbare Verpackung.
Ein Ausschusszuschlag wird ebenfalls begründet. Werden für 120 benötigte Teile fünf Prozent zusätzlicher Bedarf eingeplant, ergeben sich 126 Stück. Das ist eine andere Rechnung als die Annahme, nur 95 Prozent der beschafften Teile seien verwendbar: Dann wären rechnerisch 120 / 0,95, also aufgerundet 127 Stück erforderlich. Die gewählte Bedeutung muss klar sein.
Der Bedarf braucht ein Datum
Ein Teil, das erst zur Endmontage benötigt wird, muss nicht zwingend gleichzeitig mit dem Rohmaterial für den ersten Arbeitsschritt eintreffen. Eine terminierte Planung verknüpft die benötigte Menge mit dem Zeitpunkt der Verwendung. Die ERPNext-Dokumentation zur Materialbedarfsplanung berücksichtigt dazu unter anderem Bedarf und Vorlaufzeiten.
Für einen fiktiven Einkauf seien sieben Arbeitstage Lieferzeit, zwei Tage interne Prüfung und ein Tag Reserve vorgesehen. Der Auftrag muss dann mindestens zehn Arbeitstage vor dem Bedarf ausgelöst werden. Ob Feiertage und betriebliche Schließtage mitzählen, richtet sich nach dem vereinbarten Kalender; sie dürfen nicht stillschweigend wie normale Arbeitstage behandelt werden.
Lieferzeiten sind keine Naturkonstanten. Änderungen werden mit Datum und Herkunft erfasst. Ein veralteter Standardwert kann einen neuen Auftrag rechnerisch pünktlich erscheinen lassen, obwohl der Lieferant bereits einen späteren Termin bestätigt hat.
Planungsstand und freigegebener Auftrag trennen
Eine Angebotsvariante darf noch nicht automatisch das gleiche Material blockieren wie ein freigegebener Fertigungsauftrag. Andernfalls wirken Bestände knapp, obwohl mehrere unverbindliche Entwürfe dieselben Teile reservieren. Umgekehrt muss die Freigabe rechtzeitig eine verlässliche Reservierung erzeugen.
Für Änderungen ist sichtbar, welche Aufträge betroffen sind. Wird eine Halterung durch eine andere Ausführung ersetzt, braucht nicht jede bereits begonnene Fertigung denselben Änderungsweg. Das System muss den tatsächlichen Auftragsstand bewahren, statt rückwirkend alle Stücklistenverwendungen auf den neuesten Entwurf umzudeuten.
Eine autorisierte Person entscheidet über Ersatzmaterial und dokumentiert die Grundlage. Ein verfügbarer Artikel mit ähnlicher Bezeichnung ist nicht automatisch ein technisch zulässiger Ersatz. Diese Entscheidung lässt sich nicht allein aus Menge und Preis ableiten.
Mit drei Kontrollfällen beginnen
Der erste Testfall ist ein Auftrag mit vollständig verfügbaren Teilen. Der zweite enthält eine gemeinsame Komponente auf mehreren Stücklistenebenen. Der dritte hat genug physischen Bestand, aber eine Reservierung für einen anderen Auftrag. In jedem Fall wird der erwartete Nettobedarf vorab von Hand bestimmt.
Danach folgen eine verspätete Lieferung und eine geänderte Auftragsmenge. Die Anwendung sollte erkennen lassen, welche Beschaffungsvorschläge sich ändern und welche bereits ausgelösten Bestellungen bestehen bleiben. Eine neue Planung darf keine unkontrollierten Doppelbestellungen erzeugen.
Technisch wird der geplante gleichzeitige Betrieb geprüft: mehrere Mitarbeiter suchen Positionen, während eine Planung läuft und Bestände aktualisiert werden. Erst wenn hierbei Ressourcen fehlen, lässt sich eine Serveraufrüstung begründen. Die Zahl der Artikel allein sagt wenig über die benötigte Ausstattung.
Erfolg an Fehlteilen und Nacharbeit messen
Für einen angenommenen Monat mit 40 Fertigungsaufträgen verursachen acht Aufträge ungeplante Materialrückfragen. Das sind 20 Prozent. Nach einer Verbesserung werden Auftragszahl, Fehlteilgründe und gebundene Arbeitszeit nach derselben Definition erfasst. Ein kleinerer Bestand ist nicht automatisch ein Erfolg, wenn dadurch mehr Arbeit stehen bleibt.
Der praktische Nutzen einer sauberen Materialplanung liegt in erklärbaren Entscheidungen: warum eine Menge fehlt, wann sie benötigt wird und welche Bestellung sie decken soll. Für kleine Betriebe ist diese Nachvollziehbarkeit wichtiger als ein möglichst komplexer Algorithmus. Sie entsteht aus verlässlichen Stammdaten und getesteten Regeln, auf denen die Serveranwendung aufbauen kann.
PM
