> Kontinuierliche Prozessverbesserung > Qualitätsmanagement > Oracle Quality Management > Daten Template

Ihr Daten-Template für das Qualitätsmanagement

Oracle Quality Management

Attribute des Qualitätsmanagements (20) Aktivitäten des Qualitätsmanagements (14) Anleitungen zur Extraktion (3)

Ihr Daten-Template für das Qualitätsmanagement

Dieses Template bietet eine umfassende Übersicht über die wesentlichen Datenattribute und Prozessaktivitäten, die Sie für eine wirksame Analyse des Qualitätsmanagements benötigen. Es enthält außerdem praktische Hinweise dazu, wie Sie diese wichtigen Informationen aus Ihrem Oracle-Quality-Management-System extrahieren. Verwenden Sie diese Ressource, um alle erforderlichen Daten für fundierte Erkenntnisse und die Optimierung Ihrer Prozesse zu erfassen.

Empfohlene zu erfassende Attribute
Wichtige zu überwachende Aktivitäten
Hinweise zur Extraktion

Neu bei Event Logs? Lernen Sie, wie Sie ein Process-Mining-Event-Log erstellen.

Template herunterladen

Attribute des Qualitätsmanagements

Dies sind die empfohlenen Datenfelder und Kontextinformationen, die Sie für eine umfassende Analyse und aussagekräftige Erkenntnisse zum Qualitätsmanagement in Ihr Event Log aufnehmen sollten.

3 Erforderlich 7 Empfohlen 10 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Der Name der konkreten Aufgabe oder des Schritts, der innerhalb des Qualitätsmanagementprozesses ausgeführt wurde.
Beschreibung Dieses Attribut beschreibt ein einzelnes Event oder eine einzelne Aktion im Rahmen der Bearbeitung eines Qualitätsereignisses. Die nach Timestamps geordnete Abfolge dieser Aktivitäten bildet den Prozessfluss jedes Cases. Die Analyse des Aktivitätsnamens ist ein zentraler Bestandteil von Process Mining. Sie ermöglicht die Ermittlung des tatsächlichen Prozessmodells, den Vergleich mit einem Sollmodell zur Konformitätsprüfung sowie die Identifizierung von Engpässen oder Nacharbeitsschleifen zwischen bestimmten Aktivitäten. So lässt sich beispielsweise die Zeit zwischen „Investigation Initiated“ und „Root Cause Analysis Performed“ messen. Warum das wichtig ist Dieses Attribut ist grundlegend für die Abbildung des Prozessflusses, die Identifizierung von Abweichungen und das Verständnis der tatsächlichen Arbeitsweise. Bezugsquelle Diese Informationen werden typischerweise aus Event Logs, Statusänderungsdatensätzen oder Tabellen zur Aktionshistorie innerhalb des Oracle Quality Management-Moduls abgeleitet. Beispiele Qualitätsproblem identifiziertUntersuchung eingeleitetKorrekturmaßnahmenplan genehmigtAbschließende Prüfung und Schließung
	Qualitätsereignis QualityEventId	Der eindeutige Identifier für ein einzelnes Qualitätsereignis, beispielsweise eine Nichtkonformität, eine Beschwerde oder eine Abweichung.
Beschreibung Die Quality Event ID dient als primärer Case-Identifier und fasst alle zugehörigen Aktivitäten von der ersten Meldung bis zum endgültigen Abschluss zusammen. Jedem Qualitätsvorfall wird eine eindeutige ID zugewiesen, wodurch ein vollständiger historischer Datensatz des Untersuchungs- und Lösungsprozesses entsteht. In der Process-Mining-Analyse ist dieses Attribut grundlegend für die Rekonstruktion des End-to-End-Verlaufs jedes Qualitätsereignisses. Es ermöglicht die Berechnung der gesamten Zykluszeiten, die Identifizierung von Prozessvarianten und die Analyse der Bearbeitung verschiedener Ereignistypen. Indem jedes Aktivitätsprotokoll mit einer bestimmten Quality Event ID verknüpft wird, können Analysten den vollständigen Prozessfluss visualisieren und systemische Engpässe oder Compliance-Probleme erkennen. Warum das wichtig ist Diese ID ist entscheidend, da sie den Umfang eines einzelnen Cases definiert. Dadurch lassen sich Qualitätsereignisse präzise nachverfolgen und End-to-End-Leistungskennzahlen berechnen. Bezugsquelle Dies ist typischerweise der Primärschlüssel in den zentralen Tabellen für Qualitätsereignisse oder Prüfpläne innerhalb von Oracle Quality Management, beispielsweise QA_RESULTS. Beispiele NC-2023-00123CAPA-45892QE-500-A
	Startzeit des Events EventStartTime	Der Timestamp, der angibt, wann eine Aktivität oder ein Event begonnen hat.
Beschreibung Dieses Attribut liefert das genaue Datum und die genaue Uhrzeit, zu denen ein bestimmter Prozessschritt begonnen hat. Es ist das zentrale zeitliche Element für die chronologische Sortierung von Events und den Aufbau der Prozesssequenz für jeden Case eines Qualitätsereignisses. In der Analyse ist die Startzeit des Events entscheidend für die Berechnung von Zykluszeiten, Dauern und Wartezeiten zwischen Aktivitäten. Sie ermöglicht die Identifizierung von Engpässen, indem sie lange Verzögerungen zwischen aufeinanderfolgenden Schritten sichtbar macht, und dient zur Messung der Leistung anhand zeitbezogener KPIs wie „Root Cause Analysis Lead Time“. Warum das wichtig ist Dieser Timestamp bildet das Fundament der Prozessanalyse. Er ermöglicht alle zeitbezogenen Berechnungen und die korrekte Reihenfolge der Aktivitäten. Bezugsquelle Dieser Timestamp ist typischerweise in Transaktionsprotokollen oder Verlaufstabellen zu Qualitätsmaßnahmen und Prüfplänen zu finden, häufig unter der Bezeichnung CREATION_DATE oder einer ähnlichen Bezeichnung. Beispiele 2023-04-15T09:00:12Z2023-04-16T11:30:00Z2023-05-01T14:22:45Z
	Aktueller Status CurrentStatus	Der aktuelle Status des Cases eines Qualitätsereignisses.
Beschreibung Dieses Attribut gibt den aktuellen Status des Qualitätsereignisses in seinem Lebenszyklus an, beispielsweise „Open“, „Under Investigation“, „Pending Approval“ oder „Closed“. Es zeigt, an welcher Stelle sich der Case zum Zeitpunkt der Datenextraktion im Prozess befindet. Dieses Attribut ist für das operative Monitoring entscheidend und unterstützt direkt das Dashboard „Open Quality Events & Status Overview“. Manager können damit die aktuelle Pipeline von Qualitätsproblemen schnell überblicken und Ressourcen priorisieren. Im Process Mining hilft die Filterung nach dem finalen Status, die Ergebnisse verschiedener Prozesspfade zu analysieren. Warum das wichtig ist Damit erhalten Sie einen aktuellen Überblick über die Pipeline der Qualitätsereignisse und können aktive Cases wirksam steuern und priorisieren. Bezugsquelle Diese Informationen sind normalerweise in der zentralen Kopftabelle für Qualitätsereignisse verfügbar und spiegeln den zuletzt bekannten Status des Ereignisses wider. Beispiele OffenIn BearbeitungGenehmigung ausstehendGeschlossen
	Endzeit des Events EventEndTime	Der Timestamp, der angibt, wann eine Aktivität oder ein Event abgeschlossen wurde.
Beschreibung Die Endzeit des Events kennzeichnet den Abschluss einer bestimmten Aktivität. Zusammen mit der Startzeit des Events definiert sie die Bearbeitungszeit dieser Aktivität. In manchen Systemen ist eine Aktivität unmittelbar abgeschlossen, sodass Start- und Endzeit identisch sind. Dieses Attribut ist für eine detaillierte Daueranalyse unerlässlich. Es ermöglicht Analysten, zwischen aktiver Bearbeitungszeit, also der Zeit zwischen Start und Ende, und Wartezeit, also der Zeit zwischen dem Ende einer Aktivität und dem Beginn der nächsten, zu unterscheiden. Das ist entscheidend, um zu erkennen, wann Ressourcen aktiv arbeiten und wann Übergaben Verzögerungen verursachen. Warum das wichtig ist Damit lassen sich die Bearbeitungszeiten von Aktivitäten präzise berechnen. So können ineffiziente Aufgaben von langen Wartezeiten unterschieden werden. Bezugsquelle Diese Information kann in denselben Transaktions- oder Verlaufstabellen wie die Startzeit verfügbar sein, teilweise als LAST_UPDATE_DATE oder als spezifischer Abschluss-Timestamp. Sie kann auch aus der Startzeit des nachfolgenden Events abgeleitet werden. Beispiele 2023-04-15T09:15:30Z2023-04-16T12:00:00Z2023-05-02T10:00:00Z
	Kategorie der Grundursache RootCauseCategory	Die Klassifizierung der ermittelten Grundursache des Qualitätsproblems.
Beschreibung Nach einer durchgeführten Ursachenanalyse werden die Ergebnisse häufig vordefinierten Gruppen wie „Geräteausfall“, „menschlicher Fehler“ oder „Konstruktionsfehler“ zugeordnet. Dieses Attribut speichert diese abschließende Klassifizierung. Die Analyse des Prozesses nach der Kategorie der Grundursache ist besonders aussagekräftig. Sie verlagert den Fokus von der Behebung einzelner Symptome auf die zugrunde liegenden systemischen Probleme. Eine hohe Anzahl von Ereignissen mit der Grundursache „Schulungsproblem“ kann beispielsweise auf den Bedarf an besseren Schulungsprogrammen für Mitarbeitende hinweisen, ein zentrales Ziel vorbeugender Maßnahmen. Warum das wichtig ist Dieses Attribut ist entscheidend für den Wechsel von einem reaktiven zu einem proaktiven Qualitätsmanagement, da es die Analyse der grundlegenden Ursachen von Fehlern ermöglicht. Bezugsquelle Prüfen Sie die Dokumentation zu Oracle Quality Management. Dabei handelt es sich wahrscheinlich um ein benutzerdefiniertes Element in einem Erfassungsplan, das nach der Aktivität „Ursachenanalyse durchgeführt“ befüllt wird. Beispiele Fehlfunktion der AnlageMaterialfehlerMenschlicher FehlerVerfahren nicht befolgt
	Schweregrad SeverityLevel	Eine Klassifizierung der Auswirkungen des Qualitätsereignisses, beispielsweise kritisch, schwerwiegend oder geringfügig.
