1. Introduction

La notion d’évènement qualité a été introduite pour répondre aux deux problématiques ci-dessous :

• Tracer les différents problèmes autour de la qualité produit en centralisant le traitement et en ne générant une ou n NC que si c’est nécessaire
• Intégrer la qualité système en centraliser le suivi et pouvoir enclencher si nécessaire de la qualité produit

Dans le module qualité d’Hélios le point d’entrée a toujours été une non-conformité à partir de laquelle il était possible de prendre les décisions au sujet des lots incriminés par le problème rencontré. Chaque non-conformité créée nécessitait en plus de tracer les actions curatives et correctives mises en œuvre pour traiter le problème.

Ce n’est pas le fonctionnement optimum car un défaut qualité peut entrainer la génération de plusieurs non-conformités pour traiter chacun des lots mais le suivi du défaut ne doit être effectué qu’une seule fois. Il est donc nécessaire d’adapter le processus à ce qui existe dans les entreprises.

Le choix a été d’introduire cette notion d’évènement qualité qui est le point d’entrée du processus et qui en finalité peut aboutir ou non, à la création d’une ou plusieurs non-conformités pour traiter les lots. Dans le déroulé du processus nous aborderons les notions propre au domaine de la qualité tel que

• QQOQCCP : Cette méthode consiste à se poser les questions utiles pour comprendre et résoudre l'évènement qualité.

Quoi ?
Le Quoi définit le sujet à étudier, le problème à régler. C'est le point d'entrée de la démarche. dans Hélios ERP, il peut s'agir d'un OF, d'un Processus ou Procédé, d'une Livraison ou d'une Réception....
Qui ?
Le Qui spécifie l'acteur principale qui est concernée.  Le client, le fournisseur, l'ERP Hélios....
Où ?
Le Où indique l’endroit (physique ou virtuel) où l'évènement s'est produit (lieu, service, phase de production, ...). 
Quand ?
Le Quand définit la date de l'évènement (date de découverte ou date de l'évènement).
Comment ?
Le Comment fait référence à l'évènement qui a déclenché la découverte de l'évènement qualité : Audit, Contrôle, Rappel produit fournisseur....
Combien ?
Combien de produit sont concernés ? Le Combien permet de quantifier l’objet de la problématique en question et souvent d’en apprécier la gravité.
Pourquoi ?
Pourquoi l'évènement s'est il produit ?

• Les causes racines et les méthodes 5P / 6M
• Les plans d’actions et leur efficacité
• Le processus 8D
• La sécurisation des pièces

2. Les codificateurs du module "Evènement "

 Il est nécessaire d'avoir au préalable créés les codificateurs utiles à la gestion des Clients :

3. L'écran principal des Evènements 

L’écran de gestion des évènements qualité est accessible depuis le menu principal d’Hélios ERP (Evènement qualité)

Il est composé de trois partie :

1. Critères de sélection : Permet de filtrer les évènements à consulter => Saisir le filtre désiré puis sélectionner le bouton "Appliquer"
2. Liste des évènements : Liste des évènements filtrés selon les critères saisis et compétence de l'opérateur (restriction en fonction des types d’évènements).
3. Détail des sous évènements de l'évènement sélectionné : La création d’un sous évènement se fera dans le cadre défini par l’évènement. C’est sur un sous évènement que l’on viendra déterminer les causes du problème constaté et greffer les plans d’actions pour les résoudre. La sécurisation éventuelle des lots incriminés sera aussi déclenchée depuis le sous évènement.

Son ergonomie est celle des écrans de recherche filtre, c’est-à-dire qu’à l’ouverture il n’y a pas de données affichées. Il est nécessaire de cliquer sur le bouton appliquer pour charger les données qui correspondent aux critères sélectionné sur la partie gauche de l’écran

4. La toolbar du module "Evènements qualité "

4.1. Création d'un évènement 

Un évènement qualité est défini par sa nature, Hélios ERP possède 4 natures :

• •  Système : Lié à un processus ou procédé

    

  • Produit : Cette typologie d’événement, concerne essentiellement les évènements que l’on rencontre lors de la production des pièces

     Produit (Interne) : Lié à un OF, une Phase d'OF ou un Article,

    

  • Client : tracer un évènement qualité lorsque celui-ci a été constaté par un client : problème sur une pièce, BL, ….

     Client : Lié à un bon de livraison client ou à un client.

    

  • Achat : Lorsque la non-qualité est constatée pour un fournisseur ou un sous-traitant

     Achat : Lié à un Bon de réception ou un fournisseur ou un bon de réception de Sous-traitance ou à un fournisseur de sous-traitance.

    

