Prozessbeschreibung aus dem semantischen Modell

Fachlicher Zweck
Die Material Quality Lot Submission (MQLS) ist das zentrale fachliche Objekt für die
Qualitätsbewertung eines Materialloses, das von einem Lieferanten bereitgestellt wird. Sie
bündelt alle Informationen und Nachweise, die erforderlich sind, um die Eignung des
Materials für die weitere Verwendung zu beurteilen.

Dazu gehören insbesondere:

 Angaben zum Materiallos und zum zugehörigen Bauteil
 Informationen zum Lieferanten und zur Herstellung
 anzuwendende Qualitätsanforderungen
 Prüfergebnisse und weitere Qualitätsnachweise
 Dokumente und Anhänge
Freigabeentscheidungen und Genehmigungen.


Die MQLS steuert den fachlichen Lebenszyklus von der Erstellung durch den Lieferanten
über die Prüfung auf Kundenseite bis zur endgültigen Annahme oder Ablehnung. Eine
Besonderheit besteht darin, dass der Versand bereits vor der endgültigen Annahme
ausdrücklich autorisiert werden kann.

Beteiligte Rollen
Der Prozess unterscheidet im Wesentlichen zwischen Lieferanten- und Kundenseite.

Quality Supplier

Ein Benutzer mit der Rolle Quality Supplier kann:

 eine MQLS für ein vom Lieferanten bezogenes Bauteil anlegen
 die fachlichen Angaben bearbeiten und publizieren
 die MQLS an den Kunden weiterleiten
 eine zurückgesandte MQLS überarbeiten und erneut weiterleiten
eine MQLS in den Zuständen „Created“ oder „Returned“ löschen.

Quality Customer und Quality Manager

Die kundenseitigen Entscheidungen dürfen durch einen Benutzer mit der Rolle Quality
Customer getroffen werden, der zugleich als verantwortlicher Quality Manager der MQLS
zugeordnet ist.

Dieser Benutzer kann:

 eine eingereichte MQLS an den Lieferanten zurückgeben
 den Versand autorisieren
 die MQLS ablehnen
die endgültige Annahme erklären.

Die Zuordnung eines verantwortlichen Quality Managers ist damit nicht nur eine
organisatorische Information, sondern Bestandteil der Autorisierung.

Quality Administrator

Ein Benutzer mit einer administrativen Kundenrolle kann die MQLS-Daten in
kundenseitigen Bearbeitungszuständen publizieren. Für die eigentlichen fachlichen
Entscheidungen wie Versandfreigabe, Rückgabe, Ablehnung oder endgültige Annahme
fordert das Modell jedoch den zugeordneten Quality Manager mit der Rolle Quality
Customer.

Fachlicher Kontext der MQLS
Bei der Erstellung werden mehrere Kontexte dauerhaft mit der MQLS verbunden:

 das ausgewählte Bauteil
 der zugehörige Lieferant
 der erstellende Benutzer
eine automatisch erzeugte MQLS-Referenz.


Das Bauteil muss aus den für den aktuellen Lieferanten verfügbaren Sourcing Parts
stammen. Der Lieferantenkontext wird aus der Zugehörigkeit des angemeldeten Benutzers
ermittelt.

Die Lieferantenzuordnung wird zum Zeitpunkt der Erstellung fest in der MQLS hinterlegt.
Spätere Änderungen an der Lieferantenzuordnung des Benutzers verändern diese
Eigentumsbeziehung nicht rückwirkend.

Zu den im Modell vorgesehenen fachlichen Angaben gehören unter anderem:

 MQLS-Typ
 Anzahl der Teile
 Heat beziehungsweise Schmelze
 Heat Code und Suffix
 Engine Program
 Gruppierung und Anwendbarkeit einer Gruppierung
 Herstellungsverfahren
 Manufacturing Approval
 Manufacturing Approval für Forging Stock
 Forging-Stock-Lieferant
 Bemerkungen
 zusätzliche E-Mail-Adresse
verantwortlicher Quality Manager.

Welche dieser Angaben in einer konkreten Situation verpflichtend sind, wird über
modellierte Konsistenz- und Pflichtfeldsituationen bestimmt.

Fachlicher Ablauf
Der zentrale Ablauf lässt sich wie folgt zusammenfassen:

Nicht vorhanden

│

▼

Created ───────────────► Deleted

│

│ Forward

▼

Forwarded ── Return ───► Returned ─────► Deleted

▲ │

└────── Forward ────────┘

│

├── Reject ─────────► Rejected

│


└── Authorize Shipment

│

▼

Authorized for Shipment

│

├── Reject ───────► Rejected

│

└── Accept Finally

▼

Finally Accepted

