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

Votre modèle de données Quality Management

Gestion de la qualité Oracle

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

Votre modèle de données Quality Management

Ce modèle fournit un guide complet des attributs de données et des activités de processus essentiels à une analyse efficace de la gestion de la qualité. Il contient également des indications pratiques pour extraire ces informations importantes de votre système Oracle Quality Management. Utilisez cette ressource pour vous assurer de recueillir toutes les données nécessaires à des analyses détaillées et à l’optimisation des processus.

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

Vous découvrez les journaux d’événements ? En savoir plus sur la création d’un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs de la gestion de la qualité

Voici les champs de données et les informations contextuelles recommandés à inclure dans votre journal d’événements pour analyser en détail la gestion de la qualité et obtenir une vision complète du processus.

3 Obligatoire 7 Recommandé 10 Facultatif

	Nom	Description
	Événement qualité QualityEventId	L’identifiant unique d’un événement qualité donné, tel qu’une non-conformité, une réclamation ou un écart.
Description L’identifiant Quality Event ID sert d’identifiant de cas principal et regroupe toutes les activités associées, du signalement initial à la clôture définitive. Chaque incident qualité reçoit un identifiant unique, ce qui crée un historique complet du processus d’investigation et de résolution. Dans l’analyse par Process Mining, cet Attribut est fondamental pour reconstituer le parcours de bout en bout de chaque événement qualité. Il permet de calculer les durées globales des cycles, d’identifier les variantes de processus et d’analyser la manière dont les différents types d’événements sont traités. En reliant chaque journal d’activité à un Quality Event ID précis, les analystes peuvent visualiser l’ensemble du flux de processus et identifier les goulots d’étranglement systémiques ou les problèmes de conformité. Pourquoi c’est important Cet identifiant est essentiel, car il définit le périmètre d’un cas donné, permet de suivre précisément les événements qualité et de calculer les indicateurs de performance de bout en bout. Où les obtenir 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, telles que QA_RESULTS. Exemples NC-2023-00123CAPA-45892QE-500-A
	Heure de début de l’événement EventStartTime	L’horodatage indiquant le début d’une activité ou d’un événement.
Description Cet Attribut fournit la date et l’heure précises auxquelles une étape donnée du processus a commencé. Il constitue le principal élément temporel utilisé pour classer les événements par ordre chronologique et établir 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 pour calculer les durées de cycle, les temps de traitement et les temps d’attente entre les activités. Elle permet d’identifier les goulots d’étranglement en mettant en évidence les longs délais entre deux étapes successives et sert à suivre la performance par rapport aux KPI fondés sur le temps, tels que « Root Cause Analysis Lead Time ». Pourquoi c’est important Cet horodatage constitue la base de l’analyse du processus, car il permet tous les calculs temporels et le classement correct des activités. Où les obtenir 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, souvent sous 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	Le nom de la tâche ou de l’étape précise exécutée dans le processus de Gestion de la qualité.
Description Cet Attribut décrit un événement ou une action unique réalisé dans le cadre de la gestion d’un événement qualité. La séquence de ces activités, classé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 réel du processus, de le comparer à un modèle cible dans le cadre d’un contrôle de conformité et d’identifier 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 c’est important Cet Attribut est fondamental pour cartographier le flux de processus, identifier les écarts et comprendre comment le travail est réellement effectué. Où les obtenir 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éInvestigation lancéePlan d’actions correctives approuvéExamen final et clôture
	Catégorie de cause racine RootCauseCategory	La classification de la cause racine déterminée du problème qualité.
