Auftragsfluss & Zustände

Eine Bestellung. Der ganze Weg.

Klick dich durch die Phasen — jede zeigt ihr Ziel und was der Stack dort tut. Was Nordwerk vom reinen ERP unterscheidet: ein geschlossener Optimierungs-Kreislauf.

Aufträge

Maschinen

Lieferungen

Wartungen

Ganzen Ablauf als PDF ↓

Akt I · Anbahnung

→ →

Akt II · Auftrag → Lieferung

→ → → → →

Akt III · Nach der Lieferung

→ →

Was Nordwerk vom reinen ERP unterscheidet.

Ein geschlossener Kreislauf: Maschinendaten fließen zurück in bessere Fertigung.

Maschinen

→

Historian

→

BI · Wartung

→

Digital Twin

→

Fertigung

↺

Telemetrie → Auswertung → optimierte Parameter → zurück in die Fertigung.

Ganzer Ablauf — die ausführliche Doku +

Nordwerk — Auftragsfluss & Zustände (mit Stack-Abdeckung)

Zweck: Der komplette Betrieb der Demo-Firma Nordwerk Manufacturing (fiktiver B2B-CNC-/Metallteile-Hersteller, make-to-order) als ein durchgehender Fluss — von der ersten Anfrage über den Bestelleingang bis zur fertigen Lieferung, und weiter bis Service und Reklamation. Für jede Phase steht: welche Zustände ein Auftrag durchläuft (Geschäftssprache + echter System-Status) und was unser Stack dabei tut — inkl. Anlagen, Produktionsoptimierung und Digital Twin.

Schwester-Dokument: PROZESS-ROADMAP.md (Schritte P0–P12, Personas, Coverage). Dieses hier ist die Zustands-/Ablauf-Sicht mit Stack-Zuordnung.

Lesehilfe: Status stehen als Geschäftssprache technischer Odoo-Status. ✅ = klickbare read-only Demo vorhanden. Alle Zahlen/Status sind aus der laufenden Demo-DB (met18/nordwerk) verifiziert, nicht erfunden.

1 · Gesamtüberblick

flowchart TD
    subgraph A["AKT I · Anbahnung"]
      P0["Web / Marketing\n(Anfrage)"] --> P1["Lead / CRM\nqualifizieren"]
      P1 --> P2["Angebot + Kalkulation\n(Digital-Twin-What-if)"]
      P2 --> P3["Auftrag / AB\n★ BESTELLEINGANG"]
    end
    subgraph B["AKT II · Auftrag → Lieferung (Kern)"]
      P3 --> P4["Arbeitsvorbereitung\nMRP / Routing"]
      P4 --> P5["Beschaffung\nEinkauf + Wareneingang"]
      P4 --> P6["Fertigung\nLeitstand · Anlage · Twin"]
      P5 --> P6
      P6 --> P7["Qualitätssicherung\ni.O. / n.i.O."]
      P7 --> P8["Lager / Kommissionierung\n+ Versand"]
      P8 --> P9["★ LIEFERUNG\n+ Rechnung"]
    end
    subgraph C["AKT III · Nach der Lieferung"]
      P9 --> P10["Service / Wartung\n(Servicevertrag)"]
      P9 --> P11["Reklamation /\nSchadensfall"]
      P10 --> P12["Auswertung\nKPIs · KVP"]
      P11 --> P12
      P9 --> P12
    end
    P6 -. "Telemetrie" .-> HIST[("Historian")]
    HIST -. "Optimierung / vorausschauende Wartung" .-> P6
    HIST -. "Process-Drift / OEE" .-> P12

Stack auf einen Blick

