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

Ihr Daten-Template für das Qualitätsmanagement

Oracle-Qualitätsmanagement

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute des Qualitätsmanagements(20) Aktivitäten im Qualitätsmanagement(14) Anleitungen zur Datenextraktion(3)

Ihr Daten-Template für das Qualitätsmanagement

Dieses Template bietet einen umfassenden Leitfaden zu den wesentlichen Datenattributen und Prozessaktivitäten, die Sie für eine aussagekräftige Analyse des Qualitätsmanagements benötigen. Außerdem erfahren Sie, wie Sie diese wichtigen Informationen aus Ihrem Oracle-Qualitätsmanagementsystem extrahieren. So stellen Sie sicher, dass alle erforderlichen Daten für detaillierte Erkenntnisse und die Prozessoptimierung erfasst werden.

Empfohlene Attribute für die Erfassung
Wichtige Aktivitäten für die Nachverfolgung
Anleitung zur Datenextraktion

Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Template herunterladen

Attribute des Qualitätsmanagements

Diese Datenfelder und Kontextinformationen sollten Sie in Ihr Event Log aufnehmen, um das Qualitätsmanagement umfassend analysieren und aussagekräftige Erkenntnisse gewinnen zu können.

3 Erforderlich 7 Empfohlen 10 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Der Name der konkreten Aufgabe oder des Schritts im Qualitätsmanagementprozess.
Beschreibung Dieses Attribut beschreibt ein einzelnes Ereignis oder eine Handlung im Rahmen der Bearbeitung eines Qualitätsereignisses. Die nach Timestamp geordnete Abfolge dieser Aktivitäten bildet den Prozessablauf für jeden Fall. Die Analyse des Aktivitätsnamens ist zentral für Process Mining. Sie ermöglicht es, das tatsächliche Prozessmodell zu ermitteln, es im Rahmen einer Konformitätsprüfung mit einem Sollmodell zu vergleichen und Engpässe oder Nacharbeitsschleifen zwischen bestimmten Aktivitäten zu erkennen. So lässt sich beispielsweise die Zeit zwischen 'Untersuchung eingeleitet' und 'Ursachenanalyse durchgeführt' messen. Warum das wichtig ist Dieses Attribut ist grundlegend, um den Prozessablauf abzubilden, Abweichungen zu erkennen und zu verstehen, wie die Arbeit tatsächlich ausgeführt wird. Woher beziehen Diese Informationen stammen üblicherweise aus Event Logs, Statusänderungsdatensätzen oder Aktionstabellen im Oracle-Quality-Management-Modul. Beispiele Qualitätsproblem erkanntUntersuchung eingeleitetKorrekturmaßnahmenplan freigegebenAbschließende Prüfung und Schließung
	Qualitätsereignis QualityEventId	Die eindeutige Kennung eines einzelnen Qualitätsereignisses, etwa einer Nichtkonformität, Beschwerde oder Abweichung.
Beschreibung Die Qualitätsereignis-ID dient als primäre Fall-ID und fasst alle zugehörigen Aktivitäten von der ersten Meldung bis zum endgültigen Abschluss zusammen. Jeder Qualitätsvorfall erhält eine eindeutige ID. So entsteht eine vollständige Historie der Untersuchung und Lösung. Bei der Process-Mining-Analyse ist dieses Attribut grundlegend, um den gesamten Verlauf jedes Qualitätsereignisses zu rekonstruieren. Es ermöglicht die Berechnung der Gesamtdurchlaufzeiten, die Ermittlung von Prozessvarianten und die Analyse, wie unterschiedliche Ereignistypen bearbeitet werden. Wenn jedes Aktivitätsprotokoll mit einer bestimmten Qualitätsereignis-ID verknüpft ist, können Analysten den vollständigen Prozessablauf visualisieren und systemische Engpässe oder Compliance-Probleme erkennen. Warum das wichtig ist Diese ID legt den Umfang eines einzelnen Falls fest. Sie ermöglicht die genaue Nachverfolgung von Qualitätsereignissen und die Berechnung von Leistungskennzahlen für den gesamten Prozess. Woher beziehen In Oracle Quality Management ist dies üblicherweise der Primärschlüssel in den Haupttabellen für Qualitätsereignisse oder Prüfpläne, etwa QA_RESULTS. Beispiele NC-2023-00123CAPA-45892QE-500-A
	Startzeit des Ereignisses EventStartTime	Der Timestamp, der angibt, wann eine Aktivität oder ein Ereignis begonnen hat.
Beschreibung Dieses Attribut gibt Datum und Uhrzeit an, zu denen ein bestimmter Prozessschritt begonnen hat. Es ist das zentrale Zeitmerkmal, um Ereignisse chronologisch zu ordnen und die Prozessabfolge für jeden Qualitätsereignisfall zu erstellen. Bei der Analyse ist die Startzeit des Ereignisses entscheidend für die Berechnung von Durchlauf-, Bearbeitungs- und Wartezeiten zwischen Aktivitäten. Sie hilft, Engpässe anhand langer Verzögerungen zwischen aufeinanderfolgenden Schritten zu erkennen. Außerdem dient sie dazu, die Leistung anhand zeitbezogener KPIs wie der Durchlaufzeit der Ursachenanalyse zu verfolgen. Warum das wichtig ist Dieser Timestamp bildet die Grundlage der Prozessanalyse. Er ermöglicht alle zeitbezogenen Berechnungen und die korrekte Reihenfolge der Aktivitäten. Woher beziehen Dieser Timestamp findet sich üblicherweise in Transaktionsprotokollen oder Historientabellen zu Qualitätsmaßnahmen und Prüfplänen. Das Feld heißt häufig CREATION_DATE oder ähnlich. Beispiele 2023-04-15T09:00:12Z2023-04-16T11:30:00Z2023-05-01T14:22:45Z
	Aktueller Status CurrentStatus	Der aktuelle Status des Falls zum Qualitätsereignis.
Beschreibung Dieses Attribut gibt den aktuellen Stand des Qualitätsereignisses im Prozess an, etwa 'Open', 'Under Investigation', 'Pending Approval' oder 'Closed'. Es zeigt, an welcher Stelle sich der Fall zum Zeitpunkt der Datenextraktion befindet. Dieses wichtige Attribut unterstützt die operative Überwachung und das Dashboard 'Offene Qualitätsereignisse und Statusübersicht'. Führungskräfte können damit die aktuellen Qualitätsfälle schnell überblicken und Ressourcen priorisieren. Beim Process Mining hilft die Filterung nach dem Endstatus, die Ergebnisse verschiedener Prozesspfade zu analysieren. Warum das wichtig ist Das Attribut zeigt den aktuellen Stand der Qualitätsereignisse und unterstützt so die operative Steuerung und Priorisierung aktiver Fälle. Woher beziehen Diese Informationen sind üblicherweise in der Haupttabelle für Qualitätsereignisse verfügbar und geben den zuletzt bekannten Status des Ereignisses wieder. Beispiele OffenIn BearbeitungFreigabe ausstehendGeschlossen
	Endzeit des Ereignisses EventEndTime	Der Timestamp, der angibt, wann eine Aktivität oder ein Ereignis abgeschlossen wurde.
