Comment mesurer l’efficacité des mesures prises contre les non-conformités ?

Indicateurs de qualité des solutions anti-non-conformités

Cet article a été rédigé en réponse à une question d’organisation posée par l’un de mes lecteurs.

Si vous aussi, vous avez à poser une question intéressante, ou si vous souhaitez partager vos réflexions,  je me ferais une joie de les publier ou simplement d’échanger entre nous.

Toutes vos suggestions sont les bienvenues. Contact en bas de l’article

Qu’est-ce qu’une non-conformité ?

Une non-conformité est le résultat d’une comparaison entre un produit fabriqué et la norme suivi selon les spécificités imposées par un organisme de normalisation ou une procédure interne.

Une non-conformité concerne également toute la documentation qui doit respecter des normes rédactionnelles et des processus de création et de mise à jour.

La correction de la non-conformité

Quand une non-conformité est détectée, c’est généralement au cours de la fabrication du produit ou d’un défaut dans le résultat, vérifié après coup.

La prise en charge de la ou des solutions à apporter est de la responsabilité d’un ou de plusieurs acteurs internes à l’organisation :

• Le service Qualité en est le principal
• Le service Maintenance
• La Production, en usine
• Le Bureau des Méthodes
• Le Bureau d’Études
• Le Service R&D
• ou tout autre service selon l’organisation interne.

La non-conformité est enregistrée, puis corrigée pour éviter qu’elle ne se reproduire.

Comment contrôler la qualité de la solution

1. L’intervalle entre deux non-conformités

Une fois la mesure correctrice décidée et mise en place, le seul moyen de vérifier l’efficacité de cette mesure est d’attendre qu’une nouvelle non-conformité identique ou proche de la première non -conformité se produise.

Le temps entre les deux non-conformités est un indicateur.
Plus il est long et plus la mesure a joué son rôle.

Si, bien sûr, aucune non-conformité ne revient, c’est que la mesure était idéale.

2. Le nombre de non-conformité

Le nombre de non-conformités sur une certaine durée est également un indicateur.

Si la fréquence de l’apparition des non-conformités augmente alors c’est que la mesure a été efficace, bien qu’incomplète.

3. La norme

La ou les mesures à mettre en place dépendent des moyens à déployer après l’analyse des causes de la non-conformité.

Pour être conforme, il y a la mesure de la déviation par rapport à une norme.

Comme la norme ne peut être modifiée, ce sont donc les processus et les outils du respect des normes qui sont donc à améliorer.

Philippe Garin, plus de 20 ans de management en entreprise

Pour plus de conseils, contactez-moi : phgarin@gmail.com

Pour en savoir plus :

Inscrivez-moi à la Newsletter (recommandé)

Nom Prénom(obligatoire)

Email(obligatoire)

Envoyer

Δ

En complément :

Origine et Prévention des risques sur un site industriel
La gestion de la réclamation
Insatisfactions et suggestions des clients : Les objectifs

Étapes de la qualification d’un logiciel
Vérification des comptabilités informatisées
Formulaires Qualité

Insatisfactions et suggestions des clients : Les objectifs

Les objectifs qualitatifs et quantitatifs concernent tous les acteurs d’une entreprise et pas seulement les commerciaux, comme nous venons de le voir dans les articles Gérer l’insatisfaction client et Gérer les suggestions des clients.

Sommaire :

1. Gérer les insatisfactions des clients
2. La relation avec le commercial : source d’insatisfactions
3. Insatisfaction client : Les causes financières
4. La gestion de la réclamation
5. Gérer les suggestions des clients
6. Insatisfactions et suggestions des clients : Les objectifs

Il convient donc de donner de tels objectifs à chaque personne ou/et à chaque service.

Une partie de la rémunération des salariés peut être liée, partiellement, en fonction du degré d’attente de ces objectifs.

Exemples d’objectifs par service :

• Pour le commercial, cela peut être, le nombre de commandes ou de lignes de commandes.
• Pour le SAV, le délai entre l’enregistrement de la réclamation et son règlement.
• Pour le service livraison : la capacité à fournir des livraisons totales et de diminuer le nombre de livraisons partielles.
• Pour la fabrication, le respect des instructions de fabrications et la diminution du nombre de produits défectueux.
• Pour les achats, la qualité des produits et services achetés, en conformité avec ses propres spécifications.

Parmi les critères qualitatifs, se trouve le respect des normes du marché ou définies par l’entreprise, la courtoisie, la ponctualité, la propreté, etc.

Si vous avez à partager vos réflexions, émettre des commentaires sur vos réflexions, je me ferais une joie de les publier ou simplement d’échanger entre nous. Ce serait ma satisfaction de prendre en compte vos suggestions.

Philippe Garin, plus de 20 ans de management en entreprise

