ambigüité entre les taches de la conception génie logiciel et le management qualité

Bonjour amis concepteur
Voilà je suis développeur et concepteur logiciel, j’ai commencé à développer un logiciel de gestion complète d’une entreprise BTPH (achat, réception, stock, production, vente, banque….) depuis un an et demi, comme cette entreprise est ressèment créé et n’est pas très organisée niveau procédures de travail, documents et hiérarchie, pas de fiche de poste (Bon de réception, facture, livraison, dette, …….), je suis contraint à créer ces procédures et les former car l’entreprise possède plusieurs direction et magasin, parc engins, chantiers, mais je me suis retrouvé à faire un travail de création des service, recruter les responsables, création des procédures et documents (exemple de documents (Bon d’entrée caisse, bon de sortie caisse, Bon de justification dépense non justifié, créer des champs supplémentaires dans le bon de réception pour le relié à la facture et au BL pour obtenir les prix d’achat, procédure pour calculer le cout du transport, ……) ,une grande ambigüité pour moi car je me demande si sa fait partie du travail de conception du système d’information tout ça , d’après les méthodes enseigné en informatique (Merise, UML), en doit informatiser un système d’information manuel (qui fonctionne de façon manuel (Excel, registre…) pour le rendre automatique),mais comme y’a pas de travail manuel bien structuré qui permet a mon logiciel d’être alimenté des bons données, je suis forcé de les faire moi-même, es normal ou tout ce travail doit être fait par un autre service du genre management qualité, et moi je dois simplement automatisé ces taches la
J’espéré que c’est assez claire, car je vous avoue que c’est un grand mystère pour moi

S'il y a un qualiticien dans l'entreprise, travaille avec lui ! Il sera ravi de voir quelqu'un s'intéresser à son sujet et vouloir faire les choses bien.

Ton analyse du besoin que tu dois implémenter informatiquement te fait découvrir des carences organisationnelles dans l'entreprise. C'est au qualiticien de prendre alors les choses en mains, faire des audits, en rapporter à la direction qui prendra les décisions quant à l'organisation. S'il s'agit de réorganiser les méthodes de travail, la direction peut avoir son mot à dire mais c'est plus à travailler avec le qualiticien et les fonctionnels. Une méthode ou une procédure n'est jamais si bien appliquée que lorsqu'elle est établie par ceux qui doivent l'appliquer !

Bon courage d'un ancien responsable qualité et informatique d'une PME filiale d'un groupe de BTP.

Citation:

---

un autre service du genre management qualité

---

Il faut distinguer 2 aspects "qualité" :

1. au niveau du développement logiciel
2. au niveau de l'organisation de l'entreprise

Pour le 1), le responsable qualité vérifie que les développements sont menés conformément au plan d'assurance qualité logiciel (essentiellement contrôle de la documentation projet), par exemple existence d'un plan de dev, de dossiers de spécifications, de plan de tests ...

Pour le 2), les démarches qualité mises en place dans l'entreprise (pouvant aller jusqu'à la qualification ISO 9000) visent à couvrir l'ensemble des aspects organisationnnels comme "procédures de travail, documents et hiérarchie".

Donc d'aprés ce que j'ai compris c'est pas a moi (concepteur logiciel) de créer les procédures et les documents, mais le probléme c'est que les données réconlté par les documents et les procédure fixé par le SMQ doivent étre conforme au données demandées par le logiciel, ce qui pousse le concepteur a adapté ces procédure et documents et meme la hiérarchie pour étre exploitation dans le logiciel, je crois qu'il y'a des beaucoup de taches communes entre les deux service et sa arrive souvent qu'ils rentre dans des conflit vu que les visions ne se converge pas en général

Citation:

---

les données réconlté par les documents et les procédure fixé par le SMQ doivent étre conforme au données demandées par le logiciel

---

Si c'est un logiciel maison en cours de conception, je dirais que c'est plutôt le contraire !

Si c'est un logiciel du commerce acheté par l'entreprise, c'est peut-être à l'organisation de s'adapter au logiciel.

Quoi qu'il en soit, c'est au service qui gère le système de management (qualité, sécurité, environnement), de faire son boulot en terme d'élaboration et d'amélioration des procédures, méthodes, formulaires... à appliquer et à employer dans l'entreprise. Et ce service ne peut bien entendu pas ignorer les contraintes imposées par les logiciels en place.