Beschreibung Die Endzeit des Ereignisses kennzeichnet den Abschluss einer bestimmten Aktivität. Zusammen mit der Startzeit des Ereignisses gibt sie die Bearbeitungszeit dieser Aktivität an. In manchen Systemen dauert eine Aktivität nur einen Augenblick. Dann sind Start- und Endzeit identisch. Dieses Attribut ist für eine detaillierte Daueranalyse unverzichtbar. Analysten können damit die aktive Bearbeitungszeit, also die Zeit zwischen Start und Ende, von der Wartezeit zwischen dem Ende einer Aktivität und dem Beginn der nächsten unterscheiden. So wird sichtbar, wo Ressourcen aktiv eingesetzt werden und wo Übergaben Verzögerungen verursachen. Warum das wichtig ist Damit lassen sich die Bearbeitungszeiten von Aktivitäten genau berechnen. So können ineffiziente Aufgaben von langen Wartezeiten unterschieden werden. Woher beziehen Dieser Wert ist möglicherweise in denselben Transaktions- oder Historientabellen wie die Startzeit verfügbar, manchmal als LAST_UPDATE_DATE oder als eigener Abschluss-Timestamp. Er kann auch aus der Startzeit des Folgeereignisses abgeleitet werden. Beispiele 2023-04-15T09:15:30Z2023-04-16T12:00:00Z2023-05-02T10:00:00Z
	Geplantes Behebungsdatum TargetResolutionDate	Das geplante oder erwartete Datum, an dem das Qualitätsereignis endgültig abgeschlossen sein soll.
Beschreibung Dieses Attribut gibt die Frist an, bis zu der ein Qualitätsereignis vollständig behoben sein soll. Es dient als Service Level Agreement (SLA) oder internes Ziel. Die Frist richtet sich häufig nach Schweregrad oder Art des Ereignisses. Das Datum ist eine wichtige Grundlage für die Leistungskontrolle und fließt direkt in die Berechnung der KPI „CAPA-Umsetzungsquote fristgerecht“ ein. Durch den Vergleich der tatsächlichen Abschlussdaten mit dem Zieltermin können Analysten die Termintreue messen, verspätungsgefährdete Ereignisse erkennen und Entwicklungen bei der fristgerechten Bearbeitung verfolgen. So lassen sich die Durchlaufzeiten bis zur Behebung verkürzen. Warum das wichtig ist Das Datum dient als Maßstab für die Termintreue und ist für die Berechnung von Termintreue-KPIs sowie die Überwachung von SLAs unverzichtbar. Woher beziehen Lesen Sie die Dokumentation zu Oracle Quality Management. Dabei kann es sich um ein Standard-Datumsfeld oder ein benutzerdefiniertes Element im Qualitätsprüfplan handeln. Beispiele 2023-05-302023-06-152024-01-10
	Schweregrad SeverityLevel	Eine Einstufung der Auswirkungen des Qualitätsereignisses, etwa als kritisch, schwerwiegend oder geringfügig.
Beschreibung Der Schweregrad ist eine Einschätzung, die üblicherweise bei der Erstprüfung vorgenommen wird. Sie bewertet die möglichen Auswirkungen des Qualitätsproblems auf Kunden, Compliance oder den Geschäftsbetrieb. Die Einstufung hilft, Ressourcen zu priorisieren und die Dringlichkeit der erforderlichen Reaktion festzulegen. Beim Process Mining ist dieses Attribut wichtig für die Segmentierung. Analysten können Prozessabläufe, Durchlaufzeiten und Ergebnisse bei Ereignissen mit hohem und niedrigem Schweregrad vergleichen. Das unterstützt das Dashboard 'Einheitlichkeit der Erstprüfung von Qualitätsereignissen' und die KPI 'Lösungsquote nach Schweregrad'. So wird sichtbar, ob kritische Probleme tatsächlich schneller und wirksamer bearbeitet werden. Warum das wichtig ist Das Attribut unterstützt die Priorisierung und Segmentierung der Analyse. So können Qualitätsereignisse mit großen Auswirkungen wirksam und effizient bearbeitet werden. Woher beziehen Lesen Sie die Dokumentation zu Oracle Quality Management. Dabei handelt es sich häufig um ein konfigurierbares Element innerhalb eines Qualitätsprüfplans. Beispiele 1 - Kritisch2 - Schwerwiegend3 - Geringfügig4 - Zur Information
	Ursachenkategorie RootCauseCategory	Die Klassifizierung der ermittelten Ursache des Qualitätsproblems.
Beschreibung Nach einer Ursachenanalyse werden die Ergebnisse häufig vordefinierten Kategorien wie „Geräteausfall“, „menschlicher Fehler“ oder „Konstruktionsmangel“ zugeordnet. Dieses Attribut speichert die abschließende Klassifizierung. Die Analyse nach Ursachenkategorie ist besonders aussagekräftig. Sie lenkt den Blick weg von der Behebung einzelner Symptome und hin zu den zugrunde liegenden systemischen Problemen. Eine hohe Zahl von Ereignissen mit der Ursache „Schulungsbedarf“ kann beispielsweise auf den Bedarf an besseren Schulungsprogrammen für Mitarbeitende hinweisen. Das ist ein wichtiges Ziel vorbeugender Maßnahmen. Warum das wichtig ist Dieses Attribut ist entscheidend für den Wechsel von reaktivem zu proaktivem Qualitätsmanagement, da es die Analyse der grundlegenden Fehlerursachen ermöglicht. Woher beziehen Lesen Sie die Dokumentation zu Oracle Quality Management. Dabei handelt es sich wahrscheinlich um ein benutzerdefiniertes Element im Prüfplan, das nach der Aktivität „Ursachenanalyse durchgeführt“ ausgefüllt wird. Beispiele GerätestörungMaterialmangelMenschlicher FehlerVorgehensweise nicht eingehalten
	Zugewiesener Benutzer AssignedUser	Der Benutzer, der mit der Ausführung einer Aktivität oder der Verantwortung für das Qualitätsereignis betraut ist.