Beschreibung Der Schweregrad ist eine meist während der Triage vorgenommene Einschätzung der möglichen Auswirkungen des Qualitätsproblems auf Kunden, Compliance oder den Geschäftsbetrieb. Diese Klassifizierung hilft bei der Priorisierung von Ressourcen und der Festlegung der Dringlichkeit der erforderlichen Reaktion. Im Process Mining ist dieses Attribut für die Segmentierung entscheidend. Analysten können Prozessflüsse, Zykluszeiten und Ergebnisse von Ereignissen mit hohem und niedrigem Schweregrad vergleichen. Das unterstützt das Dashboard „Quality Event Triage Consistency“ und den KPI „Severity-Based Resolution Rate“, indem sichtbar wird, ob kritische Probleme tatsächlich schneller und wirksamer bearbeitet werden. Warum das wichtig ist Damit lassen sich Analysen priorisieren und segmentieren. So können Qualitätsereignisse mit großen Auswirkungen wirksam und effizient bearbeitet werden. Bezugsquelle Prüfen Sie die Dokumentation zu Oracle Quality Management. Der Schweregrad ist häufig ein konfigurierbares Element innerhalb eines Prüfplans. Beispiele 1 - Kritisch2 - Schwerwiegend3 - Geringfügig4 - Information
	Verantwortliche Abteilung ResponsibleDepartment	Die Abteilung oder der Funktionsbereich, der für das Qualitätsereignis oder die aktuelle Aktivität verantwortlich ist.
Beschreibung Dieses Attribut identifiziert das Team oder die Abteilung, die mit der Bearbeitung des Qualitätsereignisses beauftragt ist. Dabei kann es sich um Quality Assurance, Engineering, Produktion oder eine andere Gruppe handeln. Die Zuständigkeit kann sich ändern, während das Ereignis seinen Lebenszyklus durchläuft. Im Process Mining ist die Analyse nach verantwortlicher Abteilung entscheidend, um die Arbeitslastverteilung zu verstehen, Abteilungsengpässe zu erkennen und die Leistung verschiedener Teams zu vergleichen. Sie unterstützt das Dashboard „Quality Event Resource Allocation“, indem sie zeigt, welche Abteilungen an welchen Aktivitätstypen beteiligt sind und wie sich die Ressourcenplanung verbessern lässt. Warum das wichtig ist Damit lassen sich Arbeitslast, Leistung und Engpässe nach Abteilung analysieren. Das ist entscheidend für die Ressourcenplanung und die organisatorische Weiterentwicklung. Bezugsquelle Prüfen Sie die Dokumentation zu Oracle Quality Management. Die Informationen können in Tabellen zu Qualitätsmaßnahmen oder Zuweisungen gespeichert und mit dem Qualitätsereignis verknüpft sein. Beispiele QualitätsengineeringProduktionsbetriebLieferantenqualitätKonstruktionsengineering
	Zieltermin für die Lösung TargetResolutionDate	Das geplante oder erwartete Datum für den endgültigen Abschluss des Qualitätsereignisses.
Beschreibung Dieses Attribut bezeichnet die Frist, bis zu der ein Qualitätsereignis vollständig gelöst sein soll. Es dient als Service Level Agreement (SLA) oder internes Ziel und wird häufig anhand des Schweregrads oder Typs des Ereignisses festgelegt. Dieses Datum ist für das Performance-Monitoring grundlegend und fließt direkt in die Berechnung des KPI „CAPA Impl. On-Time Rate“ ein. Durch den Vergleich der tatsächlichen Abschlussdaten von Aktivitäten mit diesem Ziel können Analysten die Termintreue messen, von Verzögerung bedrohte Ereignisse erkennen und Trends bei der fristgerechten Bearbeitung verfolgen. Das unterstützt die Verkürzung von Lösungszyklen. Warum das wichtig ist Das Datum dient als Referenz für die Messung der Termintreue und ist für die Berechnung von KPIs zur fristgerechten Bearbeitung sowie für das SLA-Management unerlässlich. Bezugsquelle Prüfen Sie die Dokumentation zu Oracle Quality Management. Dabei kann es sich um ein Standard-Datumsfeld oder ein benutzerdefiniertes Element im Prüfplan handeln. Beispiele 2023-05-302023-06-152024-01-10
	Zugewiesener Benutzer AssignedUser	Der einzelne Benutzer, der mit der Ausführung einer Aktivität oder der Verantwortung für das Qualitätsereignis betraut ist.
Beschreibung Dieses Attribut gibt die Person an, die für eine bestimmte Aufgabe oder die übergreifende Bearbeitung des Qualitätsereignisses verantwortlich ist. Es bietet einen detaillierteren Einblick als die verantwortliche Abteilung. Die Analyse nach Benutzer hilft, individuelle Arbeitslasten zu verstehen, Schulungsbedarf zu erkennen und besonders leistungsstarke Mitarbeiter zu identifizieren. Sie kann außerdem Muster sichtbar machen, etwa wenn Arbeit regelmäßig neu zugewiesen wird oder Aufgaben bei bestimmten Personen ins Stocken geraten. Diese Detailtiefe unterstützt das Leistungsmanagement und eine präzise Ressourcenoptimierung. Warum das wichtig ist Damit lassen sich individuelle Arbeitslast und Leistung detailliert analysieren. So können Ressourcenengpässe oder Schulungsmöglichkeiten erkannt werden. Bezugsquelle Prüfen Sie die Dokumentation zu Oracle Quality Management. Informationen zur Benutzerzuweisung werden typischerweise in Aktions- oder Workflow-Tabellen gespeichert, die mit dem Qualitätsereignis verknüpft sind. Beispiele j.smitha.jonesr.williams
	Abschlusscode ClosureCode	Ein Code, der den Grund oder das Ergebnis des Abschlusses des Qualitätsereignisses angibt.
Beschreibung Beim Abschluss eines Qualitätsereignisses wird häufig ein Abschlusscode vergeben, um das endgültige Ergebnis zu klassifizieren. Beispiele sind „Maßnahme wirksam“, „Keine Maßnahme erforderlich“ oder „Doppeltes Problem“. Dieses Attribut ist für die Analyse von Ergebnissen besonders nützlich. Durch die Filterung nach verschiedenen Abschlusscodes können Analysten die Prozesspfade untersuchen, die zu erfolgreichen Ergebnissen führen, und sie mit weniger erfolgreichen Verläufen vergleichen. So lassen sich Fragen beantworten wie: „Wie sieht unser Prozess bei Problemen aus, die als Duplikate geschlossen werden?“ Außerdem können Ineffizienzen bei der Triage erkannt werden. Warum das wichtig ist Es liefert wichtige Informationen über das Ergebnis eines Cases und ermöglicht die Analyse, welche Prozesspfade zu erfolgreichen Lösungen führen. Bezugsquelle Prüfen Sie die Dokumentation zu Oracle Quality Management. Dabei handelt es sich wahrscheinlich um ein Feld, das während der abschließenden Abschlussaktivität befüllt wird. Beispiele WIRKSAMKEINE_MASSNAHMEDOPPELTRISIKO_AKZEPTIERT
	Gesamtdurchlaufzeit TotalCycleTime	Die gesamte Zeit vom Erkennen eines Qualitätsproblems bis zu seinem endgültigen Abschluss.
Beschreibung Dieses Attribut misst die vollständige End-to-End-Dauer eines einzelnen Qualitätsereignis-Cases. Es wird als Differenz zwischen dem Timestamp der ersten Aktivität („Qualitätsproblem erkannt“) und dem Timestamp der letzten Aktivität („Abschließende Prüfung und Abschluss“) berechnet. Dies ist ein zentraler Key Performance Indicator (KPI) für die Gesamteffizienz des Qualitätsmanagementprozesses. Er bildet die wichtigste Kennzahl für das Dashboard „End-to-End-Durchlaufzeit von Qualitätsereignissen“. Die zeitliche Entwicklung dieser Kennzahl sowie ihre Segmentierung nach Attributen wie Schweregrad oder Problemkategorie geben einen übergeordneten Einblick in den Zustand des Prozesses und die Wirkung von Verbesserungsmaßnahmen. Warum das wichtig ist Dies ist ein entscheidender KPI, der die Geschwindigkeit und Effizienz des gesamten Qualitätsmanagementprozesses vom Anfang bis zum Ende misst. Bezugsquelle Dieser Wert wird während der Datenverarbeitung für Process Mining auf Case-Ebene berechnet. Dafür werden die Startzeit des ersten Ereignisses und die Endzeit des letzten Ereignisses für jede QualityEventId benötigt. Beispiele P30DT12HP15DP92D
	Geschäftseinheit BusinessUnit	Die Geschäftseinheit oder der Unternehmensbereich, in dem das Qualitätsereignis aufgetreten ist oder bearbeitet wird.
Beschreibung Dieses Attribut ordnet das Qualitätsereignis einem bestimmten Teil der Unternehmensstruktur zu. Dadurch lassen sich die Qualitätsleistungen verschiedener Organisationseinheiten analysieren und vergleichen. Die Segmentierung der Prozessanalyse nach Geschäftseinheit ist für große Unternehmen eine häufige Anforderung. Sie ermöglicht Dashboards für einzelne Geschäftseinheiten und zeigt, ob bestimmte Bereiche effizientere Qualitätsprozesse haben oder mit besonderen Herausforderungen konfrontiert sind. Das unterstützt die unternehmensweite Steuerung und den Austausch bewährter Vorgehensweisen. Warum das wichtig ist Es ermöglicht den Vergleich und die Analyse der Leistung verschiedener Unternehmensteile und unterstützt damit ein unternehmensweites Qualitätsmanagement. Bezugsquelle Dieses Attribut gehört typischerweise zu den Organisationskontextdaten der Transaktion und wird häufig aus den Stammdaten des Benutzers oder der Abteilung abgeleitet. Beispiele MedizinprodukteUnterhaltungselektronikAutomobilteile
	ID des Korrekturmaßnahmenplans CorrectiveActionPlanId	Die eindeutige Kennung des Korrekturmaßnahmenplans (CAPA), der zur Bearbeitung des Qualitätsereignisses erstellt wurde.