Baustein	Rolle im Fluss	Demo
ERP (Odoo)	Heimat aller Auftrags-Zustände: Lead, Angebot, Auftrag, Einkauf, Fertigung, Lager, Rechnung, Wartung, Reklamation	erp-demo.indystry.works ↗ (demo/demo) ✅
BI (Metabase + Grafana)	Auslastung, OEE, Ausschuss, Process-Drift, Mass-Balance, Liefertreue, GF-Cockpit	bi-demo ↗ · grafana-demo ↗ ✅
Historian	Zeitreihen (Temperatur/Vibration) je Maschine → Optimierung + vorausschauende Wartung	/historian/ → ✅
Leitstand / SCADA	Live-Zustand jeder Maschine (läuft / Wartung fällig / Leerlauf / Störung)	/leitstand/ → ✅
Anlagen-Twin / 3D	Werk → Linie → Maschine → Schaltschrank → Stromlaufplan (beherrschen, entstören)	/anlage/ → ✅
Digital Twin	What-if-Simulation Durchsatz/Ausschuss/Kosten — Angebot + Produktionsoptimierung	twin-demo.indystry.works ↗ ✅
KI-Suche	„Frag die Firma" über Produkte/Maschinen/Aufträge/Handbuch	/suche/ → ✅
Zusammenarbeit	Dateiraum (Angebote/Zeichnungen/Prüfprotokolle), versioniert, kommentierbar	/zusammenarbeit/ → ✅
Wissen / Kiosk	Handbuch, Compliance-Register, App-Launcher	/wissen/ → ✅
Betrieb / Status	Dienste, Backups, Uptime — alles selbst gehostet	/status/ → ✅

AKT I · Anbahnung

P0–P1 · Erstkontakt & Lead-Qualifizierung

Ziel: Anfrage erfassen, qualifizieren, zur Chance machen. Schritte: Website/Anfrage → Lead anlegen → Bedarf erfassen → Qualifizierung → Opportunity.

Geschäftssprache	System-Status `crm.lead`	Auslöser	Wer	Nächster Schritt
Neuer Lead	`Neu` (New)	Anfrage / Formular	Sandra, Marco	qualifizieren
Qualifiziert	`Qualifiziert` (Qualified)	Bedarf/Budget geklärt	Marco, Lena	Angebot erstellen
Im Angebot	`Angebot` (Proposition)	Angebot raus	Lena	nachfassen
Gewonnen / Verloren	`Gewonnen` (Won) / lost	Zu-/Absage	Marco	→ Auftrag (P3)

stateDiagram-v2
    [*] --> Neu
    Neu --> Qualifiziert
    Qualifiziert --> Angebot
    Angebot --> Gewonnen
    Angebot --> Verloren
    Gewonnen --> [*]
    Verloren --> [*]

Was unser Stack hier macht: ERP/CRM führt die Pipeline (Demo-Stand: 2 neu · 1 qualifiziert · 1 im Angebot · 2 gewonnen). KI-Suche findet Kundenhistorie/ähnliche Anfragen. Web liefert den Lead. Personas: Sandra (Marketing), Marco (Außendienst), Lena (Innendienst), Kunde.

P2 · Angebot, Kalkulation & Digital-Twin-What-if

Ziel: Technische Klärung + belastbares Angebot mit Liefertermin. Schritte: Zeichnung/Spez prüfen → Machbarkeit → Kalkulation (Material + Zeit + Maschine) → Twin-Simulation → Angebot.

Geschäftssprache	System-Status `sale.order`	Auslöser	Wer	Nächster Schritt
Angebot (Entwurf)	`draft`	aus Chance erzeugt	Lena	versenden
Angebot gesendet	`sent`	an Kunde	Lena	nachfassen / bestätigen

Was unser Stack hier macht: ERP kalkuliert aus Stückliste (BOM) + Arbeitsplan automatisch. Digital Twin (twin-demo ↗) simuliert Durchsatz / Ausschuss / Kosten als What-if, bevor zugesagt wird → realistischer Preis + Termin. Zusammenarbeit hält Zeichnungen/Angebote versioniert. Personas: Lena, Thomas (AV), Petra (Machbarkeit), Kunde.

P3 · Auftrag & Auftragsbestätigung — ★ Bestelleingang

Ziel: Bestellung verbindlich machen — hier beginnt der Auftragsdurchlauf. Schritte: Kundenbestellung → Prüfung → Bestätigen → Auftrag im ERP, AB an Kunde.

