DEPLOIEMENT d'un SMQ

 

La question qu'il faut se poser avant ou après la description des processus est de savoir comment déployer ? Parce que cela soulève beaucoup de sous questions pas très faciles.

 

Le risque est bien connu : Les documents remplissent une étagère et l'adhésion des salariés aux processus n'est pas réalisée.

 

La structure de l'évaluation de la norme ASPICE semble suggérer de mettre en place les bonnes pratiques et de les transcrire ensuite. Sauf qu'il faut bien un support materiel pour fixer d'abord la liste des pratiques, le cadre général des flux de données, et des support de formation.

 

Faut-il déployer chaque processus, les uns apres les autres ? Chaque processus fonctionne en harmonie avec les autres. Si l'ensemble des processus n'est pas décrit rapidement, la description d'un processus et son activation fait que des données d'entrées proviennent d'un nuage et les données de sorties retournent dans un autre nuage. L'ensemble peut paraitre incohérent et se trouve discrédité.

 

Si l'ensemble des processus est décrit, il a plus de chance d'être plus stable, l'effet de chantier est atténué. En revanche, la marche peut paraitre énorme, elle demande du temps d'assimilation. La gestion des changements peut être difficile.

 

C'est une stratégie à définir par les dirigeants de l'entreprise. Mais un conseil peut être appliqué, on peut commencer par des processus dits "support".

 

Auparavant, des informations fondamentales doivent etre récoltées. Elles serviront à la compréhension sans ambiguité de toutes les communications inter services.
1)Les abbréviations sont elles uniques pour l'ensemble des métiers de l'entreprise ? Sont-elles dans une table centralisée ?
2)Y a t-il un glossaire des termes techniques avec la traduction dans les diverses langues utilisées par l'organisation ?
3)Les trigrammes des personnels sont-ils définis ? Cela évite les fichiers nominatifs.
4)Les postes sont-ils décrits en terme de taches à accomplir ? Cela aide à comprendre les processus existants mais qui ne sont pas formalisées, ils sont intuitifs.
5)Le périmètre : Quels sont les personnes concernées et les processus envisagés ? Quels sont les projets qui vont deployer les processus ? (Voir plus bas le paragraphe du reuse)
6)Quel est le calendrier souhaité du déploiement et de la certification ? Un premier audit a t-il été mené ?
7)Qui porte la conduite de la certification ? Le service assurance qualité est il indépandant du management des projets ? La question peut sembler incongrue, mais elle a deux origines : D'abord si cette condition n'est pas remplie, le niveau de maturité de l'Assurance Qualité tombe à 0. Ensuite l'assurance qualité vise des objectifs à moyen ou long terme, alors que le management de projet se soucie de la livraison au client.

 

Les processus support:
1)Gestion de résolution des problèmes; parce que pour en arriver à la décision de se structurer, une entreprise a surement des problèmes à résoudre.
2)Gestion documentaire ; une source d'efficacité est de savoir où se trouvent les documents, en adoptant une série de conventions.
3)Gestion de configuration pour les logiciels et pour les produits (nomenclatures).
4)Gestion des risques projets.
5)Processus d'assurance qualité ; initialisé par une déclaration de politique générale sur la qualité.
6)Gestion des changements.

 

Deuxième lot de processus : ce qui peut améliorer la vision client :
1)Définition des projets, étude des besoins des clients, réponse aux appels d'offre.
2)Processus de livraison.

 

Troisième lot de processus : ce qui peut améliorer la gestion des fournisseurs
1)Gestion des achats.
2)Processus de revues.

 

Et enfin rentrer en profondeur dans les processus de dévelopements internes, Systèmes et Logiciels.

 

Les écueils du déploiement.

 

1)La motivation des directeurs. Si des directeurs ne sont pas les premiers à accepter les changements. Par zèle, toute la hiérarchie descendante ira encore plus loin que le directeur lui même. Par exemple, dans une grande entreprise internationale, les revues étaient mal acceptées jusqu'à ce que les directeurs aient une prime proportionnelle au nombre de revues.

 

2)La résistance au changement. Elle est tout à fait compréhensible. Personne ne souhaite se trouver en situation d'échec, donc les gens ont "tendance" à reproduire ce qui les a fait réussir auparavant. C'est leur propre capitalisation. Il faut bien prendre conscience de trois choses:
De la difficulté de comprendre et faire fonctionner des outils développés par d'autres entreprises avec les lacunes qu'elles ont laissées.
De la vitesse de changement des matériels et composants que les ingénieurs doivent intégrer.
Du fait que certains sont plus méfiants que d'autres sur l'expérience des autres. Les plus difficiles à convaincre sont ceux qui n'ont jamais connus de situation d'échec, ou qui ont négligé de les interpreter comme tel.

 

3)L'aspect bureaucratique. Très peu de temps après le déploiement des processus, les plaintes montent vite sur le fait que les gens passent du temps à produire des documents au lieu de travailler sur le produit. C'est pourtant la même chose. Cela ne fait que mettre en lumière la défaillance de l'ancien mode de travail. Produire un document ce n'est pas de la bureaucratie, c'est le coeur de l'Ingénierie. Cela permet de:
capitaliser,
réutiliser,
partager les décisions avec les experts,
utiliser le "cerveau collectif" de l'entreprise,
corriger les erreurs au plus tôt avant que leurs impacts financiers s'aggravent,
et parer aux accidents de la vie.

 

Pour toutes ces raisons, certains disent que l'Assurance Qualité ne coute rien.

 

Il y a en effet des entreprises qui ont acquis des réflexes documentaires par les obligations légales ou commerciales et d'autres qui découvrent ces pratiques.
Pendant la phase de déploiement, il est utile de capitaliser sur les objections, c'est à dire les enregistrer et conserver les réponses à apporter. Lorsqu'une équipe de reviewers est constituée, une réunion par semaine sur les objections me semble pertinente.

 

 

Le sujet du REUSE


Cela réponds à la question souvent crument posée par des auditeurs : << Mais comment font-ils pour sortir les produits ??? >>
Toutes les entreprises reposent sur leurs expériences et donc sur la réutilisation de projets passés pour construire les nouveaux. Ainsi les contextes de fonctionnement des produits et leur fonctionalités deviennent de plus en plus intuitives, des racourcis sont pris dans la gestion de projets, on oublie leurs justifications et on reprends des risques.
Ce qui est une force au départ, devient un problème lors du déploiement et de la preuve d'un Système de Management de la Qualité. Parce que la certification va demander de prouver que chaque bonne pratique du cycle en V a été réalisée ou son contournement justifié. C'est quasiment un effort d'introspection. Cet effort a un cout, avant de réutiliser tous les Work products (Resultats des processus) et de repartir en mode reuse pour enfin revenir sur cet investissement. C'est pour cette raison qu'il y a un lien avec la question citée plus haut à propos du choix du projet.
Le Reuse est aussi à l'origine d'une confiance en l'organisation et ses hommes qui sous estiment le temps de mise en place du SMQ et le résultat des audits. Je peux vous affirmer que j'ai vu des chefs de projets craquer en réunion de synthèse suite à un Audit ASPICE.

mailto:gerald.mauboussin@gmail.com

 

Page crée le 29.10.2019 - - - - - Dernière mise à jour 06.12.2019
Cet article est soumis aux Lois du Copyright.
Seules les sociétés qui m'ont employés ou qui vont m'employer ont le droit de l'utiliser..