Beschreibung Dieses Attribut gibt an, wer für eine bestimmte Aufgabe oder die Gesamtbearbeitung des Qualitätsereignisses zuständig ist. Es bietet eine detailliertere Sicht als die zuständige Abteilung. Die Auswertung nach Benutzer hilft, die individuelle Arbeitslast zu verstehen, Schulungsbedarf zu erkennen und besonders leistungsstarke Mitarbeitende zu identifizieren. Sie kann auch Muster aufzeigen, etwa wenn Aufgaben regelmäßig neu zugewiesen werden oder bei bestimmten Personen ins Stocken geraten. Diese Detailtiefe ist für das Leistungsmanagement und eine gezielte Ressourcenplanung hilfreich. Warum das wichtig ist Das Attribut ermöglicht eine detaillierte Analyse der individuellen Arbeitslast und Leistung. So lassen sich Ressourcenengpässe und Schulungsbedarf erkennen. Woher beziehen Lesen Sie die Dokumentation zu Oracle Quality Management. Informationen zu Benutzerzuweisungen sind üblicherweise in Aktions- oder Workflow-Tabellen zum Qualitätsereignis gespeichert. Beispiele j.smitha.jonesr.williams
	Zuständige Abteilung ResponsibleDepartment	Die Abteilung oder der Funktionsbereich, der für das Qualitätsereignis oder die aktuelle Aktivität zuständig ist.
Beschreibung Dieses Attribut gibt das Team oder die Abteilung an, das beziehungsweise die mit der Bearbeitung des Qualitätsereignisses betraut ist. Dazu können Qualitätssicherung, Engineering, Produktion oder andere Bereiche gehören. Die Zuständigkeit kann sich im Verlauf des Ereignisses ändern. Bei Process Mining ist die Auswertung nach zuständiger Abteilung wichtig, um die Arbeitslast zu verstehen, Engpässe in einzelnen Abteilungen zu erkennen und die Leistung verschiedener Teams zu vergleichen. Das Attribut unterstützt das Dashboard 'Ressourcenzuweisung bei Qualitätsereignissen'. Es zeigt, welche Abteilungen an welchen Aktivitäten beteiligt sind, und hilft so, den Ressourceneinsatz zu verbessern. Warum das wichtig ist Damit lassen sich Arbeitslast, Leistung und Engpässe nach Abteilung auswerten. Das ist wichtig für die Ressourcenplanung und die Weiterentwicklung der Organisation. Woher beziehen Lesen Sie die Dokumentation zu Oracle Quality Management. Die Daten können in Tabellen zu Qualitätsmaßnahmen oder Zuweisungen gespeichert und mit dem Qualitätsereignis verknüpft sein. Beispiele QualitätsengineeringFertigungsbetriebLieferantenqualitätKonstruktionsengineering
	Abschlusscode ClosureCode	Ein Code, der den Grund oder das Ergebnis für den Abschluss des Qualitätsereignisses angibt.
Beschreibung Beim Abschluss eines Qualitätsereignisses wird häufig ein Abschlusscode vergeben, der das Endergebnis klassifiziert. Beispiele sind „Maßnahme wirksam“, „Keine Maßnahme erforderlich“ oder „Doppelter Eintrag“. Dieses Attribut ist für die Ergebnisanalyse sehr hilfreich. Durch die Filterung nach Abschlusscode können Analysten untersuchen, welche Prozesspfade zu erfolgreichen Ergebnissen führen und welche nicht. So lässt sich beispielsweise die Frage beantworten: „Wie verläuft unser Prozess bei Problemen, die als doppelte Einträge geschlossen werden?“ Außerdem können Ineffizienzen bei der Erstbewertung erkannt werden. Warum das wichtig ist Das Attribut liefert wichtige Informationen zum Ergebnis eines Falls. So lässt sich analysieren, welche Prozesspfade zu einer erfolgreichen Lösung führen. Woher beziehen Lesen Sie die Dokumentation zu Oracle Quality Management. Dieses Feld wird wahrscheinlich während der abschließenden Aktivität zum Schließen ausgefüllt. Beispiele WIRKSAMKEINE_MASSNAHMEDOPPELTRISIKO_AKZEPTIERT
	Fehlerkategorie IssueCategory	Kategorie oder Art des Qualitätsproblems, zum Beispiel „Produktmangel“ oder „Prozessabweichung“.
Beschreibung Dieses Attribut klassifiziert das Qualitätsereignis und erleichtert es, ähnliche Probleme für die Analyse zusammenzufassen. Die Organisation legt die Kategorien üblicherweise passend zu ihrem betrieblichen Umfeld fest. Eine Analyse nach Fehlerkategorie macht Muster bei bestimmten Problemarten sichtbar. So kann sich beispielsweise zeigen, dass Probleme mit „Lieferantenmaterial“ eine deutlich längere Zykluszeit aufweisen als Probleme mit „internen Prozessen“. Diese Aufschlüsselung hilft dabei, gezielte Verbesserungsmaßnahmen einzuleiten. Warum das wichtig ist Durch die Kategorisierung lassen sich Trends und Ursachen in bestimmten Problembereichen gezielt untersuchen. Woher beziehen Lesen Sie die Dokumentation zu Oracle Quality Management. Dabei handelt es sich wahrscheinlich um ein benutzerdefiniertes Element im Qualitätsprüfplan. Beispiele ProduktmangelProzessabweichungLieferantenmaterialKundenbeschwerde
	Fristgerecht IsOnTime	Eine Kennzeichnung, die angibt, ob eine Korrekturmaßnahme bis zum geplanten Behebungsdatum umgesetzt wurde.
Beschreibung Dieses boolesche Attribut wird ermittelt, indem der Abschluss-Timestamp der Aktivität „Korrekturmaßnahme umgesetzt“ mit dem „Geplanten Behebungsdatum“ des Falls verglichen wird. Es ist wahr, wenn die Maßnahme am oder vor dem Zieltermin abgeschlossen wurde, andernfalls falsch. Das Attribut fließt direkt in die KPI „CAPA-Umsetzungsquote fristgerecht“ ein. Es vereinfacht Analysen und die Erstellung von Dashboards, da es die Termintreue für jeden Fall eindeutig in zwei Kategorien einteilt. Durch einfaches Filtern und Aggregieren können Sie die Einhaltung von Service Levels überwachen und Ursachen für Verzögerungen ermitteln. Warum das wichtig ist Das Attribut erleichtert die Überwachung der Termintreue im Vergleich zu den Zielvorgaben und die Messung und Berichterstattung zu diesem wichtigen KPI. Woher beziehen Diese Kennzeichnung wird bei der Datentransformation abgeleitet. Dafür werden TargetResolutionDate und der Timestamp der relevanten Abschlussaktivität benötigt. Beispiele truefalse
	Gesamte Zykluszeit TotalCycleTime	Die gesamte Zeitspanne von der Erkennung eines Qualitätsproblems bis zu seinem endgültigen Abschluss.