Geschäftssprache	System-Status `sale.order`	Auslöser	Wer	Nächster Schritt
Auftrag (Bestelleingang)	`sale`	„Bestätigen"	Lena	löst MRP + Lieferung aus
Abgeschlossen / gesperrt	`done` (locked)	nach Abwicklung	System	Archiv

stateDiagram-v2
    [*] --> Angebot_draft
    Angebot_draft --> Angebot_sent: versenden
    Angebot_sent --> Auftrag_sale: bestätigen ★
    Angebot_draft --> Auftrag_sale: bestätigen ★
    Auftrag_sale --> Abgeschlossen_done
    Abgeschlossen_done --> [*]

Was unser Stack hier macht: Mit dem Bestätigen erzeugt ERP automatisch die Fertigungsaufträge (MRP) und die Lieferung (Picking) — keine Doppelerfassung. Demo-Stand: 22 bestätigte Aufträge (sale) + 6 offene Angebote (draft). Personas: Lena, Birgit (Konditionen), Kunde.

AKT II · Auftrag → Lieferung (Kern)

P4 · Arbeitsvorbereitung & Planung

Ziel: Auftrag fertigungsreif machen + einplanen. Schritte: Stückliste → Arbeitsplan/Routing → Materialbedarf (MRP) → Terminierung → Maschinen-/Schichtbelegung.

Was unser Stack hier macht: ERP/MRP erzeugt Bedarfe + Fertigungsaufträge aus dem Auftrag. BI zeigt Maschinen-Auslastung je Linie (Engpässe früh). Leitstand zeigt, welche Maschine frei/belegt ist. Anlagen-Twin liefert die Maschinen-/Linienstruktur (3 Linien, 8 Maschinen). Personas: Thomas (AV/PPS), Frank (Fertigungsleiter), Bernd (Einkauf-Trigger).

P5 · Beschaffung & Wareneingang

Ziel: Material termin- und mengengerecht bereitstellen.

Geschäftssprache	System-Status `purchase.order`	Auslöser	Wer
Anfrage / RFQ	`draft`	Bedarf aus MRP	Bernd
Bestellung bestätigt	`purchase`	Lieferant gewählt	Bernd
Erledigt	`done`	abgeschlossen	System

stateDiagram-v2
    [*] --> RFQ_draft
    RFQ_draft --> Bestellung_purchase: bestätigen
    Bestellung_purchase --> Erledigt_done
    Erledigt_done --> [*]

Wareneingang läuft als stock.picking (siehe P8-Diagramm, Richtung eingehend). Was unser Stack hier macht: ERP schlägt Bestellungen aus dem Bedarf vor (Demo: 4 RFQ · 4 bestätigt), bucht Wareneingang + Eingangsprüfung ins Lager. Wissen hält Lieferanten-Zertifikate. Personas: Bernd (Einkauf), Klaus (Lager), Petra (Eingangs-QS), Lieferant.

P6 · Fertigung & Leittechnik — bis auf den Schaltschrank

Ziel: Teile in Qualität + Termin produzieren; Anlage beherrschen. Schritte: Fertigungsauftrag freigeben → Rüsten → Produktion → Live-Leitstand → Werker-Rückmeldung → Störungsbehandlung.

Geschäftssprache	System-Status `mrp.production`	Auslöser	Wer
Entwurf	`draft`	aus Auftrag erzeugt	System
Bestätigt / eingeplant	`confirmed`	freigegeben	Thomas/Frank
In Arbeit	`progress`	Rüsten/Start	Ali (Werker)
Abzuschließen	`to_close`	Menge gemeldet	Ali
Erledigt	`done`	gebucht	Frank

stateDiagram-v2
    [*] --> Entwurf_draft
    Entwurf_draft --> Bestätigt_confirmed: freigeben
    Bestätigt_confirmed --> InArbeit_progress: rüsten/starten
    InArbeit_progress --> Abzuschließen_to_close: Menge melden
    Abzuschließen_to_close --> Erledigt_done: buchen
    Erledigt_done --> [*]

Demo-Stand: 18 confirmed + 22 to_close (laufender Betrieb).

Was unser Stack hier macht (Kernstück):

