> Amélioration continue des processus > Gestion de la qualité > Gestion de la qualité dans Oracle > Modèle de données

Votre modèle de données pour la gestion de la qualité

Gestion de la qualité dans Oracle

Attributs de gestion de la qualité(20) Activités de gestion de la qualité(14) Guides d’extraction(3)

Votre modèle de données pour la gestion de la qualité

Ce modèle présente les attributs de données et les activités de processus essentiels à une analyse efficace de la gestion de la qualité. Il explique également comment extraire ces informations de votre système Oracle Quality Management. Utilisez cette ressource pour recueillir toutes les données nécessaires à des analyses détaillées et à l’optimisation de vos processus.

Attributs recommandés à recueillir
Activités clés à suivre
Guide d’extraction

Vous découvrez les journaux d’événements ? Découvrez comment créer un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs de gestion de la qualité

Voici les champs de données et les informations contextuelles recommandés pour votre journal d’événements, afin de mener une analyse complète de la gestion de la qualité.

3 Obligatoire 7 Recommandé 10 Facultatif

	Nom	Description
	Événement qualité QualityEventId	Identifiant unique d’un événement qualité, par exemple une non-conformité, une réclamation ou un écart.
Description L’identifiant de l’événement qualité sert d’identifiant de cas principal et regroupe toutes les activités associées, du signalement initial à la clôture. Chaque incident qualité reçoit un identifiant unique, ce qui permet de conserver un historique complet de l’enquête et de la résolution. Dans une analyse de Process Mining, cet attribut est essentiel pour reconstituer le parcours complet de chaque événement qualité. Il permet de calculer les temps de cycle globaux, de repérer les variantes du processus et d’analyser le traitement des différents types d’événements. En reliant chaque journal d’activité à un identifiant d’événement qualité précis, les analystes peuvent visualiser l’ensemble du flux de processus et repérer les goulots d’étranglement systémiques ou les problèmes de conformité. Pourquoi est-ce important ? Cet identifiant définit le périmètre d’un cas unique. Il permet de suivre précisément les événements qualité et de calculer les indicateurs de performance de bout en bout. Où trouver ces données Il s’agit généralement de la clé primaire des principales tables d’événements qualité ou de plans de collecte dans Oracle Quality Management, comme QA_RESULTS. Exemples NC-2023-00123CAPA-45892QE-500-A
	Heure de début de l’événement EventStartTime	Horodatage indiquant le début d’une activité ou d’un événement.
Description Cet attribut indique la date et l’heure précises du début d’une étape du processus. Il sert principalement à ordonner chronologiquement les événements et à reconstituer la séquence du processus pour chaque cas d’événement qualité. Dans l’analyse, l’heure de début de l’événement est essentielle au calcul des temps de cycle, des durées et des temps d’attente entre les activités. Elle permet de repérer les goulots d’étranglement en mettant en évidence les longs délais entre deux étapes successives et de suivre les résultats par rapport aux indicateurs temporels, comme le délai d’analyse de la cause racine. Pourquoi est-ce important ? Cet horodatage est au cœur de l’analyse du processus : il permet d’effectuer tous les calculs temporels et d’ordonner correctement les activités. Où trouver ces données Cet horodatage se trouve généralement dans les journaux de transactions ou les tables d’historique associés aux actions qualité et aux plans de collecte. Le champ porte souvent le nom CREATION_DATE ou un nom similaire. Exemples 2023-04-15T09:00:12Z2023-04-16T11:30:00Z2023-05-01T14:22:45Z
	Nom de l’activité ActivityName	Nom de la tâche ou de l’étape précise réalisée dans le processus de gestion de la qualité.
Description Cet attribut décrit un événement ou une action réalisée dans le cadre de la gestion d’un événement qualité. La séquence de ces activités, ordonnées selon leurs horodatages, constitue le flux de processus de chaque cas. L’analyse du nom de l’activité est au cœur du Process Mining. Elle permet de découvrir le modèle de processus réel, de le comparer au modèle attendu pour vérifier la conformité et de repérer les goulots d’étranglement ou les boucles de reprise entre certaines activités. Elle permet, par exemple, de mesurer le temps écoulé entre « Investigation Initiated » et « Root Cause Analysis Performed ». Pourquoi est-ce important ? Cet attribut est essentiel pour représenter le flux de processus, repérer les écarts et comprendre comment le travail est réellement effectué. Où trouver ces données Ces informations proviennent généralement des journaux d’événements, des enregistrements de changements de statut ou des tables d’historique des actions du module Oracle Quality Management. Exemples Problème qualité identifiéEnquête lancéePlan d’action corrective approuvéExamen final et clôture
	Catégorie de la cause profonde RootCauseCategory	La classification de la cause profonde identifiée pour le problème qualité.
Description Après l’analyse des causes profondes, les conclusions sont souvent classées dans des catégories prédéfinies, comme « Défaillance d’équipement », « Erreur humaine » ou « Défaut de conception ». Cet attribut enregistre la classification finale. L’analyse du processus par catégorie de cause profonde est particulièrement utile. Elle permet de dépasser la correction des symptômes individuels pour s’attaquer aux problèmes systémiques sous-jacents. Par exemple, un nombre élevé d’événements attribués à un « problème de formation » peut montrer qu’il faut améliorer les programmes de formation du personnel, un objectif important des actions préventives. Pourquoi est-ce important ? Cet attribut aide à passer d’une gestion réactive à une gestion préventive de la qualité, en permettant d’analyser les causes fondamentales des défaillances. Où trouver ces données Consultez la documentation Oracle Quality Management. Il s’agit probablement d’un élément défini par l’utilisateur dans un plan de collecte, renseigné après l’activité « Analyse des causes profondes effectuée ». Exemples Dysfonctionnement de l’équipementDéfaut de matériauErreur humaineProcédure non respectée
	Date cible de résolution TargetResolutionDate	La date prévue ou attendue pour la clôture définitive de l’événement qualité.