Beschreibung Dieses Attribut misst die gesamte End-to-End-Dauer eines einzelnen Qualitätsereignisses. Sie wird berechnet, indem der Timestamp der ersten Aktivität („Qualitätsproblem erkannt“) vom Timestamp der letzten Aktivität („Abschließende Prüfung und Abschluss“) abgezogen wird. Die Kennzahl ist ein zentraler KPI für die Gesamteffizienz des Qualitätsmanagementprozesses. Sie bildet die Grundlage für das Dashboard „End-to-End-Zykluszeit von Qualitätsereignissen“. Wird die Kennzahl über einen längeren Zeitraum verfolgt und nach Attributen wie Schweregrad oder Fehlerkategorie aufgeschlüsselt, zeigt sich, wie gesund der Prozess ist und welche Wirkung Verbesserungsmaßnahmen haben. Warum das wichtig ist Dieser wichtige KPI misst die Geschwindigkeit und Effizienz des gesamten Qualitätsmanagementprozesses vom Anfang bis zum Abschluss. Woher beziehen Die Berechnung erfolgt auf Fallebene während der Datenverarbeitung für Process Mining. 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 Abteilung der Organisation, in der das Qualitätsereignis aufgetreten ist oder bearbeitet wird.
Beschreibung Dieses Attribut ordnet das Qualitätsereignis einem bestimmten Teil der Unternehmensstruktur zu. So lassen sich die Qualitätsleistungen verschiedener Organisationseinheiten analysieren und vergleichen. Für große Unternehmen ist es üblich, Prozesse nach Geschäftseinheit aufzuschlüsseln. So können Dashboards für einzelne Geschäftseinheiten erstellt und Bereiche ermittelt werden, deren Qualitätsprozesse effizienter sind oder die vor besonderen Herausforderungen stehen. Das unterstützt die unternehmensweite Steuerung und den Austausch bewährter Vorgehensweisen. Warum das wichtig ist Das Attribut ermöglicht den Vergleich und die Analyse der Leistung verschiedener Organisationseinheiten und unterstützt so das unternehmensweite Qualitätsmanagement. Woher beziehen Diese Information gehört üblicherweise zu den Organisationsdaten der Transaktion und wird häufig aus den Stammdaten des Benutzers oder der Abteilung abgeleitet. Beispiele MedizintechnikUnterhaltungselektronikAutomobilteile
	ID des Korrekturmaßnahmenplans CorrectiveActionPlanId	Die eindeutige Kennung des Korrekturmaßnahmenplans (CAPA), der zur Behebung des Qualitätsereignisses erstellt wurde.
Beschreibung Dieses Attribut verknüpft ein Qualitätsereignis direkt mit dem konkreten Korrektur- und Vorbeugungsmaßnahmenplan, der zu seiner Behebung erstellt wurde. Dieser Plan ist häufig ein separates Objekt im System und hat einen eigenen Lebenszyklus. In der Analyse lässt sich diese ID verwenden, um Daten aus dem Qualitätsereignisprozess mit Daten aus dem CAPA-Managementprozess zusammenzuführen. Dadurch entsteht ein umfassenderes Bild. Außerdem können Sie prüfen, ob jedem Ereignis, für das eine CAPA erforderlich ist, ein Plan zugewiesen wurde, und die Wirksamkeit der Maßnahmen analysieren. Warum das wichtig ist Das Attribut verknüpft das Problem (Qualitätsereignis) mit der Lösung (CAPA) und ermöglicht so eine umfassendere End-to-End-Analyse des Qualitätsmanagementsystems. Woher beziehen Dabei handelt es sich um 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 Aktualisierung oder Datenübernahme aus dem Quellsystem.
Beschreibung Dieses Attribut gibt an, wann die Daten zu diesem Ereignis zuletzt im Process-Mining-Datensatz aktualisiert wurden. Es zeigt, wie aktuell die Daten sind, und hilft Benutzern, die Aktualität der Analyse einzuschätzen. In Dashboards und Berichten liefert dieser Timestamp wichtigen Kontext. Er zeigt, ob die Daten aktuell sind oder einen Stand zu einem bestimmten Zeitpunkt wiedergeben. Das ist entscheidend für fundierte operative Entscheidungen und sorgt für Transparenz über den Datenstand. Warum das wichtig ist Dieser Timestamp macht den Datenstand transparent. So können Benutzer einschätzen, wie aktuell die Prozessanalyse ist. Woher beziehen Dieser Wert wird während des ETL-Prozesses erzeugt und gespeichert. Üblicherweise gibt er an, wann die Datenpipeline zuletzt erfolgreich ausgeführt wurde. Beispiele 2023-10-27T04:00:00Z2023-10-26T04:00:00Z
	Nacharbeit IsRework	Eine Kennzeichnung, die angibt, ob eine Aktivität eine Wiederholung oder Nacharbeit eines vorherigen Schritts im selben Fall ist.
Beschreibung Dieses boolesche Attribut wird auf „wahr“ gesetzt, wenn eine bestimmte Aktivität, etwa „Korrekturmaßnahmenplan vorgeschlagen“, innerhalb eines Qualitätsereignisses mehr als einmal auftritt. Das weist auf eine Schleife oder Korrektur im Prozess hin, bei der ein bereits abgeschlossener Schritt wiederholt werden musste. Nacharbeit zu erkennen, gehört zu den zentralen Funktionen von Process Mining. Mit dieser Kennzeichnung lässt sich der Umfang solcher Ineffizienzen ermitteln. Sie fließt direkt in die KPI „Häufigkeit von Aktivitätswiederholungen“ ein. Eine Analyse der Schritte, bei denen besonders häufig Nacharbeit anfällt, und der jeweiligen Bedingungen kann Probleme bei Schulungen, der Datenqualität oder den Freigabekriterien aufdecken. So werden Verbesserungsmöglichkeiten sichtbar. Warum das wichtig ist Das Attribut kennzeichnet Ineffizienzen und Schleifen im Prozess. So lässt sich der Aufwand für Nacharbeit messen und deren Ursachen ermitteln. Woher beziehen Die Berechnung erfolgt bei der Datenaufbereitung mithilfe von Fensterfunktionen oder einer sequenziellen Analyse des Event Logs. Dabei wird erkannt, wenn derselbe Aktivitätsname mehrmals für denselben Fall auftritt. Beispiele truefalse
	Produktkennung ProductIdentifier	Die Kennung 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. Es kann 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 lassen sich Qualitätsmanagementprozesse verschiedener Produktlinien vergleichen und Produkte ermitteln, bei denen häufig Qualitätsprobleme auftreten. So können Verbesserungen in Entwicklung oder Fertigung dort priorisiert werden, wo sie am dringendsten benötigt werden. Warum das wichtig ist Das Attribut verknüpft Qualitätsereignisse mit bestimmten Produkten. So lassen sich produktbezogene Qualitätstrends und Prozessabweichungen analysieren. Woher beziehen Diese Information wird in einem Feld des Qualitätsprüfplans gespeichert, das häufig mit dem Artikelstamm von Oracle Inventory verknüpft ist. Beispiele SKU-100-A-REDPN-987654CHEM-X2
	Quellsystem SourceSystem	Gibt das führende System an, aus dem die Daten extrahiert wurden.
