Le PLM, pour « Product Lifecycle Management », permet de concevoir globalement un produit et d’en assurer son suivi depuis l’idée de départ jusqu’à son obsolescence. C’est un projet structurant qui touche aux enjeux de l’entreprise. Néanmoins, la criticité est exacerbée sur un PLM.

L’objectif de la « TMA PLM » est de maintenir l’application en conditions opérationnelles, de la stabiliser, de la faire évoluer selon les besoins des nouveaux utilisateurs ou des nouvelles fonctionnalités. Elle doit aussi faire évoluer le COTS (Progiciel sur étagère) sur lequel elle est basée. Et ce, en tenant compte de la sensibilité des applications qui gèrent les données critiques du client (production de la structure d’un avion, d’un moteur, d’une voiture), et avec un volume important d’utilisateurs.

La clé du succès d’une « TMA PLM » réside, dès le démarrage d’un projet PLM, dans la transition mais pas seulement. La part de l’évolutivité est essentielle, et la plus-value de la TMA jaillit de la partie adaptative du projet, que ce soit en préventif ou à la demande. La TMA étant un sujet sensible, voici cinq règles à suivre pour être un « bon TMiste ».

Transition : ne surtout pas la minimiser !
Que ce soit pour la mise en place des outils, de l’infrastructure, des processus (gouvernance, management, indicateurs) et, bien sûr, pour la récupération de la connaissance technique et fonctionnelle de l’application, la transition est la clé de voûte d’une future TMA.

Une transition mal effectuée conduit systématiquement à des difficultés, voire à des échecs dans la maintenance opérationnelle de l’application.

Périmètre : réussir et anticiper les évolutions
La TMA touche différents services avec une importante partie corrective et de gestion des incidents de données ou d’utilisation, de correction des bugs, d’interfaçage avec les éditeurs des solutions COTS PLM (PTC, Dassault, Siemens notamment) pour appliquer les patchs éditeur chez le client final.

La partie évolutive est la clé. Le périmètre fonctionnel et le périmètre utilisateurs sont très souvent amenés à évoluer assez largement. Ces évolutions applicatives viennent principalement du client final. Aussi, le TMiste doit répondre aux nouveaux besoins du client, sans oublier d’anticiper et de proposer des solutions suite à des incidents récurrents.

Partie adaptative : dépasser les durées de vie
Cette partie de la TMA concerne principalement la gestion de l’obsolescence, tant hardware que software : changements d’OS, de version du COTS PLM ou évolution des normes de sécurité dans l’entreprise. Sur cette partie adaptative, on est souvent confronté à des problèmes liés aux cycles de vie des COTS PLM eux-mêmes. Il est fréquent qu’une première version arrive en production avec un COTS dont la maintenance par l’éditeur ne dure plus que quelques mois, voire une maintenance qui a expiré.

Le TMiste doit ainsi accompagner son client pour trouver les solutions les plus adaptées afin de gérer l’obsolescence du COTS (montée de version, extension du support éditeur).

Documentation : ne pas la négliger !
C’est un élément primordial pour assurer la TMA. C’est un peu l’histoire du projet qui est racontée à travers la documentation. Les référentiels clés de documentation, d’exigences et de configuration logicielle, initialisés pendant la transition, permettent de délivrer l’ensemble des services du catalogue proposé dans le respect du cahier des charges. C’est parfois (et même souvent) une faiblesse des projets (selon les exigences qualité qu’a pu avoir le client final) : la documentation n’est pas tout le temps à jour et manque de traçabilité.

L’état de la solution : la considérer
Trois facteurs clés sont à prendre en compte : la maturité, la stabilité et les performances.

La maturité d’une application est mesurée par le nombre d’incidents levés sur l’application, à condition que l’on soit dans les conditions cibles d’utilisation (nombre d’utilisateurs et périmètre fonctionnel notamment).

La stabilité dépend de la quantité d’évolutions et de corrections encore à faire sur l’application.

L’état de performance des applications PLM est également très importante. En effet, les COTS PLM, pour répondre aux besoins des clients, subissent des customisations plus ou moins importantes (du code spécifique pour détourner ou contourner certaines fonctionnalités du standard et répondre ainsi au client). C’est alors qu’on peut rapidement se retrouver face à des problèmes d’utilisabilité de l’application.

La capacité d’un TMiste à intervenir sur tout type de problème, qu’il soit technique, fonctionnel ou lié à la performance, réside en grande partie dans ses ressources, ses retours d’expérience et la maitrise d’outils de monitoring.

De façon générale, plus l’application est mature, stable et performante, plus il sera facile d’opérer la TMA.

__________
David Bourrières est Chef de projet chez Gfi Informatique