In den Zuständen Created, Returned, Forwarded und Authorized for Shipment können die
jeweils berechtigten Benutzer mit „Publish“ aktualisierte Informationen publizieren, ohne
den fachlichen Zustand zu verändern.

Erstellung der MQLS
Der Prozess beginnt mit der Auswahl eines Bauteils, das vom aktuellen Lieferanten bezogen
wird. Voraussetzung ist, dass folgende Kontexte vorhanden sind:

 aktueller Benutzer
 aktueller Lieferant
ausgewähltes Bauteil.

Die Erstellung ist ausschließlich für die Rolle Quality Supplier autorisiert.

Beim Anlegen:

 wird eine MQLS-Referenz erzeugt
 wird der aktuelle Benutzer als Ersteller hinterlegt
 wird das ausgewählte Bauteil verbunden
 wird der aktuelle Lieferant als dauerhafter Supplier Ownership Context übernommen
wechselt die MQLS in den Zustand Created.

Gleichzeitig wird der MQLS-Kontext als aktiv veröffentlicht. Dadurch kann er von den
unterstützenden Bereichen für Approval Requests, Attachments und Notifications als
übergeordneter fachlicher Kontext verwendet werden. Das SemanticBook beschreibt an
dieser Stelle die Bereitstellung des Parent Contexts, jedoch nicht automatisch die Erzeugung
aller untergeordneten Objekte.

Bearbeitung durch den Lieferanten
Im Zustand Created befindet sich die MQLS auf Lieferantenseite. Der Lieferant ergänzt die
erforderlichen fachlichen Informationen, Nachweise und Dokumente.

Mit der Aktion Publish können die aktuellen Angaben veröffentlicht werden, ohne dass die
MQLS bereits an den Kunden übergeben wird.


Nach Abschluss seiner Tätigkeiten leitet der Lieferant die MQLS mit Forward weiter. Dafür
muss die modellierte Situation „Application is consistent“ erfüllt sein. Die MQLS wechselt
anschließend in den Zustand Forwarded und befindet sich damit in der kundenseitigen
Bewertung.

Solange die MQLS noch nicht weitergeleitet wurde, kann sie durch den Lieferanten gelöscht
werden.

Prüfung auf Kundenseite
Im Zustand Forwarded bewertet der zugeordnete Quality Manager die eingereichten
Informationen und die damit verbundenen Qualitätsergebnisse.

Die MQLS selbst übernimmt dabei nicht die fachliche Verantwortung für alle beteiligten
Objekte. Sie integriert deren Ergebnisse:

Quality Requirement Applications liefern Informationen über Relevanz, Status und
Erfüllung der Qualitätsanforderungen.

Approval Requests liefern die zugehörigen Freigabeentscheidungen.

Attachments enthalten Dokumente und Qualitätsnachweise.

Notifications unterstützen die Kommunikation mit den Beteiligten.

Die MQLS hält Projektionen auf die zugehörigen Quality Requirement Applications und
Approval Requests. Deren eigener Lebenszyklus verbleibt in den jeweils verantwortlichen
fachlichen Bereichen.

Aus der Prüfung können drei unmittelbare Ergebnisse entstehen.

Rückgabe an den Lieferanten

Sind Angaben unklar oder ist eine Nachbearbeitung erforderlich, kann der Quality Manager
die MQLS mit Return an den Lieferanten zurückgeben.

Die MQLS wechselt in den Zustand Returned beziehungsweise In revision. Der Lieferant
kann die Informationen anschließend überarbeiten, erneut publizieren und mit Forward
wieder zur kundenseitigen Bewertung einreichen.

Dieser Rückgabe- und Überarbeitungszyklus kann grundsätzlich erneut durchlaufen
werden.

Ablehnung

Der Quality Manager kann eine MQLS bereits im Zustand Forwarded endgültig ablehnen.
Die MQLS wechselt in den Zustand Rejected und kann im bestehenden Lebenszyklus nicht
weiter freigegeben werden.

Mit der Ablehnung wird der MQLS-Kontext finalisiert. Noch offene Approval Requests
werden beendet beziehungsweise storniert; die verbundenen Approval-, Attachment- und
Notification-Kontexte erhalten ebenfalls die Information, dass ihr Parent Context finalisiert
wurde.

Autorisierung des Versands


Alternativ kann der Quality Manager den Versand mit Authorize Shipment freigeben.

Voraussetzung ist:

Der Benutzer besitzt die Rolle Quality Customer.

Der Benutzer ist der zugeordnete Quality Manager.

Die MQLS besitzt konsistente und korrekte Daten.

Die MQLS wechselt daraufhin in den Zustand Authorized for Shipment.