Pour plus de conseils, contactez-moi : phgarin@gmail.com

Pour en savoir plus :

Inscrivez-moi à la Newsletter (recommandé)

Nom Prénom(obligatoire)

Email(obligatoire)

Envoyer

Δ

En complément :
Inventions grâce à la perception du temps
Méthode SBAM pour booster sa relation client
Comment retenir et valoriser ses propres idées

Pourquoi les propositions, recommandations, nouvelles idées sont-elles souvent refusées ?
Choix de projets : Méthode de la moyenne pondérée
Prise de décision : 10 méthodes

Autres Management et Organisation :

Récapitulatif 15 Management
Récapitulatif 15 Organisation

Merise Méthode de gestion de projet obsolète

La merise est le fruit d’un cerisier appelé merisier.

C’est aussi le nom que porte une méthode de gestion de projet, destinée principalement aux grands projets.

Les systèmes informatiques ont évolué avec le temps et la méthode Merise est devenue inadaptée et obsolète. Elle est, de fait, remplacée par d’autres méthodes.

La caractéristique principale de cette méthode est la séparation des données et des traitements, quelle que soit la phase du projet dans laquelle on se trouve.

De nos jours, les données sont associées à des traitements intrinsèques aux données. Il ne viendrait à l’idée de personne de programmer un traitement pour vérifier que le 30 février est une date inexistante, par exemple.

Tout, cependant, n’est pas à jeter et certains éléments de la méthode, lorsqu’ils sont bien assimilés peuvent servir dans la compréhension et l’approche d’un projet.

Tout d’abord, les trois phases de Merise sont :

1) L’étude préalable

2) L’étude détaillée

3) L’étude technique

L’étude préalable

permet de modéliser les besoins en termes de traitements et de données avec :

• MCT ou Modèle conceptuel des traitements
• MLT ou Modèle logique des traitements
• MCD ou Modèle conceptuel des données
• MLD ou Modèle logique des données

Le fait de décrire les traitements principaux puis détaillés séparément des données permet une représentation intellectuelle qui permet de savoir de quoi on parle. Bien sûr, les traitements inhérents aux données ne seront plus représentés et laisseront la place aux traitements d’interactions entre les flux.

L’étude détaillée

La deuxième phase permet de détailler chacune des fonctions à traiter.

A retenir dans cette phase pour les projets actuels est la séparation entre les spécifications fonctionnelles décrites par la maîtrise d’ouvrage, plus générales, que celles décrites par la maîtrise d’œuvre qui doit aller dans le détail le plus fin.

L’étude technique

La troisième et dernière phase permet de définir les moyens techniques à mettre en œuvre.

Là encore, les matériels et systèmes ont évolués. Leur nombre est réduit. Seules quelques systèmes de base de données et quelques langages de programmation ont survécus.

Néanmoins, il convient toujours de s’intéresser aux dispositifs informatiques qui vont prendre en charge les données et les traitements. Les procédés de programmation restent toujours à décrire ainsi que la formalisation des textes d’aide, de support utilisateur ainsi que l’environnement technique.

Philippe Garin, plus de 20 ans de management en entreprise

Pour plus de conseils, contactez-moi : phgarin@gmail.com

Pour en savoir plus :

Inscrivez-moi à la Newsletter (recommandé)

Nom Prénom(obligatoire)

Email(obligatoire)

Envoyer

Δ

En complément :

Introduction à la méthode MERISE
Approche Bottom-up
Approche Top-down

Données
Langage
Base de données

Java un langage et non une danse
Projet pierre fondamentale de l’informatique
Programmation Quick and Dirty

Autres Informatique :

Récapitulatif 4-1 Informatique
Récapitulatif 4-2 Informatique
Récapitulatif 5 Informatique

Applications point d’entrée sur le Lexique informatique de Philippe Garin

Applications point d’entrée sur le Lexique informatique

source : Apple

Ajout de la rubrique Applications comme point d’entrée pour visiter le

Lexique informatique de Philippe Garin

Philippe Garin, plus de 20 ans de management en entreprise

Pour plus de conseils, contactez-moi : phgarin@gmail.com

Pour en savoir plus :

Inscrivez-moi à la Newsletter (recommandé)

Nom Prénom(obligatoire)

Email(obligatoire)

Envoyer

Δ

En complément :

Projet sur le Lexique informatique de Philippe Garin
Spécification
Logiciel tout ce qui tourne autour sur le Lexique informatique de Philippe Garin

Moyens mnémotechniques de création de mots de passe
Quand phonèmes et graphèmes rendent la langue française difficile
Application du schéma directeur

Autres Informatique :

Récapitulatif 4-1 Informatique
Récapitulatif 4-2 Informatique

Spécification

Pas de développement d’applications informatiques sans de bonnes spécifications.