Description Après l’analyse de la cause racine, les résultats sont souvent classés dans des groupes prédéfinis tels que « Défaillance de l’équipement », « Erreur humaine » ou « Défaut de conception ». Cet attribut enregistre cette classification finale. L’analyse du processus par catégorie de cause racine est particulièrement utile. Elle permet de ne plus se limiter à corriger les symptômes individuels et de s’attaquer aux problèmes systémiques sous-jacents. Par exemple, un nombre élevé d’événements dont la cause racine est un « Problème de formation » peut révéler la nécessité d’améliorer les programmes de formation des collaborateurs, un objectif essentiel des actions préventives. Pourquoi c’est important Cet attribut est essentiel pour passer d’une gestion réactive à une gestion proactive de la qualité, en permettant d’analyser les causes fondamentales des défaillances. Où les obtenir 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 de la cause racine effectuée ». Exemples Dysfonctionnement de l'équipementDéfaut matérielErreur 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 représente la date limite à laquelle un événement qualité doit être entièrement résolu. Il sert de niveau de service (SLA) ou d’objectif interne, souvent défini selon la gravité ou le type de l’événement. Cette date est fondamentale pour le suivi de la performance et intervient directement dans le calcul du KPI « CAPA Impl. On-Time Rate ». En comparant les dates réelles d’achèvement des activités à cette cible, les analystes peuvent mesurer le respect des délais, identifier les événements susceptibles d’être en retard et suivre les tendances de la performance dans les délais. Cette analyse contribue à réduire les durées de cycle de résolution. Pourquoi c’est important Elle fournit une référence pour mesurer la performance dans les délais et est essentielle au calcul des KPI de respect des délais ainsi qu’à la gestion des SLA. Où les obtenir 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	L’horodatage indiquant la fin d’une activité ou d’un événement.
Description L’heure de fin de l’événement marque l’achèvement d’une activité donnée. Associée à l’heure de début de l’événement, elle définit le temps de traitement de cette activité. Dans certains systèmes, une activité peut être instantanée, auquel cas les heures de début et de fin sont identiques. Cet Attribut est essentiel pour l’analyse détaillée des durées. Il permet aux analystes de distinguer le temps de traitement actif, c’est-à-dire la durée entre le début et la fin, du temps d’attente, c’est-à-dire la durée entre la fin d’une activité et le début de la suivante. Cette distinction est essentielle pour identifier les moments où les ressources sont effectivement mobilisées et ceux où les transferts entraînent des retards. Pourquoi c’est important Il permet de calculer précisément les temps de traitement des activités et d’identifier les tâches inefficaces par rapport aux longues périodes d’attente. Où les obtenir Cette information peut être disponible dans les mêmes tables de transactions ou d’historique que l’heure de début, parfois sous la forme de LAST_UPDATE_DATE ou d’un horodatage d’achèvement spécifique. Elle peut également ê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	Une 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 du triage, 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éfinir le degré d’urgence de la réponse requise. Dans le Process Mining, cet Attribut est essentiel à la segmentation. Les analystes peuvent comparer les flux de processus, les durées de cycle et les résultats des événements à forte gravité avec ceux des événements à faible gravité. Il alimente le Dashboard « Quality Event Triage Consistency » et le KPI « Severity-Based Resolution Rate » en montrant si les problèmes critiques sont effectivement traités plus rapidement et plus efficacement. Pourquoi c’est important Il permet de prioriser et de segmenter l’analyse, afin de garantir une gestion efficace des événements qualité à fort impact. Où les obtenir 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 - Informatif
	Service responsable ResponsibleDepartment	Le service ou le 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, et cette responsabilité peut changer au cours du cycle de vie de l’événement. Dans le Process Mining, l’analyse par service responsable est essentielle pour comprendre la répartition de la charge de travail, identifier les goulots d’étranglement entre les services et comparer la performance de différentes équipes. Elle alimente le Dashboard « Quality Event Resource Allocation » en indiquant quels services interviennent dans quels types d’activités, ce qui aide à optimiser la gestion des ressources. Pourquoi c’est important Il permet d’analyser la charge de travail, la performance et les goulots d’étranglement par service, ce qui est essentiel à la planification des ressources et à l’amélioration de l’organisation. Où les obtenir 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 productionQualité fournisseursIngénierie de conception
	Statut actuel CurrentStatus	Le 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 fournit un instantané de la position du cas dans le processus au moment de l’extraction des données. Il s’agit d’un Attribut essentiel au suivi opérationnel, qui alimente directement le Dashboard « Open Quality Events & Status Overview ». Il permet aux responsables de visualiser rapidement le portefeuille actuel de problèmes qualité et de prioriser les ressources. Dans le Process Mining, le filtrage par statut final aide à analyser les résultats des différents parcours du processus. Pourquoi c’est important Il fournit une vue à jour du portefeuille d’événements qualité et permet de gérer efficacement les opérations ainsi que de prioriser les cas actifs. Où les obtenir Ces informations sont généralement disponibles dans la table d’en-tête principale des événements qualité et reflètent le dernier état connu de l’événement. Exemples OuvertEn coursEn attente d'approbationClôturé
	Utilisateur affecté AssignedUser	L’utilisateur chargé d’exécuter une activité ou responsable de l’événement qualité.
Description Cet Attribut précise la personne responsable d’une tâche donnée 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 les charges de travail individuelles, à identifier les besoins de formation et à repérer les meilleurs contributeurs. Elle peut également révéler des tendances, par exemple des réaffectations fréquentes ou des tâches qui restent bloquées avec certaines personnes. Ce niveau de détail est utile à la gestion de la performance et à l’optimisation précise des ressources. Pourquoi c’est important Il permet d’analyser finement la charge de travail et la performance individuelles, afin d’identifier les contraintes de ressources ou les possibilités de formation. Où les obtenir Consultez la documentation Oracle Quality Management. Les informations d’affectation des 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
	Catégorie du problème IssueCategory	La catégorie ou le type du problème qualité, par exemple « Product Defect » ou « Process Deviation ».
Description Cet Attribut fournit une classification de l’événement qualité et permet de regrouper les problèmes similaires à des fins d’analyse. Les catégories sont généralement définies par l’organisation afin de refléter son contexte opérationnel propre. L’analyse du processus par catégorie de problème permet d’identifier les tendances associées à certains types de problèmes. Elle peut par exemple révéler que les problèmes liés aux « Supplier Material » présentent une durée de cycle bien supérieure à celle des problèmes liés à l’« Internal Process ». Cette segmentation est utile pour cibler les initiatives d’amélioration des processus. Pourquoi c’est important La catégorisation des problèmes permet de cibler l’analyse afin d’identifier les tendances et les causes racines propres à certains domaines de difficulté. Où les obtenir 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 produitDéviation du processusMatériel fournisseurRéclamation client
	Code de clôture ClosureCode	Code indiquant la raison ou le résultat de la clôture de l’événement qualité.