Beschreibung Dieses Attribut stellt eine direkte Verbindung zwischen einem Qualitätsereignis und dem konkreten Korrektur- und Vorbeugemaßnahmenplan her, der zu seiner Behebung vorgesehen ist. Dabei handelt es sich häufig um ein separates Objekt im System mit eigenem Lebenszyklus. In der Analyse kann diese ID verwendet werden, um Daten aus dem Prozess für Qualitätsereignisse mit Daten aus dem CAPA-Managementprozess zu verknüpfen. So entsteht ein umfassenderes Bild. Außerdem lässt sich prüfen, ob jedem Ereignis, für das eine CAPA erforderlich ist, eine solche zugewiesen wurde, und wie wirksam diese Maßnahmen sind. Warum das wichtig ist Es verbindet das Problem, also das Qualitätsereignis, mit der Lösung, also der CAPA, und ermöglicht dadurch eine umfassendere End-to-End-Analyse des Qualitätsmanagementsystems. Bezugsquelle Dies wäre ein Referenzfeld im Datensatz des Qualitätsereignisses, das auf einen Datensatz in einer CAPA-spezifischen Tabelle oder einem entsprechenden Modul verweist. Beispiele CAPA-2023-088CAPA-2023-091
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp der letzten Datenaktualisierung oder -auffrischung aus dem Quellsystem.
Beschreibung Dieses Attribut gibt an, wann die Daten für dieses Event zuletzt im Process-Mining-Datensatz aktualisiert wurden. Es zeigt die Aktualität der Daten und hilft Benutzern, die zeitliche Aussagekraft der Analyse einzuschätzen. In Dashboards und Berichten ist dieser Timestamp wichtig, um den Kontext für die Benutzer bereitzustellen. Er zeigt, ob Echtzeitdaten oder eine Momentaufnahme zu einem bestimmten Zeitpunkt betrachtet werden. Das ist entscheidend für fundierte operative Entscheidungen und schafft Transparenz über den Aktualitätsstand der Daten. Warum das wichtig ist Dieser Timestamp schafft Transparenz über die Aktualität der Daten und zeigt, wie aktuell die Prozessanalyse ist. Bezugsquelle Dieser Wert wird während des ETL-Prozesses erzeugt und gespeichert. Er entspricht typischerweise dem Timestamp, zu dem die Datenpipeline zuletzt erfolgreich ausgeführt wurde. Beispiele 2023-10-27T04:00:00Z2023-10-26T04:00:00Z
	Nacharbeit IsRework	Ein Kennzeichen dafür, ob eine Aktivität eine Wiederholung oder Nacharbeit eines vorherigen Schritts im selben Case ist.
Beschreibung Dieses boolesche Attribut wird auf wahr gesetzt, wenn eine bestimmte Aktivität, etwa „Korrekturmaßnahmenplan vorgeschlagen“, innerhalb eines einzelnen Qualitätsereignis-Cases mehr als einmal auftritt. Dies weist auf eine Schleife oder Korrektur im Prozess hin, bei der ein bereits abgeschlossener Schritt erneut ausgeführt werden musste. Die Erkennung von Nacharbeit ist eine zentrale Funktion von Process Mining. Dieses Kennzeichen vereinfacht die Quantifizierung solcher Ineffizienzen und unterstützt direkt den KPI „Häufigkeit von Aktivitätsnacharbeit“. Die Analyse, welche Schritte besonders häufig Nacharbeit erfordern und unter welchen Bedingungen dies geschieht, kann Probleme bei Schulungen, der Datenqualität oder den Genehmigungskriterien aufdecken. Daraus ergeben sich Ansatzpunkte für einen effizienteren Prozess. Warum das wichtig ist Es kennzeichnet Ineffizienzen und Schleifen im Prozess, hilft bei der Quantifizierung von Verschwendung und zeigt die Grundursachen von Nacharbeit auf. Bezugsquelle Dieser Wert wird während der Datenaufbereitung mithilfe von Window-Funktionen oder einer sequenziellen Analyse des Event Logs berechnet. Dabei wird ermittelt, wann derselbe Aktivitätsname für denselben Case mehrfach auftritt. Beispiele truefalse
	Problemkategorie IssueCategory	Die Kategorie oder der Typ des Qualitätsproblems, beispielsweise „Product Defect“ oder „Process Deviation“.
Beschreibung Dieses Attribut klassifiziert das Qualitätsereignis und hilft dabei, ähnliche Probleme für die Analyse zu gruppieren. Die Kategorien werden normalerweise vom Unternehmen festgelegt, um den jeweiligen betrieblichen Kontext abzubilden. Die Analyse des Prozesses nach Problemkategorie ermöglicht es, Muster für bestimmte Problemtypen zu erkennen. So kann sich beispielsweise zeigen, dass Probleme mit „Supplier Material“ eine deutlich längere Zykluszeit haben als Probleme mit „Internal Process“. Diese Segmentierung ist für gezielte Initiativen zur Prozessverbesserung wertvoll. Warum das wichtig ist Die Kategorisierung von Problemen ermöglicht eine gezielte Analyse, um Trends und Grundursachen in bestimmten Problembereichen zu erkennen. Bezugsquelle Prüfen Sie die Dokumentation zu Oracle Quality Management. Dabei handelt es sich wahrscheinlich um ein benutzerdefiniertes Element innerhalb des Prüfplans. Beispiele ProduktfehlerProzessabweichungLieferantenmaterialKundenbeschwerde
	Produkt-Identifier ProductIdentifier	Der Identifier des Produkts, das mit dem Qualitätsereignis verbunden ist.
Beschreibung Dieses Attribut verknüpft das Qualitätsereignis mit einem bestimmten Produkt, Material oder einer Dienstleistung. Dabei kann es sich um einen Produktcode, eine SKU oder eine Teilenummer handeln. Diese Verknüpfung ist für die Analyse der Produktqualität entscheidend. Mit Process Mining können Qualitätsmanagementprozesse verschiedener Produktlinien verglichen oder Produkte identifiziert werden, die besonders häufig mit Qualitätsproblemen verbunden sind. So lassen sich Verbesserungsmaßnahmen in Engineering oder Produktion gezielt dort priorisieren, wo sie am dringendsten erforderlich sind. Warum das wichtig ist Damit werden Qualitätsereignisse mit bestimmten Produkten verknüpft. So lassen sich produktbezogene Qualitätstrends und Prozessvarianten analysieren. Bezugsquelle Diese Informationen werden in einem Feld des Prüfplans gespeichert und sind häufig mit dem Artikelstamm von Oracle Inventory verknüpft. Beispiele SKU-100-A-REDPN-987654CHEM-X2
	Quellsystem SourceSystem	Identifiziert das führende System, aus dem die Daten extrahiert wurden.
Beschreibung Dieses Attribut gibt die Ursprungsanwendung oder das Ursprungssystem der Event-Daten an. In einer Unternehmensumgebung können Qualitätsereignisdaten aus mehreren Quellen stammen, beispielsweise aus dem zentralen Oracle-Quality-Modul, einem separaten CAPA-System oder einem Portal für Kundenbeschwerden. Für die Analyse hilft dieses Feld, die Datenherkunft nachzuvollziehen und den Prozess nach Ursprungssystem zu segmentieren. Es ist für Data Governance und die Behebung von Problemen bei der Datenintegration entscheidend, damit die Prozessansicht die kombinierte Datenlandschaft korrekt abbildet. Warum das wichtig ist Das Attribut liefert wichtigen Kontext zur Datenherkunft. Dieser ist für die Datenvalidierung, Data Governance und die Analyse von Prozessvarianten in unterschiedlichen Systemen relevant. Bezugsquelle Dabei handelt es sich typischerweise um einen statischen Wert, der während des ETL-Prozesses zur Kennzeichnung der Herkunft des Datensatzes ergänzt wird. Beispiele Oracle Quality Management R12Oracle EBS QualityQM-PROD
	Termingerecht IsOnTime	Ein Kennzeichen dafür, ob eine Korrekturmaßnahme bis zum vorgesehenen Lösungsdatum umgesetzt wurde.
Beschreibung Dieses boolesche Attribut wird abgeleitet, indem der Abschluss-Timestamp der Aktivität „Korrekturmaßnahme umgesetzt“ mit dem „vorgesehenen Lösungsdatum“ des Cases verglichen wird. Der Wert ist wahr, wenn die Maßnahme am oder vor dem Zieltermin abgeschlossen wurde, andernfalls falsch. Dieses Attribut unterstützt direkt den KPI „CAPA-Umsetzungsquote termingerecht“. Es vereinfacht die Analyse und die Erstellung von Dashboards, da es für die Termintreue jedes Cases eine eindeutige binäre Klassifizierung bereitstellt. Dadurch können Sie einfach filtern und aggregieren, um die Einhaltung von Service Levels zu überwachen und die Grundursachen von Verzögerungen zu ermitteln. Warum das wichtig ist Es vereinfacht die Überwachung der Termintreue im Vergleich zu den Zielvorgaben und erleichtert die Messung und Berichterstattung zu diesem wichtigen KPI. Bezugsquelle Dies ist ein abgeleitetes Kennzeichen, das während der Datentransformation berechnet wird. Dafür werden TargetResolutionDate und der Timestamp der relevanten Abschlussaktivität benötigt. Beispiele truefalse

Erforderlich Empfohlen Optional

Aktivitäten des Qualitätsmanagements

Dies sind die wichtigsten Prozessschritte und wesentlichen Meilensteine, die Sie für eine präzise Prozesserkennung und Leistungsbewertung in Ihrem Event Log erfassen sollten.

6 Empfohlen 8 Optional

	Aktivität	Beschreibung
	Abschließende Prüfung und Schließung	Der letzte Schritt, bei dem der Abschluss aller zugehörigen Maßnahmen bestätigt und das übergeordnete Qualitätsproblem formell geschlossen wird. Dies wird durch eine abschließende Statusänderung des Hauptdatensatzes zu „Closed“ oder „Resolved“ erfasst.
Warum das wichtig ist Dies ist das zentrale End-Event des Prozesses. Es ist entscheidend für die Berechnung des KPI „Average Event Cycle Time“ und für die Messung des gesamten Prozessdurchsatzes. Bezugsquelle Abgeleitet aus der abschließenden Statusänderung des übergeordneten Quality Issue-Datensatzes zu „Closed“. Der Timestamp dieser Änderung dient als Zeitpunkt des Events. Erfassen Abgeleitet aus einer Statusänderung zu „Closed“ beim Hauptdatensatz des Quality Issue. Ereignistyp inferred
	Korrekturmaßnahmenplan genehmigt	Beschreibt die formelle Genehmigung des vorgeschlagenen Korrekturmaßnahmenplans durch eine dafür zuständige Stelle. Dies ist ein wichtiger Kontrollpunkt, der normalerweise durch eine ausdrückliche Genehmigungsaktion oder eine Statusänderung zu „Approved“ erfasst wird.