La définition se trouve dans

Le lexique informatique de Philippe Garin

Philippe Garin, plus de 20 ans de management en entreprise

Pour plus de conseils, contactez-moi : phgarin@gmail.com

Pour en savoir plus :

Inscrivez-moi à la Newsletter (recommandé)

Nom Prénom(obligatoire)

Email(obligatoire)

Envoyer

Δ

En complément :

Génie informatique
Introduction à la méthode MERISE
Méthode Jackson de développement

La compatibilité en informatique, c’est quoi ?
Méthode Yourdon : Éléments des schémas
Programmation Quick and Dirty

Autres Informatique :

Récapitulatif 4-1 Informatique
Récapitulatif 4-2 Informatique

De la planification d’un projet

La plaie pour un chef de projet est le changement dans les spécifications.

La hiérarchie ou le client demande des modifications, des ajouts dans les spécifications. Cela se produit souvent à la vue des résultats des tâches, qu’elles soient terminées ou pas.

Si ces demandes de changements sont mineures, alors leur intégration ne fait qu’ajouter un peu de travail.
Par contre, elles peuvent mettre en cause la durée du chemin critique et donc la date de fin du projet. Un avenant au contrat pour le client externe est alors indispensable, ou une communication écrite avec un retour validé par la hiérarchie interne.

Il existe des tâches qui sont communes à toutes les phases. Leur durée est alors estimée comme un pourcentage de la tâche.
Par exemple, le contrôle qualité et la documentation d’un programme représentent autant que la durée de la programmation, soit 50% de la tâche.

Des Outils existent pour aider à la planification de projets. Se pose alors la question de l’échelle de temps à utiliser.

Pour une planification sur deux ans, le détail se fait au niveau de la semaine.

Pour une tâche T qui est prévue de durer quatre semaines, il vaut mieux planifier quatre tâches d’une semaine, avec le même libellé auquel on ajoute le rang de la semaine, T1 à T4. Ce principe permet de mieux suivre l’avancement de la tâche et des indisponibilités et donc des retards potentiels.

Si on sous-estime une tâche, on reste sous-estimé.

Si on surestime une tâche, il n’y a pas de compensation.
C’est la théorie des gaz parfaits : le gaz occupe toute la place disponible !

Le chef de projet doit prévoir des tâches fictives pour lui permettre des durées de réserve, des tampons de temps qu’il utilisera lorsqu’il sera nécessaire de compenser un retard et/ou faire face à un imprévu.

Attention de faire en sorte que ces tâches n’apparaissent pas dans les documents fournis aux collaborateurs dans le projet, toujours à cause de la théorie des gaz parfaits, sinon il utilisera ce tampon et le chef de projet n’aura plus de marge de manœuvre.

Si le tampon n’est pas utilisé alors on peut accepter des modifications de spécifications plus importantes sans remettre en cause la date finale prévue du projet à la satisfaction du demandeur.

L’expérience prouve que le pourcentage de disponibilité d’un collaborateur sur un projet est de l’ordre de 50%. Dans de rare cas, il atteint 70%.
La planification se fait donc en deux temps :

• Tout d’abord, la durée de chaque tâche est calculée avec une disponibilité de 100%, c’est la durée de la tâche.
• Ensuite, la planification de la tâche est faite avec le degré de disponibilité, soit 50%.
• Une variante consiste à présenter le projet avec une planification prenant en compte une disponibilité à 70% et à ajouter 20% à la durée globale du projet.
  Cette variante est à l’usage du client ou de la hiérarchie, jamais à celle des collaborateurs dans le projet

Le syndrome des 90% est l’idée que se font bon nombre de personnes sur le degré d’achèvement d’un projet.

Il faut autant que temps pour les 10% restants que de temps pour faire les 90 premiers pourcents.

Contre cela, il ne faut pas se baser sur les impressions des gens. Les informations orales ne suffisent pas. Il faut se baser essentiellement sur les rapports d’activité écrits des collaborateurs au fur et à mesure de l’avancement du projet.

Ce flou des 90% est du principalement à la mauvaise identification des tâches.

Une tâche est mal identifiée si son résultat est mal identifié.

Philippe Garin, plus de 20 ans de management en entreprise

Pour plus de conseils, contactez-moi : phgarin@gmail.com

Pour en savoir plus :

Inscrivez-moi à la Newsletter (recommandé)

Nom Prénom(obligatoire)

Email(obligatoire)

Envoyer

Δ

En complément :

Du découpage d’un projet en tâches
Mesures à prendre en cas d’écart dans le planning d’un projet
Ajouter des ressources en cours de projet ou le principe chinois

Règles et axiomes d’un chef de projet
Management de projet : 9 erreurs les plus courantes du Chef de projet
Estimez la charge de travail, le coût et l’implication à leurs justes valeurs