Description Cet attribut indique la date limite à laquelle l’événement qualité doit être entièrement résolu. Il correspond à un accord de niveau de service (SLA) ou à un objectif interne, souvent défini en fonction de la gravité ou du type d’événement. Cette date est essentielle au suivi des performances et intervient directement dans le calcul de l’indicateur « CAPA Impl. On-Time Rate ». En comparant les dates réelles de fin des activités à cette échéance, les analystes peuvent mesurer le respect des délais, repérer les événements susceptibles d’être traités en retard et suivre l’évolution des résultats dans les délais. Ces analyses contribuent à réduire les temps de cycle de résolution. Pourquoi est-ce important ? Cette date sert de référence pour mesurer le respect des délais. Elle est indispensable au calcul des indicateurs de ponctualité et au suivi des SLA. Où trouver ces données Consultez la documentation Oracle Quality Management. Il peut s’agir d’un champ de date standard ou d’un élément défini par l’utilisateur dans le plan de collecte qualité. Exemples 2023-05-302023-06-152024-01-10
	Heure de fin de l’événement EventEndTime	Horodatage indiquant la fin d’une activité ou d’un événement.
Description L’heure de fin de l’événement marque la fin d’une activité précise. Associée à l’heure de début de l’événement, elle permet de calculer la durée de traitement de cette activité. Dans certains systèmes, une activité peut être instantanée : ses heures de début et de fin sont alors identiques. Cet attribut est essentiel pour analyser les durées en détail. Il permet de distinguer le temps de traitement actif, entre le début et la fin, du temps d’attente, entre la fin d’une activité et le début de la suivante. Cette distinction aide à repérer les étapes qui mobilisent activement des ressources et les transferts qui entraînent des retards. Pourquoi est-ce important ? Il permet de calculer précisément les durées de traitement des activités et de distinguer les tâches inefficaces des longues périodes d’attente. Où trouver ces données Cette information peut se trouver dans les mêmes tables de transactions ou d’historique que l’heure de début, parfois sous le nom LAST_UPDATE_DATE ou sous la forme d’un horodatage de fin spécifique. Elle peut aussi être déduite de l’heure de début de l’événement suivant. Exemples 2023-04-15T09:15:30Z2023-04-16T12:00:00Z2023-05-02T10:00:00Z
	Niveau de gravité SeverityLevel	Classification de l’impact de l’événement qualité, par exemple critique, majeur ou mineur.
Description Le niveau de gravité correspond à une évaluation, généralement réalisée lors de l’évaluation initiale, de l’impact potentiel du problème qualité sur les clients, la conformité ou les opérations. Cette classification aide à prioriser les ressources et à déterminer le degré d’urgence de la réponse nécessaire. Dans le Process Mining, cet attribut est essentiel pour segmenter l’analyse. Les analystes peuvent comparer les flux de processus, les temps de cycle et les résultats des événements de gravité élevée et faible. Il alimente le Dashboard « Quality Event Triage Consistency » et l’indicateur « Severity-Based Resolution Rate », qui permettent de vérifier si les problèmes critiques sont effectivement traités plus rapidement et efficacement. Pourquoi est-ce important ? Il permet de prioriser et de segmenter l’analyse afin que les événements qualité à fort impact soient traités efficacement. Où trouver ces données Consultez la documentation Oracle Quality Management. Il s’agit souvent d’un élément configurable dans un plan de collecte qualité. Exemples 1 - Critique2 - Majeur3 - Mineur4 - À titre informatif
	Service responsable ResponsibleDepartment	Service ou domaine fonctionnel responsable de l’événement qualité ou de l’activité en cours.
Description Cet attribut identifie l’équipe ou le service chargé de traiter l’événement qualité. Il peut s’agir de l’assurance qualité, de l’ingénierie, de la production ou d’un autre groupe. Le service responsable peut changer au fil du cycle de vie de l’événement. Dans le Process Mining, l’analyse par service responsable permet de comprendre la répartition de la charge de travail, de repérer les goulots d’étranglement au sein des services et de comparer les résultats des différentes équipes. Elle alimente le Dashboard « Quality Event Resource Allocation » en montrant quels services interviennent dans quels types d’activités, afin d’aider à mieux gérer les ressources. Pourquoi est-ce important ? Il permet d’analyser la charge de travail, les résultats et les goulots d’étranglement par service, ce qui aide à planifier les ressources et à améliorer l’organisation. Où trouver ces données Consultez la documentation Oracle Quality Management. Ces informations peuvent être stockées dans des tables liées aux actions qualité ou aux affectations, associées à l’événement qualité. Exemples Ingénierie qualitéOpérations de fabricationQualité fournisseursIngénierie de conception
	Statut actuel CurrentStatus	Statut actuel du cas d’événement qualité.
Description Cet attribut indique l’état actuel de l’événement qualité dans son cycle de vie, par exemple « Open », « Under Investigation », « Pending Approval » ou « Closed ». Il donne un aperçu de l’étape à laquelle se trouve le cas au moment de l’extraction des données. Cet attribut est essentiel au suivi opérationnel et alimente directement le Dashboard « Open Quality Events & Status Overview ». Il permet aux responsables de voir rapidement les problèmes qualité en cours et de prioriser les ressources. Dans le Process Mining, le filtrage par statut final permet d’analyser les résultats des différents parcours du processus. Pourquoi est-ce important ? Il donne une vue en temps réel des événements qualité en cours et facilite la gestion opérationnelle ainsi que la priorisation des cas actifs. Où trouver ces données Ces informations figurent généralement dans la table d’en-tête principale des événements qualité et reflètent leur dernier état connu. Exemples OuvertEn coursEn attente d’approbationClôturé
	Utilisateur affecté AssignedUser	Utilisateur chargé d’effectuer une activité ou responsable de l’événement qualité.