Leitstand / SCADA (/leitstand/ →) — Echtzeit-Kacheln aller 8 Maschinen mit läuft / Wartung fällig / Leerlauf / Störung + Live-Temperatur/Vibration.
Anlagen-Twin / 3D (/anlage/ →) — Drilldown Werk → Linie → Maschine → Schaltschrank → Stromlaufplan (SPS, Antriebe/FU, Klemmen, Sicherungen). Für Rüsten, Verstehen, Entstören.
Digital Twin (twin-demo ↗) — Simulation der Linie (Parameter, Engpass).
Historian (/historian/ →) — jede Messreihe je Maschine.
BI — Live-Cockpit (Stückzahlen, Ausschuss, OEE).
ERP/BDE — Werker-Rückmeldung Gut/Ausschuss/Zeit (treibt die mrp.production-Zustände oben). Personas: Frank (Schichtleiter), Ali (Werker), Jens (Instandhaltung/Automatisierung).

P7 · Qualitätssicherung

Ziel: Konformität sichern + dokumentieren.

Geschäftssprache	Status	Auslöser	Wer
Prüfung offen	— (Prüfauftrag)	nach Fertigung	Petra/Ali
i.O.	`passed = true`	im Grenzbereich	Petra
n.i.O.	`passed = false`	außerhalb Grenzwert	Petra → Sperre

Was unser Stack hier macht: Messwerte je Auftrag (Maßhaltigkeit, Oberflächenrauheit, Gewicht) liegen im Warehouse (factory.quality_check) mit Grenzwerten; automatische i.O./n.i.O.-Bewertung. BI wertet Ausschussquote / Cpk aus. Wissen liefert Prüfprotokoll/Zertifikat. (Kein separates Odoo-Quality-Modul — QS läuft über Warehouse + BI.) Personas: Petra (QS), Ali (Selbstprüfung), Frank.

P8 · Lager, Kommissionierung & Versand

Ziel: Fertigware bereitstellen + verpacken.

Geschäftssprache	System-Status `stock.picking`	Auslöser	Wer
Entwurf	`draft`	aus Auftrag	System
Wartet auf Material	`waiting` / `confirmed`	Bestand fehlt	System
Bereit	`assigned`	Bestand reserviert	Klaus
Erledigt	`done`	validiert/gebucht	Klaus

stateDiagram-v2
    [*] --> Entwurf_draft
    Entwurf_draft --> Wartet_confirmed: reservieren
    Wartet_confirmed --> Bereit_assigned: Bestand da
    Bereit_assigned --> Erledigt_done: validieren ★ Lieferung
    Erledigt_done --> [*]

Demo-Stand: 6 assigned (bereit) · 8 confirmed (wartet) · 12 done (geliefert). Was unser Stack hier macht: ERP/Stock führt Bestände in Echtzeit, Picking + Lieferschein; Werker-App für mobiles Kommissionieren. Personas: Klaus (Lager/Versand), Lena.

P9 · ★ Auslieferung & Fakturierung

Ziel: Liefern + abrechnen + Zahlung.

Geschäftssprache	System-Status `account.move`	Auslöser	Wer
Lieferung gebucht	`stock.picking = done`	Versand	Klaus
Rechnung (Entwurf)	`draft`	aus Lieferung	Birgit
Rechnung gebucht	`posted`	bestätigt	Birgit
Offen / Bezahlt	`payment_state` not_paid → paid	Zahlung	Birgit

stateDiagram-v2
    [*] --> Lieferung_done
    Lieferung_done --> Rechnung_draft: fakturieren
    Rechnung_draft --> Rechnung_posted: buchen
    Rechnung_posted --> Offen_not_paid
    Offen_not_paid --> Bezahlt_paid: Zahlungseingang
    Bezahlt_paid --> [*]

Demo-Stand: 12 gebuchte Rechnungen (posted, offen). Auftrags-Faktura: 12 fakturiert · 10 zu fakturieren · 6 offen. Was unser Stack hier macht: ERP/Accounting erzeugt die Rechnung aus der Lieferung (Ziel: E-Rechnung/PEPPOL), Zahlungsabgleich + Mahnwesen. Status-Board zeigt, dass alles selbst gehostet + gesichert läuft. Personas: Birgit (Buchhaltung), Lena, Kunde.