Autres Informatiques :

Récapitulatif 1 Informatique

Méthode Jackson de développement

Jackson a inventé tout un système qui a servi pour le développement informatique.

Andrew Jackson

I. Etude technique

A. Introduction

B. Modèle physique des données

C. Conception détaillée du logiciel

1. Conception de l’architecture du logiciel

a) Typologie des fonctions types

(1) Spécifications utilisateurs

• • Fonctions du logiciel
  • Description de l’écran
  • Description du traitement
  • Diagramme de répartition des tâches homme / machine
  • Caractéristiques de fonctionnement
    • (i) Facteurs relatifs à l’environnement d’exploitation
    • Confidentialité, couplabilité, maniabilité, robustesse
    • (ii) Facteurs liés à l’environnement de maintenance et de suivi
    • Maintenabilité, adaptibilité, portabilité

(2) Contraintes techniques

b) Définition de composantes types

Primitives technologiques, fonctionnelles

(1) Niveaux d’abstraction

Couche conceptuelle, logique, physique

(2) Couplage / Cohésion

• • (a) Couplage
    • (i) 1er niveau de couplage – data coupling
    • (ii) 2ème niveau de couplage – stamp coupling
    • (iii) 3ème niveau de couplage – control coupling
    • (iv) 4ème niveau de couplage – content coupling
  • (b)Cohésion
    • (i) 1er niveau de cohésion – functionnaly cohesion
    • (ii) 2ème niveau de cohésion – séquential cohesion
    • (iii) 3ème niveau de cohésion – communicational cohesion
    • (iv) 4ème niveau de cohésion – procedural conhesion
    • (v) 5ème niveau de cohésion – temporal cohesion
    • (vi) 6ème niveau de cohésion logical cohesion

c) Modèles de logiciel

Modèle logique, physique

d) Directive d’utilisation

e) Directive d’exploitation

f) Directives de développement

2. Analyse du logiciel

Type traitement, entrée / sortie

D. Stratégie de production du logiciel

1. Planification de la production du logiciel

Définition des tâches, ordonnancement, affectation du personnel, charge de réalisation, réservation des moyens matériels.

2. Stratégie / planning de qualification du logiciel

Intégration descendante, ascendante

II. Production du logiciel

A. Introduction

B. Codage et documentation interne

C. Analyse des modules par inspection structurée

D. Conception des jeux d’essais internes

E. Intégration et tests internes

F. Coordination avec la confection des jeux d’essais

G. Etablissement de la documentation

III. Tests

A. Introduction

Objectifs, objets, participants, tests effectués tout au long du cycle de vue du produit

B. Qui exécute les tests

Analyste-programmeur, utilisateur, centre de calcul, centre de contrôle

C. Définition des procédés de tests

Moniteur de test

1. Analyse statique

a) Inspection

Préparation, exécution, correction

2. Analyse symbolique

3. Analyse dynamique

a) Approche boite noire – tests fonctionnels

Tests aléatoires, d’incidents simulés, de domaine

b) Approche boite blanche – tests structurels

Taux de couverture, branche de programme, de chemin, de décision, contrôleur de déroulement (débugger)
Couverture des instructions, des branchements, des circuits

D. Stratégie de test

1. Méthode globale

2. Méthode descendante

3. Méthode ascendante

4. Méthode mixte

E. Phases de test

1. Test d’élément

2. Test d’intégration

Test d’intégration pure, étendu

3. Test du système

4. Test d’acceptation

a) Test en laboratoire

b) Test d’installation pilote

c) Test d’exploitation en parallèle

5. Test de sécurité / de panne

6. Autres tests

IV. Méthode de structuration Jackson

A. Introduction

B. Formalisme

Structogramme

C. Principes de base

Structurer les données, le programme, lister et attribuer les opérations, écrire le teste structurel / pseudo-code / programme

1. Introduction

2. Structure des données

3. Structure du programme

4. Liste / attribution des opérations

5. Ecriture du texte structurel / pseudo-code / programme

D. Types de programmes

1. Programme de base

2. Traitement de groupes

3. Traitement des concordances / matching

Philippe Garin, plus de 20 ans de management en entreprise

Pour plus de conseils, contactez-moi : phgarin@gmail.com

Pour en savoir plus :

Inscrivez-moi à la Newsletter (recommandé)

Nom Prénom(obligatoire)

Email(obligatoire)

Envoyer

Δ

En complément :

Les étapes du développement d’application
Organisation de la qualification en développement informatique
Fonction de développeur

Fonction Analyste Programmeur
Java un langage et non une danse
Limites et réalités du partenariat pour un développement informatique spécifique

Autres Informatiques :

Récapitulatif 1 Informatique