La toolbar présente 4 icônes, un pour chaque nature. Sélectionner la nature en fonction de l'évènement qualité à saisir.

La création de l'évènement permet de saisir les réponses aux questions QQOQCCP.  Elle permet d'alimenter le formulaire suivant :

4.2. Modifier un évènement

Cette action permet de rouvrir la fenêtre de création de l'évènement pour modifier sont contenu et/ou compléter les notes.

4.3. Suppression

Il est possible de supprimer un évènement que s’il est en attente.

4.4. Note

4.4.1 Comment

Permet de modifier la note relative au Comment ? si l'opérateur a la compétence du type d'événement 

4.4.2. Constat

Permet de modifier la note relative au Constatation ? si l'opérateur a la compétence du type d'événement 

4.4.3. Pourquoi

Permet de modifier la note relative au Pourquoi ? si l'opérateur a la compétence du type d'événement 

4.5. Imprimer

Sélectionner le rapport à imprimer

4.6. Fichiers liés

Permet d'insérer des documents liés à l'évènement qualité, photo documents divers.

5. Le sous évènement qualité

A un évènement, il est possible d'associer plusieurs sous évènements. Ces sous évènements se font dans le cadre de l’évènement dont ils dépendent.

Il permet de préciser les informations pour les quatre natures d'évènement et types d'évènement.

5.1. La toolbar du sous évènement qualité

5.1.1. Création sous événement

5.1.2 Diffusion /Relance

Voir partie 5.5. Diffusion (5.5.3) 

5.1.3. Fichiers Liés

Permet d'insérer des documents liés au sous évènement qualité, photo documents divers.

5.2 Recherche de cause d'un sous évènement

La problématique client suivante est à l’origine de cette fonctionnalité :

• les clients imposent de suivre un processus 8D pour déterminer et résoudre les causes des problèmes qualité majeurs

A la fin de ce processus, un diagramme d’Ishikawa peut être renseigné. Il permet de mettre en évidence les causes du problème qualité analysé et la cause racine

La méthodologie employée pour mener cette recherche est la suivante :

• Méthodologie : 6M / 5P
  • Approfondir un fait sur un axe d’analyse en répondant à 5 Pourquoi
  • Un axe d’analyse est codifié via les familles de causes
    • Généralement : Moyen / Matière / Mesure / Machine / Milieu / Main d’œuvre
  • Le processus permet
    • De mettre en évidence les causes potentielles du défaut étudié
    • De vérifier les hypothèses
    • De retenir des causes
    • De dégager une cause racine

5.2.1 Création d'une recherche de cause.

Le formulaire est vidé et nécessite à minima la saisie d’une famille de cause via la liste déroulante. Le champ libellé est à renseigner avec la cas à analyser et la réponse au premier pourquoi peut être saisie juste en dessous.

La saisie de la première réponse libère la saisie pour répondre au deuxième pourquoi et met à jour la cause avec la première réponse saisie.

Le processus peut se répéter 5 fois mais ce n’est pas une obligation. La cause affinée correspondra à la dernière réponse saisie.

Si la cause affinée peut être à l’origine du problème alors on vient l’indiquer en cochant la case Potentielle.

Un processus de vérification doit être effectué par l’entreprise pour définir précisément sa catégorie. La cause pourra être non retenue, retenue ou être la cause racine du problème analyser.

La codification existante dans le module qualité, pavé traitement, est disponible pour venir codifier l’information.

5.3 Plan d'action d'un sous évènement

Les plans d’action permettent de résoudre les causes retenues ou racine mais aussi de mettre en œuvre un suivi ou des action préventives.

Lier à un sous évènement, un plan d’action sera constitué d’actions qui seront effectuées par des opérateurs ou des tiers extérieurs. Un plan d’action nécessitera la définition d’une clause d’efficacité qui devra pouvoir être mesurer. La finalité de la mesure est de déterminer si le problème a été corrigé ou si un autre plan d’action est nécessaire.  

Le diagramme ci-dessous présente les étapes qui seront présentés dans les paragraphes suivant.

5.3.1 Plan d'action 

Un plan d’action pourra être défini à partir d’un sous évènement. Il sera nécessaire de préciser sur le sous évènement la présence d’un plan d’action en cochant l’option correspondante sur le formulaire du sous évènement