Description Cet attribut indique la personne responsable d’une tâche précise ou de la gestion globale de l’événement qualité. Il fournit un niveau de détail plus fin que le service responsable. L’analyse par utilisateur aide à comprendre la charge de travail de chacun, à repérer les besoins de formation et à reconnaître les personnes les plus performantes. Elle peut aussi révéler des tendances, comme la réaffectation répétée du travail ou le blocage de tâches chez certaines personnes. Ce niveau de détail est utile à la gestion des performances et à l’optimisation des ressources. Pourquoi est-ce important ? Il permet d’analyser en détail la charge de travail et les résultats de chaque personne, afin de repérer les contraintes de ressources ou les besoins de formation. Où trouver ces données Consultez la documentation Oracle Quality Management. Les informations sur les affectations d’utilisateurs sont généralement stockées dans les tables d’actions ou de flux de travail associées à l’événement qualité. Exemples j.smitha.jonesr.williams
	Avec reprises IsRework	Un indicateur précisant si une activité correspond à la répétition ou à la reprise d’une étape précédente du même dossier.
Description Cet attribut booléen prend la valeur vrai lorsqu’une activité précise, comme « Proposition d’un plan d’actions correctives », se produit plusieurs fois dans un même dossier d’événement qualité. Cela signale une boucle ou une correction dans le processus : une étape déjà réalisée a dû être répétée. Le repérage des reprises est une fonction clé du Process Mining. Cet indicateur facilite la quantification de ces inefficacités et contribue directement au calcul de la métrique « Fréquence des reprises d’activité ». L’analyse des étapes les plus souvent reprises et des circonstances associées peut révéler des problèmes de formation, de qualité des données ou de critères d’approbation, et mettre en évidence des possibilités d’améliorer le processus. Pourquoi est-ce important ? Il signale les inefficacités et les boucles du processus, ce qui aide à quantifier les pertes et à repérer les causes profondes des reprises. Où trouver ces données Cette valeur est calculée à l’aide de fonctions de fenêtre ou d’une analyse séquentielle du journal d’événements lors de la préparation des données. Elle permet de repérer les cas où le nom d’une même activité apparaît plusieurs fois pour un même dossier. Exemples truefalse
	Catégorie du problème IssueCategory	La catégorie ou le type du problème qualité, par exemple « Défaut de produit » ou « Écart de processus ».
Description Cet attribut classe l’événement qualité et permet de regrouper les problèmes similaires pour les analyser. Les catégories sont généralement définies par l’organisation en fonction de son contexte opérationnel. L’analyse du processus par catégorie de problème permet de repérer des tendances propres à certains types de problèmes. Elle peut, par exemple, révéler que les problèmes liés aux « matériaux du fournisseur » ont un temps de cycle bien plus long que ceux associés aux « processus internes ». Cette segmentation aide à cibler les initiatives d’amélioration des processus. Pourquoi est-ce important ? La catégorisation des problèmes permet de cibler les analyses afin de repérer les tendances et les causes profondes dans des domaines précis. Où trouver ces données Consultez la documentation Oracle Quality Management. Il s’agit probablement d’un élément défini par l’utilisateur dans le plan de collecte qualité. Exemples Défaut de produitÉcart de processusMatériaux du fournisseurRéclamation client
	Code de clôture ClosureCode	Un code indiquant le motif ou le résultat de la clôture de l’événement qualité.
Description À la clôture d’un événement qualité, un code est souvent attribué pour classer le résultat final. Il peut s’agir, par exemple, de « Action efficace », « Aucune action requise » ou « Problème en double ». Cet attribut est très utile pour l’analyse des résultats. En filtrant les différents codes de clôture, les analystes peuvent étudier les parcours du processus qui aboutissent à un résultat satisfaisant et ceux qui n’y parviennent pas. Ils peuvent ainsi répondre à des questions comme « À quoi ressemble le processus pour les problèmes clôturés comme doublons ? » et repérer les inefficacités du processus de triage. Pourquoi est-ce important ? Il renseigne sur le résultat d’un dossier et permet d’analyser les parcours du processus qui mènent à une résolution satisfaisante. Où trouver ces données Consultez la documentation Oracle Quality Management. Ce champ est probablement renseigné lors de l’activité finale de clôture. Exemples EFFECTIVENO_ACTIONDUPLICATERISK_ACCEPTED
	Dans les délais IsOnTime	Un indicateur précisant si une action corrective a été mise en œuvre avant la date cible de résolution.
Description Cet attribut booléen est calculé en comparant l’horodatage de fin de l’activité « Action corrective mise en œuvre » à la « Date cible de résolution » du dossier. Il vaut vrai si l’action a été terminée à la date cible ou avant, et faux dans le cas contraire. Cet attribut contribue directement au calcul de l’indicateur « CAPA Impl. On-Time Rate ». Il simplifie l’analyse et la création de Dashboards en fournissant une classification claire, binaire, du respect des délais pour chaque dossier. Il facilite le filtrage et l’agrégation des données afin de suivre le respect des niveaux de service et de repérer les causes profondes des retards. Pourquoi est-ce important ? Il simplifie le suivi du respect des échéances et facilite la mesure et la communication des résultats pour cet indicateur clé. Où trouver ces données Cet indicateur est calculé lors de la transformation des données. Il nécessite la TargetResolutionDate et l’horodatage de l’activité de fin concernée. Exemples truefalse
	Dernière mise à jour des données LastDataUpdate	Horodatage de la dernière actualisation ou mise à jour des données provenant du système source.
Description Cet attribut indique la dernière mise à jour des données de cet événement dans le jeu de données de Process Mining. Il renseigne sur leur fraîcheur et aide les utilisateurs à évaluer l’actualité de l’analyse. Dans les Dashboards et les rapports, cet horodatage apporte un contexte essentiel. Il précise si les données consultées sont en temps réel ou correspondent à un instantané pris à une date donnée, ce qui est indispensable pour prendre des décisions opérationnelles éclairées. Il garantit la transparence sur l’actualité des données. Pourquoi est-ce important ? Cet horodatage indique la fraîcheur des données et permet aux utilisateurs de savoir si l’analyse du processus est à jour. Où trouver ces données Cette valeur est générée et enregistrée lors du processus ETL des données. Elle correspond généralement à l’horodatage de la dernière exécution réussie du pipeline de données. Exemples 2023-10-27T04:00:00Z2023-10-26T04:00:00Z
	Identifiant du plan d’actions correctives CorrectiveActionPlanId	L’identifiant unique du plan d’actions correctives (CAPA) créé pour traiter l’événement qualité.