Beschreibung Dieses Attribut gibt die Ursprungsanwendung oder das Ursprungssystem der Ereignisdaten an. In einem Unternehmen können Daten zu Qualitätsereignissen aus mehreren Quellen stammen, etwa aus dem zentralen Oracle-Quality-Modul, einem separaten CAPA-System oder einem Portal für Kundenbeschwerden. Bei der Analyse hilft dieses Feld, die Datenherkunft nachzuvollziehen und Prozesse nach Ursprungssystem aufzuschlüsseln. Es ist wichtig für die Data Governance und die Fehlersuche bei Datenintegrationen. So lässt sich sicherstellen, dass die Prozessansicht die zusammengeführten Daten korrekt abbildet. Warum das wichtig ist Das Attribut liefert wichtigen Kontext zur Datenherkunft. Dieser ist für die Datenvalidierung und Governance sowie für die Analyse von Prozessvarianten in verschiedenen Systemen relevant. Woher beziehen Dieser statische Wert wird üblicherweise während des ETL-Prozesses (Extraktion, Transformation und Laden) hinzugefügt, um die Herkunft des Datensatzes zu kennzeichnen. Beispiele Oracle Quality Management R12Oracle EBS QualityQM-PROD

Erforderlich Empfohlen Optional

Aktivitäten im Qualitätsmanagement

Diese wichtigen Prozessschritte und Meilensteine sollten Sie in Ihrem Event Log erfassen, um den Prozess präzise zu entdecken und seine Leistung zu bewerten.

6 Empfohlen 8 Optional

	Aktivität	Beschreibung
	Abschließende Prüfung und Schließung	Im letzten Schritt wird bestätigt, dass alle zugehörigen Maßnahmen abgeschlossen sind. Anschließend wird das übergeordnete Qualitätsproblem formell geschlossen. Erfasst wird dies durch eine abschließende Statusänderung des Hauptdatensatzes zu 'Closed' oder 'Resolved'.
Warum das wichtig ist Dies ist das zentrale End-Event des Prozesses. Es ist wichtig, um die KPI 'Durchschnittliche Durchlaufzeit von Ereignissen' zu berechnen und den Gesamtdurchsatz des Prozesses zu messen. Woher beziehen Lässt sich aus der abschließenden Statusänderung des übergeordneten Quality Issue-Datensatzes zu 'Closed' ableiten. Der Timestamp dieser Änderung dient als Ereigniszeitpunkt. Erfassung Lässt sich aus einer Statusänderung des Hauptdatensatzes für das Quality Issue zu 'Closed' ableiten. Ereignistyp inferred
	Korrekturmaßnahmenplan freigegeben	Diese Aktivität steht für die formelle Freigabe des vorgeschlagenen Korrekturmaßnahmenplans durch eine zuständige Stelle. Sie ist ein wichtiger Kontrollpunkt und wird üblicherweise durch eine ausdrückliche Freigabeaktion oder eine Statusänderung zu 'Approved' erfasst.
Warum das wichtig ist Die Freigabe ist ein wichtiger Meilenstein und häufig ein Engpass. Die Analyse der Freigabezeiten hilft, den Prozess zu verbessern und die Einhaltung der Vorgehensweisen sicherzustellen. Woher beziehen Lässt sich aus einer Statusänderung des Quality Action- oder CAPA-Datensatzes zu 'Approved' ableiten. In Oracle-Systemen mit Freigabe-Workflows wird diese Änderung häufig ausdrücklich in Audit-Tabellen protokolliert. Erfassung Lässt sich aus einer Statusänderung zu 'Approved' ableiten. 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 üblicherweise erfasst, wenn der Status des Problems von 'New' zu 'Assessed' oder 'In Triage' wechselt.
Warum das wichtig ist Dieser Meilenstein ist entscheidend für die KPI 'Durchschnittliche Bearbeitungszeit der Erstprüfung'. Verzögerungen an dieser Stelle können den gesamten Lösungsprozess verlangsamen, insbesondere bei kritischen Problemen. Woher beziehen Lässt sich aus einer Statusänderung des Quality Issue-Datensatzes ableiten, zum Beispiel von 'New' zu 'Under Assessment', oder daraus, dass Felder wie 'Severity' oder 'Priority' erstmals ausgefüllt werden. Erfassung Lässt sich aus einer Statusänderung oder dem erstmaligen Ausfüllen der Felder für Schweregrad oder Priorität ableiten. Ereignistyp inferred
	Qualitätsproblem erkannt	Diese Aktivität kennzeichnet die Erfassung eines neuen Qualitätseintrags, etwa 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 anlegt.
Warum das wichtig ist Als Start-Event ist diese Aktivität wichtig, um die gesamte Durchlaufzeit des Qualitätsmanagementprozesses zu berechnen und das Volumen eingehender Qualitätsereignisse zu ermitteln. Woher beziehen Das Ereignis wird anhand des Erstellungs-Timestamps des Quality Issue- oder Quality Action-Datensatzes erfasst. Dieser findet sich wahrscheinlich in Tabellen wie QAM_QUALITY_ISSUES oder QAM_QUALITY_ACTIONS. Erfassung Ereignis, das beim Anlegen eines neuen Quality Issue- oder Action-Datensatzes protokolliert wird. Ereignistyp explicit
	Untersuchung eingeleitet	Kennzeichnet den offiziellen Beginn der Untersuchung zur Ermittlung der Grundursache des Qualitätsproblems. Im System wird dies üblicherweise durch eine Statusänderung angezeigt, etwa zu 'Under Investigation'.
Warum das wichtig ist Dieser Schritt bildet den Ausgangspunkt für die KPI 'Durchlaufzeit der Ursachenanalyse' und zeigt, wie lange Probleme vor Beginn einer formellen Untersuchung warten. Woher beziehen Lässt sich aus einer Statusänderung des Quality Issue-Datensatzes oder eines zugehörigen Quality Action-Datensatzes zu einem Status wie 'Investigation' ableiten. Der Timestamp dieser Änderung gibt den Ereigniszeitpunkt an. Erfassung Lässt sich aus einer Statusänderung zu 'Under Investigation' oder einem ähnlichen Status ableiten. Ereignistyp inferred
	Wirksamkeit der Maßnahme bestätigt	Bestätigt, dass die umgesetzte Korrekturmaßnahme die Grundursache erfolgreich behoben und ein erneutes Auftreten verhindert hat. Erfasst wird dies, wenn ein Benutzer die Prüfung abschließt und den Status des Datensatzes aktualisiert.