L’ouverture de l’écran est effectuée via le menu des sous évènement présent sur le haut de la fenêtre ou via le menu contextuel si l’option a été rajouté aux raccourcis. Lorsqu’un plan d’action existe un double clic sur la ligne ouvre l’écran.

Un plan d’action est défini par

• Un pilote : Opérateur qui s'occupe du plan d'action 
• Délai de traitement en jours
• Objectif du PAC : but du plan d'action
• Efficacité : 4 valeurs possibles
  • A définir / Définie / Efficace / Non efficace
  • Valeur par défaut : à définir
• Si un critère d’efficacité est défini alors efficacité passe au statut définie. Pour cela il faudra
  • Codifier le critère
  • Saisir une date prévue ou le plan sera efficace
  • Décrire un moyen de mesurer l’efficacité

• Il ne sera possible d’indiquer que le critère l’efficacité est efficace ou non efficace que lorsque le plan d’action aura été terminé.
• Le statut du plan d’action est en attente. Il passera en cours lorsqu’au moins une action aura été associé au plan d’action

Les changements des valeurs « date fin prévu » et « date fin prévu efficacité » sont historisées dans les notes

5.3.1.1. Bouton lier 

Un plan d’action peut être créé pour traiter une ou plusieurs causes d’origine de la non-qualité.

Pour cela, un écran de lien accessible depuis la toolbar de l’écran permet d’accéder à un écran de basculement.

Celui-ci présentera sur la gauche les causes retenue ou racine déterminées précédemment et permettra de les lier.

• Les causes liées sont visibles sur une zone de détail du formulaire :

5.3.1.2. Bouton Action 

L’ensemble des actions est visible dans la grille du bas, accessible depuis le bouton de la toolbar

Les actions sont définies pour un plan d’action. Il peut y en avoir plusieurs de nécessaires pour traiter le plan et les intervenants sont soit interne soit externe.

La saisie d’un pan d’action permettra de passer le plan d'action au statut encours. Pour en saisir il est nécessaire de saisir :

• Un responsable de l’action
• Un type d’action à Codification
• Date de début de l’action et un délai à Date prévue de fin d’action
• Libellé de l’action
• Avancement
• Prise en compte
• Traité le / par
• Action corrective associée
• Action curative associée
• L’opérateur ou le tiers qui doit effectuer l’action
  • Sélection du type de tiers
  • En fonction du type alors précision du tiers
    • Si interne à Opérateur
    • Si client ou contact client à Le client concerné et le contact
    • Si Fournisseur ou contact fournisseur à Le fournisseur concerné et le contact
    • Si sous-traitant ou contact sous-traitant à Le sous-traitant concerné et son contact
• L’avancement est saisi manuellement par l’opérateur concerné. Cette information est consolidée sur le plan d’action pour déterminer l’avancement du plan d’action
• A la fin de l’action, la case traité doit être initialisée afin de terminer l’action. Lorsque toutes les actions d’un plan d’action sont terminées alors le plan d’action passe au statut terminé.

5.3.2 Suivi des actions

Pour permettre de suivre les actions en cours pour chaque opérateur responsable d’une action un indicateur a été mis en place qui indique le nombre d’action à traiter

• Concerne l’opérateur connecte, responsable de l’action
• Les actions non traités sont comptabilisées
• Les actions dont la date prévue de traitement est au plus tard dans 10 jours

Depuis cet indicateur il est possible d’ouvrir un écran dédié au suivi des actions affecté à l’opérateur.

5.3.3 Efficacité d'un plan d'action 

Pour finaliser le plan d’action il faut maintenant le solder. Pour pouvoir solder le plan d’action il faudra renseigner l’efficacité du plan d’action à traiter la cause de la non-qualité. Pour ce faire le processus ci-dessous est mis en place

• Lorsque le plan d’action est traité c’est-à-dire que chaque action est au statut traité

• Libération de la saisie de fin du PAC
  • Case à cochée soldée
  • Mise à jour auto
    • Date d’efficacité
    • Vérifiée par
  • Nécessite un commentaire de vérification
  • Mise à jour du champ efficacité
    • Efficace
    • Non efficace

5.3.3.1 Suivi efficacité

Sur le même principe que pour les actions, un indicateur et un écran de suivi ont été implémentés. L’indicateur est présent sur l’IHM principale et il prend en compte