Description Cet attribut établit un lien direct entre un événement qualité et le plan d’actions correctives et préventives (CAPA) conçu pour le résoudre. Ce plan est souvent un objet distinct dans le système, doté de son propre cycle de vie. Lors de l’analyse, cet identifiant permet de rapprocher les données du processus de gestion des événements qualité de celles du processus de gestion des CAPA, pour obtenir une vue d’ensemble plus complète. Il aide à vérifier que chaque événement nécessitant une CAPA en a bien une d’attribuée et à analyser l’efficacité des actions menées. Pourquoi est-ce important ? Il relie le problème (l’événement qualité) à la solution (la CAPA), ce qui permet d’analyser plus complètement le système de gestion de la qualité de bout en bout. Où trouver ces données Il s’agit d’un champ de référence dans l’enregistrement de l’événement qualité, qui pointe vers un enregistrement dans une table ou un module dédié aux CAPA. Exemples CAPA-2023-088CAPA-2023-091
	Identifiant du produit ProductIdentifier	L’identifiant du produit associé à l’événement qualité.
Description Cet attribut associe l’événement qualité à un produit, un matériau ou un service précis. Il peut s’agir d’un code produit, d’une référence SKU ou d’un numéro de pièce. Cette association est essentielle à l’analyse de la qualité des produits. Le Process Mining permet de comparer les processus de gestion de la qualité entre différentes gammes de produits ou de repérer ceux qui sont fréquemment associés à des problèmes qualité. Vous pouvez ainsi prioriser les améliorations techniques ou de fabrication là où elles sont le plus nécessaires. Pourquoi est-ce important ? Cet attribut relie les événements qualité à des produits précis, ce qui permet d’analyser les tendances de qualité par produit et les variations des processus. Où trouver ces données Cette information est stockée dans un champ du plan de collecte qualité, souvent associé à la fiche article d’Oracle Inventory. Exemples SKU-100-A-REDPN-987654CHEM-X2
	Système source SourceSystem	Indique le système de référence dont les données ont été extraites.
Description Cet attribut précise l’application ou le système d’origine des données d’événement. Dans une entreprise, celles-ci peuvent provenir de plusieurs sources, comme le module Oracle Quality principal, un système CAPA distinct ou un portail de réclamations clients. Ce champ aide à comprendre la provenance des données et permet de segmenter le processus selon le système d’origine. Il est important pour la gouvernance des données et le diagnostic des problèmes d’intégration, afin que la vue du processus reflète fidèlement les données combinées. Pourquoi est-ce important ? Il apporte un contexte essentiel sur l’origine des données, utile à leur validation et à leur gouvernance, ainsi qu’à l’analyse des variations du processus entre les systèmes. Où trouver ces données Il s’agit généralement d’une valeur statique ajoutée lors du processus d’extraction, de transformation et de chargement des données (ETL) pour indiquer l’origine du jeu de données. Exemples Oracle Quality Management R12Oracle EBS QualityQM-PROD
	Temps de cycle total TotalCycleTime	Le temps total écoulé entre l’identification d’un problème qualité et sa clôture définitive.
Description Cet attribut mesure la durée totale de bout en bout d’un dossier lié à un événement qualité. Il correspond à la différence entre l’horodatage de la toute première activité (« Problème qualité identifié ») et celui de la toute dernière (« Examen final et clôture »). Il s’agit d’un indicateur clé de performance (KPI) de l’efficacité globale du processus de gestion de la qualité. C’est la principale métrique du Dashboard « Temps de cycle de bout en bout des événements qualité ». Le suivi de cette métrique dans le temps et sa segmentation selon des attributs comme la gravité ou la catégorie du problème donnent une vue d’ensemble de la santé du processus et des effets des initiatives d’amélioration. Pourquoi est-ce important ? Cet indicateur clé mesure la rapidité et l’efficacité globales du processus de gestion de la qualité, du début à la fin. Où trouver ces données Cette valeur est calculée au niveau du dossier lors du traitement des données pour le Process Mining. Le calcul nécessite l’heure de début du premier événement et l’heure de fin du dernier événement pour chaque QualityEventId. Exemples P30DT12HP15DP92D
	Unité opérationnelle BusinessUnit	L’unité opérationnelle ou la division de l’organisation où l’événement qualité s’est produit ou est pris en charge.
Description Cet attribut rattache l’événement qualité à une partie précise de la structure de l’entreprise. Il permet d’analyser et de comparer les performances qualité entre différentes unités organisationnelles. Dans les grandes entreprises, il est courant de segmenter l’analyse des processus par unité opérationnelle. Cela permet de créer des Dashboards propres à chaque unité et de repérer les divisions dont les processus qualité sont plus efficaces ou qui rencontrent des difficultés particulières. Ces analyses sont utiles au pilotage de l’entreprise et au partage des bonnes pratiques entre ses différentes entités. Pourquoi est-ce important ? Il permet de comparer les performances et d’analyser les différentes entités de l’organisation, au service d’une gestion de la qualité à l’échelle de l’entreprise. Où trouver ces données Cette information fait généralement partie des données de contexte organisationnel associées à la transaction. Elle provient souvent des données de référence de l’utilisateur ou du service. Exemples Dispositifs médicauxÉlectronique grand publicPièces automobiles

Obligatoire Recommandé Facultatif

Activités de gestion de la qualité

Voici les principales étapes du processus et les jalons importants à enregistrer dans votre journal d’événements pour découvrir le processus avec précision et évaluer ses performances.

6 Recommandé 8 Facultatif

	Activité	Description
	Efficacité de l’action vérifiée	Cette activité confirme que l’action corrective mise en œuvre a bien résolu la cause racine et empêché la réapparition du problème. Elle est enregistrée lorsqu’un utilisateur termine la vérification et met à jour le statut de l’enregistrement.
