La fonction de DSI ou de responsable de département dans certains cas contient très souvent une forte composante de fonction d’acheteur vis à vis des différents logiciels que ces personnes vont devoir intégrer à leur gestion. Être acheteur est un vrai métier et dans certains cas comme pour de l’achat de matière, de composants, etc. Les acheteurs peuvent avoir une grande implication et une grande compétence pour aller travailler en direct et quasiment en autonomie avec les fournisseurs. Au niveau de la recherche de solutions pour la gestion de systèmes d’information liés à la gestion du cycle de vie du produit la chose est plus délicate. Pour y avoir été confronté en tant qu’intégrateur de la solution PLM Aras Innovator, j’ai finalement très rarement été en lien direct avec un acheteur. Je voulais donc proposer quelques points importants, que j’espère objectifs, qui permettent de minimiser les risques lors de l’acquisition de ces solutions et d’élargir le périmètre de son sourcing. Cette liste de points n’est pas du tout exhaustive et le but est simplement de rappeler des points qui ne sont pas toujours évidents lorsque l’on se plonge dans la recherche d’une solution pour répondre à une problématique spécifique. N’hésitez pas à me proposer de l’enrichir, l’expérience limitée de ma petite carrière doit sûrement me faire manquer certains points.

  • Exhaustivité de la recherche
    • Cette tâche n’est pas simple. Même si Google nous aide grandement, il est important de passer une bonne journée en contactant aussi d’autres acteurs du domaine pour exiger plusieurs listes des éditeurs PLM.
    • Il ne faut pas à ce stade discriminer une solution.
  • Découverte de la solution
    • Il est important de voir la solution logicielle, vous ne pouvez plus vous fier à des textes à propos de la capacité de tel ou tel logiciel à intégrer les processus métier de telle ou telle industrie, vous ne pas non plus vous baser sur une personne qui vous présente 20 ans d’expérience dans le domaine. L’expérience est importante mais les solutions logicielles n’ont pas la même durée de vie. L’expérience est donc plus valide pour un consultant fonctionnel que pour un intégrateur d’une solution technologique.
    • Pour permettre cette découverte, vous devez pouvoir utiliser la solution, soit à travers la mise à disposition de la solution, des présentations en direct lors de présentation d’éditeurs et d’intégrateurs ou encore, l’utilisation de plus en plus communes du webinaire en assistant aux séances programmées par ces mêmes acteurs.
  • La composante technologique de la solution
    • L’évolution des technologies est plus rapide que jamais dans les systèmes de gestion de données et au niveau de leurs intégrations. Il est donc de plus en plus important de prendre conscience des composantes technologiques de chaque solution. La solution utilise t’elle des standards? Quelle est sont schéma de base de données et quelles sont les conséquence sur les capacités d’intégration et les capacités à récupérer les données de manière structurée.
  • Structures de prix
  • Quel est le rapport de mes utilisateurs au logiciel, Quel est ma capacité à imposer des choix
    • Parfois on a beau avoir tous les meilleurs arguments du monde, si les utilisateurs rejettent une solution on peut être complètement bloqué. Cela a souvent été le cas avec des solutions PDM qui rajoutaient trop de temps de gestion (souvent complètement justifié par un gain de temps et d’argent sur le long termes), mais cela peut aussi exister dans des structures de type holding où différentes cultures se confrontent pour l’utilisation d’un même système. Il est donc important de voir quelles solutions permettront soit un consensus, soit de s’adapter facilement.

Conclusion

Cette liste demande à être enrichie et le sera avec de nouvelles expériences et des contributions, cependant elle représente déjà un bon début car nombreuse acquisitions de solutions PLM sont faites sans avoir consulté plus de deux ou trois solutions. Il y a un peu plus d’un an, j’étais dans un rendez-vous où la personnes que je rencontrai s’étonnait de me voir lancer Aras Innovator pendant notre première rencontre. Mon interlocuteur agréablement surpris m’indiquait qu’il fallait attendre deux ou trois rendez-vous avec certains éditeurs pour enfin voir la solution.  Validez donc ce que vous recherchez, des spécialistes du développement produit ou une solution PLM technologique qui supportera ce développement produit?