Warum das wichtig ist Dieser ergebnisbezogene Meilenstein ist entscheidend und bildet die Grundlage für die KPI 'Quote bestätigter Wirksamkeitsprüfungen'. Er schließt den Korrekturmaßnahmenzyklus ab und stellt sicher, dass die Probleme tatsächlich behoben sind. Woher beziehen Lässt sich aus einer Statusänderung des CAPA-Datensatzes zu 'Verification Complete' oder 'Effective' ableiten. Dabei können auch bestimmte Felder zum Prüfergebnis ausgefüllt werden. Erfassung Lässt sich aus einer Statusänderung zu 'Verification Complete' oder 'Effective' ableiten. Ereignistyp inferred
	Beteiligte über die Lösung informiert	Diese Aktivität steht für die Mitteilung der Lösung eines Qualitätsereignisses an die zuständigen Personen, etwa die meldende Person oder betroffene Kunden. Sie lässt sich nur schwer erfassen und kann aus einer Statusänderung nach dem Abschluss oder einem protokollierten Kommentar abgeleitet werden.
Warum das wichtig ist Diese Aktivität ist entscheidend für die KPI 'Verzögerung bei der Information Beteiligter'. Eine zeitnahe Mitteilung ist wichtig für die Kundenzufriedenheit und die interne Transparenz, auch nachdem ein Problem gelöst wurde. Woher beziehen Diese Aktivität lässt sich häufig nicht automatisch erfassen. Sie kann aus einem Status wie 'Notification Sent' abgeleitet oder in einem Aktivitäts- oder Kommentarfeld protokolliert werden. Für die Extraktion ist möglicherweise eine spezielle Logik erforderlich. Erfassung Lässt sich aus einer bestimmten Statusänderung oder gegebenenfalls durch Textanalyse der Aktivitätsprotokolle ableiten. Ereignistyp inferred
	Korrekturmaßnahme umgesetzt	Kennzeichnet den Abschluss der im freigegebenen Korrekturmaßnahmenplan festgelegten Aufgaben. Üblicherweise wird dies erfasst, wenn ein Benutzer den Status des Corrective Action-Datensatzes zu 'Implemented' oder 'Completed' ändert.
Warum das wichtig ist Diese Aktivität ist wichtig für die KPI 'CAPA-Umsetzungsquote zum Termin'. Sie zeigt, dass die geplante Maßnahme umgesetzt wurde, und ermöglicht den Abgleich mit den Zieldaten. Woher beziehen Dieses Ereignis lässt sich aus einer Statusänderung des zugehörigen Quality Action- oder CAPA-Datensatzes zu 'Implemented' oder 'Completed' ableiten. Erfassung Lässt sich aus einer Statusänderung zu 'Implemented' oder 'Completed' ableiten. Ereignistyp inferred
	Korrekturmaßnahmenplan vorgeschlagen	Diese Aktivität findet statt, wenn Korrekturmaßnahmen festgelegt und mit dem Qualitätsproblem verknüpft werden. Sie beschreiben die Schritte zur Behebung des Problems. Erfasst werden kann beispielsweise das Anlegen eines zugehörigen Corrective Action-Datensatzes oder eine Statusänderung, die anzeigt, dass der Plan zur Prüfung bereitsteht.
Warum das wichtig ist Diese Aktivität bildet den Übergang von der Problemanalyse zur Lösungsplanung ab. Nacharbeit an dieser Stelle, gemessen anhand von Nacharbeits-KPIs, kann auf unklare Anforderungen oder eine ineffektive Planung hindeuten. Woher beziehen Das Ereignis kann ausdrücklich beim Anlegen eines neuen Corrective Action-Datensatzes in einem CAPA-Objekt erfasst oder aus einer Statusänderung zu 'Plan Proposed' oder 'Pending Approval' abgeleitet werden. Erfassung Lässt sich aus einer Statusänderung zu 'Pending Approval' oder dem Anlegen eines verknüpften Corrective Action-Datensatzes ableiten. Ereignistyp inferred
	Problem zur Erstprüfung zugewiesen	Diese Aktivität steht für die Zuweisung des neu erfassten Qualitätsproblems an einen bestimmten Benutzer oder ein Team zur ersten Prüfung und Bewertung. Sie lässt sich häufig anhand von Änderungen im Feld für den Zuständigen oder Eigentümer des Quality Issue-Datensatzes ableiten.
Warum das wichtig ist Die Nachverfolgung dieser ersten Übergabe hilft, Verzögerungen vor Beginn der Bewertung zu erkennen. Die Verweildauer in diesem Status kann auf Rückstände in der Erstprüfungswarteschlange hinweisen. Woher beziehen Lässt sich aus Änderungen im Feld für den Eigentümer oder Zuständigen des Quality Issue-Datensatzes ableiten. Als Quelle kommen Audit-Trail-Tabellen oder die Nachverfolgung von Statusänderungen im Zuweisungs-Workflow infrage. Erfassung Lässt sich aus einer Änderung im Feld 'Assigned To' oder 'Owner' des Quality Issue-Datensatzes ableiten. Ereignistyp inferred
	Ursachenanalyse durchgeführt	Diese Aktivität steht für den Abschluss der Ursachenanalyse (RCA) und die Dokumentation der Ergebnisse. Sie wird üblicherweise erfasst, wenn das Untersuchungsteam die ermittelte Grundursache im Quality Issue-Datensatz einträgt und dessen Status ändert.
Warum das wichtig ist Diese Aktivität bildet den Endpunkt der KPI 'Durchlaufzeit der Ursachenanalyse'. Die Dauer bis zu diesem Schritt zeigt, wo im Problemlösungsprozess Engpässe auftreten. Woher beziehen Lässt sich aus einer Statusänderung zu 'RCA Complete' oder daraus ableiten, dass das Feld für die Grundursachenkategorie ausgefüllt und der Datensatz gespeichert wird. Verwendet wird der Timestamp dieser Aktualisierung. Erfassung Lässt sich aus einer Statusänderung zu 'RCA Complete' oder dem Ausfüllen der Felder zur Grundursache ableiten. Ereignistyp inferred
	Vorbeugungsmaßnahme identifiziert	Diese Aktivität steht für das Anlegen einer Vorbeugungsmaßnahme (PA), die systemische Probleme beheben und ähnliche Qualitätsereignisse verhindern soll. Häufig wird sie als neuer, mit dem ursprünglichen Problem verknüpfter Preventive Action-Datensatz protokolliert.
Warum das wichtig ist Diese Aktivität zeigt einen ausgereiften Qualitätsprozess: Statt nur einzelne Probleme zu beheben, werden auch künftige Probleme verhindert. Ihre Nachverfolgung hilft, proaktive Qualitätsverbesserungen zu messen. Woher beziehen Erfasst beim Anlegen eines neuen Quality Action-Datensatzes mit dem Typ 'Preventive Action', der häufig mit dem ursprünglichen Quality Issue- oder Corrective Action-Datensatz verknüpft ist. Erfassung Wird beim Anlegen eines Quality Action-Datensatzes vom Typ 'Preventive Action' protokolliert. Ereignistyp explicit
	Vorbeugungsmaßnahme umgesetzt	Kennzeichnet den Abschluss der im Plan für Vorbeugungsmaßnahmen festgelegten Aufgaben zur Verringerung systemischer Risiken. Erfasst wird dies, wenn ein Benutzer den Status des Preventive Action-Datensatzes zu 'Implemented' oder 'Completed' ändert.