Description Lorsqu’un événement qualité est clôturé, un code de clôture lui est souvent attribué afin de classer le résultat final. Parmi les exemples figurent « Action efficace », « Aucune action requise » ou « Problème en double ». Cet attribut est très utile pour analyser les résultats. En filtrant les différents codes de clôture, les analystes peuvent étudier les parcours de processus qui mènent à une résolution réussie et ceux qui n’y parviennent pas. Il peut notamment aider à répondre à des questions telles que : « À quoi ressemble notre processus pour les problèmes clôturés comme doublons ? » et à repérer les inefficacités du processus de triage. Pourquoi c’est important Il fournit des informations importantes sur le résultat d’un cas et permet d’analyser les parcours de processus qui mènent aux résolutions réussies. Où les obtenir Consultez la documentation Oracle Quality Management. Il s’agit probablement d’un champ renseigné lors de l’activité finale de clôture. Exemples EFFICACENO_ACTIONDUPLICATERISK_ACCEPTED
	Dernière mise à jour des données LastDataUpdate	L’horodatage de l’actualisation ou de la mise à jour la plus récente des données provenant du système source.
Description Cet Attribut indique la dernière date à laquelle les données relatives à cet événement ont été mises à jour dans le jeu de données de Process Mining. Il reflète la fraîcheur des données et aide les utilisateurs à comprendre l’actualité de l’analyse. Dans les Dashboards et les rapports, cet horodatage fournit un contexte essentiel. Il précise si les utilisateurs consultent des données en temps réel ou un instantané correspondant à un moment donné, ce qui est indispensable pour prendre des décisions opérationnelles éclairées. Il garantit la transparence quant à l’actualité des données. Pourquoi c’est important Cet horodatage garantit la transparence sur la fraîcheur des données et permet aux utilisateurs de comprendre dans quelle mesure l’analyse du processus est à jour. Où les obtenir 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
	Durée totale du cycle 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 complète de bout en bout d’un cas correspondant à un événement qualité. Il est calculé comme la différence entre l’horodatage de la toute première activité (« Problème qualité identifié ») et celui de la toute dernière activité (« Revue finale et clôture »). Il s’agit d’un indicateur clé de performance (KPI) majeur pour évaluer l’efficacité globale du processus de gestion de la qualité. C’est la principale mesure du Dashboard « Durée de cycle de bout en bout des événements qualité ». Le suivi de cet indicateur dans le temps et sa segmentation selon des attributs tels que la gravité ou la catégorie du problème fournissent une vision globale de la santé du processus et de l’impact des initiatives d’amélioration. Pourquoi c’est important Il s’agit d’un KPI essentiel qui mesure la rapidité et l’efficacité globales du processus de gestion de la qualité, du début à la fin. Où les obtenir Cet indicateur est calculé au niveau du cas lors du traitement des données pour le Process Mining. Il 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
	ID 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 spécifique conçu pour le résoudre. Il s’agit souvent d’un objet distinct dans le système, avec son propre cycle de vie. Dans le cadre de l’analyse, cet ID peut servir à relier les données du processus de gestion des événements qualité à celles du processus de gestion des CAPA, afin d’obtenir une vision plus complète. Il permet de vérifier que chaque événement nécessitant une CAPA en possède bien une et d’analyser l’efficacité des actions engagées. Pourquoi c’est important Il relie le problème, c’est-à-dire l’événement qualité, à la solution, c’est-à-dire la CAPA, et permet ainsi une analyse de bout en bout plus complète du système de gestion de la qualité. Où les obtenir Il s’agit d’un champ de référence de l’enregistrement de l’événement qualité, qui pointe vers un enregistrement d’une table ou d’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 relie 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. Ce lien est essentiel à l’analyse de la qualité des produits. Le Process Mining peut servir à comparer les processus de Gestion de la qualité entre différentes gammes de produits ou à identifier les produits fréquemment associés à des problèmes qualité. Il aide ainsi à prioriser les efforts d’amélioration en ingénierie ou en production là où ils sont les plus nécessaires. Pourquoi c’est important Il relie les événements qualité à des produits précis et permet d’analyser les tendances qualité ainsi que les variations de processus associées aux produits. Où les obtenir Ces informations seraient stockées dans un champ du plan de collecte qualité, souvent associé au référentiel des articles Oracle Inventory. Exemples SKU-100-A-REDPN-987654CHEM-X2
	Respect du délai IsOnTime	Indicateur précisant si une action corrective a été mise en œuvre au plus tard à la date cible de résolution.