[subscribe2]

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.

  • Noémie

    Oui, il s’agit avant tout de permettre aux utilisateur finaux de s’impliquer dans le choix des outils pour bien sûr répondre aux exigences métier de productivité mais aussi être certain que le logiciel soit ensuite accepté par les utilisateurs. Vous pouvez retrouver un article sur ce thème sur : http://www.blogplm.com/utilisateurs-metier–de-plus-en-plus-demandeurs-pour-etre-acteurs-d-b9c97d94ff3cf84dca30534cc624a5cf.html

  • Bernard Chabot

    A mon avis, une bonne pratique de conception (quelque soit ce que l’on doit concevoir ) consiste à s’intéresser tout d’abord aux usages de la chose « à concevoir ». Dans le cas d’une solution PLM, son usage principal étant de soutenir certains processus métier de l’entreprise (en particulier ceux liés à la conception/industrialisation de produit/service), il est donc fondamental de s’intéresser d’abord et avant tout à ces processus métier et de les décrire. Mais ce n’est pas une fin en soit … en effet, le fait de s’intéresser aux processus métier permet surtout de faire émerger les sujets métier manipulés par ces processus. Une fois les sujets métier identifiés, il devient possible de décrire les relations entre ces sujets (avec la sémantique métier adéquate) dans le but de spécifier un modèle sémantique métier. Ce modèle sémantique métier incarne alors le volet « statique » du besoin utilisateur qu’il faudra implémenter dans la solution PLM (en choisissant la classe d’objet applicatif qui « collent » le mieux à chaque sujet métier).

    Remarque : Plus haut, il s’agit bien de processus métier (décrivant « ce que les métier doivent faire ») et non de procédure ou de pratique métier (décrivant « comment les métier font ce qu’il doivent faire »). Cf : Processus VS Procédure :
    http://fr.wikipedia.org/wiki/Processus
    http://www.adeli.org/document/429-l55p11pdf
    http://www.c-log.com/la-methode-ossad/ (Modèle « Abstrait » = Processus VS Modèle Descriptif = Procédure)

    • Bonjour, merci pour votre commentaire. J’ai encore du mal avec tous ces concepts sur la sémantique du web et donc encore plus sur la sémantique du PLM. Je pense que l’objet de votre remarque est assez spécifique au modèle de données des solutions mises en place plus qu’à la partie technologique/logicielle d’une solution PLM.
      Je ne suis pas forcément d’accord si vous estimez que le point de départ pour des concepteurs logiciels, doit être l’analyse des processus métier de l’entreprise. Cela rend l’étude très dépendante de chaque activité. Ce que je comprendrai pour quelqu’un qui implémente/configure/adapte une solution à une entreprise donnée.
      Je pense vraiment qu’il est important de trouver la solution qui vous apporte les bons outils et qui potentiellement outilleront la démarche que vous décrivez.

      • Bernard Chabot

        En fait l’idée derrière la « sémantique du PLM » vient du constat que les classes d’objets applicatifs proposés par une solution PLM représentent en fait des notions, des concepts, des sujets … déjà présents au niveau métier et qu’il est essentiel de bien les identifier avant toute chose. Par ailleurs, lorsque vous faite l’analyse des processus métier et des sujets métier qu’ils manipulent, vous constatez rapidement qu’il y a 2 facettes « orthogonales » qui se combinent.
        Une première facette « générique » vient du fait qu’une activité métier appartient à un domaine particulier : conception, industrialisation, production, … (et cela quelle que soit l’entreprise)
        Une seconde facette « spécifique » vient du fait qu’une activité métier appartient également à une filière industrielle particulière : des plats cuisinés, des ordinateurs, des produits cosmétiques, … (et cela est propre à chaque entreprise, ou en tout cas à chaque secteur industriel)
        Donc dernière la spécificité apparente de chaque activité métier, il y a également une facette générique qui peut être exploitée pour mutualiser des problématiques communes à différents secteurs industriels … et cela peux servir de point de départ aux concepteurs de logiciels … Qui pourront ensuite apporter de la spécificité via des mécanismes complémentaires (je pense en particulier aux modules de classification des solutions PLM)