AKT III · Nach der Lieferung

P10 · Service & Wartung (Servicevertrag)

Ziel: Anlagen/Produkte im Betrieb halten; wiederkehrende Umsätze.

Geschäftssprache	System-Status `maintenance.request`	Typ	Auslöser
Neue Anfrage	`New Request`	präventiv/korrektiv	Plan oder Störung
In Bearbeitung	`In Progress`	—	Disposition
Repariert	`Repaired`	—	Einsatz erledigt
Ausschuss	`Scrap`	—	nicht reparabel

stateDiagram-v2
    [*] --> NeueAnfrage
    NeueAnfrage --> InBearbeitung
    InBearbeitung --> Repariert
    InBearbeitung --> Ausschuss
    Repariert --> [*]
    Ausschuss --> [*]

Demo-Stand: 6 Anfragen über die 8 Maschinen (präventiv + korrektiv); z. B. „Drehzentrum B1: Wartung fällig" — deckt sich mit dem Leitstand-Status. Was unser Stack hier macht: ERP/Maintenance führt Equipment (= die 8 Maschinen) + Wartungsanfragen. Historian liefert Zustandsdaten (Vibration/Temperatur) für vorausschauende Wartung. Anlagen-Twin zeigt am selben Objekt Schaltschrank + letzte Wartung. Personas: Sven (Servicetechniker), Jens (Instandhaltung), Birgit, Kunde.

P11 · Schadens- & Reklamationsmanagement

Ziel: Fehler/Schäden strukturiert lösen + Wiederholung verhindern.

Geschäftssprache	System-Status `repair.order`	Auslöser	Wer
Reklamation erfasst	`draft`	Kundenmeldung	Petra/Lena
Bestätigt	`confirmed`	angenommen	Petra
In Reparatur	`under_repair`	Bearbeitung	Sven
Erledigt	`done`	Abschluss	Petra

stateDiagram-v2
    [*] --> Erfasst_draft
    Erfasst_draft --> Bestätigt_confirmed
    Bestätigt_confirmed --> InReparatur_under_repair
    InReparatur_under_repair --> Erledigt_done
    Erledigt_done --> [*]

Demo-Stand: 4 Reklamationen (draft) auf NW-Produkte (Maßabweichung, Kratzer, Riss, Toleranz). Was unser Stack hier macht: ERP/Repair führt den Fall; Wissen dokumentiert Ursachenanalyse (8D/CAPA); KI-Suche findet ähnliche Fälle; Zusammenarbeit für die fallbezogene Abstimmung. Personas: Petra (QM), Sven (Service), Lena, GF, Kunde.

P12 · Auswertung, KPIs & KVP

Ziel: Steuern + verbessern. Was unser Stack hier macht: BI (Metabase + Grafana) liefert OEE, Liefertreue, Ausschuss, Deckungsbeitrag, Process-Drift, Mass-Balance, GF-Cockpit. Historian ist die Datenbasis. KI-Suche beantwortet „Frag die Zahlen". Personas: Dr. Weber (GF), Frank, Petra.

2 · Anlagen, Leittechnik & Digital Twin (vertieft)

Der Teil, der Nordwerk vom reinen ERP unterscheidet — die Brücke vom Auftrag zur realen Maschine.

Anlagen-Twin / 3D — beherrschen & entstören (/anlage/ →)

Klickbarer Drilldown, read-only, generisch (kein Maschinenbauer-Geheimnis):

Werk → Linie (Nord/Süd/West) → Maschine (8) → Schaltschrank → Komponente → Stromlaufplan

Pro Maschine ein 3D-Modell mit Hotspots (Steuerung/HMI, Spindel, Schaltschrank); im Schaltschrank SPS, Antriebe/Frequenzumrichter, Klemmen, Sicherungen → je Komponente ein Mermaid-Stromlaufplan. Nutzen: Rüsten verstehen, im Störfall schnell von der Maschine zum Plan (Persona Jens).

Leitstand / SCADA — Echtzeit-Zustand (/leitstand/ →)