Description Cet attribut booléen est obtenu en comparant l’horodatage d’achèvement de l’activité « Action corrective mise en œuvre » à la « Date cible de résolution » du cas. Sa valeur est vraie si l’action a été achevée à la date cible ou avant celle-ci, et fausse dans le cas contraire. Cet attribut contribue directement au KPI « Taux de mise en œuvre des CAPA dans les délais ». Il simplifie l’analyse et la création de Dashboards en fournissant une classification binaire claire de la ponctualité de chaque cas. Il facilite le filtrage et l’agrégation pour suivre le respect des niveaux de service et identifier les causes racines des retards. Pourquoi c’est important Il simplifie le suivi du respect des délais par rapport aux objectifs et facilite la mesure ainsi que le reporting de ce KPI essentiel. Où les obtenir Il s’agit d’un indicateur dérivé, calculé lors de la transformation des données. Il nécessite la TargetResolutionDate et l’horodatage de l’activité d’achèvement concernée. Exemples truefalse
	Retouche IsRework	Indicateur précisant si une activité constitue la répétition ou la reprise d’une étape précédente dans le même cas.
Description Cet attribut booléen prend la valeur vraie lorsqu’une activité donnée, telle que « Plan d’actions correctives proposé », se produit plusieurs fois dans un même cas d’événement qualité. Cela indique une boucle ou une correction dans le processus, lorsqu’une étape déjà réalisée doit être recommencée. L’identification des reprises constitue une fonction importante du Process Mining. Cet indicateur simplifie la quantification de ces inefficacités et contribue directement au KPI « Fréquence des reprises d’activité ». L’analyse des étapes les plus sujettes aux reprises et des conditions dans lesquelles elles surviennent 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élioration du processus. Pourquoi c’est important Il signale les inefficacités et les boucles du processus, ce qui aide à quantifier les gaspillages et à identifier les causes racines des reprises. Où les obtenir Il est calculé à 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. Il identifie les cas où le même nom d’activité apparaît plusieurs fois pour un même cas. Exemples truefalse
	Système source SourceSystem	Identifie le système de référence à partir duquel les données ont été extraites.
Description Cet Attribut précise l’application ou le système d’origine des données d’événements. Dans un environnement d’entreprise, les données relatives aux événements qualité peuvent provenir de plusieurs sources, telles que le module Oracle Quality principal, un système CAPA distinct ou un portail de réclamations clients. Pour l’analyse, ce champ aide à comprendre la traçabilité des données et peut servir à segmenter le processus selon le système d’origine. Il est essentiel à la gouvernance des données et au diagnostic des problèmes d’intégration, afin de garantir que la vue du processus reflète correctement l’ensemble des systèmes concernés. Pourquoi c’est important Il fournit un contexte important sur l’origine des données, indispensable à leur validation, à leur gouvernance et à l’analyse des variations du processus entre les différents systèmes. Où les obtenir Il s’agit généralement d’une valeur statique ajoutée lors du processus d’extraction, de transformation et de chargement (ETL) des données afin d’indiquer l’origine du jeu de données. Exemples Oracle Quality Management R12Oracle EBS QualityQM-PROD
	Unité opérationnelle BusinessUnit	L’unité opérationnelle ou la division de l’organisation dans laquelle l’événement qualité s’est produit ou est géré.
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. La segmentation de l’analyse des processus par unité opérationnelle est une exigence courante dans les grandes entreprises. Elle permet de créer des Dashboards propres à chaque unité et d’identifier les divisions dont les processus qualité sont les plus efficaces ou qui rencontrent des difficultés particulières. Cette approche est utile pour le pilotage au niveau du groupe et le partage des bonnes pratiques dans toute l’organisation. Pourquoi c’est important Il permet de comparer et d’analyser les performances entre différentes parties de l’organisation, et contribue ainsi à une gestion de la qualité à l’échelle de l’entreprise. Où les obtenir Cet élément fait généralement partie des données de contexte organisationnel associées à la transaction. Il est souvent dérivé 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 et les jalons importants à enregistrer dans votre journal d’événements pour découvrir précisément le processus et évaluer ses performances.

6 Recommandé 8 Facultatif

	Activité	Description
	Efficacité de l’action vérifiée	Confirme que l’action corrective mise en œuvre a bien éliminé la cause racine et empêché la réapparition du problème. Cet événement est enregistré lorsqu’un utilisateur termine l’étape de vérification et met à jour le statut de l’enregistrement.
Pourquoi c’est important Il s’agit d’une étape clé fondée sur le résultat et de la base du KPI « Effectiveness Verif. Rate ». Elle clôt le cycle de l’action corrective et garantit que les problèmes sont réellement résolus. Où les obtenir Déduit d’un changement de statut de l’enregistrement CAPA vers « Verification Complete » ou « Effective ». Il peut également impliquer le renseignement de champs spécifiques relatifs au résultat de la vérification. Collecte Déduit d’un changement de statut vers « Verification Complete » ou « Effective ». Type d’événement inferred
	Examen final et clôture	Dernière étape, au cours de laquelle l’achèvement de toutes les actions associées est confirmé et le problème qualité parent est officiellement clôturé. Elle est enregistrée par un changement de statut final vers « Closed » ou « Resolved » sur l’enregistrement principal.