Warum das wichtig ist Misst, wie gut das Unternehmen proaktive Qualitätsverbesserungen umsetzt. Verzögerungen können darauf hindeuten, dass systemische Änderungen im Unternehmen nur schwer umgesetzt werden. Woher beziehen Lässt sich, ähnlich wie bei Korrekturmaßnahmen, aus einer Statusänderung des zugehörigen Preventive Action-Datensatzes zu 'Implemented' oder 'Completed' ableiten. Erfassung Lässt sich aus einer Statusänderung des Preventive Action-Datensatzes zu 'Implemented' ableiten. Ereignistyp inferred
	Wirksamkeitsprüfung erforderlich	Diese Aktivität steht dafür, dass das System oder ein Benutzer eine Nachprüfung der umgesetzten Maßnahme veranlasst, um ihre Wirksamkeit zu bestätigen. Häufig erfolgt dies nach der Umsetzung durch eine automatische oder manuelle Statusänderung.
Warum das wichtig ist Mit diesem Schritt beginnt die wichtige Prüfphase. Die Zeit zwischen der Umsetzung und dieser Aktivität kann Verzögerungen beim Einleiten notwendiger Nachprüfungen sichtbar machen. Woher beziehen Dieses Ereignis lässt sich aus einer Statusänderung des Quality Action-Datensatzes zu 'Pending Effectiveness Check' oder einem ähnlichen Status im Workflow ableiten. Erfassung Lässt sich aus einer Statusänderung zu 'Pending Effectiveness Check' ableiten. Ereignistyp inferred

Anleitungen zur Datenextraktion

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 wechseln Sie zu der Verantwortung, die Zugriff auf BI Publisher bietet, zum Beispiel BI Publisher Administrator oder eine vergleichbare benutzerdefinierte Verantwortung.
Neues Datenmodell erstellen: Wählen Sie auf der BI-Publisher-Startseite zunächst Create und dann Data Model. Dadurch wird der Datenmodell-Editor geöffnet.
SQL-Query-Dataset definieren: Klicken Sie im Datenmodell-Editor im Bereich Data Sets auf das Pluszeichen und wählen Sie SQL Query. Daraufhin öffnet sich das Fenster für die SQL-Query.
Datenquelle konfigurieren: Geben Sie im Fenster New Data Set einen Namen für Ihr Dataset ein, zum Beispiel DS_QUALITY_EVENTS. Wählen Sie unter Data Source die passende Oracle-EBS-Datenbank aus.
SQL-Query eingeben: Kopieren Sie die vollständige SQL-Query aus dem Abschnitt „query“ dieses Dokuments und fügen Sie sie in das Textfeld SQL Query ein.
Query-Parameter definieren: Die bereitgestellte Query verwendet für den Berichtszeitraum die Platzhalter :P_START_DATE und :P_END_DATE. Definieren Sie diese im BI-Publisher-Datenmodell als Parameter. Erstellen Sie für jeden Parameter einen neuen Eintrag, vergeben Sie den entsprechenden Namen (zum Beispiel P_START_DATE), wählen Sie als Datentyp Date und richten Sie eine verständliche Eingabeaufforderung ein.
Datenmodell speichern: Speichern Sie das Datenmodell, nachdem Sie die Query eingefügt und die Parameter definiert haben. Wir empfehlen, es in einem freigegebenen Berichtsordner abzulegen.
Neuen Bericht erstellen: Wechseln Sie zurück zur BI-Publisher-Startseite und wählen Sie Create und anschließend Report. Wählen Sie die Option 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 als Ausgabeformat CSV festgelegt ist.
Berichtseigenschaften festlegen: Prüfen Sie in den Berichtseigenschaften, ob die Option Enable CSV Output aktiviert ist. Bei Bedarf können Sie auch Standardwerte für die Parameter festlegen.
Bericht ausführen und exportieren: Speichern Sie den Bericht und führen Sie ihn mit dem gewünschten Start- und Enddatum aus. Klicken Sie nach 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 dem ProcessMind-Schema entsprechen. Anschließend können Sie die Datei hochladen.

Konfiguration