Warum das wichtig ist Diese Genehmigung ist ein zentraler Meilenstein und häufig ein Engpass. Die Analyse der Genehmigungszeiten hilft, den Prozess zu verbessern und die Einhaltung der Vorgaben sicherzustellen. Bezugsquelle Abgeleitet aus einer Statusänderung des Quality Action- oder CAPA-Datensatzes zu „Approved“. Oracle-Systeme mit Genehmigungs-Workflows protokollieren diese Änderung häufig ausdrücklich in Audit-Tabellen. Erfassen Abgeleitet aus einer Statusänderung zu „Approved“. Ereignistyp inferred
	Problem kategorisiert und priorisiert	Diese Aktivität findet statt, wenn ein Analyst die erste Bewertung abschließt und wichtige Attribute wie Schweregrad, Priorität und Problemtyp festlegt. Sie wird typischerweise erfasst, wenn das Problem vom Status „New“ in den Status „Assessed“ oder „In Triage“ wechselt.
Warum das wichtig ist Dieser Meilenstein ist für den KPI „Avg Triage Processing Time“ entscheidend. Verzögerungen an dieser Stelle können den gesamten Lösungsprozess verlangsamen, insbesondere bei kritischen Problemen. Bezugsquelle Abgeleitet aus einer Statusänderung des Quality Issue-Datensatzes, beispielsweise von „New“ zu „Under Assessment“, oder aus der erstmaligen Befüllung von Feldern wie „Severity“ oder „Priority“. Erfassen Abgeleitet aus einer Statusänderung oder der erstmaligen Befüllung der Felder „Severity“ oder „Priority“. Ereignistyp inferred
	Qualitätsproblem identifiziert	Diese Aktivität kennzeichnet die Erstellung eines neuen Qualitätsereignisdatensatzes, beispielsweise einer Nichtkonformität, einer Abweichung oder einer Kundenbeschwerde. Sie wird ausdrücklich erfasst, wenn ein Benutzer in Oracle einen neuen Quality Issue- oder Quality Action-Datensatz erstellt.
Warum das wichtig ist Als Start-Event ist diese Aktivität entscheidend für die Berechnung der gesamten Zykluszeit des Qualitätsmanagementprozesses und für das Verständnis des Volumens eingehender Qualitätsereignisse. Bezugsquelle Dieses Event wird anhand des Erstellungs-Timestamps des Quality Issue- oder Quality Action-Datensatzes erfasst, der wahrscheinlich in Tabellen wie QAM_QUALITY_ISSUES oder QAM_QUALITY_ACTIONS zu finden ist. Erfassen Event wird bei der Erstellung eines neuen Quality Issue- oder Action-Datensatzes protokolliert. Ereignistyp explicit
	Untersuchung eingeleitet	Kennzeichnet den offiziellen Beginn der Untersuchungsphase zur Ermittlung der Grundursache des Qualitätsproblems. Dies wird normalerweise durch eine Statusänderung im System dargestellt, beispielsweise durch den Wechsel zu „Under Investigation“.
Warum das wichtig ist Dieser Schritt bildet den Ausgangspunkt für die Messung des KPI „Root Cause Analysis Lead Time“ und zeigt, wie lange Probleme warten, bevor eine formelle Untersuchung beginnt. Bezugsquelle Abgeleitet aus einer Statusänderung des Quality Issue- oder eines zugehörigen Quality Action-Datensatzes in den Status „Investigation“. Der Timestamp dieser Statusänderung liefert den Zeitpunkt des Events. Erfassen Abgeleitet aus einer Statusänderung zu „Under Investigation“ oder einem vergleichbaren Status. Ereignistyp inferred
	Wirksamkeit der Maßnahme verifiziert	Bestätigt, dass die umgesetzte Korrekturmaßnahme die Grundursache erfolgreich behoben und ein erneutes Auftreten verhindert hat. Das Event wird erfasst, wenn ein Benutzer die Prüfung abschließt und den Status des Datensatzes aktualisiert.
Warum das wichtig ist Dies ist ein entscheidender ergebnisbezogener Meilenstein und die Grundlage für den KPI „Effectiveness Verif. Rate“. Damit wird der Zyklus der Korrekturmaßnahme abgeschlossen und sichergestellt, dass Probleme tatsächlich gelöst sind. Bezugsquelle Abgeleitet aus einer Statusänderung des CAPA-Datensatzes zu „Verification Complete“ oder „Effective“. Zusätzlich können bestimmte Felder mit den Prüfergebnissen befüllt werden. Erfassen Abgeleitet aus einer Statusänderung zu „Verification Complete“ oder „Effective“. Ereignistyp inferred
	Grundursachenanalyse durchgeführt	Beschreibt den Abschluss der Grundursachenanalyse (RCA) und die Dokumentation der Ergebnisse. Das Event wird typischerweise erfasst, wenn das Untersuchungsteam die ermittelte Grundursache im Qualitätsproblem dokumentiert und dessen Status ändert.
Warum das wichtig ist Diese Aktivität bildet den Endpunkt für den KPI „Root Cause Analysis Lead Time“. Die Analyse der bis zu diesem Schritt verstrichenen Zeit hilft, Engpässe in der Problemlösungsphase zu erkennen. Bezugsquelle Abgeleitet aus einer Statusänderung zu „RCA Complete“ oder aus der Befüllung des Feldes für die Grundursachenkategorie und dem Speichern des Datensatzes. Der Timestamp dieser Aktualisierung wird verwendet. Erfassen Abgeleitet aus einer Statusänderung zu „RCA Complete“ oder der Befüllung von Feldern zur Grundursache. Ereignistyp inferred
	Korrekturmaßnahme umgesetzt	Kennzeichnet den Abschluss der im genehmigten Korrekturmaßnahmenplan festgelegten Aufgaben. Das Event wird typischerweise erfasst, wenn ein Benutzer den Status des Korrekturmaßnahmen-Datensatzes auf „Implemented“ oder „Completed“ setzt.
Warum das wichtig ist Diese Aktivität ist für den KPI „CAPA Impl. On-Time Rate“ entscheidend, da sie zeigt, dass die geplante Maßnahme umgesetzt wurde und einen Vergleich mit den Zielterminen ermöglicht. Bezugsquelle Dieses Event wird aus einer Statusänderung des zugehörigen Quality Action- oder CAPA-Datensatzes zu „Implemented“ oder „Completed“ abgeleitet. Erfassen Abgeleitet aus einer Statusänderung zu „Implemented“ oder „Completed“. Ereignistyp inferred
	Korrekturmaßnahmenplan vorgeschlagen	Dieses Event tritt ein, wenn Korrekturmaßnahmen definiert und mit dem Qualitätsproblem verknüpft werden, um die zur Behebung erforderlichen Schritte festzulegen. Es kann sich um die Erstellung eines zugehörigen Corrective Action-Datensatzes oder um eine Statusänderung handeln, die anzeigt, dass ein Plan zur Prüfung bereitsteht.
Warum das wichtig ist Damit wird der Übergang von der Problemanalyse zur Lösungsplanung erfasst. Nacharbeit an diesem Schritt, gemessen durch Nacharbeits-KPIs, kann auf unklare Anforderungen oder eine unzureichende Planung hinweisen. Bezugsquelle Dies kann ein explizites Event sein, das bei der Erstellung eines neuen Corrective Action-Datensatzes innerhalb eines CAPA-Objekts entsteht, oder ein abgeleitetes Event aus einer Statusänderung zu „Plan Proposed“ oder „Pending Approval“. Erfassen Abgeleitet aus einer Statusänderung zu „Pending Approval“ oder der Erstellung einer verknüpften Corrective Action. Ereignistyp inferred
	Problem zur Triage zugewiesen	Diese Aktivität beschreibt die Zuweisung des neu erstellten Qualitätsproblems an einen bestimmten Benutzer oder ein Team zur ersten Prüfung und Bewertung. Das Event wird häufig abgeleitet, indem Änderungen am Feld für den Bearbeiter oder Verantwortlichen des Qualitätsproblem-Datensatzes verfolgt werden.
Warum das wichtig ist Die Nachverfolgung dieser ersten Übergabe hilft, Verzögerungen vor Beginn der Bewertung zu erkennen. Die Analyse der Verweildauer in diesem Status zeigt mögliche Rückstände in der Triage-Warteschlange. Bezugsquelle Abgeleitet aus Änderungen im Feld für den Verantwortlichen oder Bearbeiter innerhalb des Quality Issue-Datensatzes. Die Daten können aus Audit-Trail-Tabellen stammen oder durch die Nachverfolgung von Statusänderungen im Zusammenhang mit Zuweisungs-Workflows gewonnen werden. Erfassen Abgeleitet aus einer Änderung im Feld „Assigned To“ oder „Owner“ des Quality Issue. Ereignistyp inferred
	Stakeholder über die Lösung informiert	Beschreibt die Mitteilung der Lösung des Qualitätsereignisses an relevante Beteiligte, beispielsweise an den Meldenden oder betroffene Kunden. Dieses Event ist schwer zu erfassen und kann aus einer Statusänderung nach dem Abschluss oder einem protokollierten Kommentar abgeleitet werden.
Warum das wichtig ist Entscheidend für den KPI „Stakeholder Notification Lag“. Eine zeitnahe Information ist auch nach der Behebung eines Problems wichtig für die Kundenzufriedenheit und die interne Transparenz. Bezugsquelle Dieses Event lässt sich häufig nur schwer automatisch erfassen. Es kann aus einem Status wie „Notification Sent“ oder aus einem Eintrag in einem Aktivitäts- oder Kommentarfeld abgeleitet werden und erfordert möglicherweise eine spezielle Extraktionslogik. Erfassen Abgeleitet aus einer bestimmten Statusänderung oder möglicherweise durch Text Mining von Aktivitätsprotokollen. Ereignistyp inferred
	Vorbeugemaßnahme identifiziert	Beschreibt die Erstellung einer Vorbeugemaßnahme (PA), um systemische Probleme zu beheben und ähnliche Qualitätsereignisse künftig zu verhindern. Häufig wird dies als Erstellung eines neuen, mit dem ursprünglichen Problem verknüpften Preventive Action-Datensatzes protokolliert.
