Fallbeispiel 2 – Transition Table des MQLS-Lebenszyklus
Die Transition Table verdichtet den im semantischen Modell beschriebenen Lebenszyklus der Material Quality Lot Submission zu einer fachlich lesbaren Übersicht. Sie zeigt für jede Transition die auslösende Geschäftshandlung, den zulässigen Ausgangszustand, Autorisierung, fachliche Voraussetzungen und Guards, den Zielzustand sowie das veröffentlichte Domain Event.
Damit bildet sie eine kompakte Brücke zwischen fachlichem Zustandsmodell, Prozesssicht und späterer technischer Projektion. Die Tabelle basiert auf der Transition Projection des aufgelösten Enterprise Models.
Transition Table des MQLS-Lebenszyklus| Business Action | Ausgangszustand | Autorisierung | Requirements / Guards | Zielzustand | Domain Event |
|---|
| Create | Undefined State | Rolle Quality Supplier | Supplier Ownership Context und User Context verfügbar; Part Context verfügbar | Created | MQLS Created |
|---|
| Publish | Created | Rolle Quality Supplier | Keine weiteren Requirements oder Guards | Created | MQLS Published |
|---|
| Forward | Created | Rolle Quality Supplier | MQLS ist konsistent; alle notwendigen Daten sind korrekt befüllt | Forwarded | MQLS Forwarded |
|---|
| Delete | Created | Rolle Quality Supplier | Keine weiteren Requirements oder Guards | Deleted | MQLS Deleted |
|---|
| Publish | Forwarded | Zugeordneter Quality Manager mit Rolle Quality Customer oder Quality Admin | Keine weiteren Requirements oder Guards | Forwarded | MQLS Published |
|---|
| Reject | Forwarded | Rolle Quality Customer und zugeordneter Quality Manager | Keine weiteren Requirements oder Guards | Rejected | MQLS Rejected |
|---|
| Authorize Shipment | Forwarded | Rolle Quality Customer und zugeordneter Quality Manager | MQLS besitzt konsistente und korrekte Daten | Authorized for Shipment | MQLS Authorized for Shipment |
|---|
| Return | Forwarded | Rolle Quality Customer und zugeordneter Quality Manager | Keine weiteren Requirements oder Guards | In revision | MQLS Returned |
|---|
| Publish | Authorized for Shipment | Zugeordneter Quality Manager mit Rolle Quality Customer oder Quality Admin | Keine weiteren Requirements oder Guards | Authorized for Shipment | MQLS Published |
|---|
| Reject | Authorized for Shipment | Rolle Quality Customer und zugeordneter Quality Manager | Keine weiteren Requirements oder Guards | Rejected | MQLS Rejected |
|---|
| Accept Finally | Authorized for Shipment | Rolle Quality Customer und zugeordneter Quality Manager | Positiv entschiedener Approval Request vorhanden; Guard verlangt positiv entschiedenen Approval Request des zweiten Approvers; MQLS ist konsistent | Finally accepted | MQLS Finally Accepted |
|---|
| Publish | In revision | Rolle Quality Supplier | Keine weiteren Requirements oder Guards | In revision | MQLS Published |
|---|
| Forward | In revision | Rolle Quality Supplier | MQLS ist konsistent; alle notwendigen Daten sind korrekt befüllt | Forwarded | MQLS Forwarded |
|---|
| Delete | In revision | Rolle Quality Supplier | Keine weiteren Requirements oder Guards | Deleted | MQLS Deleted |
|---|
Einordnung
Die Tabelle zeigt, dass der MQLS-Lebenszyklus nicht als ein einziger linearer Ablauf angelegt ist. Aus einem Zustand können mehrere fachlich zulässige Handlungen hervorgehen. Welche Transition tatsächlich verfügbar und ausführbar ist, ergibt sich aus Zustand, Rolle, Verantwortungszuordnung, Requirements und Guards.
Besonders sichtbar wird dies im Zustand „Authorized for Shipment“. Dort kann der aktuelle Stand publiziert, die MQLS endgültig abgelehnt oder – nach erfolgreicher Approval- und Konsistenzprüfung – endgültig angenommen werden. Das folgende Fallbeispiel untersucht genau diese Transition im Detail.
Unformatierten Originaltext anzeigen
5.3 Fallbeispiel 2 – Transition Table des MQLS-Lebenszyklus
DIESE PROJEKTION WURDE DURCH CHATGPT SOL 5.6 ERSTELLT.
Die Transition Table verdichtet den im semantischen Modell beschriebenen Lebenszyklus
der Material Quality Lot Submission zu einer fachlich lesbaren Übersicht. Sie zeigt für jede
Transition die auslösende Geschäftshandlung, den zulässigen Ausgangszustand,
Autorisierung, fachliche Voraussetzungen und Guards, den Zielzustand sowie das
veröffentlichte Domain Event.
Damit bildet sie eine kompakte Brücke zwischen fachlichem Zustandsmodell, Prozesssicht
und späterer technischer Projektion. Die Tabelle basiert auf der Transition Projection des
aufgelösten Enterprise Models.
Fallbeispiel 2 – Transition Table des MQLS-Lebenszyklus
Business Action Ausgangszustand Autorisierung Requirements / Guards Zielzustand Domain Event
Create Undefined State Rolle Quality Supplier Supplier Ownership Context und Created MQLS Created
User Context verfügbar; Part
Context verfügbar
Publish Created Rolle Quality Supplier Keine weiteren Requirements oder Created MQLS Published
Guards
Forward Created Rolle Quality Supplier MQLS ist konsistent; alle Forwarded MQLS Forwarded
notwendigen Daten sind korrekt
befüllt
Delete Created Rolle Quality Supplier Keine weiteren Requirements oder Deleted MQLS Deleted
Guards
Publish Forwarded Zugeordneter Quality Manager mit Keine weiteren Requirements oder Forwarded MQLS Published
Rolle Quality Customer oder Quality Guards
Admin
Reject Forwarded Rolle Quality Customer und Keine weiteren Requirements oder Rejected MQLS Rejected
zugeordneter Quality Manager Guards
Authorize Shipment Forwarded Rolle Quality Customer und MQLS besitzt konsistente und Authorized for Shipment MQLS Authorized for Shipment
zugeordneter Quality Manager korrekte Daten
Return Forwarded Rolle Quality Customer und Keine weiteren Requirements oder In revision MQLS Returned
zugeordneter Quality Manager Guards
Publish Authorized for Shipment Zugeordneter Quality Manager mit Keine weiteren Requirements oder Authorized for Shipment MQLS Published
Rolle Quality Customer oder Quality Guards
Admin
Reject Authorized for Shipment Rolle Quality Customer und Keine weiteren Requirements oder Rejected MQLS Rejected
zugeordneter Quality Manager Guards
Accept Finally Authorized for Shipment Rolle Quality Customer und Positiv entschiedener Approval Finally accepted MQLS Finally Accepted
zugeordneter Quality Manager Request vorhanden; Guard verlangt
positiv entschiedenen Approval
Request des zweiten Approvers;
MQLS ist konsistent
Publish In revision Rolle Quality Supplier Keine weiteren Requirements oder In revision MQLS Published
Guards
Forward In revision Rolle Quality Supplier MQLS ist konsistent; alle Forwarded MQLS Forwarded
notwendigen Daten sind korrekt
befüllt
Delete In revision Rolle Quality Supplier Keine weiteren Requirements oder Deleted MQLS Deleted
Guards
Fallbeispiel 2 – Transition Table des MQLS-Lebenszyklus
Einordnung
Die Tabelle zeigt, dass der MQLS-Lebenszyklus nicht als ein einziger linearer Ablauf angelegt ist. Aus einem Zustand können mehrere fachlich zulässige
Handlungen hervorgehen. Welche Transition tatsächlich verfügbar und ausführbar ist, ergibt sich aus Zustand, Rolle, Verantwortungszuordnung,
Requirements und Guards.
Besonders sichtbar wird dies im Zustand „Authorized for Shipment“. Dort kann der aktuelle Stand publiziert, die MQLS endgültig abgelehnt oder – nach
erfolgreicher Approval- und Konsistenzprüfung – endgültig angenommen werden. Das folgende Fallbeispiel untersucht genau diese Transition im Detail.