HMI-Kacheln aller Maschinen mit läuft / Wartung fällig / Leerlauf / Störung + aktueller Temperatur/Vibration. Dieselben Maschinen wie im ERP-Workcenter und im Historian — eine Wahrheit.

Digital Twin — What-if & Optimierung (twin-demo.indystry.works ↗)

vor dem Auftrag (P2): Durchsatz/Ausschuss/Kosten simulieren → realistisches Angebot.
im Betrieb (P6/P12): Parameter und Engpässe durchspielen, ohne die echte Linie anzuhalten.

Produktionsoptimierung — der geschlossene Regelkreis

flowchart LR
    M["Maschinen\n(Fertigung P6)"] -->|Telemetrie| H[("Historian\nTemp/Vibration")]
    H --> BI["BI: Process-Drift,\nMass-Balance, OEE"]
    H --> PW["Vorausschauende\nWartung → maintenance.request"]
    BI --> TW["Digital Twin:\nParameter optimieren"]
    TW --> M
    PW --> M

Drift-Erkennung: BI erkennt schleichende Abweichung (Process-Drift) früher als die Endprüfung.
Massenbilanz: Mass-Balance-Dashboard deckt Material-/Ausbeuteverluste auf.
Vorausschauende Wartung: steigende Vibration/Temperatur im Historian → Wartungsanfrage (P10), bevor die Maschine ausfällt (sichtbar als „Wartung fällig" im Leitstand).
Twin-Rückkopplung: optimierte Parameter aus der Simulation zurück in die Fertigung.

3 · Querschnitts-Prozesse (über den ganzen Fluss)

Prozess	Was es leistet	Demo
Zusammenarbeit	Dateiraum (Angebote, Zeichnungen, Prüfprotokolle, Wartung), versioniert, kommentierbar — fall- und auftragsbezogen	/zusammenarbeit/ →
Wissen / Compliance / Kiosk	Handbuch, Risikoregister (ISO 9001 / IEC 62443), App-Launcher	/wissen/ →
KI-Suche	„Frag die Firma" über Produkte/Maschinen/Aufträge/Handbuch/Kennzahlen	/suche/ →
Betrieb / Status	Dienste, Backups, Uptime — selbst gehostet, kein Cloud-Lock-in	/status/ →
Historian / Data-Lake	jeder Mess-/Betriebswert sicher + abrufbar; Basis für BI, Twin, Wartung	/historian/ →

4 · Master-Zustandstabelle (Nachschlagen)

Entität (`Odoo-Modell`)	Zustandskette (Geschäftssprache → `technisch`)	Demo-Stand
Lead/Chance `crm.lead`	Neu→Qualifiziert→Angebot→Gewonnen/Verloren (`New/Qualified/Proposition/Won`)	2/1/1/2
Angebot/Auftrag `sale.order`	Angebot `draft`→gesendet `sent`→Auftrag `sale`→gesperrt `done`	6 draft · 22 sale
Faktura-Status `sale.order`	nichts `no`→zu fakturieren `to invoice`→fakturiert `invoiced`	6 · 10 · 12
Einkauf `purchase.order`	RFQ `draft`→bestellt `purchase`→erledigt `done`	4 · 4
Lieferung/WE `stock.picking`	`draft`→wartet `confirmed/waiting`→bereit `assigned`→erledigt `done`	8 · 6 · 12
Fertigung `mrp.production`	`draft`→`confirmed`→`progress`→`to_close`→`done`	18 confirmed · 22 to_close
Qualität `factory.quality_check`	i.O. `passed=true` / n.i.O. `passed=false`	je Auftrag, 3 Merkmale
Rechnung `account.move`	Entwurf `draft`→gebucht `posted`; offen→bezahlt (`payment_state`)	12 posted/offen
Wartung `maintenance.request`	Neue Anfrage→In Bearbeitung→Repariert→Ausschuss	6 Anfragen
Reklamation `repair.order`	`draft`→`confirmed`→`under_repair`→`done`	4 draft

Einstieg für Besucher: der Demo-Firma-Hub /demos/ → bündelt alles als „eine Firma zum Durchklicken".