Pourquoi c’est important Il s’agit de l’événement de fin principal du processus. Il est essentiel pour calculer le KPI « Average Event Cycle Time » et mesurer le débit global du processus. Où les obtenir Déduit du changement de statut final de l’enregistrement Quality Issue parent vers « Closed ». L’horodatage de cette modification sert d’heure de l’événement. Collecte Déduit d’un changement de statut vers « Closed » dans l’enregistrement Quality Issue principal. Type d’événement inferred
	Investigation lancée	Marque le début officiel de la phase d’investigation visant à déterminer la cause racine du problème qualité. Elle est généralement représentée par un changement de statut dans le système, par exemple le passage à « Under Investigation ».
Pourquoi c’est important Cette étape sert de point de départ pour mesurer le KPI « Root Cause Analysis Lead Time » et aide à déterminer combien de temps les problèmes attendent avant le début d’une investigation formelle. Où les obtenir Déduit du changement de statut de l’enregistrement Quality Issue ou d’un enregistrement Quality Action associé vers un statut « Investigation ». L’horodatage de ce changement de statut fournit l’heure de l’événement. Collecte Déduit d’un changement de statut vers « Under Investigation » ou vers un état similaire. Type d’événement inferred
	Plan d’actions correctives approuvé	Représente l’approbation formelle du plan d’actions correctives 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 un changement de statut vers « Approved ».
Pourquoi c’est important Cette approbation constitue une étape clé et un goulot d’étranglement fréquent. L’analyse des délais d’approbation aide à optimiser le processus et à garantir le respect des procédures. Où les obtenir Déduit d’un changement de statut de l’enregistrement Quality Action ou CAPA vers « Approved ». Dans les systèmes Oracle dotés de flux de travail d’approbation, ce changement est souvent enregistré explicitement dans les tables d’audit. Collecte Déduit d’un changement de statut vers « Approved ». Type d’événement inferred
	Problème catégorisé et priorisé	Cette activité intervient lorsqu’un analyste termine l’évaluation initiale et attribue des Attributs clés tels que la gravité, la priorité et le type de problème. Elle est généralement enregistrée lorsque le problème passe du statut « New » au statut « Assessed » ou « In Triage ».
Pourquoi c’est important Cette étape est essentielle pour le KPI « Avg Triage Processing Time ». Les retards à ce stade peuvent ralentir l’ensemble du processus de résolution, en particulier pour les problèmes critiques. Où les obtenir Déduit d’un changement de statut de l’enregistrement Quality Issue, par exemple de « New » à « Under Assessment », ou lorsque des champs tels que « Severity » ou « Priority » sont renseignés pour la première fois. Collecte Déduit 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é marque 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 c’est important En tant qu’événement de début, elle est essentielle pour calculer la durée totale du cycle du processus de Gestion de la qualité et comprendre le volume des événements qualité entrants. Où les obtenir Cet événement est enregistré à partir de l’horodatage de création de l’enregistrement Quality Issue ou Quality Action, probablement présent dans des tables telles que QAM_QUALITY_ISSUES ou QAM_QUALITY_ACTIONS. Collecte É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	Marque l’achèvement des tâches définies dans le plan d’actions correctives approuvé. Cet événement est généralement enregistré lorsqu’un utilisateur met à jour le statut de l’enregistrement de l’action corrective vers « Implemented » ou « Completed ».
Pourquoi c’est important Cette activité est essentielle pour le KPI « CAPA Impl. On-Time Rate », car elle indique que la correction prévue a été exécutée et permet de la comparer aux dates cibles. Où les obtenir Cet événement est déduit du changement de statut de l’enregistrement Quality Action ou CAPA associé vers « Implemented » ou « Completed ». Collecte Déduit d’un changement de statut vers « Implemented » ou « Completed ». Type d’événement inferred
	Action préventive identifiée	Représente la création d’une action préventive (PA) destinée à traiter les problèmes systémiques et à empêcher la survenue d’événements qualité similaires. Elle est souvent enregistrée lors de la création d’un nouvel enregistrement Preventive Action associé au problème initial.
Pourquoi c’est important Cette activité témoigne d’un processus qualité mature, qui ne se limite pas à corriger les problèmes isolés, mais cherche également à prévenir leur réapparition. Son suivi permet de mesurer les améliorations qualité proactives. Où les obtenir Enregistré lors de la création d’un nouvel enregistrement Quality Action de type « Preventive Action », souvent associé au Quality Issue ou à la Corrective Action d’origine. Collecte Enregistré 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	Marque l’achèvement des tâches définies dans le plan d’actions préventives visant à réduire les risques systémiques. Cet événement est enregistré lorsqu’un utilisateur met à jour le statut de l’action préventive vers « Implemented » ou « Completed ».
Pourquoi c’est important Mesure la capacité de l’organisation à mettre en œuvre des améliorations qualité proactives. Les retards à ce stade peuvent indiquer des difficultés à déployer des changements systémiques dans l’ensemble de l’organisation. Où les obtenir Déduit d’un changement de statut de l’enregistrement Preventive Action associé vers « Implemented » ou « Completed », selon un mécanisme similaire à celui utilisé pour suivre les actions correctives. Collecte Déduit d’un changement de statut vers « Implemented » dans un enregistrement Preventive Action. Type d’événement inferred
	Analyse de la cause racine réalisée	Représente la fin de l’analyse de la cause racine (RCA) et la documentation des résultats. Cet événement est généralement enregistré lorsque l’équipe d’investigation met à jour le problème qualité avec la cause racine identifiée et modifie son statut.