Pourquoi est-ce important ? Cette étape, fondée sur le résultat, est importante et sert de base à l’indicateur « Effectiveness Verif. Rate ». Elle clôt le cycle de l’action corrective et confirme que le problème est réellement résolu. Où trouver ces données Déduite du passage de l’enregistrement CAPA au statut « Verification Complete » ou « Effective ». Il peut également être nécessaire de renseigner des champs spécifiques sur les résultats de la vérification. Données à recueillir Déduite du passage au statut « Verification Complete » ou « Effective ». Type d’événement inferred
	Enquête lancée	Cette activité marque le début officiel de l’enquête visant à déterminer la cause racine du problème qualité. Elle correspond généralement à un changement de statut dans le système, par exemple le passage à « Under Investigation ».
Pourquoi est-ce important ? Cette étape sert de point de départ au calcul de l’indicateur « Root Cause Analysis Lead Time » et permet de mesurer le temps d’attente avant le lancement officiel d’une enquête. Où trouver ces données Déduite du passage de l’enregistrement Quality Issue ou d’un enregistrement Quality Action associé au statut « Investigation ». L’horodatage de ce changement de statut indique l’heure de l’événement. Données à recueillir Déduite du passage au statut « Under Investigation » ou à un état similaire. Type d’événement inferred
	Examen final et clôture	Cette dernière étape confirme que toutes les actions associées sont terminées et que le problème qualité parent est officiellement clôturé. Elle est enregistrée lors du passage final de l’enregistrement principal au statut « Closed » ou « Resolved ».
Pourquoi est-ce important ? Il s’agit de l’événement de fin principal du processus. Il est essentiel pour calculer l’indicateur « Average Event Cycle Time » et mesurer le débit global du processus. Où trouver ces données Déduite du passage final de l’enregistrement Quality Issue parent au statut « Closed ». L’horodatage de ce changement indique l’heure de l’événement. Données à recueillir Déduite du passage de l’enregistrement Quality Issue principal au statut « Closed ». Type d’événement inferred
	Plan d’action corrective approuvé	Cette activité correspond à l’approbation officielle du plan d’action corrective proposé par une autorité désignée. Il s’agit d’un point de contrôle important, généralement enregistré par une action d’approbation explicite ou par le passage au statut « Approved ».
Pourquoi est-ce important ? Cette approbation constitue une étape importante et représente souvent un goulot d’étranglement. L’analyse des délais d’approbation aide à optimiser le processus et à garantir le respect des procédures. Où trouver ces données Déduite du passage de l’enregistrement Quality Action ou CAPA au statut « Approved ». Dans les systèmes Oracle dotés de flux de travail d’approbation, ce changement est souvent consigné explicitement dans les tables d’audit. Données à recueillir Déduite du passage au statut « Approved ». Type d’événement inferred
	Problème catégorisé et priorisé	Cette activité a lieu lorsqu’un analyste termine l’évaluation initiale et attribue les principaux attributs, comme la gravité, la priorité et le type de problème. Elle est généralement enregistrée lorsque le statut passe de « New » à « Assessed » ou « In Triage ».
Pourquoi est-ce important ? Cette étape est essentielle pour l’indicateur « Avg Triage Processing Time ». Tout retard à ce stade peut ralentir l’ensemble du processus de résolution, en particulier pour les problèmes critiques. Où trouver ces données Déduite d’un changement de statut de l’enregistrement Quality Issue, par exemple de « New » à « Under Assessment », ou du premier renseignement de champs tels que « Severity » ou « Priority ». Données à recueillir Déduite d’un changement de statut ou du premier renseignement des champs Severity ou Priority. Type d’événement inferred
	Problème qualité identifié	Cette activité correspond à la création d’un nouvel enregistrement d’événement qualité, par exemple une non-conformité, un écart ou une réclamation client. Elle est enregistrée explicitement lorsqu’un utilisateur crée un nouvel enregistrement Quality Issue ou Quality Action dans Oracle.
Pourquoi est-ce important ? En tant qu’événement de début, elle est essentielle pour calculer le temps de cycle total du processus de gestion de la qualité et comprendre le volume d’événements qualité entrants. Où trouver ces données Cet événement est extrait de l’horodatage de création de l’enregistrement Quality Issue ou Quality Action, probablement dans des tables telles que QAM_QUALITY_ISSUES ou QAM_QUALITY_ACTIONS. Données à recueillir Événement enregistré lors de la création d’un nouvel enregistrement Quality Issue ou Action. Type d’événement explicit
	Action corrective mise en œuvre	Cette activité marque la fin des tâches prévues dans le plan d’action corrective approuvé. Elle est généralement enregistrée lorsqu’un utilisateur fait passer l’enregistrement de l’action corrective au statut « Implemented » ou « Completed ».
Pourquoi est-ce important ? Cette activité est essentielle pour l’indicateur « CAPA Impl. On-Time Rate » : elle confirme que la mesure prévue a été mise en œuvre et permet de comparer la date de réalisation à la date cible. Où trouver ces données Cet événement est déduit du passage de l’enregistrement Quality Action ou CAPA associé au statut « Implemented » ou « Completed ». Données à recueillir Déduite du passage au statut « Implemented » ou « Completed ». Type d’événement inferred
	Action préventive identifiée	Cette activité correspond à la création d’une action préventive (PA) visant à traiter les problèmes systémiques et à éviter que des événements qualité similaires ne se reproduisent. Elle est souvent consignée lors de la création d’un nouvel enregistrement Preventive Action associé au problème initial.
Pourquoi est-ce important ? Cette activité témoigne d’un processus qualité mature, qui ne se limite pas à corriger des problèmes isolés et vise aussi à prévenir leur réapparition. Son suivi permet de mesurer les améliorations proactives de la qualité. Où trouver ces données Enregistrée lors de la création d’un nouvel enregistrement Quality Action de type « Preventive Action », souvent associé au Quality Issue ou au Corrective Action d’origine. Données à recueillir Consignée lors de la création d’un enregistrement Quality Action de type « Preventive Action ». Type d’événement explicit
	Action préventive mise en œuvre	Cette activité marque la fin des tâches définies dans le plan d’action préventive pour réduire les risques systémiques. Elle est enregistrée lorsqu’un utilisateur fait passer l’enregistrement de l’action préventive au statut « Implemented » ou « Completed ».