Warum das wichtig ist Diese Aktivität zeigt einen ausgereiften Qualitätsprozess, der über die Behebung einzelner Probleme hinausgeht und künftige Probleme verhindert. Ihre Nachverfolgung hilft, proaktive Qualitätsverbesserungen zu messen. Bezugsquelle Erfasst durch die Erstellung eines neuen Quality Action-Datensatzes mit dem Typ „Preventive Action“, der häufig mit dem ursprünglichen Quality Issue oder der Corrective Action verknüpft ist. Erfassen Bei der Erstellung eines Quality Action-Datensatzes vom Typ „Preventive Action“ protokolliert. Ereignistyp explicit
	Vorbeugemaßnahme umgesetzt	Kennzeichnet den Abschluss der im Plan für die Vorbeugemaßnahme festgelegten Aufgaben zur Verringerung systemischer Risiken. Das Event wird erfasst, wenn ein Benutzer den Status des Vorbeugemaßnahmen-Datensatzes auf „Implemented“ oder „Completed“ setzt.
Warum das wichtig ist Misst die Fähigkeit des Unternehmens, proaktive Qualitätsverbesserungen umzusetzen. Verzögerungen an dieser Stelle können darauf hinweisen, dass systemische Veränderungen im gesamten Unternehmen nur schwer umgesetzt werden. Bezugsquelle Abgeleitet aus einer Statusänderung des zugehörigen Preventive Action-Datensatzes zu „Implemented“ oder „Completed“, analog zur Nachverfolgung von Korrekturmaßnahmen. Erfassen Abgeleitet aus einer Statusänderung zu „Implemented“ bei einem Preventive Action-Datensatz. Ereignistyp inferred
	Wirksamkeitsprüfung erforderlich	Beschreibt, dass das System oder ein Benutzer kennzeichnet, dass die umgesetzte Maßnahme nachträglich geprüft werden muss, um ihre Wirksamkeit sicherzustellen. Dies ist häufig eine automatische oder manuelle Statusänderung nach der Umsetzung.
Warum das wichtig ist Dieser Schritt leitet die entscheidende Prüfphase ein. Die Analyse der Zeit zwischen der Umsetzung und dieser Aktivität kann Verzögerungen beim Start notwendiger Nachprüfungen sichtbar machen. Bezugsquelle Dieses Event wird aus einer Statusänderung des Quality Action zu „Pending Effectiveness Check“ oder einem vergleichbaren Status innerhalb des Workflows abgeleitet. Erfassen Abgeleitet aus einer Statusänderung zu „Pending Effectiveness Check“. Ereignistyp inferred

Anleitungen zur Extraktion

So extrahieren Sie Ihre Daten aus Oracle Quality Management

Schritte

Oracle BI Publisher öffnen: Melden Sie sich bei Ihrer Oracle-E-Business-Suite-Instanz an und öffnen Sie die Zuständigkeit, über die Sie auf BI Publisher zugreifen, etwa BI Publisher Administrator oder eine vergleichbare benutzerdefinierte Zuständigkeit.
Neues Datenmodell erstellen: Wählen Sie auf der BI-Publisher-Startseite zunächst „Create“ und anschließend „Data Model“. Dadurch wird der Datenmodell-Editor geöffnet.
Dataset für eine SQL-Abfrage definieren: Klicken Sie im Datenmodell-Editor im Bereich „Data Sets“ auf das Plus-Symbol und wählen Sie „SQL Query“. Das Fenster des SQL-Abfrage-Editors wird geöffnet.
Datenquelle konfigurieren: Geben Sie im Fenster „New Data Set“ einen Namen für das Dataset ein, zum Beispiel DS_QUALITY_EVENTS. Wählen Sie die passende Oracle-EBS-Datenbank als Data Source aus.
SQL-Abfrage eingeben: Kopieren Sie die vollständige SQL-Abfrage aus dem Abschnitt „query“ dieses Dokuments und fügen Sie sie in das Textfeld „SQL Query“ ein.
Abfrageparameter definieren: Die bereitgestellte Abfrage verwendet die Platzhalter :P_START_DATE und :P_END_DATE für den Berichtszeitraum. Im BI-Publisher-Datenmodell müssen Sie diese als Parameter definieren. Erstellen Sie für jeden Parameter einen neuen Eintrag, vergeben Sie den entsprechenden Namen, etwa P_START_DATE, setzen Sie den Data Type auf „Date“ und konfigurieren Sie eine verständliche Eingabeaufforderung.
Datenmodell speichern: Speichern Sie das Datenmodell, nachdem Sie die Abfrage eingefügt und die Parameter definiert haben. Es empfiehlt sich, das Modell in einem freigegebenen Berichtsordner zu speichern.
Neuen Bericht erstellen: Kehren Sie zur BI-Publisher-Startseite zurück und wählen Sie „Create“ und anschließend „Report“. Wählen Sie „Use Data Model“ und suchen Sie das soeben gespeicherte Datenmodell.
Berichtslayout konfigurieren: Der Berichtsassistent führt Sie durch die Konfiguration des Layouts. Für ProcessMind genügt ein einfaches Tabellenlayout. Ziehen Sie alle Spalten aus dem Datenmodell in das Berichtslayout. Stellen Sie sicher, dass das Ausgabeformat auf CSV gesetzt ist.
Berichtseigenschaften festlegen: Prüfen Sie in den Berichtseigenschaften, ob die Option „Enable CSV Output“ aktiviert ist. Bei Bedarf können Sie außerdem Standardwerte für die Parameter festlegen.
Bericht ausführen und exportieren: Speichern Sie den Bericht und führen Sie ihn anschließend mit dem gewünschten Start- und Enddatum aus. Klicken Sie nach Abschluss der Berichtserstellung auf „Export“ und wählen Sie CSV als Ausgabeformat. Die Datei wird auf Ihren lokalen Rechner heruntergeladen.
Upload vorbereiten: Öffnen Sie die heruntergeladene CSV-Datei und prüfen Sie, ob sie die erwarteten Daten enthält. Vergewissern Sie sich, dass die Spaltenüberschriften den Schemaanforderungen von ProcessMind entsprechen. Die Datei kann nun hochgeladen werden.

Konfiguration

Voraussetzungen: Ein Benutzerkonto mit Zugriff auf Oracle BI Publisher sowie Leserechte für die zugrunde liegenden Tabellen des Qualitätsmoduls, etwa QA_RESULTS, QA_PLANS, QA_ACTIONS und FND_USER.
Konfiguration der Datenquelle: Das BI-Publisher-Datenmodell muss für die Verbindung mit Ihrer primären Oracle-EBS-Anwendungsdatenbank, dem APPS-Schema, konfiguriert sein.
Parameter für den Datumsbereich: Die Abfrage verwendet die beiden obligatorischen Parameter :P_START_DATE und :P_END_DATE, um den Datenexport zu filtern. Für eine erste Analyse empfiehlt sich ein Zeitraum von 6 bis 12 Monaten, damit ausreichend vollständige Cases enthalten sind. Verwenden Sie das Datumsformat „YYYY-MM-DD“.
Ausgabeformat: Der Bericht muss für die CSV-Ausgabe konfiguriert sein. Dieses Format eignet sich optimal für die Aufnahme in ProcessMind, da es einfach und strukturiert ist und keine komplexe Verarbeitung erfordert.
Zeitplanung: Planen Sie den BI-Publisher-Bericht für eine kontinuierliche Prozessüberwachung regelmäßig ein, beispielsweise täglich oder wöchentlich. Konfigurieren Sie die Ausgabe so, dass sie an einen festgelegten Server oder ein Content Repository übermittelt und automatisiert abgeholt werden kann.
Leistung: Bei sehr großen Mengen an Qualitätsereignissen kann die Abfrage längere Zeit benötigen. Achten Sie auf einen angemessenen Datumsbereich. Wenn die Leistung problematisch ist, besprechen Sie eine Optimierung der Abfrage oder die Indexierung von Tabellen mit Ihrer Datenbankadministration.

a Beispielabfrage sql

SELECT
    qr.occurrence AS QualityEventId,
    'Quality Issue Identified' AS ActivityName,
    qr.creation_date AS EventStartTime,
    qr.last_update_date AS EventEndTime,
    qp.department_code AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qr.qa_last_update_status AS CurrentStatus,
    qpc_sev.char_value AS SeverityLevel,
    qr.transaction_date AS TargetResolutionDate, -- Or a dedicated target date field
    qpc_rc.char_value AS RootCauseCategory,
    NULL AS ProcessingTime
FROM
    qa_results qr
JOIN
    qa_plans qp ON qr.plan_id = qp.plan_id
LEFT JOIN
    fnd_user fu ON qr.created_by = fu.user_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Severity_Char_ID]) qpc_sev ON qr.result_id = qpc_sev.result_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Root_Cause_Char_ID]) qpc_rc ON qr.result_id = qpc_rc.result_id
WHERE
    qr.creation_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

-- Activities based on status changes are best captured from an audit table if available. 
-- This example uses LAST_UPDATE_DATE which is an approximation.
SELECT
    qr.occurrence AS QualityEventId,
    'Issue Assigned For Triage' AS ActivityName,
    qr.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    qp.department_code AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qr.qa_last_update_status AS CurrentStatus,
    qpc_sev.char_value AS SeverityLevel,
    qr.transaction_date AS TargetResolutionDate,
    qpc_rc.char_value AS RootCauseCategory,
    NULL AS ProcessingTime
FROM
    qa_results qr
JOIN
    qa_plans qp ON qr.plan_id = qp.plan_id
LEFT JOIN
    fnd_user fu ON qr.last_updated_by = fu.user_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Severity_Char_ID]) qpc_sev ON qr.result_id = qpc_sev.result_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Root_Cause_Char_ID]) qpc_rc ON qr.result_id = qpc_rc.result_id
WHERE
    qr.qa_last_update_status IN ('Assigned', 'In Triage') AND qr.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT
    qr.occurrence AS QualityEventId,
    'Issue Categorized and Prioritized' AS ActivityName,
    qr.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    qp.department_code AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qr.qa_last_update_status AS CurrentStatus,
    qpc_sev.char_value AS SeverityLevel,
    qr.transaction_date AS TargetResolutionDate,
    qpc_rc.char_value AS RootCauseCategory,
    NULL AS ProcessingTime
FROM
    qa_results qr
JOIN
    qa_plans qp ON qr.plan_id = qp.plan_id
LEFT JOIN
    fnd_user fu ON qr.last_updated_by = fu.user_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Severity_Char_ID]) qpc_sev ON qr.result_id = qpc_sev.result_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Root_Cause_Char_ID]) qpc_rc ON qr.result_id = qpc_rc.result_id
WHERE
    qr.qa_last_update_status IN ('Assessed', 'Prioritized') AND qr.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT
    qr.occurrence AS QualityEventId,
    'Investigation Initiated' AS ActivityName,
    qr.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    qp.department_code AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qr.qa_last_update_status AS CurrentStatus,
    qpc_sev.char_value AS SeverityLevel,
    qr.transaction_date AS TargetResolutionDate,
    qpc_rc.char_value AS RootCauseCategory,
    NULL AS ProcessingTime