• Les plans d’action concernant l’opérateur connecté (Pilote de l’action)
• Les plans d’action au statut traité mais non soldé
• Les plans d’action dont la date prévue d’efficacité est au plus tard dans 10 jours

Depuis l’indicateur, il est possible d’ouvrir un écran dédié Suivi efficacité

5.5 Diffusion d'un sous évènement

A un sous évènement il est possible de venir constituer une liste de personnes ou de tiers qui sont concernés par le sous évènement. Ces destinataires peuvent être liés pour action ou pour information. Le choix peut être fait parmi

• Les clients et les contacts clients
• Les fournisseurs et les contacts fournisseurs
• Les sous-traitants et les contacts sous-traitant
• Les opérateurs et les abonnés

Un écran de basculement permet de les associer au sous évènement. Le choix de la zone de basculement déterminera le type du lien (action / information)

L’information est présentée dans un onglet dédié au sous évènement.

5.5.1 Etats & Vue

Les états du module évènement sont accessibles depuis l’écran de paramétrage de la qualité existant. Une zone dédiée a été rajoutée pour permettre de les gérer.

Pour faciliter la création des états autour des évènements, une vue dédiée a été constituée. Elle vient consolider et agréger les données. La composition de la vue est la suivante :

L’une des finalités de la gestion des évènements est de répondre à la problématique de constituer un rapport 8D. Pour cela nous mettrons à disposition un état standard qui sera basé sur la vue ci-dessus et sur lequel nous devrons rajouter les informations ci-dessous à l’aide de sous états. Les tables concernés et le modèle physique ont été précisés

• Plan d’action / Recherche de cause
  • Pour un sous évènement il est possible de créer plusieurs Plan d’action à NC_EVT_LG_PAC
  • Pour un plan d’action plusieurs actions peuvent être définies à NC_EVT_LG_PAC_LG
  • Pour un sous évènement il est possible de créer plusieurs Recherche de cause à NC_EVT_LG_CAUSE
  • A un plan d’action on peut venir lier une ou plusieurs recherches de cause à NC_EVT_LG_PAC_LIEN

Pour les informations de sécurisation qui seront détaillées dans chapitre suivant, nous avons comme données

• Sécurisation et détail
  • Pour un sous évènement une seule sécurisation possible à NC_EVT_LG_SECU
  • Pour une sécurisation, plusieurs vérifications peuvent être nécessaires à NC_EVT_LG_SECU_LG
  • Pour une vérification, le champ TYPE_ACTION contiendra la suite à donner à la vérification
    • 0 à RAS
    • 1 à Non-conformité
    • 2 à Evènement qualité

Le lien entre la NC créée ou l’évènement créé suite à la vérification est stocké dans la table NC_EVT_SECU_LG_NCF

5.5.2 Diffusion

Un écran de paramétrage a été mis en place pour permettre de renseigner les états à utiliser lors des diffusions et relance. Il permet aussi de paramétrer le corps du mail.

Les fonctionnalités de diffusion et de relance sont accessibles depuis la toolbar des sous évènements

Les dernières dates de diffusion et de relance figurent dans le récapitulatif ci-dessus.

5.5 Sécurisation d'un sous évènement

Pour donner suite à un problème qualité majeur, un délai de 48h maximum est donné pour procéder à la sécurisation des pièces.

Lier à un sous évènement, la sécurisation s’appuiera sur l’information concernant de l’évènement ou du sous évènement.

Le but est d’isoler et vérifier la qualité des pièces produites ou encours de production suite à un défaut constaté. 2 cas sont possibles que nous allons traiter avec les termes suivant :

• Elément : la pièce posant problème n’est pas assemblée
• Produit : La pièce posant problème a été assemblé sur une autre référence

Pour chacun de ces 2 cas, 3 états de production sont possibles

• En stock
• En cours de production ou d’achat
• Livré

Ces différents cas seront traités au travers des termes et des onglets ci-dessous.

Les évènements sont de natures différentes mais les éléments concernés convergent vers une liste finie qu’il nous est possible de venir sécuriser grâce aux données issues de la traçabilité d’Hélios ERP.

Les points d’entrée proviennent essentiellement des évènements de nature produit mais un évènement système sur un procédé lié à un CDC sera traité de la même façon. Les éléments concernés par un sous évènement et pour lequel il ne pourra pas y avoir de sécurisation sont :

• Les consommables
• Les sous processus
• Les procédés standard
• Les sous évènement en saisie libre (pas de concernant lié à une donnée Hélios)

