Ihr Template für Qualitätsmanagement-Daten
Ihr Template für Qualitätsmanagement-Daten
- Empfohlene Attribute für eine umfassende Analyse
- Wichtige Quality Management Aktivitäten zur Nachverfolgung
- Anleitung zur Datenextraktion aus SAP S/4HANA Qualitätsmanagement
Quality Management Attribute
| Name | Beschreibung | ||
|---|---|---|---|
|
Aktivität
ActivityName
|
Der Name des spezifischen Geschäfts-events oder der Aufgabe, die innerhalb des Quality Management Prozesses aufgetreten ist. | ||
|
Beschreibung
Dieses attribute beschreibt einen einzelnen Schritt oder Meilenstein im Quality Event Lebenszyklus, wie z.B. 'Qualitätsmeldung erstellt' (Notification Created), 'Root Cause Analysis abgeschlossen' (Root Cause Analysis Completed) oder 'Verwendungsentscheid getroffen' (Usage Decision Made). Diese Aktivitäten werden aus Änderungen im Systemstatus, der Erstellung zugehöriger Dokumente oder spezifischen Benutzeraktionen, die in Änderungs-logs aufgezeichnet sind, abgeleitet. Die Analyse der Reihenfolge und des Timings dieser Aktivitäten ist der Kern des Process Mining. Sie ermöglicht die Entdeckung des tatsächlichen Process Flow, die Identifizierung von Bottlenecks zwischen den Schritten und die Messung der Konformität mit Standardarbeitsanweisungen. Die Granularität der Aktivitäten bestimmt den Detaillierungsgrad der Process Analyse.
Bedeutung
Dieses attribute definiert die Schritte des Process und ermöglicht so die Visualisierung und Analyse des Process Flow, die Identifizierung von Abweichungen und die Messung der Leistung zwischen Aktivitäten.
Datenquelle
Abgeleitet aus Statusänderungen in den Tabellen JEST und JSTO oder aus Aktivitätsprotokollen in Tabellen wie QMSM (Aufgaben). Event Logs können auch aus Änderungsbelegtabellen CDHDR und CDPOS erstellt werden.
Beispiele
Qualitätsmeldung erstelltUntersuchungsaufgabe zugewiesenKorrekturmaßnahme implementiertMeldung geschlossen
|
|||
|
Quality Event
QualityEvent
|
Die eindeutige Kennung für eine Qualitätsmeldung, die als primäre case ID dient, um ein Qualitätsproblem von der Initiierung bis zum Abschluss zu verfolgen. | ||
|
Beschreibung
Das Quality Event ist die zentrale case Kennung, die alle Aktivitäten, Aufgaben und Entscheidungen im Zusammenhang mit einem einzelnen Qualitätsproblem verbindet. In SAP entspricht dies typischerweise der Qualitätsmeldungsnummer (QMNUM). Im Process Mining ermöglicht die Analyse von events anhand dieser Kennung die Rekonstruktion des End-to-End-Weges jedes Qualitäts-case. Dies ist grundlegend für die Visualisierung von Process Flows, die Berechnung von Zykluszeiten für den gesamten case und die Identifizierung gemeinsamer oder abweichender Pfade im Lösungsprozess. Es dient als Rückgrat für fast alle Quality Management Analysen.
Bedeutung
Es ist der entscheidende Schlüssel, um alle zugehörigen Aktivitäten zu einer einzigen, kohärenten Prozessinstanz zu verknüpfen und so eine End-to-End-Analyse der Bearbeitung von Qualitätsproblemen zu ermöglichen.
Datenquelle
Dies ist die Qualitätsmeldungsnummer, zu finden in der Tabelle QMEL, Feld QMNUM.
Beispiele
200000018200000019200000020
|
|||
|
Startzeit
EventTimestamp
|
Das genaue Datum und die Uhrzeit, zu der eine spezifische Aktivität oder ein Event auftrat. | ||
|
Beschreibung
Die Startzeit, oder das event timestamp, zeichnet den genauen Moment auf, in dem eine Activity stattfand. Dies ist entscheidend für die chronologische Anordnung von events und die Berechnung der Dauer zwischen ihnen. Zum Beispiel erfasst es, wann eine Meldung erstellt, eine Aufgabe abgeschlossen oder ein Status geändert wurde. In der Process Mining Analyse ist dieses attribute grundlegend für die Berechnung aller zeitbasierten Metriken, wie z.B. Zykluszeiten, Bearbeitungszeiten und Wartezeiten. Es ermöglicht die Identifizierung von Bottlenecks, die Analyse des Durchsatzes und die Überwachung der Leistung im Vergleich zu zeitbasierten SLAs oder Zielen. Genaue timestamps sind entscheidend für die Integrität des gesamten Process Model.
Bedeutung
Dieser Zeitstempel ist essenziell für die Ereignisanordnung, die Berechnung aller Performance-Metriken wie Durchlaufzeiten und Wartezeiten sowie für das Verständnis der Prozessdynamik.
Datenquelle
Typischerweise entnommen aus Datums- und Zeitfeldern, die mit Statusänderungen oder der Dokumentenerstellung verbunden sind. Beispiele hierfür sind ERDAT/ERZEIT (Erstellt am/Zeit) in QMEL oder die Änderungszeitstempel in CDHDR.
Beispiele
2023-04-15T09:00:12Z2023-04-18T14:35:00Z2023-05-01T11:21:45Z
|
|||
|
`Grundursache`
RootCauseCode
|
Ein Code oder Text, der die ermittelte Ursache des Qualitätsproblems identifiziert. | ||
|
Beschreibung
Das Root Cause attribute erfasst den zugrundeliegenden Grund für den Qualitätsmangel oder die Nichtkonformität. Die Identifizierung der korrekten Root Cause ist ein kritischer Schritt im Quality Management Prozess, da sie die Grundlage für die Definition wirksamer Korrektur- und Vorbeugemaßnahmen bildet. Dieses attribute ist wesentlich für die Dashboards 'Root Cause Analysis Cycle Time' und 'Recurring Issue Pattern Detection'. Die Analyse nach Root Cause hilft, systemische Probleme zu identifizieren. Zum Beispiel kann durch Filtern der Process Map nach einer spezifischen Root Cause festgestellt werden, ob diese zu einzigartigen Process Paths oder längeren Lösungszeiten führt.
Bedeutung
Ermöglicht die Analyse systemischer Probleme durch Korrelation von Ursachen mit Produkten, Abteilungen und Prozesseffizienzdefiziten, um vorbeugende Maßnahmen zu steuern.
Datenquelle
Typischerweise gespeichert in der Tabelle QMUR (Meldungsursachen), Feld URCOD.
Beispiele
BEDIENERFEHLERDEFECTIVE_MATERIALMASCHINENFEHLFUNKTION
|
|||
|
Benutzer
ChangedBy
|
Die Benutzer-ID der Person, die die Activity durchgeführt oder die letzte Änderung vorgenommen hat. | ||
|
Beschreibung
Dieses attribute identifiziert den spezifischen Benutzer, der für die Ausführung eines bestimmten Process Schritts verantwortlich ist. In SAP entspricht dies oft den Feldern 'Geändert von' (AENAM) oder 'Erstellt von' (ERNAM). Die Analyse nach Benutzer hilft beim Verständnis der Arbeitslastverteilung, der Identifizierung von Schulungsbedarfen und der genauen Bestimmung benutzerspezifischer Process Abweichungen. Sie ist grundlegend für ressourcenbasierte Analysen, wie z.B. die Untersuchung, warum bestimmte Benutzer längere Bearbeitungszeiten haben oder dazu neigen, nicht-standardmäßige Pfade zu verfolgen.
Bedeutung
Es ermöglicht die Analyse der Benutzerleistung, Arbeitslastverteilung und Einhaltung von Standardverfahren, was für die Ressourcenoptimierung entscheidend ist.
Datenquelle
Findet sich in Kopf- und Positionstabellen wie QMEL-ERNAM (Angelegt von) oder wird aus Änderungsbelegen (CDHDR-USERNAME) abgeleitet.
Beispiele
SMITHJWILSONAPROZESS_AUTOMATISIERUNGS_BOT
|
|||
|
Priorität
NotificationPriority
|
Die Prioritätsstufe, die der Qualitätsmeldung zugewiesen ist und ihre Dringlichkeit anzeigt. | ||
|
Beschreibung
Die Priorität definiert die Dringlichkeit der Bearbeitung eines Quality Event. Sie hilft Teams, ihre Arbeit zu organisieren und sicherzustellen, dass die kritischsten Probleme zuerst behandelt werden. SAP ermöglicht die Konfiguration verschiedener Prioritätstypen, die die Zielantwortzeiten beeinflussen können. Dieses attribute wird verwendet, um zu analysieren, ob hochpriorisierte Elemente tatsächlich schneller bearbeitet werden als niedrigpriorisierte. Es kann Ineffizienzen aufzeigen, bei denen Fälle mit hoher Priorität im Process stecken bleiben. Es ist eine Schlüsseldimension für Dashboards wie die 'Quality Event Throughput Analysis'.
Bedeutung
Hilft zu analysieren, ob die Prozessleistung der geschäftlichen Dringlichkeit entspricht, und stellt sicher, dass hochprioritäre Probleme schneller gelöst werden.
Datenquelle
Befindet sich in der QMEL-Tabelle, Feld QMPRI. Die Beschreibung ist in Tabelle TQ05.
Beispiele
1234
|
|||
|
Produkt
MaterialNumber
|
Die eindeutige Kennung für das Produkt oder Material, das vom Quality Event betroffen ist. | ||
|
Beschreibung
Dieses attribute verknüpft das Quality Event mit einem spezifischen Produkt oder Material. Diese Verbindung ist entscheidend für die Qualitätssicherung, da sie hilft, Produkte mit wiederkehrenden Problemen oder hohen Fehlerraten zu identifizieren. Im Process Mining ermöglicht die Analyse nach Produkt die Erkennung von Mustern, z.B. ob bestimmte Produkte längere Lösungszeiten haben oder mit spezifischen Root Causes verbunden sind. Dies unterstützt das Dashboard 'Mustererkennung wiederkehrender Probleme' (Recurring Issue Pattern Detection), indem Produkte mit Qualitätsproblemen korreliert werden, was für gezielte Qualitätsverbesserungsinitiativen entscheidend ist.
Bedeutung
Verknüpft Qualitätsprobleme mit bestimmten Produkten, um die Analyse produktspezifischer Fehlerraten, Grundursachen und Lösungsmuster zu ermöglichen.
Datenquelle
Findet sich in der Qualitätsmeldungs-Positionstabelle QMFE, Feld MATNR.
Beispiele
FIN-1001RAW-205ASEMI-303B
|
|||
|
Qualitätsmeldungsart
QualityNotificationType
|
Die Klassifizierung der Qualitätsmeldung, z.B. Kundenreklamation, internes Problem oder Lieferantenmangel. | ||
|
Beschreibung
Dieses attribute kategorisiert das Quality Event basierend auf seinem Ursprung und seiner Art. Standard-SAP-Typen umfassen Kundenreklamationen, interne Problemberichte und lieferantenbezogene Mängel. Diese Kategorisierung bestimmt den nachfolgenden Process Flow und die erforderliche Dokumentation. Die Analyse des Process nach Meldungsart ist essenziell, um zu verstehen, ob verschiedene Arten von Problemen unterschiedlich behandelt werden oder unterschiedliche Effizienzgrade aufweisen. Es unterstützt Dashboards wie die 'Quality Event Throughput Analysis', indem es das Filtern und Vergleichen von Zykluszeiten und Process Paths für verschiedene Problemkategorien ermöglicht.
Bedeutung
Es ermöglicht die Segmentierung des Prozesses, um zu sehen, ob verschiedene Arten von Qualitätsproblemen unterschiedliche Pfade verfolgen oder unterschiedliche Leistungsmerkmale aufweisen.
Datenquelle
Befindet sich in der QMEL-Tabelle, Feld QMART.
Beispiele
Q1Q2F2
|
|||
|
Verantwortliche Abteilung
ResponsibleDepartment
|
Die Abteilung oder der Funktionsbereich, der für die Ausführung einer bestimmten Aufgabe oder die Verwaltung des Quality Event verantwortlich ist. | ||
|
Beschreibung
Dieses attribute gibt die Organisationseinheit an, die einer Activity oder dem gesamten Quality Event zugewiesen ist. Dies könnte ein Qualitätssicherungsteam, eine Ingenieurabteilung oder eine Produktionseinheit sein. Dies ist eine kritische Dimension für die Analyse der abteilungsübergreifenden Zusammenarbeit und Übergaben. Es hilft, Verzögerungen zu identifizieren, die auftreten, wenn die Verantwortung von einer Abteilung zur anderen wechselt, und unterstützt das Dashboard 'Verzögerungen bei abteilungsübergreifenden Übergaben' (Cross-Department Handoff Delays). Es ermöglicht auch das Filtern der Process View, um zu verstehen, wie bestimmte Abteilungen arbeiten.
Bedeutung
Entscheidend für die Analyse abteilungsübergreifender Übergaben, die Identifizierung organisatorischer Engpässe und das Verständnis, wie verschiedene Teams zum Prozess beitragen.
Datenquelle
Oft abgeleitet von Partnerfunktionen, die der Meldung oder Aufgabe zugeordnet sind, oder von der organisatorischen Zuordnung des Benutzers in den HR-Stammdaten. Es handelt sich möglicherweise nicht um ein direktes Feld.
Beispiele
QualitätssicherungProduktionslinie 3Lieferantenqualitätsingenieurwesen
|
|||
|
Ziel-Lösungsdatum.
TargetResolutionDate
|
Das geplante oder erforderliche Abschlussdatum für das Quality Event. | ||
|
Beschreibung
Dieses Datum stellt die Frist dar, bis zu der das Quality Event vollständig gelöst und abgeschlossen sein soll. Es wird oft als Benchmark zur Messung der Leistung und Einhaltung von Service Level Agreements (SLAs) verwendet. Dieses attribute ist grundlegend für die Berechnung der termingerechten Abschlussquoten und die Identifizierung überfälliger cases. Das Dashboard 'Quality Event On-Time Completion' und der KPI 'Quality Action On-Time Rate' sind direkt davon abhängig, das tatsächliche Abschlussdatum mit diesem Zieldatum zu vergleichen. Es hilft bei der Priorisierung von Arbeiten und der effektiven Ressourcenverwaltung.
Bedeutung
Bietet eine Basis für die Messung der termingerechten Leistung, was ein kritischer KPI zur Bewertung der Prozesseffizienz und Compliance mit SLAs ist.
Datenquelle
Kann in QMEL-QMDAT (Erforderliches Enddatum) oder auf Aufgabenebene in QMSM-PSTER gefunden werden.
Beispiele
2023-05-302023-06-152023-07-01
|
|||
|
Aktivitätsbearbeitungszeit
ProcessingTime
|
Die Dauer der Zeit, die aktiv an einer einzelnen Activity gearbeitet wurde. | ||
|
Beschreibung
Die Bearbeitungszeit, auch als Zykluszeit bekannt, ist die von Anfang bis Ende einer einzelnen Activity verstrichene Zeit. Dies unterscheidet sich von der Wartezeit, die die zwischen den Aktivitäten verbrachte Zeit ist. Sie wird berechnet, indem die Differenz zwischen den Start- und End-timestamps einer Activity genommen wird. Diese Metrik ist grundlegend, um zu identifizieren, welche spezifischen Aufgaben am zeitaufwendigsten sind. Im Dashboard zur 'Process Bottleneck Identification' können hohe Bearbeitungszeiten für bestimmte Aktivitäten auf Komplexität, mangelnde Ressourcen oder ineffiziente Verfahren hinweisen. Es hilft, genau zu bestimmen, wo Prozessverbesserungsbemühungen anzusetzen sind.
Bedeutung
Misst die Zeit, die für wertschöpfende Aktivitäten aufgewendet wird, und hilft dabei, die zeitaufwendigsten Schritte im Prozess zu identifizieren, die sich ideal für eine Optimierung eignen.
Datenquelle
Berechnetes Feld, abgeleitet aus den Start- und End-Timestamps jeder Aktivität im Event Log. (EndTime - StartTime).
Beispiele
2 Stunden 15 Minuten3 Tage 4 Stunden30 Minuten
|
|||
|
Ist Nacharbeit
IsRework
|
Ein boolesches Flag, das anzeigt, ob eine Aktivität oder eine Abfolge von Aktivitäten Nacharbeit darstellt. | ||
|
Beschreibung
Dieses Flag wird auf true gesetzt, wenn ein case bestimmte Schritte wiederholt, was darauf hindeutet, dass die anfängliche Arbeit unzureichend war. Wenn zum Beispiel einer 'Root Cause Analysis'-Activity später eine weitere 'Untersuchungsaufgabe zugewiesen' (Investigation Task Assigned) für denselben case folgt, signalisiert dies eine Nacharbeitsschleife. Dieses attribute unterstützt direkt den KPI 'Corrective Action Rework Rate'. Nacharbeit zu identifizieren und zu quantifizieren ist ein primäres Ziel des Process Mining, da Nacharbeit verschwendeten Aufwand und Process-Ineffizienz darstellt. Das Hervorheben von Nacharbeitsschleifen in der Process Map kann erhebliche Möglichkeiten zur Verbesserung der Qualität und Effizienz aufzeigen.
Bedeutung
Quantifiziert die Process-Ineffizienz, indem es identifiziert, wann Schritte wiederholt werden, und so unnötigen Aufwand und Möglichkeiten zur Verbesserung der 'First-Time-Right'-Raten aufzeigt.
Datenquelle
Hierbei handelt es sich um ein berechnetes Attribut. Es wird während der Process Mining-Analyse abgeleitet, indem wiederkehrende Abfolgen von Aktivitäten innerhalb eines einzelnen Falls (Case) erkannt werden.
Beispiele
truefalsch
|
|||
|
Kunde
CustomerNumber
|
Die Kennung für den Kunden, der dem Quality Event zugeordnet ist, falls zutreffend. | ||
|
Beschreibung
Dieses attribute verknüpft ein Quality Event mit einem spezifischen Kunden. Dies ist am relevantesten für Meldungsarten wie 'Kundenreklamation' (Customer Complaint). Die Verfolgung dieser Informationen ist entscheidend für das Customer Relationship Management und das Verständnis der Kundenauswirkungen von Qualitätsproblemen. Die Analyse nach Kunden ermöglicht es dem Unternehmen zu identifizieren, ob bestimmte Kunden mehr Qualitätsprobleme als andere erleben oder ob die Lösungszeiten je nach Kunde variieren. Dies unterstützt das Dashboard 'Quality Events nach Schweregrad und Auswirkungen' (Quality Events By Severity And Impact), indem es die Kundendimension zur Analyse der Auswirkungen hinzufügt.
Bedeutung
Verbindet Qualitätsereignisse mit Kunden, ermöglicht die Analyse kundenspezifischer Probleme und stellt sicher, dass hochwertige Kunden priorisierten Support erhalten.
Datenquelle
Typischerweise zu finden in den Partnerfunktionen für die Meldung. Kann auch in QMEL-KUNUM enthalten sein, wenn es sich um eine Reklamation aus einem Kundenauftrag handelt.
Beispiele
CUST-10045CUST-20399CUST-80110
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Zeitstempel, der angibt, wann die Daten für diesen Datensatz zuletzt aus dem Quellsystem aktualisiert wurden. | ||
|
Beschreibung
Dieses attribute liefert einen timestamp für die letzte data Extraktion oder Aktualisierung aus dem Quellsystem. Es informiert Benutzer über die Aktualität der data, die sie analysieren. In jedem analytischen Dashboard oder Bericht ist die Anzeige dieser Informationen entscheidend, um die Erwartungen der Benutzer an die data Aktualität zu steuern. Es hilft, zwischen kürzlichen Process Änderungen und Artefakten veralteter data zu unterscheiden.
Bedeutung
Informiert Benutzer über die Aktualität der Daten, was entscheidend ist, um zeitnahe und präzise Entscheidungen auf Basis der Process-Mining-Analyse zu treffen.
Datenquelle
Hierbei handelt es sich um ein Metadatenfeld, das vom Datenextraktionstool oder der Datenpipeline zum Zeitpunkt der Datenaktualisierung generiert und befüllt wird.
Beispiele
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
Meldungsstatus
SystemStatus
|
Der aktuelle Bearbeitungsstatus der Qualitätsmeldung, z.B. „Offen“ oder „Abgeschlossen“. | ||
|
Beschreibung
Der Systemstatus zeigt den aktuellen Zustand des Quality Event in seinem Lebenszyklus an. SAP verwendet ein Statusverwaltungssystem, bei dem Status wie OSNO (Outstanding Notification), NOPR (Notification in Process) und NOCO (Notification Completed) den Fortschritt widerspiegeln. Dieses attribute wird oft verwendet, um die Aktivitäten im Event Log abzuleiten. Es ist auch wertvoll als Dimension zum Filtern von cases, um beispielsweise nur offene oder kürzlich abgeschlossene Quality Events zu analysieren. Das Verständnis von Statusübergängen ist entscheidend für den Aufbau eines genauen Process Model.
Bedeutung
Gibt den aktuellen Status eines Falls an, ermöglicht die Filterung von aktiven versus geschlossenen Fällen und hilft, die Prozessaktivitäten selbst abzuleiten.
Datenquelle
Abgeleitet aus den Tabellen JEST und JSTO, die Statusinformationen für verschiedene SAP-Objekte speichern. Die Verknüpfung erfolgt über QMEL-OBJNR.
Beispiele
OSNO NOPRNOCOTSCO
|
|||
|
Quellsystem
SourceSystem
|
Identifiziert das Quellsystem, aus dem die Daten extrahiert wurden, z. B. die spezifische SAP S/4HANA-Instanz. | ||
|
Beschreibung
Dieses attribute spezifiziert den Ursprung der Quality Management data. In einer Umgebung mit mehreren ERPs oder integrierten Systemen ist dieses Feld entscheidend, um data Quellen zu unterscheiden und die data Integrität sicherzustellen. Für die Analyse ermöglicht es das Filtern oder Vergleichen von Prozessen über verschiedene Systeme oder Organisationseinheiten hinweg. Es ist oft ein konstanter Wert für einen gegebenen Datensatz, aber obligatorisch für die data governance und den Kontext.
Bedeutung
Bietet wesentlichen Kontext über den Ursprung der data, was für die data governance und in Umgebungen mit mehreren miteinander verbundenen Systemen entscheidend ist.
Datenquelle
Dies ist typischerweise ein statischer Wert, der während des Datenextraktionsprozesses zur Identifizierung des SAP S/4HANA Mandanten und der System-ID hinzugefügt wird.
Beispiele
S4H_PROD_100SAP_QM_EUS4HANA_QAS_200
|
|||
|
Termingerechte Fertigstellung
IsOnTimeCompletion
|
Ein boolesches Flag, das anzeigt, ob das Qualitätsereignis bis zu seinem Zieltermin abgeschlossen wurde. | ||
|
Beschreibung
Dieses berechnete Flag vergleicht den tatsächlichen Abschluss-timestamp eines Quality Event mit seinem 'Zielauflösungsdatum' (Target Resolution Date). Es ist true, wenn das event am oder vor dem Zieldatum geschlossen wurde, und false andernfalls. Dieses attribute bietet eine einfache, direkte Messgröße zur Leistungsüberwachung und ist die Basis für das Dashboard 'Quality Event On-Time Completion' und den KPI 'Quality Action On-Time Rate'. Es ermöglicht einfaches Filtern und Aggregieren, um die termingerechte Leistung über verschiedene Dimensionen wie Abteilung, Produkt oder Meldungsart zu verstehen.
Bedeutung
Liefert ein klares, binäres Ergebnis für die Leistungsverfolgung anhand von Fristen, wodurch die Messung und Berichterstattung über die SLA-Compliance vereinfacht wird.
Datenquelle
Berechnetes Attribut, abgeleitet durch den Vergleich des Timestamps der abschließenden Aktivität mit dem Attribut 'TargetResolutionDate'.
Beispiele
truefalsch
|
|||
|
Werk
Plant
|
Das Fertigungswerk oder der Standort, an dem das Quality Event entstanden ist oder verwaltet wird. | ||
|
Beschreibung
Das Plant attribute spezifiziert den physischen Standort, wie z.B. eine Fabrik oder ein Lager, der mit dem Quality Event verbunden ist. Es bietet einen geografischen oder organisatorischen Kontext dafür, wo Qualitätsprobleme auftreten. Dies ist eine mächtige Dimension für vergleichende Analysen. Durch das Filtern oder Gruppieren nach Werk kann das Management die Leistung verschiedener Standorte vergleichen, standortspezifische Probleme identifizieren und Best Practices von leistungsstarken Werken teilen. Es hilft bei der Beantwortung von Fragen wie 'Welches Werk hat die längste Root Cause Analysis Zykluszeit?'.
Bedeutung
Ermöglicht den Leistungsvergleich über verschiedene Betriebsstandorte hinweg und hilft, standortspezifische Probleme und Best Practices zu identifizieren.
Datenquelle
Das mit dem Meldungskopf verbundene Werk befindet sich in QMEL-WERKS. Falls es sich auf ein spezifisches Material bezieht, kann es auch auf Positionsebene gefunden werden.
Beispiele
100017102000
|
|||
|
Wirksamkeit der Maßnahme
EffectivenessEvaluation
|
Das Ergebnis der Verifizierungsprüfung, um festzustellen, ob eine implementierte Maßnahme wirksam war. | ||
|
Beschreibung
Dieses attribute zeichnet das Ergebnis der Wirksamkeitsprüfung auf, einen entscheidenden letzten Schritt in der Quality Management Schleife. Es bestätigt, ob die ergriffenen Korrektur- oder Vorbeugemaßnahmen die Root Cause erfolgreich behoben und ein Wiederauftreten verhindert haben. Dies ist das primäre attribute für das Dashboard 'Action Effectiveness Verification' und den KPI 'Action Effectiveness Verification Rate'. Es bietet direkte Einblicke in die Qualität des Problemlösungsprozesses selbst. Eine hohe Rate ineffektiver Maßnahmen weist auf die Notwendigkeit hin, die Root Cause Analysis oder die Maßnahmenplanungsphasen zu verbessern.
Bedeutung
Misst direkt den Erfolg des Problemlösungsprozesses und zeigt an, ob Maßnahmen ein erneutes Auftreten von Problemen tatsächlich verhindern.
Datenquelle
Diese Informationen sind oft in Folgeaktionen oder spezifischen Aufgabenstatus innerhalb der Qualitätsmeldung hinterlegt. Es kann sich dabei um ein benutzerdefiniertes Feld oder einen bestimmten Statuscode handeln.
Beispiele
EffektivNicht wirksamÜberwachung erforderlich
|
|||
Quality Management Aktivitäten
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Korrekturmaßnahme implementiert
|
Markiert den Abschluss der im Korrekturmaßnahmenplan definierten Arbeit. Dies wird typischerweise erfasst, wenn die zugewiesene Korrekturmaßnahmenaufgabe innerhalb der Qualitätsmeldung als abgeschlossen markiert wird. | ||
|
Bedeutung
Dies ist ein wichtiger Meilenstein, der anzeigt, dass Schritte zur Behebung des Qualitätsproblems eingeleitet wurden. Er ist entscheidend für die Messung der fristgerechten Abschlussrate von Maßnahmen und der Gesamteffizienz der Behebungsphase.
Datenquelle
Abgeleitet aus dem Abschluss einer Korrekturmaßnahmenaufgabe in der Tabelle QMSM. Das Abschlussdatum wird im Feld ERLDT oder über eine Statusänderung 'Abgeschlossen' in den Tabellen JEST/JCDS erfasst.
Erfassen
Identifizieren Sie den Abschluss-Timestamp (ERLDT) der Korrekturmaßnahmenaufgabe in der Tabelle QMSM.
Ereignistyp
inferred
|
|||
|
Meldung abgeschlossen
|
Zeigt den geschäftlichen Abschluss der Qualitätsmeldung an, was bedeutet, dass alle erforderlichen Maßnahmen ergriffen wurden und das Problem aus operativer Sicht gelöst ist. Dies ist eine formale Statusänderung im System. | ||
|
Bedeutung
Diese Activity dient als primärer Endpunkt zur Messung der geschäftlichen Lösungszeit. Sie bestätigt, dass aus Sicht des Prozesseigners der case abgeschlossen ist, auch wenn der technische Abschluss noch aussteht.
Datenquelle
Abgeleitet aus einer Statusänderung am Qualitätsmeldungsobjekt. Dies wird erfasst, indem der Timestamp identifiziert wird, wann ein Status wie 'NOCO' (Meldung abgeschlossen) in der Tabelle JCDS gesetzt wird.
Erfassen
Identifizieren Sie den Timestamp, wenn der Status 'Meldung abgeschlossen' in der Tabelle JCDS gesetzt wird.
Ereignistyp
inferred
|
|||
|
Qualitätsmeldung erstellt
|
Diese Activity markiert den offiziellen Beginn des Quality Management Prozesses, bei dem ein qualitätsbezogenes Problem, Defekt oder eine Beschwerde formal erfasst wird. Die Erstellung der Qualitätsmeldung in SAP S/4HANA erfasst die initialen Details und weist eine eindeutige Kennung zu, wodurch der case initiiert wird. | ||
|
Bedeutung
Als primäres Startereignis ist diese Aktivität unerlässlich, um die End-to-End-Durchlaufzeit des Qualitätslösungs-Prozesses zu messen. Sie liefert die Basis, um zu verfolgen, wie lange es dauert, Qualitätsereignisse zu bearbeiten und abzuschließen.
Datenquelle
Dies ist ein explizites Ereignis, das aus der QM-Meldungskopf-Tabelle QMEL erfasst wird. Der Erstellungszeitstempel ist typischerweise im Feld ERDAT für die entsprechende Meldungsnummer QMNUM zu finden.
Erfassen
Verwenden Sie den Erstellungszeitstempel (ERDAT) aus der Tabelle QMEL für die gegebene Meldung.
Ereignistyp
explicit
|
|||
|
Ursachenanalyse abgeschlossen
|
Markiert den Abschluss der Untersuchungsphase, in der die zugrundeliegende Ursache des Qualitätsproblems identifiziert wurde. Dies wird typischerweise aus dem Abschluss einer spezifischen 'Root Cause Analysis' Aufgabe innerhalb der Meldung abgeleitet. | ||
|
Bedeutung
Dies ist ein entscheidender Meilenstein zur Messung der Dauer und Effizienz des Untersuchungsprozesses. Die Identifizierung von Verzögerungen vor diesem Schritt hilft, Engpässe bei der Problemanalyse und Entscheidungsfindung genau zu lokalisieren.
Datenquelle
Abgeleitet aus dem Abschluss einer Untersuchungs- oder RCA-spezifischen Aufgabe in der Tabelle QMSM. Der Abschluss wird durch eine Statusänderung oder die Füllung des Aufgabenabschlussdatumsfeldes (ERLDT) identifiziert.
Erfassen
Identifizieren Sie den Abschluss-Timestamp (ERLDT) der relevanten Ursachenanalyse-Aufgabe in der Tabelle QMSM.
Ereignistyp
inferred
|
|||
|
Verwendungsentscheidung getroffen
|
Stellt die formale Entscheidung über die Qualität von Waren aus einem Prüflos dar, z.B. Annahme oder Ablehnung. Dies ist ein separates event für Qualitätsprobleme, die aus Prüfungen stammen, und wird erfasst, wenn der Verwendungsentscheid gespeichert wird. | ||
|
Bedeutung
Für prüfungsgesteuerte Prozesse ist dies ein wichtiger Meilenstein, der nachfolgende Aktionen wie Materialsperrung oder -freigabe vorgibt. Die Analyse des Zeitpunkts und der Ergebnisse ist entscheidend für das Verständnis der Effizienz der Produktqualitätskontrolle.
Datenquelle
Dies ist ein explizites Ereignis, das in der Verwendungsentscheidungstabelle QAVE aufgezeichnet wird. Der Erstellungszeitstempel des Datensatzes, der dem Prüflos (PRUEFLOS) zugeordnet ist, bezeichnet diese Aktivität.
Erfassen
Verwenden Sie den Erstellungszeitstempel für das relevante Prüflos in der Tabelle QAVE.
Ereignistyp
explicit
|
|||
|
Wirksamkeit der Maßnahme überprüft
|
Bestätigt, dass die implementierte Korrektur- oder Vorbeugemaßnahme erfolgreich war und das Qualitätsproblem ohne Wiederauftreten gelöst wurde. Dies wird bei Abschluss der Wirksamkeitsprüfungsaufgabe oder einer abschließenden Qualitätsprüfung erfasst. | ||
|
Bedeutung
Dies ist ein entscheidender Meilenstein zur Validierung des gesamten Lösungsprozesses. Eine hohe Rate erfolgreicher Verifizierungen deutet auf ein effektives Qualitätsmanagementsystem hin und unterstützt die Reduzierung wiederkehrender Probleme.
Datenquelle
Typischerweise abgeleitet aus dem Abschluss einer Aufgabe 'Wirksamkeitsprüfung' in der Tabelle QMSM (unter Verwendung des Abschlussdatums ERLDT).
Erfassen
Identifizieren Sie den Abschluss-Timestamp der Wirksamkeitsprüfungsaufgabe in QMSM.
Ereignistyp
inferred
|
|||
|
Korrekturmaßnahme vorgeschlagen
|
Diese Activity stellt den Punkt dar, an dem ein Plan zur Korrektur des identifizierten Problems formal dokumentiert wird. In SAP wird dies oft durch die Erstellung einer 'Korrekturmaßnahmen'-Aufgabe innerhalb der Qualitätsmeldung erfasst. | ||
|
Bedeutung
Dieses event initiiert die Lösungsphase des Process. Die Messung der Zeit von der Root Cause Analysis bis zu diesem Schritt kann Verzögerungen in der Maßnahmenplanung aufzeigen.
Datenquelle
Dieses event wird erfasst, wenn eine Aufgabe mit dem Code 'Korrekturmaßnahme' (Corrective Action) in der Tabelle QMSM für die relevante Qualitätsmeldung erstellt wird.
Erfassen
Verwenden Sie den Erstellungszeitstempel (ERDAT) aus der Tabelle QMSM für Aufgaben vom Typ Korrekturmaßnahme.
Ereignistyp
explicit
|
|||
|
Maßnahmenplan genehmigt
|
Zeigt an, dass ein vorgeschlagener Korrektur- oder Vorbeugemaßnahmenplan überprüft und zur Umsetzung genehmigt wurde. Dieser Schritt ist oft kein eigenständiges event und kann aus der Freigabe einer Aufgabe zur Bearbeitung abgeleitet werden. | ||
|
Bedeutung
Lange Verzögerungen in dieser Genehmigungsphase können den gesamten Lösungsprozess erheblich verlangsamen. Die Analyse dieser Dauer hilft, administrative Bottlenecks und Möglichkeiten zur Straffung der Governance zu identifizieren.
Datenquelle
Dies wird typischerweise aus einer Statusänderung einer Aufgabe in Tabelle QMSM abgeleitet, wie z.B. 'Freigegeben'. Der Zeitstempel für diese Statusänderung wäre in der Tabelle JCDS zu finden, verknüpft mit dem Aufgabenobjekt.
Erfassen
Identifizieren Sie den Timestamp, wenn der Status 'Freigegeben' für die Korrektur- oder Vorbeugemaßnahmenaufgabe gesetzt wird.
Ereignistyp
inferred
|
|||
|
Meldung geschlossen
|
Stellt den endgültigen, technischen Abschluss der Qualitätsmeldung im System dar. Nach diesem Zeitpunkt können keine weiteren Änderungen an der Meldung vorgenommen werden, was das absolute Ende des Lebenszyklus des Datensatzes markiert. | ||
|
Bedeutung
Diese Activity stellt das finale End-event für den Process dar. Die Analyse der Zeit zwischen 'Meldung abgeschlossen' (Notification Completed) und 'Meldung geschlossen' (Notification Closed) kann Verzögerungen bei administrativen Abschlussverfahren aufzeigen.
Datenquelle
Abgeleitet aus einer Statusänderung der Qualitätsmeldung, insbesondere wenn ein Archivierungs- oder abschließender Schließstatus gesetzt wird. Diese Änderung wird mit einem Timestamp in der Tabelle JCDS protokolliert.
Erfassen
Identifizieren Sie den Timestamp, wenn der endgültige Status 'Geschlossen' für die Meldung in der Tabelle JCDS gesetzt wird.
Ereignistyp
inferred
|
|||
|
Meldung in Bearbeitung genommen
|
Stellt den Moment dar, in dem eine neu erstellte Meldung aktiv vom Qualitätsteam zur Bearbeitung übernommen wird. Dies ist typischerweise ein abgeleitetes event, das aus einer Systemstatusänderung hervorgeht, die den Arbeitsbeginn anzeigt. | ||
|
Bedeutung
Diese Activity hilft, zwischen der bloßen Erfassung eines Problems und dem tatsächlichen Arbeitsbeginn zu unterscheiden. Die Analyse der Zeitverzögerung zwischen Erstellung und diesem Schritt deckt potenzielle Verzögerungen bei der Problemanerkennung und Ressourcenzuweisung auf.
Datenquelle
Abgeleitet aus einer Statusänderung am Qualitätsmeldungsobjekt. Dies kann durch die Analyse von Statusänderungsprotokollen in den Tabellen JEST und JCDS für einen Status wie 'NOPO' (Meldung in Bearbeitung) verfolgt werden.
Erfassen
Identifizieren Sie den Timestamp, wenn der Status 'in Bearbeitung' für die Meldung in der Tabelle JCDS gesetzt wird.
Ereignistyp
inferred
|
|||
|
Stakeholder benachrichtigt
|
Stellt die Kommunikation der Lösung an relevante Stakeholder, wie Kunden oder interne Abteilungen, dar. Dies ist selten ein automatisiertes System-event und oft ein manueller Schritt. | ||
|
Bedeutung
Eine zeitnahe Stakeholder-Kommunikation ist entscheidend für die Kundenzufriedenheit und Transparenz. Die Messung der Verzögerung zwischen Abschluss und Benachrichtigung kann Lücken in den Kommunikationsprozessen aufzeigen.
Datenquelle
Diese Activity ist schwierig direkt aus SAP zu erfassen. Sie kann aus dem Abschluss einer manuellen Aufgabe in QMSM, die als 'Stakeholder benachrichtigen' (Notify Stakeholder) gekennzeichnet ist, abgeleitet werden oder würde eine Analyse externer Systeme wie email logs erfordern.
Erfassen
Identifiziert den Abschluss einer manuellen Kommunikationsaufgabe, falls eine verwendet wird. Andernfalls ist dies typischerweise nicht verfügbar.
Ereignistyp
inferred
|
|||
|
Untersuchungsaufgabe zugewiesen
|
Dieses event tritt auf, wenn eine spezifische Aufgabe, wie die Untersuchung der Root Cause, formal erstellt und einer Person oder Abteilung zugewiesen wird. Dies wird erfasst, wenn ein Aufgabendatensatz innerhalb der Qualitätsmeldung erstellt wird. | ||
|
Bedeutung
Die Nachverfolgung der Aufgabenvergabe ist entscheidend für das Verständnis der Arbeitslastverteilung und die Identifizierung von Engpässen in der Ressourcenzuweisung. Sie kennzeichnet den Beginn der Untersuchungsphase und ist ein wichtiger Input zur Messung der Durchlaufzeit der Ursachenanalyse.
Datenquelle
Erfasst aus der Aufgabenverwaltungstabelle QMSM, verknüpft mit der Qualitätsmeldung. Das Erstellungsdatum (ERDAT) einer Aufgabe mit einem relevanten Code, z. B. für eine Untersuchung, kennzeichnet dieses Ereignis.
Erfassen
Verwenden Sie den Erstellungszeitstempel (ERDAT) aus der Tabelle QMSM für Untersuchungsaufgaben.
Ereignistyp
explicit
|
|||
|
Vorbeugemaßnahme implementiert
|
Markiert die erfolgreiche Ausführung der geplanten Vorbeugemaßnahme. Dies wird durch die Erfassung des Abschlusses der entsprechenden Vorbeugemaßnahmenaufgabe im System festgehalten. | ||
|
Bedeutung
Der Abschluss von Vorbeugemaßnahmen ist ein entscheidender Schritt in ausgereiften Qualitätsprozessen. Die Verfolgung dieser Activity hilft, das Engagement zur Verhinderung zukünftiger Probleme und zur Reduzierung wiederkehrender Probleme zu messen.
Datenquelle
Abgeleitet aus dem Abschluss einer vorbeugenden Maßnahmenaufgabe in der Tabelle QMSM, angezeigt durch das Feld ERLDT oder eine Statusänderung 'Abgeschlossen'.
Erfassen
Identifizieren Sie den Abschluss-Timestamp (ERLDT) der vorbeugenden Maßnahmenaufgabe in der Tabelle QMSM.
Ereignistyp
inferred
|
|||
|
Vorbeugemaßnahme vorgeschlagen
|
Diese Activity tritt auf, wenn ein Plan erstellt wird, um das Wiederauftreten eines Qualitätsproblems zu verhindern. Ähnlich wie bei Korrekturmaßnahmen wird sie oft durch die Erstellung einer 'Vorbeugemaßnahmen'-Aufgabe erfasst. | ||
|
Bedeutung
Dieses event ist entscheidend für die Bewertung des Fokus der Organisation auf proaktive Qualitätsverbesserung anstatt nur auf reaktive Korrekturen. Es markiert den Beginn langfristiger Lösungsbemühungen.
Datenquelle
Dieses event wird bei der Erstellung einer Aufgabe mit dem Code 'Vorbeugemaßnahme' (Preventive Action) in der Tabelle QMSM für die spezifische Qualitätsmeldung erfasst.
Erfassen
Verwenden Sie den Erstellungszeitstempel (ERDAT) aus der Tabelle QMSM für Aufgaben vom Typ Vorbeugemaßnahme.
Ereignistyp
explicit
|
|||
|
Wirksamkeitsprüfung erforderlich
|
Gibt an, dass eine Nachverfolgung erforderlich ist, um zu bestätigen, dass die implementierten Maßnahmen das Problem erfolgreich gelöst haben. Dies wird oft durch einen spezifischen Status der Meldung oder die Erstellung einer dedizierten Verifizierungsaufgabe dargestellt. | ||
|
Bedeutung
Diese Activity stellt sicher, dass der Quality Management Prozess eine entscheidende Validierungsschleife enthält. Sie trennt die Implementierung einer Maßnahme von der Bestätigung ihres Erfolgs.
Datenquelle
Kann aus einer Statusänderung der Qualitätsmeldung (via JEST/JCDS) oder der Erstellung einer spezifischen 'Wirksamkeitsprüfung'-Aufgabe in der Tabelle QMSM abgeleitet werden.
Erfassen
Identifizieren Sie den Timestamp der Statusänderung oder der Erstellung einer Verifizierungsaufgabe in QMSM.
Ereignistyp
inferred
|
|||