Pourquoi est-ce important ? Cette activité mesure la capacité de l’organisation à mettre en œuvre des améliorations proactives de la qualité. Les retards peuvent révéler des difficultés à appliquer des changements systémiques dans l’ensemble de l’organisation. Où trouver ces données Déduite du passage de l’enregistrement Preventive Action associé au statut « Implemented » ou « Completed », comme pour le suivi des actions correctives. Données à recueillir Déduite du passage d’un enregistrement Preventive Action au statut « Implemented ». Type d’événement inferred
	Analyse de la cause racine effectuée	Cette activité correspond à la fin de l’analyse de la cause racine (RCA) et à la consignation des conclusions. Elle est généralement enregistrée lorsque l’équipe d’enquête met à jour le problème qualité avec la cause racine identifiée et modifie son statut.
Pourquoi est-ce important ? Cette activité marque la fin de l’indicateur « Root Cause Analysis Lead Time ». L’analyse du délai avant cette étape permet de repérer les goulots d’étranglement dans la résolution du problème. Où trouver ces données Déduite du passage au statut « RCA Complete » ou du renseignement du champ de catégorie de cause racine suivi de l’enregistrement de la fiche. L’horodatage de cette mise à jour est utilisé. Données à recueillir Déduite du passage au statut « RCA Complete » ou du renseignement des champs de cause racine. Type d’événement inferred
	Parties prenantes informées de la résolution	Cette activité correspond à la communication de la résolution de l’événement qualité aux personnes concernées, par exemple à son déclarant ou aux clients touchés. Elle est difficile à enregistrer et peut être déduite d’un changement de statut après la clôture ou d’un commentaire consigné.
Pourquoi est-ce important ? Cette activité est essentielle pour l’indicateur « Stakeholder Notification Lag ». Une communication rapide contribue à la satisfaction des clients et à la transparence interne, même après la résolution du problème. Où trouver ces données Cette activité est souvent difficile à enregistrer automatiquement. Elle peut être déduite d’un statut tel que « Notification Sent » ou d’une entrée dans un champ d’activité ou de commentaires, ce qui nécessite une logique d’extraction spécifique. Données à recueillir Déduite d’un changement de statut spécifique ou, éventuellement, de l’analyse textuelle des journaux d’activité. Type d’événement inferred
	Plan d’action corrective proposé	Cette activité a lieu lorsque les actions correctives sont définies et associées au problème qualité afin de préciser les mesures à prendre pour le résoudre. Elle peut correspondre à la création d’un enregistrement Corrective Action associé ou à un changement de statut indiquant que le plan est prêt à être examiné.
Pourquoi est-ce important ? Cette activité marque le passage de l’analyse du problème à la conception d’une solution. Les reprises à cette étape, mesurées par les indicateurs correspondants, peuvent révéler des exigences imprécises ou une planification inefficace. Où trouver ces données Il peut s’agir d’un événement explicite, déclenché par la création d’un nouvel enregistrement Corrective Action dans un objet CAPA, ou d’un événement déduit d’un passage au statut « Plan Proposed » ou « Pending Approval ». Données à recueillir Déduite du passage au statut « Pending Approval » ou de la création d’une action corrective associée. Type d’événement inferred
	Problème affecté pour évaluation initiale	Cette activité correspond à l’affectation du problème qualité nouvellement créé à un utilisateur ou à une équipe pour un premier examen et une première évaluation. Elle est souvent déduite du suivi des modifications apportées au champ du responsable ou du propriétaire de l’enregistrement du problème qualité.
Pourquoi est-ce important ? Le suivi de ce premier transfert permet de repérer les retards avant le début de l’évaluation. L’analyse du temps passé dans cet état révèle les éventuels retards dans la file d’évaluation initiale. Où trouver ces données Déduite des modifications du champ du propriétaire ou du responsable dans l’enregistrement Quality Issue. Ces informations peuvent provenir des tables d’audit ou du suivi des changements de statut associés aux flux de travail d’affectation. Données à recueillir Déduite d’une modification du champ « Assigned To » ou « Owner » dans l’enregistrement Quality Issue. Type d’événement inferred
	Vérification de l’efficacité requise	Cette activité indique que le système ou un utilisateur a signalé la nécessité d’effectuer une vérification après la mise en œuvre, afin de s’assurer de l’efficacité de l’action. Il s’agit souvent d’un changement de statut automatique ou manuel intervenant après la mise en œuvre.
Pourquoi est-ce important ? Cette étape lance la phase de vérification. Le délai entre la mise en œuvre et cette activité peut révéler des retards dans le lancement des suivis nécessaires. Où trouver ces données Cet événement est déduit du passage de l’enregistrement Quality Action au statut « Pending Effectiveness Check » ou à un état similaire dans le flux de travail. Données à recueillir Déduite du passage au statut « Pending Effectiveness Check ». Type d’événement inferred

Recommandé Facultatif

Guides d’extraction

Comment extraire vos données d’Oracle Quality Management

Étapes