Pourquoi c’est important Cette activité constitue le point final du KPI « Root Cause Analysis Lead Time ». L’analyse de la durée jusqu’à cette étape permet de localiser les goulots d’étranglement dans la phase de résolution des problèmes. Où les obtenir Déduit d’un changement de statut vers « RCA Complete » ou lorsque le champ de catégorie de cause racine est renseigné et que l’enregistrement est sauvegardé. L’horodatage de cette mise à jour est utilisé. Collecte Déduit d’un changement de statut vers « RCA Complete » ou du renseignement des champs relatifs à la cause racine. Type d’événement inferred
	Parties prenantes informées de la résolution	Représente la communication de la résolution de l’événement qualité aux parties concernées, telles que le déclarant ou les clients affectés. Cet événement est difficile à capturer et peut être déduit d’un changement de statut après clôture ou d’un commentaire enregistré.
Pourquoi c’est important Essentiel pour le KPI « Stakeholder Notification Lag ». Une communication rapide est importante pour la satisfaction client et la transparence interne, y compris après la résolution d’un problème. Où les obtenir Cet événement est souvent difficile à capturer automatiquement. Il peut être déduit d’un statut tel que « Notification Sent » ou être enregistré dans un champ d’activité ou de commentaires, ce qui nécessite une logique spécifique d’extraction. Collecte Déduit d’un changement de statut précis ou, éventuellement, de l’analyse textuelle des journaux d’activité. Type d’événement inferred
	Plan d’actions correctives proposé	Cette étape intervient lorsque les actions correctives sont définies et associées au problème qualité, en précisant 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 qu’un plan est prêt à être examiné.
Pourquoi c’est important Cette étape suit le passage de l’analyse du problème à la conception de la solution. Les reprises à ce stade, mesurées par les KPI de reprise, peuvent révéler des exigences imprécises ou une planification inefficace. Où les obtenir Il peut s’agir d’un événement explicite correspondant à la création d’un nouvel enregistrement Corrective Action dans un objet CAPA, ou d’un événement déduit d’un changement de statut vers « Plan Proposed » ou « Pending Approval ». Collecte Déduit d’un changement de statut vers « Pending Approval » ou de la création d’une Corrective Action associée. Type d’événement inferred
	Problème affecté pour triage	Représente l’affectation du problème qualité nouvellement créé à un utilisateur ou à une équipe donnée pour son examen et son évaluation initiale. Cet événement est souvent déduit du suivi des modifications apportées au champ d’affectation ou de responsable de l’enregistrement du problème qualité.
Pourquoi c’est important Le suivi de ce transfert initial permet d’identifier les retards avant le début de l’évaluation. L’analyse du temps passé dans cet état révèle les éventuels retards accumulés dans la file de triage. Où les obtenir Déduit des modifications apportées au champ du propriétaire ou de la personne affectée dans l’enregistrement Quality Issue. Ces informations peuvent provenir des tables d’historique d’audit ou du suivi des changements de statut associés aux flux de travail d’affectation. Collecte Déduit d’une modification du champ « Assigned To » ou « Owner » dans Quality Issue. Type d’événement inferred
	Vérification de l’efficacité requise	Représente le signalement, par le système ou un utilisateur, que l’action mise en œuvre nécessite une vérification de suivi afin de confirmer son efficacité. Il s’agit souvent d’un changement de statut automatique ou manuel intervenant après la mise en œuvre.
Pourquoi c’est important Cette étape lance la phase essentielle de vérification. L’analyse du temps écoulé entre la mise en œuvre et cette activité peut révéler des retards dans le lancement des suivis nécessaires. Où les obtenir Cet événement est déduit d’un changement de statut de Quality Action vers « Pending Effectiveness Check » ou vers un état similaire dans le flux de travail. Collecte Déduit d’un changement de statut vers « Pending Effectiveness Check ». Type d’événement inferred

Recommandé Facultatif

Guides d’extraction

Comment extraire vos données d’Oracle Quality Management

Étapes