Mais, dans le cadre d'un développement d'un logiciel interne, c'est à l'équipe de projet informatique de prendre en compte les contraintes imposées par les procédures, méthodes et formulaires existants, quitte à discuter de leur pertinence et de leur amélioration éventuelle grâce à la mise en oeuvre du nouveau logiciel.

Par exemple, si actuellement existe un formulaire papier qui circule entre différents responsables pour une série de validations, le logiciel pourra prévoir cette validation informatisée, ce qui peut changer la structure du formulaire imprimé.

Petite anecdote personnelle...
À mes débuts de qualiticien, nous récupérions un système qualité du groupe auquel appartient la filiale qui m'employait et nous avons examiné si les procédures écrites ailleurs étaient applicables directement chez nous. Il y avait un formulaire papier auto-carbonné en 4 exemplaires dont 1 était systématiquement jeté chez nous car notre structure hiérarchique était plus simple. Nous avons alors créé notre propre formulaire et adapté la procédure. Nous en avons profité pour revoir complètement la structure du formulaire pour en éliminer tout ce qui ne nous servait pas, ce qui l'a rendu plus clair et plus utile.

Bonjour,

Il n'y a pas d'ambigüité entre les taches de la conception d'un logiciel et le management qualité.
A condition de considérer les points suivants.
Contrairement à ce que semble dire ton prof d'informatique le but de Merise/UML ou la mission implicite d'un concepteur de SI n'est pas je cite "d'automatiser (avec un ordinateur) des tâches manuelles" .

Un concepteur de système d'information est tout à tout à fait dans son rôle s'il est amené à concevoir des procédures ou des formulaires papier pour remplacer des procédures encore moins efficaces telles que : "taka demander à Georges, il sait où sont rangées les factures " ou pour remplacer des procédures de recollement des factures, des BL et des commandes instanciées/implémentées ainsi : "Martine pense que ça doit être la grosse commande qu'on a reçue le jour où il a fait si chaud , tu te souviens... , c'était avant la fête des mères , etc...) .

SI le cahier des charges est triple : a) diminuer le bordel de gestion, ne pas dépenser un rond et c) faire en sorte que Georges et Martine soient moins emm... et si, d’autre part, le modèle Merise/UML du système cible démontre à tous que l'objectif sera atteint par le simple ajout d’un champ sur un formulaire pour faciliter le recoupement de l’information, alors on doit conclure que le concepteur du (nouveau) SI est un génie.

Tout ceci pour dire qu'en fonction des objectifs d'amélioration du SI, les résultats de la conception du SI peuvent être soit une "simple" procédure papier, soit un "simple" template de fichier Excel " soit des "simples" calculs numériques d'approvisionnement de stocks fait sur une machine ( pourquoi pas un ordinateur) , et pourquoi pas aussi un mix des 3.

Informatisation ou pas, ce n'est pas le rôle du responsable qualité de définir le format des factures, celui des bons de livraison, ou les règles d'approvisionnement des stocks. Chacun son boulot. Si les comptables ou les gestionnaires des stocks sont des bras cassés, il faut les virer.
S'agissant des conflits potentiels informaticien/qualiticien, là encore il faut en revenir au cahier des charges et aux objectifs. Si le responsable qualité demande à ce que l'informatique puisse conserver (archiver) les factures pendant 10 ans et les résultats de tests faits sur l'avion pendant 30 ans et que l'informaticien dit qu'il n'est pas d'accord , il faut virer ce dernier. SI le calcul fait par l'informaticien (dé)montre que le disque dur à 50 euros acheté par le client dont l'utilisation est obligatoire par contrat, ne pourra pas contenir ces données, alors c'est un autre débat : un débat entre avocats.

Si le patron d'une organisation décide de revoir/améliorer tout le fonctionnement de son organisation sans mettre le responsable qualité dans la boucle de définition du cahier des charges du Nouveau SI, il faut virer le patron !
Si le responsable des 150 camions de l'entreprise affirme que les coûts de transport sont au minimum, qu'il connait ses chauffeurs et camions par cœur et que tout est noté dans son carnet noir, et que de son coté le responsable qualité affirme (démontre) qu'il n'y a jamais d'erreurs de livraison et que l'organisation des tournées est optimale, Il faut virer le responsable qualité ou donner une prime au gestionnaire, c'est au choix.

Pour conclure, il me semble que dans la problématique que tu soulèves, il manque quelqu’un (à embaucher ?!) pour définir les objectifs du nouveau Système d'information et montrer les coûts & avantages du système cible par rapport au système existant. Ces 2 SI devraient pouvoir se modéliser en Merise / UML.