Accédez à Oracle BI Publisher : Connectez-vous à votre instance Oracle E-Business Suite, puis ouvrez la responsabilité qui donne accès à BI Publisher, par exemple BI Publisher Administrator ou une responsabilité personnalisée équivalente.
Créez un modèle de données : Depuis la page d’accueil de BI Publisher, sélectionnez Create, puis Data Model. L’éditeur de modèle de données s’ouvre.
Définissez un jeu de données à partir d’une requête SQL : Dans l’éditeur de modèle de données, cliquez sur l’icône plus du panneau Data Sets, puis sélectionnez SQL Query. La fenêtre de l’éditeur de requête SQL s’ouvre.
Configurez la source de données : Dans la fenêtre New Data Set, saisissez un nom pour votre jeu de données, par exemple DS_QUALITY_EVENTS. Sélectionnez la base de données Oracle EBS appropriée comme Data Source.
Saisissez la requête SQL : Copiez la requête SQL complète fournie dans la section « query » de ce document et collez-la dans le champ SQL Query.
Définissez les paramètres de la requête : La requête utilise les variables :P_START_DATE et :P_END_DATE pour définir la période du rapport. Dans le modèle de données BI Publisher, vous devez les définir comme paramètres. Pour chacun, créez un paramètre, attribuez-lui le nom correspondant (par exemple, P_START_DATE), définissez le type de données sur Date et rédigez une invite claire pour l’utilisateur.
Enregistrez le modèle de données : Après avoir collé la requête et défini les paramètres, enregistrez le modèle de données. Il est recommandé de le placer dans un dossier partagé destiné aux rapports.
Créez un rapport : Revenez à la page d’accueil de BI Publisher, sélectionnez Create, puis Report. Choisissez l’option Use Data Model et recherchez le modèle de données que vous venez d’enregistrer.
Configurez la mise en page du rapport : L’assistant de création vous guide dans la configuration de la mise en page. Pour ProcessMind, un simple tableau suffit. Faites glisser toutes les colonnes du modèle de données dans la mise en page du rapport. Vérifiez que le format de sortie est défini sur CSV.
Définissez les propriétés du rapport : Dans les propriétés du rapport, vérifiez que l’option Enable CSV Output est cochée. Vous pouvez également définir des valeurs par défaut pour les paramètres, si nécessaire.
Exécutez et exportez le rapport : Enregistrez le rapport, puis exécutez-le en indiquant les dates de début et de fin souhaitées. Une fois le rapport généré, cliquez sur Export et sélectionnez CSV comme format de sortie. Le fichier sera téléchargé sur votre ordinateur.
Préparez l’importation : Ouvrez le fichier CSV téléchargé et vérifiez qu’il contient les données attendues. Assurez-vous que les en-têtes de colonnes correspondent aux exigences du schéma ProcessMind. Le fichier est prêt à être importé.

Configuration

Prérequis : Un compte utilisateur donnant accès à Oracle BI Publisher et un accès en lecture aux tables sous-jacentes du module Quality (par exemple, QA_RESULTS, QA_PLANS, QA_ACTIONS, FND_USER).
Configuration de la source de données : Le modèle de données BI Publisher doit être configuré pour se connecter à la base de données principale de votre application Oracle EBS (schéma APPS).
Paramètres de période : La requête utilise deux paramètres obligatoires, :P_START_DATE et :P_END_DATE, pour filtrer l’extraction. Pour une première analyse, une période de 6 à 12 mois est recommandée afin de recueillir suffisamment de cas complets. Saisissez les dates au format « YYYY-MM-DD ».
Format de sortie : Le rapport doit être configuré pour autoriser une sortie CSV. Ce format convient à l’importation dans ProcessMind : il est simple, structuré et évite les traitements complexes.
Planification : Pour assurer un suivi continu du processus, planifiez l’exécution récurrente du rapport BI Publisher, par exemple chaque jour ou chaque semaine. Configurez la livraison du fichier vers un serveur ou un référentiel de contenu désigné afin qu’il puisse être récupéré automatiquement.
Performances : Dans les instances comportant un très grand nombre d’événements qualité, l’exécution de la requête peut prendre beaucoup de temps. Choisissez une période raisonnable et, si les performances posent problème, demandez à votre administrateur de base de données d’examiner l’optimisation de la requête ou l’indexation des tables.

Exemple de requête 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')

Étapes

Prérequis : Assurez-vous de disposer d’un client de base de données, tel que SQL Developer ou DBeaver, et d’identifiants en lecture seule pour la base Oracle qui héberge le module Quality Management.
Familiarisez-vous avec le schéma : Repérez les principales tables Oracle Quality. La requête utilise principalement QA_RESULTS pour les en-têtes d’événements qualité, QA_PLANS pour les définitions de plans, QA_RESULTS_V pour une vue combinant les résultats et leurs valeurs, ainsi que des tables d’utilisateurs de l’application comme FND_USER ou PER_ALL_PEOPLE_F.
Définissez les paramètres de la requête : Avant de lancer la requête, repérez les variables de remplacement dans la clause WHERE. Remplacez :start_date, :end_date et :organization_id par les valeurs correspondant au périmètre de votre extraction. Par exemple, définissez :start_date sur « 2023-01-01 » et :end_date sur « 2023-06-30 ».
Exécutez la requête SQL : Copiez le script SQL complet et exécutez-le dans votre client de base de données. Le script utilise plusieurs clauses UNION ALL pour réunir différents événements dans un journal d’événements unique.
Vérifiez les données brutes : Après l’exécution, examinez les résultats. Chaque ligne correspond à une activité du cycle de vie d’un événement qualité. Vérifiez que les données sont complètes et que les colonnes clés, telles que QualityEventId, ActivityName et EventStartTime, sont renseignées.
Gérez les horodatages et les durées : La requête fournit EventStartTime. EventEndTime est volontairement défini sur NULL, car le calcul de l’heure de fin d’un événement nécessite souvent de connaître l’heure de début de l’événement suivant. Il est généralement préférable d’effectuer ce calcul dans l’outil de Process Mining ou dans un script de post-traitement. De même, ProcessingTime est défini sur NULL, car son calcul nécessite les heures de début et de fin.
Exportez au format CSV : Exportez l’ensemble des résultats de votre client SQL dans un fichier CSV. Vérifiez que le fichier est encodé en UTF-8 et qu’il comporte une ligne d’en-tête avec les alias de colonnes de la requête.
Préparez l’importation : Vérifiez que les en-têtes de colonnes du fichier CSV correspondent aux exigences de la plateforme ProcessMind (ID de cas, Activité, Start Timestamp). Avant l’importation, renommez les colonnes QualityEventId, ActivityName et EventStartTime en conséquence.

Configuration