Accéder à Oracle BI Publisher : Connectez-vous à votre instance Oracle E-Business Suite et accédez à la responsabilité qui donne accès à BI Publisher, par exemple BI Publisher Administrator ou une responsabilité personnalisée équivalente.
Créer 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éfinir un jeu de données SQL Query : Dans l’éditeur de modèle de données, cliquez sur l’icône plus du panneau Data Sets et sélectionnez SQL Query. La fenêtre de l’éditeur de requête SQL s’ouvre.
Configurer 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.
Saisir la requête SQL : Copiez la requête SQL complète fournie dans la section « query » de ce document et collez-la dans la zone de texte SQL Query.
Définir les paramètres de la requête : La requête fournie utilise les paramètres :P_START_DATE et :P_END_DATE pour la période de reporting. Dans le modèle de données BI Publisher, vous devez les définir comme paramètres. Pour chacun d’eux, créez un nouveau paramètre, attribuez-lui le nom correspondant, par exemple P_START_DATE, définissez le Data Type sur Date et configurez une invite conviviale.
Enregistrer 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 l’enregistrer dans un dossier partagé destiné aux rapports.
Créer un rapport : Revenez à la page d’accueil de BI Publisher, sélectionnez Create, puis Report. Sélectionnez l’option « Use Data Model » et recherchez le modèle de données que vous venez d’enregistrer.
Configurer la mise en page du rapport : L’assistant de rapport vous guide dans la configuration de la mise en page. Pour ProcessMind, une mise en page sous forme de tableau suffit. Faites glisser toutes les colonnes du modèle de données vers la mise en page du rapport. Vérifiez que le format de sortie est configuré sur CSV.
Définir 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 de paramètres par défaut si nécessaire.
Exécuter et exporter le rapport : Enregistrez le rapport, puis exécutez-le en indiquant les dates de début et de fin souhaitées. Une fois la génération terminée, cliquez sur le bouton Export et sélectionnez CSV comme format de sortie. Le fichier est téléchargé sur votre ordinateur.
Préparer le chargement : Ouvrez le fichier CSV téléchargé pour vérifier qu’il contient les données attendues. Vérifiez que les en-têtes de colonnes correspondent aux exigences du schéma ProcessMind. Le fichier est maintenant prêt à être chargé.

Configuration

Prérequis : Un compte utilisateur disposant d’un accès à Oracle BI Publisher et d’un accès en lecture aux tables sous-jacentes du module Quality, par exemple QA_RESULTS, QA_PLANS, QA_ACTIONS et 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 l’application Oracle EBS, dans le schéma APPS.
Paramètres de période : La requête est conçue avec deux paramètres obligatoires, :P_START_DATE et :P_END_DATE, pour filtrer l’extraction. Pour une première analyse, il est recommandé d’utiliser une période de 6 à 12 mois 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 particulièrement à l’ingestion dans ProcessMind, car il est simple, structuré et évite les analyses complexes.
Planification : Pour assurer une surveillance continue du processus, planifiez l’exécution récurrente du rapport BI Publisher, par exemple chaque jour ou chaque semaine. Configurez la livraison de la sortie vers un serveur ou un référentiel de contenu désigné afin d’automatiser sa récupération.
Performances : Dans les environnements présentant un très grand volume d’événements qualité, l’exécution de la requête peut prendre un temps important. Vérifiez que la période est raisonnable et envisagez de discuter de l’optimisation de la requête ou de l’indexation des tables avec votre administrateur de base de données si les performances posent problème.

a 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, ainsi que d’identifiants en lecture seule pour la base Oracle qui héberge le module de gestion de la qualité.
Comprendre le schéma : familiarisez-vous avec les principales tables Oracle dédiées à la qualité. La requête utilise principalement QA_RESULTS pour les en-têtes des événements qualité, QA_PLANS pour les définitions des plans, QA_RESULTS_V pour une vue combinée des résultats et de leurs valeurs, ainsi que des tables d’utilisateurs applicatifs telles que FND_USER ou PER_ALL_PEOPLE_F.
Définir les paramètres de la requête : avant d’exécuter la requête, repérez les variables de substitution dans la clause WHERE. Vous devez remplacer :start_date, :end_date et :organization_id par les valeurs appropriées pour le périmètre de votre extraction. Par exemple, définissez :start_date sur '2023-01-01' et :end_date sur '2023-06-30'.
Exécuter la requête SQL : copiez l’intégralité du script SQL et exécutez-le dans votre client de base de données. Le script utilise plusieurs clauses UNION ALL pour rassembler différents événements dans un format unique de journal d’événements.
Examiner les données brutes : après l’exécution, examinez le résultat. Chaque ligne représente une activité du cycle de vie d’un événement qualité. Vérifiez que les données sont complètes et que les colonnes importantes, telles que QualityEventId, ActivityName et EventStartTime, sont renseignées.
Gérer les horodatages et les durées : la requête fournit EventStartTime. EventEndTime est volontairement défini sur NULL, car la détermination de l’heure de fin d’un événement nécessite souvent de connaître l’heure de début du suivant. Ce calcul est généralement mieux réalisé 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.
Exporter au format CSV : exportez l’ensemble des résultats depuis votre client SQL vers un fichier CSV. Vérifiez que le fichier utilise l’encodage UTF-8 et contient une ligne d’en-tête avec les alias de colonnes de la requête.
Préparer 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). Renommez les colonnes QualityEventId, ActivityName et EventStartTime en conséquence avant l’importation.

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 se trouver dans les schémas APPS, QA, PER et RH.
Filtres principaux de la requête : la requête contient des variables de substitution importantes qui doivent être configurées :
- :start_date : début de la période de reporting. La requête filtre les événements créés à partir de cette date.
- :end_date : fin de la période de reporting.
- :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, une période de trois à six mois de données est recommandée. Pour les systèmes volumineux à forte activité, 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.
Considérations relatives aux performances : cette requête joint plusieurs tables volumineuses et regroupe 14 ensembles de résultats distincts. Elle peut mobiliser beaucoup de ressources. Planifiez l’extraction en dehors des heures de pointe afin de limiter son impact sur les performances du système. Si les performances sont insuffisantes, demandez conseil à un administrateur de base de données au sujet de l’indexation des colonnes clés, en particulier des colonnes de date et des clés étrangères.