FROM
    qa_results qr
JOIN
    qa_plans qp ON qr.plan_id = qp.plan_id
LEFT JOIN
    fnd_user fu ON qr.last_updated_by = fu.user_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Severity_Char_ID]) qpc_sev ON qr.result_id = qpc_sev.result_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Root_Cause_Char_ID]) qpc_rc ON qr.result_id = qpc_rc.result_id
WHERE
    qr.qa_last_update_status = 'Under Investigation' AND qr.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT
    qr.occurrence AS QualityEventId,
    'Root Cause Analysis Performed' AS ActivityName,
    qr.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    qp.department_code AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qr.qa_last_update_status AS CurrentStatus,
    qpc_sev.char_value AS SeverityLevel,
    qr.transaction_date AS TargetResolutionDate,
    qpc_rc.char_value AS RootCauseCategory,
    NULL AS ProcessingTime
FROM
    qa_results qr
JOIN
    qa_plans qp ON qr.plan_id = qp.plan_id
LEFT JOIN
    fnd_user fu ON qr.last_updated_by = fu.user_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Severity_Char_ID]) qpc_sev ON qr.result_id = qpc_sev.result_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Root_Cause_Char_ID]) qpc_rc ON qr.result_id = qpc_rc.result_id
WHERE
    qpc_rc.char_value IS NOT NULL AND qr.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

-- Corrective and Preventive Actions from a table like QA_ACTIONS
SELECT 
    qa.source_code AS QualityEventId,
    'Corrective Action Plan Proposed' AS ActivityName,
    qa.creation_date AS EventStartTime,
    NULL AS EventEndTime,
    NULL AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qa.status_code AS CurrentStatus,
    NULL AS SeverityLevel,
    qa.target_date AS TargetResolutionDate,
    NULL AS RootCauseCategory,
    NULL AS ProcessingTime
FROM qa_actions qa
LEFT JOIN fnd_user fu ON qa.assignee_id = fu.user_id
WHERE qa.action_code = 'CORRECTIVE_ACTION' AND qa.creation_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT 
    qa.source_code AS QualityEventId,
    'Corrective Action Plan Approved' AS ActivityName,
    qa.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    NULL AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qa.status_code AS CurrentStatus,
    NULL AS SeverityLevel,
    qa.target_date AS TargetResolutionDate,
    NULL AS RootCauseCategory,
    NULL AS ProcessingTime
FROM qa_actions qa
LEFT JOIN fnd_user fu ON qa.last_updated_by = fu.user_id
WHERE qa.action_code = 'CORRECTIVE_ACTION' AND qa.status_code = 'Approved' AND qa.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT 
    qa.source_code AS QualityEventId,
    'Corrective Action Implemented' AS ActivityName,
    qa.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    NULL AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qa.status_code AS CurrentStatus,
    NULL AS SeverityLevel,
    qa.target_date AS TargetResolutionDate,
    NULL AS RootCauseCategory,
    NULL AS ProcessingTime
FROM qa_actions qa
LEFT JOIN fnd_user fu ON qa.last_updated_by = fu.user_id
WHERE qa.action_code = 'CORRECTIVE_ACTION' AND qa.status_code IN ('Implemented', 'Completed') AND qa.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT
    qr.occurrence AS QualityEventId,
    'Effectiveness Check Required' AS ActivityName,
    qr.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    qp.department_code AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qr.qa_last_update_status AS CurrentStatus,
    qpc_sev.char_value AS SeverityLevel,
    qr.transaction_date AS TargetResolutionDate,
    qpc_rc.char_value AS RootCauseCategory,
    NULL AS ProcessingTime
FROM
    qa_results qr
JOIN
    qa_plans qp ON qr.plan_id = qp.plan_id
LEFT JOIN
    fnd_user fu ON qr.last_updated_by = fu.user_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Severity_Char_ID]) qpc_sev ON qr.result_id = qpc_sev.result_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Root_Cause_Char_ID]) qpc_rc ON qr.result_id = qpc_rc.result_id
WHERE
    qr.qa_last_update_status = 'Verification Pending' AND qr.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT
    qr.occurrence AS QualityEventId,
    'Effectiveness of Action Verified' AS ActivityName,
    qr.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    qp.department_code AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qr.qa_last_update_status AS CurrentStatus,
    qpc_sev.char_value AS SeverityLevel,
    qr.transaction_date AS TargetResolutionDate,
    qpc_rc.char_value AS RootCauseCategory,
    NULL AS ProcessingTime
FROM
    qa_results qr
JOIN
    qa_plans qp ON qr.plan_id = qp.plan_id
LEFT JOIN
    fnd_user fu ON qr.last_updated_by = fu.user_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Severity_Char_ID]) qpc_sev ON qr.result_id = qpc_sev.result_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Root_Cause_Char_ID]) qpc_rc ON qr.result_id = qpc_rc.result_id
WHERE
    qr.qa_last_update_status = 'Verification Complete' AND qr.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT 
    qa.source_code AS QualityEventId,
    'Preventive Action Identified' AS ActivityName,
    qa.creation_date AS EventStartTime,
    NULL AS EventEndTime,
    NULL AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qa.status_code AS CurrentStatus,
    NULL AS SeverityLevel,
    qa.target_date AS TargetResolutionDate,
    NULL AS RootCauseCategory,
    NULL AS ProcessingTime
FROM qa_actions qa
LEFT JOIN fnd_user fu ON qa.assignee_id = fu.user_id
WHERE qa.action_code = 'PREVENTIVE_ACTION' AND qa.creation_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT 
    qa.source_code AS QualityEventId,
    'Preventive Action Implemented' AS ActivityName,
    qa.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    NULL AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qa.status_code AS CurrentStatus,
    NULL AS SeverityLevel,
    qa.target_date AS TargetResolutionDate,
    NULL AS RootCauseCategory,
    NULL AS ProcessingTime
FROM qa_actions qa
LEFT JOIN fnd_user fu ON qa.last_updated_by = fu.user_id
WHERE qa.action_code = 'PREVENTIVE_ACTION' AND qa.status_code IN ('Implemented', 'Completed') AND qa.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT
    qr.occurrence AS QualityEventId,
    'Final Review and Closure' AS ActivityName,
    qr.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    qp.department_code AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qr.qa_last_update_status AS CurrentStatus,
    qpc_sev.char_value AS SeverityLevel,
    qr.transaction_date AS TargetResolutionDate,
    qpc_rc.char_value AS RootCauseCategory,
    NULL AS ProcessingTime
FROM
    qa_results qr
JOIN
    qa_plans qp ON qr.plan_id = qp.plan_id
LEFT JOIN
    fnd_user fu ON qr.last_updated_by = fu.user_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Severity_Char_ID]) qpc_sev ON qr.result_id = qpc_sev.result_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Root_Cause_Char_ID]) qpc_rc ON qr.result_id = qpc_rc.result_id
WHERE
    qr.qa_last_update_status IN ('Closed', 'Resolved') AND qr.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

UNION ALL

SELECT
    qr.occurrence AS QualityEventId,
    'Stakeholders Notified of Resolution' AS ActivityName,
    qr.last_update_date AS EventStartTime,
    NULL AS EventEndTime,
    qp.department_code AS ResponsibleDepartment,
    fu.user_name AS AssignedUser,
    qr.qa_last_update_status AS CurrentStatus,
    qpc_sev.char_value AS SeverityLevel,
    qr.transaction_date AS TargetResolutionDate,
    qpc_rc.char_value AS RootCauseCategory,
    NULL AS ProcessingTime
FROM
    qa_results qr
JOIN
    qa_plans qp ON qr.plan_id = qp.plan_id
LEFT JOIN
    fnd_user fu ON qr.last_updated_by = fu.user_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Severity_Char_ID]) qpc_sev ON qr.result_id = qpc_sev.result_id
LEFT JOIN
    (SELECT result_id, character_value AS char_value FROM qa_results_chars WHERE char_id = [Your_Root_Cause_Char_ID]) qpc_rc ON qr.result_id = qpc_rc.result_id
WHERE
    qr.qa_last_update_status = 'Notification Sent' AND qr.last_update_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')

Schritte

Voraussetzungen: Stellen Sie sicher, dass Sie über einen Datenbank-Client wie SQL Developer oder DBeaver sowie über schreibgeschützte Zugangsdaten für die Oracle-Datenbank verfügen, in der das Modul Quality Management betrieben wird.
Schema verstehen: Machen Sie sich mit den wichtigsten Oracle-Quality-Tabellen vertraut. Die Abfrage verwendet hauptsächlich QA_RESULTS für die Kopfdaten der Qualitätsereignisse, QA_PLANS für die Plandefinitionen, QA_RESULTS_V für eine kombinierte Ansicht der Ergebnisse und ihrer Werte sowie Anwendungstabellen für Benutzer wie FND_USER oder PER_ALL_PEOPLE_F.
Abfrageparameter festlegen: Suchen Sie vor der Ausführung der Abfrage die Platzhaltervariablen in der WHERE-Klausel. Ersetzen Sie :start_date, :end_date und :organization_id durch die passenden Werte für Ihren Extraktionsumfang. Setzen Sie :start_date beispielsweise auf „2023-01-01“ und :end_date auf „2023-06-30“.
SQL-Abfrage ausführen: Kopieren Sie das vollständige SQL-Skript und führen Sie es in Ihrem Datenbank-Client aus. Das Skript verwendet mehrere UNION ALL-Klauseln, um verschiedene Ereignisse in einem einheitlichen Event-Log-Format zusammenzuführen.
Rohdaten prüfen: Prüfen Sie nach der Ausführung die Ausgabe. Jede Zeile stellt eine einzelne Aktivität im Lebenszyklus eines Qualitätsereignisses dar. Kontrollieren Sie die Vollständigkeit und das Vorhandensein von Daten in wichtigen Spalten wie QualityEventId, ActivityName und EventStartTime.
Timestamps und Dauer verarbeiten: Die Abfrage liefert EventStartTime. EventEndTime bleibt absichtlich NULL, da die Ermittlung der Endzeit eines Ereignisses häufig den Startzeitpunkt des nächsten Ereignisses erfordert. Diese Berechnung erfolgt in der Regel am besten im Process-Mining-Tool oder in einem Skript zur Nachbearbeitung. Auch ProcessingTime wird auf NULL gesetzt, da für die Berechnung Start- und Endzeit benötigt werden.
Als CSV exportieren: Exportieren Sie die vollständige Ergebnismenge aus Ihrem SQL-Client in eine CSV-Datei. Stellen Sie sicher, dass die Datei UTF-8 verwendet und eine Kopfzeile mit den Spaltenaliasen aus der Abfrage enthält.
Upload vorbereiten: Prüfen Sie, ob die CSV-Spaltenüberschriften den Anforderungen der ProcessMind-Plattform entsprechen (Case-ID, Aktivität, Start-Timestamp). Benennen Sie die Spalten QualityEventId, ActivityName und EventStartTime vor dem Upload entsprechend um.