Accès à la base de données : L’utilisateur qui exécute la requête doit disposer des privilèges SELECT sur toutes les tables référencées dans le script, qui peuvent inclure des tables des schémas APPS, QA, PER et Ressources humaines.
Principaux filtres de la requête : La requête contient des variables essentielles à configurer :
- :start_date : Début de la période du rapport. La requête sélectionne les événements créés à cette date ou après.
- :end_date : Fin de la période du rapport.
- :organization_id : Identifiant de l’organisation Oracle à analyser. Les plans et les résultats qualité sont souvent associés à une organisation.
Période : Pour une première analyse, il est recommandé d’extraire 3 à 6 mois de données. Si le système est volumineux et traite un grand nombre d’événements, commencez par une période plus courte, par exemple un mois, afin d’évaluer les performances de la requête avant de lancer une extraction plus importante.
Performances : Cette requête joint plusieurs tables volumineuses et combine 14 jeux de résultats distincts. Elle peut donc mobiliser beaucoup de ressources. Planifiez l’extraction en dehors des heures de pointe pour limiter son impact sur les performances du système. Si elle est lente, demandez à un administrateur de base de données d’examiner l’indexation des colonnes clés, en particulier les dates et les clés étrangères.

Exemple de requête 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'

Étapes

Préparez votre environnement : Vérifiez que Python 3.6 ou une version ultérieure est installé sur votre système. Installez les bibliothèques nécessaires avec pip : pip install pandas oracledb. Elles permettent de se connecter à la base Oracle et de traiter les données.
Rassemblez les identifiants de connexion : Obtenez les informations nécessaires pour vous connecter à votre base Oracle Quality Management : nom d’utilisateur, mot de passe et nom de source de données (DSN), généralement au format hostname:port/service_name.
Enregistrez le script d’extraction : Copiez le script Python complet fourni dans la section « query » et enregistrez-le dans un fichier, par exemple extract_quality_events.py.
Configurez le script : Ouvrez le fichier dans un éditeur de texte. Dans la section de configuration en haut du script, remplacez les valeurs fictives de db_user, db_password, db_dsn, start_date et end_date par vos propres informations.
Adaptez les variables de la requête SQL : Examinez la requête SQL dans le script. Vous devrez peut-être adapter les noms de tables, comme QA_RESULTS, ou certaines valeurs d’état, comme 'NEW' et 'CLOSED', à la configuration Oracle de votre organisation. En cas de doute, consultez votre administrateur système Oracle.
Exécutez le script : Ouvrez une invite de commandes ou un terminal, accédez au répertoire où vous avez enregistré le script, puis lancez la commande python extract_quality_events.py.
Suivez l’exécution : Le script se connecte à la base de données, exécute la requête et traite les données. Selon la période et le volume de données, l’opération peut prendre plusieurs minutes. Vérifiez l’apparition du message « Successfully connected to Oracle Database ! », puis de « Event log saved to quality_event_log.csv ».
Récupérez le fichier de sortie : À la fin de l’exécution, le fichier quality_event_log.csv est créé dans le même répertoire. Il contient le journal d’événements extrait.
Vérifiez le journal d’événements : Ouvrez le fichier quality_event_log.csv dans un tableur pour effectuer une première vérification. Contrôlez la présence des colonnes attendues et vérifiez que les données de quelques cas sont correctement renseignées.
Importez le fichier dans l’outil de Process Mining : Le fichier CSV généré est prêt à être importé dans votre application de Process Mining pour analyse.

Configuration

Connexion à la base de données : Le script nécessite un nom de source de données Oracle (DSN), un nom d’utilisateur et un mot de passe donnant un accès en lecture aux tables nécessaires de Quality Management (par exemple, QA_RESULTS, QA_PLANS, FND_USER, PER_ALL_PEOPLE_F).
Filtrage par période : Les variables start_date et end_date du script déterminent le volume de données extrait. Il est recommandé de commencer par une période plus courte, par exemple 3 à 6 mois, afin de vérifier les performances et les résultats avant de lancer une extraction plus importante.
Filtres propres au système : Vous pouvez adapter la requête SQL à la structure de votre organisation. Par exemple, ajoutez une clause WHERE pour filtrer sur ORGANIZATION_ID et limiter l’extraction à une usine ou à une unité opérationnelle.
Correspondance des codes d’état : La logique d’extraction des activités associe certaines valeurs d’état (par exemple, 'NEW', 'UNDER_INVESTIGATION', 'CLOSED') aux étapes du processus. Ces valeurs dépendent fortement de votre configuration Oracle. Vérifiez-les et adaptez la requête SQL pour obtenir des résultats exacts.
Dépendances Python : Le script nécessite les bibliothèques pandas et oracledb. Vérifiez qu’elles sont installées dans l’environnement Python où le script sera exécuté.

Exemple de requête 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)

Prêt à commencer ?

Ce modèle vous aide à préparer rapidement vos données et à commencer à optimiser vos processus de gestion de la qualité. Repérez dès aujourd’hui les possibilités d’améliorer l’efficacité et la conformité.

Retour au guide d’amélioration

Télécharger le modèle

Transformez la gestion de la qualité dans Oracle et renforcez la conformité dès maintenant

Éliminez les inefficacités et réduisez les temps de cycle de 30 %.

Démarrez votre essai gratuit

Aucune carte bancaire requise. Essai gratuit de 14 jours.

Votre modèle de données pour la gestion de la qualité

Votre modèle de données pour la gestion de la qualité

Attributs de gestion de la qualité

Activités de gestion de la qualité

Guides d’extraction

Rapport Oracle BI Publisher sur les données des événements qualité

Étapes

Configuration

Exemple de requête sql

Requête SQL directe sur les tables Oracle Quality Management

Étapes

Configuration

Exemple de requête sql

Script d’extraction Python avec le connecteur Oracle DB

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Transformez la gestion de la qualité dans Oracle et renforcez la conformité dès maintenant

Votre modèle de données pour la gestion de la qualité

Votre modèle de données pour la gestion de la qualité

Attributs de gestion de la qualité

Activités de gestion de la qualité

Guides d’extraction

Rapport Oracle BI Publisher sur les données des événements qualité

Étapes

Configuration

Exemple de requête sql

Requête SQL directe sur les tables Oracle Quality Management

Étapes

Configuration

Exemple de requête sql

Script d’extraction Python avec le connecteur Oracle DB

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Transformez la gestion de la qualité dans Oracle et renforcez la conformité dès maintenant

Prêt à commencer ?