a 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éparer 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 sont indispensables pour se connecter à la base Oracle et manipuler les données.
Obtenir les identifiants de la base de données : Rassemblez les informations de connexion nécessaires à votre base Oracle Quality Management. Elles comprennent le nom d’utilisateur, le mot de passe et le Data Source Name (DSN), qui suit généralement le format hostname:port/service_name.
Enregistrer 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.
Configurer le script : Ouvrez le script enregistré dans un éditeur de texte. Dans la section de configuration située en haut du fichier, remplacez les valeurs de remplacement de db_user, db_password, db_dsn, start_date et end_date par vos informations.
Personnaliser les paramètres SQL : Examinez la requête SQL intégrée au script. Vous devrez peut-être adapter les noms de tables, tels que QA_RESULTS, ou certaines valeurs de statut, telles que 'NEW' et 'CLOSED', à la configuration Oracle de votre organisation. En cas de doute, consultez l’administrateur de votre système Oracle.
Exécuter le script : Ouvrez une invite de commandes ou un terminal, accédez au répertoire dans lequel vous avez enregistré le script et exécutez la commande suivante : python extract_quality_events.py.
Surveiller 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 la présence du message « Successfully connected to Oracle Database! », puis du message final « Event log saved to quality_event_log.csv ».
Récupérer le fichier de sortie : Une fois le script terminé, un fichier nommé quality_event_log.csv est créé dans le même répertoire. Il contient le journal d’événements extrait.
Examiner le journal d’événements : Ouvrez le fichier quality_event_log.csv dans un tableur pour effectuer une vérification rapide. Contrôlez la présence des colonnes attendues et vérifiez que les données sont correctement renseignées sur quelques cas représentatifs.
Charger les données dans l’outil de Process Mining : Le fichier CSV généré est maintenant prêt à être chargé dans votre application de Process Mining pour analyse.

Configuration

Connexion à la base de données : Le script nécessite un Data Source Name (DSN) Oracle, un nom d’utilisateur et un mot de passe disposant d’un accès en lecture aux tables Quality Management nécessaires, par exemple QA_RESULTS, QA_PLANS, FND_USER et PER_ALL_PEOPLE_F.
Filtrage de la période : Les variables start_date et end_date du script sont essentielles pour contrôler le volume de données. Il est recommandé de commencer par une période plus courte, de 3 à 6 mois par exemple, afin de vérifier les performances et de valider le résultat avant de lancer une extraction plus importante.
Filtres propres au système : La requête SQL peut être personnalisée pour intégrer des filtres liés à votre structure organisationnelle. Vous pouvez par exemple ajouter une clause WHERE filtrant sur ORGANIZATION_ID afin de limiter l’extraction à une usine ou à une unité opérationnelle donnée.
Correspondance des codes de statut : La logique d’extraction des activités repose sur la correspondance entre certaines valeurs de statut, par exemple 'NEW', 'UNDER_INVESTIGATION' et 'CLOSED', et les étapes du processus. Ces valeurs dépendent fortement de votre configuration Oracle et doivent être vérifiées et ajustées dans la requête SQL pour garantir l’exactitude des résultats.
Dépendances Python : Le script dépend des bibliothèques pandas et oracledb. Vérifiez qu’elles sont installées dans l’environnement Python dans lequel le script sera exécuté.

a 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 est conçu pour vous aider à préparer rapidement vos données et à commencer à optimiser vos processus de gestion de la qualité. Commencez dès aujourd’hui à identifier les possibilités d’amélioration de l’efficacité et de la conformité.

Retour au guide d’amélioration Télécharger le modèle

Transformez Oracle Quality Management et renforcez la conformité dès maintenant

Éliminez les inefficacités et réduisez de 30 % la durée des cycles.

Démarrer l’essai gratuit

Aucune carte bancaire requise. Essai gratuit de 14 jours.

Votre modèle de données Quality Management

Votre modèle de données Quality Management

Attributs de la gestion de la qualité

Activités de gestion de la qualité

Guides d’extraction

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

Étapes

Configuration

a Exemple de requête sql

Requête SQL directe sur les tables Oracle Quality Management

Étapes

Configuration

a Exemple de requête sql

Script d’extraction Python via le connecteur Oracle DB

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

Transformez Oracle Quality Management et renforcez la conformité dès maintenant

Votre modèle de données Quality Management

Votre modèle de données Quality Management

Attributs de la gestion de la qualité

Activités de gestion de la qualité

Guides d’extraction

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

Étapes

Configuration

a Exemple de requête sql

Requête SQL directe sur les tables Oracle Quality Management

Étapes

Configuration

a Exemple de requête sql

Script d’extraction Python via le connecteur Oracle DB

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

Transformez Oracle Quality Management et renforcez la conformité dès maintenant

Nous attachons de l’importance à votre confidentialité