Diese Entscheidung erlaubt dem Lieferanten, die Teile zu versenden, obwohl die endgültige
Qualitätsannahme noch aussteht. Die Versandautorisierung ist deshalb nicht mit der finalen
Annahme gleichzusetzen.

Im Zuge der Versandautorisierung werden fachliche Rohinhalte für zwei
Dokumentationsartefakte erzeugt:

 Shipment Letter
Benachrichtigung über die Versandfreigabe.

Diese Inhalte werden an den Content Structure Builder übergeben, der daraus strukturierte
Inhalte erzeugt.

Phase nach der Versandautorisierung
Im Zustand Authorized for Shipment ist die Lieferung erlaubt, der MQLS-Lebenszyklus
jedoch noch nicht abgeschlossen.

Die MQLS kann weiterhin aktualisiert und publiziert werden. Dafür ist entweder der
zugeordnete Quality Manager mit der Rolle Quality Customer oder ein entsprechend
berechtigter Quality Administrator erforderlich.

Aus diesem Zustand sind zwei abschließende Entscheidungen möglich:

 endgültige Annahme
endgültige Ablehnung.

Endgültige Annahme
Mit Accept Finally bestätigt der Quality Manager, dass die für die MQLS erforderlichen
Qualitätsanforderungen erfüllt wurden.

Das Modell fordert hierfür:

 mindestens einen positiv entschiedenen Approval Request
 eine positiv entschiedene Freigabe durch einen zweiten Approver
 konsistente und korrekte MQLS-Daten
 die Rolle Quality Customer
die Zuordnung des ausführenden Benutzers als verantwortlicher Quality Manager.

Nach erfolgreicher Entscheidung wechselt die MQLS in den Zustand Finally Accepted.

Die endgültige Annahme bewirkt außerdem:

 die Veröffentlichung des finalen Status


 die Finalisierung des MQLS-Kontexts
 die Beendigung noch verbliebener Approval Requests
 die Finalisierung der zugehörigen Approval-, Attachment- und Notification-Kontexte
 die Erzeugung eines Final Letter
die Erzeugung einer abschließenden Benachrichtigung.

Final Letter und Benachrichtigung werden zunächst als fachliche Rohinhalte abgeleitet und
anschließend über den Content Structure Builder in strukturierte Inhalte überführt.

Endgültige Ablehnung nach Versandautorisierung
Auch nach einer bereits erteilten Versandfreigabe kann die MQLS noch abgelehnt werden.
Dadurch wird deutlich, dass „Authorized for Shipment“ lediglich eine vorläufige
Versandentscheidung und keine endgültige Qualitätsannahme darstellt.

Die Ablehnung führt in den Zustand Rejected. Wie bei einer Ablehnung aus dem Zustand
Forwarded wird der Kontext finalisiert und noch offene beziehungsweise abhängige
Freigabekontexte werden beendet oder auf den finalen Zustand des Parent Contexts
ausgerichtet.

Löschen einer MQLS
Eine MQLS kann nur auf Lieferantenseite gelöscht werden:

 im Zustand Created
im Zustand Returned.

Eine bereits zur Kundenseite weitergeleitete oder für den Versand autorisierte MQLS kann
nicht mehr durch den Lieferanten gelöscht werden.

Die Löschung führt in den Zustand Deleted und deaktiviert den MQLS-Kontext. Dadurch
werden auch die zum MQLS-Kontext gehörenden Objekte behandelt:

 Approval Requests werden gelöscht beziehungsweise deaktiviert
 Attachments werden entfernt oder deaktiviert
 Notifications werden gelöscht beziehungsweise deaktiviert
Quality Requirement Applications werden gelöscht.

Damit verhindert das Modell, dass fachlich verwaiste Unterobjekte bestehen bleiben.

Fachliche Kernaussage
Der MQLS-Prozess ist kein einfacher linearer Freigabeablauf. Er bildet eine koordinierte
Zusammenarbeit zwischen Lieferant und Kunde ab:

Der Lieferant erstellt und vervollständigt die Qualitätsmeldung.

Der Kunde prüft die Angaben und kann sie zur Überarbeitung zurückgeben.

Der Versand kann vorläufig autorisiert werden.

Die endgültige Annahme erfolgt erst nach den vorgesehenen Qualitäts- und
Freigabeentscheidungen.


Alle Nachweise, Entscheidungen, Dokumente und Benachrichtigungen bleiben über den
gemeinsamen MQLS-Kontext nachvollziehbar verbunden.

Die MQLS fungiert dabei als orchestrierender fachlicher Kontext. Sie besitzt nicht sämtliche
beteiligten Capabilities selbst, sondern integriert deren Ergebnisse zu einer konsistenten
Gesamtsicht auf den Qualitätsfreigabestatus des Materialloses.