Konfiguration

Datenbankzugriff: Der Benutzer, der die Abfrage ausführt, benötigt SELECT-Berechtigungen für alle im Skript referenzierten Tabellen. Dazu können Tabellen in den Schemas APPS, QA, PER und Personalwesen gehören.
Wichtige Abfragefilter: Die Abfrage enthält wichtige Platzhalter, die konfiguriert werden müssen:
- :start_date: Beginn des Berichtszeitraums. Die Abfrage filtert nach Ereignissen, die an diesem Datum oder danach erstellt wurden.
- :end_date: Ende des Berichtszeitraums.
- :organization_id: Die spezifische Oracle-Organisations-ID, die Sie analysieren möchten. Qualitätspläne und Ergebnisse sind häufig einer Organisation zugeordnet.
Datumsbereich: Für eine erste Analyse empfiehlt sich ein Zeitraum von drei bis sechs Monaten. Beginnen Sie bei großen Systemen mit hohem Datenvolumen mit einem kürzeren Zeitraum, etwa einem Monat, um die Abfrageleistung zu prüfen, bevor Sie eine größere Extraktion ausführen.
Überlegungen zur Leistung: Diese Abfrage verknüpft mehrere große Tabellen und führt 14 separate Ergebnismengen zusammen. Sie kann erhebliche Ressourcen beanspruchen. Planen Sie die Extraktion für Zeiten mit geringer Auslastung, um die Auswirkungen auf die Systemleistung zu begrenzen. Wenn die Leistung nicht ausreicht, wenden Sie sich an einen Datenbankadministrator und prüfen Sie die Indizierung wichtiger Spalten, insbesondere von Datums- und Fremdschlüsselspalten.

a Beispielabfrage sql

WITH QualityEventBase AS (
    SELECT
        qr.COLLECTION_ID,
        qr.PLAN_ID,
        qp.NAME AS PLAN_NAME,
        qr.ORGANIZATION_ID,
        qr.CREATION_DATE,
        qr.LAST_UPDATE_DATE,
        qr.CREATED_BY,
        qr.LAST_UPDATED_BY,
        (SELECT qrv.CHARACTER1 FROM QA_RESULTS_V qrv WHERE qrv.COLLECTION_ID = qr.COLLECTION_ID AND qrv.ELEMENT_SHORT_CODE = 'Q_STATUS') AS CurrentStatus,
        (SELECT qrv.CHARACTER1 FROM QA_RESULTS_V qrv WHERE qrv.COLLECTION_ID = qr.COLLECTION_ID AND qrv.ELEMENT_SHORT_CODE = 'Q_SEVERITY') AS SeverityLevel,
        (SELECT qrv.CHARACTER1 FROM QA_RESULTS_V qrv WHERE qrv.COLLECTION_ID = qr.COLLECTION_ID AND qrv.ELEMENT_SHORT_CODE = 'Q_ROOT_CAUSE') AS RootCauseCategory,
        (SELECT qrv.CHARACTER1 FROM QA_RESULTS_V qrv WHERE qrv.COLLECTION_ID = qr.COLLECTION_ID AND qrv.ELEMENT_SHORT_CODE = 'Q_DEPT') AS ResponsibleDepartment,
        (SELECT qrv.DATE1 FROM QA_RESULTS_V qrv WHERE qrv.COLLECTION_ID = qr.COLLECTION_ID AND qrv.ELEMENT_SHORT_CODE = 'Q_TARGET_DATE') AS TargetResolutionDate,
        (SELECT fu.USER_NAME FROM FND_USER fu WHERE fu.USER_ID = qr.LAST_UPDATED_BY) AS AssignedUser
    FROM
        QA_RESULTS qr
    JOIN
        QA_PLANS qp ON qr.PLAN_ID = qp.PLAN_ID
    WHERE
        qr.CREATION_DATE BETWEEN TO_DATE(:start_date, 'YYYY-MM-DD') AND TO_DATE(:end_date, 'YYYY-MM-DD')
        AND qr.ORGANIZATION_ID = :organization_id
)
-- 1. Quality Issue Identified
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Quality Issue Identified' AS ActivityName,
    qeb.CREATION_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb

UNION ALL

-- 2. Issue Assigned For Triage (Approximation: first update after creation)
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Issue Assigned For Triage' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'TRIAGE' AND qeb.LAST_UPDATE_DATE > qeb.CREATION_DATE

UNION ALL

-- 3. Issue Categorized and Prioritized
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Issue Categorized and Prioritized' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'ASSESSED' AND qeb.SeverityLevel IS NOT NULL

UNION ALL

-- 4. Investigation Initiated
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Investigation Initiated' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'UNDER_INVESTIGATION'

UNION ALL

-- 5. Root Cause Analysis Performed
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Root Cause Analysis Performed' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'RCA_COMPLETE' AND qeb.RootCauseCategory IS NOT NULL

UNION ALL

-- 6. Corrective Action Plan Proposed
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Corrective Action Plan Proposed' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'CAPA_PROPOSED'

UNION ALL

-- 7. Corrective Action Plan Approved
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Corrective Action Plan Approved' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'CAPA_APPROVED'

UNION ALL

-- 8. Corrective Action Implemented
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Corrective Action Implemented' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'CAPA_IMPLEMENTED'

UNION ALL

-- 9. Effectiveness Check Required
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Effectiveness Check Required' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'EFFECTIVENESS_CHECK'

UNION ALL

-- 10. Effectiveness of Action Verified
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Effectiveness of Action Verified' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'VERIFIED'

UNION ALL

-- 11. Preventive Action Identified
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Preventive Action Identified' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'PAPA_DEFINED'

UNION ALL

-- 12. Preventive Action Implemented
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Preventive Action Implemented' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'PAPA_IMPLEMENTED'

UNION ALL

-- 13. Final Review and Closure
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Final Review and Closure' AS ActivityName,
    qeb.LAST_UPDATE_DATE AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'CLOSED'

UNION ALL

-- 14. Stakeholders Notified of Resolution (Approximation)
SELECT
    qeb.COLLECTION_ID AS QualityEventId,
    'Stakeholders Notified of Resolution' AS ActivityName,
    qeb.LAST_UPDATE_DATE + interval '1' minute AS EventStartTime,
    NULL AS EventEndTime,
    qeb.ResponsibleDepartment,
    qeb.AssignedUser,
    qeb.CurrentStatus,
    qeb.SeverityLevel,
    qeb.TargetResolutionDate,
    qeb.RootCauseCategory,
    NULL AS ProcessingTime
FROM QualityEventBase qeb
WHERE qeb.CurrentStatus = 'CLOSED'

Schritte

Umgebung vorbereiten: Stellen Sie sicher, dass Python 3.6 oder höher auf Ihrem System installiert ist. Installieren Sie die erforderlichen Bibliotheken mit pip: pip install pandas oracledb. Diese Bibliotheken werden für die Verbindung zur Oracle-Datenbank und die Datenverarbeitung benötigt.
Datenbankzugangsdaten beschaffen: Besorgen Sie die erforderlichen Verbindungsdaten für Ihre Oracle-Quality-Management-Datenbank. Dazu gehören Benutzername, Passwort und der Data Source Name (DSN), der üblicherweise dem Format hostname:port/service_name folgt.
Extraktionsskript speichern: Kopieren Sie das vollständige Python-Skript aus dem Abschnitt „query“ und speichern Sie es als Datei, zum Beispiel extract_quality_events.py.
Skript konfigurieren: Öffnen Sie das gespeicherte Skript in einem Texteditor. Ersetzen Sie im Konfigurationsbereich am Anfang die Platzhalterwerte für db_user, db_password, db_dsn, start_date und end_date durch Ihre konkreten Angaben.
SQL-Platzhalter anpassen: Prüfen Sie die SQL-Abfrage im Skript. Möglicherweise müssen Sie Tabellennamen wie QA_RESULTS oder bestimmte Statuswerte wie „NEW“ und „CLOSED“ an Ihre Oracle-Konfiguration anpassen. Wenden Sie sich an Ihre Oracle-Systemadministration, wenn Sie bei diesen Werten unsicher sind.
Skript ausführen: Öffnen Sie eine Eingabeaufforderung oder ein Terminal, wechseln Sie in das Verzeichnis, in dem Sie das Skript gespeichert haben, und führen Sie es mit dem Befehl python extract_quality_events.py aus.
Ausführung überwachen: Das Skript verbindet sich mit der Datenbank, führt die Abfrage aus und verarbeitet die Daten. Je nach Datumsbereich und Datenvolumen kann dies mehrere Minuten dauern. Achten Sie auf die Meldung „Successfully connected to Oracle Database!“ und abschließend auf „Event log saved to quality_event_log.csv“.
Ausgabedatei abrufen: Nach Abschluss des Skripts wird im selben Verzeichnis eine Datei namens quality_event_log.csv erstellt. Diese Datei enthält das extrahierte Event Log.
Event Log prüfen: Öffnen Sie die Datei quality_event_log.csv in einer Tabellenkalkulation, um eine erste Prüfung durchzuführen. Kontrollieren Sie die erwarteten Spalten und prüfen Sie anhand einiger Beispiel-Cases, ob die Daten korrekt befüllt sind.
In das Process-Mining-Tool hochladen: Die erzeugte CSV-Datei kann nun zur Analyse in Ihre Process-Mining-Anwendung hochgeladen werden.

Konfiguration

