Un “Ms Access-like” pour supporter une démarche PLM?

Posted on August 10, 2010

AccessPLMUn des premiers éléments à gérer dans une stratégie PLM ce sont des données. Que ce soit des méta-données ou des fichiers, c’est la qualité de cette gestion de données qui va représenter un facteur determinant sur la flexibilité et la performance de la solution mise en place. Compte tenu de l’importance de cette gestion de données, quel est le processus de reflexion sur un outil de gestion de données liées au produit dans le département d’une PME?

Typiquement on va prendre l’exemple d’un responsable de projet à qui l’on demande de mener une campagne de test sur un matériel qui doit répondre à des normes spécifiques de tenue en environnement climatique contraignant.

1. le tableur: le tableur est typiquement la première application à laquelle cette personne va penser, et par chance pour lui, en général Microsoft a bien fait son travail et a fait en sorte que la plupart des entreprises aient acheté une licence Office pour chacun de ses postes informatiques. Donc il renseigne toutes ses lignes de test, intègre des hyperliens pour faire référence aux documents précisant chaque condition à valider et il lance sa campagne de test. La campagne de test se déroule, Et pendant ce temps une modification a été demandée sur le produit et quelques points n’ont pas été validés lors des tests. Donc il reprend sont fichier Excel, renseigne tous les éléments, crée un nouvel onglet pour cette nouvelle version recopie tous les tests corrects, renseigne ceux qui doivent être refaits, etc…

Jusque la tout fonctionne à peu près bien, il a une petite équipe, il permet même à certaines personnes d’accéder à son fichier pour renseigner des résultats de test. Cependant il n’a pas une traçabilité convaincante et peu de contrôle sur l’intégrité de son fichier. De plus, il a du mal à suivre la gestion des changements dans le cas de modifications apportées au produit et sur les documentations dont le fichier fait référence.

2. Le L4G (langage de quatrième génération = mix langage de programmation avec un système de gestion de base de données-SGBD): Après plusieurs fichiers excels réalisés pour divers produits, il s’est aperçu qu’il a réalisé plusieurs fois le test pluie pour des produits qui partageaient un même boitier étanche. Il veut donc centraliser tous ces fichiers dans un même référentiel. Il décide alors de stocker tout cela dans une base de données. Il a vu que sur son PC il avait un logiciel qu’il n’utilisait jamais mais qui était intégré à Office: Microsoft Access. Il a donc dessiné son modèle de données et commence à le développer. Cependant il a rapidement besoin de compétences en programmation pour réaliser toute la logique et plus son projet avance plus la flexibilité de l’outil diminue. En plus, ils s’aperçoit qu’avec la quantité de données grandissante, sa base Access devient très lente en lecture.

En fin de compte il a une base Access qui lui permet de gérer ses essais sans trop pouvoir faire evoluer les méthodes, alors que l’entreprise a grandi et demande un plus grand suivi de workflows et de relecture etc… Il a entendu parler des solutions PLM et a vu dans des démonstrations que sa problématique était traitée. Il fait donc venir des vendeurs de solutions. Il va se retrouver face à des problématiques beaucoup plus larges qu’il n’espérait traiter. Son besoin qui était clair et restreint à son département devient pour ses interlocuteurs un projet pilote pour une future intégration élargie.

Quel était le réel besoin de cette personne? Cette personne avait en fait besoin d’un outil qui soit un peu plus spécifique que la solution Access. Un outil qui intègre SGBD, BPM (Business Process Management), formulaires et droits d’accès. Un outil qui puisse être configuré à patir d’un diagramme de type UML, en plus explicite (tout le monde n’est pas spécialiste de l’UML).

Si l’on reste sur des technologies Microsoft pour l’exemple, le but serait un outil tel que Microsoft Access avec une gestion graphique plus accessible (type MS Visio) pour manipuler les tables. Il faudrait que l’outil propose en plus un moteur de workflow avec la aussi une interface graphique. Un produit simple à déployer au sein d’une petite équipe. Ce produit serait déployé de manière indépendante dans chaque département de l’entreprise et permettrait, le jour venu, une intégration vers un seul et même environnement pour permettre une gestion complète du cycle de vie du produit à travers toute l’entreprise.

Un rève? Une usine à gaz? Sharepoint? Aras Innovator? C’est avant tout une reflexion que je me permets de partager.

Quel a été votre cheminement s’il a eu lieu à travers des outils tels que tableurs, système de gestion de base de données évolués? autres?

Yoann Maingon


 

Yoann Maingon

Yoann Maingon is an Entrepreneur and a PLM enthousiast. He is our main blogger at Minerva as he has been publishing articles about General PLM concepts and Aras Innovator for more than three years.