5.5.1 Principe

Le processus autour de la sécurisation sera :

• Détermination de l’élément concerné
• Détermination des critères de recherche
• Consolidation des données dans les 6 onglets de traitement
  • Fonctionnalité de lier manuel ou automatique
• Prise de décision sur chacune des lignes pouvant
  • Créer une non-conformité
  • Créer un évènement
  • Aucune action attendue

Le principe de la sécurisation est de venir déterminer une liste d’OFs à partir du contexte. En fonction de cette liste il en découlera les éléments et les produits et leur avancement donnera les répartitions dans les zones stock, encours et BL

5.5.2 Sécurisation produit

Si l’évènement est un de type produit alors il concerne généralement un OFs ou une phase d’OFs. Dans ces deux cas de figure, le critère pourra concerner l’OFs lié à l’évènement. Le second choix du critère sera l’élément concerné dans le sous évènement, dans ce cas-ci n’importe quel article, composant ou matière présent dans la nomenclature de l’article de l’OFs ou un CDC, document de GED, sous-traitant ou outillage présent sur une des phases d’une des gammes des articles constituant l’article porté par l’OFs. Pour les composants et les matières nous aborderons la problématique dans le chapitre suivant.

Si le choix du critère est basé sur un des articles de la nomenclature du dossier technique, alors pour affiner les recherches il faudra préciser soit une période, soit un lot ce qui permettra d’isoler les OFs sur lesquels peut se porter le problème. La règle choisie est que l’OFs de l’article est entré en stock dans la période initialisée. Cette liste-là alimentera le moteur de constitution des liens pour, à partir de la traçabilité des données, proposer les données à sécuriser.

Si le critère se base sur un des éléments de la gamme du dossier technique alors il sera nécessaire de venir initialiser une période pour permettre d’affiner la recherche. A partir de cette période et de l’élément du dossier technique (CDC ou Document ou Sous-traitant ou Outillage) une liste d’OFs sera constituée à partir des pointages effectués sur les phases des OFs où le critère est lié.

5.5.2 Sécurisation Achat

Une sécurisation sur un achat se produit lorsque le critère de sécurisation est un composant ou une matière. Dans ce cas-là, un critère doit être précisé

• Période
• Un numéro de lot
• Un numéro de BR

Le filtre déduit permettra de mettre à jour les 3 catégories de l’élément (composant ou une matière) en répartissant les commandes encours , le stock disponible et les BL de négoce dans les différentes catégories. Les produits seront les OFs contenant (existera une sortie de stock) l’élément correspondant au filtre positionné.

5.5.3 Lier/délier

La fonctionnalité Lier, permet d’appliquer le filtre et d’initialiser les différents tables qui permettront de traiter les lignes de sécurisation dans l’ensemble des onglets disponible.

Inversement, la fonctionnalité Délier supprime l’ensemble des liens effectués. Elle ne pourra être utilisée que si aucune action de type Non-conformité ou Evènement a été prise.

Pour chacun des 6 contextes de sécurisation il est possible de venir manuellement ajouter ou enlever les données.

Des écrans de basculement permettent d’effectuer les choix.

5.5.4 Statut de sécurisation

Une ligne de sécurisation est soldée lorsque qu’une action est définie

• RAS / Non-conformité / Evènement

Lorsque toutes les lignes de sécurisation sont soldées alors la sécurisation se solde automatiquement

Une fonctionnalité permettant de solder automatiquement l’ensemble des éléments des lignes de sécurisation est disponible depuis le menu de la fiche de sécurisation (Solder/Sé-solder).

Pour pouvoir activer la fonctionnalité il faut

• Posséder la compétence associé au type du sous évènement
• Si pas de compétence définie alors posséder la compétence définie sur le type de l’évènement

L’exécution de la fonctionnalité Solder sécurisation va Solder chacune des lignes du tableau de sécurisation avec

• Décision : RAS
• Date de l’action
• Opérateur réalisant l’action

L’ensemble des actions de sécurisation ayant été traitée la sécurisation se solde.

La fonction inverse existe. Elle permet de venir dé solder une entête de sécurisation soldée. Elle nécessite les mêmes compétences que celles précédemment citées. Le résultat n’affecte pas les lignes de sécurisation. Il faudra ensuite manuellement venir modifier les lignes dont l’action est RAS pour mettre en place l’action souhaitée.

5.5.6 Création de Non Conformité

5.5.7. Création d'évènement