Datenbankverbindung: Das Skript benötigt einen Oracle Data Source Name (DSN), einen Benutzernamen und ein Passwort mit Lesezugriff auf die erforderlichen Tabellen des Qualitätsmanagements, etwa QA_RESULTS, QA_PLANS, FND_USER und PER_ALL_PEOPLE_F.
Filterung nach Datumsbereich: Die Variablen start_date und end_date im Skript steuern das Datenvolumen maßgeblich. Beginnen Sie mit einem kürzeren Zeitraum von beispielsweise 3 bis 6 Monaten, um die Leistung zu prüfen und die Ausgabe zu validieren, bevor Sie einen größeren Export starten.
Systemspezifische Filter: Sie können die SQL-Abfrage an Ihre Organisationsstruktur anpassen. Fügen Sie beispielsweise eine WHERE-Klausel für ORGANIZATION_ID hinzu, um den Export auf ein bestimmtes Werk oder eine Geschäftseinheit zu begrenzen.
Zuordnung von Statuscodes: Die Logik zur Aktivitätsextraktion ordnet bestimmte Statuswerte, etwa „NEW“, „UNDER_INVESTIGATION“ und „CLOSED“, Prozessschritten zu. Diese Werte hängen stark von Ihrer Oracle-Konfiguration ab und müssen in der SQL-Abfrage geprüft und gegebenenfalls angepasst werden.
Python-Abhängigkeiten: Das Skript benötigt die Bibliotheken pandas und oracledb. Stellen Sie sicher, dass diese in der Python-Umgebung installiert sind, in der das Skript ausgeführt wird.

a Beispielabfrage python

import pandas as pd
import oracledb
import sys

class=class="hl-string">"hl-comment"># --- Configuration Settings --- 
class=class="hl-string">"hl-comment"># Replace with your Oracle database credentials and connection details
db_user = class="hl-string">"your_username"
db_password = class="hl-string">"your_password"
class=class="hl-string">"hl-comment"># DSN (Data Source Name) format: hostname:port/service_name
db_dsn = class="hl-string">"your_host:1521/your_service_name"

class=class="hl-string">"hl-comment"># Define the date range for the extraction
start_date = class="hl-string">"2023-01-01"
end_date = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># --- SQL Query --- 
class=class="hl-string">"hl-comment"># This query extracts events from the Oracle Quality Management module.
class=class="hl-string">"hl-comment"># Each SELECT statement with a UNION ALL corresponds to a specific activity.
sql_query = fclass="hl-string">"""
WITH base_events AS (
    SELECT 
        qr.COLLECTION_ID AS QualityEventId,
        qr.LAST_UPDATE_DATE,
        qr.CREATION_DATE,
        qpc.PROMPT AS StatusPrompt,
        qr.CHARACTER1 AS CurrentStatus,
        qr.CHARACTER2 AS SeverityLevel,
        qr.CHARACTER3 AS RootCauseCategory,
        oap.NAME AS ResponsibleDepartment,
        fu.USER_NAME AS AssignedUser,
        qr.DATE1 AS TargetResolutionDate,
        (qr.LAST_UPDATE_DATE - qr.CREATION_DATE) * 24 * 60 AS ProcessingTime
    FROM 
        QA_RESULTS qr
    JOIN 
        QA_PLANS qp ON qr.PLAN_ID = qp.PLAN_ID
    JOIN 
        QA_PLAN_CHARS qpc ON qp.PLAN_ID = qpc.PLAN_ID AND qpc.PROMPT = 'Status'
    LEFT JOIN 
        FND_USER fu ON qr.LAST_UPDATED_BY = fu.USER_ID
    LEFT JOIN
        HR_ALL_ORGANIZATION_UNITS oap ON qr.ORGANIZATION_ID = oap.ORGANIZATION_ID
    WHERE 
        qr.CREATION_DATE BETWEEN TO_DATE('{start_date}', 'YYYY-MM-DD') AND TO_DATE('{end_date}', 'YYYY-MM-DD')
)
-- 1. Quality Issue Identified
SELECT
    be.QualityEventId,
    'Quality Issue Identified' AS ActivityName,
    be.CREATION_DATE AS EventStartTime,
    be.CREATION_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    'New' AS CurrentStatus, -- Initial status
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be

UNION ALL

-- 2. Issue Assigned For Triage (approximated by first update after creation)
SELECT
    be.QualityEventId,
    'Issue Assigned For Triage' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.LAST_UPDATE_DATE > be.CREATION_DATE AND be.CurrentStatus IN ('Assigned', '[Your Triage Status]')

UNION ALL

-- 3. Issue Categorized and Prioritized
SELECT
    be.QualityEventId,
    'Issue Categorized and Prioritized' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus IN ('Assessed', 'Prioritized', '[Your Categorized Status]')

UNION ALL

-- 4. Investigation Initiated
SELECT
    be.QualityEventId,
    'Investigation Initiated' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus IN ('Under Investigation', 'Investigation')

UNION ALL

-- 5. Root Cause Analysis Performed
SELECT
    be.QualityEventId,
    'Root Cause Analysis Performed' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus = 'RCA Complete' AND be.RootCauseCategory IS NOT NULL

UNION ALL

-- 6. Corrective Action Plan Proposed
SELECT
    be.QualityEventId,
    'Corrective Action Plan Proposed' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus = 'CAP Proposed'

UNION ALL

-- 7. Corrective Action Plan Approved
SELECT
    be.QualityEventId,
    'Corrective Action Plan Approved' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus = 'CAP Approved'

UNION ALL

-- 8. Corrective Action Implemented
SELECT
    be.QualityEventId,
    'Corrective Action Implemented' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus = 'CAP Implemented'

UNION ALL

-- 9. Effectiveness Check Required
SELECT
    be.QualityEventId,
    'Effectiveness Check Required' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus = 'Verification Pending'

UNION ALL

-- 10. Effectiveness of Action Verified
SELECT
    be.QualityEventId,
    'Effectiveness of Action Verified' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus = 'Verified Effective'

UNION ALL

-- 11. Preventive Action Identified
SELECT
    be.QualityEventId,
    'Preventive Action Identified' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus = 'PA Identified'

UNION ALL

-- 12. Preventive Action Implemented
SELECT
    be.QualityEventId,
    'Preventive Action Implemented' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus = 'PA Implemented'

UNION ALL

-- 13. Final Review and Closure
SELECT
    be.QualityEventId,
    'Final Review and Closure' AS ActivityName,
    be.LAST_UPDATE_DATE AS EventStartTime,
    be.LAST_UPDATE_DATE AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus = 'Closed'

UNION ALL

-- 14. Stakeholders Notified of Resolution
SELECT
    be.QualityEventId,
    'Stakeholders Notified of Resolution' AS ActivityName,
    be.LAST_UPDATE_DATE + interval '1' day AS EventStartTime, -- Approximated as 1 day after closure
    be.LAST_UPDATE_DATE + interval '1' day AS EventEndTime,
    be.ResponsibleDepartment,
    be.AssignedUser,
    be.CurrentStatus,
    be.SeverityLevel,
    be.TargetResolutionDate,
    be.RootCauseCategory,
    be.ProcessingTime
FROM base_events be
WHERE be.CurrentStatus = 'Closed'
"""

class=class="hl-string">"hl-comment"># --- Main Execution Logic ---
try:
    class=class="hl-string">"hl-comment"># Establish the database connection
    with oracledb.connect(user=db_user, password=db_password, dsn=db_dsn) as connection:
        print(class="hl-string">"Successfully connected to Oracle Database!")
        
        class=class="hl-string">"hl-comment"># Execute the query and load data into a pandas DataFrame
        print(class="hl-string">"Executing query... This may take a few minutes.")
        df = pd.read_sql_query(sql_query, connection)
        print(fclass="hl-string">"Query finished. {len(df)} events extracted.")

        class=class="hl-string">"hl-comment"># Data Type Conversion
        df[class="hl-string">'EVENTSTARTTIME'] = pd.to_datetime(df[class="hl-string">'EVENTSTARTTIME'])
        df[class="hl-string">'EVENTENDTIME'] = pd.to_datetime(df[class="hl-string">'EVENTENDTIME'])
        df[class="hl-string">'TARGETRESOLUTIONDATE'] = pd.to_datetime(df[class="hl-string">'TARGETRESOLUTIONDATE'])

        class=class="hl-string">"hl-comment"># Sort the data for chronological order
        df = df.sort_values(by=[class="hl-string">'QUALITYEVENTID', class="hl-string">'EVENTSTARTTIME'], ascending=[True, True])

        class=class="hl-string">"hl-comment"># Save the DataFrame to a CSV file
        output_filename = class="hl-string">'quality_event_log.csv'
        df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%d %H:%M:%S')
        print(fclass="hl-string">"Event log saved to {output_filename}")

except oracledb.DatabaseError as e:
    error, = e.args
    print(fclass="hl-string">"Database connection or query failed: {error.message}", file=sys.stderr)
    sys.exit(1)
except Exception as e:
    print(fclass="hl-string">"An unexpected error occurred: {e}", file=sys.stderr)
    sys.exit(1)

Möchten Sie jetzt starten?

Dieses Template unterstützt Sie dabei, Ihre Daten schnell vorzubereiten und mit der Optimierung Ihrer Qualitätsmanagementprozesse zu beginnen. Entdecken Sie noch heute Möglichkeiten für mehr Effizienz und Compliance.

Zurück zum Leitfaden zur Verbesserung Template herunterladen

Transformieren Sie Oracle Quality Management und verbessern Sie jetzt Ihre Compliance

Beseitigen Sie Ineffizienzen und verkürzen Sie die Durchlaufzeiten um 30 %.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. Kostenlose 14-tägige Testphase.

Ihr Daten-Template für das Qualitätsmanagement

Ihr Daten-Template für das Qualitätsmanagement

Attribute des Qualitätsmanagements

Aktivitäten des Qualitätsmanagements

Anleitungen zur Extraktion

Oracle-BI-Publisher-Bericht für Daten zu Qualitätsereignissen

Schritte

Konfiguration

a Beispielabfrage sql

Direkte SQL-Abfrage für Oracle-Quality-Management-Tabellen

Schritte

Konfiguration

a Beispielabfrage sql

Python-Extraktionsskript über den Oracle-Datenbank-Connector

Schritte

Konfiguration

a Beispielabfrage python

Möchten Sie jetzt starten?

Transformieren Sie Oracle Quality Management und verbessern Sie jetzt Ihre Compliance

Ihr Daten-Template für das Qualitätsmanagement

Ihr Daten-Template für das Qualitätsmanagement

Attribute des Qualitätsmanagements

Aktivitäten des Qualitätsmanagements

Anleitungen zur Extraktion

Oracle-BI-Publisher-Bericht für Daten zu Qualitätsereignissen

Schritte

Konfiguration

a Beispielabfrage sql

Direkte SQL-Abfrage für Oracle-Quality-Management-Tabellen

Schritte

Konfiguration

a Beispielabfrage sql

Python-Extraktionsskript über den Oracle-Datenbank-Connector

Schritte

Konfiguration

a Beispielabfrage python

Möchten Sie jetzt starten?

Transformieren Sie Oracle Quality Management und verbessern Sie jetzt Ihre Compliance

Ihre Privatsphäre ist uns wichtig