More Posts

  • Yannick

    Hello,

    Cette réflexion me semble valable pour de petites entreprises seulement. En effet, j’ai fait pas mal d’entreprise dans ma petite carrière (Et oui vive le Consulting) et aujourd’hui je suis dans une grande entreprise (+6000 personnes).

    A voir comment on travaille, j’ai analyser le réel besoin que nous avons. Cela peut paraître simpliste mais travailler ensemble n’est pas chose aisée entre les différents services 🙂

    Surtout que dans une grande entreprise, bien souvent chaque services devient au fil du temps tellement spécialisé dans son domaine qu’il devient très compliqué de dire que demain tout le monde devra travailler selon le même flux.

    C’est en fait quasi impossible de mettre en place ce type de stratégie. Tout cela pour en arrivé à mon idée qui est la suivante:

    Mettre en place un logiciel permettant à chaque service de modéliser son propre processus de travail et de déclarer des “indicateurs”. Ces derniers pourront être choisi ou non par les services supérieures qui n’ont en fait besoin que de ces indicateurs et de leur validité lors du déroulement d’un projet.

    C’est une ébauche mais la philosophie est là (Du moins pour moi).

    Bonne journée

  • Bonjour,

    En fait à part le dernier paragraphe de l’article qui parle d’intégrer les différentes solutions “Ms Access-like” dans une solution élargie à l’entreprise. Tout le reste plébiscite une réalisation indépendante d’un système dans chaque département. Ms Access est déjà beaucoup utilisé mais est souvent limité je pense par l’absence d’un outil de BPM et par une mise en ligne et une gestion multi-utilisateurs facilitée.
    Ayant fait aussi diverses tailles d’entreprises, on se rend compte que dans les cas des petites structure, il y a souvent un manque d’outil et dans les grandes entreprises un manque de flexibilité des outils mis en place. Et vous retrouverez dans ces grands groupes des fichiers excel et Access pour parfois devenir la référence de données critiques de l’entreprise.
    L’exemple du suivi de phase de test, pour moi est frappant. Il y a des entreprises de grandes tailles qui vont avoir des départements qui ne vont pas réaliser les mêmes produits mais qui vont passer par ces mêmes phases de test et qui à chaque fois les gères à travers des fichiers Excel. Alors soit il faut un outil spécifique de gestion de ces campagnes de test, soit une solution telle que présentée dans l’article.
    Le but de l’article est surtout, le constat que Microsoft Access est quand même beaucoup utilisé, mais qu’il manque quelques éléments pour que cela devienne un outil incontournable de données produit, ou de prototypage de solution PLM.

  • Yannick

    Il manque juste un développeur malin connaissant bien les APIs Microsoft 🙂 afin de prendre les données à un endroit et les injecter ailleur etc…..

  • Aurélien Dang

    Tombé sur votre Blog grâce à une copie de cet article sur Viadéo, je ne peux m’empêcher d’y déposer un commentaire.

    Je pense que lorsque votre besoin devient assez complexe pour que les outils bureautiques usuels ne soient plus suffisants pour le satisfaire, et si votre entreprise est assez grande pour être munie d’une DSI, c’est qu’alors vous êtes mûr pour lancer un “projet Système d’Information”, vous pourrez même prétendre en être maître d’ouvrage !

    Pour rentrer dans le fond, je ne connais que très mal la gestion des données “produit”, mais j’ai connu un peu le même genre de problématiques que vous, concernant les campagne de tests de bon fonctionnement des *logiciels*. Word, Excel ayant atteint leurs limites lorsque l’on veut réutiliser et réitérer, la solution la plus simple qui avait été trouvée lors d’une de mes expériences antérieures a été d’installer TestLink (Logiciel Libre) pour suivre les campagnes de test, et Bugzilla de la fondation Mozilla pour suivre les anomalies déclarées et leurs corrections. Ceci nécessite d’avoir à votre disposition quelqu’un qui sache installer/configurer notamment un Système de Gestion de Bases de Données (plus complexe qu’Access, comme MySQL, PostgreSQL, ou Oracle), un serveur web, comme Apache HTTP Server, ou Microsoft Internet Information Services, un serveur SMTP pou l’envoi d’e-mails ; mais le peu que j’ai pu rencontrer de la Gestion des Non-Conformités dans un contexte industriel m’a fait pressentir qu’il y avait des processus communs avec ce que j’avais connu dans le monde Logiciel.

    Bonne continuation dans vos réflexions à ce sujet.

  • Bonjour Aurélien et merci pour votre commentaire,

    J’ai mentionné dans plusieurs articles la proximité qu’il pouvait y avoir entre la gestion de configuration pour de la mécanique et celle appliquée aux logiciels. C’est d’ailleurs dans l’article suivant ( http://www.prodeos.fr/2010/08/06/le-plm-elargir-la-reflexion-a-tous-les-secteurs/ ) que je propose de ne pas se restreindre aux outils dits PLM et voir ce qui se fait dans les différents secteurs.
    La problématique que j’essaie de traiter c’est le nombre de PME/PMI qui se trouvent entre “besoin assez complexe” et “entreprise assez grande pour être munie d’une DSI” conséquente. Et je pense qu’en traitant ce panel on répondra à un grand nombre de besoins de grand groupes qui se révèlent en interne à l’échelle de business unit, départements, etc…

Download Aras Innovator