Voraussetzungen: Ein Benutzerkonto mit Zugriff auf Oracle BI Publisher und Leseberechtigung für die zugrunde liegenden Tabellen des Qualitätsmoduls, zum Beispiel QA_RESULTS, QA_PLANS, QA_ACTIONS und FND_USER.
Datenquelle konfigurieren: Das BI-Publisher-Datenmodell muss eine Verbindung zur primären Oracle-EBS-Anwendungsdatenbank (Schema APPS) herstellen.
Parameter für den Datumsbereich: Die Query enthält die beiden Pflichtparameter :P_START_DATE und :P_END_DATE, mit denen die extrahierten Daten gefiltert werden. Für eine erste Analyse empfiehlt sich ein Zeitraum von 6 bis 12 Monaten, damit genügend vollständige Cases erfasst werden. Verwenden Sie das Datumsformat 'YYYY-MM-DD'.
Ausgabeformat: Der Bericht muss so konfiguriert sein, dass eine CSV-Ausgabe möglich ist. Dieses Format eignet sich besonders für den Import in ProcessMind, da es einfach und strukturiert ist und keine komplexe Verarbeitung erfordert.
Zeitplanung: Für eine kontinuierliche Prozessüberwachung sollten Sie den BI-Publisher-Bericht regelmäßig ausführen lassen, zum Beispiel täglich oder wöchentlich. Richten Sie die Ausgabe so ein, dass sie an einen festgelegten Server oder ein Content Repository übermittelt und von dort automatisch abgerufen wird.
Leistung: Bei Oracle-Instanzen mit sehr vielen Qualitätsereignissen kann die Query lange dauern. Achten Sie auf einen angemessenen Datumsbereich. Wenn die Leistung problematisch ist, besprechen Sie mit Ihrer Datenbankadministration mögliche Optimierungen der Query oder eine Indexierung der Tabellen.

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 mit dem Qualitätsmanagementmodul verfügen.
Schema verstehen: Machen Sie sich mit den wichtigsten Oracle-Quality-Tabellen vertraut. Die Query verwendet hauptsächlich QA_RESULTS für die Kopfdaten der Qualitätsereignisse, QA_PLANS für die Plandefinitionen, QA_RESULTS_V als kombinierte Ansicht der Ergebnisse und ihrer Werte sowie Anwendungstabellen für Benutzer wie FND_USER oder PER_ALL_PEOPLE_F.
Query-Parameter festlegen: Suchen Sie vor der Ausführung der Query die Platzhalter in der WHERE-Klausel. Ersetzen Sie :start_date, :end_date und :organization_id durch die passenden Werte für den gewünschten Extraktionsumfang. Setzen Sie beispielsweise :start_date auf '2023-01-01' und :end_date auf '2023-06-30'.
SQL-Query 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 Ergebnisse. Jede Zeile steht für eine einzelne Aktivität im Lebenszyklus eines Qualitätsereignisses. Achten Sie auf Vollständigkeit und darauf, dass wichtige Spalten wie QualityEventId, ActivityName und EventStartTime Daten enthalten.
Timestamps und Dauern berücksichtigen: Die Query liefert EventStartTime. EventEndTime bleibt absichtlich NULL, da sich die Endzeit eines Ereignisses oft erst anhand der Startzeit des nächsten Ereignisses bestimmen lässt. Diese Berechnung erfolgt am besten im Process-Mining-Tool oder in einem Skript zur Nachbearbeitung. Auch ProcessingTime ist auf NULL gesetzt, da der Wert anhand der Start- und Endzeiten berechnet werden muss.
Als CSV exportieren: Exportieren Sie das vollständige Ergebnis aus Ihrem SQL-Client in eine CSV-Datei. Verwenden Sie UTF-8-Kodierung und fügen Sie eine Kopfzeile mit den Spaltenaliasen aus der Query ein.
Upload vorbereiten: Prüfen Sie, ob die Spaltenüberschriften der CSV-Datei 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 Query 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 Query-Filter: Die Query enthält wichtige Platzhalter, die konfiguriert werden müssen:
- :start_date: Beginn des Berichtszeitraums. Die Query filtert Ereignisse, die an oder nach diesem Datum erstellt wurden.
- :end_date: Ende des Berichtszeitraums.
- :organization_id: Die Oracle-Organisationskennung, 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 3 bis 6 Monaten. Bei großen Systemen mit hohem Datenvolumen sollten Sie zunächst einen kürzeren Zeitraum, etwa einen Monat, wählen. So können Sie die Leistung der Query prüfen, bevor Sie einen größeren Datenbestand extrahieren.
Leistungsaspekte: Diese Query verknüpft mehrere große Tabellen und führt 14 separate Ergebnismengen zusammen. Sie kann daher viele Ressourcen beanspruchen. Planen Sie die Extraktion außerhalb der Spitzenzeiten, um die Systemleistung möglichst wenig zu beeinträchtigen. Bei schlechter Leistung sollten Sie mit der Datenbankadministration über die Indexierung wichtiger Spalten sprechen, insbesondere von Datums- und Fremdschlüsselspalten.

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 neuer auf Ihrem System installiert ist. Installieren Sie die erforderlichen Bibliotheken mit pip: pip install pandas oracledb. Sie benötigen diese Bibliotheken für die Verbindung zur Oracle-Datenbank und die Datenverarbeitung.
Datenbankzugangsdaten beschaffen: Halten Sie die erforderlichen Verbindungsdaten für Ihre Oracle-Qualitätsmanagementdatenbank bereit. Dazu gehören Benutzername, Passwort und der Data Source Name (DSN), der üblicherweise dem Format hostname:port/service_name entspricht.
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. Suchen Sie den Konfigurationsabschnitt am Anfang und ersetzen Sie die Platzhalterwerte für db_user, db_password, db_dsn, start_date und end_date durch Ihre Angaben.
SQL-Platzhalter anpassen: Prüfen Sie die SQL-Query im Skript. Möglicherweise müssen Sie Tabellennamen wie QA_RESULTS oder bestimmte Statuswerte wie 'NEW' und 'CLOSED' an Ihre Oracle-Konfiguration anpassen. Fragen Sie bei Unsicherheit Ihre Oracle-Systemadministration.
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 den Befehl python extract_quality_events.py aus.
Ausführung überwachen: Das Skript stellt eine Verbindung zur Datenbank her, führt die Query 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 die Datei quality_event_log.csv im selben Verzeichnis erstellt. Sie enthält das extrahierte Event Log.
Event Log prüfen: Öffnen Sie die Datei quality_event_log.csv in einer Tabellenkalkulation, um sie kurz zu prüfen. Kontrollieren Sie, ob die erwarteten Spalten vorhanden sind und die Daten für einige Beispiel-Cases korrekt ausgefüllt sind.
In das Process-Mining-Tool hochladen: Die erstellte 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, zum Beispiel QA_RESULTS, QA_PLANS, FND_USER und PER_ALL_PEOPLE_F.
Filter für den Datumsbereich: Mit den Variablen start_date und end_date im Skript steuern Sie das Datenvolumen. Beginnen Sie am besten mit einem kürzeren Zeitraum von beispielsweise 3 bis 6 Monaten. So können Sie die Leistung prüfen und die Ergebnisse validieren, bevor Sie einen größeren Datenbestand extrahieren.
Systemabhängige Filter: Sie können die SQL-Query an Ihre Organisationsstruktur anpassen. Ergänzen Sie zum Beispiel eine WHERE-Klausel für ORGANIZATION_ID, um die Extraktion auf ein bestimmtes Werk oder eine Geschäftseinheit zu begrenzen.
Zuordnung von Statuscodes: Die Logik zur Extraktion der Aktivitäten ordnet bestimmte Statuswerte wie 'NEW', 'UNDER_INVESTIGATION' und 'CLOSED' den Prozessschritten zu. Diese Werte hängen stark von Ihrer Oracle-Konfiguration ab. Prüfen und korrigieren Sie sie bei Bedarf in der SQL-Query.
Python-Abhängigkeiten: Das Skript benötigt die Bibliotheken pandas und oracledb. Stellen Sie sicher, dass beide in der Python-Umgebung installiert sind, in der Sie das Skript ausführen.

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 loslegen?

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, Effizienz und Compliance zu verbessern.

Zurück zum Leitfaden zur Prozessverbesserung

Template herunterladen

Optimieren Sie das Oracle-Qualitätsmanagement und stärken Sie jetzt Ihre Compliance

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

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. 14 Tage kostenlos testen.

Ihr Daten-Template für das Qualitätsmanagement

Ihr Daten-Template für das Qualitätsmanagement

Attribute des Qualitätsmanagements

Aktivitäten im Qualitätsmanagement

Anleitungen zur Datenextraktion

Oracle-BI-Publisher-Bericht für Qualitätsereignisdaten

Schritte

Konfiguration

Beispielabfrage sql

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

Schritte

Konfiguration

Beispielabfrage sql

Python-Extraktionsskript mit Oracle-DB-Connector

Schritte

Konfiguration

Beispielabfrage python

Möchten Sie loslegen?

Optimieren Sie das Oracle-Qualitätsmanagement und stärken Sie jetzt Ihre Compliance