Toujours à la recherche des meilleures méthodologies d’implémentation de solutions IT et particulièrement sur la partie PLM, j’ai réfléchi à l’opportunité proposée par la croissance exponentielle de l’usage des API. Vous avez pu voir dans ma démonstration de sailsjs qu’il devenait très facile de mettre en place des services web avec l’infrastructure sécurisée et l’intégration aux systèmes d’entreprise. Alors je propose maintenant à travers mon activité de conseil une méthodologie d’implémentation de solution PLM que j’appelle « API-Driven ».

Le processus se focalise sur les services. Et propose une implémentation avec les étapes suivantes:

1450281693_top_chart_track_number_one  1450151275_vector_396_18

Audit des services nécessaires
 1450281713_track_number_two_circle  1450151598_vector_396_22

Sélection de la plateforme
 1450281715_three_top_chart_track  1450150626_vector_396_23

Développement
 1450281711_top_number_four_track_chart_circle  1450151303_vector_396_05

Déploiement

Cette démarche se veut indépendante des logiciels au lancement. La dépendance ne vient qu’après la sélection de la plate-forme qui se fait en cohérence avec l’historique de l’IT de l’entreprise sa vision long terme et ses ressources en interne. La valeur de la démarche est surtout dans l’approche en se concentrant sur le besoin réel des utilisateurs. Les services énumérés et spécifiés ensuite sont de divers types:

  • Les personnes avec telle responsabilité ont besoin d’enregistrer un fichier
  • Un utilisateur doit recevoir un email lorsque le fichier dont il est le responsable a été validé par la qualité
  • Un utilisateur doit recevoir un message sur une solution de messagerie (slack) lorsqu’il y a une question sur l’article dont il est responsable
  • Un utilisateur doit pouvoir voir la différence entre deux fichiers.

On est sur du basique mais c’est bien à cela que j’aime ramener mes interlocuteurs. Revenons au besoin brut, mettons de côté les particularités techniques, les contraintes logicielles, mettons en place des services, nous construirons ensuite les interfaces pour pouvoir les utiliser.

Retrouvez l’offre de mydatalinx à ce sujet : « API-Driven » PLM

Posted by Yoann Maingon

Consultant PLM avec des expériences autant côté métier que dans l'implémentation technique de solutions PLM et d'intégrations de systèmes, je partage avec vous mes expériences, mes recherches et mes développements à travers ce blog.

All Posts Website

2 Comments

  1. Urban décembre 21, 2015 at 09:03

    Je n’ai pas approfondi les possibilités permises par ces tableaux (« Excel »). Ils peuvent structurer le début d’une approche nomenclature élémentaire. Une difficulté qui mérite attention est l’historisation des compositions : c’est là que l’on peut commencer à parler de PLM. Je ne sais si cela est prévu dans le « modèle » sous-jacent.
    Si cette « dimension évolution (temporelle ou à rang) » n’est pas disponible, c’est probablement le moment de passer aux API (qui eux vont, j’espère, le permettre …)

    1. Yoann Maingon décembre 21, 2015 at 09:39

      Bonjour Jean-Jacques, Je pense en effet que les feuilles excel de dragon innovate sont un début, mais que ça ne structure pas de la bonne manière la vision PLM de leurs utilisateurs. Comme toutes les grilles excel, il y a un mélange d’objet dans un même tableau qui simplifie l’interface mais qui peut poser des difficultés de compréhension de modèles PLM par la suite. Le contexte de Dragon Innovate est le lancement rapide d’évaluation de la qualité et du coût de fabrication d’appareils majoritairement électroniques, avec peu d’historique et peu de diversité. Les API, si elles sont bien réalisées, permettent cela. J’ai d’ailleurs présenté le versionning de PLMAPI sur le blog dédié ( https://plmapi.wordpress.com/2015/12/10/lets-talk-versioning-keeping-it-simple-and-effective/ ), plus de détails sur la partie historisation sont à venir…

Comments are closed.