L UNIVERSITÉ BORDEAUX 1

Transcription

1 N d'ordre : 4714 THÈSE PRÉSENTÉE A L UNIVERSITÉ BORDEAUX 1 ÉCOLE DOCTORALE DES SCIENCES PHYSIQUES ET DE L INGENIEUR Par Mlle. Mylène BACZKOWSKI SPÉCIALITÉ : PRODUCTIQUE POUR OBTENIR LE GRADE DE DOCTEUR TITRE : Amélioration du processus de déploiement d une solution PLM par l utilisation de cartes heuristiques et de persona : cas LASCOM Directeur de recherche : Professeur Philippe GIRARD Soutenue le : 12 décembre 2012 Devant la commission d examen formée de : MM. Aziz BOURAS Président du jury Aziz BOURAS Rapporteur Professeur des Universités - Université Lumière Lyon 2 Benoît EYNARD Rapporteur Enseignant Chercheur HDR Université de Technologie de Compiègne Philippe GIRARD Directeur de thèse Professeur des Universités IUFM d Aquitaine Université Bordeaux 4 Vincent ROBIN Co-directeur Maître de Conférences IUFM d Aquitaine Université Bordeaux 4 Christophe MERLO Examinateur Docteur (HDR) ESTIA Sabine NOISETTE Examinateur Directrice de recherche LASCOM Bièvres Bertrand ROSE Examinateur Maître de conférence Université de Strasbourg Dominique PIOLLE Invité Technical Sales Director, BT EuroWest - Dassault Systèmes Université Bordeaux 1 Les Sciences et les Technologies au service de l Homme et de l environnement

2

3 A mes proches

4

5 Résumé Pour améliorer le pilotage et la gestion de l ensemble des activités, les entreprises tentent de mettre en œuvre des solutions informatiques aptes à répondre à leurs besoins théoriques. Toutefois lors de la mise en pratique, de nombreuses itérations sont généralement nécessaires pour s approcher d une solution adéquate à leurs besoins réels. Cet écart provient essentiellement de trois causes majeures. D une part un manque de maturité et la connaissance des besoins réels au sein de l entreprise. D autre part la difficulté de transposer ces besoins métiers dans une solution logicielle prédéfinie et enfin du manque de communication sur le projet et d investissement des utilisateurs finaux. Notre contribution se place dans une dynamique de recherche d amélioration des processus d implémentation et de déploiement des solutions logicielles de type PLM dans les entreprises. Nous proposons une démarche complète de déploiement, centrée sur les acteurs de l entreprise et qui s appuie sur l utilisation de deux outils jusque là peu usités pour répondre à ce type de problématique : les cartes heuristiques et les personas. Cette démarche a été construite puis mise en œuvre dans le cadre d une collaboration avec LASCOM, éditeur de solutions PLM. Mots-clés : persona ; carte heuristique ; PLM ; déploiement ; expression des besoins ; centrage utilisateur

6

7 Remerciements Je tiens tout d abord à exprimer ma profonde reconnaissance envers la société LASCOM qui m a permis de réaliser cette thèse CIFRE malgré un sujet qui s est un peu éloigné des préoccupations premières d un éditeur. Je tiens plus particulièrement à remercier Monsieur Dominique PIOLLE ancien Directeur Marketing & Avant Vente qui a initié ce projet et qui m a fait confiance. Ces années partagées ont contribué à faire évoluer le sujet en fonction de nos échanges, de l expérience et de l analyse du terrain mais également de mes motivations. Je remercie également Madame Sabine NOISETTE qui a su reprendre le flambeau à son arrivée chez LASCOM après une période de trouble. L un comme l autre ont permis grâce à leur expérience et leur souci de l utilisateur final de prendre des orientations de recherche pragmatiques faces aux problèmes rencontrés. Je remercie bien évidemment mon directeur de thèse et mon encadrant de thèse, en commençant par Monsieur Philippe GIRARD pour sa confiance tout au long du projet. Je remercie également Monsieur Vincent ROBIN pour son soutien et pour les confrontations très intéressantes entre les deux mondes que peuvent être la recherche et l industrie. Je remercie également les membres du jury, tout particulièrement Monsieur Aziz BOURAS pour avoir présidé la séance, mais aussi pour avoir tenu le rôle de rapporteur avec Monsieur Benoit EYNARD. Tous deux ont permis d apporter des pistes de réflexions intéressantes. Je n oublie pas tout ceux qui ont eu un rôle moins officiel mais tout aussi important tout au long de ma vie sans qui je n aurais jamais pu arriver jusque là. Je remercie également vivement toutes les personnes qui m ont soutenu et encouragé durant ces quatre années de thèse tant dans le cadre personnel (ma famille, mon ange gardien, mes amis) que dans le cadre professionnel (la liste est un peu trop longue vous m en excuserez j en suis sure). Sans ce soutien quotidien ou du moins fréquent, je n aurais jamais réussi à parvenir au terme de cette expérience enrichissante mais semée d embûches et de doutes. Et pour finir l initiateur de cette aventure, qui rentre dans de nombreuses catégories précitées, monsieur Bertrand ROSE sans qui cette aventure n aurait jamais vu le jour et n aurait jamais abouti.

8

9 Table des matières Table des matières INTRODUCTION GENERALE CHAPITRE PROBLEMATIQUE Introduction La «r»évolution de l informatisation L évolution de l informatisation Du Système d Information support à la stratégie Au Système d Information partie intégrante de la stratégie Les verrous de l implémentation d un Système d Information en entreprise L organisation polymorphe des entreprises La vision transverse : hétérogénéité organisationnelle La collaboration : hétérogénéité sémantique Une implémentation intégrée pour une meilleure interopérabilité Synthèse CHAPITRE METHODOLOGIE DE DEPLOIEMENT D UNE SOLUTION PLM Introduction Les briques fonctionnelles La gestion électronique documentaire : la mémoire de l entreprise La gestion de configuration : la représentation réelle d un produit/projet Les processus : le dynamisme de l entreprise Le reporting : le support à l aide à la décision Mise en place d un PLM : un processus aux multiples facettes La mise en place théorique vue du coté «client» La mise en place théorique vue du coté «éditeur», exemple de LASCOM Des besoins à la solution logicielle : de la réalité aux modèles Les approches de modélisation d entreprises L approche «descendante» : l intégration itérative L approche «ascendante» : la fédération Les méthodes et outils de modélisation d entreprise et de processus Méthodes et outils de modélisation d entreprise Méthodes et outils de modélisation des processus/activités Analyse et synthèse Synthèse CHAPITRE ANALYSE ET AMELIORATION DU DEPLOIEMENT DES SOLUTIONS : LE CAS LASCOM Page 9

10 Table des matières 1 Introduction La réponse de LASCOM aux problématiques industrielles D une solution «globale» vers des plateformes adaptées et pré-paramétrées : la «verticalisation» LASCOM AEC (Architectural Engineering & Construction) LASCOM ICS (Industry & Complex Systems) LASCOM CPG (Consumer Packaged Goods) Synthèse Vers une évolution de la démarche de déploiement de la solution Définir le cadre du projet : le périmètre, les acteurs, les interlocuteurs potentiels Des phases clés : avant-projet et après projet Communiquer, former et accompagner le client pour être efficace Des actions de communication/formation de plus en plus en amont Un accompagnement sur le long terme : une hotline au service du client Synthèse CHAPITRE ADAPTER L APPROCHE ET LE DIALOGUE «CLIENT» : UN VECTEUR DE PERFORMANCE Introduction Le choix de la méthodologie de modélisation : une étape clé Problématique générale du choix de la méthodologie Le casse-tête de la représentation multi-niveaux et de l implication des acteurs Deux outils «non conventionnels» pour lever les verrous Les cartes heuristiques : une base commune de modélisation et de discussion La carte heuristique ou une structuration rapide d idées La formalisation heuristique tout au long du projet : approche théorique Le commercial et la map L avant vente et la map Le service projet et la map Le support client et la map Synthèse Une carte générique pour le déploiement des solutions LASCOM Le contexte de l entreprise Suivi des interventions Suivi des livraisons Définition des applications Synthèse CHAPITRE UNE ANALYSE CENTREE SUR LES FUTURS UTILISATEURS Introduction Persona : une approche au plus près des utilisateurs finaux Page 10

11 Table des matières 2.1 Contexte et approche théorique De la map à persona : de l entreprise à l acteur Etape préliminaire : comment et quand établir les questionnaires? Mise en place des questionnaires durant la phase d analyse des besoins Mise en place des questionnaires durant la phase d exploitation Synthèse : Confrontation des deux approches pour consolider le modèle CHAPITRE L ENTREE DANS LE PROCESSUS ET LES PROBLEMATIQUES ASSOCIEES : ETUDES DE CAS CHEZ LASCOM Cas d une réponse à un appel d offres : la map pour initialiser et aider à la communication Réponse à un appel d offres par l avant vente Problématique liée à l avant vente L importance de la map en avant vente L analyse des besoins : le cœur du processus Problématique de l analyse des besoins L importance de l exploration et des persona pour définir les besoins réels Synthèse Cas d une reprise d exploitation : importance des supports Problématique de la constitution d une vue globale de l application Mise en évidence de l intérêt de la map comme support d intervention Situations sans notre proposition Situation avec notre proposition Synthèse CONCLUSION ET PERSPECTIVES BIBLIOGRAPHIE PERSONNELLE BIBLIOGRAPHIE ANNEXES Page 11

12 Table des matières Liste des figures Figure 1. La brique fonctionnelle «Gestion des Configurations» Figure 2. La brique fonctionnelle «Gestion Documentaire» Figure 3. La brique fonctionnelle «Gestion des Processus» Figure 4. La brique fonctionnelle «Reporting» Figure 5. Les tâches d'un projet logiciel par activités et par phases Figure 6. Les différentes phases d un projet d informatisation chez LASCOM Figure 7. La déclinaison LASCOM PLM pour le marché de l AEC Figure 8. La déclinaison LASCOM PLM pour le marché de l ICS Figure 9. La déclinaison LASCOM PLM pour le marché du CPG Figure 10. Cyclicité du processus d informatisation Figure 11. L illustration des sept questions d Aristote [Créativité, 12] Figure 12. Les acteurs du processus d informatisation et points d évolution de la map Figure 13. Structure d une carte client générique («méta-map») Figure 14. Le contexte prédéfini par le commercial Figure 15. Le contexte enrichi par l avant vente Figure 16. Le contexte revu lors du projet Figure 17. Contexte à prendre en compte pour le projet Figure 18. L initialisation du suivi des interventions par l avant vente Figure 19. Le suivi des interventions en cours de projet Figure 20. Convention pour les interventions par le support Figure 21. Origine d une correction par le support Figure 22. Structure de la partie «Livrable» Figure 23. La définition succincte de l application vue par l avant vente Figure 24. Élaboration partielle de la définition de l application Figure 25. Structure de l organisation de l application Figure 26. Persona ou la définition de l organisation dans la map projet Figure 27. Les documents manipulés vus par les utilisateurs Figure 28. Les questionnaires sources de la typologie des documents Figure 29. L utilisation vue par les utilisateurs Figure 30. Communiquer sur l aboutissement du travail commun Figure 31. Communiquer sur les listes établies Page 12

13 Table des matières Figure 32. La grille d utilisation de l application Figure 33. Personnifier l utilisation Figure 34. Présenter le persona de l utilisateur Figure 35. Les difficultés des utilisateurs Figure 36. Les demandes d améliorations des utilisateurs Figure 37. Apport de persona au contexte de la carte heuristique Figure 38. Réponse financière de LASCOM Figure 39. Extraits du Cahier Technique des Clauses Particulières (CCTP) Figure 40. Extrait de la réponse technique LASCOM (1/2) Figure 41. Extraits de la réponse technique LASCOM (2/2) Figure 42. Carte issue de l analyse de l extrait du CCTP Figure 43. Image de l application envisagée par l avant vente Figure 44. Impacts de la map «avant vente» au cours du processus Figure 45. La définition du fonctionnement issue du cahier des charges Figure 46. Exemple de chiffrage pour une nouvelle application Figure 47. Définition du fonctionnement suite à la consultation interne Figure 48. Exemple de modification effectuée Figure 49. Exemple de désactivation Figure 50. Support à l initiation à la map contexte Figure 51. Extrait du contexte issu de l analyse Figure 52. Impacts de l utilisation de la map pour l analyse des besoins Figure 53. Améliorations du processus de déploiement Figure 54. Améliorations des étapes après projet Figure 55. Phase du cycle de vie d un produit Figure 56. Cycle de vie d un produit Figure 57. Complémentarité de l ERP et du PLM Figure 58. Principe de la méthode MPPI Figure 59. Diagramme BPMN du processus d'avant-projet Figure 60. Diagramme BPMN du processus de déploiement Figure 61. Phase de gestion du changement [Debaecker, 04] Page 13

14 Table des matières Liste des tableaux Tableau 1. Etude comparative des outils/méthodes de modélisation de processus Page 14

15 Table des matières Liste des annexes Annexe 1. Des solutions logicielles au cœur de la «r»évolution : ERP et PLM Annexe 2. Processus de déploiement d une solution PLM en PMI/PME [Bissay, 10] Annexe 3. Adapter l outil aux entreprises Annexe 4. PERSONNA Page 15

16

17 Introduction générale Introduction générale Notre contribution se place dans une dynamique de recherche d amélioration des processus d implémentation et de déploiement de solutions logicielles de type PLM dans les entreprises. Nous proposons une démarche complète de déploiement, centrée sur les acteurs de l entreprise et qui s appuie sur l utilisation de deux outils jusque là peu usités pour répondre à ce type de problématique : les cartes heuristiques et les personas. Le premier chapitre montre dans quel contexte les industriels cherchent des solutions informatiques leurs permettant de les aider à piloter et à gérer l ensemble des activités liées aux produits/projets. Nous présentons ensuite deux types de logiciels de gestion proposés sur le marché : les ERP (Enterprise Ressource Planning), pour la gestion des ressources et des plannings, et le PLM (Product Life Management) pour la gestion des données techniques. Au regard du contexte, nous mettons en exergue les difficultés rencontrées par les industriels et les éditeurs logiciels et en particulier la nécessité pour les premiers d être conscients de l impact structurant de ce type de projet et les seconds d avoir une méthodologie de déploiement efficace et fiable. L enjeu de ce travail de recherche est alors replacé dans le contexte plus spécifique de cette thèse CIFRE chez LASCOM puisque nous nous focalisons sur notre problématique d amélioration de la méthodologie de déploiement mise en œuvre par cet éditeur de solutions de PLM. Le second chapitre identifie les principaux verrous de l implémentation d une solution logicielle. Pour LASCOM, le problème réside surtout dans le nombre d itérations nécessaires au recueil d informations chez le client en vue d obtenir un modèle exploitable de l entreprise. LASCOM souhaite réduire ces itérations en améliorant les phases amont de son processus d implémentation. En partant du postulat que les entreprises clientes et que les intervenants nécessaires à la construction du modèle ne sont pas tous des experts dans les techniques de modélisation utilisées, nous montrons que l un des préalables essentiel au déploiement d une solution est le choix du «langage» de modélisation. Il doit être simple et mettre en évidence de façon explicite l ensemble des informations pour favoriser l implication et la compréhension de chacune des entités interrogées quelque soit le niveau de maturité du projet. Page 17

18 Introduction générale Le troisième chapitre concerne l étude et l analyse critique des formalismes classiquement utilisés pour modéliser les entreprises et leurs processus. Le but de cette analyse est de travailler à l affinement de la démarche d implémentation chez LASCOM et à l identification d au moins un formalisme «accessible» et «utilisable» dans le monde industriel pour répondre à notre problématique. Nous montrons aussi que la pérennité d une solution PLM dans une entreprise est garantie quasiment essentiellement par le fait que les utilisateurs se l approprie. Pour ce faire, nous proposons de revoir les phases critiques du processus de déploiement pour faire que les utilisateurs soient parties prenantes très tôt du projet, de son développement jusqu à la fin de l exploitation de la solution. Le quatrième chapitre décrit les outils supports à la démarche qui contribueront au respect des grands principes que nous définissons dans ce chapitre. Nous nous centrons essentiellement sur les outils supports à la modélisation des processus et à l émergence des profils utilisateurs. Notre réflexion nous conduit dans un premier temps à utiliser les cartes heuristiques pour lever certains verrous que nous avons identifiés. Dans notre proposition, la carte heuristique (ou map) qui doit constituer le support du projet et plus globalement du cycle de vie de l application, joue le rôle de moteur de la réflexion et de la communication. Dans le cadre d un projet, l utilisation de la map offre une nouvelle dimension à la définition de l application et à la communication avec le client : une structure et une organisation dynamiques et «immédiates» qui reprennent sur un seul document très visuel l ensemble des informations ce qui est un atout vis-à-vis des différents prototypes présentés d une réunion à l autre. L autre intérêt de la map réside dans le fait qu elle est conçue conjointement avec le client ce qui a pour effet de lui faire percevoir et assimiler la philosophie du logiciel. Le cinquième chapitre se centre sur l accompagnement et l implication du client lors de la construction de carte heuristique pour finalement replacer le client - et en particulier les futurs utilisateurs - au centre de nos préoccupations. Nous proposons donc une démarche complémentaire à la carte heuristique pour faire émerger des spécifications directement par le client. Notre objectif est ici de responsabiliser encore un peu plus le client dans l analyse et de faire en sorte que l éditeur reste centré sur son savoir faire pour faire des économies (chiffrage plus précis et projet plus court). Nous nous appuyons ici sur la définition de personas qui illustrent les rôles tenus par les utilisateurs dans un environnement plus ou moins précis. La carte heuristique permet d obtenir un support unique pour suivre le cycle de vie du logiciel et sa construction repose sur l approche descendante, tandis que le persona, centré sur les Page 18

19 Introduction générale utilisateurs et leur environnement, se base sur une approche ascendante. C est l association des deux qui offre une dimension de complémentarité des approches, grâce à la double exploration du système et à une confrontation facilitée sur un même support, améliorant la pertinence et la qualité de l analyse donc de l application. Le sixième chapitre présente des études de cas menées dans le cadre de projets «réels» auprès de clients de LASCOM. Chaque projet est unique, en fonction du secteur, du métier, des intervenants, des prédispositions, du contexte, des ambitions, des contraintes, des intervenants mais il est généralement possible de classer les projets en fonction de leur état d avancement initial, des éléments mis à la disposition de l éditeur et des attentes des clients. Le problème pour LASCOM va être d identifier à quelle étape de son processus d implémentation se fait le démarrage du projet. Classiquement trois entrées dans le processus sont possibles : soit l éditeur répond à un appel d offres, soit il répond à une demande d amélioration/évolution, soit il est dans une phase de prospection. Nous décrivons dans ce chapitre le cas d une entrée dès l avant projet, puis d une intervention «classique» pour LASCOM - c'est-à-dire suite à la constitution d un cahier des charges, pour finir par un projet de reprise qui fait suite à l exploitation d une solution déjà en place. Le dernier chapitre de ce mémoire synthétise notre contribution, reprend la chronologie de nos travaux et identifie leurs limites actuelles, ce qui nous permet de proposer des perspectives industrielles et universitaires de cette recherche. Page 19

20

21 Chapitre 1 Problématique Chapitre 1 Problématique 1 Introduction Dans le contexte économique actuel, aux évolutions incertaines amplifiées par la mondialisation des échanges commerciaux, la rationalisation est devenue le mot d ordre des entreprises tant d un point de vue de leurs activités que de leur structure. Cette rationalisation s articule particulièrement autour de trois points essentiels : la recentralisation de leur activité sur leur métier propre, la croissance de leurs performances et leur capacité d innovation. Les entreprises ont en effet compris que leur atout majeur, source de valeur ajoutée sur leurs produits et donc de bénéfices, résidait dans leurs savoir-faire et non dans la multiplication d activités nécessitant de déployer d énormes moyens pour des résultats dégageant peu de retours sur investissement directs. Cette prise de conscience a engendré des bouleversements majeurs et une réflexion profonde au niveau de leur organisation et de leurs méthodes de consolidation de leurs savoir-faire afin d accroître leur performance. Ce bouleversement est le fruit de la lente évolution économique à laquelle nous avons assistée ces soixante dernières années. Classiquement, trois phases se distinguent durant cette période [Giard, 2003]. La première débute à la fin de la guerre en 1945, tout est à reconstruire, tant les hommes que les infrastructures ou l économie. Grâce au plan de relance mis en place (le plan Marshall), les entreprises sont les fers de lance de cette période de reconstruction surnommée les Trente Glorieuses. Elles permettent de répondre activement à la forte demande grâce aux avancées technologiques issues de la guerre, tout en offrant le plein emploi. Stratégiquement les entreprises cherchent à produire peu de produits différents mais à les générer en masse, l organisation n est pas au centre de leurs préoccupations. Elles optent pour l organisation la plus naturelle : le produit est conçu en passant d un département à l autre, d un intervenant à l autre de façon séquentielle, correspondant à une structure purement fonctionnelle [Boboc, 02]. La confiance renait au sein de la population, la consommation prend peu à peu le pas sur la pénurie jusqu à la survenue du premier choc pétrolier en Cet événement sonne le début de la seconde phase et l essor industriel important aboutit à cette époque à équilibrer l offre et la demande. Pour conserver leur monopole sur le marché les entreprises optent pour Page 21

22 Chapitre 1 Problématique la diversification de leurs produits en élargissant leurs gammes, leurs activités et leurs cibles en partant à la conquête du marché international. La concurrence grandissant, les entreprises cherchent des moyens de diminuer leurs coûts. C est l ère de la négociation et de la soustraitance. La performance et l organisation prennent place au cœur de la stratégie des entreprises. La gestion d un portefeuille de produit/projet de plus en plus volumineux et la conduite d une organisation élargie à l externalisation font naitre des besoins nouveaux de suivi centralisé, tant d un point de vue économique que d un point de vue planning pour favoriser le développement de l entreprise. Finalement les frontières s effacent peu à peu et c est en 1989 que le monde - et en particulier l Europe découvre le potentiel économique et industriel du bloc de l Est. La délocalisation ne se limite plus aux activités à fort coût de main d œuvre, mais à l ensemble des productions pour profiter des avantages de la relance financière des pays de l Est et également de leur position géographique centrale. La mondialisation permet d accroître la compétitivité des entreprises, en diminuant les coûts de production, mais a contrario cette ouverture du marché, les contraint aussi à faire face à un nombre de plus en plus important de concurrents en pleine croissance. La performance devient l axe prépondérant dans la stratégie mises en œuvre par les industriels. La coordination nécessaire des projets et la continuité dans la relation entre le projet et les départements métier qui en découle deviennent prépondérantes dans la méthodologie. L organisation de la conception utilisée jusque là montre ses limites, elle est revue et passe d un modèle séquentiel à un modèle concourant à l image des méthodes mise en œuvre dans le système japonais requérant un pilotage et un suivi accrus. En effet, «on se rend compte que la manière séquentielle de déroulement des phases dans le projet est source de coûts supplémentaires, sans être la voie vers un bon compromis efficacité/qualité. De plus, on prend conscience du fait qu enchaîner des solutions considérées optimales au niveau local n'amène pas vers un optimum global.» [...] Alors que [...] «parmi les aspects découverts dans le système japonais concernant le management des projets / des produits nouveaux on compte les équipes de projet auto-organisées, le recouvrement des étapes, qui détermine une diminution de la durée totale du projet, l apprentissage qui se situe au cœur du système de management de projets, les procédés de contrôle, "fins et subtils", les apprentissages, transférés systématiquement à l organisation, etc.» [Boboc, 02]. La migration entre ces deux types d organisation s opère dans le but d accroître la performance et l efficacité des entreprises. Ce mouvement est complexifié par l extension des distances géographiques entre les différents intervenants contraignant les industriels à utiliser d avantage les avancées Page 22

23 Chapitre 1 Problématique technologiques des transports et de la communication pour parvenir à conserver un niveau de gouvernance suffisant. Pour comprendre les évolutions structurelles et fonctionnelles des entreprises il est nécessaire de s intéresser à l étude des changements du contexte industriel. Ces changements sont généralement décrits suivant trois périodes [Giard, 03]. La première période s étend de 1945 à 1975 : les trente glorieuses. Le contexte industriel est caractérisé par une forte pénurie, la croissance est forte, les marchés localisés et la demande est supérieure à l offre. Le client a un choix restreint car les entreprises ne cherchent pas forcément à innover et misent plutôt sur une offre et une gamme très réduites de produits, produits en grand nombre et dont la durée de vie est élevée [Le Masson et Weil, 05]. La seconde période court de 1975 à la fin des années 80 : l offre équilibre la demande puis finit par la dépasser. Les marchés s ouvrent et deviennent de plus en plus concurrentiels. L entreprise doit garantir la conformité du produit fourni avec le produit attendu par le client et ce dans un délai de plus en plus court. L une des finalités principales est de répondre à des objectifs de conformité du produit et de satisfaction du client mais aussi à des contraintes temporelles de plus en plus restrictives entre le moment où le client exprime son besoin et le moment où celui-ci est effectivement satisfait. De plus, les entreprises se doivent d accroître la variété de leurs gammes pour ainsi être présentes et positionnées sur divers marchés. Enfin, la troisième période va du début des années 90 jusqu à aujourd hui : l offre est supérieure à la demande. Les entreprises doivent faire face à un marché relativement saturé, ouvert et très concurrentiel. Adaptation du produit aux besoins ciblés du client et réactivité sont donc les maîtres mots. Pour Kaplan [Kaplan et Norton, 98] «la réactivité est devenue une arme concurrentielle majeure. Savoir répondre rapidement et précisément à la demande d un client est souvent essentiel pour conquérir et conserver sa clientèle». Cette réactivité s applique à toutes les activités de l entreprise : en conception pour suivre (ou précéder) le marché, et développer et intégrer les innovations technologiques, en production pour synchroniser les commandes et optimiser les délais de réalisation [Di Mascolo 00], [Sadfi, 02]. Pour ce faire, les entreprises ont à répondre à un problème relativement simple dans son énoncé mais complexe dans sa résolution : concevoir un produit avec les fonctionnalités désirées, le plus rapidement possible, avec un coût et une qualité acceptables pour le client, tout en assurant leur pérennité. Ceci n est possible qu en «pilotant les dépendances entre les activités, analysant l action du groupe en terme de recherche de la performance des activités interdépendantes pour atteindre les objectifs en utilisant ou créant des ressources et en analysant l organisation à mettre en place pour faciliter la réutilisation des processus efficients» [Crowston, 97]. Ceci se traduit par une organisation non plus basée Page 23

24 Chapitre 1 Problématique sur des processus séquentiels mais basée sur un processus de conception intégré et une ingénierie simultanée [Prudhomme, 99] pour embrasser toute la problématique du cycle de vie du produit [Lonchampt, 04] et ce dans un contexte d entreprise étendue [Browne, 95]. Les différents aspects traités successivement dans les organisations séquentielles doivent désormais être pris en compte simultanément et conjointement, les acteurs auront alors à travailler en parallèle et à collaborer de plus en plus [Parsaei et Sullivan, 93]. La collaboration entre les acteurs est d autant plus nécessaire que la complexification croissante des processus oblige à intégrer de plus en plus d expertises souvent dispersées du fait de l organisation des entreprises [Midler, 97], [Poveda, 01], [Munoz, 02]. Un processus d entreprise est donc une œuvre collective et son achèvement nécessite la coopération de plusieurs acteurs, ainsi que la coordination du travail de ces acteurs [Lonchampt, 04]. Une approche globale qui tiendrait compte aussi bien des acteurs, de l organisation mise en place pour coordonner leur travail et du contexte dans lequel le processus se déroule est nécessaire pour maîtriser la performance de l entreprise. Ceci nous conduit à considérer non seulement les processus de l entreprise mais également l entreprise elle-même et plus globalement le contexte dans lequel ils se déroulent. La définition la plus couramment admise concernant le concept de processus est la suivante : «Le processus est un ensemble d activités inter-reliées utilisant des ressources afin de transformer des éléments entrants en des éléments sortants» [ISO 9000/version 2000]. Cette transformation est le résultat de l'écoulement d'un flux de nature informationnelle au travers d une succession d'activités qui le transforment et permettent de décrire le processus. Le Moigne [Le Moigne, 90] caractérise les modifications du flux comme suit : «modification au cours du temps (T) de la position du produit dans un référentiel "Espace-Forme" (E-F) et pouvant être identifiée à une somme de processements d'un flux de produit dans l'espace (transport), dans le temps (stockage) et dans la forme (transformation)». Diverses solutions organisationnelles et structurelles ont été mises en place pour répondre aux objectifs stratégiques des entreprises dans le cadre de leur adaptation à ces différentes contraintes et aux exigences du marché pour pérenniser leur place sur le marché. Pour répondre à ces problématiques d équipe virtuelle, de cycle de vie rapide, d un besoin d innovation important, de réglementation de plus en plus stricte, les entreprises espèrent trouver «la» solution qui leur permettraient non seulement d accroître le retour sur investissement, de diminuer la durée des phases de conception et de fabrication malgré les contraintes liées à ces phases, mais aussi d assurer d avantage la qualité et la traçabilité des produits et ce quasi immédiatement pour un coût modéré. La gestion informatisée des Page 24

25 Chapitre 1 Problématique organisations, des processus et des différentes activités de l entreprise et la dématérialisation sont apparues comme autant de solutions aux problématiques des entreprises. 2 La «r»évolution de l informatisation 2.1 L évolution de l informatisation Dans le milieu des années 80, le rôle de l ordinateur et celui de l être humain sont bien distincts. D une part, l ordinateur vient en «aide lors du traitement des dossiers individuels dont il facilite aussi le tri et la recherche ; et il permet de produire des indicateurs» [Volle, 06]. D autre part l être humain libéré de ces actions fastidieuses et sans valeur ajoutée mais pour autant nécessaires, se spécialise dans les tâches demandant une expertise métier : «il analyse l information pour faire le tour d un problème, l interprète pour comprendre, la synthétise pour résumer et communiquer ce qu il a compris ; enfin il décide ou même il conçoit.» [Volle, 06]. C est avec cet état d esprit que les entreprises investissent dans des automates et des mini-ordinateurs pour déporter les tâches répétitives de vérification, de calcul et de transcription vers les machines plus performantes que l être humain, en termes de puissance et de mémoire. Cette informatisation des entreprises ne s est pas faite sans mal et a posé de nombreux problèmes. En effet, chaque éditeur, pour tenter de se différencier, a développé de façon autonome ses propres outils, utilisant des interfaces et des bases de données propres, et souvent même son propre langage dit «propriétaire». Cette situation conduit à ce que les «contours fonctionnels» de ces outils soient réduits. Ainsi, pour mener à bien une activité, les usagers sont souvent contraints de se connecter à plusieurs «applications» informatiques aux ergonomies différentes. Autre conséquence directe du développement parallèle des applications : la mauvaise communication entre les outils et leur non-interopérabilité [Paviot, 10]. Les utilisateurs devaient ressaisir des données dans chacune des applications, à l aide de codes divers et variés et dont la mémorisation demande un apprentissage. Ceci ayant pour effet d accroître les risques d erreurs et de limiter le taux de performance. Loin d atteindre le niveau de performance qu elles étaient en droit d attendre suite à la mise en place d outils informatiques, les entreprises se contentaient d une performance «dégradée» directement liée à la capacité qu avaient les utilisateurs de s adapter aux outils et aux machines malgré les défauts de cohérence et de «convivialité». Cette tolérance ne durera pas et deviendra de plus en plus insupportable au vue du besoin croissant d informatisation et des pertes engendrées par celle-ci. C est le développement de la mise en réseau des micro-ordinateurs, dans les années 90, qui a déclenché la réelle prise de Page 25

26 Chapitre 1 Problématique conscience de la nécessaire cohérence dans l utilisation des outils informatiques : «pour toute donnée importante, seule doit exister sur le réseau une mesure définie et tenue à jour par le propriétaire de la donnée» [Volle, 06]. L informatique va alors évoluer avec pour objectif de fournir à l utilisateur «une interface qui, fédérant sous une ergonomie cohérente les accès aux diverses applications, lui évite les connexions-déconnexions et les doubles saisies tout en soulageant son effort de mémoire ; elle lui fournit aussi un média de communication» [Volle, 06]. Le concept de «système d information» apparait à ce moment là avec pour ambition de construire un référentiel unique sur lequel les diverses applications pourront s appuyer. Cette uniformisation induit non seulement la cohérence sémantique mais elle doit favoriser les échanges de données et une mise à jour mutuelle, ce qui assure la cohérence de leur contenu et supprime les ressaisies. Au-delà de l uniformisation se pose le problème de la «gestion» des échanges, de la nécessaire «orchestration» des actions à mener et de leur suivi/évaluation par le fait que l on assiste à un phénomène de dématérialisation du travail. Cette dématérialisation fait que les utilisateurs sont en grande partie libérés des tâches répétitives et fastidieuses (calculs, vérifications, transcription ) mais que les fonctions de logistique et de supervision (vérification de la qualité du travail fait, évaluation de la productivité des personnes, maîtrise des délais de production) sont devenues quasi impossibles. C est pour pallier à ces problématiques que le concept de workflows [David et al., 2001] [Benali et al. 2002] [WfMC, 99] à petit à petit vu le jour à la fin des années 90. Sous ce terme se cache des sortes de tables d adressage qui balisent les flux de données et offrent diverses fonctionnalités comme la traçabilité (possibilité de retrouver, de consulter et d identifier un dossier à tout moment de son cycle de vie), des indicateurs de volume, de délai voire de qualité. La maîtrise de ces aspects logistiques longtemps négligés par l informatique devient alors nettement plus performante comparativement à l époque de la gestion «papier» en supprimant le risque du «last in, first out», en assurant la traçabilité des dossiers et en produisant automatiquement des indicateurs de volume et de délai qui facilitent la maîtrise de la qualité. Les entreprises ont pris conscience de l intérêt stratégique d intégrer cette nouvelle «couche» d informatisation pour les processus internes clés, ces derniers devant si possible reproduire au plus près leurs pratiques professionnelles en articulant les fonctionnalités de l informatique de communication à celles du traitement des données structurées. Grâce à l évolution de l informatique de ces dernières années, le resserrement des relations entre l informatique dite communicante et le traitement des données structurées est devenu possible entrainant l essor de systèmes d informations évolués. Cette avancé technologique Page 26

27 Chapitre 1 Problématique amène à construire des solutions «sur-mesure» dont la définition, l extension et l évolution au sens large adhèrent aux besoins des utilisateurs pour que les solutions soient de réels supports à la prise de décision et parties intégrantes de la stratégie. 2.2 Du Système d Information support à la stratégie Originellement, un Système d Information (SI) est un ensemble de personnes, de procédures et de ressources qui recueille de l information, la transforme et la distribue au sein d une organisation [O Brien et Marion, 97]. Par opposition au SI manuel (basé sur l utilisation de papier-crayon), les SI modernes s informatisent, ce qui permet de mieux gérer non seulement la quantité grandissante de données mais également la complexité croissante de leurs contextes et de leurs interactions. Nous nous concentrerons ici sur les systèmes d informations informatisés, qui utilisent du matériel, des logiciels, des télécommunications et d autres techniques d information pour transformer les ressources en données et en divers produits informatifs, et plus spécifiquement en produits de gestion, qui orientent les dirigeants dans leur prise de décision. Dans ce cadre, un système d information peut se définir comme un système utilisant plusieurs ressources le matériel (machines et supports), le logiciel (programmes et procédures), le personnel (informaticiens et utilisateurs) afin d accomplir des activités d entrée, de traitement, de sortie, de stockage et de contrôle qui convertissent les données en produits informatifs [O Brien et Marion, 97]. Ces activités suivent un cours chronologique rythmant le cycle de vie des données. Dans un premier temps, les données sont rassemblées (collecte) et converties en un format acceptable pour le traitement (entrée). Ensuite, les données sont manipulées (mise à jour) et de nouveau converties mais cette fois en information (traitement), pour être emmagasinées en vue d une utilisation ultérieure (stockage) ou pour les communiquer/diffuser à l utilisateur final (extraction) selon des procédures de traitement (contrôle). En pratique, un SI n est pas un logiciel au sens propre du terme, mais la jonction d une interface homogène et d un orchestrateur (base(s) de données et des procédures) reliant plusieurs logiciels pour un domaine d activité (production, administration ). Pour qu un logiciel soit intégré dans le SI, il doit répondre aux contraintes techniques et stratégiques propre au logiciel mais également aux contraintes induites par les caractéristiques du SI. Selon [Gervais, 06], le SI est généralement composé de trois parties : - une interface graphique (pour interagir avec l environnement, essentiellement saisir et visualiser les informations), - une base de données (pour stocker, consolider et mettre à disposition les informations brutes ou résultantes), Page 27

28 Chapitre 1 Problématique - un ensemble de transactions (modélisant les procédures et les savoir-faire de l entreprise pour modifier et rendre utilisable les informations). Cet ensemble, nécessaire à l accomplissement des activités de l entreprise, est caractérisé par : - l utilisation de nombreuses données, - des relations complexes entre les structures de données, - des utilisateurs hétérogènes qui peuvent agir en concurrence, - des opérations impliquant plusieurs structures de données, utilisant un volume important de données, tout en préservant l intégrité des données modifiées, - une communication adaptée des requêtes des utilisateurs et une gestion des messages d erreur en cas d appel invalide des opérations. L efficacité d un SI est alors basée sur la qualité de la représentation de l organisation et de la modélisation des activités, pour une intégration fonctionnelle, afin de constituer non seulement la mémoire de l entreprise, mais surtout de générer les informations nécessaires à l ensemble des acteurs de l entreprise à tous les niveaux quelque soit leurs outils de travail quotidiens pour une intégration informationnelle [Laleau, 02], [Millet et al., 2005]. Les systèmes d information jouent un rôle capital dans l exploitation, la gestion et la réussite stratégique des entreprises et des autres organisations. Ils constituent aujourd hui une fonction vitale au sein des entreprises garantissant l efficience et l efficacité de ces dernières, clé de voûte de l obtention ou du maintien de leurs avantages face à la concurrence [O Brien et Marion, 97]. Ainsi les SI constituent un enjeu stratégique pour les dirigeants des organisations et prennent une position centrale dans l entreprise tant d un point de vue stratégique que fonctionnel. Leurs rôles sont de permettre l adaptation de l'entreprise à son environnement quelque soit les outils métiers mis en place en son sein et d assister l ensemble des membres de l entreprise dans leurs activités quotidiennes en fournissant à chacun les informations adéquates. L opérationnel accèdera à l ensemble des données nécessaires au traitement d un dossier. Le manager pourra suivre les indicateurs utiles au pilotage. Les études stratégiques et l analyse stratégique seront alimentées par les statistiques issues du système. L intérêt majeur des systèmes d information est de fournir des stratégies d'échange, de partage et d'intégration des processus techniques globaux de l entreprise à partir des éléments issus du savoir faire, contenus dans différents outils au contour fonctionnel précis, interconnectés ou non, mis en place dans tout ou partie de l entreprise. Chaque logiciel connecté au SI doit respecter, dans la mesure du possible, cette structure et cette philosophie pour ne pas risquer une perte d informations qui peuvent être stratégiques. Aujourd hui les SI ont donc un rôle crucial dans Page 28

29 Chapitre 1 Problématique la modification, l utilisation et la communication de l information au cœur des entreprises. Véritable moteur de la production et de la stratégie, les SI sont conçus pour se rapprocher et s adapter aux besoins et aux habitudes de l entreprise voire de l utilisateur. Cette adaptation n est possible que si l entreprise a une forte volonté d identifier et de définir l ensemble de ses procédures, de ses habitudes et des besoins de chacun des usagers au moment de la conception du système d information. Ce n est que parce que la modélisation de l entreprise aura été bien menée que le SI sera bien implémenté et implanté, celui-ci n étant que le reflet des données, procédures, processus ou workflows que nous voulons bien mettre à l intérieur. 2.3 Au Système d Information partie intégrante de la stratégie La mise en place d une solution logicielle représente une réponse spécifique à un problème donné. Lorsque ce problème concerne la réalisation d une tâche dans une activité assez opérationnelle, la solution logicielle sera souvent «standard» (outil de bureautique, modeleur 3D, etc.) et ne nécessitera que la formation des personnes ayant à manipuler l outil et qu une légère remise à plat des procédures. Dans le cas de la mise en place de logiciels d aide au pilotage et à la gestion des données, la problématique est plus stratégique et concerne généralement l entreprise dans son ensemble. Elle est donc à aborder de façon plus globale. Pour ce faire, il n existe pas de solutions «standards» d implémentation et d implantation qui permettraient de se dédouaner d une analyse préalable de l entreprise et de ses besoins propres, et d un paramétrage spécifique de l outil en fonction de cette analyse. Ce n est qu une fois adaptées au contexte d utilisation donné, que ces solutions logicielles deviennent un des éléments support à la stratégie de l entreprise en s intégrant dans son système d information qui hébergera les données et documents représentant une part de la connaissance des acteurs de cette dernière [Millet, 08]. La maximisation de cette adaptation correspond au minimum pour assurer l utilisabilité de l outil, définie par la norme ISO [ISO , 08], comme «le degré selon lequel un produit peut être utilisé, par des utilisateurs identifiés, pour atteindre des buts définis avec efficacité, efficience et satisfaction, dans un contexte d utilisation spécifié». Si le système mis en place ne suit pas au plus près les processus réels qui ont cours dans l entreprise, si la sémantique employée par les outils logiciels ne correspond pas à celle des acteurs de l entreprise, si les utilisateurs ne retrouvent pas leurs habitudes de travail, l outil ne sera pas ou peu utilisé et les données risquent d être pauvres, erronées et inexploitables. Le gain pour l entreprise sera donc nul et les évolutions du SI seront donc perçues comme négatives et néfastes. Les changements organisationnels que les dirigeants auront à faire dans l avenir seront alors plus difficiles à faire accepter aux Page 29

30 Chapitre 1 Problématique utilisateurs. Pour éviter ces écueils un tel projet d implantation d un nouvel outil devra s accompagner d une démarche spécifique qui permet de structurer méthodiquement et progressivement une réalité à venir. [ ] Il sera défini et mis en œuvre pour répondre aux besoins d'un client [ ] et impliquera un objectif et des besoins à entreprendre avec des ressources données comme le définit l AFNOR [AFNOR X50-105, 94]. Du point de vue de l entreprise «cliente», l implantation d un outil de gestion se fait, comme de nombreux systèmes d informations, en quatre étapes [Botta et al, 01], [Le Duigou, 10] : - Une phase de définition du projet : le maître d œuvre définit les besoins, établit le cahier des charges et l équipe projet. - Une phase de sélection de la solution : les éditeurs sont mis à contribution pour prouver que leur outil répond le mieux aux exigences du maître d œuvre. - Une phase d implémentation : la solution est paramétrée et installée, le personnel est formé, on applique une stratégie de diffusion (large fonctionnalité, peu d utilisateurs puis de plus en plus d utilisateurs ou peu de fonctionnalités, beaucoup d utilisateurs puis de plus en plus de fonctionnalités). - Une phase d évolution : la solution est utilisée par tous les utilisateurs, l entreprise évolue, de nouveaux besoins sont identifiés. L entreprise aura donc nécessairement à définir un objectif, qui peut se décliner en termes de qualité, de coûts et d échéance ; des moyens, correspondant à des ressources (des hommes, des techniques, de l information, de l argent), à décrire l organisation de ces ressources dans le cadre du projet et à identifier des conditions et/ou des contraintes limitatives. La qualité du projet et de son management seront conditionnés par la façon dont seront pris en compte ces différents éléments et dont leurs interactions seront gérées. Du point de vue de l éditeur de la solution logicielle, la spécification et le déploiement d'un outil de gestion au sein d'une entreprise nécessitent de : - Analyser les besoins «métier» de l'entreprise, - Établir un modèle de données et une cartographie des processus cibles, - Implémenter ces modèles dans les systèmes d'information supports, - Développer des fonctionnalités et méthodologies spécifiques au «métier» de l'entreprise, - Expliquer l'approche «PLM» aux collaborateurs, - Déployer et reprendre les données - Assurer la formation et le support. Page 30

31 Chapitre 1 Problématique Pour que les solutions logicielles apportent un gain substantiel, leur implantation doit s accompagner d une réflexion sur l organisation et plus particulièrement sur les processus internes de l entreprise. La valeur ajoutée dépend en grande partie de l alignement entre le modèle organisationnel de l entreprise et celui porté par le logiciel [Neubert, 09]. Autrement dit, les projets de gestion intégré ne sont pas uniquement des projets informatiques, car le pouvoir structurant de ces logiciels impose bien souvent une réorganisation importante de l entreprise ce qui en fait de véritables projets d intégration [Neubert, 09]. Le rôle de l éditeur est donc d accompagner l entreprise dans cette réflexion et dans la formalisation, souvent pour la première fois, d un référentiel «métier» permettant à chacun de partager une même vue des objets «métiers» manipulés et des processus parcourus. Cette phase constitue un prérequis indispensable à tout déploiement d'un système informatique car elle est censée limiter les taux de non assimilation et de non utilisation des outils. Ce référentiel se construit par une analyse fine de l existant tant d un point de vue «terrain» (besoins, méthodologie, support, échéance ) que d un point de vue informatique (sémantique, interopérabilité, orchestration ) afin d être en adéquation avec les besoins propres de l entreprise. Cette analyse fine oblige à la définition précise d objectifs globaux et locaux puis à leur déclinaison en objectifs spécifiques, mais aussi à la spécification des cadres d utilisation, de flux à dématérialiser et enfin d éléments nécessaires au paramétrage. Au regard de la complexité de la tâche, la mise en place d un outil de gestion dans une entreprise doit être comprise comme un projet stratégique à moyen et long terme qui obligera à un engagement fort de la part de l entreprise comme de tous les intervenants. Les entreprises sont souvent en quête de solutions informatiques clés en main mais aujourd hui rares sont les logiciels pouvant répondre exactement et complètement à leurs vastes besoins. Ainsi, plusieurs outils informatiques sont généralement nécessaires pour répondre à l ensemble de leurs exigences. Chacun d eux répond à un contour fonctionnel déterminé, basé sur une ou plusieurs fonctions plus ou moins étendues (GED, calcul, simulation, archivage, processus ). Le projet d informatisation se doit donc de prendre en compte non seulement l implémentation de chacune de ces briques mais surtout l orchestration de toutes ces solutions au sein d un même système d information global capable d assurer la cohérence des flux et des données induites par chacune des briques pour parvenir à optimiser l organisation de l entreprise mais en aucun cas pour la restructurer ou de la rigidifier. La spécification d un tel réseau de SI implique d évoluer du seul paradigme d intégration vers un paradigme d interopération [Fisher, 06] où l agrégation est le mécanisme «de construction» des relations entre des SI distribués, et participant au pilotage Page 31

32 Chapitre 1 Problématique du Système Entreprise. Ce mécanisme se différencie du mécanisme de composition qui est assimilé à une vision monolithique d un SI décomposé en SI structurel tel que préconisé par MERISE6 [Tardieu et al., 83] [Tardieu et al., 85]. La difficulté majeure rencontrée dans l ingénierie de SI distribués, hétérogènes et autonomes, concerne la complexité de leur assemblage pour former un SI d entreprise cohérent au regard d une performance globale à atteindre [Mayer et Auzelle, 07], [Auzelle et al., 08]. En effet, ces SI étant pour la plupart considérés comme des composants sur étagères (COTS), leur configuration doit prendre en compte les propriétés et les fonctionnalités d un assemblage plus global auquel ils vont participer tout en conservant les conditions opérationnelles propres à chacun. Nous allons voir dans la section suivante la problématique liée à la mise en place de solutions logicielles dans les entreprises en étudiant les verrous contraignants leur implantation. 3 Les verrous de l implémentation d un Système d Information en entreprise Toutes les entreprises ont besoin d échanger des informations et des connaissances, aussi bien en interne qu en externe avec leurs partenaires, leurs clients et leurs fournisseurs. Les systèmes PLM peuvent être une réponse à ce type de problématique. Les principaux problèmes mis en évidence dans les travaux de Sansonnet [Sansonnet, 04] et par les enquêtes de terrain [Bissay, 10] sont les suivants : - L hétérogénéité organisationnelle ou la difficulté de modélisation des processus et des données d entreprise : L'hétérogénéité organisationnelle nait donc du fait que les éditeurs ont généralement développé leurs outils relativement à des entreprises qui ont grandies et prospérées chacune séparément des autres et construit leurs propres organisations indépendamment de celles des autres. Par conséquent, la même tâche pourra être exécutée de manière différente dans deux entreprises distinctes mais les outils devront malgré tout s adapter [Blanc 05]. La modélisation des processus est une source de problème pour les entreprises. Elles n ont pas toutes formalisé leurs processus actuels et ne savent pas forcément quels processus mettre en place. Le lien entre stratégie, besoins et processus n est pas présent de manière explicite. De manière plus pragmatique la modélisation des données et du Système d Informations (première étape à la modélisation d entreprise) est une compétence qui n est pas présente au sein de toutes les entreprises. Il est alors impératif d implanter le modèle de données adéquat lors de l installation du logiciel par les consultants sous peine de garder un Page 32

33 Chapitre 1 Problématique modèle non adapté. Le modèle de données est indispensable au bon déroulement des processus souhaités. - L hétérogénéité sémantique et le problème d adéquation des fonctionnalités avec les besoins : L'hétérogénéité sémantique est liée au fait que les applications qui interagissent sur la base d agents ont souvent été définies et construites par des personnes différentes, en des lieux différents, à des moments différents, dans des buts différents, avec des vocabulaires différents [Hewitt, 85]. Il ressort de tout cela des difficultés d interopérabilité non plus au niveau du transport et des langages de communication mais au niveau des contenus informationnels eux-mêmes : c est ce problème qui est qualifié d hétérogénéité sémantique [Sansonnet, 04]. Les fonctionnalités des PLM actuels découlent souvent des besoins de grands donneurs d ordres car ils ont été les premiers à travailler avec les éditeurs au développement de ces outils. Ces problèmes de sémantique se retrouvent donc dans les outils puisqu ils sont structurés relativement à leurs organisations et leurs usages qui ne sont pas forcément transposables à d autres entreprises. Le travail de mise «en phase» des besoins d une entreprise et des fonctionnalités de l outil est alors parfois complexe. - Manque d interopérabilité avec les autres systèmes d informations : Longtemps, les systèmes distribués ont été peu interopérables. Aujourd hui de gros progrès ont été faits et les architectures de systèmes multi-agents en particulier ont contribué à diminuer fortement la question du transport de l information, de manière indépendante des conditions matérielles c est-à-dire des machines et/ou des systèmes d exploitation sous-jacents [Sansonnet 04]. La principale interopérabilité exigée concerne les échanges avec le système d informations interne. Il s agit principalement de lier le PLM, la CAO et l ERP. Dans le cadre d activité d entreprise étendue, une interopérabilité avec les systèmes PLM du réseau d entreprises partenaires est également nécessaire [Paviot, 10]. Nous allons nous intéresser dans les sections suivantes à montrer en quoi ces trois types d hétérogénéité sont autant de verrous à l implémentation d une solution logicielle dans une entreprise. 3.1 L organisation polymorphe des entreprises D un point de vue organisationnel, les entreprises ont dû prendre des décisions stratégiques pour rester concurrentielles. Les bouleversements ont suivi une évolution progressive et souvent cumulative au fil du temps : l automatisation, l informatisation, la Page 33

34 Chapitre 1 Problématique sous-traitance La dernière tendance était d opter pour la délocalisation de tout ou partie de leur savoir-faire requérant généralement un niveau accru de dématérialisation des documents et des flux. Ainsi, la réalisation d une activité nécessite un ou plusieurs acteurs, appartenant à une ou plusieurs sociétés, sur un ou plusieurs sites, avec un ou plusieurs outils, avec une ou plusieurs sources d information pour parvenir à un résultat. Tous les acteurs du cycle de vie du produit sont donc amenés à travailler à distance avec une équipe «virtuelle» dispersée nationalement ou internationalement, travaillant sur des créneaux horaires différents et avec différents outils informatiques. Pourtant, pour garantir la qualité et la durée des processus, les actions de chacun de ces acteurs sont rarement séquentielles et la formation des acteurs aux outils (physiques comme méthodologiques) reste trop souvent négligée voire inexistante. Par conséquent, ces derniers ne doivent pas seulement posséder des compétences dans leur domaine, mais également en informatique, tant sur des outils bureautiques que sur des produits métiers plus ou moins variés, et avoir des qualités de collaboration, de communication et plus largement de management. Cette diversité de compétences imposée par le système oblige les acteurs à endosser plusieurs rôles dans l entreprise, en conservant toutefois une qualité d expert dans leur domaine de prédilection. Cette pluridisciplinarité, pouvant être pesante voire stressante pour le personnel, est amplifiée par un turn-over important du personnel souvent encouragé par les entreprises. Ces dernières espérant, par ce biais, accroître leur capacité d innovation, grâce à un œil neuf, mais aussi leur performance, une nouvelle entité n étant par définition pas encore ancrée dans une routine donc moins rétissante aux changements. Par contre d un point de vue stratégique, quelques soient les changements, les acteurs et leurs conditions, le produit doit être mis sur le marché dans des délais de plus en plus courts, à moindre coût et avec un niveau de qualité jugé acceptable. Or la mobilité du personnel entraine nécessairement un niveau de compétence et de connaissance fluctuant en fonction des profils. Les acteurs se retrouvent confrontés à la rétention d informations, de connaissances mais également de données métiers dans des carnets personnels. Face à l ampleur de ces phénomènes, le risque de perdre une compétence particulière mais surtout une connaissance métier a été évalué comme majeur par les entreprises ces dernières années. Pour minimiser ces risques, les entreprises ont lancé une campagne de formalisation des process de fabrication. Ces «procédures» ont longtemps évoluées au cours du temps sans un suivi rigoureux, ni de validation. Chacun ajoutant des étapes mal explicitées ou pas détaillées, des compléments d information, voire des correctifs. Malgré tout, ces procédures décrivaient rarement unitairement les actions à réaliser, elles correspondaient plus souvent à des check-lists et des mémos qu à de véritable mode Page 34

35 Chapitre 1 Problématique opératoire. Autrement dit, les nouveaux arrivants, internes ou externes, devaient nécessairement passer par une formation pour parvenir à un niveau suffisant de transmission de compétence et de connaissance complémentaires à ces «procédures». Cette période, selon les individus et la technicité du poste, pouvait s étaler dans le temps tout en sachant que la transmission ne pouvait pas être totale. Malgré cette perte de performance, les entreprises étaient conscientes de la nécessité de cette période de transition pour parvenir à un niveau de qualité similaire. Force est de constater que la formalisation, généralement mal cadrée, ne parvenait pas à lever le verrou lié au postulat ethnique que la transmission de connaissances et de compétences n est pas naturelle dans le cadre professionnel en France. Les entreprises tentent alors de freiner cette perte de connaissance et d efficacité via des outils de capitalisation et des formations continues internes. Cette prise de conscience et les moyens mis en œuvre restent bien souvent insuffisants face à cette mutation des rôles des acteurs et de la définition d une activité. En effet, si les acteurs deviennent multi-compétences et accumulent des connaissances, bien souvent, ils ont tendance à se sentir incompétent dans tous les domaines. Ce sentiment à des conséquences directes sur la qualité de leur travail et donc du produit. Tout ceci induit inévitablement un manque de confiance en soi, des difficultés à anticiper et prendre les décisions dans les temps. Or, les bases de connaissances capitalisées mises en places actuellement ne permettent pas de remplacer l expérience des années face aux situations critiques rencontrées sur le terrain. Seul l échange et la communication - où la transmission ne se concentre pas uniquement sur un simple principe de «constat solution» mais apporte également le contexte, la démarche d analyse qui a permis d élaborer la solution et les moyens préventifs mis en place - pourraient limiter ces problèmes. Mais les changements organisationnels (de rôles, de statuts, de hiérarchies ) génèrent des tensions et des conflits d intérêt souvent sous estimés par les entreprises, ce qui défavorisent ces échanges pourtant essentiels. Autrement dit, les compétences, les connaissances et la collaboration sont indissociables pour parvenir à limiter les pertes tant de performance que d efficacité d un point de vue stratégique pour l entreprise. Pour pallier à ces problématiques une activité ne peut donc plus être perçue comme une action individuelle mais comme une coopération (sous entendu collective). Ainsi la qualité du produit est régie par le professionnalisme de l équipe en charge et le processus mis en œuvre mais surtout par la qualité de l échange d informations et la collaboration non seulement entre les personnes (de l équipe projet et en dehors) mais également entre les outils utilisés tout au long du projet [Ostergaard et Summers, 03]. L impact de cette nouvelle perception d une activité conditionne les méthodes de travail du personnel ainsi que les différentes phases du Page 35

36 Chapitre 1 Problématique cycle de vie d un produit/projet (l étude, la conception, la production ). Or aujourd hui, ces différents processus doivent non seulement respecter les contraintes techniques classiques et organisationnelles actuelles, mais également les nouvelles contraintes imposées aux entreprises. Ainsi la mode des «entreprises éco-citoyennes» intégrant les contraintes environnementales, a obligé les entreprises à se soumettre aux réglementations accrues impliquant de maîtriser la qualité et d assurer la sécurité des produits, et des Hommes. En effet, aujourd hui, il n est pas concevable de mettre un produit sur le marché sans pouvoir assurer sa qualité, sa traçabilité et la sécurité (des sites de production et de la signalétique du produit). Ce nouvel aspect réglementaire dans les entreprises fut vecteur d une période de formalisation, de cartographie et de documentation de l entreprise pour obtenir les certifications qualités souvent perçues comme gage de leur réussite. Les dysfonctionnements majeurs des méthodes utilisées de formalisation se situaient au niveau de l abondance de la documentation, du caractère fastidieux de sa mise à jour, de la rigidification des processus liés à la production des documentations et donc inadéquates aux réalités changeantes du terrain et finalement de l utilisation et de la mise en œuvre de ces outils. Aujourd hui, cette période est révolue. Non pas que les entreprises n aient plus besoin d être certifiées, bien au contraire, mais la méthodologie et les moyens mis en œuvre actuellement doivent permettre d obtenir cette certification mais surtout de la conserver à moindre effort. Cette évolution a pour objectif non pas de sur-documenter comme dans le passé, mais plutôt d identifier et de suivre les différents points critiques tout au long du cycle de vie de façon rationnelle et fonctionnelle. Les axes majeurs sont orientés vers l utilisation et l évolutivité de la documentation et des processus en fonction des contraintes du terrain, vers l étude des impacts d une modification ou d un problème, mais également le suivi des points critiques. Encore aujourd hui, beaucoup d entreprises, cherchant à maximiser leur ROI (Retour sur Investissement) à moindre frais et dans des délais de plus en plus courts, n ont pas pris en considération l importance de revoir leur système qualité et sécurité. Bien souvent, les performances et l efficacité de ces entreprises sont finalement pénalisées par ces contraintes réglementaires. Leur plan d assurance qualité représente un frein à leurs évolutions potentielles, à l innovation mais surtout au bon déroulement des processus. Ces différentes contraintes cumulatives et croissantes sont essentiellement dues au marché mondial et au niveau d exigence croissant des clients. En effet, face à la concurrence de plus en plus forte, la durée du cycle de vie d un produit a fortement diminuée ainsi que la durée de présence de ce dernier sur le marché. Le «time-to-market» doit être minimisé et la rentabilité doit être assurée durant la période d exploitation pour maximiser les profits. De plus, pour Page 36

37 Chapitre 1 Problématique répondre à cette ère de la consommation à outrance, le taux de renouvellement des produits doit être important, ce qui se traduit d un point de vue industriel par une explosion du nombre de projets et un nombre exponentiel des références produits. Or dans l organisation et la structuration des entreprises, les interactions et les implications croisées non seulement entre les projets/produits mais également entre les hommes et entre les données sont inévitables et complexifient les flux. Toutes les difficultés énoncées précédemment étant démultipliées également par une priorisation des actions à mener souvent arbitraire et se faisant au fil de l eau par les acteurs dépourvus de tout ou partie de la vision globale et transverse des produits/projets, voire de l entreprise. Cette situation est antinomique à la profitabilité d une entreprise, car progressivement son fonctionnement se sclérose, des sous-entités anarchiques se forment et compromettent sa stratégie. Or ces différents mauvais fonctionnements voir dysfonctionnements dans certains cas, n étaient pas identifiés, volontairement ou non, voire identifiables par les managers et les conséquences n étaient pas mesurées ou mesurables. Compte tenu de la complexité et quantité croissantes des projets, pour autant nécessaires pour assurer la pérennité de l entreprise, le pilotage est devenu un axe stratégique pour les entreprises. Initialement, les entreprises se contentaient de se fixer une cible «textuelle» à moyen terme. Poussées par les financeurs, ces cibles se sont transformées en objectifs chiffrés à moyen et long terme. Progressivement, ces derniers ont été déclinés en objectifs chiffrés aux dirigeants des services. L évaluation portait généralement sur les critères traditionnels : le coût, la qualité et les délais [Porter, 86], [Hazebroucq, 99]. En l absence d outils fonctionnels et par manque de méthode, ce pré-pilotage n était en fin de compte qu un simple suivi a posteriori basé sur différents récapitulatifs (ou reporting : rapport, tableau de bord, compte rendu ) présents dans l entreprise, réalisés périodiquement parfois associés, manuellement, à des éléments prévisionnels. Aujourd hui pour permettre leur développement et assoir leur position sur le marché, les entreprises ont besoin d entrer dans un mode de pilotage en temps réel, vecteur d anticipation, d innovation et d amélioration de la pertinence et de la qualité du pilotage. Après cette prise de conscience de l impact préjudiciable des dysfonctionnements de leur organisation et de leurs procédures, la mise en place d indicateurs de performances devient une nécessité. Rapidement, les entreprises se sont confrontées aux problématiques de définition de ces indicateurs et des moyens de les mesurer et de les suivre. En effet, par définition, un système de pilotage est l agrégation d indicateurs [Ducq, 99], [Ducq, 05] qui permet de dégager l information nécessaire à l optimisation et à la prise de décision en amont Page 37

38 Chapitre 1 Problématique de l action. Suite à l essor de l implémentation d outils informatiques au sein des différents services, les entreprises qui manquaient précédemment de données pour permettre ce pilotage, se heurtent à présent à l abondance d informations non ordonnées, ni consolidées, ni reliées entre elles issues de la multiplication des applications dédiées à l entreprise, au site, à l équipe, à une activité... Un traitement plus ou moins complexes doit être réalisé pour parvenir à synthétiser et mettre en valeur les chiffres clés pour l entreprise et les décliner ensuite en indicateurs clés de performance (KPI) sur une échelle de temps plus faible (la semaine, le mois, le trimestre ) au niveau des services, des équipes, des lignes de production, d un produit/projet selon les structures, la criticité et les ambitions de l entreprise. Cette complexité, nécessitant une étude longue et coûteuse, décourage souvent les entreprises qui ne mettent alors en place non pas un système décisionnel centralisé mais un système de pilotage partiel de leurs activités. 3.2 La vision transverse : hétérogénéité organisationnelle La réussite d un projet informatique passe par la clarté de la vision globale du projet au sein de l entreprise et la qualité de transmission de ces données par les deux parties en présence lors de la conception de l application : le chef de projet côté entreprise et le chef de projet côté éditeur. Pour parvenir à une solution logicielle adéquate pour l entreprise, les objectifs doivent être clairement définis tant d un point de vue stratégique, champ d application, fonctionnel que technique. Ces éléments définis en partie en avant-projet, ne sont pas forcément bien appréhendés par les chefs de projets découvrant le projet au moment du lancement. La bonne compréhension de la portée du projet permet d identifier les différents enjeux et contraintes potentielles sous-jacentes. Une maturité suffisamment avancée du projet non seulement au sein de l entreprise mais surtout pour les différents acteurs du processus est nécessaire. Cette phase est évidement basée sur l échange et la communication entre le personnel de l entreprise, entre le personnel de l éditeur et entre les chefs de projet. Durant cette phase l éditeur doit être attentif et à l écoute de toutes les informations pouvant lui permettre d acquérir au plus vite une vision transverse du projet et estimer la criticité du besoin afin de proposer un planning approprié prenant en compte la complexité du projet dans son ensemble mais également les solutions adéquates lors de la conception pour une exploitation optimum à long terme de l application. Page 38

39 Chapitre 1 Problématique 3.3 La collaboration : hétérogénéité sémantique Au travers les premiers échanges entre les deux chefs de projet, une sémantique commune se met en place, plus ou moins naturellement. Cette brique élémentaire de la communication est un élément essentiel. Initialement, l entreprise en recherche d outil pour améliorer son organisation et la rendre plus performante, est souvent néophyte dans le domaine informatique et inversement, l éditeur l est dans la compréhension du fonctionnement de l entreprise voire du métier de cette dernière. La mise en place d une sémantique commune est cruciale pour assurer le bon déroulement des différentes phases du projet. Elle permet de limiter les mésententes et les désaccords basés souvent sur une mécompréhension mutuelle sur des aspects fonctionnels et techniques mal maitrisés ou méconnus par l un des deux intervenants. Dans le cas contraire, les conséquences en terme temporel et financier sont inéluctables et peuvent faire péricliter l ensemble du projet. Pendant toute la durée du projet, si les deux chefs de projet mettent en place un langage commun formalisé, auquel ils peuvent se référer en cas de doute, les anicroches pourront être évitées et la dynamique conservée. Ce lexique permet de faciliter la compréhension, les échanges, les compromis pour parvenir à une solution informatique adaptée au besoin. Cette étape est d autant plus essentielle que le niveau de personnalisation est conséquent. En effet, le degré de personnalisation est un élément à considérer dès le début de l étude, car il influencera la conception, les fonctionnalités, les développements, les tests et le déploiement. Initialement, ce dernier nécessitera une compréhension mutuelle d autant plus fine pour concilier les aspects techniques et fonctionnels, entre l entreprise et l intégrateur/éditeur du logiciel afin de déboucher sur la définition de ses spécificités. Cette étape vient en sus de la définition même du système. Ce surplus de travail se répercutera dans chacune des étapes et démultipliera d autant la durée de chacune des étapes du processus. Ainsi cette étape, souvent galvaudée, favorisera et améliorera d autant la collaboration entre les différents acteurs. La réussite de ce type de projet se base en grande partie sur la qualité de la collaboration entre les deux chefs de projet. La conséquence est directe sur toutes les phases du projet, mais plus particulièrement lors de la spécification et la modélisation. En effet si la collaboration est performante, le nombre d itérations pour parvenir à un compromis technique et fonctionnel entre les deux parties sur un des points sensibles voire critiques du projet, qu il soit standard ou spécifique à l entreprise, sera moindre. Il ne sera pas nécessaire de modéliser toutes les décisions unitairement pour s assurer de la bonne compréhension mutuelle. Le gain de temps peut se révéler très important en fonction de l envergure, de la complexité et de la spécificité Page 39

40 Chapitre 1 Problématique du projet. La pertinence de ces deux étapes du projet est également conditionnée par le premier facteur clé évoqué, la vision globale du projet. En effet, plus la définition globale du projet est précise, plus les chefs de projets pourront anticiper les spécifications mais également les besoins sous-entendus et/ou futurs dans la conception du système propre à l entreprise. Cette prise en compte au plus tôt des contraintes permet à long terme un gain de temps et d argent important tant pour l entreprise que pour l éditeur. La solution pourra être jugée comme un outil stratégique, perspicace et adaptée au besoin. Pour parvenir à ce résultat, les deux critères, qualité de la collaboration et vision globale, doivent nécessairement être réunis. 3.4 Une implémentation intégrée pour une meilleure interopérabilité Outre l aspect technologique, l interopérabilité est également un point clé de la conception et doit être prise en compte également au plus tôt dans le projet afin d uniformiser la sémantique employée au sein du système d information ce qui facilitera l interaction a priori ou a posteriori entre les différents logiciels [Paviot, 10] Ces éléments sont cruciaux pour pérenniser l implémentation, l utilisation et l intérêt tant au niveau individuel que stratégique du logiciel. C est pourquoi la vision transverse de la stratégie de l entreprise doit être identifiée au préalable pour anticiper au maximum les besoins futurs. En effet, quel que soit le besoin initial, la dématérialisation de flux a un caractère stratégique à court terme pour accroître la performance et l efficacité des activités, mais également à long terme pour enrichir le système d information et permettre une meilleure visibilité sur l ensemble des activités et leur pilotage. Si ces aspects sont prédéfinis dans le projet initial, la portée et l intérêt du logiciel en seront d autant plus reconnus et valorisés a posteriori. L un des problèmes sous-jacent de cette dématérialisation est que souvent l entreprise n a pas de vision agrégée et consolidée des informations et certaines opérations ou des éléments dématérialisés sont saisis dans l outil lors d opérations manuelles avec des risques d erreur et des indicateurs peuvent être non calculés car trop fastidieux ou s appuyant sur des données manquantes ou erronées. Pour lever cette contrainte, peu de solutions dite techniques sont envisageables : soit le système d information a été pensé dès sa création pour respecter ses contraintes, soit il faut agrémenter le système d information avec une solution centralisatrice des informations avec toutes les problématiques liées à la redondance et la synchronisation des informations, soit permettre la visualisation centralisée des rapports «équivalents» (sur la même échelle de temps, sur les données liées ) dans une même fenêtre. La première solution n est possible que lors de la mise en place de l ensemble d un système d information et répond donc qu à Page 40

41 Chapitre 1 Problématique une faible proportion des entreprises. La seconde est très coûteuse de part sa spécificité pour chaque cas et se révèle souvent difficile à maintenir. Malgré tout cette solution peut se positionner comme une solution intermédiaire intéressante de part les avancées technologiques qui permettent aujourd hui à des systèmes de «portail» de se connecter à différents logiciels informatiques en standard. Les difficultés qui apparaissent alors sont liées à la rigidité des outils (pas d évolution facile, pas beaucoup adaptables) et à la nécessité, dans des cas de plus en plus nombreux, de travailler sur des portails d entreprise déjà existants chez les clients. 4 Synthèse L évolution des besoins, des contraintes réglementaires et sociales ont poussé les entreprises à réagir et à s adapter à leur environnement pour continuer à exister sur le marché et pérenniser durablement leur activité. Pour répondre à leurs nouveaux objectifs, les industriels ont généralement optés pour des modifications d ordre organisationnelles et structurelles. Grâce aux avancées technologiques et à l utilisabilité des outils dans un cadre industriel, l axe «matériel» a connu un essor important et a souvent été perçu comme «la» solution «simple et rapide» à mettre en place pour accroître la performance de l entreprise. Face à la mondialisation et à la concurrence grandissante, la quête de l optimisation absolue reste le nerf de la guerre pour privilégier toujours d avantage l innovation à la production. A force de considérer que l optimisation locale engendre l optimisation globale, les entreprises ont mis en place bon nombre d outils informatiques pour répondre à des besoins locaux, sans prendre en considération la cohérence des informations stockées dans chacun d eux. Or avec l émergence des normes qualités et les réglementations de plus en plus strictes, la traçabilité et la responsabilisation sont devenues des critères primordiaux pour subsister sur le marché mondial. Autrement dit, les entreprises ont dû rapidement mettre en place des solutions de suivi et de stockage des informations liées aux produits/projets et à leur environnement. Au vue de la croissance exponentielle du nombre de produit/projet à gérer, pour répondre aux besoins accrus de nouveauté émis par la clientèle, les industriels se sont d autant plus tournés vers la dématérialisation et l informatisation de ces données pour réduire les coûts engendrés par ces nouvelles contraintes. Le recueil mais surtout la qualité des informations deviennent des enjeux stratégiques. De nombreuses informations liées au produit/projet sont déjà traitées dans les divers outils informatiques mis en place localement. Mais par manque de cohérence, toutes ces données doivent subir un traitement important pour les uniformiser et les fédérer avant l archivage. Page 41

42 Chapitre 1 Problématique Une stratégie d uniformisation informatique est alors nécessaire : les Systèmes d Information. Ce concept implique que tous les outils doivent respecter la même philosophie et les mêmes règles (de conception, d implémentation ) pour favoriser l échange, le partage et l intégration de processus entre les outils. Cette structuration commune garantira la qualité des données en évitant les ressaisies et les pertes d informations, ce qui permet également un gain d efficacité pour l entreprise. Pour maximiser leurs profits et tracer l ensemble des actions réalisées à moindre coût, les industriels cherchent des solutions informatiques leurs permettant de les aider à piloter et à gérer l ensemble des activités liées aux produits/projets. Pour cela deux types de logiciels de gestion proposés sur le marché provoquent un vif intérêt de la part des responsables informatiques : les ERP (Enterprise Ressource Planning), pour la gestion des ressources et des plannings, et le PLM (Product Life Management) pour la gestion des données techniques. L un comme l autre promettent de conserver la flexibilité et l adaptabilité de l entreprise étendue tout en uniformisant, fédérant, dynamisant et optimisant leur processus de gestion (une présentation générale et une comparaison des outils les outils ERP et PLM est fournie en Annexe 1). Or les industriels sous-estiment bien souvent l impact de l implémentation de tels outils au sein de leur société. En effet, pour garantir la qualité et la circulation des informations entre les différents acteurs du projet, la modélisation du logiciel doit être alignée sur le modèle de fonctionnement de l entreprise et du projet en question. Une réflexion et une remise en question de ces derniers doit donc être opéré avant la mise en place de la solution informatique pour ne pas risquer d omettre certaines possibilités, faire émerger les bonnes pratiques capitalisées et adapter au plus près l outil aux habitudes réelles de fonctionnement. Dans le cas contraire, le risque majeur est de rigidifier la structure et rendre inutilisable la solution. Une perte d informations et de traçabilité serait alors inévitable. Le déploiement d un logiciel de gestion ne se résume pas uniquement à un projet informatique devant s intégrer dans le système d information en place mais à un projet d intégration d envergure organisationnelle et technique. Au regard du contexte, des difficultés rencontrées par les industriels et des caractéristiques des solutions présentes sur le marché, il apparait que pour que le gain escompté soit probant, il est nécessaire d une part que l entreprise soit consciente de l impact structurant de ce type de projet et d autre part que les éditeurs et/ou intégrateurs proposent une méthodologie les aidant dans leurs démarches de réflexion et qu ils permettent un fort degré de flexibilité dans l outil et dans son implémentation. L enjeu de ce travail de recherche est d améliorer la Page 42

43 Chapitre 1 Problématique méthodologie de déploiement, voir les solutions proposées par LASCOM, éditeur de solutions de PLM. Page 43

44

45 Chapitre 2 Déploiement d une solution PLM Méthodologie de déploiement d une solution PLM 1 Introduction Chapitre 2 Longtemps réservées aux secteurs de pointe, essentiellement dans l aéronautique, les solutions logicielles PLM se démocratisent et font leur entrée dans tous les secteurs d activité industrielle. Cet essor alimente la réflexion tant des éditeurs d un point de vue fonctionnel («ce que l outil est capable de faire») que des intégrateurs du point de vue de la méthodologie de déploiement («comment mettre en place l outil chez le client») pour conserver leurs avantages concurrentiels sur le marché. La mise en place d un logiciel au cœur du système d information est un projet stratégique tant pour l entreprise, pour accroître ses performances, que pour l éditeur pour sa pérennité. Cette décision sous-entend pour les industriels que l investissement consentit doit rendre leur entreprise plus performante. De leur point de vue, la notion de performance possède une double nature. D une part la performance sera évaluée sur leur capacité à mettre en place des supports informatiques pour répondre aux contraintes (réglementaires, qualités, géographique, sous-traitance, partenariat ) sans qu il y ait de fortes perturbations dans le fonctionnement de l entreprise. D autre part, les attentes relatives à l outil informatique et plus généralement aux nouvelles technologies concernent l accélération des processus industriels afin de concevoir, produire, mettre sur le marché et vendre de plus en plus rapidement. Plus généralement, l intérêt d un tel investissement est de faire «mieux» que le système existant selon le triptyque coût/délais/qualité pour le produit réalisé. L objectif financier est réduit à améliorer le ratio coût, délais. Tandis que l objectif stratégique se concentre sur une meilleure maîtrise des éléments liés au produit/projet au sein de son environnement et ce durant l ensemble de son cycle de vie (éléments temporels, «qualité» et volumes de données manipulés, etc.). Pour répondre à cet objectif stratégique de maîtrise du cycle de vie du produit, l éditeur et/ou intégrateur doit atteindre trois objectifs techniques : - informatiser les données/documents, - conceptualiser les processus, - apporter des éléments de pilotage de l ensemble. Ceci l oblige à ce que l implémentation de son outil soit efficace et que son déploiement corresponde réellement et pleinement aux attentes fonctionnelles du client pour qu il soit Page 45

46 Chapitre 2 Déploiement d une solution PLM accepté par les utilisateurs et s intègre parfaitement dans l organisation et dans le système informatique (en étant livré dans les délais et en respectant le budget prévu). La problématique de l éditeur/intégrateur peut donc se résumer ainsi : Comment offrir une solution visiblement plus performante, intégrant l ensemble des activités impactant le produit et élargissant le champ fonctionnel pour satisfaire l ensemble des utilisateurs, sans qu elle ait un coût et un délai de mise en place prohibitifs? Pour ce faire, les aspects fonctionnels et méthodologiques doivent être en phase l un avec l autre mais aussi et surtout avec le marché et les attentes des clients. Afin d apporter une réponse adéquate à ces objectifs et à tous les niveaux hiérarchiques de l entreprise, il est nécessaire de modéliser toutes les activités impactant le produit constituant ainsi l environnement le plus complet possible de conception dans le logiciel support au PLM. Nous verrons dans ce chapitre que le problème majeur réside souvent dans le fait que l entreprise «cliente» et l éditeur de l offre logicielle ont du mal à concilier leurs objectifs communs. En effet, face aux avancées technologiques, les entreprises se sont fourvoyées quant aux capacités réelles des outils. Elles percevaient les logiciels informatiques comme des solutions miracles à leurs nouvelles problématiques à l instar de l automatisation des lignes de production par exemple. Idéalement les entreprises souhaitent un logiciel clé en main (standard), pour minimiser les coûts et les délais de déploiement, mais avec toutes les caractéristiques propres à leurs métiers et spécifiques à l organisation de l entreprise. Ceci pour limiter le temps de prise en main de l outil par l ensemble des acteurs et maximiser un retour sur investissement rapide. Cette posture peut être issue non seulement de la communication qui est faite sur le caractère flexible et paramétrable des outils informatiques en général, mais également de la transposition individuelle de la facilité d installation des logiciels tel que ceux de bureautiques. Or l éditeur ne peut satisfaire à cette attente de part l ampleur et l impact du déploiement d un outil de gestion des données et des flux, qui ne sont pas comparables d un point de vue analyse, conception et déploiement à ceux d un logiciel bureautique. La solution logicielle n étant souvent que peu modulable, il est important de bien cerner les éléments qui la structurent pour ainsi cerner en quoi cette structure peut être un facteur contraignant pour le client et pour l éditeur lors de la mise en place de la solution. Nous allons dans un premier temps décrire les composants «classiques» (ou briques fonctionnelles) d une solution PLM pour identifier les besoins en méthodologie de déploiement et en particulier en méthodologie de modélisation. Puis nous analyserons en quoi Page 46

47 Chapitre 2 Déploiement d une solution PLM ces besoins peuvent être source de difficultés et nous proposerons des pistes de réflexion pour lever ces difficultés, pistes qui seront étudiées dans les chapitres suivants. 2 Les briques fonctionnelles Pour répondre aux besoins de gestion de la conception produit, en termes de performance et de conception, le marché regorge de nombreuses solutions logicielles telles que Windchill de PTC, Agile d Oracle, TeamCenter de Siemens, ENOVIA de Dassault, LASCOM PLM de LASCOM Chacune de ces solutions possèdent ses particularités, ses atouts et ses points faibles mais toutes sont structurées autour de 4 briques fonctionnelles identiques La gestion électronique documentaire : la mémoire de l entreprise Dans l organisation des entreprises, il apparait clairement deux grandes contraintes : un turn-over rapide, favorisant certes l innovation au sein de l entreprise mais également la perte de savoirs, et des normes de plus en plus strictes à respecter selon les domaines d activité, nécessitant le respect et la traçabilité de tous les documents utilisés. Ce contexte propulse peu à peu la capitalisation des connaissances au cœur des entreprises pour éviter la perte d informations cruciales. Longtemps, le coût de ce type de projet représentait un frein pour les entreprises au regard de l investissement essentiellement temporel pour concevoir, alimenter et mettre à jour ce type de base. Mais aujourd hui, les entreprises doivent faire face aux modifications significatives de leur organisation, à la concurrence mondiale toujours plus importante quelque soit le marché et à la course effrénée à l innovation. Il leur faut produire des nouveautés, en plus grand nombre dans un temps de plus en plus restreint. Le choix de la capitalisation de l information sous format électronique apparait comme la clé de voute de la prospérité des entreprises pour pérenniser leur place sur le marché en conservant et réutilisant leurs savoirs sur l ensemble de leurs produits/projets. L implémentation d une gestion documentaire répond en grande partie à ce besoin. Elle a pour objectif de créer un référentiel unique avec une structuration des documents et de leur classement. Les intérêts de la mise en place d une telle base sont multiples pour les entreprises. En effet, cette dernière constitue la mémoire de l entreprise et facilite de surcroit la recherche de documentation, l échange des savoirs-faires et des expériences, la traçabilité et l intégration de nouveaux arrivants. Ainsi le module de GED est un outil pertinent aux regards de ces éléments en structurant les informations selon leur nature grâce à la définition d un modèle de données adapté. Il offre une réponse pour respecter les critères de plus en plus Page 47

48 Chapitre 2 Déploiement d une solution PLM contraignants de la législation mais surtout pour constituer une véritable base de connaissance facilitant la capitalisation mais également la traçabilité des données, des produits, des projets grâce au suivi de version. L application assure ainsi l unicité des données tous les utilisateurs ont accès à la même «vraie» information, la recherche tous les utilisateurs ont accès rapidement à l information et l archivage des données tous les utilisateurs peuvent se référer aux informations capitalisées. Pour répondre au besoin d accessibilité et de traçabilité des informations, la majeure partie des outils sur le marché intègre cette première brique de gestion documentaire connectée intrinsèquement au moteur de la solution comme l illustre la Figure 1. Figure 1. La brique fonctionnelle «Gestion des Configurations» La gestion de configuration : la représentation réelle d un produit/projet Les industriels proposent des gammes de produits de plus en plus diversifiées, afin de répondre aux exigences des clients en proposant régulièrement de nouveaux produits avec un «time to market» minimisé. La durée de vie globale des produits se trouvant réduite, le cycle de conception a du être optimisé. Pour répondre à cette contrainte, les entreprises ont mis en place des équipes virtuelles, autrement dit les différents intervenants ne font pas forcément parties du même service, de la même filiale voire de la même entreprise. Il est alors essentiel non seulement que tout le monde travaille sur la même version des documents, mais surtout que chacun est la même vision du produit adaptée à son métier. De plus, la coexistence de nombreuses variantes pour chacun des produits impose un suivi et une traçabilité fine pour faciliter la maintenance et la réutilisation des connaissances acquises tout au long des projets. Autrement dit, les entreprises ne cherchent pas seulement à gérer leurs documentations mais l ensemble de leurs gammes de produits tout au long de leur cycle de vie. Le besoin réside donc dans la gestion des documents mais aussi des liens qui existent entre ces derniers. Ce Page 48

49 Chapitre 2 Déploiement d une solution PLM sont tant ces liens que les documents qui constituent et restituent la complexité du produit dans la base de connaissance à travers soit sa nomenclature, sa recette, son dossier d exécution Dans la littérature cette arborescence, ou configuration, est désignée, selon la norme ISO [ISO 10007, 03], comme l ensemble des caractéristiques fonctionnelles et physiques d un produit définies par des documents techniques et obtenues par le produit. On parle par exemples, de configuration de référence, de configuration applicable, de configuration documentaire, de configuration réalisée selon les étapes atteintes dans les projets, etc. La gestion de configuration consiste à gérer les informations qui décrivent la structure du produit, en particulier sa décomposition en sous-ensembles et pièces élémentaires. Elle permet de superviser la totalité du cycle de vie d'un produit, elle comporte l'identification des composants qui doivent être contrôlés (éléments de configuration), le contrôle des évolutions apportées à ces éléments (y compris la documentation), ainsi que des fonctions et des mécanismes permettant d'auditer et de contrôler toutes les actions effectuées. La gestion de la configuration permet donc de formaliser et de présenter de manière claire et complète la configuration du produit à un instant donné et l état d accomplissement des exigences physiques et fonctionnelles. Selon le domaine d activité et selon les entreprises, la définition comme la constitution d un document, divergent. En effet, la structure des documents (le nombre de propriétés propres et provenant d autres items par exemple) et les propriétés des liens entre ces derniers atteignent différents degrés de complexité. Ainsi la difficulté est issue : soit de la quantité d informations importante au sein du document, soit de la présence obligatoire de fichier spécifique associé à un ou plusieurs documents, soit de la précision de la structure d un produit basé sur de nombreux documents (nomenclature, recette, ) Ces diverses perceptions d un document engendrent de multiples niveaux de complexité lors de la création d une GED et du suivi des documents. Le plus ardu reste la gestion de cette arborescence hiérarchisée de documents communs à différents dossiers (c est le cas d une nomenclature, ou d une liste d ingrédients ). En effet, le suivi, l impact des modifications sur les différents documents, la mise à jour de ce type de structure sont souvent cruciales pour les entreprises. Si les caractéristiques d un élément sont modifiées, il est essentiel que l utilisateur identifie les impacts sur l ensemble de la base de son action, et qu il puisse choisir de modifier ou pas tous les produits/projets utilisant cet élément. Pour résoudre ces contraintes liées aux structures complexes, la gestion de configuration est une composante essentielle. Cet outil entièrement intégré à la solution permet de créer, Page 49

50 Chapitre 2 Déploiement d une solution PLM modifier et supprimer une configuration. Son utilisation est facilitée grâce à une interface dédiée, accessible dans un onglet présent sur les documents concernés. Il offre la possibilité de créer des configurations plus ou moins complexes, avec de nombreux niveaux, représentant la décomposition réelle du produit. Cette décomposition est souvent complétée par des liens d attributs, de valeurs, de types. Ces informations supplémentaires contribuent à accroître la lisibilité de l arborescence de la configuration, en faisant apparaitre directement ces informations, sans nécessairement naviguer vers le document en question. L utilisateur dispose ainsi d une complémentarité de l information qui est à la fois portée par les documents mais aussi par les liens qui les relient par exemple une date de validité, une quantité... La fonctionnalité native d analyse d impact met en valeur très rapidement, à partir d un onglet spécifique, l utilisation d un même document par d autres dossiers/produits/projets dans l ensemble de la base avant toute modification ou suppression. Ainsi pour faciliter la modélisation de la structure plus ou moins complexe des produits/projets et gérer non seulement l évolution des documents de référence pour le produit/projet mais aussi l évolution dans son ensemble du produit/projet tout au long du cycle de vie, une seconde brique de gestion de configuration connectée au moteur de la solution est intégrée et utilise les données contenues dans la première brique de gestion documentaire comme l illustre la Figure 2. Figure 2. La brique fonctionnelle «Gestion Documentaire» Les processus : le dynamisme de l entreprise Dans l ère de la dématérialisation, pour des raisons de coût, de respect de l environnement, de validité des informations pour l ensemble de l entreprise étendu, les entreprises veulent non seulement accélérer la mise à disposition des informations «vraies», Page 50

51 Chapitre 2 Déploiement d une solution PLM de suivre l évolution de leurs produit/projet, mais ils souhaitent surtout minimiser le «time to market». Depuis longtemps, des procédures existent pour valider les différentes étapes cruciales identifiées grâce à leurs expériences mais aussi obligatoires par la réglementation en vigueur. La mise à jour de toutes ces procédures est généralement fastidieuse si l on souhaite conserver une cohérence entre les produits/projets, et favoriser la standardisation et la mise en place des bonnes pratiques uniformément sur l ensemble de la production. Comme à l époque de l automatisation des chaines de production, les entreprises, de par le déploiement d un outil de gestion, informatisent ces procédures et en profitent pour automatiser certaines étapes ne nécessitant pas une analyse humaine. Ce qui leur permet de conserver leur rigueur, leurs connaissances des échanges, des démarches administratives ou métiers, nécessaire pour assurer l efficacité de leurs activités et d accélérer et fiabiliser la circulation des informations. La raison majeure reste que ces procédures formelles ou informelles constituent souvent le cœur de l entreprise et illustrent leurs savoirs-faires propres. Autrement dit, l intérêt de la mise en place d une simple GED agrémentée d une gestion de configuration, perd de son sens en termes de performance, d image et de mémoire de l entreprise sans l intégration de ces procédures. Ces dernières peuvent être spécifiques à un cœur de métier ou à une entreprise, ou tout à fait générale comme une validation ou une diffusion. Malgré la formalisation informatique, il est important que cette automatisation ne soit pas trop rigide, à l image des procédures papiers, qui nécessitent souvent un degré important de flexibilité, pour adapter, faire évoluer, voire même pour by-passer ponctuellement des étapes non cruciales mais bloquantes afin de respecter les impératifs majeurs. Cette automatisation doit être source de dynamisation des échanges en favorisant la circulation des informations tout en conservant et en assurant la cohérence et la fiabilité de ces dernières. La typologie de processus la plus communément reconnue distingue trois catégories [AFNOR X50-176, 00], [Tudor, 06] : les processus de réalisation (ou processus opérationnel, processus métiers) Ce sont les processus qui couvrent le cycle de vie des produits ou des services de l entreprise à destination des clients, de la définition à la livraison, voir la maintenance. les processus supports (ou processus de soutien, processus d appuis) Ce sont les processus qui couvrent l approvisionnement en ressources nécessaires à la réalisation des processus métiers. les processus de management (ou processus de pilotage, processus de direction) Page 51

52 Chapitre 2 Déploiement d une solution PLM Ce sont les processus qui permettent de conduire l organisation dans le respect des objectifs stratégiques définis. La norme ISO 9001 [ISO 9001, V.2000] ajoute une quatrième catégorie de processus : les processus de mesure Ce sont les processus qui permettent la maîtrise des autres processus et la réalisation de l amélioration continue en fournissant des indicateurs répondants à des objectifs précis. Cette cartographie n est pas exhaustive mais permet une première qualification de tous les processus d une entreprise. Tout dépend du contexte, de l activité de l entreprise : le processus de gestion des ressources humaines sera un processus support pour une entreprise d assemblage automobile et un processus métier pour une agence d intérim. La performance globale des entreprises est basée sur la pertinence et l efficacité de ces quatre types de processus, pas uniquement sur les processus purement métier. Devant la complexité croissante des produits et des organisations et l informatisation massive, les entreprises sont amenées à formaliser leurs processus clés. Un grand nombre de ces processus concernent la gestion du changement dans les différentes phases du cycle de vie du produit et doivent naturellement être incorporés dans les systèmes de gestion de l entreprise, soit dans l ERP soit dans le PLM. Ces derniers permettent ainsi de prédéfinir le cheminement, les tâches, les personnes en charge de réaliser ces dernières, mais également les actions automatiques à faire tout au long du processus. La plus part des outils sont dotés d une application de création de processus connectable au moteur de la solution. L implémentation de processus au cœur du système confère aux outils une capacité à organiser les flux d informations et d en faciliter la circulation. La simplicité de création de nouveaux processus élémentaires, la modularité et la flexibilité de l outil permettent de s approcher au plus juste de l organisation réelle de l entreprise. Tous ces flux sont enregistrés dans la base de données facilitant ainsi la traçabilité des actions, des commentaires et de tout élément intégré aux processus. Cette partie du logiciel contribue également à créer des assistants de saisie, de suivi de documents, d opérations, de projets afin de faciliter l acceptation et l utilisation de l application par l ensemble des utilisateurs. C est la brique de gestion de processus connectée au moteur de la solution qui dynamise les flux de données, uniformise l ensemble des méthodes et savoir- faire de l entreprise et permet de maitriser la circulation et les actions menées sur les données contenues dans la première Page 52

53 Chapitre 2 Déploiement d une solution PLM brique de gestion documentaire et/ou sur un produit/projet gérer par la brique de gestion de configuration comme l illustre la Figure 3. Figure 3. La brique fonctionnelle «Gestion des Processus» Le reporting : le support à l aide à la décision Face à la concurrence grandissante et à la mondialisation, les entreprises doivent perpétuellement optimiser le triptyque : qualité, coût, délais. Quelque soit leur secteur d activité, elles ont du mettre en œuvre de nombreuses modifications : organisationnelles, en étendant l entreprise, méthodologiques, en utilisant les avancées technologiques et stratégiques, en se recentrant sur leur cœur d activité mais aussi en prônant l innovation nécessaire pour subsister sur le marché. La seconde conséquence pour les entreprises fut de gérer rapidement un nombre exponentiel de produit/projet pour répondre aux besoins de nouveauté imposée par les clients. Or la performance de l entreprise dépend du résultat, au regard des ratios issus du triptyque qualité/coût/délais, de chacun des projets qui eux mêmes sont conditionnés par les différents choix pris tout au long de son cycle de vie que ce soit au niveau méthodologique, processus, organisation, technologie Pour conserver leur place sur le marché, la minimisation des risques liés à ces différents choix, que ce soit lors du lancement d un nouveau projet mais également durant son déroulement, est primordiale. C est pourquoi, les décideurs ont besoin de disposer d informations fiables et pertinentes tout au long du cycle pour prévoir, anticiper et agir sur la performance du projet, donc de leur entreprise. Ce qui explique que la capacité à disposer de l information juste - et juste à temps - est devenue un facteur-clé de succès d un point de vue stratégique. Ces informations doivent permettre de suivre l ensemble des flux critiques, transactionnels et informationnels, pour agir Page 53

54 Chapitre 2 Déploiement d une solution PLM sur l activité et sur son management. Autrement dit, les informations en question doivent provenir des différentes sources d informations présentes dans le SI afin de les mettre en corrélation pour obtenir une vision transverse et complète du produit/projet dans le but de déterminer les actions correctives au plus juste et adapter les actions futures du processus. Pour obtenir l ensemble de ces informations, un traitement fastidieux était nécessaire entrainant soit un suivi partiel, basé que sur un type unique d information, soit un suivi a posteriori des actions, empêchant l anticipation dans l action. Eu égard aux investissements réalisés dans les systèmes d information depuis plusieurs années, les décideurs estiment pouvoir disposer maintenant de l ensemble de ces informations, nécessaires pour piloter leurs activités, à moindre effort, ce qui suppose d avoir une cohérence et une accessibilité complète sur ces dernières. Pour un produit/projet donné, le choix de l organisation et de la méthodologie suivie pour aboutir aux objectifs déterminés est réalisé a priori en fonction du savoir faire et des retours d expériences de l entreprise mais aussi en fonction des moyens à disposition. Le pilotage d une activité présuppose la mise en place d actions correctives et la re-définition des actions prochaines, adaptées au contexte, en fonction des actions prédéfinies et des mesures de contrôle effectuées. Le but de cette boucle rétroactive est de parvenir aux résultats escomptés en optimisant le triptyque qualité/coût/délais de façon performante. Cette dernière caractéristique repose d après Gibert [Gibert, 80] sur l optimisation de : - l efficience - le rapport entre la qualité du résultat et les moyens déployés -, - l efficacité - le rapport entre objectifs déterminés et le résultat obtenu -, - la pertinence - le rapport entre les moyens déployés et les objectifs -. Or pour un produit/projet donné, la performance globale de ce dernier dépend du déroulement de l ensemble des sous activités nécessaire pour parvenir au résultat, elles mêmes conditionnées par les décisions prisent par les acteurs en fonction de l environnement. La performance est donc multi-acteur et multi-période, car elle doit être prise en compte sur l ensemble du cycle de vie du produit/projet [Tomala, 02]. La performance est une motivation essentielle pour les entreprises pour pérenniser et survivre face à la concurrence. Il est donc crucial de pouvoir l évaluer à tout moment. Or l entreprise regroupant différentes activités, il est nécessaire de toutes les évaluer afin d obtenir des performances locales (leur «agrégation» ne fournissant pas au décideur une représentation de la performance globale). Il est alors stratégique de pouvoir évaluer et suivre cette caractéristique à tous les niveaux de l activité jusqu au niveau global. Des systèmes d évaluation de la performance comme celui de [Duffy et O Donnell, 97], [Bonnefous, 01], [Robin, 05], [Sauser, 06] proposent un certain Page 54

55 Chapitre 2 Déploiement d une solution PLM nombre d étapes pour développer un système d évaluation de la performance et des tableaux de bords. Ces différentes étapes sont : - Définition des objectifs pour les différents niveaux (stratégique, tactique, opérationnel) - Définition des leviers d action ou inducteurs de performance, - Définition des indicateurs ainsi que des performances exigibles, - Synthèse des données sous la forme généralement d un tableau de bord, - Évaluation de la pertinence du système lui-même. L indicateur de performance permet d exprimer la performance en fonction de l atteinte d un objectif fixé, par sa comparaison à une mesure concrète résultant d un calcul ou d un constat. Il doit être mesurable, observable ou contrôlable tout en étant simple, clairement défini et facile à comprendre. Sa construction est basée sur les différents facteurs identifiés comme ayant un impact direct sur la performance, les inducteurs. Pour rendre lisible et se positionner comme un support à l action, les indicateurs de performance sont regroupés et organisés sous forme de listes et de représentations graphiques adaptées à un utilisateur selon son champ d action. Ce type de rapport est nommé tableau de bord, définit selon l AFNOR comme étant un «outil de pilotage et d aide à la décision regroupant une sélection d indicateurs» [AFNOR X50-176, 00]. Son but est de mettre en évidence les actions qui s imposent pour atteindre les objectifs et améliorer les processus. Les rapports et les tableaux de bord, que nous qualifierons de reporting pour la suite, sont devenus des éléments clés pour les entreprises. Chaque nouvel outil implémenté dans le SI doit fournir un niveau important d accessibilité aux données soit pour une utilisation direct au sein de ce dernier, soit par un outil tiers qui agrègera, selon certaines règles, les différentes données issues de l ensemble des logiciels mis en œuvre au cours de l activité. C est une nouvelle façon de naviguer dans les données de l entreprise et ouvre la possibilité de passer d un management de contrôle hiérarchique à un management anticipatif autonome. Étant donné que la réalisation d une activité émane d une succession de choix issus du savoir faire et des retours d expérience du décisionnaire au regard de l environnement du produit/projet en question, s il dispose du reporting adapté, il pourra analyser seul ou avec son équipe les impacts de ses choix sur le déroulement de son activité, et optimiser ses actions au fur et à mesure de l avancé de cette dernière pour respecter les objectifs. Ceci se décline à tous les niveaux hiérarchiques de l entreprise : le patron pour réviser sa stratégie globale en fonction du déroulement des projets, le chef de projet pour connaitre les leviers d actions possible pour améliorer le déroulement de son projet, le chef d atelier pour identifier les points bloquants de Page 55

56 Chapitre 2 Déploiement d une solution PLM son installation, l opérateur pour connaitre l impact de ses actions sur le projet et se positionner au regard des objectifs qui lui ont été fixés. L intégration d un référentiel unique pour les données et les processus, simplifie et accroit les capacités de créer, mesurer et croiser des informations pour obtenir des indicateurs adaptés tout au long du cycle de vie géré par le système. Le reporting est une brique fonctionnelle importante dans les solutions proposées par LASCOM. Intégrant nativement un moteur de reporting connecté avec la base de données, différents niveaux de suivi d indicateurs de performance sont possible tant au niveau global qu au niveau local. En effet, il est possible de créer soit des rapports complexes agrégeant les données du PLM et/ou d applications tiers afin d obtenir une vision transverse des activités, soit des tableaux de bord axés sur une activité en particulier basées sur des rapports plus simples, plus accessible et plus flexible en fonction de l utilisateur et du produit/projet. L objectif des industries est de produire «mieux», autrement dit de produire d avantage, à moindre coût et dans un délai restreint. Pour évaluer leur performance et optimiser le pilotage de leurs activités, les entreprises cherchent des outils de suivis et d aide à la décision. C est en général un «moteur de reporting» qui aide au suivi, à l adaptation et à l optimisation du pilotage des activités tout au long du cycle de vie du produit/projet. Il représente un vecteur prépondérant de la performance global de l entreprise, à partir des données contenues dans les trois autres briques fonctionnelles et/ou dans des outils tiers (Figure 4). Figure 4. La brique fonctionnelle «Reporting» Ces briques sont d autant plus importantes que se sont-elles qui vont être implémentées lors de la mise en place d une solution logicielle et c est donc de leur définition et des périmètres Page 56

57 Chapitre 2 Déploiement d une solution PLM qu elles recouvrent que vont dépendre le ou les processus de mise en place de l outil. La mise en œuvre d'une infrastructure autour du PLM est un projet global du SI qui s'inscrit dans une logique de long terme. Aussi, tout projet de déploiement d'un système PLM nécessite de maîtriser les points suivants [Bissay, 10] : - les processus métiers et les refontes éventuelles, - les processus fonctionnels, - les migrations de données, - l'intégration globale avec les autres composantes du SI (comme l'erp), - la conduite de changement, - les supports et la formation. Dans les projets autour des PLM, deux grandes orientations existent. Il y a les projets qui nécessitent de nombreux développements de par l'histoire de l'entreprise, sa complexité, ou les contraintes de son business. Ces projets demandent un fort accompagnement. L'autre tendance, la plus forte actuellement, vise à déployer rapidement son projet, tout en limitant le coût. Pour cela, on cherche en permanence l'adéquation entre les besoins, les gains espérés et les fonctionnalités standards des progiciels. Les restrictions de budgets poussent même à segmenter les projets en petits lots peu onéreux, au risque de dégrader l'objectif global [Debaecker, 04]. Il apparaît donc finalement au moins deux visions (parfois divergentes) du processus de mise en place d une solution logicielle dans une entreprise : la vision du «client» - l entreprise - et la vision du «fournisseur» - l éditeur logiciel. Nous présenterons ces deux visions dans la section suivante. 3 Mise en place d un PLM : un processus aux multiples facettes 3.1 La mise en place théorique vue du coté «client» Même s'il est difficile d'établir un ensemble d'étapes exhaustif représentatif de la vision «client» du processus de mise en place d un outil PLM dans une entreprise [Bordegoni et al., 04], nous retiendrons les travaux de Bissay [Bissay, 10]. Les recherches qu elle a menées au sein de PME/PMI lui ont permis de modéliser la perception «client» suivant trois grandes phases et sept sous-phases (une description plus complète des travaux de Bissay est fournie en Annexe 2) : - la phase d'avant-projet qui débute de l'idée de mettre en place un tel projet jusqu'au choix de la solution et qui se compose de 3 sous-phases : o La définition du projet, Page 57

58 Chapitre 2 Déploiement d une solution PLM o La rédaction du cahier des charges, o Choix d'une solution. - la phase de mise en œuvre qui va correspondre à l'adaptation du système choisi à l'organisation de l'entreprise, o La définition du plan projet. o La mise en œuvre. - La phase d'accompagnement et d'adaptation du système qui est une phase transversale généralement incluse dans les deux précédentes et qui permet de garantir l'adéquation et l'adaptation du système aux évolutions du contexte industriel de l'entreprise. o La gestion du changement. o La reprise de l'existant. L'approche globale pour le déploiement de système d'information de type PLM au sein des PME/PMI proposée par Bissay est caractérisée par différents processus qui vont guider la mise en œuvre en amont et en aval du projet. Cette proposition est représentative du fait que les entreprises ont souvent une approche «processus» plutôt qu'une approche «projet» de la mise en place d une solution logicielle PLM ce qui a pour conséquence de compliquer la tâche de l éditeur. La section suivante, par la description de la vision «éditeur» de la mise en place d une solution, va mettre en exergue les problématiques liées aux perceptions divergentes du client et de l éditeur. 3.2 La mise en place théorique vue du coté «éditeur», exemple de LASCOM Dès 1981, des propositions de phasage d un projet de mise en place d une solution logicielle dans les entreprises ont été diffusées (Figure 5) [Boehm, 81], [Morlay, 01]. Page 58

59 Chapitre 2 Déploiement d une solution PLM Figure 5. Les tâches d'un projet logiciel par activités et par phases Cette proposition de phasage est très proche de celle que nous avons pu mettre en évidence chez LASCOM, l éditeur au sein duquel se déroulait le travail de recherche. En effet, les retours d expérience de l entreprise permettent de mettre en évidence que le processus de déploiement d une solution logicielle est généralement décomposable en treize étapes incontournables illustrées sur la Figure 6. Page 59

60 Chapitre 2 Déploiement d une solution PLM Figure 6. Les différentes phases d un projet d informatisation chez LASCOM Les tenants et les aboutissants de chacune de ces étapes peuvent être définis comme suit : - Prospection : correspond à toutes les actions débouchant sur une mise en relation d un client potentiel et d un éditeur. - Expression du besoin : correspond à l étape initialisant le processus, en effet ce type de projet est généralement issu d un constat d un ou plusieurs disfonctionnement ou vecteurs d amélioration identifiés au sein de l entreprise permettant de définir le besoin. - Étude de marché : à partir de la définition du besoin, l étude de marché permet de délimiter le contour fonctionnel de leur besoin au regard des solutions informatiques présentes sur le marché. Page 60

61 Chapitre 2 Déploiement d une solution PLM - Cahier des charges : en fonction de cette étude, le cahier des charges est réalisé. Ce dernier permet de définir formellement le besoin et de délimiter la portée du projet pour compléter l appel d offre émis aux éditeurs. - Réponses : tous les éditeurs intéressés par le projet répondent au cahier des charges à travers un chiffrage (la réponse financière), une description fonctionnelle de leur solution (la réponse technique) et propose une démonstration de leur solution. - Choix de la solution : suite aux réponses, des soutenances sont organisées entre l entreprise «cliente» et les éditeurs retenus. Ces entretiens doivent permettre aux éditeurs de défendre leur proposition, de l illustrer à travers une démonstration et de négocier les termes du contrat, essentiellement le prix. Selon les projets, cette étape peut être réitérée plusieurs fois afin de restreindre les candidatures tout en affinant le besoin. A l issue des entretiens, l entreprise fait un choix entre les différentes propositions techniques et financières revues. - Spécifications : une fois le choix réalisé, le projet commun avec l éditeur commence par une formation dite au concept afin d expliquer les termes techniques liés au logiciel et améliorer la qualité de la communication entre les deux intervenants. La spécification est une étape cruciale du processus, c est un moment d écoute et d échange pour parvenir à déterminer le cadre fonctionnel et technique le plus précis possible de la future application, mais également de déterminer les solutions techniques à mettre en œuvre pour parvenir à remplir, de la façon la plus satisfaisante, le cahier des charges. - Modélisation(s) : suite à cette analyse, une étape de modélisation et de prototypage commence pour permettre d illustrer le besoin, s assurer de la faisabilité et de la bonne compréhension mutuelle du fonctionnement. Elle comporte plusieurs sous étapes en commençant par une schématisation puis une pré-modélisation, constituant les bases de la modélisation pour aboutir au prototype. - Développements : en parallèle un sous projet chez l éditeur peut également être lancé afin de réaliser les éléments spécifiques demandé par le client afin de les intégrer dans un premier temps dans le prototype puis dans la solution finale du client. - Tests : pour valider ce modèle, différents tests, généralement par module ou fonctionnalité, sont réalisés par l éditeur comme par le client (le chef de projet mais également quelques utilisateurs), pour tester les développements spécifiques, les spécificités fonctionnelles ou tout simplement le modèle de données. Page 61

62 Chapitre 2 Déploiement d une solution PLM - Déploiement : une fois l application validée, le déploiement est généralement réalisé en deux phases. Dans un premier temps, le système est déployé sur une partie du site, nommé site pilote, pour confirmer les différents tests dans une utilisation quotidienne, initialiser la reprise des données et l intégration au sein du système d information. Si cette étape est réussie, l application est déployée sur l ensemble du site, sinon des modifications sont réalisées pour être testées à nouveau. Selon les projets cette étape est intégrée dans l étape de tests. - Support : pour faciliter l appropriation du logiciel, différentes étapes d accompagnement se succèdent durant les premiers temps : la formation des utilisateurs, la formation des administrateurs qui vont constituer également les premiers référents techniques dans l entreprise, mais également la mise à disposition d un support technique. - Exploitation : finalement, l entreprise lance l exploitation et impose l utilisation systématique du logiciel à l ensemble des acteurs du cadre fonctionnel prédéfini. L éditeur n interviendra que dans le cadre du suivi commercial et de la maintenance, voire d une enquête de satisfaction au près des interlocuteurs habituels. Cette décomposition met en évidence le découpage généralement constaté dans les projets réalisés par LASCOM, mais également la définition du terme «projet» pour chacun des acteurs dans ce processus lié au moment de leur implication dans le cycle global. Pour mettre en œuvre ce processus, LASCOM a jusque là adopté une approche qui consiste à définir un processus issu d une procédure «idéale» décrite par des experts et répondant à un besoin spécifique, puis à construire le modèle de données associé. Puis au cours de la réalisation du prototype ou lors du déploiement test, des corrections sont apportées au fur et à mesure des réserves du client. Chacune de ces étapes nécessite des temps d analyse, de formalisation et de communication, leur durée, mais également le nombre d itération, est donc relativement variable en fonction du client, de la complexité du projet, des différentes contraintes à prendre en compte. Tout l enjeu des étapes «amont» de ce processus est de définir un modèle le plus précis possible de ce que souhaite le client sur le contour prédéfini. Pour se faire, différentes réunions et échanges sont mis en place pour recueillir les informations auprès des personnes identifiées par le client comme étant potentiellement détentrices possédant les connaissances, puis ces éléments sont interprétés à travers des outils. Finalement la modélisation est effectuée Page 62

63 Chapitre 2 Déploiement d une solution PLM a posteriori du système à considérer : l entreprise, le service, un produit, un projet Cette démarche met en œuvre différentes méthodologies en fonction des intervenants, du type de projet, du niveau de formalisation existant dans l entreprise. En effet, en fonction de l existant et/ou des intervenants, il est souvent plus simple et surtout plus rapide soit de partir des modèles existants et d approfondir la partie à traiter, l approche descendante, soit de partir de la réalité du terrain et de définir le système permettant la réalisation du produit/projet, l approche ascendante. Ces deux approches représentent l essence de toutes les méthodologies utilisées pour modéliser les données, les activités et finalement l organisation. La section suivante présente les approches ainsi que les méthodes et outils classiquement employés pour établir un modèle précis de ce que souhaite le client [Baczkowski et al., 12]. 4 Des besoins à la solution logicielle : de la réalité aux modèles Comme nous l avons dit précédemment, il est souvent plus simple et surtout plus rapide, en fonction de l existant et/ou des intervenants, soit de partir des modèles existants et d approfondir la partie à traiter (approche descendante), soit de partir de la réalité du terrain et de définir le système permettant la réalisation du produit/projet (approche ascendante). Ces deux approches vont à la fois concerner l entreprise dans son ensemble (visions organisationnelle et fonctionnelle) mais aussi ses processus et activités (vision opérationnelle). Les approches et méthodes de modélisation d entreprise et de processus/activités vont donc être nécessaires à la construction des modèles qui seront par la suite implémentés dans la solution logicielle [Baczkowski et al., 08a]. 4.1 Les approches de modélisation d entreprises Les modèles d'entreprises permettent de décrire les pratiques d'entreprises selon plusieurs points de vues : fonctionnel, physique, processus, décisionnel et informationnel. Les modèles d'entreprises sont des représentations de l'état existant d'un système et, à ce titre, sont un pré-requis indispensable à toute étude de mise en place d un SI dans une entreprise [Blanc, 06] [Chevallereau, 11] L approche «descendante» : l intégration itérative L approche descendante repose sur le principe de l approfondissement des systèmes. Il s agit, dans un premier temps, de définir le niveau le plus haut, représentant le système dans sa globalité et d en identifier ses finalités. A partir de cette définition fonctionnelle, l approche consiste à lister l ensemble des processus mis en œuvre pour parvenir à passer Page 63

64 Chapitre 2 Déploiement d une solution PLM d un état d entrée à l état fini désiré. Ainsi la fonction du système s affinera au cours des décompositions successives en sous-fonctions jusqu au niveau opérationnel. L aboutissement de cette étude itérative est l obtention, par intégration de l ensemble des données recueillies, d une définition du système cohérente du niveau global jusqu au niveau local. Ce type d étude s appuie sur des modèles préexistants et sur une forte connaissance de l entreprise, de son organisation, ses processus, ses activités. La démarche doit conduire un expert à analyser et formaliser progressivement le système pour faire émerger des modèles globaux. Ce niveau d expertise nécessite d impliquer rapidement dans les projets les équipes dirigeantes, ce qui peut constituer un attrait important due à la transversalité de la réflexion dans le cadre de l uniformisation du modèle L approche «ascendante» : la fédération Cette démarche est directement inspirée de la «Grounded Theory», [Taylor et al., 84], dont le but était de découvrir des concepts, hypothèses ou propositions directement à partir des données de terrain plutôt qu en partant de suppositions ou cadres théoriques existants. Autrement dit, cette démarche conceptuelle consiste à recenser d abord toutes les activités liées à la réalisation du produit/projet, puis à les regrouper selon le déroulement logique du flux, depuis l identification des exigences des clients jusqu à la satisfaction des exigences convenues. Cette première étape permet de répertorier les activités et de les séquencer, aboutissant à la formalisation de l ensemble des processus de réalisation du produit/projet. Pour aboutir à une définition globale du système, il est nécessaire d adjoindre à ce modèle les processus de management, de support et de mesure dans une seconde étape. L agrégation et la standardisation de toutes ces informations a pour finalité de modéliser les activités locales jusqu à considérer l ensemble en une seule activité globale. Ce type de démarche a pour avantage sa rapidité et le réalisme du modèle, basée sur des collectes d'informations sur le terrain auprès des personnes qui ont la connaissance sur l'activité et non à une équipe projet n ayant pas forcément l expérience nécessaire pour apporter le recul suffisant sur les situations exceptionnelles. Par contre, cette équipe et son caractère transverse aux activités est mis à bonne escient lors de l uniformisation des différentes procédures. Page 64

65 Chapitre 2 Déploiement d une solution PLM 4.2 Les méthodes et outils de modélisation d entreprise et de processus Méthodes et outils de modélisation d entreprise Il existe divers outils et méthodes de modélisation d entreprise mais nous ne les détaillerons pas de façon exhaustive ici car notre objectif est ici de mettre en évidence leur adéquation ou leur inadaptation aux problématiques rencontrées par les éditeurs logiciels. L une des premières méthodes, la méthode SADT (Structured Analysis and Design Technique), est apparue à la fin des années 70 sous l impulsion de Ross [Ross, 77] et devait permettre une analyse structurée des systèmes. Cette méthode a ouvert la voie à la modélisation par représentation graphique des activités et des chaînes d activités. La méthode SADT introduit le principe de décomposition fonctionnelle et formalise le concept d'activité. Elle se présente comme un langage graphique et un ensemble limité de primitives, des «boîtes» et des «flèches», pour la représentation des composants des systèmes et des interfaces. SADT a donné lieu à la famille des méthodes IDEF [ICAM, 1981] (IDEF0, utilisée pour décrire les aspects fonctionnels d un système, IDEF3, spécialement conçue pour la modélisation des séquences d'activités ou processus [Mayer et al, 1995], [Vernadat, 1999], etc.). D'autres méthodes plus élaborées mais toujours issues du génie logiciel proposent des supports d'analyse statique ou dynamique en se basant sur des approches fonctionnelles, relationnelles ou objets. Nous pouvons citer MERISE [Tardieu et al., 83] et ses modèles de traitement, la modélisation objet OMT [Rumbaugh, 91] (vues statiques, dynamiques et fonctionnelles d'un système), OOD [Booch, 00] (vues logiques et physiques du système), OOSE [Jacobson, 92] (couvre tout le cycle de développement), UML (Unified Modeling Langage) est la fusion et synthèse des méthodes précédentes mais ce n'est pas vraiment une méthode car il ne comporte pas de démarche, c'est un langage de modélisation objet [OMG, 03]. Enfin, il existe plusieurs travaux relatifs à la modélisation en entreprise dans son ensemble. Parmi les plus connues, nous pouvons citer pour des architectures de référence et méthodes telles que : - CEN ENV [Shorter, 00], qui est une pré-norme du Comité Européen de Normalisation (CEN) pour la modélisation d'entreprise. Son but est de préciser la terminologie et d'énoncer les principes fondamentaux sous-jacents au domaine de la modélisation en entreprise. L'architecture de référence retenue est basée sur le cadre de modélisation de CIMOSA, - CIMOSA (CIM Open System Architecture) [AMICE 93], qui est une architecture pour construire des systèmes intégrés de production. Elle a été développée par le Page 65

66 Chapitre 2 Déploiement d une solution PLM Consortium AMICE dans le cadre de projets ESPRIT. Cette architecture comprend un cadre de modélisation (MFW «Modeling FrameWork») ; une plateforme d'intégration (IIS «Integrating InfraStructure») et le cycle de vie d un système CIM «Computer-Integrated Manufacturing» (SLC «System Life Cycle»). CIMOSA offre des langages de modélisation intégrés pour les aspects fonctionnels, informationnels, ressources et organisationnels [Vernadat, 96]. - GERAM (Generalized Enterprise Reference Architecture and Methodology) [IFAC, 97], qui est une architecture de référence développée par un groupe de réflexion sur les architectures pour l'intégration des entreprises. GERAM est en fait une généralisation de CIMOSA, de GRAI-GIM, de PERA et de quelques autres architectures (ARIS, ENV et IEM), - La méthode GRAI (Graphe de Résultats et Activités Interreliés) qui a pour but la conception ou la reconception des systèmes de production et qui se focalise sur la partie décisionnelle (système de conduite) et s'applique dans une optique générale d'amélioration des performances. La méthode GRAI est construite à partir d'un modèle de référence et s'appuie sur des langages (grille, processus, réseaux,...) [Doumeingts, 84], [Roboam, 93], [Ducq, 05]. - PERA (Purdue Enterprise Reference Architecture) [Williams, 92], est une méthodologie complète d'ingénierie des environnements industriels. La méthodologie définit toutes les phases du cycle de vie d'une entité industrielle depuis sa conceptualisation jusqu'à sa mise en opération en passant par les phases de conception. L'originalité de PERA réside dans la prise en compte des aspects humains et notamment de leur positionnement dans l architecture ; - ARIS (Architecture for integrated Information Systems) [Scheer 99] dont la structure est similaire à celle de CIMOSA mais qui à la place de se focaliser sur les systèmes CIM traite les entreprises avec des méthodes traditionnelles orientées métier (planning de production, inventaires de contrôles, etc.). Elle se focalise surtout en ingénierie des logiciels et des aspects organisationnels de la conception des systèmes intégrés dans l entreprise Méthodes et outils de modélisation des processus/activités Il existe divers outils et méthodes de modélisation des processus métier [Abdmouleh 04] et comme pour les méthodes de modélisation d entreprise nous ne les détaillerons pas ici car notre objectif est d estimer la pertinence de l utilisation de ces outils pour les éditeurs Page 66

67 Chapitre 2 Déploiement d une solution PLM logiciels. Nous avons étudié et comparé les principaux outils et méthodes de modélisation des processus (IDFEØ, IDEF3, workflow de la «Workflow Management Coalition», réseaux de Petri, grafcet, UML, workflow de Windchill, réseaux GRAI, gestionnaire de processus d Enovia-LCA). Le Tableau 1 présente la synthèse de notre analyse. Tableau 1. Etude comparative des outils/méthodes de modélisation de processus Page 67

68 Chapitre 2 Déploiement d une solution PLM Analyse et synthèse Même si les modèles d'entreprise sont une représentation de l'état existant d'un système et, à ce titre, sont un pré-requis indispensable à toute étude des entreprises, il est à noter qu ils sont peu utilisés par les éditeurs logiciels. Ceci peut s expliquer par le fait que les clients exigent un temps d étude du besoin relativement court ce qui ne permet pas forcément de déployer de tels outils ou méthodes. Les méthodes de modélisation de processus sont finalement plus utilisées mais il n existe pas forcément de consensus quant à la «meilleure» méthode à employer. L utilisation de telle ou telle méthode dépend en fait de l expertise de la personne mandatée par l éditeur logiciel pour aller recueillir les informations chez le client qui aura plus d appétence avec une méthode plutôt qu une autre. L utilisation de ces méthodes demande une organisation rigoureuse des informations et un nombre important de schémas, souvent imposants selon la granularité, pour parvenir à modéliser de façon cohérente l ensemble du processus et ainsi obtenir une cartographie de l organisation de l entreprise. Cette cartographie n a de sens qu à un instant précis et pour une utilisation précise, dans notre cas pour aligner le logiciel sur l organisation de l entreprise. En effet, le modèle résultant ne permet pas une mise à jour aisée du fait des impacts engendrés sur tout ou partie des nombreux schémas. Autrement dit, cette modélisation constitue une vue statique du système au lieu d être un outil d analyse et d amélioration utilisable au quotidien pour le client mais aussi pour l intégrateur lors d évolution du logiciel. 5 Synthèse L un des objectifs de toute entreprise, comme de toute organisation, est de développer un produit/projet relativement à ses buts propres. Pour répondre stratégiquement à cet objectif, leur structure a souvent été établie pour cette seule fin en plaçant le produit au centre des préoccupations. Dans le monde industriel, pour un produit donné, un ensemble de livrables, documents, données internes et externes est produit pour répondre aux exigences réglementaires, qualité, commerciales exigences qui peuvent influencer la structuration, la nature et la définition des activités à mettre en œuvre et ainsi instaurer une organisation particulière. Pour accélérer la modélisation (et finalement l implémentation), base de l adéquation entre le logiciel et l entreprise, c est préférentiellement la première étude sur le terrain qui doit être efficace pour mettre en évidence fidèlement mais globalement cette logique d organisation. C est lors d une seconde étape d analyse plus fine que l organisation de l entreprise et ses processus/activités sera réellement détaillée. Ces deux grandes étapes primordiales donnent souvent lieu à des incompréhensions entre le client et l éditeur et des Page 68

69 Chapitre 2 Déploiement d une solution PLM incertitudes apparaissent. Incertitudes qui par la suite perturberont le déroulement du projet car elles seront autant de sources d itérations et de discussions chronophages entre les partenaires. Ce sont ces itérations que LASCOM souhaite réduire en améliorant les phases amonts de son processus d implémentation et en particulier celles qui correspondent au recueil d informations chez le client. Ainsi, et en partant du postulat que les entreprises clientes et que les intervenants nécessaires à la constitution du modèle ne sont pas tous des experts dans les techniques de modélisation utilisées, il apparait donc essentiel que le «langage» de modélisation utilisé soit simple et qu il mette en évidence de façon explicite l ensemble des informations pour favoriser l implication et la compréhension de chacune des entités interrogées quelque soit le niveau de maturité du projet. L objectif du chapitre suivant est donc de travailler à l affinement de la démarche d implémentation chez LASCOM et à l identification d au moins un formalisme plus «accessible» et «utilisable» dans le monde industriel. Page 69

70

71 Chapitre 3 Analyse et amélioration du déploiement des solutions Chapitre 3 Analyse et amélioration du déploiement des solutions : le cas LASCOM 1 Introduction Aujourd hui l information est au cœur des préoccupations des entreprises, que ce soit par peur d une fuite de connaissance, soit pour des problématiques de suivi et de croissance de la performance de la collaboration dans le cadre des entreprises étendues. Pour faciliter la capitalisation et le transfert de ces dernières, la dématérialisation et plus généralement l informatisation, représente le nerf de la guerre économique pour les industriels. Aux vues des impacts organisationnelles de la mise en place d un logiciel de gestion et plus particulièrement d une démarche PLM, le processus d informatisation devient un processus stratégique pour les entreprises et a un rôle majeur dans la croissance de la performance de ces dernières. L apport méthodologique et l optimisation de ce dernier peut constituer un différentiateur fort entre plusieurs éditeurs en sus des performances de l outil au regard des besoins identifiés par l entreprise elle-même. L objectif est de subsister sur le marché, ce qui induit de rentabiliser l investissement au plus tôt pour les entreprises et, pour l éditeur, de rendre son produit central pour l activité de son client. Ainsi l éditeur peut espérer accroître la satisfaction du client et assurer la longévité du produit chez celui-ci et surtout son utilisation engendrant de la maintenance, des évolutions techniques et nombre d utilisateurs croissant (et donc de licences). Le but commun pour l entreprise et pour l éditeur est de maximiser le retour sur investissement en implémentant une solution logicielle performante (très) rapidement. Pour atteindre ces exigences, le logiciel doit non seulement répondre aux besoins et aux critères financiers fixés au moment du déploiement, mais également à long terme, autrement dit l éditeur doit fournir une solution plus efficace que les dispositions actuelles, adaptée aux besoins présents et futurs de l ensemble des utilisateurs et surtout maximiser l utilisation de son produit par un panel élargie. Nous allons nous intéresser dans ce chapitre à la définition des évolutions tant techniques que méthodologiques que doivent subir les solutions PLM, notamment celle développée par LASCOM, pour répondre aux besoins toujours croissants des entreprises et des utilisateurs. Page 71

72 Chapitre 3 Analyse et amélioration du déploiement des solutions 2 La réponse de LASCOM aux problématiques industrielles La solution LASCOM PLM proposée par l éditeur LASCOM répond au besoin de gestion des données critiques les plus complexes et est un outil full web de gestion de cycle de vie produit/projet (PLM - Product Life Management) et de processus (BPM Business Process Management). Elle assure la gestion de données complexes et de processus critiques permettant à ses clients de gérer, d assurer l échange et le suivi de leurs données et dossiers à travers un référentiel technique unique. Cet ensemble permet de constituer véritablement la mémoire, voire l image de l entreprise, d améliorer la conception et de réduire le temps de mise sur le marché de produits. Cette application permet non seulement de constituer une Gestion Électronique Documentaire (GED), mais également la gestion des liens existant entre ces données (les configurations), sans oublier l automatisation des procédures (les processus ou workflows) et l apport d une vision transverse et dynamique support à la décision (les rapports et tableaux de bord ou reporting). L intégration de cette solution au sein du Système d Information d une entreprise est complexe et nécessite de prendre en considération les spécificités du client. Or l expérience montre que LASCOM, quelque soit le projet d informatisation (une nouvelle intégration ou une évolution) mais également quelque soit l entreprise cliente, emploie toujours le même processus de déploiement (Chapitre 2, section 3.2, Figure 6). Ce mode de fonctionnement est propre à LASCOM et donc souvent non partagé par le client ce qui entraine différents problèmes : - Un problème de communication entrainant une mécompréhension, due en partie à une formation aux concepts souvent inadaptée aux interlocuteurs (aux clients) et peu orientée sur les concepts et l intérêt du PLM, en effet : o Soit le client ne connait absolument pas l informatique et plus particulièrement le fonctionnement d une base de données, ce qui entraine des difficultés énormes de communication et la formation proposée par LASCOM n est pas suffisante pour combler les lacunes. o Soit le client est ou se croit être expert dans ces domaines et a déjà son idée préconçue sur la solution à mettre en place et son paramétrage. Dans ce cas le client n a bien souvent qu une vision «technique» et non conceptuelle de problème ce qui limite sa perception et sa réflexion quant à l intérêt du déploiement d une solution PLM. Page 72

73 Chapitre 3 Analyse et amélioration du déploiement des solutions - Des itérations, essentiellement lors des spécifications du système (pendant l étape de spécification ou lors des tests), difficilement chiffrables en terme de temps et incontrôlables par l éditeur car elles sont en majorité : o Fonction de la qualité de la communication entre les parties prenantes et de fait de la compréhension qu ont les interlocuteurs du problème tant au niveau des besoins métiers que des solutions techniques employées. o Fonction de la place du chef de projet coté client, sa vision du projet étant généralement parcellaire. o Fonction de la maturité et de la définition du besoin global du client mais également des besoins plus «locaux» des utilisateurs finaux. - Une définition des besoins locaux incomplète entrainant des mécontentements des utilisateurs et un ROI plus faible et/ou plus long qu espéré dû essentiellement : o À l utilisation d une seule approche de définition des besoins et qui ne reflète souvent qu un point de vue idéalisé du fonctionnement global du système «entreprise», o À l utilisation de méthodologies non-outillées pour l analyse des besoins et dont le choix est laissé au chef de projet (client et éditeur) qui en fonction de son expérience préfèrera telle ou telle méthode de modélisation. Ceci démontre la nécessité pour LASCOM de mener totalement la réflexion avec le client pour avoir une démarche commune forte. o À une perte de temps sur des itérations au niveau global qui ne laisse ensuite que trop peu de temps pour de mener correctement des réflexions au niveau local. Finalement, l ensemble de ces problèmes fait que souvent la solution mise en place par LASCOM ne permet pas d atteindre le niveau d utilisabilité de l outil espéré ni même d apporter tous les éléments permettant le pilotage des processus et activités et donc d élargir le cercle des utilisateurs par manque de temps de modélisation. Trois axes de réflexions susceptibles d améliorer la démarche de LASCOM émergent des problèmes que nous avons mis en évidence dans cet état des lieux : les outils, la méthodologie et la communication. Nous allons dans un premier temps nous intéresser aux outils et à ce que les éditeurs logiciels appellent la «verticalisation» des solutions. Page 73

74 Chapitre 3 Analyse et amélioration du déploiement des solutions 2.1 D une solution «globale» vers des plateformes adaptées et préparamétrées : la «verticalisation» Les briques fonctionnelles classiques vues dans le chapitre précédent permettent de constituer le socle technico-fonctionnel de l offre de LASCOM et font en sorte que le PLM puisse : - aider au pilotage en guidant l'information critique au travers de processus métier et en donnant une totale traçabilité et un système de «reporting» efficace, - représenter l organisation en place contribuer à sa coordination en gérant et en assurant l'échange et le suivi de toutes les données d'un client, pour lui apporter une vision dynamique et un véritable tableau de bord de l'ensemble de son information technique, - participer à l uniformisation des procédures en optimisant et en standardisant au maximum les échanges de données de manière transversale à l entreprise avec les autres applications (ERP, CRM, MES, ) pour unifier et valoriser l ensemble du système d information plutôt que ses différentes briques. Une fois mis en place, le PLM devient un outil du quotidien pour les entreprises étendues, c'est-à-dire pour l entreprise et l ensemble de ses partenaires. Pour être efficace, et s inscrire dans l environnement quotidien des utilisateurs, il se doit d être accessible via internet pour répondre aux nouveaux principes organisationnels et de productivité qui imposent un accès distant, une disponibilité continue des données pour les équipes géographiquement dispersées, sans aucune contrainte technique, ni installation de logiciel préalable. Mais pour être performant, l outil doit être adapté à l entreprise, à son organisation, au produit et à son environnement. Classiquement, les éditeurs définissent leurs offres en fonction : d un métier, d un produit/service, d un profil Dans le cas de LASCOM, la stratégie fut pendant longtemps d adapter le socle fonctionnel composé par les quatre briques classiques à chaque client, ce qui donnait lieu à la mise en place de solutions spécifiques à chaque client. Cette démarche fut celle préconisée durant ces vingt dernières années. Elle confère à LASCOM une grande expérience et un grand savoir faire en terme développement et de mise en place de solutions dédiées à un client mais elle n est plus forcément adaptée aux exigences du monde d aujourd hui. En effet, cette démarche est chronophage alors que les clients exigent de plus en plus une mise en place rapidement et efficace. C est pour répondre à ces exigences que LASCOM a donné une nouvelle dimension à son produit en ajoutant à son socle fonctionnel Page 74

75 Chapitre 3 Analyse et amélioration du déploiement des solutions une «surcouche métier» d un point de vue fonctionnel, ergonomique, conception. La gamme LASCOM est donc aujourd hui constituée d une déclinaison de solutions «verticalisées», autrement dit de plateformes adaptées et pré-paramétrées, en fonction de trois grands domaines d activités : - l AEC (Architectural Engineering & Construction) : BTP, ingénierie, construction et collectivités territoriales, - l ICS (Industry & Complex Systems) : aérospatial, défense, industrie manufacturière, - le CPG (Consumer Packaged Goods) : agroalimentaire, distribution, cosmétique et pharmaceutique. Chacun de ces secteurs se caractérisent par des besoins différents liés au type de produit géré, à l organisation en place pour le réaliser, aux réglementations et exigences applicables, aux contraintes rencontrées, aux processus métiers LASCOM AEC (Architectural Engineering & Construction) Historiquement présent sur le marché de la CAO en tant que revendeur Autodesk, LASCOM a acquis des connaissances sur les métiers et les problématiques du bâtiment. Que ce soit pour la gestion d une nouvelle construction ou la maintenance d une infrastructure, les outils LASCOM aident les entreprises à surmonter les difficultés techniques liées à la disponibilité des dernières informations validées et induites par la multiplication du nombre d intervenants et l évolution continuelle des aspects réglementaires de plus en plus contraignant vis-à-vis de la traçabilité et de la sécurité. La gestion du cycle de vie des plans puis celle du patrimoine technique complet sont devenues vitales pour les entreprises du bâtiment mais également pour tous celles qui doivent gérer des infrastructures, que ce soit des sites industriels, administratifs ou historiques. Pour faire face aux enjeux concurrentielles et budgétaires les entreprises se doivent de : - respecter des délais et des plannings projet, - coordonner des équipes et des intervenants nombreux et dispersés, - maîtriser et réduire les risques, - augmenter la disponibilité des infrastructures. Tout ceci peut alors se traduire en termes de besoins relativement à cinq axes : - Unifier le savoir-faire et les données associées dans un référentiel commun, - Disposer à tout moment d une information valide et à jour, Page 75

76 Chapitre 3 Analyse et amélioration du déploiement des solutions - Faciliter la collaboration avec l ensemble des acteurs afin d optimiser le respect des délais et des normes, - Conserver et capitaliser le savoir-faire de l entreprise, dont la réutilisation permet d accélérer le lancement des nouveaux projets, - Fournir des outils d aide à la décision pertinents et évolutifs afin de faciliter la gestion en temps réel de vos projets. En réponse à ces problématiques, LASCOM propose un référentiel web multi-projets, organisé et piloté par des processus métiers et par des outils de reporting avancés dédiés au secteur de la construction, l'ingénierie industrielle et des collectivités locales. Développé pour la conduite des projets de construction, d'exploitation et de maintenance depuis leur lancement jusqu'à la gestion du patrimoine bâti, LASCOM AEC est aussi bien dédié aux PME qu'aux grands comptes grâce à sa structure modulaire et paramétrable. Pour atteindre ces objectifs et proposer une réponse précise et performante aux problématiques du secteur et du client, l offre LASCOM AEC se décompose autour de six concepts essentiels : - Un référentiel unique et structuré pour toute les phases du projet, basé sur un modèle de données adapté au métier, structurant et stockant les données et les documents, doté de fonctionnalités. - Une déclinaison du référentiel par projet permettant de créer une structure décisionnelle associée à ce dernier. - Une optimisation de la production documentaire en reliant les outils de bureautique directement au référentiel évitant les ressaisies, le rangement manuel des données tout en conservant la traçabilité et en automatisant la génération de document à partir des données du référentiel et d un modèle. - Un portail d échange commun facilitant et accélérant les interactions pour l ensemble des intervenants du projet - Un catalogue de processus métier permettant d optimiser l échange des informations au sein de l entreprise et avec les acteurs externes en automatisant les procédures et les activités critiques (ex : validation de documents, gestion des modifications, gestion des faits techniques, ) - Des outils de reporting support à l aide à la décision grâce au suivi des activités documentaires et de l avancement global pour l ensemble des projets. LASCOM AEC apporte une «surcouche métier» par rapport aux quatre briques de base constituant LASCOM PLM, pour répondre aux besoins spécifiques de ses clients du secteur de la construction, l'ingénierie industrielle et des collectivités locales, essentiellement orientés Page 76

77 Chapitre 3 Analyse et amélioration du déploiement des solutions sur la gestion du patrimoine technique et de la gestion de projet. Cette «surcouche métier» contribue à développer plus particulièrement les capacités de la gestion documentaire, des processus et du reporting (Figure 7). Figure 7. La déclinaison LASCOM PLM pour le marché de l AEC LASCOM ICS (Industry & Complex Systems) Le secteur de «l Industrie et des systèmes Complexes» comporte deux grands pôles : le manufacturier et les systèmes complexes (les industries de pointe mais pas seulement). Nous retrouvons dans ce secteur les domaines de l'aéronautique, du spatial, du transport et de la défense par exemple dont la gestion des programmes et des systèmes demande une identification précise de l'ensemble des composantes et des processus qui leurs sont associés. Gérer ces systèmes complexes tout au long de leur vie suppose une vision unifiée, partagée et consolidée de l'ensemble de ses composants par l'ensemble des acteurs. La solution de LASCOM LASCOM ICS est axée sur la phase de conception qui la première génératrice des données relatives aux composants et répond aux défis de l Ingénierie de conception en permettant de : - Rationaliser les coûts de conception, - Accroître la productivité grâce à l'automatisation des procédures, - Maîtriser les échanges avec les co-traitants, - Renforcer la confiance des clients par une connaissance exhaustive des produits. Page 77

78 Chapitre 3 Analyse et amélioration du déploiement des solutions LASCOM ICS est une plateforme technologique développée pour concevoir, intégrer et maintenir des systèmes complexes, collaborer sur les projets et les programmes et gérer les modifications et maîtriser l'évolution des systèmes. Cette solution tend donc à favoriser la collaboration, gérer la diversité des données techniques et globaliser l'information des entreprises. Elle repose sur le développement des 4 briques fonctionnelles complémentaires et interopérables (Figure 8) : - La gestion des données techniques et des documents au sein d un référentiel commun afin de stocker l ensemble de la documentation relative au produit, - La gestion de configuration intégrée de manière native afin de réaliser les nomenclatures adaptées et intégrés des informations sur la composition (date de validité d un lien par exemple) - La gestion de processus avec la présence au catalogue d une bibliothèque de processus métiers sur étagère (gestion des faits techniques, des retrofits, des opérations de maintenance, des modifications, des anomalies...). En outre, l adaptation et la création de processus sur mesure reste possible. - Le reporting apporte une vision synthétique des données et des actions sur le référentiel pour réaliser des indicateurs, des tableaux de bord et des rapports au service de la performance. Figure 8. La déclinaison LASCOM PLM pour le marché de l ICS Page 78

79 Chapitre 3 Analyse et amélioration du déploiement des solutions LASCOM CPG (Consumer Packaged Goods) Dans le secteur des industries agroalimentaires, plus que dans toute autre industrie, l'innovation est le principal moteur de croissance et de profits. Être innovant dans ce secteur signifie aujourd'hui être capable d'améliorer ou d'ajouter de nouveaux produits sur le marché, de réduire les coûts en modifiant les ingrédients, les procédés de fabrication, les emballages ou les fournisseurs, etc. Dans ce secteur, pour la plupart des industriels, l'innovation produit consiste le plus souvent à opérer des changements sur un produit déjà commercialisé. Ces changements qui peuvent concerner l'emballage, la recette, le process de fabrication, les contrôles qualité sur le produit, les fournisseurs ou encore l'étiquetage. Ils sont conditionnés par les tendances du marché, les exigences nouvelles des consommateurs et les contraintes règlementaires toujours plus fortes et cela sa traduit par : - Une gestion croissante du nombre de références, - Une capacité de réaction à la montée en puissance des marques de distributeurs, - Une amélioration de la productivité, - Une maîtrise des processus critiques d'innovation et de mise sur le marché de nouveaux produits. La solution LASCOM CPG est centrée sur la phase de R&D d un produit dans un premier temps puis sur la production de ce dernier une fois sa conception validée. Ce logiciel de gestion d'informations permet de structurer, gérer et auditer l'ensemble des données et des documents associés au produit. L objectif de LASCOM CPG est d aider les industriels et distributeurs du secteur de l agroalimentaire et des autres biens de consommation à réduire le temps de mise en marché, à gagner en productivité et à capitaliser sur la connaissance acquise pour innover à moindre coûts en leur permettant de (Figure 9): - Centraliser l'information relative aux produits dans un référentiel unique, - Optimiser la formulation des produits donc la R&D, - Automatiser la production documentaire (fiches techniques et cahier des charges), - Disposer d'une traçabilité complète. Page 79

80 Chapitre 3 Analyse et amélioration du déploiement des solutions Figure 9. La déclinaison LASCOM PLM pour le marché du CPG Synthèse Les outils développés par LASCOM sont issus de la gestion des systèmes complexes et du monde de la CAO. En 20 ans, les modes de conception et d utilisation d un PLM ont changé, le cercle fonctionnel s est élargi à d autres activités et à d autres types d utilisateurs. Mais surtout les clients recherchent des outils qui s adaptent à leur besoin et à leur méthodologie de travail et ils ne sont plus prêts à s adapter à l outil. Ainsi, pour rester concurrentiel sur le marché du PLM, il est primordial d adopter une stratégie de baisse du coût de la solution et d accélération de sa mise en fonctionnement effective chez le client. L un des premiers freins à cette stratégie provenait de la méthodologie employée qui consistait à créer complètement une solution par client. Au regard des délais et de la méthodologie d approche, les solutions choisies étaient dédiées et développées relativement au seul besoin exprimé par un client. La standardisation des développements n était pas primordiale et la réutilisation était donc souvent fastidieuse voire impossible de part sa spécificité. La première étape de la «verticalisation» consista à développer des plateformes pré-paramétrées en fonction du secteur d activité avec un modèle de données, un certain Page 80

81 Chapitre 3 Analyse et amélioration du déploiement des solutions nombre de fonctionnalités et de processus basés sur la récupération des développements réalisés historiquement pour un client. L idée était de permettre un déploiement «éclair». Cette «spécialisation globale» permet aux clients de percevoir la solution PLM de LASCOM comme un ensemble prêt à installer, répondant à leur besoin et à leurs usages aux paramétrages près, et ce sans surcout, ni délai supplémentaire. Les mécontentements apparurent lorsque les clients souhaitèrent encore plus «personnaliser» l application et que cette démarche s avéra très complexe de part le caractère malgré tout figé et générique du cœur de la solution. LASCOM eut donc à répondre à des demandes de plus en plus fréquentes de modifications gratuites, voire d évolutions, qui mettaient les projets en périls. Les clients étaient convaincus de leur bon droit dès lors que leur demande apparaissait à leurs yeux comme du paramétrage. Or peu d éléments étaient vraiment paramétrables, car le travail de standardisation n avait pas vraiment été réalisé et il était souvent complexe et coûteux de réaliser ces modifications dans la base existante de l outil. Face à cet échec il était essentiel de prévoir un maximum d éléments paramétrables pour réduire les temps d adaptation de l outil mais aussi de prévoir plusieurs modèles ou types de besoin pour un même secteur afin de répondre plus précisément aux spécificités du client. Les «nouvelles» applications verticalisées se sont alors améliorées et enrichies avec pour objectif non pas d obtenir des solutions prêtes à l emploi mais des solutions prêtes à être paramétrées. Mes premiers travaux de recherche chez LASCOM concernaient le développement de telles solutions. Le principal verrou à lever pour que ces solutions voient le jour concernait la prise en compte de la multiplicité des profils utilisateur (et donc des paramétrages) et la simplification de l utilisation de l application pour le plus grand nombre d utilisateurs afin d élargir son cadre d utilisation. D un point de vue «technique» ceci implique la simplification du modèle de données, de l interface homme machine (IHM) et la création d un catalogue de fonctionnalités interopérables et adaptées à l ensemble des profils visées (Voir Annexe 3). D un point de vue plus «méthodologique», il va être essentielle de travailler à l implication des utilisateurs dans les phases très amont du projet, bien avant que la solution soit mise en place. La section suivante présente nos préconisations quant aux évolutions nécessaires de la démarche de déploiement de LASCOM pour favoriser une adaptation encore plus forte aux contraintes clients. Page 81

82 Chapitre 3 Analyse et amélioration du déploiement des solutions 2.2 Vers une évolution de la démarche de déploiement de la solution Choisir un progiciel de gestion intégré est un moment des plus importants pour le développement d une entreprise et pour sa survie face à la concurrence. Au regard du coût d un tel projet, l entreprise doit tenir compte de ses besoins actuels et futurs mais également de ses expériences antérieures. Quelque soit la méthodologie ou le logiciel mis en place et sa performance supposée, son intérêt ne sera avéré que s il est approprié aux besoins de l entreprise, à son organisation et à ses activités. Cette informatisation induit très souvent la reconstruction d une communauté autour de nouveaux modes de coopération et les échecs constatés lors de l implémentation d un tel logiciel proviennent régulièrement d un manque de préparation des équipes projets quant à la gestion de cette problématique communautaire. Autre facteur aggravant pour les équipes, leur manque de connaissances de ce type de projet et des outils à mettre en place. Ces facteurs d échec conduisent les équipes à négliger les impacts tant techniques qu organisationnels et humains de la mise en place de la solution. Les effets «organisationnels» des logiciels de gestion sont nombreux : - Ils modifient la structure de l organisation par la création de nouveaux services et la réorganisation des services informatiques, - Ils font évoluer la nature, la circulation et les modes de création de l information, - Ils affectent le processus de décision, les processus de contrôle et la culture de l organisation. Ces effets sont souvent perçus comme ne concernant que des petites parties de l entreprise alors que c est l entreprise dans son ensemble qui est impactée. Aujourd hui, pour des raisons financières et de délais, l approche globale au niveau de l entreprise est généralement galvaudée au profit d une analyse plus succincte (mais plus rapide) qui ne se concentre uniquement que sur les besoins pré-définis dans le cahier des charges. Il n existe ainsi pas de réelle phase de lancement de projet qui permettrait à l intégrateur de prendre la mesure de l entreprise dans son ensemble et de mieux comprendre et d appréhender ses besoins, sa culture organisationnelle et son mode de fonctionnement pour le produit/projet à considérer dans le logiciel. Ceci semble incohérent de par l impact du contexte de l entreprise sur le cycle de conception, mais cette phase n est aujourd hui jamais prise en compte dans le projet car il semble trop couteux d effectuer cette analyse complémentaire. Sous estimer cette phase induira inévitablement des questions complémentaires par la suite, provoquant indubitablement des dépassements lors des spécifications pour combler les lacunes, voire des omissions essentiels au bon fonctionnement. Dans ce cas de nombreuses itérations Page 82

83 Chapitre 3 Analyse et amélioration du déploiement des solutions client/éditeur apparaitront lors des tests pour arriver à faire que l outil s intègre dans l organisation de l entreprise. Ces itérations conduisent à des modifications souvent plus couteuses que si ces éléments avaient été pris en considération dès le départ du projet. Pour éviter ce travers, il faudra dépasser deux obstacles. D une part la pression commerciale ou du client qui lors de la négociation va chercher à diminuer considérablement, voire supprimer, cette phase de lancement de projet. Et d autre part, les habitudes de travail prisent chez l éditeur qui sont elles aussi des freins à la réalisation d une phase de lancement efficace et profitable pour le client et l éditeur. Une évolution de l état d esprit du client et de l éditeur passera selon nous par la mise en place d une nouvelle démarche de déploiement au sein de chez LASCOM. Nous nous proposons de décrire dans cette section les phases «amont» du déploiement, les phases qui font suite au déploiement seront présentées dans la section suivante Définir le cadre du projet : le périmètre, les acteurs, les interlocuteurs potentiels Le projet d implantation est souvent considéré de manière différente si l on se place du point de vue du client ou du point de vue de l éditeur. Le client considère cette démarche comme un pas vers l amélioration de son processus et donc de sa productivité à travers l énoncé de ses besoins. Pour l éditeur, le projet est généralement considéré comme un «simple» déploiement de sa solution, adaptée pour un client. Les enjeux ne sont donc pas du même ordre. Le chef de projet coté éditeur se cantonnera bien souvent aux besoins énoncés par le client alors que le projet doit s inscrire dans un contexte global et l application devra prendre place dans un ensemble pour faire un tout afin d aboutir aux résultats escomptés par le client. L organisation de cette réflexion est généralement dictée par les informations présentes dans le cahier des charges fourni à l éditeur en amont du projet de déploiement. Ce document recense les besoins et attentes mais le problème lié à sa rédaction vient du fait qu il est produit avant le choix du logiciel et donc avant de connaitre les possibilités du logiciel et les éléments nécessaires à sa «personnalisation». Ce document est donc souvent mal adapté car il n existe pas vraiment de cohérence entre les besoins et les possibilités de l outil. Cette incohérence est d autant plus dommageable qu elle peut perdurer relativement longtemps dans le projet. De plus, le cahier des charges est généralement réalisé par plusieurs personnes, avec des profils différents, sans forcément de concertation sur l ensemble des détails et souvent sans le chef de projet côté client qui sera effectivement en lien direct avec l éditeur. En effet, le cahier des charges peut être émis des mois voire des années avant la phase de spécification de l outil et il n est pas rare que les chefs de projet changent. Des contradictions Page 83

84 Chapitre 3 Analyse et amélioration du déploiement des solutions apparaissent donc souvent dans les cahiers des charges, d autant plus si le projet est d envergure et que le chef de projet coté client a du mal à comprendre le besoin et le fonctionnement réel de la solution. Dans quasiment tous les projets, le client va chercher à remédier à ces contradictions par des actions en «internes» : le chef de projet en réfère aux différents responsables, qui eux même si besoin est, verront avec les utilisateurs, puis il revient vers l éditeur pour lui faire part des résultats. Dans cette démarche, il n est quasiment jamais prévu que l éditeur puisse participer à ces séances d éclaircissement ou à des réunions avec les différents utilisateurs. Ceci est d autant plus dommageable que sa présence pourrait éviter des «pertes» de temps et que l identification au plus tôt des différents profils des futurs utilisateurs est essentielle pour mieux appréhender leurs besoins mais également leur façon de travailler. Prendre en considération les habitudes de travail des utilisateurs «clés» de l application permet de limiter la résistance naturelle aux changements car ils se retrouvent au cœur du système. Principe 1 : Pour que les deux parties trouvent un avantage à long terme au logiciel, il est essentiel d intégrer la nouvelle application dans son contexte mais également de faire participer les futurs utilisateurs le plus tôt possible dans le processus de déploiement pour créer un outil adapté à l entreprise mais surtout aux futurs utilisateurs actifs. Le point clé selon nous d une analyse du contexte réussie va résider dans la capacité du chef de projet «éditeur» à cerner l entreprise dans toute sa complexité : de sa structure globale aux utilisateurs finaux. Il doit pour se faire s appuyer sur des interlocuteurs solides au sein de l entreprise. La démarche de LASCOM ayant montré ses limites dans ce domaine, c est donc toute cette démarche, notamment dans les premières phases du processus de déploiement (Expression du besoin, Etude de marché, Cahier des Charges, Chapitre 2, section 3.2, Figure 6) qui doit être revue Des phases clés : avant-projet et après projet Une des problématiques à la source des retards pris durant le projet était le manque de connaissance sur le client, plus particulièrement sur le projet et son contexte. Une des possibilités pour accroître le degré de connaissance du projet et de la solution logicielle serait, pour l éditeur, d entrer dans l entreprise en amont du lancement du projet. Cette présence peut être faite soit par l éditeur, soit par un tiers (un intégrateur, un partenaire ou une filiale de consulting), l objectif étant d une part d aider l entreprise à mûrir leur projet et d autre part de Page 84

85 Chapitre 3 Analyse et amélioration du déploiement des solutions récolter un maximum d information sur le projet avant le lancement officiel du projet pour constituer l environnement de ce dernier. Quelque soit l intervenant en amont, l ensemble des connaissances sur le client et sur le projet doivent être formalisé et transmis aux différents acteurs, côté éditeur/intégrateur, du processus en aval. L adjonction de ces connaissances au cahier des charges permettront d acquérir une vision plus globale du projet et de son contexte et ainsi d accélérer les spécifications, ce qui permettra d approfondir sereinement les aspects liés aux utilisateurs. A l origine d un projet, deux cas peuvent se présenter, soit le projet concerne un client existant et il en a parlé à un de ses interlocuteurs privilégiés (commercial, chef de projet, support ), soit c est un prospect qui a été contacté par un mode de prospection ou un tiers qui a prévenue le commercial. Cette entrée en amont du lancement de projet est plus ou moins complexe à réaliser en fonction de ces deux modes et du lien existant entre l éditeur et le demandeur. Aujourd hui, dans des projets de grande envergure, une relation étroite est souvent instaurée, dû aux forts enjeux et à la durée du projet, entre le client et le chef de projet. Cette évolution permet de mieux appréhender la complexité du déploiement de la solution coté client et offre la possibilité d échanger d avantage sur le mode de fonctionnement de l entreprise cliente, des impacts que peut engendrer ce type de projet sur l organisation. Finalement, ces discussions permettent d améliorer la qualité des spécifications en ne se contentant pas uniquement de traiter les besoins initiaux du cahier des charges sans analyse complémentaire, mais en affinant en fonction des besoins réels. La solution mise en place correspond alors naturellement aux méthodes et habitudes de travail de l entreprise, facilitant la montée en charge et l acceptation du logiciel par les différents utilisateurs. La qualité de cette relation de confiance, établie entre les intervenants durant les phases antérieures à la mise en production, favorise et facilité les prises de contacts en cours d exploitation en cas de soucis ponctuel ou d émergence de nouveaux besoins. Des évolutions sont alors envisagées (technique, fonctionnel, ergonomique ) naturellement, pour parvenir à ajuster au plus près le logiciel aux besoins réels des utilisateurs finaux ainsi que l ouverture du système à de nouveaux profils, donc à de nouvelles fonctionnalités. Ce mode de fonctionnement est possible, car le projet est constitué de plusieurs phase, autrement dit le client commande régulièrement des améliorations, conclusion le chef de projet travaille quasiment continuellement sur le projet. Dans le cas présent, d un projet élaboré par phase, la problématique de captation des informations en amont existe mais ne met pas en péril le projet, car d une part le client est conscient de la complexité du projet et apporte assez naturellement des explications sur le cadre de ces besoins, et d autre part ces retards sont souvent négligeables sur la durée. Par Page 85

86 Chapitre 3 Analyse et amélioration du déploiement des solutions contre, ce mécanisme n est pas généralisable à tous les projets, car nombreux sont ceux où les délais d obtention de la solution finale sont réduits et ne tolèrent aucun retard. Il est donc nécessaire d obtenir ces informations en dehors du cadre du projet et idéalement avant même le lancement du projet pour établir des devis avisés. Hormis les grands projets, cette prise d information peut être réalisée malgré tout plus facilement avec les clients existants lors de nouveaux projets (demande d amélioration, élargissement du cadre fonctionnel par exemple). Soit parce qu ils ont opté pour l accompagnement fonctionnel (décrit dans le chapitre 3 section 2.3.2) durant la phase d exploitation et dans ce cas toutes les informations sont récoltées au fur et à mesure par l éditeur. Soit parce qu il est possible de proposer des audits réguliers d un panel d utilisateurs dans un souci d optimisation et d amélioration continue pouvant s inscrire dans une politique qualité du client. Les intérêts de ces actions sont non seulement d accroître la satisfaction client, d identifier les améliorations à apporter au produit, de capitaliser l expérience mais également d identifier dès leur émergence les futurs besoins sur la partie fonctionnelle existante, pour être force de proposition ou de conseil en établissant un lien fort de confiance, ouvert à la discussion. Dans ce cas, l ajout de cette étape dans le cycle de vie du projet permet d apporter une nouvelle brique au processus, créant une jonction entre l exploitation et le lancement d un nouveau projet, basée sur la capitalisation des retours d expérience propre au client dans le but de proposer des axes d amélioration de la solution ou du support et d affiner les besoins en évitant de réitérer les erreurs tant d implémentation que de déploiement. Dans ce cas, contrairement au schéma proposé précédemment, le projet n est plus linéaire mais cyclique s inscrivant dans une boucle d amélioration continue (Figure 10). Page 86

87 Chapitre 3 Analyse et amélioration du déploiement des solutions Figure 10. Cyclicité du processus d informatisation Ce schéma peut également être proposé dans le cadre d un nouveau client par le biais d un audit permettant d affiner leur besoin. Cette incursion dans l entreprise révèle différents avantages, d une part elle permet de mieux connaitre les clients ou prospects, ces derniers découvrent l éditeur ou les nouveaux produits qu ils proposent tout en leurs permettant de faire un état des lieux de leurs besoins. Il est important dans ce cas, d arriver en avant projet, lorsque la définition du besoin n est pas encore totalement établie, car selon les types de marché public ou privé, l obtention d une telle prestation est quasiment impossible. Dans ce domaine, un certain nombre de service de consulting existe, mais généralement ils sont soient expert dans le métier de l entreprise, soient expert informatique. Dans les deux cas, le cahier des charges émis via une prestation de consulting, cumule différents niveaux d interprétation Page 87

88 Chapitre 3 Analyse et amélioration du déploiement des solutions du besoin dans son contexte et intègre une sémantique souvent approximative tant du métier que de l informatique pouvant altérer la définition des besoins, faussant leur perception et leur compréhension. C est un besoin réel pour les entreprises en quêtes d une solution informatique tant pour affiner leur expression de besoin, que pour établir leur cahier des charges, que pour définir le type de logiciel. Malheureusement, cette option est difficilement réalisable directement tant que la prestation n est pas reconnue sur le marché, voire dissocier de l éditeur. L accent doit donc être mis sur les clients existants potentiellement source de projet pour eux, mais il constitue aussi les meilleurs ambassadeurs de la solution qu il utilise vers l extérieur. Cette nouvelle étape offre un suivi personnalisé non pas uniquement commercial mais également technico-fonctionnel. L intérêt est de pouvoir établir et conserver un lien fort avec le client, assurer un suivi de la satisfaction utilisateurs et favoriser la capitalisation des retours d expériences clients. Ce service permet de rassurer le client et établir un climat de confiance. Si les utilisateurs sont satisfaits et si l entreprise constate une valeur ajoutée à la prestation, le produit et les services associés, elle sera amenée à divulguer plus facilement les futurs projets en amont des différentes étapes d analyse et de recherche de solution. Dans ce cas, si le besoin correspond au contour fonctionnel de l éditeur, il sera souvent plus simple pour l entreprise de choisir une extension de la solution existante que d apporter un nouveau logiciel au sein du système d information. Cette relation, du type gagnant/gagnant basée sur la satisfaction client, sort du métier de l éditeur, car il ne vend plus uniquement un produit mais un package dans lequel le produit est tout aussi important que les services. Mais finalement, l éditeur n est pas perdant, car indirectement, si la relation devient une véritable collaboration, cela lui assure un taux de renouvellement important voire même l accroissement du nombre de licence vendu grâce aux extensions, mais également grâce à l ouverture vers d autres clients potentiels grâce à la publicité réalisée directement par les clients satisfaits. Ainsi, cette structure cyclique basée sur l accompagnement permet non seulement d assurer la présence de l éditeur chez le client en amont du processus classique (linéaire), mais également de favoriser et améliorer la collaboration grâce aux quatre préceptes suivant : - Se positionner en tant qu interlocuteur privilégié : être connu et reconnu tant par les décideurs que les utilisateurs pour intervenir en amont des projets - Limiter le nombre d interlocuteur durant le projet : la mise en place d une équipe efficace prend du temps tant sur des aspects humains, organisationnels ou techniques pour favoriser l efficacité et la qualité du service. Page 88

89 Chapitre 3 Analyse et amélioration du déploiement des solutions - Anticiper les besoins de l entreprise et des acteurs : pour parvenir à une définition du besoin plus précise, autrement dit un outil adapté à l ensemble des utilisateurs. - Se centrer sur le client : rendre le client participatif à l évolution du produit et être sur que les évolutions correspondent à des besoins réels des clients, du marché. Pour optimiser le processus de déploiement et éviter des itérations lors des étapes décisives de spécification et de modélisation, la solution proposée ici est d ajouter une étape d accompagnement pouvant prendre différentes formes en fonction des besoins et reliant la fin d un projet au début d un autre. Ce qui permet de passer d un processus de déploiement à un cycle de déploiement. Principe 2 : L acteur doit être au centre des préoccupations des éditeurs, non seulement dans la philosophie de construction de la structure de base du logiciel, mais également lors de la conception de la solution propre à une entreprise. Un travail devra être mené au niveau de la solution de LASCOM pour que celle-ci puisse fournir toutes les informations en temps utiles aux utilisateurs en fonction de leurs activités mais aussi puisse faire que les données, les fonctionnalités et plus généralement l ergonomie soient personnalisables pour s adapter aux besoins propres à chacun des utilisateurs. Le fait de vouloir faire participer très tôt un nombre d utilisateurs important va obliger LASCOM à revoir sa politique de communication et d accompagnement. D une part, lors des premières phases du processus pour créer puis entretenir une vraie dynamique autour du projet. D autre part, durant les phases de déploiement et de tests pour que les informations et les échanges se fassent rapidement et efficacement. Enfin, lors de la phase d utilisation de l outil pour accompagner au mieux les utilisateurs et montrer que LASCOM est un éditeur avec une offre «globale» et un suivi sur le long terme. 2.3 Communiquer, former et accompagner le client pour être efficace Des actions de communication/formation de plus en plus en amont L élargissement du contour fonctionnel et l anticipation des besoins lors des phases «amont» de la démarche vont obliger LASCOM à modifier ses actions de formation vers les clients. En effet, la formation ne se cantonnait jusque là qu à apporter aux futurs utilisateurs les bases nécessaires en vue d une exploitation quotidienne de l application. La formation Page 89

90 Chapitre 3 Analyse et amélioration du déploiement des solutions présentait les fonctionnalités les plus usitées mais ne mettait pas en avant les concepts de base de la solution et plus globalement d un PLM. Cette démarche contribuait à construire une certaine capacité à utiliser l application mais ne permet pas de limiter la réticence aux changements car elle se faisait trop tardivement, lorsque l outil était déjà en place. Nous proposons d avoir des actions de communication/formation bien avant la mise en place de l outil pour que l éditeur puisse faire passer les concepts du PLM, valoriser l utilisation de l application comme vecteur de performance et donc contribuer à limiter les résistances aux changements. Mais un autre objectif fondamental de la démarche est de permettre la détection des réticences et des difficultés éprouvées par les futurs utilisateurs très tôt pour tenter d y remédier. L'implication des utilisateurs durant le projet de déploiement de la solution est primordiale d une part pour vérifier les besoins, comprendre le mode de fonctionnement et pour atténuer la réticence aux changements. Le degré d'implication des utilisateurs dans l'implantation de nouvelles technologies d information, constitue un facteur clé de succès pour la conduite du changement. L adhésion au projet se révèlera difficile si l implantation du PLM n est pas ressentie comme une nécessité par les collaborateurs mais plutôt appréhendée comme une source de difficultés par rapport à l impact sur les métiers et la circulation de l information. Les analyses de la situation existante en avant-projet doivent être minutieuses car elles vont contribuer largement à déceler les points sur lesquels il faudra insister pendant la phase de communication/formation. Étant donné que les utilisateurs sont rarement impliqués dans les phases de conception de la solution PLM, la formation constitue souvent la première interaction entre l outil et les utilisateurs actifs et/ou passifs. Pour les premiers, l objectif est de comprendre l intérêt de l outil et se familiariser avec lui pour favoriser son utilisation quotidienne et faire en sorte qu ils soient force de propositions. Pour les seconds, le but est de connaitre l existence de l outil et ses capacités pour être en mesure de trouver et d utiliser les informations mises à leur disposition et valoriser son utilisation. Dans les deux cas, il est à prévoir qu il y aura après la phase de formation, une phase d apprentissage mais aussi une phase d assimilation : l utilisateur a une vue globale du fonctionnement du PLM mais encore faut-il qu il saisisse les détails des actions qu il sera capable de développer. Pour que les phases d apprentissage et d assimilation se déroulent correctement, il est important de ne pas laisser les utilisateurs seuls face à ce nouvel outil. En effet, selon le profil de l usager et son niveau de compétence en informatique au sens large, l arrivé de ce nouvel outil peut désarçonner un acteur, le bloquer dans son travail quotidien, voire être perçu comme une Page 90

91 Chapitre 3 Analyse et amélioration du déploiement des solutions intrusion dans son travail de tous les jours avec une sensation d être «surveillé» (avec le traçage des activités, l apposition de son nom automatiquement, la présence d indicateurs ). Principe 3 : Les actions de communication et de formation à destination des futurs usagers doivent être fréquentes, suivies et construites relativement à une situation clairement définie. De telles actions ne sauraient être «standardisées» et se doivent de montrer la volonté farouche de l éditeur d intégrer aux plus tôt les utilisateurs finaux et de les accompagner tout au long de la vie du projet et de la solution Un accompagnement sur le long terme : une hotline au service du client Aujourd hui dans le déroulement d un projet type, au moment du déploiement à grande échelle, le lien entre l éditeur et le client est constitué du commercial et de la hotline, normalement le chef de projet ne devrait pas être sollicité mais cela peut arriver. En effet, l entreprise opte généralement pour une formation initiale de tout ou partie des utilisateurs et des administrateurs, puis elle réalise ses formations en interne. Elle ne prévoit pas dans ses budgets la possibilité de réaliser une «formation complémentaire» suite au début de l utilisation de l outil par le plus grand nombre, générateur de questions et de doutes. Généralement, pour résoudre les difficultés des utilisateurs, un premier niveau de support est réalisé en interne le temps du démarrage des utilisateurs. Quand ces derniers ne possèdent pas la réponse, en fonction du type de question ils font appel soit à la hotline pour les problèmes techniques, soit au commercial pour évoquer des nouveaux besoins, soit, selon sa disponibilité, à l ancien chef de projet pour des explications fonctionnelles. Malheureusement, pour certains projets d ampleur, le déploiement peut prendre beaucoup de temps, et au moment où l entreprise à besoin d un support «spécifique», soit les intervenants du projet sont toujours là mais ne se souviennent plus forcément de l ensemble des spécificités du projet, soit ils ne sont peut être plus dans les effectifs de l entreprise, dans les deux cas, le temps nécessaire pour répondre aux questions du client est relativement long et couteux. La pérennité d une solution ne se base pas uniquement sur la qualité de l outil au regard des besoins au moment de la livraison, ni sur sa capacité d évoluer, mais bien sur son utilisation à long terme par les utilisateurs. L entreprise doit être consciente que la mise en place d une cellule support interne est primordiale pour que les personnes ne restent pas démunies non seulement face au nouveau logiciel, mais également face aux nouvelles méthodes de travail imposées, c est un élément essentiel concourant à une politique d accompagnement aux changements. Ce service ne peut pas être sous traité facilement, car la connaissance des Page 91

92 Chapitre 3 Analyse et amélioration du déploiement des solutions procédures interne, des habitudes de travail est capital pour apporter le bon niveau de réponse. Par contre au niveau logiciel, la qualité de service n est pas homogène de part la diversité des problématiques. On peut distinguer deux types, le niveau technique (les bugs) où la réponse est de se référer au support technique de l éditeur et le niveau fonctionnel où normalement la formation, la documentation et l expérience constituent les seuls sources de réponse. Aujourd hui, si la réponse n est pas trouvée au sein de la cellule, dans le meilleur des cas, la question sera posée au support technique, qui ne connaitra pas forcément pleinement leur application et qui tentera de trouver une solution pour leur problème précis, mais n aura pas le temps de former véritable la personne, d analyser le cadre du besoin ou au chef de projet s il est toujours joignable. Dans le pire des cas, la réponse se restreindra à l usage courant de l application, à leurs connaissances du logiciel et tout élément hors de ce cadre sera jugé comme impossible. Ce cas peut être problématique, car il se base sur des connaissances et des compétences humaines, et non pas sur les capacités du logiciel. L éditeur est normalement plus apte à répondre aux difficultés rencontrées, aux demandes particulières et d identifier les évolutions potentielles des incompréhensions. Autrement dit, pour améliorer la qualité du support interne, l éditeur pourrait avoir un rôle de conseil fonctionnel pour utiliser au mieux son logiciel envers la cellule support du client en plus du support technique. L avantage pour le client est d assurer un meilleur niveau de service, favorisant l utilisation et améliorant ainsi le taux de rentabilité du projet, mais également d obtenir des devis plus adapté à ses besoins. En effet, en étant plus près des réalités du terrain, des difficultés des utilisateurs, il aura une vision plus claire des demandes formalisées. L évaluation des demandes d évolution se basera donc non pas uniquement sur un simple cahier des charges, mais sur les expériences du terrain contenant des habitudes d utilisations et souvent des besoins sous-jacents mineures qui ne sont pas budgétés. Cette solution d association a également des avantages pour l éditeur, et ce quelque soit les capacités du client. D un point de vue produit, les retours peuvent faire émergence des évolutions ou des améliorations de sa solution et ainsi enrichir son catalogue. D un point de vue stratégique, il va également accroître sa connaissance du marché en acquérant des connaissances plus précise sur le métier et les besoins de son client et d un point de vue méthodologie projet, en validant l adéquation entre la solution réalisée et les besoins réels des utilisateurs et faire émerger des disfonctionnements ou des manques. Finalement, il est essentiel de prendre soin ne de pas laisser le client totalement en autonomie sur sa solution après son installation, pour que la solution conserve sa place clé au sein de Page 92

93 Chapitre 3 Analyse et amélioration du déploiement des solutions l entreprise en répondant continuellement aux besoins des utilisateurs. Si des difficultés apparaissent et que le client est en autonomie soit : - elles sont trop importantes et il abandonne la solution ce qui représente une perte importante pour les deux parties, - son niveau de compétence du client et de ses capacités techniques lui permettent de développer lui-même les éléments nécessaire à répondre à ses besoins au lieu de contacter l éditeur, ce qui représente d une part une perte pour l éditeur, tant sur la vente de service ou de module que sur l évolution de sa solution globale en fonction au marché. Les retours d expérience sont des éléments stratégiques pour l évolution d un logiciel afin de continuer à coller aux besoins du marché. En l absence de contact autre que commercial et support technique, bons nombres de ces informations, qui pourraient être cruciales, sont donc perdus dans les méandres des boites vocales, mails ou couloirs de bureaux, voire restent uniquement chez le client. La création de ce type de service apparait importante et nécessite de mettre des ressources dédiées à cette tâche uniquement. En effet, il semble difficile de demander aux mêmes personnes que celles du support technique, car une personne au profil trop technique aura du mal à prendre de la distance avec la technologie, que ce soit lors de la compréhension du problème énoncé, de la réponse, que lors de la définition des besoins pour l évolution du produit (ergonomique et fonctionnel). La mise à disposition d un support fonctionnel est donc tout aussi essentiel qu un support technique pour accompagner le client tout au long du cycle de vie de l application et pas uniquement jusqu au déploiement. L intégration du concept de hotline fonctionnelle amène une nouvelle dimension au projet en plaçant les retours d expérience utilisateurs au cœur de la stratégie de l éditeur pour continuer à proposer un logiciel en adéquation aux besoins de ses clients. La généralisation de cette proposition est un investissement important pour les éditeurs, sans garantir systématiquement, pour chaque projet, le recueil d information innovante. Mais un des différentiateurs important entre les deux niveaux de support est leur évolutivité dans le temps, en effet pour un projet donnée, les problèmes techniques existeront constamment, alors que les explications sur le fonctionnel vont diminuer dans le temps pour devenir des nouvelles demandes et prendre un caractère plutôt d avant vente pour des nouvelles commandes. Autrement dit, la demande n est pas constante dans le temps et présente des pics important lors du début de l exploitation, puis lors du déploiement du logiciel auprès des groupes d utilisateurs. Une des propositions pourrait être alors de proposer ce service sous deux formes, dite «en régie», c'est-à-dire sur site, dans un premier temps, pour accompagner la cellule de support et Page 93

94 Chapitre 3 Analyse et amélioration du déploiement des solutions apporter son expertise sur la politique aux changements, et à chaque fois que nécessaire, puis passer sur un système de hotline classique à distance. Principe 4 : Les actions d accompagnement après la mise en place de la solution doivent s effectuer chez le client pour participer à la mise en place d une cellule «interne» d experts puis, lorsque la cellule est opérationnelle, se faire à distance par le biais d une hotline «classique» et ce tout au long de la vie de la solution. L accompagnement doit aller au delà d une simple formation et doit perdurer tout au long du cycle de vie de la solution. Cette assistance doit pouvoir répondre à toutes les thématiques autour du produit en particulier techniques et fonctionnels. Elle rassure le client et lui évite de rester bloqué sur une problématique qui n en est peut être pas une. Dès lors le logiciel ne constitue plus juste une boite noire, sans vie, incompréhensible malgré la documentation ou les formations, d un point de vue client et surtout utilisateur, mais un outil du quotidien utilisable par chacun à son rythme et à sa façon. En améliorant la durée et la qualité du support fonctionnel, les utilisateurs ont la possibilité d assimiler au fur et à mesure de leurs besoins les différentes possibilités et fonctionnalités de l application et faciliter ainsi l acceptation et d adéquation des utilisateurs au logiciel, voire d amélioration continue du process et du logiciel. 3 Synthèse La pérennité d une solution PLM dans une entreprise est garantie quasiment essentiellement par le fait que les utilisateurs se l approprie. Pour ce faire, nous avons proposé de revoir les phases critiques du processus de déploiement pour faire que les utilisateurs soient parties prenantes très tôt du projet et de son développement et ce jusqu à la fin de l exploitation de la solution. Les utilisateurs doivent être perçus comme le maillon essentiel du développement et du déploiement d une solution dans une entreprise et comme une source d amélioration continue de celle-ci de part leurs interactions quotidiennes avec elle. Nous étudierions dans le chapitre suivant les outils support à la démarche qui contribueront au respect des 4 principes énoncés ci-dessus. Nous ne nous focaliserons malgré tout pas sur les aspects liés à la communication/formation et à la hotline car ils ne relevaient pas du domaine de compétences qui était le notre au sein de l entreprise LASCOM. Nous nous centrerons Page 94

95 Chapitre 3 Analyse et amélioration du déploiement des solutions donc essentiellement sur les outils support à la modélisation des processus et à l émergence des profils utilisateurs. Page 95

96

97 Chapitre 4 Adapter l approche et le dialogue «client» Chapitre 4 Adapter l approche et le dialogue «Client» : un vecteur de performance 1 Introduction Un logiciel PLM, une fois défini et implémenté pour un client, constitue un produit unique propre à l entreprise qui structure son produit/projet. Ceci explique qu il n existe pas d application prête à l emploi efficace sur le marché des logiciels car, contrairement aux logiciels de bureautique, il ne suffit pas de demander ou d imposer aux acteurs de s adapter à ce dernier. En effet, dans le cadre de logiciels PLM c est toute la logique de travail qui est impactée car l enjeu se situe au cœur du savoir-faire de l entreprise. Le niveau de satisfaction client sera donc évalué non seulement sur le logiciel fourni au regard des besoins énoncés - besoins stratégiques, mais aussi par son taux d utilisation - besoins locaux, et la qualité des services gravitant autour du produit (projet, support technique et fonctionnel, audit, etc.) - besoins opérationnels. Dans le cadre de ce type de logiciel, le fonctionnement est basé sur la hiérarchisation des différents types de données et le mode de traitement de ces dernières au cours du cycle de vie du produit/projet. Cette modélisation est conçue pour une entreprise et doit être représentative de la réalité opérationnelle et non pas uniquement théorique. La qualité de ce travail constitue l enjeu majeur pour favoriser la cohérence et la performance de la solution PLM vis-à-vis de l entreprise. L importance de l étude réalisée durant les premières étapes du processus d informatisation, et plus spécifiquement durant les spécifications, apparait comme la clé de voute de l optimisation tant du ratio coût/qualité que du résultat informatique. L amélioration du cycle de déploiement repose donc essentiellement sur la définition et la qualité des spécifications finales. Cette définition dépendra à la fois du niveau de granularité de la modélisation pour aboutir à une solution la plus proche des besoins réels, mais aussi de l exhaustivité de la documentation associée. En effet, cette étape d analyse constitue le cœur du produit fini car elle explicite les besoins, elle imagine des solutions à créer dans le logiciel et elle valide les solutions théoriques retenues sous forme textuelles. Les documents qui en sont issues (les spécifications fonctionnelles) composeront la référence commune entre l éditeur et le client d un point de vue fonctionnel et formeront la base documentaire pour le support afin de répondre rapidement et spécifiquement aux demandes, mais aussi lors de Page 97

98 Chapitre 4 Adapter l approche et le dialogue «client» commandes d évolution pour vérifier les aspects fonctionnels et adapter le devis (que la demande soit une adaptation d une fonction existante ou une création). Pour obtenir une solution cohérente aux besoins de l entreprise et un niveau de service optimum il est nécessaire d aboutir à la fin des spécifications à une modélisation la plus détaillée et la plus réaliste possible tant au niveau local, pour répondre aux besoins, qu au niveau global, pour intégrer la solution dans son environnement, c est à dire pour prendre en compte tous les besoins connexes et les enjeux. Pour assurer l efficacité de la modélisation, nous avons montré dans le chapitre précédent qu il est nécessaire d avoir une démarche de déploiement très structurée et très proche du client. Au-delà de la démarche, il faut aussi avoir des outils efficaces pour que la phase «d opérationnalisation» de la démarche se déroule correctement. Il est primordial d adapter le choix des outils supports à la méthode en fonction de l entreprise (de sa culture), du projet (de l existant), de son envergure (de ses capacités), mais surtout du niveau à analyser et donc des personnes à interroger. L objectif est d obtenir le niveau de précision (de granularité) nécessaire et suffisant en fonction du/des focus et besoins à satisfaire et d agréger les résultats de chacun des modèles pour obtenir une vision complète du système à modéliser. La partition du système en différents n est pas simple et elle n est pas appréciée de la même façon selon les interlocuteurs et leur implication dans l entreprise. Pour accroître la pertinence et la complétude du modèle global, il va être important de construire avec le client une partition (décomposition) partagée du système et de faire intervenir des acteurs de chaque niveau de décomposition identifié. Cette démarche est un peu différente de ce qui a cours aujourd hui puisque se sont souvent les personnes en charge du projet qui travaillent à la décomposition du système et à la construction des modèles. Ainsi, même s il s avère que plus le niveau d implication est fort, plus le niveau d abstraction est faible, la caractérisation des besoins pour et par l ensemble des utilisateurs (ou un panel représentatif) est un véritable enjeu pour l éditeur et le client. Nous verrons dans ce chapitre que pour répondre à cet enjeu et respecter les 4 principes que nous avons édicté il est nécessaire de travailler sur deux axes : d une part le choix puis la mise en place effective d une méthode/démarche de modélisation adaptée au niveau de l entreprise et d autre part les moyens à mettre en œuvre pour placer l acteur au cœur de la définition des modèles et donc finalement au cœur du projet et de la solution. Page 98

99 Chapitre 4 Adapter l approche et le dialogue «client» 2 Le choix de la méthodologie de modélisation : une étape clé 2.1 Problématique générale du choix de la méthodologie Pour favoriser l implémentation et surtout l acceptation de la solution, il est important d approcher au plus près la réalité du terrain. L analyse du besoin et la modélisation constituent les étapes essentielles tant d un point de vue organisationnel - pour établir une relation de confiance avec le client, que méthodologique - pour assurer la qualité des fonctionnalités demandées. L établissement d un climat de confiance, favorisera la communication et la collaboration avec le client, facilitant et améliorant ainsi la modélisation. Si ce climat propice est présent tout au long du projet, il sera alors possible d étudier plus précisément la définition des processus et des indicateurs de performance ouvrant des possibilités d accroître le coté décisionnel des reporting proposés et donc la pertinence de l application. Le but est ici de construire un modèle au plus près du déroulement réel du cycle de vie du produit/projet qui doit être géré dans le logiciel, et ce dans les temps et le budget impartis pour cette étape. Pour concevoir ce logiciel «unique» et adapté à l entreprise sur le périmètre prédéfini, les seules qualités de communicant des interlocuteurs ne suffisent pas et l utilisation des méthodologies adaptées et efficaces est primordiale. Nous avons montré dans le deuxième chapitre (Chapitre 2, 4.2) que bon nombre de méthodologies (et les formalismes associés) permettaient de modéliser une entreprise, une organisation, des processus, des activités et des flux. Certaines sont plus particulièrement orientées sur des aspects stratégiques et généraux (niveau global), d autres sur des aspects plus tactiques et opérationnels (niveau local), d autres enfin permettent l approfondissement et la coordination des niveaux les uns envers les autres. Le choix de la méthodologie doit se faire en fonction des éléments existants (éléments déjà modélisés précédemment par l entreprise ou par l éditeur lors d un projet précédent), du projet (complexité, envergure) et également des participants (connaissance du fonctionnement de l entreprise, aisance avec des méthodes de modélisation). Mais la méthode à adopter sera aussi fonction de l application logicielle implémentée puisque c est elle qui déterminera les besoins en termes de «degré de précision» et d éléments à prendre en compte dans la modélisation. Enfin, le choix dépendra aussi du contexte lié à l entreprise et surtout de la maitrise, de la connaissance et de l aisance qu ont les acteurs du projet dans l utilisation de la méthode. En effet, en fonction de l existant et/ou des intervenants il est souvent plus simple, et surtout plus rapide, soit de partir des modèles existants et d approfondir la partie à traiter, Page 99

100 Chapitre 4 Adapter l approche et le dialogue «client» l approche descendante, soit de partir de la réalité du terrain et de définir le système permettant la réalisation du produit/projet, l approche ascendante. L expérience de LASCOM montre que rares sont les entreprises qui connaissent et utilisent les méthodologies que nous avons précédemment décrites pour modéliser leur organisation, leur fonctionnement et surtout leurs besoins, sauf dans le cadre d une certification portée et réalisée quasi exclusivement par le service qualité. Généralement, ce ne sont qu une ou deux méthodologies qui sont utilisées : IDEF0-SADT et IDEF3. Malheureusement elles n apportent que des représentations assez statiques et globales de l entreprise (par manque de temps de modélisation) qui sont relativement peu exploitables dans le cadre de la conception et du déploiement d un PLM. De plus, les retours des ingénieurs commerciaux de LASCOM montrent aussi que les clients ont souvent du mal comprendre les modèles censés représenter un objet qu ils connaissent pourtant bien : leur entreprise! Il apparait clairement que les méthodologies «classiques» ne sont pas forcément appropriées pour mettre en exergues tous les aspects nécessaires à la conception et au paramétrage des applications. Aucune méthode et aucun formalisme classiquement utilisés ne peuvent répondre à l ensemble des critères nécessaires à un déploiement efficace d une solution PLM. Pour qu une méthodologie et un formalisme de modélisation puisse convenir à la conception d une application, il faut qu ils soient : - Adaptés au paramétrage du logiciel, car le chef de projet doit pouvoir identifier tous les éléments nécessaires à la conception de l outil propre au client, - Adaptés à tous les projets, quelque soit leur complexité et les nombre et le degré d expertise des participants, - Simples, quasiment «intuitifs» et rapides à mettre en œuvre car aucun temps d appropriation des concepts et outils n est prévu dans le cadre du projet, - Compréhensibles par tout un chacun, car plus le support est simple, plus la communication est facilitée et plus il est aisé d impliquer un grand nombre de personnes dans la mise en place de l outil afin d obtenir un produit répondant à toutes les attentes. Quand bien même, la méthodologie choisie est adaptée au projet et au logiciel, compréhensible par tous et ni trop complexe ni trop chronophage, il est primordial de prendre en compte un temps nécessaire pour informer et valider l utilisabilité d une méthodologie (ou d un formalisme) dans le cadre du projet. Information qui doit concerner tout ou partie des intervenants tant au niveau global qu au niveau local. Malheureusement cette phase n est généralement pas prévue lors du chiffrage de l application et doit donc rentrer dans le cadre Page 100

101 Chapitre 4 Adapter l approche et le dialogue «client» des spécifications, diminuant d autant leur durée et détériorant ainsi leur qualité et donc la qualité du produit final et la satisfaction client. En pratique dans de nombreux projets, le choix est d outre passer ces étapes de formalisation dans le but d accélérer la mise en production, et ce au détriment de la qualité des premiers résultats. Ce manque de formalisation entraine un nombre d itérations et de corrections plus conséquents ce qui va à l encontre de l effet escompté en termes de délai et de qualité. C est pour contrer les effets néfastes de la réduction de cette phase pourtant si importante que nous avons proposé de revoir notamment la phase d avant projet (Chapitre 3, Figure 10). Mais revoir une démarche ne suffit pas si cela ne s accompagne pas de la mise en œuvre d outils opérationnels supports à celle-ci, permettant une représentation multi-niveaux et l entreprise et étant des vecteurs de communication entre les acteurs. 2.2 Le casse-tête de la représentation multi-niveaux et de l implication des acteurs Pour obtenir une solution fidèle au système, il est nécessaire d étudier le système avec différents niveaux de représentations et de préférence avec différents acteurs pour confronter leurs différentes visions, leurs expériences et ainsi approcher la modélisation au plus près du système réel et non pas uniquement théorique. La multiplication des acteurs dans le projet apporte un degré de précision important sur la définition des informations à chaque niveau mais entraine aussi la nécessité de gérer un groupe important et de faire «du tri» dans les données récoltées. Au niveau de l entreprise, au niveau global, il sera nécessaire de faire apparaitre son «besoin», comment il s intègre dans son environnement mais également d avoir une vision plus transverse pour ne pas s arrêter au fonctionnel mais intégrer également les aspects stratégiques. Au niveau des processus et des activités de l entreprise (point de vue local), nous devrons être capables de mettre en évidence la définition à plus proche du réel des activités pour que la solution soit en phase avec l organisation mais aussi les acteurs. L expérience montre qu une étude «du réel» contribue à faire apparaitre qu une ou plusieurs personnes non référencées théoriquement interviennent dans certaines actions ou dans certains cas bien spécifiques. Ces personnes sont souvent des ressources clés qui permettent de solutionner des problèmes ou de débloquer des situations jusque là conflictuelles. L aboutissement à une image réel de l entreprise est donc le résultat de la confrontation des différentes visions que peuvent avoir les personnes sur le système. Il est essentiel de les intégrer lors des spécifications mais toujours à un moment opportun. Dans l idéal, il serait nécessaire de Page 101

102 Chapitre 4 Adapter l approche et le dialogue «client» descendre jusqu au niveau «local» pour valider l ensemble des points prévus et adapter la solution aux utilisateurs même du logiciel, car ce sont eux qui seront les moteurs de l utilisation de l application. Aujourd hui il est très difficile de faire participer activement tous ces profils lors des spécifications pour des raisons notamment de coût et seules des validations ponctuelles peuvent se faire et toujours par l intermédiaire du responsable de projet. Notre proposition d accompagnement du client très en amont dans la démarche de modélisation (4 principes édictés dans le chapitre 3) viendra donc se heurter à la difficulté du choix de la méthodologie et du formalisme de modélisation (section précédente) mais aussi à la difficulté de tenir compte de la structuration multi-niveaux et multi-acteurs de l entreprise client. Pour pallier à ces difficultés nous avons axé nos réflexions sur la recherche d efficacité en termes de modélisation de l ensemble des besoins dans leurs contextes, mais aussi de réalisation d un support de réflexion et de l analyse commun en vue d une validation concertée des solutions. Support qui idéalement contribuera aussi au suivi du projet des phases des très amont de processus de déploiement jusqu au déploiement de l application à proprement parler. La section suivante présente nos travaux quant à l utilisation de deux outils pour répondre à notre problématique : les cartes heuristiques et les personas. 2.3 Deux outils «non conventionnels» pour lever les verrous Dans le cadre d un projet d implémentation, de durée relativement courte, non seulement toutes les parties doivent, a priori, comprendre la méthode choisie afin de contribuer activement à l élaboration du modèle selon les étapes définies par cette dernière, mais également connaitre le fonctionnement du formalisme associé. De la même manière, il apparait que le choix du formalisme est tout aussi important que le choix de la méthode pour améliorer la compréhension mutuelle et plus généralement la communication. Sa complexité aura un impact déterminant sur le déroulement des spécifications. De plus, la formalisation graphique constitue la base de la communication pendant les réunions avec le client, or durant ces réunions les intervenants peuvent varier, il est même conseillé qu ils changent pour accroître la pertinence du modèle. Il n est pas opportun d utiliser un modèle trop complexe à comprendre pour un nouvel arrivant ne connaissant rien aux méthodologies et aux différentes cartographies. Tous les intervenants doivent être en mesure de l interpréter, le critiquer et le modifier tout au long du processus de réflexion. L expérience de LASCOM montre que si toutes les personnes participant aux réunions d analyse comprennent le modèle présenté sans explications préalables, leur participation et la communication en seront améliorées. De même Page 102

103 Chapitre 4 Adapter l approche et le dialogue «client» leur visibilité sur le déroulement du projet et plus particulièrement de l étape de spécification et le contenu de la future application sera elle aussi plus grande. Pour que l implication des acteurs soit «naturelle» et «simplifiée», il semble donc que nous devons nous dédouaner des problèmes de sémantiques intrinsèquement liés aux méthodologies et aux formalismes. Nous devons choisir une méthodologie et un formalisme proches du «langage naturel» et basé sur des concepts cognitiques eux-mêmes réduits à leur plus simple expression et proches des démarches intellectuelles quotidiennes des acteurs. Sans oublier malgré tout que nos choix devront permettre une représentation des plus précises de l entreprise, de son organisation et de son fonctionnement. Pour obtenir un modèle d entreprise suffisamment riche tout en conservant la possibilité d intégrer le plus grand nombre de personnes à la définition de l application, nous proposons d utiliser deux formalismes complémentaires et relativement peu conventionnels dans le cadre de la modélisation d entreprises. D une part les cartes heuristiques pour ce qui est de modéliser l entreprise et ses processus et d autre part les personas pour l étude et la validation des spécifications au niveau des utilisateurs finaux de tous les niveaux (du global au local). Ces formalismes ont le mérite d être très simples et souples puisque aucune règle formelle n existe et ils sont facilement adaptables au besoin d implémentation en fonction de la solution et du projet. D un point de vue client nous veillerons à ce que ces formalismes l aident à suivre l évolution de son application et à définir son organisation et ses besoins, et enfin facilitent la communication avec LASCOM. Pour LASCOM ces formalismes devront améliorer la communication et la visibilité du déroulement des projets, voire de déporter une partie de d étude des besoins actuels et futurs chez le client, unifier la définition des applications et faciliter la transmission d informations entre les services. Nous verrons dans les paragraphes suivants que les cartes heuristiques serviront de base aux réunions de spécifications et permettront de définir le projet et son contexte. Et que les personas seront à la base du questionnement des acteurs finaux et contribueront à affiner et vérifier les besoins du terrain en fonction des éléments recueillis durant l étude globale. Nous montrerons aussi comment ces deux formalismes sont étroitement liés, se complètent et pourquoi nous avons décidé de les mettre en œuvre dans le cadre du déploiement d une solution PLM au sein d une entreprise. Page 103

104 Chapitre 4 Adapter l approche et le dialogue «client» 3 Les cartes heuristiques : une base commune de modélisation et de discussion Dans le cas d un projet PLM, la compréhension du contexte d utilisation de la solution passe avant tout par la compréhension de l entreprise (son activité, son organisation, le projet, les besoins, le rôle ). En pratique une partie des éléments du contexte est fournie durant la phase d avant vente, phase au cours de laquelle sont impliqués au moins un commercial et le service de «l avant vente» de chez LASCOM. Ces éléments sont ensuite revus et/ou complétés durant la réunion de lancement qui concerne les directeurs de projet et les chefs de projet du client et de LASCOM. Enfin, ses éléments sont plus explicités et affinés au fil des interrogations qui peuvent apparaitre durant le projet. L environnement du projet étant un facteur clé de succès de par son impact direct sur la qualité et la pertinence de la future application, plus il sera clarifié dès le départ et plus ses évolutions seront tracées meilleur seront les spécifications et la solution par la suite. Les phases préliminaires et de suivi de l évolution du projet ne doivent donc pas être sous-estimées et doivent aboutir à une cartographie de l entreprise, des(s) service(s) concerné(s), de(s) produit(s), des données des plus précises mais malgré tout évolutive. La difficulté de la construction du modèle d entreprise vient du fait que les informations sont parfois de natures différentes et qu il n existe pas un modèle de travail et d échange unique et commun tout au long du projet. Les informations fournies en avant projet sont souvent générales et reflètes les besoins essentiellement stratégiques. Durant la phase d avant vente on tend à passer d une définition stratégique à une définition technique et finalement durant le projet, on passe de cette définition technique à une définition fonctionnelle. Il est souvent compliqué d obtenir l ensemble des informations détenues par chacun des intervenants tout au long du projet car le laps de temps entre l avant vente et les phases de conception peut être relativement long, les intervenants changent et que de nombreuses informations ont été donné informellement, à travers un certain nombre de mails, plus ou moins explicitées dans différents documents... La restitution unique est globale de l ensemble des données est souvent impossible. De plus l évolution de la définition des besoins entraine souvent des discordances entre ce qui a été prévue en avant vente, c'est-à-dire chiffrée et vendue, et ce que le client veut finalement et ce qui est réalisé. La création d un recueil unique de toutes ces informations tout au long du processus, quelque soit le service, apparait indispensable pour éviter la fuite d informations. Ce recueil sera d autant plus essentiel qu il contribuera à la bonne compréhension du projet et influera sur la conception de part les informations qu il contiendra. La problématique est de Page 104

105 Chapitre 4 Adapter l approche et le dialogue «client» construire un support unique pour modéliser l entreprise cliente et suivre l ensemble du cycle de vie du projet. Ce support devra être initié par le commercial, complété par l avant vente, puis par le chef de projet et finalement par le support client LASCOM. Idéalement, ce document sera partageable et partagé avec le client à des fins d optimisation mais également afin d avoir le même niveau d information sur le projet. La conception de ce document ne doit pas entraver le bon déroulement du projet, il ne doit pas nécessiter un effort supplémentaire au travail à chacun des participants et être un vrai vecteur de communication entre les partenaires. Pour répondre à tous ces critères et au regard du temps impartis à la construction de ce type de document, il était nécessaire de trouver un format accessible, ne nécessitant pas un haut niveau de formalisme, adaptable, rapide à construire, à parcourir et à mettre à jour. Notre choix s est donc porté sur les cartes heuristiques, plus communément appelées «mind map» ou «map». Nous allons voir quel est le principe de construction d une map puis comment elle peut s inscrire dans le cycle de vie et surtout comment définir sa structure dans le cadre du déploiement d une application. 3.1 La carte heuristique ou une structuration rapide d idées Lors d un lancement de projet d implémentation, et plus particulièrement lors des premières étapes d interventions pour l étude et les spécifications, le premier problème rencontré par les intégrateurs est la compréhension et l appropriation du fonctionnement de l entreprise. Cette problématique peut généralement se traduire par les questions suivantes : Par où et comment commencer? Notre proposition pour répondre à ces questions dans le cadre de la modélisation d une entreprise en vue du déploiement d une solution logicielle est d utiliser une représentation heuristique (du grec ancien εὑρίσκω, eurisko, «je trouve»). En vogue depuis quelles années dans le monde universitaire, la représentation heuristique fait aujourd hui son apparition dans le monde industriel pour organiser des idées, des plannings, des projets, animer des réunions Cette représentation nommée carte heuristique, ou mind map en anglais, carte des idées, schéma de pensée, carte mentale, arbre à idées ou encore topogramme, est un diagramme imaginé par le psychologue Tony Buzan en 1971 [Buzan, 93]. Il représente des liens sémantiques entre différentes idées ou des liens hiérarchiques entre différents concepts. La création d une carte heuristique se décompose en deux grandes phases : la création d un pêle-mêle d idées puis la construction du schéma. Concrètement, dans un premier temps, sur une grande feuille ou un tableau, il suffit d inscrire Page 105

106 Chapitre 4 Adapter l approche et le dialogue «client» un titre explicite au centre, illustrant le sujet de la réunion, puis à travers un brainstorming, il suffit d écrire toute les idées sous forme de mots clés autour de ce premier concept, de façon aléatoire. Le principe est de réaliser une liste la plus exhaustive de tous les préceptes se rapportant au sujet. Dès que tous les intervenants manquent d inspiration, il suffit de choisir un de ces mots clés et d effectuer la même démarche en inscrivant tout autour une nouvelle liste. Le support rempli de mots constitue la carte mentale divergente, autrement dit un minischéma visuel où les mots sont inscrits dans l'ordre d apparition dans l'esprit de la/des personne(s) et où les idées sont directement reliées à l'idée principale. Il s'agit d une première version exploratoire (remue-méninges visuel). Pour aboutir à une carte heuristique convergente, il est nécessaire de réaliser deux actions distinctes : l organisation et le figuralisme. La première a pour objectif de réorganiser la pensée en regroupant, triant, classant et hiérarchisant les idées, tandis que la seconde donne vie, grâce à une image visuelle, à la pensée en associant des éléments graphiques, des images, des couleurs, du volume La hiérarchisation des mots et des images attribue un rang qui reflète leur importance et leur filiation jusqu'à plusieurs niveaux de parenté. Le caractère graphique doit marquer l esprit et faciliter la compréhension de ces liens. En effet, à l'inverse du schéma conceptuel ou de la carte conceptuelle (concept map en anglais), la carte heuristique est le plus souvent une représentation arborescente de données sans étiquetage formel des liens. Cette représentation constitue un support très visuel, adaptée aux réunions de brainstorming ou de découverte d un concept en favorisant les échanges, l interprétation, l appropriation et la mémorisation. Pour systématiser l exploration d un système ou d un concept, sans pour autant complexifier les échanges et la communication au sein de l équipe projet, sa conception et/ou sa réorganisation peut reposer sur les sept questions d Aristote (Quoi, Qui, Quand, Où, Comment, Pourquoi, Avec quoi) (Figure 11). Finalement, une carte mentale (ou carte heuristique) est un diagramme qui permet de représenter de manière globale et assez complète une situation (un problème, un concept ou un projet). Le ou les objectifs peuvent être divers : soit la réalisation d un compte rendu de réunion en restituant rapidement les idées et les concepts clés, soit la résolution d un problème en explorant un maximum de solution rapidement, soit d apprendre en assimilant de manière connexes un ensemble d informations, soit l organisation d un projet en constituant une cheklist des éléments à ne pas oublier, soit la structuration d un projet en clarifiant les rôles et objectifs de chacun L utilisation de carte se répand de plus en plus car elle est d une manipulation très aisée, adaptable et personnalisable. Page 106

107 Chapitre 4 Adapter l approche et le dialogue «client» Figure 11. L illustration des sept questions d Aristote [Créativité, 12] Les avantages dans le monde industriel sont nombreux puisque les maps constituent des supports évolutifs facilitant la participation, améliorant la communication et les échanges et offrant la possibilité d élargir le cercle des intervenants ponctuellement sans perdre le temps de compréhension. De plus leur niveau d accessibilité est très important car elles ne reposent sur aucune méthode abstraite autre que la réflexion et l association d idée puis le questionnement systématique pour chacun des éléments présent sur la carte : il n est pas nécessaire d avoir une idée précise au départ du système à représenter. Leur formalisme flexible est adapté au concept simple ou complexe en catégorisant les liens pour représenter et visualiser la hiérarchie des concepts et il permet de formaliser les différentes perceptions d un système en fonction des regroupements fait par les uns ou les autres des intervenants. En conclusion, nous pouvons retenir que «la démarche heuristique permet d aborder la complexité dans ce qu elle contient de plus riche, parce qu elle la rend intelligible sans la réduire à quelque chose de simple. Il en est ainsi pour résoudre des problèmes. Dans ce cas, la démarche heuristique nous permet d identifier et clarifier le problème, procéder à un Page 107

108 Chapitre 4 Adapter l approche et le dialogue «client» diagnostic pour ensuite imaginer une solution. Et pour ce faire, augmenter notre champ de vision et celui des possibles.» [Deladriere et al., 07]. L utilisation de carte heuristique n est pas une méthode conventionnelle de conception - quoique de plus en plus cités et utilisés dans les articles scientifiquement, mais elle peut être adaptée pour répondre au besoin de création d une application associée de surcroit à un formalisme simple et accessible à tous. Elle constituerait la dorsale d un projet d implémentation tant pour faciliter la compréhension des besoins quelque soit le niveau d abstraction, que pour créer, présenter et valider la solution retenue. 3.2 La formalisation heuristique tout au long du projet : approche théorique Dans le cas du processus de déploiement d un logiciel de gestion, la capitalisation des connaissances sur le client et le projet représentent la clé de l optimisation du résultat. Durant l implémentation d une solution logiciel, les acteurs coté éditeur/intégrateur se succèdent au rythme des phases du projet. Chacun d eux acquièrent des connaissances de différents ordres commercial, stratégique, technique, fonctionnel, etc. en fonction de leurs interlocuteurs. Nous proposons de voir dans cette section comment la carte heuristique peut s inscrire concrètement dans la complétude du processus de déploiement (Chapitre 3, Figure 10) Le commercial et la map Comme nous l avons vu, la première phase du processus est une phase essentiellement commerciale. Sa durée est variable car le cheminement entre la prospection et l émergence d un projet peut être relativement long en fonction de la maturité du projet, et l acteur central est le commercial. Durant cette étape, un certain nombre d informations est collecté par le commercial en amont via différentes sources, d autres sont divulguées par le client lui-même au «fil de l eau». Toutes ces informations sont généralement informelles et beaucoup apparaissent mais sont mises de coté par le commercial qui peut les juger comme inutiles pour le restant du processus. Malheureusement certaines de ces informations peuvent malgré tout contribuer à déterminer le contexte stratégique du projet. Ces informations sont ensuite transmises au service de l avant vente qui lui va apporter une réponse technique et un chiffrage au plus juste et des plus approprié tout en étant conscient du peu d informations en sa possession pour parvenir un résultat très proche du résultat final. Lorsque le client a reçu l offre et l a acceptée, les informations passent ensuite de l avant-vente au niveau de l équipe projet. A ce niveau, bon nombre d informations sont généralement perdues ou resurgissent Page 108

109 Chapitre 4 Adapter l approche et le dialogue «client» parfois au gré des certaines interrogations. Pour éviter la perte d une partie de la dimension stratégique, l idée est d initialiser une map dès la prospection par le commercial, sans même savoir si effectivement un projet en ressortira. L objectif est de collecter un maximum d informations pour faciliter et accélérer le travail d avant vente, qui ne serait plus contraint «d aller à la pêche» aux informations et de se reconstruire sa vision «globale» du contexte au fil des mails échangés et des discussions avec le client. Pour le commercial, l instauration de ce formalisme peut représenter un outil efficace dans ses démarches de prospection. Pour ce faire, nous devons être en mesure de lui fournir une map générique qui orientera son questionnement et qui sera la base de la construction d une map spécifique au client, représentative de l ensemble des informations en sa possession tant pour valider certains points que pour former et enrichir sa base de connaissances sur le client. L approche de modélisation adoptée est ici clairement une approche descendante. Nous verrons par la suite qu au cours du projet cette approche sera complétée par une approche ascendante pour enrichir la carte L avant vente et la map Si l on suit le processus, une fois un cahier des charges émis par le client via le commercial, le dossier est pris en charge par l avant vente. Leur objectif est de composer une réponse technique et chiffrée d une solution répondant à un maximum d exigences décrites dans le cahier des charges. Aujourd hui cette double réponse est réalisée conjointement avec le commercial, voire le service de développement pour certains aspects spécifiques, le but étant généralement d utiliser au maximum les «briques» et les fonctionnalités standards proposées au catalogue pour chacun de verticaux. Pour élaborer sa réponse, la personne en charge du projet se construit une «image» de la solution finale, généralement de manière informelle en griffonnant sur un papier. Cette idée émerge de sa propre compréhension du besoin, basée sur les différentes informations en sa possession (transmises ou acquises en demandant au client des compléments sur certains points), de son expérience et de ses connaissances. Basée sur cette vision personnelle de la solution, elle va d une part concevoir la réponse technique expliquant le fonctionnement global de la solution et les fonctionnalités proposées pour répondre aux attentes particulières, et d autre part chiffrer approximativement cette proposition. Le chiffrage étant la partie la plus délicate du fait des incertitudes sur l expression du besoin, des possibilités techniques, des différents participants et de leurs connaissances. Autrement dit, la vision de la solution finale n est pas définie explicitement dans la réponse. Dans notre proposition, la carte initiée à l étape précédente par le commercial Page 109

110 Chapitre 4 Adapter l approche et le dialogue «client» est fournie à l avant vente en même temps que le cahier des charges. Le premier intérêt est d avoir la même vision partagée du contexte du projet que le commercial, ce qui permet d obtenir une vision d ensemble plus rapidement et de faciliter d autant plus le dialogue avec ce dernier. Le second intérêt est d illustrer la proposition technique rapidement et simplement, grâce à une librairie pré-initialisée avec l ensemble des composants nécessaires pour formaliser la vision de l application, du point de vue du modèle de données et des fonctionnalités standard disponibles, sans forcément entrer dans les détails précis de la conception. Cette modélisation rapide permet de fixer formellement une vision du besoin, du contexte et de la solution qui pourra être ajoutée à la réponse pour servir de référence pour la suite du projet. D un point de vue méthodologique, la formalisation peut également faciliter la rédaction de la réponse technique en formant la dorsale du document. Ainsi au moment de l envoi de la réponse au client par l éditeur, la carte heuristique met en évidence les besoins stratégiques, les besoins techniques et «l image» de la modélisation sur laquelle repose la proposition réalisée Le service projet et la map Si la solution est retenue, le projet est lancé et le dossier est transmis au service projet. Aujourd hui, la passation repose sur le transfert d un certain nombre de documents, généralement le cahier des charges et la réponse de l avant vente (technique et financière) ainsi que des éléments temporels et financiers (date de début souhaitée, date de fin exigée, pénalités, etc.). Une réunion rassemblant le commercial, l avant vente, le directeur de projet et le futur chef de projet est organisée dans le but d appréhender le projet mais également la réponse réalisée afin d obtenir la vision globale du projet, établir le travail à faire et élaborer un planning. Généralement, à la fin de cette réunion, le nouveau chef de projet a en sa possession les documents cités précédemment, plus toute une collection de mails qui ont été transférés pendant ou après la réunion en fonction des discussions, une collection de notes prises par chacun, des feuilles griffonnées scannées, plus ses propres notes pour établir son référentiel projet. Finalement, le constat est donc que chacun doit se recréer son environnement et son support de travail, sur la base de documents aux origines et aux formats hétérogènes, provoquant indubitablement des pertes de temps, des pertes d informations mais également des mauvaises compréhensions. Tout ceci est source de doutes, de questions immédiatement après la réunion ou plus tard, lors de la confrontation avec les documents reçus, voire chez le client. Dans la nouvelle vision que nous proposons, en début de projet, la carte heuristique continue à suivre les phases du processus et est donc à disposition du chef de Page 110

111 Chapitre 4 Adapter l approche et le dialogue «client» projet. Lors de la réunion interne, tous les participants possèdent ainsi le même support, avec le même niveau d information ce qui permet de présenter le projet de manière ordonné, structuré et systématique, et d aborder des points en particulier sans perdre de temps sur d autres points très basiques ou bien explicités. Ainsi si des oublis ou des imprécisions sont décelés, la mise à jour de la carte est réalisée conjointement à ce moment là, créant ainsi un référentiel commun sur le projet rassemblant les différents niveaux de connaissance acquise par chacun des acteurs. Lors du lancement de projet à proprement parlé, c'est-à-dire lors d une réunion LASCOM / Client, l organisation du projet, les intervenants et leurs rôles, le planning prévu pour un contour fonctionnel précisé sont présentés. Jusqu à présent cette étape était délicate de par les incertitudes existantes tant sur l appréciation des informations d un point de vue client comme éditeur (le contour fonctionnel, les solutions envisagées, etc.), que sur la différence entre le besoin perçu et le besoin réel. La présence de la carte heuristique n apportera pas une aide substantielle pour cette étape mais présente deux intérêts majeurs. D une part, ayant été construite en liaison étroite avec le client dès les phases amont, elle ne devrait théoriquement contenir que peu d éléments sujets à des incertitudes. D autre part, à travers cette amélioration de la fiabilité des informations fournies, c est toute la communication au cours de cette étape qui devrait être facilitée par l utilisation qu il peut être faite de la map comme support pour exposer clairement la solution chiffrée, expliciter le lien existant entre le planning et la délimitation du projet, etc. Le projet d informatisation est alors lancé et débute par la définition des spécifications au cours d une phase d analyse du besoin plus ou moins poussé et plus ou moins dissociée de la phase de détermination des caractéristiques de la solution. Aujourd hui il n existe pas de méthode ou de formalisme propre à cette étape. Le constat général est que cette étape est souvent très longue du fait d itérations régulières, issues de problèmes de compréhension, de communication, de niveau de connaissance des intervenants, de la validation interne asynchrone et point par point. La conséquence est que la phase d analyse est souvent réduite au minimum afin de tenir les délais au risque d aboutir à un logiciel strictement fonctionnel basé sur le cahier des charges corrigé, et non sur les besoins réels et les retours d expériences des acteurs principaux et sans prendre en compte les aspects de pilotage. L utilisation d une carte heuristique a pour objectif de limiter tous ces problèmes. Dans un premier temps, il sera nécessaire de compléter la carte existante pour l enrichir. Pour ce faire nous proposons de Page 111

112 Chapitre 4 Adapter l approche et le dialogue «client» construire une nouvelle carte qui viendra compléter la précédente et qui sera dédiée aux intervenants coté client identifiés comme des utilisateurs de la future solution. Jusque là ces interlocuteurs n ont pas été impliqués et une nouvelle carte permettra de ne pas les influencer et d aboutir rapidement à une définition des besoins concrets utilisant la sémantique propre à l entreprise. L élargissement des cercles des intervenants et la rotation des participants sont facilités grâce à la simplicité du formalisme ce qui aboutit à une définition plus précise, plus rapidement et plus près la réalité et ce sans pour autant faire perdurer l étape. De plus, grâce à l accessibilité et la flexibilité, l élaboration peut donc être réalisée avec ou sans l éditeur/intégrateur permettant de diminuer les coûts. La seule contrainte est de vérifier régulièrement la présence de tous les éléments décrits dans la première carte pour assurer la compatibilité et la cohérence entre les deux cartes. Autrement dit, le concepteur de la carte des besoins doit vérifier ou s inspirer des éléments collectés dans la carte utilisée jusqu à présent pour orienter la réflexion et la description des participants, afin d éviter des manquements. L objectif est évidemment de n avoir qu une seule carte globale construite sur la base des cartes secondaires. Les informations fonctionnelles ainsi obtenues venant compléter les aspects stratégiques et techniques et mettre en exergue si besoin les différences avec le prévisionnel réalisé en avant vente. Les premiers intérêts de l utilisation d une map sont d accélérer l analyse du besoin, rendant possible la systématisation de cette phase sans augmenter les coûts, tout en améliorant sa qualité, en élargissant les profils interrogés. A la fin de cette phase, si le décalage est trop important avec le cadre fonctionnel prévu, la map est un élément commun de discussion pour mettre en évidence de manière tangible les écarts, voire pour demander un arbitrage du client. Les constitutions de maps secondaires a pour but ici d adopter une approche de modélisation ascendante venant compléter l approche descendante initiale. L idée de profiter des avantages de ces deux approches pour faire émerger une image plus précise du «réel» de l entreprise. Une fois le besoin définit, la conception débute. L idée est de mettre en vis-à-vis les besoins et la modélisation de la solution sur une même carte. Pour ce faire, soit l utilisation du modèle créé en avant vente est possible, si les écarts entre les définitions ne sont pas trop importants, soit il est préférable de recréer un modèle en se basant sur une librairie standard. Dans les deux cas le but est de créer l image la plus précise possible du logiciel en répondant aux attentes point par point. Les avantages de la map unique dans la spécification sont d explorer les besoins exprimés par les utilisateurs de manière systématique, d expliciter facilement le pendant entre chacune des demandes et leur réponse par un effet miroir, Page 112

113 Chapitre 4 Adapter l approche et le dialogue «client» d améliorer la qualité et la finesse de spécification de l application et finalement d assurer un haut niveau d adéquation entre l expression de besoin, la réalité du terrain et l application finale. Une fois la définition validée, l application est déployée et nécessite la création de documentations et l instauration de séances de formation. Aujourd hui, selon les projets, les services en charge de la documentation et des formations font soit des propositions sur la base d éléments génériques soit des propositions spécifiques. Une transmission de connaissances, essentiellement d un point de vue fonctionnel et sémantique, pour chacun des cas est nécessaire. Autrement dit les personnes en charge de ces activités au sein de LASCOM doivent se réapproprier en partie le projet ou du moins la solution réalisée pour apporter une qualité de service minimum. En effet, que ce soit pour la documentation ou pour la formation, il est essentiel d utiliser la sémantique «métier», voire celle du client, pour que l information soit comprise et assimilée et que les utilisateurs s approprient facilement l application sans être bloqués au cours de son utilisation. La map ne résoudra pas tous les problèmes mais aura au moins le gros avantage de structurer la transmission de connaissances et offrira un support dans lequel il sera la possible de naviguer aisément entre la vision métier (les besoins) et la vision logicielle (la modélisation). L intérêt étant d accroître la performance tout en améliorant la qualité du service Le support client et la map La dernière étape du processus jusqu à présent était le support client. Le rôle du support client est de répondre aux différentes problématiques rencontrées par les clients dans l utilisation de leurs applications. Une première distinction est réalisée en fonction de la nature de la question, technique ou fonctionnelle, et de la gravité, mineure, normale ou bloquante. Pour les aspects techniques spécifiques, un second niveau d analyse est nécessaire pour déterminer si c est effectivement un «bug» de la solution ou un choix volontaire validé par le client à un moment donné (la personne déclarante n étant peut être pas du tout au courant du choix validé en amont). Pour les aspects techniques standards, c'est-à-dire non développé pour un client en particulier, ou les bugs spécifiques, la compréhension du problème est généralement assez aisée. La difficulté réside essentiellement en sa reproduction sur des plateformes internes sachant que généralement en informatique si le problème est reproduit, cela signifie intrinsèquement que le problème est identifiable donc potentiellement corrigeable. Finalement les impacts de la correction et la non-déstabilisation de l application sont vérifiés. Pour les aspects fonctionnels, la distinction est toujours basée sur standard et Page 113

114 Chapitre 4 Adapter l approche et le dialogue «client» spécifique mais nécessite précédemment de traduire la nature de la demande exposée généralement avec la sémantique du client. Répondre à des questions sur le fonctionnement standard est plus simple pour le support car la réponse est souvent générique ou fonction de la version. Par contre pour le spécifique, au vue du temps impartis pour répondre, les ressources à leur disposition résident essentiellement sur leurs expériences et sur les chefs de projet. Autrement dit, lorsque le chef de projet n est plus là, les seules ressources disponibles sont les différentes documentations réalisées au fil des évolutions (en espérant qu elles soient à jour), augmentant le temps nécessaire pour trouver la réponse, donc diminuant la satisfaction client. Une fois encore, la map peut être une aide intéressante pour le support client en apportant une vision synthétique de la solution déployée au regard du besoin, des différentes évolutions réalisées, des fonctionnalités mises en œuvre, des spécificités développés Elle permet également d obtenir la traduction dans la sémantique du client, si cette dernière est bien maintenue à jour, c'est-à-dire que le support client complète la map en y annotant ses interventions Synthèse L utilisation du map générique implémentée tout au long du cycle de vie du logiciel facilite le travail de chacun des intervenants, internes et externes. La Figure 12 met en évidence le phasage de l évolution de la map générique et l implication des différents services au regard du cycle de déploiement de la solution logicielle. Cela nécessite néanmoins une certaine rigueur mais somme toute négligeable au regard de la facilité de mise à jour et des apports pour chacun des acteurs. La constitution d un référentiel commun accessible contribue ainsi à améliorer la qualité du logiciel, en raison de l analyse systématique des besoins mais également des services connexes au logiciel. Nous allons montrer dans la section suivante comment il est possible de construire et d opérationnaliser une map générique puis de l implémenter tout au long du projet. Page 114

115 Chapitre 4 Adapter l approche et le dialogue «client» Figure 12. Les acteurs du processus d informatisation et points d évolution de la map 3.3 Une carte générique pour le déploiement des solutions LASCOM L un des freins au déroulement d un projet d implémentation réside dans la difficulté à obtenir une vision globale du projet et de la solution mise en place par les différents acteurs tant du coté client que du coté éditeur. Notre proposition est de construire tout au long du cycle de vie une carte heuristique qui sera la «carte d identité» et le «carnet de santé» du projet. Cette carte sera bâtie de façon collaborative entre l éditeur et le client suivant une démarche précise que nous définirons dans ce chapitre. Notre objectif est d améliorer le processus de déploiement et plus globalement le cycle de vie du logiciel en créant un document de travail unique et commun aux deux parties. Les bénéfices de la démarche ne seront possibles que si et seulement si la map est connue, reconnue, comprise, utilisable par Page 115

116 Chapitre 4 Adapter l approche et le dialogue «client» tous les intervenants et surtout si elle est maintenue à jour. La mise en place d un tel outil impose de sensibiliser l éditeur et le client sur l intérêt de l utilisation d une map pour ensuite systématiser sa conception et sa construction. Systématiser signifie que nous devons définir la structure d une map minimale générique et implémentable par les acteurs de projet simplement et un temps réduit. Pour initier la démarche chez LASCOM puis chez les clients nous proposons une «méta-map» de base qui sera le point de départ de la construction d une vision globale du projet et aidera à systématiser la spécification des démarches. Pour que ce modèle soit un cadre générique minimaliste, simplifié et exploitable par LASCOM nous l avons bâti sur la base de capitalisations d'expériences antérieures de projets LASCOM. Ce modèle évoluera en fonction de l apparition de nouvelles bonnes pratiques ou habitudes de travail, des mœurs, des besoins spécifiques ou des améliorations de l outil et de la démarche. Pour être pertinente, la carte doit apportée une vision de l ensemble du projet des phases initiales de la démarche de déploiement jusqu aux phases terminales. Nous devons ainsi retrouver sur la carte la définition des besoins, la situation du projet et la solution déployée et ce à tout moment du cycle de vie. Pour répondre à cette contrainte, notre proposition est de décomposer la map en quatre branches (Figure 13) : - La partie «Contexte» regroupera les informations relatives à la définition de la structure organisationnelle et du fonctionnement initial de l entreprise (avant que la solution logicielle soit installée). Cette partie se complétera en collaboration avec le client au fur et à mesure de l évolution des modélisations successives de l entreprise, - La partie «Interventions» sera une zone de travail commune avec le client. Elle contiendra les éléments relatifs au déroulement des interventions et des corrections, - La partie «Livrables» concernera le suivi des livraisons liées à l implémentation et à l installation de l application, - La partie «Applications» reflète le paramétrage et la définition du logiciel en cours d utilisation et donne un premier niveau d explication du mode de fonctionnement. Page 116

117 Chapitre 4 Adapter l approche et le dialogue «client» Figure 13. Structure d une carte client générique («méta-map») Le commercial initiera ces quatre éléments puis au cours du projet chaque modification, chaque correction ou évolution apportée par un acteur fera évoluer le modèle ce qui apparaitra visiblement sur la carte heuristique. Les informations «de travail» seront tout d abord décrites dans la partie «Interventions» dans un espace de travail commun dédié. Puis, une fois validés, les différents éléments seront mis à jour tant dans la définition du besoin dans le «Contexte». Les informations décrites dans le contexte ne s y trouveront que si elles sont validées, le «Contexte» étant le modèle stabilisé, «contractuel». Au fur et à mesure de la construction de la solution, c est la définition des «Livrables» qui évoluera pour enfin aboutir à la mise à jour de la partie «Applications». Cette partie sera l image fidèle de la solution effectivement mise en place chez le client. Une telle décomposition permettra de suivre l évolution des éléments relatifs au déploiement d une solution chez un client tout au long de son cycle de vie Le contexte de l entreprise La branche «Contexte» regroupera les éléments de description de l entreprise et plus spécifiquement le contexte du projet. Cette partie de la map doit contribuer à mettre en évidence l ensemble des éléments relatifs à l environnement du projet en termes de structurations organisationnelle et fonctionnelle de l entreprise avant l installation du logiciel. Les informations contenues doivent permettre de modéliser l entreprise grâce à l association des informations collectées par tous les acteurs. La définition de l entreprise s affinera au fur et à mesure en associant les informations d ordre juridique, stratégique et fonctionnel et ce d un niveau assez global à un niveau très local. Cette branche est créée par le commercial Page 117

118 Chapitre 4 Adapter l approche et le dialogue «client» LASCOM dès le début de la prospection et son contenu évoluera tout au long de l avancée du projet et de l implication des différents acteurs. L utilisation d heuristiques apparait comme étant un outil adapté pour cette étape tant pour l exploration de l entreprise, des possibilités de projet dans une entreprise ou tout du moins des axes potentiels de développement, que pour accompagner la maturation de cette réflexion pour parvenir à déclencher un projet. Autrement dit, la formalisation de tous ces éléments fonctionnels et stratégiques fournis au fil des réunions et de discussions doit permettre de donner une vision plus structurée au commercial de l organisation, des besoins et du potentiel de l entreprise et doit l aider à fournir des exemples et des solutions probantes issues du référentiel commun (Figure 14). D un point de vue commercial, cet outil sera un support au démarchage et à la «découverte» de l entreprise mais aussi à l affinement de la prospection, la rendant ainsi plus efficace, mais également plus pertinente grâce à la mise en place d un format unique facilitant la comparaison entre les différentes solutions mises en place chez les clients. Page 118

119 Chapitre 4 Adapter l approche et le dialogue «client» Figure 14. Le contexte prédéfini par le commercial La partie «Contexte» et plus spécialement la sous partie «organisation» sera ensuite affinée en avant vente grâce à la description fournie par le cahier des charges et les informations obtenues en cours d analyse (Figure 15). Au niveau commercial, seul les grands Page 119

120 Chapitre 4 Adapter l approche et le dialogue «client» axes du besoin ont été recensés (tous ne font peut être pas partie de la demande à traiter) et c est l étape d avant vente qui fera apparaitre plus nettement bon nombre d exigences. Figure 15. Le contexte enrichi par l avant vente Pour l avant vente, cet outil apparait comme un support à la lecture des cahiers des charges pour structurer les exigences, identifier les actions voire les acteurs ou du moins leur Page 120

121 Chapitre 4 Adapter l approche et le dialogue «client» profil, les interactions, les zones d ombres. Le but est d obtenir une vision globale plus fine des demandes et des éléments à modéliser. Cette partie sera réétudiée durant les premières phases du projet d implémentation, pour parfaire la définition des besoins en complétant cette vue de l entreprise par l appréciation des acteurs interrogés durant la phase d analyse des besoins. La pertinence de cette phase est accrue de par l accessibilité et la flexibilité du formalisme, permettant d élargir le cadre des intervenants et donc des futurs utilisateurs potentiels. L objectif est d obtenir une modélisation de l entreprise nécessaire à l implémentation de la solution du niveau «global» jusqu au niveau «local» si possible et ce pour les acteurs actifs et passifs (Figure 16). La mise à jour de cette partie de la carte sera effective dès lors que cette modélisation sera validée par le client dans la partie «Interventions». Pour la partie projet, la carte initie le lancement effectif du projet en apportant une vision compréhensible par tous et partagée de la solution envisagée par l avant vente. La map devient surtout l outil central de la définition des exigences et des besoins pour tous les niveaux. Cette exploration systématique des besoins peut faire naitre des différences importantes avec le cahier des charges initial mais aussi de nouveaux besoins. L avantage d utiliser un même formalisme et une map unique entre l avant vente et le projet réside dans l identification rapide des parties non chiffrées mises en valeur par l intermédiaire de petits drapeaux : - Drapeau vert si la fonction est native dans l application c'est-à-dire nécessitant peu, voire pas de travail, - Drapeau orange si cela nécessite un peu de travail pour intégrer la demande, - Drapeau rouge si le travail est conséquent, - Drapeau noir s il n y a pas de solution. Grâce à cette mise en exergue des différences, l arbitrage commercial est facilité afin d aboutir conjointement avec le client à la définition du nouveau cadre fonctionnel à prendre en compte, voire des évolutions à prévoir (Figure 17). Page 121

122 Chapitre 4 Adapter l approche et le dialogue «client» Figure 16. Le contexte revu lors du projet Page 122

123 Chapitre 4 Adapter l approche et le dialogue «client» Figure 17. Contexte à prendre en compte pour le projet Suivi des interventions La branche «Interventions» correspond au suivi de toutes les actions réalisées durant le cycle de vie du projet, c'est-à-dire des différents sous-projets mais également des actions Page 123

124 Chapitre 4 Adapter l approche et le dialogue «client» réalisées par le service support. Dans le cadre d un projet, cette partie tient place de définition de la structure du projet en apportant une vision des différentes étapes. C est un outil de suivi de projet par la mise en évidence de l évolution de ses différentes étapes dans le temps mais également un espace de travail partagé entre le client et l éditeur. C est aussi le support à la validation de la modélisation avant son application dans les autres parties de la carte. Cette partie est pré-initialisée par l avant vente notamment au cours de la phase de chiffrage de la proposition. Pour mener cette phase à bien, c est à ce moment là que la partie organisation du projet est réellement affinée et évaluée par l avant vente en fonction des demandes spécifiques présentes dans le cahier des charges (certaines phases ou certains livrables) ou simplement en fonction de la complexité du projet. L initialisation consiste ainsi à déterminer les grandes étapes du projet et les livrables associés, que ces étapes soient réalisées avec le client ou uniquement chez l éditeur. Nous retrouvons sur cette branche l ensemble des étapes et sous-étapes du processus de déploiement de la solution LASCOM. L initialisation est très importante car elle permet de compléter la réponse de l éditeur en illustrant non seulement les aspects fonctionnels et financiers mais également l aspect organisationnel du projet (Figure 18). La définition de l organisation du projet sera reprise durant le lancement de projet pour l affiner et établir les dates prévisionnelles issues de la planification. Durant le projet, cette partie planning pourra bien évidemment évoluer et un indicateur est placé pour estimer le travail restant sur chacune des étapes. Cet indicateur est matérialisé par les carrés plus ou moins colorés présent au départ de plusieurs sousbranches (Figure 18) : plus le carré est coloré plus l étape est avancée (1/4 du carré coloré 25% de l étape réalisée, la moitié du carré, 50% réalisé ; ¾ du carré, 75% réalisée, etc.). La sous-branche «support de réunion» sera construite au fil du projet, selon les besoins. Par exemple la définition du contexte via l analyse du besoin sera construire dans cette partie avant d être intégrée dans la partie contexte, ce qui permet de débuter l étude à partir d une carte vierge pour ne pas influencer les participants, de pouvoir la modifier, la réorganiser sans pour autant perdre de vue la proposition établie précédemment (Figure 19). Aucune contrainte n est définie pour cette partie, elle doit être adaptée en fonction des intervenants et du contexte mais doit illustrer chacune des validations à effectuer par l entreprise. Page 124

125 Chapitre 4 Adapter l approche et le dialogue «client» Figure 18. L initialisation du suivi des interventions par l avant vente Page 125

126 Chapitre 4 Adapter l approche et le dialogue «client» Figure 19. Le suivi des interventions en cours de projet Dans ce contexte l utilisation d une carte heuristique a l avantage de constituer un support unique pour le suivi du projet d un point de vue macroscopique qui suffit bien souvent pour les clients, pour les réunions mais également pour la rédaction des documents à livrer à chacune des étapes grâce à sa structuration lors des réunions. Il pourra aussi générer automatiquement le plan du document suivant le logiciel utilisé. Cette zone sera également utilisée lors de l intervention du support pour tracer les demandes réalisées mais surtout les modifications et les résolutions de problèmes. Elle aide à l identification rapide de la source du problème : n avait-il pas été traité ou détecté? La modification est-elle demande d évolution ou un retour en arrière à transmettre au commercial. Pour faciliter cette recherche l information d entrée est idéalement la fonctionnalité en cause (Figure 20). Page 126

127 Chapitre 4 Adapter l approche et le dialogue «client» Figure 20. Convention pour les interventions par le support Une fois le correctif validé, il serait idéalement nécessaire de mettre à jour la partie «Contexte» et «Applications» pour ne pas perdre cette information et surtout conserver la carte à jour. Pour ne pas alourdir la charge du support, nous proposons d utiliser un système de flèche pour identifier la source et l impact de leur modification (Figure 21). Figure 21. Origine d une correction par le support Dans le cadre du support, l utilisation de la carte apporte le niveau de connaissance suffisant pour comprendre les demandes techniques ou fonctionnelles du client, dans un langage métier ou informatique et d identifier l organisation et la définition de l application facilitant la reproduction du problème et les tests de validation. La partie «Interventions» a pour objectif d améliorer le déroulement de projet tant sur la communication, le niveau d information fourni au client, que sur la qualité des prestations, le niveau d analyse, que sur la dynamique du projet (un seul document à mettre à jour, pas de support à recréer à chaque réunion, des réunions plus rapides). Plus généralement cette partie Page 127

128 Chapitre 4 Adapter l approche et le dialogue «client» retrace donc toutes les évolutions réalisées au cours du cycle de vie du logiciel. L utilisation de la map permet quelque soit l intervenant d obtenir rapidement une vision globale de la solution, de cibler plus facilement le contexte de son intervention et son impact fonctionnel Suivi des livraisons La branche «Livrables» tient sa nature à la difficulté rencontrée de gérer facilement et efficacement les différents livrables au regard de la facturation. En effet, en règle générale, la facturation est possible si et seulement si un certain nombre de livrables ont été fournis. Sa structure est très simpliste car l objectif est uniquement d obtenir une vue synthétique des éléments à livrer pour pouvoir facturer (Figure 22). Figure 22. Structure de la partie «Livrable» Cette partie est complémentaire à la partie «Interventions» et apporte un autre point de vue sur l évolution du projet. L avantage de la carte est la centralisation des données pour apporter un vue d ensemble sur le projet Définition des applications La branche «Applications» a pour objectif d apporter une vision simplifiée des choix techniques retenus pour répondre aux exigences fonctionnelles. En d autres termes, cette zone va permettre de définir les différentes composantes mises en œuvre pour parvenir à recréer l environnement des utilisateurs dans le logiciel. Cette définition comprend les modèles de données, les processus choisis, les reporting mis en place, les modèles de saisies, le paramétrage L objectif n est pas d aboutir à une définition trop technique mais d apporter un niveau minimum de compréhension du fonctionnement de la solution et de l impact des modifications demandées. Cette branche est initiée par l avant vente lors de la conception de la réponse au cahier des charges pour les sous parties «version» et «définition des composants». En effet, leur étude doit aboutir à la construction virtuelle d une application «type» répondant à l ensemble des besoins identifiés dans la partie «Contexte» et utilisant au maximum les fonctionnalités standards du logiciel. Cette pré-définition sera la base essentielle du chiffrage calculé en Page 128

129 Chapitre 4 Adapter l approche et le dialogue «client» fonction du nombre d éléments standard réutilisables (drapeau vert), du nombre de paramétrages à réaliser (drapeau jaune), du taux de réutilisation possible ou des estimations réalisées par les experts sur les aspects spécifiques (drapeau orange) et sur la complexité du projet. Cette première modélisation, importante lors du lancement de projet, sera réalisée dans la partie «Applications» (Figure 23). La définition issue de l avant vente est logiquement très approximative mais doit permettre une évaluation «grossière» de l ampleur du projet et du niveau de spécificité. A ce niveau du processus, c'est-à-dire en amont du projet, l intérêt de la mise en place d une carte heuristique repose sur son mode même de construction, nécessitant une exploration systématique évitant théoriquement les omissions. Pour parfaire la réponse technique et financière, il est important que le document d étude résultant fasse partie de la réponse afin de clarifier le cadre fonctionnel pris en compte dans la réponse, la solution envisagée et le niveau de spécificité de leur future application (le coût de la maintenance étant généralement proportionnelle à la spécificité de l application). Sa diffusion a pour objectif de partager une référence commune entre l éditeur et le client de la solution proposée et de constituer la base de la réunion de lancement de projet. Lors du projet, après avoir validé l ensemble du «Contexte», l étude des solutions techniques et pratiques est réalisée pour mettre à jour la partie «Applications». Avant d organiser l application future du client, il est nécessaire de définir chacune de ces composantes. Parmi les solutions techniques, une partie sera à établir avec le client (le modèle de données, les mises en page, les modèles de saisies, etc.), l autre avec les développeurs (processus, paramétrages) avant la validation globale par le client. La forme de la définition est fonction des possibilités du logiciel employé pour concevoir la carte, mais également en fonction du logiciel à déployer. Dans le cadre de l application LASCOM AEC et de l utilisation de MindManager, nous proposons par exemple d utiliser des tableaux pour définir les propriétés de chaque type d objet, d associer les fichiers de paramétrages, etc. (Figure 24). Page 129

130 Chapitre 4 Adapter l approche et le dialogue «client» Figure 23. La définition succincte de l application vue par l avant vente Page 130

131 Chapitre 4 Adapter l approche et le dialogue «client» Figure 24. Élaboration partielle de la définition de l application L utilisation de la map ne doit pas être perçue comme un inconvénient pour les chefs de projet mais comme une aide réelle. Dans le schéma proposé nous utilisons les tableaux ce qui permet aux acteurs de continuer à utiliser un tableur familier (Excel par exemple). Il est nécessaire d opter pour des solutions simples ne nécessitant pas de compliquer le travail et ne supprimant pas les outils usuels efficaces. Dans cette partie de la map, les fonctionnalités, les Page 131

132 Chapitre 4 Adapter l approche et le dialogue «client» processus, les rapports sont également à traiter. Pour ces points relativement standards, la carte sert surtout de check-list des actions à mener pour garantir un bon fonctionnement. Ce listing permet de sensibiliser le client sur les impacts de ses demandes mais également d apporter une aide supplémentaire pour les futurs administrateurs de l application. Figure 25. Structure de l organisation de l application Une fois chacun des composants définis, il est possible de construire l application, de définir l ergonomie et le comportement de l application dans les différents cas. Autrement dit, les fonctionnalités par type d objet, les contenus des listes, la visibilité des documents, les droits. Dans tous les cas, l entrée de la définition est le document car cela correspond à une logique plus naturelle pour les entreprises. Ceci permet d aboutir plus efficacement à la définition des comportements souhaités, des différents droits et profils. Ce travail sera réalisé dans la sous section «organisation» en respectant le plus possible la philosophie du logiciel. Dans le cas du logiciel LASCOM AEC nous retrouverons par exemple comme structure les différents onglets et avec les différentes données présentées en dessous (Figure 25). Page 132

133 Chapitre 4 Adapter l approche et le dialogue «client» 4 Synthèse Dans notre proposition, la carte heuristique qui doit constituer le support du projet joue le rôle de moteur de la réflexion et de la communication. Sa simplicité permet d agencer de nombreuses informations sur un même support ce qui donne finalement une vision synthétique de la vie de l application, compréhensible par tous et modifiable par tous. La navigation dans la map permet de comprendre les différentes étapes de la conception et les liens existants entre elles. Elle aide aussi à comprendre les tenants et les aboutissants du paramétrage de la solution décidée avec le client et à se repérer dans l application par rapport au descriptif réalisé lors d une demande d intervention. Au niveau de la communication elle tend à homogénéiser la sémantique du fait qu il est simple d employer le même vocabulaire que le client. Dans le cadre de la gestion de projet, cette carte heuristique présente de nombreux avantages pour chacun des acteurs du processus mais également pour le client. Pour les acteurs internes, l utilisation d un unique formalisme permet un gain de temps considérable tout en augmentant leur efficacité. D un point de vue client, le suivi de projet est facilité, sa participation est accrue et de surcroît mise en valeur et la solution résultante répond pleinement à ses attentes sans pour autant augmenter la durée du projet. Au fil du temps et grâce à l accessibilité et la facilité d emploi, il est semble envisageable lors d évolution de déporter en partie l analyse au client, ce qui permet à l éditeur de rester centré sur son savoir faire et au client de faire des économies (chiffrage plus précis et projet plus court). Pour parvenir à une méthode efficace, il est important de définir une structure de carte centrée sur le client représentant les grandes étapes répétitives du cycle de vie de son logiciel, afin de s inscrire dans la boucle d amélioration continue de l entreprise et de conserver une dynamique de résultat. Dans le cadre d un projet, l utilisation de la map offre une nouvelle dimension à la définition de l application et à la communication avec le client : une structure et une organisation dynamiques et «immédiates» qui reprennent sur un seul document très visuel l ensemble des informations ce qui est un atout vis-à-vis des différents prototypes présentés jusque là d une réunion à l autre. L autre intérêt de la map réside dans le fait qu elle est conçue conjointement avec le client ce qui a pour effet de lui faire percevoir et assimiler la philosophie du logiciel. Il lui semblera plus naturel et plus facile de justifier certains choix, car il aura participé pro-activement à sa réalisation et s appropriera d autant plus la solution. Page 133

134 Chapitre 4 Adapter l approche et le dialogue «client» Le dernier intérêt réside dans la dynamique de la réflexion. Les modifications sont visibles immédiatement et dans la méthode heuristique, les oublies sont normalement maitrisés. Pour accompagner et impliquer encore un peu plus le client lors de la construction de la map et pour finalement replacer le client et en particulier les futurs utilisateurs au centre de nos préoccupations nous proposons dans le chapitre suivant une démarche complémentaire de la map pour faire émerger des spécifications directement par le client. Notre objectif est ici de responsabiliser encore un peu plus de client dans l analyse et de faire en sorte que l éditeur reste centré sur son savoir faire pour offrir une meilleure qualité de service. Page 134

135 Chapitre 5 Analyse centrée sur les acteurs Chapitre 5 Une analyse centrée sur les futurs utilisateurs 1 Introduction L étape de spécification constitue l étape décisive du processus de déploiement et son déroulement conditionnera non seulement le processus mais également la place de l application au sein de l entreprise. Tout l enjeu de cette étape est de définir un modèle le plus précis possible de ce que souhaite le client sur le contour prédéfini. Pour se faire, différentes réunions et échanges sont généralement mis en place pour recueillir les informations auprès des acteurs censés posséder les connaissances, les analyser et constituer la base de travail commune pour créer l application. Ces éléments sont ensuite interprétés à travers des outils méthodologiques pour finalement transparaitre dans l application finale. Cette étape doit permettre : d appréhender le projet dans sa globalité, de définir le champ d action, les fonctionnalités, les aspects techniques, les spécificités, les processus, d anticiper les besoins et ce avec une granularité allant jusqu à l utilisateur final. Comme une solution logicielle performante et pertinente est inutile si les acteurs ne l utilisent pas faute de satisfaction il est primordial que les utilisateurs finaux restent, suite à l informatisation, les acteurs principaux du processus, ce seront eux les «moteurs» de l application. Pour être au plus près des besoins réels des futurs utilisateurs et être cohérent avec la réalité du terrain, il est important de compléter l étude du niveau globale (de l entreprise) avec une étude au niveau local (des acteurs). Comme pour la modélisation de la structure et de l organisation de l entreprise, notre proposition consiste à utiliser une méthodologie et des formalismes privilégiant la communication et aidant à une compréhension rapide des problématiques. L expérience acquise par LASCOM montre que les interviews menées chez le client apportent des informations très importantes tant pour LASCOM pour définir une solution aux plus près des besoins que pour l entreprise cliente pour capter les besoins et identifier les difficultés. Elles constituent une photographie de l entreprise assez réelle en fonction du nombre de participants. La problématique réside dans le temps nécessaire pour les mettre en œuvre dans de bonnes conditions et obtenir des résultants probants. La section présente la méthode pour obtenir des personas que nous avons identifiée comme étant un levier nous permettant de lever les verrous que nous avons mis en évidence. Page 135

136 Chapitre 5 Analyse centrée sur les acteurs 2 Persona : une approche au plus près des utilisateurs finaux 2.1 Contexte et approche théorique Dans le processus de conception de l application, le problème se pose, de nouveau, en termes de coût et de délais. Aujourd hui, il n est jamais ou presque jamais prévu d impliquer les utilisateurs dans le cadre de la définition du logiciel pour des raisons économiques (ces personnes sont souvent jugées comme plus utiles à leurs postes qu en réunion). En général les utilisateurs sont interrogés en amont pour définir ou valider certains points du cahier des charges mais ils le sont rarement lors des spécifications, à part ponctuellement pour approfondir un point à travers leur supérieur hiérarchique ou le responsable du projet. Mais ces interventions ponctuelles sont souvent compliquées car menée rapidement et sans un réel support visuel de l avancement de la définition et ce qui a pour effet de tronquer certains éléments du contexte d utilisation. L utilisateur ne sait donc pas quelle est la démarche suivie mais surtout les éléments déjà pris en compte ou pas. Le but étant souvent d avantage de valider la vision que l éditeur et/ou le responsable de projet a plutôt que de comprendre le mode de fonctionnement réel et les besoins associés, pourtant primordiaux pour l utilisateur. De plus, ces aspects sont gérés en interne, entrainant la multiplication des interprétations : l utilisateur comprend d une certaine manière la question avec ou sans contexte, et formalise sa réponse, qui est réinterprété par la personne qui lui a posé la question, pour refournir l information à l éditeur/intégrateur au niveau méthodologique, puis au niveau de l outil. Le nombre croissant d interprétations et d interlocuteurs génère généralement un nombre d itérations important (pour revalider en interne, pour des problèmes d incompréhension ) engendrant une perte de la finesse et de la justesse dans la définition tant fonctionnelle que technique par manque de temps. Finalement, ce mode de fonctionnement initialement censé accroître l efficacité de la définition des besoins en limitant le nombre d interlocuteurs pour l éditeur/intégrateur, joue souvent en défaveur de sa qualité engendrant l inadéquation partielle de l application finale avec les besoins réels des futurs utilisateurs et la non acceptation du logiciel. Autrement dit, plus la définition des besoins est réalisée loin des utilisateurs, plus la compréhension du système est partielle et plus l application s éloignera des besoins des utilisateurs et plus la résistance au changement sera forte. Il nous faut donc identifier une méthodologie ou un formalise proposant une meilleure projection dans l application pour l ensemble des intervenants tout en sachant que nous aurons déjà à notre disposition une représentation heuristique du système. Nous connaitrons donc à minima les Page 136

137 Chapitre 5 Analyse centrée sur les acteurs acteurs et leurs besoins, la méthode devant être un support à la mise en évidence de l utilisation qu ils feront de l application. Depuis quelques temps en ergonomie web, pour concevoir des interfaces plus adaptées, des nouveaux supports issus du monde du théâtre sont apparus : les PERSONAS (Annexe 4). Un «persona» est un archétype des futurs utilisateurs listant leurs besoins et leurs habitudes supposés. Ce profil utilisateur créé de toutes pièces en fonction de données prospectives, représentatif de la cible ergonomique d'un site web, a pour but de «théâtraliser» l utilisation. C'est donc une personne «virtuelle» qui va servir de référent à toute l'équipe de conception pour considérer les exigences utilisateur à travers la description d un utilisateur et de l utilisation qu il fera de l application. C est ainsi un site adapté à ses besoins qui sera conçu facilitant l accès aux fonctionnalités les plus usitées par exemple. Ce support permet une meilleure projection des besoins et des contraintes des futurs utilisateurs dans la conception de l application pour l ensemble des intervenants en développant leur imaginaire. La méthode de conception des personas présuppose de connaitre a minima la cible, en se basant sur des données tangibles issues de sondages ethnographiques, sociologiques et psychologiques [Brangier, 10], et/ou d imaginer ses besoins et l utilisation qui sera faite du site ou de l application. Elle est rapide à concevoir, à mettre en œuvre et son support de diffusion est relativement accessible. Notre proposition est donc d adapter et construire une démarche d utilisation de cette méthode dans le cadre du déploiement des solutions LASCOM. Pour ce faire nous allons créer des questionnaires à destination des acteurs pour isoler des personas «réels» définissant les besoins fonctionnels et techniques. Le but est de créer des personas en fonction des besoins et des retours d expériences des acteurs et non pas d imaginer le comportement des futurs utilisateurs. Ceci pour déterminer les besoins réels des utilisateurs pour valider les exigences retenues (issues du cahier des charges et de l analyse des besoins) et s assurer de la prise en compte de l ensemble des besoins «pratiques» afin de maximiser la pertinence du logiciel tout en intégrant les utilisateurs au projet d informatisation. L objectif n étant pas de prendre en compte toutes les requêtes mais d identifier les situations non traitées, les oublies et les manques, les évolutions potentielles. Page 137

138 Chapitre 5 Analyse centrée sur les acteurs 2.2 De la map à persona : de l entreprise à l acteur Etape préliminaire : comment et quand établir les questionnaires? Jusqu à présent, les éditeurs arrivaient à se différencier sur le marché grâce au rapport coût / nombre de fonctionnalités, longtemps considéré comme un indicateur d innovation. Le centrage acteur était alors perçu comme une contrainte souvent secondaire par les éditeurs lors de la conception de leur application au regard des contraintes techniques et technologiques pour fournir toujours plus de fonctionnalités. Mais aujourd hui avec l essor du nombre d applications, aux critères de choix précédents s ajoutent l ergonomie. La prise en compte de ce nouveau facteur impose aux éditeurs de ne plus considérer les utilisateurs uniquement comme des simples profils informatiques (classiquement pour un utilisateur : qu a-t-il le droit de voir? qu a-t-il le droit de faire? sous quelles conditions?), mais comme un ensemble de scénarii d utilisation à faciliter. Classiquement LASCOM procédait par interviews successives des intervenants directs pour faire émerger des grands profils informatiques d utilisateurs parfois assez éloignés de la réalité du terrain. Ces intervenants directs du projet n étaient en général pas les utilisateurs finaux et LASCOM ne faisait pas d interviews des utilisateurs mais bien uniquement des personnes présentes aux réunions et missionnées par le client. Un profil pour LASCOM était donc vu au sens «administration d un logiciel» : que peut voir la personne, quelles actions a- t-elle le droit de faire sur ces éléments et sous quelles conditions? Dans notre proposition nous allons chercher à conserver un peu cette façon de travailler qui a fait ses preuves mais en allant beaucoup plus dans la définition des profils réels et en évitant le biais des interviews (questions orientées par l éditeur hors du contexte) pour être plus en phase avec les utilisateurs. Les questionnaires que nous devons établir contribueront à la définition des actions menées par chacun, c'est-à-dire que pour chaque action les acteurs auront à répondre aux questions qui, quoi, comment et quand. Pour ne pas entrer dans les travers des interviews tout en conservant leur pertinence, nous avons décidé d opter pour des questionnaires informatisés (ici Excel pour faciliter les traitements), limités en taille pour ne pas immobiliser le personnel trop longtemps, et diffusés à des moments clés assez fréquents pour affiner le questionnement et accroître la communication. Les questionnaires seront composés de deux parties : une partie questionnement (QX) basée sur les informations recensées dans le cahier des charges directement ou indirectement à travers la map, et une partie résultat (QX-1) présentant les informations validées traitées dans le questionnaire précédent. A ce stade de la définition il apparait important de dissocier deux phases dans le questionnement Page 138

139 Chapitre 5 Analyse centrée sur les acteurs correspondant aux deux grandes phases du cycle de vie du logiciel durant lesquelles les utilisateurs représentent les meilleures sources de retours d expérience : durant l analyse des besoins et durant l exploitation, car le questionnement n aura pas les mêmes objectifs. Durant la phase d analyse des besoins, le rythme d envoi ainsi que le contenu du questionnaire doivent idéalement être en phase avec les différentes réunions d analyse et de spécifications que ce soit pour la conception du cahier des charges ou la conception de l application. L intérêt étant d avoir les résultats de chacun des «sondages» au moment de la réunion afin qu ils puissent être une source d exploration ou de validation au même titre que les participants présents. Ainsi, il sera plus aisé pour chacun des intervenants de comprendre et d assimiler les besoins réels, et de trouver la formulation du besoin et/ou la solution adéquate. En effet, lorsque l exigence est formulée sous forme «tous les vendredis, Léo doit imprimer et envoyer la liste des plans posant problèmes pour la réunion de suivis hebdomadaire» la réflexion et l exploration des solutions ne seront pas les mêmes que lorsqu elle est sous forme «Exporter la liste des plans» qui correspond au besoin générique émis initialement dans le cahier des charges. Pourtant l exigence est bien la même «Exporter la liste des plans» mais, grâce à la scénarisation, des détails contextuels sont apparues sur la fréquence de réalisation, sur la condition de recherche et sur le but. Dans le cas de l exigence générique, la réflexion ne sera pas poussée et la réponse sera d utiliser la fonction standard d export, mais dans ce cas Léo risque d avoir des difficultés toutes les semaines pour fournir cette liste. Alors que dans le second cas, la question se posera de savoir comment identifie-ton les «plans posant problèmes» (faut il ajouter une propriété? Est-ce l état du document qui nous donne l information ou est-ce le nombre de versions?) et à qui doit-t-on envoyer cette liste (peut-on créer un groupe fixe?) pour pouvoir utiliser la fonction standard d abonnement qui permet d envoyer une liste respectant certaines conditions à une fréquence donné. Autrement dit, sans exemple concret, sans aller au bout du raisonnement, seule l exigence générique aurait certainement été traitée et la question de l identification d une condition particulière pour repérer des difficultés n aurait pas été abordée, de même que l automatisation de cette tache jugée «particulière» pour les personnes ayant rédigés le cahier des charges et qui pourtant peut être générique également. La création de ces personas a un double intérêt : replacer l utilisateur au centre des spécifications en tant qu animateur de besoins puis en tant que «valideur» de profil au sens informatique, mais également de faciliter la communication tant au sein de l équipe de création (de la réflexion en passant par le développement voire même la documentation), qu au sein de l entreprise. En effet, il est souvent plus facile de communiquer et de se comprendre sur des exemples concrets, que sur Page 139

140 Chapitre 5 Analyse centrée sur les acteurs des exemples abstraits emprunts aux malentendus. Plus la phase de conception avancera, plus le questionnaire s orientera sur la définition des profils des utilisateurs interrogés pour aboutir à circonscrire leur espace d action et d interaction définissant ainsi les profils relatifs à la branche organisation de la carte heuristique du projet dans la section contexte (Figure 26). Ces personas constitueront la base de référence pour définir les différents types d utilisateur de l application, utile pour lister les besoins concrets, imager la réalisation ou la modification de l administration du logiciel, mais également pour faciliter l expression de nouveau besoin, et finalement concevoir une application au plus près des besoins des utilisateurs. Pour favoriser la participation, il est important que les utilisateurs soient également informés des résultats afin de prouver la prise en compte de leur réponse et qu ils s approprient petit à petit les éléments qui seront contenus dans leur application. Finalement, l utilisation du sondage des utilisateurs durant la phase de conception, apporte au fur et à mesure de la définition la confrontation de la vision globale («qu est ce qui est fait par qui» utilisé durant les réunions) à la vision local («qui fait quoi»), dessine et affine la définition des personas par regroupement d information, et participe aussi à l intégration des utilisateurs à la conception. L utilisation des questionnaires pourrait s arrêter à la fin de la conception puisque l application et les personas types sont définis, mais le risque demeure que les utilisateurs impliqués dans cette dynamique de questionnement se retrouvent frustrés de ne plus avoir de moyen de s exprimer au moment même où enfin ils voient et utilisent le «résultat» des différents sondages : le logiciel et où ils se retrouvent au cœur du système. Le déploiement est un moment tout aussi stratégique, il serait aberrant de couper la communication à cet instant précis et même par la suite. Ainsi, durant la phase d exploitation, les questionnaires devront toujours être présents. Ils seront moins fréquents et essentiellement axés sur les difficultés rencontrées lors de l utilisation de l application et les améliorations que les utilisateurs souhaiteraient voir apparaitre. Un rythme assez soutenu sera malgré tout conservé au début de chaque phase de déploiement pour détecter les difficultés voire les blocages potentiels des utilisateurs. Ce tempo aura ensuite tendance à ralentir. Idéalement, il serait pertinent que les utilisateurs puissent eux même demander un questionnaire de satisfaction à tout moment afin de s exprimer sur le logiciel quand ils le souhaitent (dès qu ils rencontrent une difficulté par exemple). S ils doivent attendre un jalon bien précis pour réagir sur l application, ils auront certainement oubliés les soucis rencontrés ou n auront peut être pas le temps de remplir le questionnaire correctement si ce jalon «tombe mal». L objectif de cette base de retours d expériences est de voir comment pallier aux difficultés (demander une correction de bug, Page 140

141 Chapitre 5 Analyse centrée sur les acteurs réaliser une formation complémentaire, diffuser des supports adaptés aux problèmes relevés, etc.) mais également d identifier et de prioriser les évolutions à prévoir. Figure 26. Persona ou la définition de l organisation dans la map projet Page 141

142 Chapitre 5 Analyse centrée sur les acteurs L utilisation des questionnaires pourrait s arrêter à la fin de la conception puisque l application et les personas types sont définis, mais le risque demeure que les utilisateurs impliqués dans cette dynamique de questionnement se retrouvent frustrés de ne plus avoir de moyen de s exprimer au moment même où enfin ils voient et utilisent le «résultat» des différents sondages : le logiciel et où ils se retrouvent au cœur du système. Le déploiement est un moment tout aussi stratégique, il serait aberrant de couper la communication à cet instant précis et même par la suite. Ainsi, durant la phase d exploitation, les questionnaires devront toujours être présents. Ils seront moins fréquents et essentiellement axés sur les difficultés rencontrées lors de l utilisation de l application et les améliorations que les utilisateurs souhaiteraient voir apparaitre. Un rythme assez soutenu sera malgré tout conservé au début de chaque phase de déploiement pour détecter les difficultés voire les blocages potentiels des utilisateurs. Ce tempo aura ensuite tendance à ralentir. Idéalement, il serait pertinent que les utilisateurs puissent eux même demander un questionnaire de satisfaction à tout moment afin de s exprimer sur le logiciel quand ils le souhaitent (dès qu ils rencontrent une difficulté par exemple). S ils doivent attendre un jalon bien précis pour réagir sur l application, ils auront certainement oubliés les soucis rencontrés ou n auront peut être pas le temps de remplir le questionnaire correctement si ce jalon «tombe mal». L objectif de cette base de retours d expériences est de voir comment pallier aux difficultés (demander une correction de bug, réaliser une formation complémentaire, diffuser des supports adaptés aux problèmes relevés, etc.) mais également d identifier et de prioriser les évolutions à prévoir. La diffusion de notre questionnaire suit donc le cycle de vie du logiciel (Chapitre 3, Figure 10), allant d une démarche de modélisation à une enquête de satisfaction, l importance étant de rester concentrer sur les acteurs, moteur de la performance. Les avantages sont d un point de vue logiciel d apporter une vision plus proche de la réalité au moment de la définition de l application pour l adapter aux utilisateurs et d un point de vue humain, de diminuer la réticence aux changements en rendant les utilisateurs actifs et participatifs au plus tôt dans le processus sans les immobiliser trop longuement Mise en place des questionnaires durant la phase d analyse des besoins Durant la phase d analyse des besoins, l objectif des questionnaires est de déterminer les besoins et les difficultés actuels des utilisateurs, sur le contour prédéfini d impact du logiciel, pour isoler les personas réels, bases de la conception de l application. Pour parvenir à ce résultat, nous avons établie trois étapes minimum étaient nécessaires : Page 142

143 Chapitre 5 Analyse centrée sur les acteurs - Lister les éléments manipulés, - Lister les manipulations effectuées et définir ces manipulations, - Présentation du résultat, c'est-à-dire les personas résultant. Pour mener à bien ces étapes, nous avons établis quatre modèles de questionnaires. Le premier questionnaire sera envoyé à l issue du lancement de projet afin d obtenir des éléments qui aideront à débuter l analyse plus précise du besoin. L initialisation du questionnaire sera donc réalisée sur la seule base disponible à ce moment du processus, c'est-à-dire la première définition des besoins vue par l avant vente et décrite dans la map. Les éléments présents dans la map sont primordiaux car ils structureront certaines parties du questionnaire. L utilisateur sera seul devant le fichier Excel «questionnaire» et si aucun élément de réponse issu de la map n est proposé (sous forme de liste par exemple) il existe un risque non négligeable de n obtenir aucun résultat car sans guide et sans dynamique l utilisateur ne sera pas enclin à explorer ses expériences et ses connaissances pour compléter le questionnaire. Même si comme nous l avons vu cette définition est souvent «grossière», elle fait tout de même apparaitre un certain nombre de documents et de fonctionnalités exploitables dans le questionnaire. La première version du questionnaire aura pour but d expliquer le projet et plus particulièrement le cadre de cette démarche de questionnement et d identifier tous les types de documents manipulés par les utilisateurs. L expérience de LASCOM montre que cette entrée est souvent plus naturelle pour les utilisateurs dans la cadre d une modélisation «ascendante». Dans le questionnaire Q1, les utilisateurs pourront choisir les documents qu ils manipulent dans la liste pré-initialisée et/ou en ajouter dans la colonne prévue à cet effet. De plus, afin de débuter la caractérisation de ces documents, ils devront également choisir leur provenance et leur fréquence d utilisation (Figure 27). Ce «sondage» peut être envoyé à un grand nombre de personnes car il a le mérite d expliquer dans l introduction la mise en place du projet. D un point de vue pratique un grand nombre de retours ne posera pas de problème puisque le traitement des réponses sera automatique. Page 143

144 Chapitre 5 Analyse centrée sur les acteurs Figure 27. Les documents manipulés vus par les utilisateurs La largesse de ce premier sondage ne permet pas de s assurer que les documents listés constituent réellement une liste finie de documents. Elle correspond plutôt à une liste usuelle pour l utilisateur dont la dénomination correspond à la sémantique du client. Cette liste sera confrontée aux résultats obtenus lors des réunions d analyse afin de valider ou compléter la carte heuristique (Figure 28) et aboutir à la constitution d une liste finie de documents catégorisés, à traiter, à cet instant du processus, dans le cadre du logiciel. Une fois cette liste déterminée, l objectif du second questionnaire sera de cadrer l utilisation (quelle manipulation est réalisée et sur quel document) réalisée par les utilisateurs de ces éléments, et ce par profil. Pour cela, le questionnaire Q2 sera envoyé à certains utilisateurs prédéterminés par le client, utilisateurs représentatifs d un panel pour chaque profil prédéterminé. La constitution du panel pourra évoluer en fonction de l avancée de l analyse et des retours. Ce questionnaire sera cette fois nominatif et présentera une partie du choix finie (la liste complète des documents) et une partie libre (les actions réalisées). C'est-àdire que la pré-initialisation sera basée sur les résultats des premières réunions d analyse du besoin et non pas sur les résultats du premier questionnaire pour que les utilisateurs explorent de nouvelles possibilités. Le travail demandé sera simplement de sélectionner le niveau de difficulté rencontré aujourd hui pour réaliser les actions que les utilisateurs mènent relativement aux documents (Figure 29). Page 144

145 Chapitre 5 Analyse centrée sur les acteurs Figure 28. Les questionnaires sources de la typologie des documents Page 145

146 Chapitre 5 Analyse centrée sur les acteurs Figure 29. L utilisation vue par les utilisateurs Page 146

147 Chapitre 5 Analyse centrée sur les acteurs Selon la taille de la liste de documents, il est tout à fait possible de scinder ce questionnement en plusieurs étapes, l objectif étant que le temps nécessaire pour répondre n excède pas 10 min. Par contre il est essentiel que dès le premier envoi d un questionnaire Q2, la liste finie de document avec sa description soit présentée dans l onglet de résultat afin de valoriser le travail commun et débuter l appropriation du contenu de la future application (Figure 30). Pour faciliter la compréhension des utilisateurs et les sensibiliser aux choix effectués, il est important de décrire le contenu de chacune des catégories génériques retenues avec les différents termes usités par les utilisateurs dans le premier questionnaire. Figure 30. Communiquer sur l aboutissement du travail commun Page 147

148 Chapitre 5 Analyse centrée sur les acteurs Les résultats de Q2 seront utilisés dans un premier temps et comme précédemment en réunion d analyse pour valider ou agrémenter la liste des actions possibles par type de document pour correspondre au plus juste aux besoins et à la sémantique client. La fréquence et le niveau de difficulté donneront un éclairage supplémentaire sur l importance de l informatisation de la fonctionnalité et de l intégration de certains types de documents pour faciliter accessibilité par exemple. Les premiers objectifs étant d établir une liste finie des actions compréhensibles par les utilisateurs qui sera présentée dans le questionnaire suivant (Figure 31) et de valider la liste des différents types de documents à intégrer dans la future application. Figure 31. Communiquer sur les listes établies Page 148

149 Chapitre 5 Analyse centrée sur les acteurs Une fois la liste des actions finie, le traitement des réponses doit être reconsidéré mais cette fois en fonction des profils présupposés en vue de la construction des personas. Grâce à son caractère nominatif, le questionnaire Q2 permettra de réaliser l analyse des résultats pour valider la cohérence des profils tant sur leur constitution (les personnes) que sur leur construction (les documents manipulés et les manipulations). Une grille d utilisation de l application par profil, correspondant au profil informatique, sera alors établie et présentée dans le prochain questionnaire, le Q3 (Figure 32). Figure 32. La grille d utilisation de l application Page 149

150 Chapitre 5 Analyse centrée sur les acteurs A partir des résultats par profil, revus en fonction des analyses, un nouveau questionnaire Q3 sera constitué pour affiner les personas, avec cette fois comme éléments finis la liste des documents et celle des actions. Les utilisateurs auront à renseigner une description d utilisation pour situer et contextualiser leurs interactions, caractériser leur besoin et valider la compréhension de la liste des actions uniformisée (Figure 33). Le but est de personnifier les profils en illustrant des cas d utilisation et de revalider la constitution des profils, des fonctionnalités et des documents associés à celui ci. Pour ce faire, les fonctionnalités seront organisées en deux groupes, celles détectées comme faisant partie du profil et celles n en faisant pas partie. Il en sera de même pour les documents. Pour faciliter la saisie, les cellules qui ne sont logiquement pas à renseigner, sont hachurées mais l utilisateur peut malgré tout les remplir si effectivement cela correspond à son besoin. Le but n est pas de restreindre les fonctionnalités et les documents possibles mais bien de valider «définitivement» son cadre d utilisation d où la nécessité de pouvoir compléter encore le document pour ne rien omettre. Les résultats permettront dans un premier temps de valider définitivement les profils informatiquement parlant, grâce au remplissage des espaces hachurés ou pas mais également les libellés des catégorisations des documents et des actions grâce à la phrase descriptive et à la sémantique employée. Dans un second temps, les réponses permettront de créer des personas «réels» pour personnifier et scénariser les besoins dans le but de mieux les appréhender, et ce pour toutes les personnes travaillant sur le projet. En fonction des descriptions apportées pour les cas d utilisation non prévus ou peu fréquents, soit le profil sera révisé, soit une étude plus précise pourra être réalisée individuellement pour comprendre comment et pourquoi ces personnes interviennent dans le processus. A partir de ce niveau d avancement du processus, c'est-à-dire à la fin de la définition du contexte, les utilisateurs ne seront plus questionnés aussi régulièrement et de manière aussi pointue car pour la suite - c'est-à-dire la définition de l application-, les retours d expériences terrain n apporteront plus autant de valeur ajoutée. Pour réaliser ce basculement et étant donné qu il est important de montrer la contribution de Q3 sur l évolution de la définition des profils, il est tout à fait envisageable de lancer un dernier sondage (Q4) pour présenter le persona répondant à l utilisateur et dont l objectif est de lui définir un nom par exemple. L objectif de présenter son persona, relatif à l application, à l utilisateur est qu il puisse s identifier à lui, d une part grâce à la description textuelle d un exemple d action réalisable dans l application, le scénario, d autre part d assimiler le vocabulaire de l application en mettant en perspective la Page 150

151 Chapitre 5 Analyse centrée sur les acteurs description avec les libellés de l application (les lignes et les colonnes) (Figure 34). Cet archétype définit le cadre fonctionnel d utilisation et l illustre. Figure 33. Personnifier l utilisation Page 151

152 Chapitre 5 Analyse centrée sur les acteurs Figure 34. Présenter le persona de l utilisateur Page 152

153 Chapitre 5 Analyse centrée sur les acteurs Durant la suite du processus de définition de l application il est tout à fait possible de continuer à réaliser des petits sondages permettant de définir des petits points ergonomiques (sur le visuel, des couleurs, des icones, etc.) ou sur des aspects plus fonctionnels (le choix des messages, les successions d actions, les critères de recherche, etc.). Le but est d entretenir un bon niveau de communication sur l avancée du projet par le fait de conserver une forte participation d un grand nombre d utilisateurs à la conception de leur future application. La succession des questionnaires offre une connaissance précise et réaliste des besoins des utilisateurs et du fonctionnement de l entreprise à un niveau très opérationnel. Le questionnement direct permet d approcher un peu plus les besoins des utilisateurs lors de la phase de conception de l application, tout en limitant la réticence au changement et en rendant chacun des utilisateurs acteur de la définition du contexte. En effet, chacune des contributions apporte des éléments d exploration pour compléter la carte heuristique du contexte, contribue à définir la sémantique à employer, définie des personas pour personnifier les besoins. Les questionnaires quant à eux contribuent à la communication sur le projet et fournissent des explications sur les termes employés dans la future application en mettant en perspective le contexte de l application avec un exemple d utilisation exprimé avec la sémantique usuelle. Aucun des questionnaires présentés n étant lié directement au choix de l application à mettre en place, toutes les étapes relatives à la saisie des informations peuvent être réalisées en amont par le client soit pour établir le cahier des charges, soit pour préparer le projet d informatisation. L un des intérêts de réaliser les questionnaires très en amont réside dans le fait que cette enquête aiderait le client à clarifier et délimiter ses besoins à moindre coût, sans avoir recourt à un consultant et sans immobiliser durablement les acteurs. Cette démarche rendrait aussi la conception du cahier des charges «client» plus simple et plus précise, ce qui aurait pour effet de limiter les «mauvaises surprises» tout au long du projet et en particulier lors des chiffrages Mise en place des questionnaires durant la phase d exploitation La valeur ajoutée du questionnement des utilisateurs réapparait lors du déploiement de l application c'est-à-dire du démarrage de l utilisation du logiciel par les différents acteurs. En effet, ce sont les utilisateurs qui sont les «moteurs» de l application or s ils rencontrent des difficultés ou des impossibilités à réaliser leur travail correctement à cause de l application, le risque est de voir une recrudescence des mécontentements voire le boycott de l application. Page 153

154 Chapitre 5 Analyse centrée sur les acteurs La communication est donc le point clé de cette phase : il ne faut pas laisser les utilisateurs seuls face à leurs difficultés. Les questionnaires en exploitation peuvent répondre à ce besoin de détection et d identification au plus tôt des difficultés rencontrées, des points bloquants, des manques, etc. LASCOM ainsi que le support interne seront alors en mesure d apporter les réponses adaptées (formation, support, accompagnement ), de solutionner les problèmes mais également d identifier les besoins futurs car ils constituent des problèmes potentiels s ils ne sont pas pris en compte. Le premier questionnaire doit rapidement faire suite au déploiement afin d instituer ce mode de fonctionnement et prévenir les utilisateurs qu ils ne sont pas seuls, qu il existe des moyens de faire remonter leurs problèmes (soit le questionnaire, soit le support interne). Pour pondérer leurs réponses, nous proposons de réaliser deux parties dans les questionnaires de retours d expériences : les difficultés rencontrées et les demandes d amélioration. En effet, autant il est difficile de demander à un utilisateur lambda de mesurer objectivement la criticité de ces problèmes surtout au début, autant il semble envisageable de lui faire dissocier les problèmes rencontrées concrètement dans l application (c'est-à-dire qu il arrive à définir le contexte de son besoin avec les termes de l application) et ce qu il souhaiterait faire (dont le contexte n est pas explicitable facilement avec les éléments présents dans l application). Dans un premier temps, la pertinence de cette décomposition ne sera pas forcément visible mais elle apparaitra lorsque la base évoluera et s enrichira dans le temps, proportionnellement à l appropriation du logiciel par les utilisateurs. Le premier objectif n est pas la qualité des retours mais de continuer la démarche centrée sur l acteur tout en conservant la dynamique et la communication autour du projet. Ceci ne sera possible que si les questionnaires reflètent la démarche de LASCOM et le fait que nous sommes aux cotés des utilisateurs pour surpasser leurs difficultés et pour les aider à utiliser notre solution logicielle. Démarche qui va au-delà de l accompagnement puisque les avis sont pris en compte pour améliorer la solution de telle sorte que les utilisateurs doivent toujours se sentir acteurs de la conception et de l amélioration de «leur» logiciel. Cette démarche d accompagnement/amélioration continue se traduit dans le modèle de questionnaire R1 par : - la présence d un certains nombres de listes pré-paramétrées en cascade qui cernent le contexte du problème et d une partie libre pour que l utilisateur exprime ses difficultés (Figure 35), Page 154

155 Chapitre 5 Analyse centrée sur les acteurs - la présence uniquement de la liste des documents pour cibler le contexte de la demande et d une zone libre (Figure 36) pour saisir les améliorations qu il pense envisageables et souhaitables. Figure 35. Les difficultés des utilisateurs Page 155

156 Chapitre 5 Analyse centrée sur les acteurs Figure 36. Les demandes d améliorations des utilisateurs Finalement les deux parties du questionnaire R1 ont le même objectif : limiter la réticence aux changements en donnant la parole à ceux qui doivent nécessairement utiliser le logiciel. Au moment du déploiement, les difficultés liées à la découverte d un nouveau logiciel et à la pertinence de la formation seront nombreuses. Les réponses se traduiront Page 156

157 Chapitre 5 Analyse centrée sur les acteurs souvent par des compléments de formations, de l accompagnement personnalisé, ou création de supports plus simples. Au niveau des demandes d amélioration l expérience montre que dans un premier temps elles correspondent généralement à la modification des profils et des droits. Au fil du temps, les retours d expériences seront de plus en plus pertinents et l identification des problèmes plus précise. Ce type de questionnement doit perdurer tout au long de la vie de la solution même si la fréquence des échanges diminuera au fil du temps, les difficultés et les demandes d amélioration étant de moins en moins nombreuses. Grâce au questionnement des utilisateurs durant l exploitation du logiciel, le niveau d utilisation de l application sera maximisé et l évolution de l application répondra aux attentes réelles de l entreprise. La solution offrira alors un niveau important d adéquation entre les besoins des utilisateurs et les réponses du logiciel. Les retours d expériences des utilisateurs permettent non seulement d inscrire le logiciel dans la boucle d amélioration continue de l entreprise mais également les utilisateurs en tant qu acteur de la qualité. 3 Synthèse : Confrontation des deux approches pour consolider le modèle De nombreuses méthodes pour définir et représenter un système existent mais leur mise en œuvre est souvent longue et coûteuse. Elles permettent d obtenir une cartographie complexe pour apporter à la fois tous les éléments nécessaires à la définition du niveau global jusqu au niveau local mais également au paramétrage de la future application PLM. Le principal inconvénient réside dans le fait que chaque méthode possède son formalisme propre et qu il y a souvent une «surcharge d informations» à représenter et/ou une multiplication des modèles. Ainsi même achevés, les modèles ne constituent pas un bon support de communication transverse pour l entreprise ils apportent rarement une représentation des éléments globaux et locaux sur un même support. Autrement dit un utilisateur lambda éprouvera des difficultés à repérer ses actions et ne peut donc pas facilement et rapidement vérifier les points qui le concernent s il ne connait pas le formalisme ou s il n a pas suivi son élaboration. Il existe de nombreuses méthodes permettant de définir les aspects fonctionnels du produit souhaité, mais la définition d un outil PLM demande également la spécification, toute aussi importante, des aspects techniques et organisationnels qui eux sont moins encadrés car dépendants du logiciel. Pour se rapprocher au plus près des utilisateurs certaines méthodes préconisent de réaliser des interviews pour élaborer par regroupement les visions globales et locales mais aussi les aspects fonctionnels et techniques. Ces approches sont souvent mal perçues par les entreprises et les intégrateurs. Pour les premières, elles jugent souvent trop Page 157

158 Chapitre 5 Analyse centrée sur les acteurs long le temps d immobilisation de leurs personnels (temps de l interview, de la restitution, d échange entre les personnes). Elles ont aussi la certitude que cela n influencera pas de façon majeure le fonctionnel de l application au regard du coût de la mise en place des interviews. Du point de vue des intégrateurs, ils ont du mal à vendre ces prestations, généralement attribuées à des sociétés de conseil, car elles sont longues (temps de conception en fonction du besoin, interviews, consolidation, restitution) tout en sachant que le résultat sera exploitable qu en partie de par la pertinence des réponses et les capacités de l outil. Ces éléments mettent en perspective uniquement la durée et le coût face au résultat technique et tangible alors qu il ne faut pas sous estimer l apport de la communication et de la participation vecteurs important dans la valorisation des personnes et la diminution de la réticence aux changements. Finalement les méthodes proposées dans la littérature sont souvent fastidieuses, onéreuses et présentent quatre inconvénients majeurs : - le mise en évidence des besoins de l entreprise mais aussi sur des besoins de l éditeur quant à la définition et au paramétrage du logiciel est souvent complexe, - la construction d une cartographie décrivant l entreprise est peu évidente et souvent celle-ci est inappropriée de par la complexité de la formalisation pour qu elle soit lisible et compréhensible par tout un chacun. La mise à jour de la cartographie dès que l entreprise évolue pose aussi problème car elle oblige souvent à sa recréation complète, - la mise en œuvre puis la confrontation d une approche de modélisation ascendante et descendante n était pas possible pour des questions de coût et de délais, ce qui pouvait limiter la qualité du modèle. - l implication active des futurs utilisateurs dans le projet dans les temps impartis est quasiment impossible. Cette absence de vision «terrain» conduit souvent à de nombreuses itérations coûteuses entre les étapes de spécifications, de modélisation et les tests en vue de l obtention d un consensus entre le résultat au regard des attentes réelles. Dans notre proposition, l utilisation de la carte heuristique «générique» présentée précédemment permet de pallier en partie aux problèmes de profondeur de l analyse en descendant un peu plus vers le niveau local et de communication grâce à l élargissement potentiellement du champ des utilisateurs participant à l analyse des besoins, voire à la conception de l outil. Cependant cette solution ne répond pas pleinement aux difficultés rencontrées en termes d intégration systématique et de participation active des utilisateurs Page 158

159 Chapitre 5 Analyse centrée sur les acteurs finaux car elle ne lève pas le verrou de la durée de l immobilisation d un grand nombre de salariés. Pour pallier à cet inconvénient nous avons proposé d utiliser une méthode complémentaire telle que persona pour interroger et impliquer les utilisateurs de façon directe et autonome. Ils seront ainsi partie prenant du projet tout au long du processus de déploiement voire au cycle de vie complet du logiciel. Mise en commun, ces deux outils permettent de lever les verrous liés aux délais et à la communication, en se basant sur une démarche et des supports simples à réaliser et à comprendre. Le but est ici d obtenir non pas une modélisation précise de l entreprise mais une modélisation suffisante à l implémentation d un logiciel informatique c'est-à-dire pour appréhender plus efficacement le contexte et les besoins. Ces supports sont complémentaires et nécessitent de peu temps d adaptation offrant la capacité d élargir le nombre de participants pour chacune des étapes du processus. Or plus le nombre de participants est important, plus nous diminuons le risque d omettre des aspects du fonctionnement de l entreprise et plus le logiciel correspondra pleinement à l entreprise. La mise en place de retour d expérience permet de surcroit de pérenniser ce fonctionnement à long terme. Nous aboutissons donc à deux supports simples à comprendre et à mettre à jour : un support pour suivre le cycle de vie du logiciel, la carte heuristique, et un support pour évaluer l utilisation et les améliorations, les personas. Cette association améliore le processus, le logiciel, et surtout apporte une meilleur visibilité et une meilleure communication. Au-delà des avantages liés à la mise en parallèle de ces deux outils, il est intéressant de noter que ces outils présentent aussi de nombreux avantages individuellement tant pour faciliter le déroulement du processus de déploiement, que pour améliorer la qualité du logiciel et de la communication. Ils peuvent aisément être utilisés indépendamment l un de l autre pour améliorer la perception d une situation précise en fonction du contexte et du besoin. La carte heuristique permet d obtenir un support unique pour suivre le cycle de vie du logiciel et sa construction repose sur l approche descendante, tandis que le persona illustre le rôle tenu par les utilisateurs dans un environnement plus ou moins précis en se basant sur une approche ascendante. Cependant c est l association des deux supports qui nous intéresse ici car elle offre une dimension de complémentarité des approches grâce à la double exploration du système et à une confrontation facilitée sur un même support (Figure 37). La valeur ajoutée de l interaction entre les deux se situe essentiellement sur l analyse des besoins et sur l analyse du résultat (le logiciel). Page 159

160 Chapitre 5 Analyse centrée sur les acteurs Figure 37. Apport de persona au contexte de la carte heuristique Page 160

161 Chapitre 5 Analyse centrée sur les acteurs Ces deux supports doivent vivre avec le logiciel, pour être en phase avec l entreprise, identifier les évolutions et les modifications dès leur émergence et donc éviter que le système ne soit bloqué. Ceci nécessite de laisser la possibilité aux utilisateurs d utiliser un modèle qu il puisse émettre quand il le souhaite pour être réactif, ne pas perdre de l information et ne pas laisser les utilisateurs face à une difficulté. Pour être pertinent, les retours d expérience doivent être nominatifs, afin de voir l évolution des difficultés pour chacun, de comparer les demandes aux personas, mais également pour cibler les groupes d utilisateurs pour réaliser des formations complémentaires par exemple. L idée première pourrait être d utiliser une sorte de forum mais le risque est que les utilisateurs n osent pas avouer leurs difficultés aux yeux et à la vue de tous. Il semble donc nécessaire d avoir une sorte de médiateur, qui apporte une réponse précise à l utilisateur directement, et qui généralise la question et les réponses pour enrichir une base de connaissance libre d accès. Idéalement, cette FAQ doit être consultable à travers l application même. Finalement ce couplage de méthodes permet de faciliter le centrage sur l acteur en apportant un support à la communication tout au long du cycle de vie. Les utilisateurs se trouvent au cœur de la définition et de l amélioration du leur logiciel, car ce sont eux qui possède l expérience tant avant la mise en place du logiciel qu après. L informatisation peut résoudre des problèmes que si ces derniers sont énoncés clairement, et ne pas en créer de nouveau si la situation est définie dans son contexte. Le sondage ne résout pas toutes les difficultés mais offre l intérêt de favoriser la communication avec le plus grand nombre limitant ainsi la réticence au changement, et d augmenter la performance de l outil en améliorant la définition du niveau local. Page 161

162

163 Chapitre 6 Études de cas Chapitre 6 L entrée dans le processus et les problématiques associées : études de cas chez LASCOM Chaque projet est unique, en fonction du secteur d activités, du métier, des intervenants, des «prédispositions» des acteurs et de l entreprise, du contexte, des ambitions, des contraintes, des intervenants L éditeur n est pas non plus maître du moment de son entrée dans le processus, des éléments construits lors d étapes réalisées sans lui. Il est encore moins maître des délais imposés par le client : il doit s adapter. Malgré tout, pour «cerner» les difficultés qui l attendent, l éditeur classe généralement les projets en fonction de leur état d avancement initial, des éléments mis à la disposition de l éditeur et des attentes des clients. En d autres termes : «Au niveau de quelle étape du processus d implémentation et sur la base de quelles informations se fait le démarrage du projet pour l éditeur»? Comme le contexte et la maturité du projet ont une influence importante sur le travail à faire par l éditeur afin de livrer une application adaptée, les réponses apportées à cette question sont centrales. Au regard du processus initial vu par l éditeur, trois entrées dans ce processus sont possibles avec des «degrés d information» différents : soit il répond à un appel d offres, soit il répond à une demande d amélioration/évolution, soit il est dans période de prospection. Nous allons décrire dans ce chapitre différents cas d études représentatifs de la diversité des projets de LASCOM et nous montrerons l intérêt de nos propositions pour aborder ces projets. Nous verrons le cas d une entrée dès l avant projet (réponse à un appel d offres), puis des interventions «classiques» pour LASCOM - c'est-à-dire suite à la constitution d un cahier des charges, pour finir par un projet de reprise qui fait suite à l exploitation d une solution déjà en place. 1 Cas d une réponse à un appel d offres : la map pour initialiser et aider à la communication Le cas le plus fréquent d entrée de l éditeur dans le processus de déploiement d une solution logicielle correspond à la réponse à un appel d offres. C'est-à-dire que le client a défini ses besoins, réalisé une étude de marché et émis un cahier des charges indépendamment de l éditeur. Ce travail peut être fait en interne directement par l entreprise ou par le biais d un consultant. Les premiers interlocuteurs «LASCOM» pour l entreprise seront alors le Page 163

164 Chapitre 6 Études de cas commercial et l avant vente. Ils vont constituer une réponse technique (illustration des fonctionnalités liées au logiciel) et financière (le chiffrage de la solution envisagée), voire une démonstration d une solution type. Puis ils négocieront le contrat sur la base essentiellement du chiffrage. Enfin, ce n est que si l éditeur est retenu que le projet démarre en suivant les étapes décrites au chapitre 3 (Figure 10) pour parvenir à réaliser une application dédiée aux besoins du client. Nous proposons dans cette section de nous focaliser sur le cas d un client qui arriverait avec un cahier des charges établi. Ceci correspond à une entrée de LASCOM dans le processus au niveau de l étape «Réponses» de la Figure 10. Il est important de s intéresser à cette phase et aux suivantes car se sont-elles qui conditionneront en grande partie le déroulement du projet et la qualité de la solution et de la relation avec le client. 1.1 Réponse à un appel d offres par l avant vente Problématique liée à l avant vente Pour l éditeur, à l entrée du processus se trouve le cahier des charges. Nous pouvons distinguer deux types de cahier des charges : soit il définit très clairement les besoins du client essentiels et secondaires, voire la solution escomptée, soit il est très flou. La qualité du cahier des charges reflète généralement la maturité du besoin et du projet. Dans le premier cas grâce à la description précise, l éditeur, et plus précisément l avant vente, possède une meilleure vision de la solution escomptée, des verrous qui devront être levés ou qui pourront être induits par l utilisation de son logiciel et de leurs importances dans la solution. Malgré tout l expérience de LASCOM montre qu un «bon» cahier des charges n est pas une condition suffisante pour garantir une marge de risque minimale et un chiffrage optimum. En effet, lors du déroulement du projet, comme dans les cas d un cahier des charges floues, des modifications et/ou la découverte de nouveaux besoins non explicités sont quasiment systématiques. Les sources d apparition sont nombreuses : la maturité du projet, la qualité et la profondeur de l analyse des besoins, les capacités liées au logiciel, etc. Dans certains cas la divergence peut être considérable. Toutefois pour «vendre» un projet, il est nécessaire de s engager et d éditer un devis, incluant une part de risque plus ou moins importante en fonction du niveau d informations obtenu. Pour illustrer certains aspects de ce devis un certain nombre de brochures commerciales est également fourni. Aujourd hui, le chiffrage (le devis) représente une solution envisagée mais non définie clairement à cette étape, une réponse technique (la brochure) relatant essentiellement les fonctionnalités à mettre en œuvre et non la définition de l application, et une proposition de déroulement type du projet (non Page 164

165 Chapitre 6 Études de cas explicitée et justifiée). De surcroit, le chiffrage émis par l avant vente est ensuite négocié entre le commercial et les achats, des coupes «franches» sont généralement réalisées dues à des considérations essentiellement financières et non méthodologiques ou fonctionnelles. Généralement les temps impartis aux aspects «méthodologie projet» (essentiellement l analyse) sont revus à la baisse, voire supprimés au regard de leur durée et de leur prix. Ces durées et ces coûts sont le fruit d un manque de méthode rapide et efficace chez les éditeurs pour réaliser certaines étapes et notamment les étapes d analyse. Finalement, le chiffrage représentant la première et unique base tangible d échange entre le client et l éditeur, il constitue souvent l élément clé en vue de l obtention d un projet mais il n est pas représentatif de l organisation du projet, de son déroulement et de la définition de la solution. Conclusion le chiffrage n est pas exploitable durant le déroulement du projet et la seule base de référence sera et restera le cahier des charges émis initialement. Sur la base de cette seule «référence exploitable» et lors de réunions avec le client, le chef de projet devra alors, dans les temps impartis, définir le plus précisément possible les besoins contextualisés du client afin de réaliser les supports nécessaires à la suite du projet et à la définition de l application. Lors de cette phase, les capacités du logiciel, la maturité du projet, de nouveaux éléments et/ou de nouvelles contraintes vont s affiner ou apparaitre comme nécessaires et dus. Et, pour ne pas provoquer de dérive trop importante au regard des éléments vendus, le chef de projet devra tenter d expliquer la non prise en compte de certains points, constituant généralement une première source de conflit tant entre les parties, qu au sein de l éditeur (mauvais chiffrage, mauvaise vente, etc.). Cet état de fait est obtenu car sans éléments tangibles et sans écrits clairs des éléments vendus suite à la négociation lors de l étape précédente, il est souvent impossible de refuser l ensemble des demandes. L éditeur se trouve tenu de réaliser la prestation telle que demandée par le client et non telle que vendue. L application doit souvent répondre à plus d exigences et ce pour le même coût et idéalement dans les mêmes délais. Ce dernier point étant quasiment intenable au vue des itérations nécessaires pour appréhender les nouveaux besoins mais également pour les réaliser, il génère généralement une seconde cause de conflit. Ainsi, aujourd hui par manque de temps et d outils, aucun élément pratique ne permet de définir les termes du contrat tant au niveau de la solution logicielle définie au regard du prix accordé, qu au niveau de l organisation et du déroulement du projet. Le principal verrou réside ainsi non pas uniquement sur la qualité et la finesse du chiffrage mais surtout sur le manque d éléments factuels et à jour suite à la négociation, éléments qui viendraient expliquer et illustrer chacun des points que ce soit technique, fonctionnel ou organisationnel, auquel Page 165

166 Chapitre 6 Études de cas raccrocher le chiffrage. L objectif de notre proposition est d instaurer un support unique (la carte heuristique), détaillé et qui suit le cycle de vie du projet, et même du logiciel, accompagné de méthodes simples d analyse (exploration de la carte et persona). Le support unique permettrait d une part que le client soit conscient de l impact de ses décisions sur la solution lors de la négociation et d autre part qu il constitue une référence de comparaison lors du déroulement du projet en cas de conflit. Tandis que les méthodes aideraient à l obtention de résultats suffisamment précis pour réaliser l application client sans pour autant être chronophages L importance de la map en avant vente Situation sans notre proposition Pour illustrer cette problématique, prenons l exemple d une exigence relevée dans un appel d offres d un marché public pour un département d état et plus précisément dans le Cahier Techniques des Clauses Particulières (CCTP représentant le cahier des charges) dans le but de trouver un logiciel pour la gestion de ses plans et de leur cycle de vie. Le besoin résidait dans l utilisation d outil métier, en particulier CAO, en lien direct avec le logiciel de gestion recherché. Les obligations liées à cette contrainte pour l éditeur étaient énoncées sous deux aspects. D une part en termes de gestion des documents, en imposant que le cartouche des plans soit renseigné en fonction des métadonnées saisies dans l application et que les références existantes entre fichiers soient conservées. D autre part en termes d accessibilité des plans au travers de l outil CAO (Figure 39). LASCOM propose différents outils tiers ou connecteurs, essentiellement CAO et bureautique, pour utiliser son application LASCOM PLM au travers d outils métiers pour faciliter le travail quotidien des utilisateurs. Longtemps partenaire privilégié d Autodesk, LASCOM vend en particulier un connecteur adapté aux fonctionnalités du logiciel AutoCAD, et plus ponctuellement des connecteurs pour d autres plateformes CAO dont MicroStation de Bentley. La réponse à ces exigences fut naturellement de proposer l acquisition de ces deux connecteurs, en sachant que son connecteur MicroStation serait disponible «prochainement», après mise à jour, afin qu il fonctionne avec la version de l application (Figure 38). Figure 38. Réponse financière de LASCOM Page 166

167 Chapitre 6 Études de cas Figure 39. Extraits du Cahier Technique des Clauses Particulières (CCTP) Page 167

168 Chapitre 6 Études de cas La réponse technique explicitait rapidement les fonctionnalités principales disponibles présentent dans ce type d outil mais sans donner une liste exhaustive des fonctionnalités prises en charge (Figure 40 et Figure 41). En effet, la réponse technique a pour objectif d illustrer les principales fonctions proposées au client pour répondre à ses besoins. Elle n a pas pour but de définir une à une chacune d elle ni d un point de vue fonctionnel, ni d un point de vue paramétrage. Elle doit répondre à des exigences commerciales et non techniques. Figure 40. Extrait de la réponse technique LASCOM (1/2) Page 168

169 Chapitre 6 Études de cas Figure 41. Extraits de la réponse technique LASCOM (2/2) Lors de la soutenance de l offre et la négociation, la seule préoccupation était de savoir si LASCOM possédait une solution pour intégrer son produit à l outil métier le plus répandu dans l entreprise MicroStation et le débat se situait plutôt au niveau du prix eu égard à la quantité de connecteurs nécessaires (un outil par poste de dessinateur). Page 169

170 Chapitre 6 Études de cas Une fois le projet obtenu et lancé, LASCOM a mis à jour son connecteur MicroStation pour être en cohérence avec celui dédié à AutoCAD et à la version applicative mise en place chez le client. D un point de vue de l éditeur, ce sont bien leurs deux connecteurs, adaptés au contexte technique du client, qui étaient vendus. Autrement dit, aucun travail, d un point de vue fonctionnel, fut réalisé, ni même prévu, car rien ne laissait soupçonner de nouveaux besoins. Or lors des tests de ce connecteur, le client a jugé le produit non conforme fonctionnellement car toutes les fonctionnalités de l outil de CAO n étaient pas prises en compte à travers cet outil tiers. Effectivement au regard des éléments présents dans la réponse, le client était en droit de supposer et d attendre que toutes les fonctionnalités natives des outils CAO soient prises en compte. Finalement, de nombreuses itérations et compromis ont du être réalisés pour aboutir à une liste exhaustive des fonctionnalités à prendre en compte et pour déterminer leur mode d utilisation. Finalement des mois ont été nécessaires pour satisfaire les besoins principaux des utilisateurs et surmontés les nombreuses difficultés techniques liées à l outil mais également liées au mode d utilisation propre au client. La divergence entre le travail vendu et le travail finalement fourni fut importante, augmentant considérablement les risques sur le projet. Encore aujourd hui, les problématiques liées à cet outil restent un point épineux à traiter, voire une source de conflit, dû au manque de cadrage du fonctionnel pris en charge au départ Situation avec notre proposition Reprenons notre proposition dans ce cas précis. Lors de l analyse du cahier des charges (ici dans le CCTP) par l avant vente, nous préconisons d utiliser la carte heuristique, initialisée ou pas par le commercial, comme support de lecture du cahier des charges. Si nous appliquons cette méthode uniquement pour la partie présentée à la Figure 39, nous obtenons une description organisée et structurée des besoins énoncés (Figure 42). Ce format offre la possibilité à l avant vente de réaliser des regroupements, des liens et des annotations, des modifications, des restructurations facilement et rapidement tout au long de l analyse. Une sorte de check-list des points à éclaircir peut être constituée et pourra ensuite être étudiée soit au près du client, soit en interne. Ce support pour servir de base à un questionnement et mais aussi à contextualiser et argumenter les propos de l avant vente. Page 170

171 Chapitre 6 Études de cas Figure 42. Carte issue de l analyse de l extrait du CCTP La construction et la réorganisation des besoins faciliteront ainsi le travail d analyse de l avant vente, mais apporteront également une aide substantielle à la conception de sa vision de l application type nécessaire. En effet, il va pouvoir dans la zone de définition de l application ajouter les différentes briques standards explicitées au fur et à mesure de son analyse et copier/coller les éléments spécifiques au projet, pour construire «grossièrement» l application type qu il envisage pour la chiffrer (Figure 43). Page 171

172 Chapitre 6 Études de cas Figure 43. Image de l application envisagée par l avant vente Page 172

173 Chapitre 6 Études de cas Ces deux esquisses, du contexte et de l application, seront ajoutées en complément du chiffrage pour expliciter le travail prévu et les besoins pris en compte. Finalement, grâce à ce complément d informations, le client ne pourra pas juger le produit non conforme à cause d un manque de fonctionnalité non prise en charge, car le cadre fonctionnel est spécifié dans le support accompagnant le chiffrage. La seule solution pour lui sera de demander une demande d évolution nécessitant un nouveau cahier des charges et un nouveau chiffrage. Dans ce cas une part plus ou moins importante sera à sa charge contrairement à un correctif Comparaison Les verrous identifiés dans ce cas sont : - une réponse type non illustrée qui ne fixe pas exactement le travail à faire et les points pris en compte dans le chiffrage au regard du cahier des charges, - un manque de méthodes pour analyser le contexte rapidement et efficacement (étape souvent diminuée voire supprimée au moment de la négociation). L instauration de la carte heuristique dès la phase d avant vente semble lever ces difficultés et améliorer le processus de déploiement. Nous avons comparé sur la Figure 44 le niveau de difficultés rencontrés durant certaines actions clés du processus de déploiement sans et avec la carte heuristique et ce sur les différentes phases du processus global. Phase Les points clés Niv. Raisons Niv. Raisons Sans les supports Avec les supports Réponse Analyser les documents reçus dépend de: un support unique pour retracer et + - la personne, de ses méthodes organiser le contenu de l'ensemble des ++ - la complexité du projet et des documents documents Lister les besoins Lister les solutions -- + risque important d'oublier ou de ne pas voir certaines difficultés ++ dépend de: - la personne, de ses méthodes - la complexité du projet et des documents un support unique pour retracer et organiser le contenu de l'ensemble des documents utilisation d'un support standard permet de : - identifier les difficultés, les verrous - corrélations plus simplement avec d'autres projets Chiffrer chiffrage approximatif avec une marge les spécifiques sont mieux chiffrés, grâce à + ++ de risque globale l'apport du contexte Rédiger le document construction du document à chaque ossature du document réaliser -- projet, mais réutilisation des briques - automatiquement à partir de la carte de description Choix de la solution Définition des éléments vendus - très flou + définie le package prévu clairement Compréhension des raisonnement uniquement sur le possibilité de montrer les conséquences - + conséquences des négociations chiffrage très général plus facilement Spécifications Marge de risque - lié au chiffrage de chaque spécifique - chiffrage plus précis - indépendamment - demande d'évolution potentiellement un + - demandes d'évolution non peu plus maitrisable maitrisable Facilité de l'arbitrage aucune description exacte de ce qui document factuel précisant le cadre de la était prévu prestation vendue Analyser le contexte --- Figure 44. Impacts de la map «avant vente» au cours du processus ++ peu de visibilité et pas de temps pour faire une analyse poussée + vision globale du besoin et de la solution proposée avant même de commencer le projet Page 173

174 Chapitre 6 Études de cas Des résultats similaires peuvent être présentés sur l utilisation de la carte heuristique à chacune des étapes d intervention de l éditeur comme expliqué dans les chapitres précédents. Le point commun intéressant est que l instauration de ce support facilite et améliore non seulement l étape en cours mais influe également de manière positive sur toutes les étapes qui lui succèdent. Le second avantage est que la complexité du projet comme la personne réalisant l étude ne représentent plus des contraintes prépondérantes. 1.2 L analyse des besoins : le cœur du processus Problématique de l analyse des besoins La seconde étape critique du processus est l étape d analyse. Par manque de temps ou par manque de méthode, cette partie est trop souvent omise ou réduite à sa plus simple expression : un point rapide par le client de son besoin avec une bribe de contexte. Ainsi, aujourd hui lors d un début de projet, après un exposé sommaire par le client de son besoin, charge à l éditeur d animer la conversation/réflexion à partir du cahier des charges afin d affiner son analyse amont et de déterminer des solutions techniques appropriées. L objectif est d aboutir à des spécifications fonctionnelles adaptées à son application, que l on pourrait qualifier plutôt de technico-fonctionnelle, définissant finalement l application future ainsi que son contenu. Selon le chef de projet (ses compétences, ses habitudes, etc.) et l envergure du projet, les spécifications technico-fonctionnelles sont accompagnées par une modélisation de l application plus ou moins complète illustrant les points clés fonctionnels (définition des objets, des processus, etc.) et non techniques pour ne pas compliquer la description. Finalement l éditeur cherche généralement à modéliser son application sans même (ou alors partiellement) modéliser le fonctionnement du système (l entreprise, le service, etc.) à prendre en charge. Malgré tout l application résultante répond globalement aux attentes des clients, mais génère également des «retouches» ponctuelles, plus ou moins importantes et fréquentes durant le démarrage de l exploitation pour répondre aux problématiques des utilisateurs. Ces itérations sont difficilement gérables, consommatrices de temps et d énergie (non «vendus»), et allongent la durée du projet ce qui amplifie le mécontentement du client et bloque potentiellement la facturation (augmentant la pression chez l éditeur). Même si les itérations ne sont pas dues à l éditeur mais bien souvent au client qui change «d avis», elles mettent en évidence toujours le même problème : l absence d analyse contextualisée du besoin réel par l éditeur au regard de son produit. Cette analyse doit compléter l analyse théorique, souvent globalisée et généralisée, contenue dans le cahier des charges. Les causes du «délaissement» Page 174

175 Chapitre 6 Études de cas de cette étape peuvent provenir soit de l éditeur, soit du client. Le premier ne se sent pas armé pour réaliser une analyse à proprement parlé ce n est pas son cœur de métier tandis que le second n en voit pas l intérêt, ne cherche pas à évaluer son fonctionnement actuel et souhaite «juste» concevoir son fonctionnement futur. Cette situation est accentuée dans deux contextes en particulier : soit l intervention d un consultant en amont, qui a déjà réalisé une étude poussée, soit un client qui souhaite une «petite application clé en main» pour un «petit projet tout simple». Dans les deux cas, il est impossible d inclure l analyse des besoins dans le coût de la solution. Le premier rétorquera qu il a déjà payé cette prestation au près d un consultant, le second qu il a déjà fait l analyse et qu il a besoin du logiciel paramétré pour «demain». En l absence de méthodologie adaptée, cette étape est généralement perçue, et souvent à juste titre, comme trop coûteuse au regard du résultat, son influence sur la qualité du logiciel n est pas toujours facile à mettre en valeur et l ensemble des résultats n est pas forcément exploitable. Dans les deux cas, les clients prétendent que toutes les informations nécessaires sont présentes dans leur cahier des charges. Sauf que ces documents répondent à une description soit totalement générique, et donc très floue, soit très figée et peut être pas adaptée au logiciel choisi en définitif ou pas complètement appropriée. Si ces problèmes ne sont pas mis en exergue lors de l avant vente, le problème devient rapidement insoluble particulièrement lors de la phase des spécifications, moment où l on doit décrire la solution technique choisie pour chacun des points fonctionnels à prendre en compte. Si la description était floue, le client souhaitera en général ajouter des éléments ou les modifier en jouant sur des prétendus sous-entendus «métiers», alors que le chef de projet tentera de ne pas trop s éloigner du chiffrage réalisé. De même si la description était figée, le client reste arcbouté sur une solution «fantasmée», imaginée sur la base de ses connaissances ou sous l influence d un consultant, même si le chef de projet, de par son expérience, entrevoit une solution plus pertinente ou des impossibilités techniques ou fonctionnelles d utilisabilité. Dans ce cas l éditeur a du mal de jouer son rôle de conseil surtout sans avoir le contexte réel du besoin. Finalement aujourd hui, l analyse n est presque jamais vendue comme une prestation en tant que telle. Elle se résume bien souvent à des petites explications durant les spécifications au cas par cas lorsque des difficultés à comprendre le cahier des charges ou à déterminer une solution technique apparaissent. En conclusion il est essentiel d illustrer le chiffrage avec la définition d une présolution applicative afin de rendre compréhensible la proposition faite par l éditeur mais aussi de faire une analyse ou du moins une «contre expertise» pour valider l ensemble des besoins Page 175

176 Chapitre 6 Études de cas à prendre en compte avant même de débuter les spécifications pour valider le cadre fonctionnel et vérifier la réalisabilité. Pour éviter ces écueils tout en optimisant le temps nécessaire, le principe est d utiliser systématiquement une méthode simple, rapide et modulable pour s adapter au projet comme au client, dont la finalité constituera une base de référence de ce qui est pris en compte et à déterminer pour mener à bien le projet, mais également une base de communication commune L importance de l exploration et des persona pour définir les besoins réels Situation sans notre proposition Pour illustrer le phénomène décrit dans la section précédente nous prendrons l exemple d un grand groupe de construction qui souhaite une nouvelle application pour suivre et vérifier la conformité de certains travaux au regard des contraintes réglementaires, de sécurité et liées aux projets. Sa première expression de besoin se concentrait essentiellement sur l issue du processus de gestion informatique des conformités, la partie données de sortie (Figure 45), c'est-à-dire la conception des deux types de documents factuelles à délivrer pour prouver le respect des contraintes imposés soit sur l ensemble du projet, soit pour une contrainte donnée et le reporting de suivi. Figure 45. La définition du fonctionnement issue du cahier des charges Page 176

177 Chapitre 6 Études de cas Grâce au travail concluant réalisé depuis plusieurs années avec ce client, LASCOM a donc été contacté directement par celui-ci, afin d évaluer sa capacité à répondre à ce nouveau besoin. Au regard des éléments en sa possession, l avant vente proposa un module standard paramétrable semblant répondre au besoin avec la possibilité de l intégrer dans des applications existantes. La démonstration convainquit le client et la vente du module avec l ajout de quelques spécificités fut conclue (Figure 46). Figure 46. Exemple de chiffrage pour une nouvelle application Pour paramétrer ce module, il était convenu de réaliser très peu de réunions de spécifications car le niveau de spécificité à apporter n était pas important et cela permettait de diminuer le coût. Le but de ces réunions était de valider le vocabulaire, définir les droits, définir les visuels, etc. Entre la signature du contrat et le démarrage du projet, le client a demandé que l étude soit menée pour accélérer les spécifications et tenter de débuter cette partie du projet avec un maximum d informations concernant le paramétrage nécessaire. Ainsi dès la première réunion, ce dernier présenta ses résultats sur le fonctionnement (Figure 47) et la définition des éléments nécessaires, avec pour objectif d obtenir la validation de LASCOM plutôt que de revalider le fonctionnement avec les autres personnes présentes. Page 177

178 Chapitre 6 Études de cas Figure 47. Définition du fonctionnement suite à la consultation interne Le client, grâce à sa bonne connaissance du produit LASCOM, a présenté une spécification initiale qui contenait en très grande partie les éléments, ou les emplacements, nécessaires au paramétrage de l application et ce dans les termes «lascomien». Mais au regard des différentes conversations avec les personnes présentes lors des réunions, il s avéra que le fonctionnement établi ne correspondait pas pleinement aux attentes et que d autres part il ne pouvait pas convenir du point de vue fonctionnel pour l éditeur. Le nombre de réunions nécessaires avant d aboutir à la validation des spécifications fonctionnelles fut finalement plus important qu escompté et des compromis pour améliorer le fonctionnement furent obligatoires car la remise en question n était pas possible dans les temps impartis (Figure 48). Page 178

179 Chapitre 6 Études de cas Figure 48. Exemple de modification effectuée Finalement de nombreuses anomalies bloquantes sont ressorties sur le fonctionnement même de la gestion des contraintes lors des tests de validation de l application. Autrement dit, l application ne peut pas être déployée en l état, des corrections sont nécessaires, puis une nouvelle campagne de test doit être opérée pour valider ce point mais également vérifier les non-régressions. Pendant ce temps, la facturation de tout ou partie du projet n est pas possible puisque l ensemble du processus n ayant pas été préalablement clairement établi. Ainsi des «sous entendus» métiers ou des habitudes d utilisation de l application en place n avaient pas été implémentés. De plus, ces troubles ont ouvert la porte aux remises en question d éléments validés durant les spécifications et aux demandes de modifications itératives. Le projet prenant de plus en plus de retard et la nécessité absolue d utiliser rapidement cette partie de l application étant devenue de plus en plus forte, d importants retours en arrière ont du être réalisé, en désactivant certaines parties, afin d éviter de bloquer l avancement de la gestion des conformités (Figure 49). Ces parties devront être réactivées par la suite. Page 179

180 Chapitre 6 Études de cas Figure 49. Exemple de désactivation En conclusion, tellement obnubiler par la conception des documents sortants, le client, chargé de la tâche d analyse, en a oublié de définir clairement le déroulement du processus. Le projet a alors pris du retard imputable aux nombreuses itérations induites par des manques, puis des doutes liés au fonctionnement même du processus de gestions des contraintes dans son ensemble. Ces points particuliers auraient dû être éclaircis dès l analyse. Finalement le client est mécontent d avoir eu à attendre aussi longtemps ce module, d être obligé de limiter ces fonctionnalités pour un temps, et il reporte la faute majoritairement sur l éditeur. Cet exemple illustre le rôle crucial de l analyse des besoins et des difficultés/iniquités de laisser le client réaliser cette étape seul impactant l ensemble de la gestion de projet Situation avec notre proposition Reprenons cet exemple en utilisant notre proposition. L utilisation de la carte heuristique pour cette étape offre potentiellement la capacité de proposer une prestation abordable grâce à une réduction de sa durée et de son coût. Deux solutions s offrent à nous, soit il est impossible de conserver l étape d analyse des besoins, soit l éditeur doit réaliser cette étape. Dans un premier temps, nous allons considérer la seconde hypothèse. Idéalement, l étape d avant vente a permis de récolter de nombreuses informations formelles et informelles constituant ainsi un premier niveau de l analyse mise en forme sous le format de la carte heuristique présentée précédemment. Ce support est alors transmis au chef de projet dès le lancement de projet, il représente la vision commune et partagée entre les différents intervenants de l éditeur. A partir de cette carte, le chef de projet déterminera les Page 180

181 Chapitre 6 Études de cas grands axes d exploration à ne pas oublier, les hiérarchisera, etc., pour élaborer ainsi la base de l animation de sa réunion. Selon le nombre de participants lors de la première réunion, soit le brainstorming est lancé sans expliquer l objectif et c est le chef de projet qui orientera l exploration possible uniquement s il y a peu de personnes à canaliser-, soit une carte explicative de l objectif (Figure 50) sera présentée expliquant le mode de fonctionnement, les préconisations d exploration, etc. avant le lancement de l exploration. Selon les éléments vendus mais également au regard de la complexité de l organisation, suite à l initiation, le client pourra effectuer l étude sans l aide de l éditeur, qui interviendra qu à la restitution de l étude complète par le client afin de partager le même niveau de connaissance du système à prendre définitivement en compte durant l informatisation. Figure 50. Support à l initiation à la map contexte A l issue de des réunions, une exploration complète du processus est établie, mettant en exergue les points délicats à confirmer par les fonctionnels afin d obtenir le contexte définitif comme présenté dans la Figure 17. Cette étude aurait permis de comprendre les différents besoins, les mécanismes à prendre en compte dans l application, les différents critères à respecter évitant ainsi les «mauvaises» surprises pendant les tests. Par exemple, au vue des actions à réaliser pour l activité «recensement des documents sources», il serait apparu que la solution d utiliser l objet «Document» existant était inappropriée, de même pour la déclinaison des contraintes, le lien ne pouvait pas être réalisé entre «contraintes», mais bien entre une «réponse» et une ou plusieurs «contraintes» (Figure 51). Figure 51. Extrait du contexte issu de l analyse Page 181

182 Chapitre 6 Études de cas Pour accélérer cette étude, nous aurions pu également proposer d utiliser, en complément, les personas soit en amont soit en parallèle, afin de pré-initialiser et/ou valider la conception de la carte comme décrit dans le chapitre 5. Finalement, la capacité de l éditeur à proposer une méthode simple d analyse des besoins en se basant sur l exploration de l organisation existante permet d améliorer la compréhension mutuelle des éléments à prendre en compte dans l informatisation, d uniformiser la sémantique et de mieux appréhender la conception de l application. Grâce à cette expertise, les chances d obtenir un logiciel approprié aux fonctionnements de l entreprise s en trouvent augmentées tout en améliorant le niveau et la qualité de la communication avec le client. Toutefois si le client n adhère pas à l offre proposée par l éditeur, il est tout à fait possible de le laisser opérer à sa manière. Pour éviter les mésaventures il est primordial que le chef de projet débute les réunions de spécifications par la création de cette partie de la carte non pas en questionnant les interlocuteurs mais à partir de l étude réalisée par le client. La carte résultante doit permettre d aboutir à un équivalent de la carte issue du brainstorming, en ordonnant et classifiant les besoins et les différents éléments à prendre en compte. La validation par le client est malgré tout nécessaire pour établir un point de repère commun simplifié au même titre que le cahier des charges Comparaison De par sa situation temporelle dans le processus, l analyse des besoins permet de faire le lien entre l étape d avant vente et le début des spécifications. Elle doit déboucher sur l énoncé clair de l ensemble du problème afin d organiser la suite du processus et limiter les risques de divergence. Pour que l éditeur puisse concrétiser cette étape d analyse des besoins, l utilisation d un support simple accompagné d une méthode efficace est primordiale. Ce support apportera une meilleure visibilité du travail à faire mais sera également un vecteur de communication important. Ce support sera une base commune de connaissances du projet pour les personnes participantes à l implémentation d un nouveau logiciel, mais il offrira aussi la possibilité d élargir le cercle des participants à des utilisateurs avertis par exemple. De plus, cette étude est une phase critique dont la qualité se répercutera sur la suite du processus et impactera directement la qualité de l ensemble des étapes suivantes (Figure 52). Page 182

183 Chapitre 6 Études de cas Phase Les points clés Niv. Raisons Niv. Raisons Sans les supports Avec la carte heuristique Spécifications Analyser le contexte peu de visibilité et pas de temps pour faire une analyse poussée - compréhension du projet dans son contexte déterminer le contour fonctionnel - constituer une base de référence commune Spécifications fonctionnelles Modélisations(s) Choix des solutions techniques Développements Spécifications techniques Tests Compréhension du besoin fonctionnel - Cohérence avec l'ensemble de l'application cliente Compréhension des scénarios Organisation des tests longue pour appréhender point par point les besoins génériques énoncés dans le cahier des charges - fort risque d'évolution au vue des capacités de l'application réalisé point par point, car difficultés d'obtenir une vision globale à ce moment là du processus réalisé point par point et avec peu de contexte + explication fonctionnel sommaire, avec très peu de contexte vision globale difficile à appréhender Pas de scénario, mais une succession de tests unitaires Difficile à prioriser meilleure compréhension des besoins individuellement mais également dans son ensemble - constitution d'une sémantique commune déjà réalisée solution plus performante individuellement et plus cohérente dans leur ensemble solution plus performante individuellement et plus cohérente dans leur ensemble support commun résumant le contexte et la situation du développement à faire vision globale du besoin et de la future application Capacité de créer des ++ scénarios de tests par profils Capacité de hiérarchiser l'importance des fonctionnalités + globalement et par profil Support Compréhension des questions + difficulté de comprendre les questions du client en l'absence de connaissance de l'application et surtout de la sémantique client ++ - support global présentant les aspects fonctionnels pris en charge - une vision sommaire de l'application Figure 52. Impacts de l utilisation de la map pour l analyse des besoins 1.3 Synthèse Chaque projet est unique de par son contenu mais également sur sa forme et son organisation, et plus particulièrement sur le niveau d informations disponibles pour son déroulement. L uniformisation doit être opérée par l éditeur car il ne maitrise ni la quantité et ni la qualité des données entrantes nécessaires au processus. Il est important d analyser l ensemble des informations fournies pour pouvoir identifier les manques qui risquent de pénaliser l ensemble du projet. D un point de vue de l éditeur, les deux premières étapes du processus, la réponse et l analyse des besoins, sont donc critiques et à «ne pas manquer», car elles sont porteuses et propices à la collecte d un grand nombre d informations cruciales pour Page 183

184 Chapitre 6 Études de cas la suite du projet, sans risque de le pénaliser. La mise en place d une méthode et d un support commun pour ces deux étapes maitresses du processus sont essentielles car elles conditionnent le bon déroulement de la suite du déploiement. Nous venons de démontrer l intérêt de l utilisation d une carte heuristique pour aider à traiter toutes les informations exploitables sous un format unique, rapide à mettre en œuvre et facilitant les échanges avec le client. De la même façon, la suite du processus présente également ses manques et ses faiblesses qui peuvent être minimisés par l utilisation du même de support et ce pour l ensemble du projet (Figure 53). Finalement l instauration d une même méthode et des outils associés tout au long du processus, quelque soit l intervenant, facilite globalement le déroulement du projet et la qualité du résultat. Le niveau de communication est également augmenté grâce à la transparence tant sur le déroulement du projet, que sur les choix pour l application, améliorant la confiance du client en l éditeur. De plus, l utilisation généralisée et l intérêt observé pour chacune des étapes et chacun des intervenants pour obtenir le niveau d information suffisant peuvent contribuer activement à la pérennité de cette solution. Page 184

185 Chapitre 6 Études de cas Phase Les points clés Niv. Raisons Niv. Raisons Niv. Raisons Sans les supports Avec la carte heuristique Avec la carte heuristique + persona Prospection Vérifier la concordance entre le projet et ses Comparer des projets Expression du besoin Etude de marché Cahier des charges Réponses Analyser les documents reçus + dépend de: - la personne, de ses méthodes - la complexité du projet et des documents ++ un support unique pour retracer et organiser le contenu de l'ensemble des documents Lister les besoins Lister les solutions Chiffrer Rédiger le document risque important d'oublier ou de ne pas voir certaines difficultés ++ dépend de: - la personne, de ses méthodes - la complexité du projet et des documents ++ chiffrage approximatif avec une marge de risque globale ++ construction du document à chaque projet, mais réutilisation des briques de description - un support unique pour retracer et organiser le contenu de l'ensemble des documents utilisation d'un support standard permet de : - identifier les difficultés, les verrous - corrélations plus simplement avec d'autres projets les spécifiques sont mieux chiffrés, grâce à l'apport du contexte ossature du document réaliser automatiquement à partir de la carte Ajout d'une description illustrée +++ des besoins clés par le biais des personas mis à jour verrifier la cohérence entre la solution et l'usage +++ cohérence accrue +++ Choix de la solution Définition des éléments vendus Compréhension des conséquences des négociations Spécifications Marge de risque Facilité de l'arbitrage Analyser le contexte Spécifications fonctionnelles Modélisations(s) Choix des solutions techniques Développements Spécifications techniques Tests Compréhension du besoin fonctionnel - Cohérence avec l'ensemble de l'application Compréhension des scénarios Organisation des tests très flou raisonnement uniquement sur le chiffrage très général + - lié au chiffrage de chaque spécifique indépendamment - demandes d'évolution non maitrisables aucune description exacte de ce qui était prévu peu de visibilité et pas de temps pour faire une analyse poussée - longue pour appréhender point par point les besoins génériques énoncés dans le cahier des charges - fort risque d'évolution au vue des capacités de l'application réalisé point par point, car difficultés d'obtenir une vision globale à ce moment là du processus réalisé point par point et avec peu de contexte + explication fonctionnel sommaire, avec très peu de contexte vision globale difficile à appréhender Pas de scénario, mais une succession de tests unitaires Difficile à prioriser définie le package prévu clairement possibilité de montrer les conséquences plus facilement - chiffrage plus précis - demandes d'évolutions potentiellement un peu plus maitrisables document factuel précisant le cadre de la prestation vendue - vision globale du besoin et de la solution proposée avant même de commencer le projet - compréhension du projet dans son contexte - déterminer le contour fonctionnel - constituer une base de référence commune - meilleure compréhension des besoins individuellement mais également dans son ensemble - constitution d'une sémantique commune déjà réalisée solution plus performante individuellement et plus cohérente dans leur ensemble solution plus performante individuellement et plus cohérente dans leur ensemble support commun résumant le contexte et la situation du développement à faire vision globale du besoin et de la future application apporter soit une base d'exploration, soit une validation de l'exploration - apporter la vision locale et la sémantique usuelle vision des besoins réels dans leur contexte, permet d'entrevoir des solutions plus adaptées vision théâtraliser de la situation à prendre en compte favorisant l'empathie Capacité de créer des Utilisation des personas scénarios de tests par profils comme scénarii Capacité de hiérarchiser l'importance des fonctionnalités + globalement et par profil Figure 53. Améliorations du processus de déploiement Page 185

186 Chapitre 6 Études de cas 2 Cas d une reprise d exploitation : importance des supports Rétrospectivement, le cycle de vie d une application chez un client peut être très long. Durant ce laps de temps, des problèmes liés à l utilisation sont rencontrés, les besoins changent ou évoluent, et la version du logiciel peut ne plus être supportée par l éditeur. Tous ces événements entrainent des interventions plus ou moins fréquentes sur l application du client. Elles peuvent être catégorisées en trois types : correctives, «amélioratives» ou préventives. Aujourd hui selon le type d intervention et sa teneur, le processus mis en œuvre diffère tant sur le mode opératoire (les étapes réalisées, les intervenants) que sur le suivi. Ces interventions constituent réellement une nouvelle entrée et rarement une suite du processus car le laps de temps écoulé entre deux interventions peut être long, les types d interventions peuvent être différents et les intervenants peuvent eux aussi être différents. Cependant dans les trois cas, que la teneur des modifications à apporter soit mineure ou majeure, chacune d elles nécessite de connaitre l environnement dans lequel elle s inscrit afin de ne pas déstabiliser l application et s assurer de répondre correctement au besoin. Autrement dit, cette seconde entrée se différencie de la première par la nécessite supplémentaire d appréhender l application existante en place chez le client pour adapter l intervention et déterminer une solution compatible. La qualité de la prestation repose donc sur la capacité à reconstituer la vue globale de l application actuelle à partir de son historique. 2.1 Problématique de la constitution d une vue globale de l application Aujourd hui, selon le type d intervention, le processus de prise en compte et les règles de gestions diffèrent de ceux mis en œuvre pour un projet dont l origine tient essentiellement au coût de ces prestations. En effet, les actions correctives sont traitées par le support et sont réalisées dans le cadre de la maintenance de l application, c'est-à-dire que quelque soit le nombre de demandes et leur difficulté, le coût annuel est fixe. La rentabilité repose alors sur la rapidité des corrections. Tandis que les améliorations et les actions préventives reposent généralement sur des commandes spécifiques ou complémentaires à la maintenance, c'est-àdire avec un budget donné et elles seront gérées par un chef de projet. Par contre à la différence d un nouveau projet, dans ces deux derniers cas, toutes les étapes du processus ne sont pas réalisées que ce soit coté client ou éditeur. Pour le client toutes les étapes de choix de solutions n ont pas lieu d être, la réponse de l éditeur doit donc consister à fournir une réponse financière. Cette différence est accentuée par le niveau d information fourni. En effet, dans ces cas, le cahier des charges est généralement réduit à une expression de besoin, c'est-àdire une description moins fonctionnelle et plus «technique» orientée en fonction du logiciel Page 186

187 Chapitre 6 Études de cas (par exemple : besoin d ajouter une étape Y dans le processus untel après l étape X). Autrement dit, le chiffrage demandé est une évaluation technique - il y a rarement une étude avant vente réalisée -, ce qui implique généralement l absence ou la minimisation du coût de la gestion de projet lié à la réticence des clients qui considèrent cette intervention comme une «simple» modification dont le travail d analyse est déjà réalisé par leur soin. Finalement dans les trois cas, aucun temps d étude n est prévu (vendu) ou alors il est réduit à son minimum, alors que cette étude est plus complexe car nécessitant la prise en compte fonctionnelle et technique du besoin dans un cadre existant. Une autre problématique repose sur le suivi de ces interventions car la récupération des informations issues de ces interventions, de la demande à la résolution, est complexe. Le support utilise un outil dédié permettant de communiquer formellement avec le client (les déclarations de problèmes, les demandes d informations complémentaires, les solutions, etc.), problème par problème et ce tout au long du cycle de traitement jusqu à sa clôture. L objectif du support est de comprendre la nature du problème pour pouvoir le résoudre. Or en fonction des clients, la description ne correspond pas forcément réellement au problème technique rencontré. Pour accélérer le processus de compréhension et donc de résolution, des échanges informelles sont également opérés soit directement entre le support et le client, soit entre l ancien chef de projet et le client, soit en interne. Finalement, l utilisation d un outil dédié permet de centraliser toutes les actions effectuées par la hotline mais ne donne pas une vision globale des interventions sur une application. Ceci est dû fait que d une part toutes les informations ne sont pas forcément tracées, et que d autre part elles sont stockées et identifiées en fonction du client (or un client peut avoir plusieurs applications), de l énoncé initial du problème (ne correspondant pas forcément au problème réel) et individuellement (plusieurs énoncés pouvant correspondre à un seul est même problème). Tandis que dans le cadre d une commande, le chef de projet sera en lien direct avec le client, accentuant les échanges informels et dans un mode «sans» projet, c'est-à-dire que toutes les étapes du processus ne sont pas forcément suivies (analyse du besoin, spécifications, etc.). Autrement dit, les modifications apportées ne donneront pas forcément lieu au même niveau de formalisation qu en mode projet et reposeront d avantage sur l élaboration de fiches d interventions listant les actions réalisées sur le serveur. Ce mode de fonctionnement entraine généralement des dérives plus ou moins importantes liées à la proximité entre les deux parties pour concevoir et mettre en place les évolutions et/ou les améliorations. Comme le client s est retrouvé seul face à son application pendant quelques temps, dès lors qu il retrouve un interlocuteur, il aura tendance à en profiter pour exposer d autres difficultés sans Page 187

188 Chapitre 6 Études de cas lien avec le but de l intervention. Le chef de projet se trouve dans une situation délicate et doit gérer les deux aspects l intervention, pour laquelle il n est pas forcément à l aise, et la reprise de contact. Selon les rapports entre le client et le chef de projet, et la disponibilité du chef de projet, le client cherchera à faire perdurer ce phénomène plus ou moins longtemps par mail ou par téléphone. Le chef de projet s y pliera pour éviter les litiges et accroître la satisfaction du client. Ces «petits» dépannages, qu ils soient réalisés durant une prestation ou pas, sont rarement retranscrits formellement ou alors dans les fiches d interventions mélangeant ainsi les actions propres à l intervention et les demandes additionnelles. Ces types d interventions ne suivent donc pas un processus figé. Le seul jalon est l opérationnalité de l application finale, les différentes étapes ayant menées à ce résultat n étant pas forcément formalisées. Finalement lors d une reprise de l existant, le type et le niveau de documentation de suivi ne sont pas homogènes entre les différents types d interventions et dépendent du contenu de la prestation, du client, du temps accordé, du chef de projet, etc. Ceci oblige, lorsque nous reprenons un existant, qu il faut non seulement comprendre les modifications à faire mais également le contexte dans lequel elles vont s intégrer que ce soit techniquement ou fonctionnellement. Au regard du mode de fonctionnement actuel, du cloisonnement entre les types d intervention et de l hétérogénéité des supports, il est très compliqué pour un intervenant ponctuel de reconstituer l historique d une application. L objectif de se construire une vision globale de l application actuelle pour déterminer des solutions cohérentes et évaluer les impacts de ses actions essentiellement d un point de vue fonctionnel est donc difficilement tenable pour les intervenants LASCOM. 2.2 Mise en évidence de l intérêt de la map comme support d intervention Situations sans notre proposition Exemple d actions sur une application déjà implantée A l origine, l application a été conçue pour répondre à un cahier des charges dont les exigences ont été revues ou adaptées en fonction de l outil, des précisions apportées lors de la conception, etc. Puis au fil de son utilisation certains ajustements ont été réalisés soit dans le cadre d évolutions à proprement parlé (ajout de fonctionnalités, d outils tiers, etc.), d améliorations, mais également des corrections (soit pour résoudre des bugs, soit pour répondre à l environnement du client). Toutes ces étapes ont été menées par des intervenants Page 188

189 Chapitre 6 Études de cas différents dont le travail fut décrit plus ou moins précisément soit à travers un cahier des charges dans le cas d un élargissement fonctionnel (sans base préexistante dans l application), soit à travers des expressions de besoins (mini cahier des charges décrivant le besoin en terme fonctionnel et/ou technique), soit des déclarations de bugs. Les deux derniers cas sont les plus fréquents durant le cycle de vie d une application. Ils sont perçus comme des «petites» adaptations et suivent des circuits internes à l éditeur différents. Le support agira à travers une application dans laquelle seront tracés les échanges avec le client, les échanges internes et la solution. Dans le cas d un élargissement, il y aura une intervention qui donnera suite, normalement, à une fiche d intervention relatant, plus ou moins finement, les actions réalisées. A cela s ajoute les questions ponctuelles du client pour effectuer soit lui-même, soit lors d une intervention prévue, des paramétrages ou des corrections jugées mineures. Finalement lors des dernières phases du cycle de vie d une application, nous assistons à une succession d interventions plus ou moins formelles pour lesquelles l enchainement de toutes les étapes du cycle de déploiement est rarement respecté. Ce non respect du processus s explique par un manque de temps et surtout car ces étapes n ont pas été vendues, le client ne voyant pas l intérêt de payer ce genre de prestation dans le cadre d interventions dite mineures Exemple une demande de modification des caractéristiques Un autre cas fréquent d interventions sur une application existante concerne la demande de modification des caractéristiques d une propriété du modèle de données pour des fins fonctionnelles (réaliser un lien dynamique entre deux types de documents). Nous étudierons le cas défavorable (mais fréquent) du chef de projet qui prend en charge le dossier sans connaitre l application dans son ensemble et qui en fonction de la modification vendue n aura pas eu l opportunité d effectuer une étude. Dans ce cas, le chef de projet va alors réaliser une modification rapidement sous la pression du client a priori sans problème, une fiche d intervention est alors éditée et stockée. Finalement, quelques temps plus tard le client déclare au support une anomalie : un outil tiers spécifique, qu il utilise ponctuellement, ne fonctionne plus. Le client n ayant pas identifié la source du problème, le support a vérifié dans un premier temps les demandes d intervention effectuées récemment. Rien ne laissant présager une modification de l outil en lui même, il a dû déterminer quel était cet outil propre au client (est-ce un outil «classique» dont le nom a été modifié pour le client? Que fait cet outil? Comment fonctionne-t-il?) et trouver un environnement de test pour reproduire le problème et analyser le dysfonctionnement. Une fois un problème reproduit, il est souvent Page 189

190 Chapitre 6 Études de cas plus facile d en déterminer la cause. Grâce à son expertise, le support a réussi à établir le lien entre une fiche d intervention et l outil en question, et ainsi trouver la source de l anomalie. Le client utilisait une donnée dont les caractéristiques avaient changées, rendant l outil tiers incompatible. Il est a noté que si la modification n avait pas été tracé, mais réalisée «pour rendre service» dans le cadre d une autre prestation, le lien entre les deux interventions et donc l identification de la cause de l anomalie aurait pris plus de temps et suscitée des itérations supplémentaires pour justifier et valider la modification du modèle de données. Finalement, une modification jugée anodine au départ a impliqué deux interventions par deux équipes différentes. Au cours de la première intervention, le chef de projet n ayant pas menée d étude et ne possédant pas une vision globale de l application, il n a pas détecté les impacts potentiels de sa modification. Tandis que la seconde intervention a conduit le support à réétudier l outil en question et rechercher l historique des modifications pour déterminer la cause du problème et rééditer un nouvel outil adapté compatible avec les modifications. En conclusion, que la modification soit «anodine» ou pas, fonctionnelle ou technique, si l intervenant n a pas une vision globale de la solution propre au client, les risques de déstabilisation sont importants Exemple d une migration d application Le dernier exemple va concerner la migration d une application déjà en place. L objectif d une migration d une application est de fournir au client une application équivalente à celle qu il possède mais avec une version supérieure du logiciel. Cette nouvelle version intègre de nouvelles fonctionnalités, des améliorations, des évolutions devenues des standards, etc. L enjeu majeur ne réside pas dans l installation d une nouvelle version du logiciel mais dans la récupération des éléments spécifiques au client. Ce point englobe les développements réalisés pour lui et qu il est nécessaire de modifier pour les intégrer à la nouvelle version, mais également l ensemble du paramétrage propre à l application (modèle de données, paramétrages de l application) et connexe à celle-ci (paramétrages structurels) essentiel pour le bon fonctionnement de l application dans l environnement informatique du client. Le jour du lancement de la migration, le nouveau chef de projet doit idéalement appréhender l application dans son intégralité ainsi que les besoins fonctionnels auxquels doit répondre le futur logiciel pour évaluer le travail à réaliser au regard des fonctionnalités disponibles dans la nouvelle version. Nous utilisons volontairement le terme «nouveau chef de projet» car c est rarement la même personne qui suit l application tout au long de son cycle de vie (turnover des ressources humaines, ancien chef occupé à la gestion d un autre Page 190

191 Chapitre 6 Études de cas projet, etc.). L objectif est de déterminer pour chacun des points si la source du développement est l application cliente ou la nouvelle version pour aboutir à une solution fonctionnellement équivalente mais à jour techniquement. Une fois encore cette étape décisive de reconstitution de l historique de l application est critique et essentielle pour aboutir à la «recréation» de l application améliorée. En effet, le niveau d information nécessaire sur les modifications apportées ne se résume ni à un aspect uniquement technique (les développements sont stockés en interne et facile à identifier), ni à un aspect paramétrage (plus compliqué à obtenir), ni enfin à un aspect fonctionnel (certains éléments développés à l origine ne sont peut être plus usités et risquent de retarder le projet pour rien). Aujourd hui, ces deux derniers points sont relativement complexes à cause d une part des différents types d interventions et de leurs différents degrés de suivis (sans oublier les actions informelles demandées par le client lors d une intervention et les modifications effectuées par le client luimême) et de l absence de suivi du contexte de l application d autre part. Il est alors quasiment impossible de s assurer d avoir véritablement récupérer l ensemble des informations. Cet état de fait engendre soit : - des migrations «trop souvent» systématiques pour limiter les risques immédiats (basées uniquement sur l application du client et rendues compatibles avec la nouvelle version) - des itérations importantes lors des tests réalisés pour parvenir au même niveau fonctionnel que l application existante. Finalement le client ne bénéficiera pas de toutes les nouvelles capacités du logiciel et la maintenance sera plus compliquée, baissant potentiellement sa rentabilité. La problématique se situe essentiellement sur la reconstitution non seulement de l historique des modifications apportées par les différents intervenants chez l éditeur mais également par le client mais aussi et surtout sur la définition du contexte à prendre en compte. En conclusion, pour l éditeur, gérer le cycle de vie d une application veut dire suivre l évolution de l organisation et de ses besoins mais également les besoins technologiques. Ce suivi est ponctué de différentes interventions plus ou moins importantes portant tant sur des points fonctionnels que techniques. Pour réaliser une prestation sur une application existante, un travail préliminaire plus important et complexe que lors d un nouveau projet est nécessaire pour reconstituer une vision de l application dans son contexte actuel (son état au jour d aujourd hui) avant d évaluer et de valider les actions prévues. Aujourd hui il existe ni Page 191

192 Chapitre 6 Études de cas méthode, ni support commun d interventions ce qui a pour effet de générer un niveau croissant de difficulté, proportionnel au nombre d interventions Situation avec notre proposition. Comme nous l avons décrit précédemment, la mise en place d une carte heuristique dès les prémisses d un projet et la mise à jour à chaque intervention permet de réduire les problèmes de reconstruction d une image de l application dans son contexte. En effet en consultant la map, soit au moment de la définition de l intervention soit lors de la préparation de l intervention, la personne obtient une vision globale et commune de l application sur laquelle il doit interagir. La prise de connaissance du contexte doit lui permettre de situer le contour de l intervention et les impacts techniques et fonctionnels potentiels. Ainsi, les problèmes énoncés dans les trois cas d études précédents devraient être détectés en amont de l intervention soit par le client directement, soit par l intervenant. Pour le premier exemple, le lien entre les données et l outil tiers aurait été visible directement sur la map. Si malgré tout la modification avait eu lieu sans prendre en compte des impacts collatéraux, le client aurait pu détecter rapidement la source du problème sur l outil tiers en cherchant la définition de ce dernier dans la map. De même, l intervention du support aurait été grandement facilitée puisqu il n aurait pas eut à rechercher la définition de cet outil propre au client dans les différents documents ou dans les sources de développement et la cause du problème aurait été identifiée rapidement. Pour le second exemple, la migration aurait été plus efficace grâce à l historisation et la description des besoins contenues dans la map. Le travail de migration se serait concentré sur les besoins toujours présents, les autres étant annotés comme obsolètes et les choix techniques plus aisés grâce à la compréhension des besoins fonctionnels au regard des solutions techniques préexistantes dans la nouvelle version du logiciel. De plus les données de paramétrages propres au client auraient également été accessibles et à jour. Finalement, les itérations pour aboutir au même niveau fonctionnel auraient été limitées, voire inexistantes, et l application résultante aurait bénéficiée de tous les avantages de la nouvelle version. L autre avantage de la map commune avec le client est de lui offrir un support pour le suivi de ses modifications. En effet, certains clients sont semi-autonomes (faisant encore appel à l éditeur pour du support ou des évolutions), voire autonomes, sur leur application, c'est-à-dire qu ils interviennent directement sur le paramétrage, voire le développement de leur application. Page 192

193 Chapitre 6 Études de cas Aujourd hui dans le premier cas, le plus critique pour l éditeur, le client n a pas de solution simple pour stocker l information et la partager avec l éditeur. Conclusion, seul le client est conscient des modifications qu il a effectué, avec une maitrise plus ou moins importante de leurs impacts sur le fonctionnement de certaines parties de l application. Cette situation engendre des difficultés supplémentaires pour corriger des anomalies liées à cette modification mais détectées bien plus tard. Finalement, cet outil de suivi commun avec le client retrace et conserve l historique des modifications effectuées tant par l éditeur que par le client. La map constitue alors l unique référence pour les deux parties définissant le contexte, les prestations (le projet initial et toutes les interventions) et la solution actuelle mise en place. Cette philosophie permet de replacer l application au centre du lien entre le client et l éditeur car ce fil conducteur contribue au suivi non pas des interventions comme actuellement mais de l impact de cellesci, c'est-à-dire qu il contribue au suivi du cycle de vie de l application, cœur du lien entre les deux parties. 2.3 Synthèse Aujourd hui, suite à la mise en place d une application, les interventions de l éditeur se limitent souvent à trois types d interventions : - Les actions correctives : réalisées par le support en réponse à une déclaration d anomalie, - Les actions d améliorations/évolutions : réalisées par un chef de projet en réponse à une commande ou dans le cadre d une prestation, - Les actions préventives : réalisées par un chef de projet pour conserver la maintenabilité de l outil. Ces interventions suivent des règles de traitement et de suivi différentes engendrant des difficultés dans le suivi de l évolution de l application et même des pertes d informations. Ces phénomènes sont accentués par les interventions directes du client sur son application qui ne sont jamais connues de l éditeur à part en cas de problème. Autrement dit, chaque intervention entraine un niveau de risque croissant proportionnel au nombre de modifications effectuées et l appropriation du «nouveau» contexte de l intervention est quasiment impossible dans les temps impartis. Page 193

194 Chapitre 6 Études de cas Notre proposition de concentrer les informations sur un même support et de conserver un historique des modifications de l application et de son contexte sur ce même support améliore la performance et la qualité des prestations (Figure 54). La définition du cadre de la prestation et l étude d impact deviennent possibles en amont de l intervention, limitant ainsi les risques de déstabilisation de l application. Tandis que dans le cadre d une action corrective, l anomalie est resituée dans l ensemble de son contexte à jour, facilitant l identification de sa source. Cette centralisation permet aussi de recentrer le suivi des interactions en termes de suivi des modifications de l application et de son environnement en sensibilisant de par sa structure l ensemble des acteurs du cycle de vie de l application, éditeur comme client. Cette sensibilisation doit porter sur l intérêt de systématiser la mise à jour de la partie applicative mais également du contexte (comment un problème est apparu? Y-a-t-il un nouveau besoin ou une modification d un besoin?). La map devient ainsi un support à l accompagnement du client et un support dynamique reflet du cycle de vie de l application. Phase Les points clés Niv. Raisons Niv. Raisons Niv. Raisons Sans les supports Avec la carte heuristique Avec la carte heuristique + persona Support Compréhension des questions difficulté de comprendre les questions du client en - support global présentant les aspects fonctionnels pris en Sensibilisation du client à l'intérêt de décrire précisément + l'absence de connaissance de l'application et surtout de la sémantique client ++ charge - une vision sommaire de l'application +++ les actions posant problème Compréhension de l'application Exploitation Suivi de l'évolution de l'application Evaluation des demandes d'évolution Intégration d'évolution/amélioration pas de vision globale de l'application à jour, nécessité de rechercher l'historique ++ - perte de contrôle du client par rapport à son application (ce qu'il a ou pas, les modifications réalisées / proposées ) et du contour fonctionnel pris en charge - voire de l'éditeur également au regard du nombre d'intervenants indépendants tout au long du cycle de vie difficultés pour l'éditeur d'être force de proposition car pas d'accompagnement difficultés pour l'éditeur : - d'obtenir une vision claire des besoins à prendre en compte - d'estimer l'adéquation et la cohérence des solutions techniques présentation sur un support de tout le cycle de vie d'une application (les choix, les validations, les modifications ) support global et commun entre l'éditeur et le client, récapitulant toutes les interventions et leurs impacts. Vision toujours à jour de l'application - vision globale de l'application cliente à jour - accompagment des utilisateurs permettant d'être force de proposition - support facilitant la connaissance de l'application cliente / aux difficultés et ou nouveaux besoins contexte d'utilisation présentées au ragard de la solution déployées et à jour +++ amélioration de la compréhension des scénarii d'utilisation et des difficultés résultantes Retours d'expérience Suivi de l'utilisabilité de l'application - pas ou peu réalisé à part lors de demandes d'interventions ou la déclaration de bug + évolution du contexte montrant les manques de l'application sur un support unique Figure 54. Améliorations des étapes après projet Page 194

195 Chapitre 6 Études de cas Page 195

196

197 Conclusion et Perspectives Conclusion et perspectives Une application «optimale» pour un client est une application qui se fond avec son environnement tout en améliorant le fonctionnement du système. Pour intégrer une solution PLM dans l environnement d une entreprise tout en apportant les services escomptés, l intégrateur et plus particulièrement si ce dernier est également l éditeur, doit apporter non seulement une solution technique répondant aux contraintes du client à long terme, mais également un accompagnement de tous les instants du client pour que son application fusionne avec l organisation existante. La tâche de l éditeur s inscrit dans ces termes : il doit être présent pour répondre aux besoins et aux difficultés rencontrées par les acteurs à travers la mise en place de son logiciel tout au long de son cycle de vie mais également pour que la solution s intègre dans l organisation. La compréhension mutuelle des attentes et des contraintes des deux parties est alors primordiale. Chacun des intervenants comprend et maitrise sa partie et l échange de connaissances et le partage sont les vecteurs d un résultat réussi. Toutefois, l objectif sera atteint uniquement si les acteurs utilisent le logiciel et se l approprient. Nous proposons d améliorer le processus de déploiement et les supports l accompagnant pour accroître l adéquation de l application et la qualité des prestations tout au long du cycle de vie de celle-ci. Conclusions générales sur la thèse Dans le premier chapitre, nous avons vu que pour résister sur le marché international, les entreprises recherchent des solutions pour améliorer leur productivité, réduire leurs coûts et accroître leur potentiel d innovation. Aujourd hui aux nouveaux besoins fonctionnels de l entreprise s ajoutent les problématiques réglementaires imposant des solutions plus globales pour gérer les entreprises de manière homogène et gérer les développements du couple produits/projets mais aussi plus précises pour optimiser la dynamique du pilotage si possible jusqu au niveau local. Un des axes d amélioration réside dans l adoption de l informatisation des flux connexes, que ce soit l ERP pour les aspects productions/ressources ou le PLM pour les aspects conceptions/techniques. Mais aujourd hui les entreprises n ont pas toujours conscience que pour aboutir aux capacités escomptées de chacun d eux, le déploiement impactera l organisation même de l entreprise de part le fait que ces outils sont très structurants et nécessitent la mise en place d une organisation structurée. Cette prise de Page 197

198 Conclusion et Perspectives conscience passe par une démarche de sensibilisation par les éditeurs et/ou intégrateurs qui doivent aussi aider les entreprises durant le processus de déploiement de leur solution. La méthodologie accompagnant la mise en place de ce type de logiciel doit donc être efficace et fiable pour parvenir au résultat escompté tant au niveau technique qu au niveau organisationnel pour l entreprise. Dans le second chapitre nous avons défini le processus de déploiement utilisé par LASCOM, éditeur et intégrateur de sa solution partie prenante des travaux de recherche. Nous avons mis en évidence les principaux verrous induits par ce processus. Aujourd hui, un nombre important d itérations est nécessaire pour spécifier définitivement la solution logicielle en fonction des besoins, d avantages théoriques que pratiques, de l entreprise. L origine de ces itérations provient en particulier de la différence de perception du processus de déploiement entre le client et l éditeur. La problématique pour l éditeur, centre de notre étude dans le cadre de cette thèse CIFRE, repose essentiellement sur un double manque. La manque de méthodologie rapide et efficace pour parvenir à modéliser le système à prendre en compte dans son environnement et surtout le manque d un support accessible par le plus grand nombre d intervenants et ce à tout moment du processus. Le troisième chapitre, nous a permis d analyser les problèmes rencontrés généralement par LASCOM durant le déploiement. Pour améliorer la prestation de l éditeur, trois axes de réflexion émergent de cette étude : les outils, les méthodologies et la communication. D un point de vue outil, les éditeurs ont déjà pris conscience du problème en proposant des offres plus adaptées au marché et plus rapide à déployer. Le nouvel enjeu se situe sur l adaptabilité du logiciel aux différentes contraintes imposées par le client mais aussi et surtout à l utilisateur. D un point de vue méthodologique, l enjeu réside essentiellement sur l accompagnement du client dans ce projet d implémentation tant sur les concepts que sur la prise en compte de l utilisateur tout au long du cycle de vie de l application. Du point de vue de la communication, le problème subsiste entre l éditeur et le client tant sur le suivi du déroulement du projet, les impacts des choix opérés, etc., que chez le client sur la communication autour du projet en général, son avancement, ses conséquences, etc. De ces trois points ressort un élément majeur : la prise en compte active de l utilisateur tout au long du cycle de vie de l application. En effet, la force de l application (et donc la rentabilité du projet) passe par sa pertinence et son utilisabilité. Pour ce faire il faut se centrer sur l utilisateur qui constitue le premier engrenage de la chaîne par l emploi de l application et le Page 198

199 Conclusion et Perspectives dernier par la validation ultime de la pertinence de la solution déployée. Il doit être le centre des préoccupations du client et de l éditeur et ce dès le début du projet et jusqu à la fin de l utilisation de l outil. La première partie des résultats de notre analyse est présentée dans le quatrième chapitre à travers la proposition d un premier support au déploiement d un logiciel de type PLM. Elle repose sur l utilisation des cartes heuristiques durant l ensemble du cycle de vie de l application. L idée est de constituer un document unique pour le suivi du projet et plus généralement des différentes activités liées à l application. Grâce à une structure préétablie et aux concepts même des map, le document unique joue le rôle de moteur de la réflexion et de la communication. Cet outil support de la modélisation et de collaboration entre l éditeur et le client permet de construire, comprendre et suivre les étapes de conception et les impacts des décisions. En effet, les cartes offrent la capacité de concentrer un grand nombre d informations hiérarchisées dynamiques et «immédiates», offrant une vision globale, commune et synthétique de l ensemble des paramètres à prendre en compte pour fonder l application et plus généralement réaliser une intervention. L intégration de toutes ces informations favorise la communication et une meilleure compréhension des problématiques fonctionnelles et techniques des deux parties aboutissant au choix de solutions plus adaptées et consolidées en un optimum global. La simplicité du support rend accessible la modélisation et la compréhension du cheminement à un plus grand nombre de profils d intervenants potentiels au cours du processus. Ainsi tous les acteurs partagent le même niveau d information et la même vision du projet facilitant la communication et la participation proactive, vecteurs d amélioration et d appropriation de l application. Le cinquième chapitre se focalise sur un outil permettant à la fois d améliorer le niveau de communication sur le projet envers les futurs utilisateurs tout en accroissant la connaissance des besoins réels de ces derniers. En effet, malgré la simplicité des cartes, il n est pas possible de faire participer tous les utilisateurs, seuls détenteurs du fonctionnement réel du système grâce à leur perception locale de celui-ci et dont les a priori jouent un rôle crucial sur le devenir de la solution. Notre proposition repose sur un second formalisme, le persona qui peut être utilisé soit pour apporter des éléments concrets lors de la création de la carte, soit pour affiner ou valider les résultats contenus dans la carte heuristique. L objectif est de créer des archétypes personnifiés des profils utilisateurs définissant leurs besoins et leurs difficultés à partir d un questionnement direct des intéressés. L intérêt est d instaurer un mode Page 199

200 Conclusion et Perspectives de communication autour du projet (l avancement, les choix, etc.), d accroître la contribution d un maximum d acteurs afin d améliorer le choix des solutions et de minimiser la résistance aux changements. Une meilleure compréhension des besoins et des utilisations, que ce soit en amont du projet ou durant l exploitation doit permettre d assurer une meilleure adéquation des solutions techniques locales comme globales, gage d un optimum global tout au long du cycle de vie de l application. De plus, cette technique sensibilise les clients, et plus particulièrement les décideurs, sur l importance de la prise en compte des utilisateurs pour sortir de la généricité définissant les besoins globaux. Que ce soit lors de la modélisation amont ou lors de l évaluation des évolutions, la bonne définition des besoins locaux maximise le taux de réussite du projet et plus particulièrement le taux d adéquation de l application aux besoins et usages réels. Le sixième chapitre illustre comment nos propositions pourraient potentiellement améliorer le déroulement des phases du processus de déploiement de LASCOM au travers d études de cas «classiques» réelles de chez LASCOM. Quelque soit l entrée dans le processus et quelque soit le projet (la maturité, l envergure, la méthode de gestion de projet, etc.), notre proposition offre la possibilité de partager un support riche, flexible, simple et accessible entre le client et l éditeur et centré sur l application. L objectif de notre proposition n est pas de trouver une méthode pour prémunir les éditeurs des problèmes liés au contrat ou pour choisir une méthode de gestion de projet mais de faciliter le déroulement de l ensemble des étapes du déploiement d une solution. L important est que celles-ci soient toutes réalisées à moindre frais (sans prendre trop de temps) tout en partageant un même niveau d information avec le client sur ce qui lie sur le long terme un éditeur et un client c'est-à-dire le cycle de vie de son application. Perspectives industrielles pour LASCOM : projets sur les phases amont du processus Aujourd hui grâce aux outils de prospection et de marketing toujours plus performants, il arrive plus régulièrement à LASCOM d entrer en contact avec un client avant même qu un projet d implémentation d un PLM soit en cours d étude. Cette prise de contact très en amont du projet implique généralement que le client entrevoit un potentiel à l informatisation mais sans avoir obligatoirement bien déterminé un besoin, soit parce qu il n entrevoit pas un projet immédiatement mais il a déjà des idées, soit parce qu il ne sait pas par ou commencer Page 200

201 Conclusion et Perspectives l analyse de ses besoins. La prospection constitue pour lui une approche intéressante car il n a pas à chercher quel type de logiciel existe sur le marché, c est l éditeur qui vient à lui! Le but de l éditeur étant de se différencier en amont pour orienter le choix final. Autrement dit, dans les deux cas, le rôle du commercial est d apporter un maximum d arguments ciblés pour pousser l implémentation de sa solution au sein de l entreprise. Aujourd hui les outils à sa disposition pour assoir son argumentaire sont de deux ordres : - une intervention gratuite de l avant vente pour illustrer ses propos et les besoins émis par le client, - la vente d un service pour l accompagner dans la détection de ses besoins. Il est entendu que la première prestation correspond en une présentation orientée d une solution type sous forme d une démonstration, tandis que la seconda correspond à la réalisation d un audit spécifique couteux car cette compétence ne fait pas partie du métier d un éditeur, mais plutôt d un consultant. Dans les deux cas, LASCOM n a ni une méthode ni un support adapté à fournir au client potentiel. Chacun de ces éléments n a pas les mêmes fins. La méthode doit aider à faire émerger le projet en créant le cadre du besoin et le support doit asseoir la vision du client par rapport à la solution, voire ajouter des besoins. Le choix de l un ou l autre sera fonction de différents éléments : la maturité du projet mais aussi et surtout évidemment les capacités financières. Ce point est crucial essentiellement pour les cas d émergence d un projet au regard des coûts d un audit spécifique. Malgré tout la taille ou plutôt les capacités internes de l entreprise peuvent également entrer en compte. Si un service DSI (Direction des services informatiques) est présent une partie de l expertise peut alors être réalisée en interne. Le problème se pose donc plus particulièrement pour les petites et moyennes entreprises voire les associations qui elles n ont pas de gros moyens pour réaliser ce type d étude ni en interne, ni en externe que ce soit par un consultant indépendant ou un éditeur/intégrateur. Cependant sans accompagnement pour réaliser cette étude, aucun projet ne sortira, l entreprise restera dans l immobilisme et l éditeur perdra un projet potentiel, si son logiciel correspond bien au besoin. Ainsi le calcul du coût de l audit est un vrai problème. D un coté il ne faut pas qu il soit trop couteux sinon l entreprise ne pourra pas acheter la prestation ou alors son coût sera retiré du budget du projet déjà calculé au plus juste. D un autre coté le potentiel détecté ne sera pas forcément transformable en projet. Malgré tout d autres critères entrent souvent en jeu dans ce calcul. Par exemple, les éditeurs font assez régulièrement de petits «sacrifices» quand ils sont convaincus du potentiel du projet, d autant plus s il peut apporter en notoriété sur un nouveau type de projet ou de marché. Page 201

202 Conclusion et Perspectives Finalement, aujourd hui l accompagnement pour définir les besoins et identifier les projets correspond à une vraie demande, d où l essor du consulting sur ce marché. Les propositions faites par ces derniers sont généralement couteuses car elles comportent la rédaction du cahier des charges très détaillé, censé améliorer le déroulement du projet. Or comme nous l avons vu dans cette thèse, quelque soit la qualité du cahier des charges, une analyse complémentaire par l éditeur est obligatoire pour mettre en perspective les besoins réels (non interprétés) par rapport au logiciel choisi et pour aider au choix de la solution la plus adaptée. Autrement dit, logiquement cette prestation n est pas déductible du temps et du coût du projet. Cette solution ne répond donc pas au besoin de petites et moyennes entreprises. Dans leur cas, le besoin n est pas de réaliser un cahier des charges poussé mais de «dégrossir» le contour fonctionnel et déterminer les besoins majeurs pour évaluer et valider l intérêt de lancer un projet d informatisation. Ceci n est rendu possible que par une présentation avant vente plus précisément adaptée aux besoins des PME et des arguments commerciaux plus solides. Ce type de support ne faisant pas partie du cœur de métier des éditeurs, ceux-ci sont généralement pas ou mal armés pour fournir cette aide facilement et à bas prix. Nos propositions ouvrent de nouvelles perspectives aux commerciaux qui demain posséderont ainsi deux outils supplémentaires à leur disposition pour répondre à ce type de besoin. Le premier outil basé sur les cartes heuristiques pourrait être une proposition de «mini forfait» comportant la présentation/formation à la démarche d analyse basée sur les heuristiques. Une telle démarche contribuerait à initier l analyse du besoin basée sur l exploration du fonctionnement de l entreprise par un certain nombre de personnes, puis l analyse des résultats au regard de son logiciel. Ceci nécessite que l entreprise soit en capacité de créer un groupe de réflexion avec au moins une personne fixe, pour conserver la vision d ensemble et animer l exploration. Le second outil s appuie sur les questionnaires persona concernerait surtout une proposition de présentation/formation à la démarche centrée sur l acteur, permettant de lister les besoins réels en questionnant directement les personnes, et faisant l analyse des retours. Dans les deux cas, la présence de l éditeur est nécessaire pour expliquer la démarche et aider à analyser les résultats. Mais l étape d identification, étape qui est la plus longue et la plus couteuse, nous pouvons imaginer que le client sera laissé en autonomie partielle voire totale. En effet, au regard de la simplicité des formalismes et dans le but de diminuer les coûts, l entreprise peut avancer seule sur la description de son besoin. Avec de telles propositions, le critère de choix ne sera plus d ordre financier ou lié à la taille de l entreprise mais plutôt sur le choix de la méthode que souhaite l entreprise : si elle Page 202

203 Conclusion et Perspectives veut et peut mettre en place un groupe de travail pour définir la vision globale de ses besoins elle choisira de travailler avec les cartes heuristiques, si elle veut obtenir une vision locale des besoins du terrain, elle optera pour persona. C est deux méthodes sont complémentaires uniquement dans le cas d une analyse précise, autrement dit, il est tout à fait possible de proposer les deux méthodes en les décalant dans le temps, l une permettant de compléter et valider les résultats de l autre. Finalement grâce à l une ou l autre des méthodes, ou les deux, le client peut prendre conscience des difficultés et des besoins émanant du cœur de son entreprise, il a muri son besoin et évalué ses attentes. La proposition d une intervention d avant vente prend alors toute sa pertinence car cette prise de conscience rend le client plus réceptif et la démonstration sera orientée essentiellement sur le cadre fonctionnel déterminé. Le but étant de prouver l adéquation et les avantages de l outil et provoquer le déclenchement d un projet avec l éditeur. Que cette étude débouche sur un projet ou non, la mise en place de l une ou l autre des méthodes apporte un double avantage pour l éditeur. D une part il accroît sa notoriété et se place en tant qu interlocuteur privilégié. D autre part il réalise une étude de marché gratuite, sur les évolutions et les améliorations à prendre en compte dans ses applications pour coïncider avec sa cible, basée sur des retours d expériences concrets tant sur le mode de fonctionnement de ses clients potentiels, que sur les besoins inhérents. Perspectives de recherche Les perspectives de recherche de cette thèse s articulent autour de trois axes. D une part, nos recherches doivent être approfondies au niveau des thématiques relatives à la modélisation d entreprise. Notre map générique et l utilisation de persona ouvrent selon nous de nouvelles perspectives au niveau de la modélisation d entreprise et notamment dans l approche de modélisation ascendante. Dans leurs travaux, Girard et Robin [Girard, 06], [Robin, 10] ont montré la nécessité de prendre en compte des vecteurs de performance globaux (niveau entreprise) et locaux (niveau des acteurs). Les map et persona peuvent contribuer à mettre en évidence ces vecteurs par une approche au plus près de l acteur et par un travail continu de fond sur un support accessible à tous. D autre part, le fait que nous soyons centrés sur les acteurs et que nous cherchions à comprendre la place des utilisateurs dans l entreprise nous conduit tout naturellement à imaginer des perspectives autour de la mise en évidence, à travers nos propositions, de la culture organisationnelle des entreprises. Les travaux menés dans laboratoire IMS par Topliceanu sous la direction de messieurs Girard et Robin [Topliceanu, 08a], [Topliceanu, Page 203

204 Conclusion et Perspectives 08b], [Topliceanu, 10] ont montré comment la culture organisationnelle agit sur l acteur à chaque niveau décisionnel et qu il fallait avoir une vision plus détaillée sur les éléments de la culture et ses formes de manifestation pour comprendre son influence sur la performance de l acteur. Il faut notamment être en mesure de suivre l apparition et la formation des éléments constitutifs de la culture organisationnelle. Les normes de comportement, les rites et les cérémoniaux influencent les perceptions, ceux-ci conduisent à la formation des certaines représentations de la réalité et celles-ci à leur tour influencent l apparition des petites histoires, des légendes et des mythes. La chaîne d influence continue ainsi jusqu à la construction de valeurs communes qui soutiennent les croyances, les tabous, les traditions, les symboles et conduisent à la formation et l appropriation des rôles, des principes et du statut des individus ce que détermine finalement leurs normes de comportements, leurs «rites» et leur propre culture organisationnelle. Notre approche proche des acteurs et représentative de leur vision de leur réalité de l entreprise sur le long terme (le cycle de vie d une application pouvant être long) peut aider à la mise en évidence d une partie des normes de comportement et de leur évolution. Nous aurons donc à cœur à explorer ces pistes de recherche. Enfin, au-delà de la culture organisationnelle, il semble que nos propositions peuvent aussi être perçues sous l angle de la thématique de la capitalisation de connaissances. Aujourd hui notre objectif ne concernait «que» l identification, la définition et la capitalisation des éléments «utiles» à LASCOM. Ainsi, si nous allons au-delà de cette vision restrictive et que nous complétons et enrichissons nos modèles, nous devrions être en mesure de capitaliser des éléments plus larges de la connaissance dans l entreprise. L un des premiers éléments à développer dans nos map concernera les collaborations entre acteurs. Nous sommes actuellement centrés sur des aspects très pratiques d échanges de données et nous pensons pouvoir compléter nos modèles pour arriver à capitaliser des éléments plus pertinents notamment en vue du pilotage des activités collaboratives comme ceux décrits par Robin et al. [Robin et al., 07] [Baczkowski et al., 08b]. Ces travaux seront à mettre en parallèle de ceux que nous mènerons dans le cadre de la modélisation d entreprise. Page 204

205 Bibliographie personnelle Bibliographie personnelle [Baczkowski et al., 08] Baczkowski M., Rose B., «Capitalisation des connaissances et aide décisionnelle en phase d industrialisation : le cas de Sony Alsace», 7ième conférence internationale de Modélisation et Simulation, MOSIM 08, pp , ISBN : , Paris (France), 31 mars 2 avril [Baczkowski et al., 08] Baczkowski M., Robin V., Girard P., «Applying a design system modeling approach to deploy the ADVITIUM PLM solution in enterprises», European Symposium on Innovative Management Practices, ERIMA 08, Porto (Portugal), 6 7 November [Baczkowski et al., 08] Baczkowski M., Rose B., Robin V., «Capitalisation des connaissances et aide décisionnelle en phase d industrialisation : le cas de Sony Alsace», Logistique & Management vol. 16, n 1, pp , [Baczkowski et al., 12] Baczkowski M., Robin V., Rose B., «Using of the concepts of roles and context in a project management / plm solution: the real case study of LASCOM», Engineering Systems Design and Analysis, ESDA 2012, Nantes, 2-4 July Page 205

206

207 Bibliographie Bibliographie A [Abdmouleh 04] Abdmouleh A., «Composants pour la Modélisation des Processus Métier en Productique, basés sur CIMOSA», Thèse de doctorat Ecole Nationale d'ingénieurs de Metz (ENIM), Metz, 15 Septembre2004. [AFNOR X50-105, 94] Norme : Management de Projet, [AFNOR X50-176, 00] [AMICE, 93] [Auzelle et al., 08] B [Baczkowski et al., 08a] [Baczkowski et al., 08b] [Baczkowski et al., 12] [Benali et al., 2002] [Bidan, 2004] [Bissay et al., 08a] [Bissay et al., 08b] Norme : Outils de management - Management des processus, édition juin ESPRIT Consortium AMICE, CIMOSA - Open System Architecture for CIM, Springer-Verlag, Berlin, ISBN , ISBN , Auzelle, J.P., Morel G., Panetto H., Mayer F., Using Systems of Systems Engineering to Improve the Integrationof Enterprise-Control Systems, Special issue on Systems Engineering: Best of France. 11/3. Insight journal of INCOSE, juillet Baczkowski M., Robin V., Girard P., «Applying a design system modeling approach to deploy the ADVITIUM PLM solution in enterprises», European Symposium on Innovative Management Practices, ERIMA 08, Porto (Portugal), 6 7 November Baczkowski M., Rose B., Robin V., «Capitalisation des connaissances et aide décisionnelle en phase d industrialisation : le cas de Sony Alsace», Logistique & Management vol. 16, n 1, pp , Baczkowski M., Robin V., Rose B., «Using of the concepts of roles and context in a project management / plm solution: the real case study of LASCOM», Engineering Systems Design and Analysis, ESDA 2012, Nantes, 2-4 July Benali, K., Bourguin, G., David, B., Derycke, A., Ferraris C., «Collaboration/Coopération», actes des secondes assises nationales du GdR I3, Nancy ; Rédacteur J. Lemaitre, Cépaduès-Editions Décembre Bidan M., «Fédération et intégration des applications du Système d information de gestion», Système d Information et Management, Vol. 9-2, pp.5 24, Bissay A., Lefebvre A., Pernelle P. and Bouras A., «Approche de capitalisation des connaissances au sein des systèmes plm». In 1er colloque international sur les Systèmes Industriels et Logistiques (SIL'08), Marrakech, Maroc, Décembre Bissay A., Lefebvre A., Pernelle P. and Bouras A., Deployment methodology of is. SIG-PLM Workshop (IFIP WG 5.7), Lausanne, Suisse, Juillet Page 207

208 Bibliographie [Bissay et al., 08c] [Bissay, 10] [Blanc, 05] [Blanc, 06] Bissay A., Lefebvre A., Pernelle P. and Bouras A., Integration of business processes and performance indicators in a plm. In International Conference on Advances in Production Management Systems (APMS'08), Espoo, Finlande, Septembre Bissay A., «Du déploiement d un système PLM vers une intégration des connaissances», Thèse de doctorat en Informatique, Université Lumière Lyon 2, soutenue le 12 janvier Blanc S., Interoperability problems: Management of evolution of collaborative enterprises, Interop ESA, Doctorial Symposium, Genève, février Blanc S., Contribution à la caractérisation et à l'évaluation de l'interopérabilité pour les entreprises collaboratives, Thèse de Doctorat de l Université Bordeaux 1, soutenue le 20 décembre [Boboc, 02] Boboc A., «Formes de socialisation dans la conception automobile le cas Renault», Thèse de doctorat de l Ecole Nationale des Ponts et Chaussées, février [Boehm, 81] Boehm, B. W., Software Engineering Economics, Prentice Hall, [Bonnefous, 01] Bonnefous C., Courtois A., «Indicateurs de performances», Editions Hermès, [Booch 00] [Bordegoni et al., 04] [Botta et al, 01] Booch G., Rumbaugh J., «Le guide de l'utilisateur UML», Eyrolles, Paris, Bordegoni, M., Benassi, M., Cugini, U., Cascini, G., Roadmap for the selection and the evaluation of PLM tools in product development processes, in Tools and Methods of Competitive Engineering, Edited by Imre Horwvath, Paul Xirouchakis, Millpress Rotterdam Netherlands, ISBN , Vol.1, pp , Botta V., Millet P.A., Neubert G., The role of Enterprise Modeling in ERP, Implementation, International Conference on Industrial Engineering and Production Management (IEPM'2001), ISBN , Quebec, Canada, August 2001, Book I,pp [Brangier, 10] Ppt Personnas HEC Montreal 2010 [Browne et al., 95] Browne J., Sackett P.J. et Wortmann J.C., Future manufacturing systems- Towards the extended enterprise, Computers in Industry, Vol. 25, n 3, pp , [Buzan, 93] Buzan T., Buzan B., The Mind Map Book, Pearson Education, 277 pages, ISBN , C [Chevallereau, 11] Chevallereau B., «Contribution des nouvelles approches de modélisation à la durabilité des apllications», Thèse de Doctorat de l Ecole Centrale de Nantes, soutenue le 11 février [CIMdata, 2009] CIMdata, PLM Market Growth in 2008, Mid-Year, [Creativité, 12] Site internet site «consacré à l'émergence de la pensée créative des individus et au développement du potentiel créatif des équipes pour innover en entreprise», site consulté en janvier Page 208

209 Bibliographie [Crowston, 97] D [David et al., 01] [Debaecker, 04] [Deladriere et al., 07] [Di Mascolo et al., 00] [Doumeingts, 84] [Ducq, 99] [Ducq, 05] [Duffy et O Donnell, 97] [Dutta, 05] F [Fisher, 06] G [Gervais, 06] [Giard, 03] Crowston K., A coordination theory approach to organizational process design, Organization Science, Vol. 8, n 2, , David, B., Vaisman, G., Saikali, K., «Evolution du Travail Coopératif Assisté par Ordinateur : Vers la TCAO «capillaire»», CITE 2001, Coopération, Innovation et Technologie, Université Technologique de Troyes, Novembre Debaecker D., «PLM, la gestion collaborative du cycle de vie des produits», Product Life-Cycle Management, Hermès - Lavoisier, ISBN : , Deladrière J-L., Le Bihan F., Mongin P., Rebaud D., «Organisez vos idées avec le Mind Mapping», 2 ième édition, éditions Dunod, 400 p., Di Mascolo M., Duri C., Frein Y., «Comparison between three Pull Control Policies : Kanban, Base Stock and Generalized Kanban», Annals of Operations Research, Vol. 93, pp , Doumeingts G., «Méthode GRAI: méthode de conception des systèmes en productique», Thèse d'état : Automatique, Université Bordeaux I, Ducq Y., «Contribution à une méthodologie d'analyse de la cohérence des systèmes de production dans le cadre du modèle GRAI», Thèse de doctorat, Université Bordeaux 1, Bordeaux, Ducq Y., Vallespir B., Definition and aggregation of performance measurement system in three aeronautical workshops using the ECOGRAI method, Production Planning & Control, Vol.16, N 2, p , Duffy A. H. B., O Donnell F., A model of product development performance. Designers The key to successful Product Development, Darmstad Symposium, 3 5 décembre Dutta D., Wolowicz J.P., An Introduction to Product Lifecycle Management, in Proceedings of the 12th ISPE International Conference on Concurrent Engineering: Research and Applications, Fort Worth, Dallas, USA, Fisher D.A., An Emergent Perspective on Interoperation in Systems of Systems, rapport technique, Carnegie Mellon University, Software Enginnering Institute, mars Gervais F., «Combinaison de spécifications formelles pour la modélisation des systèmes d information», Thèse de Doctorat, Université de Sherbrooke, décembre 2006 Giard V., «Gestion de Production», Collection Gestion, Economica, Page 209

210 Bibliographie [Gibert, 80] [Girard, 06] H [Hazebroucq, 99] Gibert, P., «Le contrôle de gestion dans les organisations publiques», Paris, Editions d'organisation, Girard P., Robin V., Analysis of collaboration for project design management, Computers in Industry, vol. 57, pp , Hazebroucq J.M., «La nouvelle conception de la performance: être efficace oui, mais aussi efficient», Revue Gestion,1999. [Hewitt 85] Hewitt C., The Challenge of OpenSystems, Avril I [ICAM, 81] [IFAC IFIP, 97] ICAM Architecture Part II-Volume IV - Function Modeling Manual (IDEF0), AFWAL-TR , Materials Laboratory, Air Force Wright Aeronautical Laboratories, Air Force Systems Command, Wright-Patterson Air Force Base, Ohio 45433, juin IFAC IFIP Task Force, GERAM : Generalised Enterprise Reference Architecture and Methodology, Version 1.4, ISO TC184/SC5/WG1, N398, août [ISO 9000, V. 2000] ISO , «Qualité et systèmes de management ISO 9000», Editions AFNOR, 581p., [ISO 9001, V. 2000] [ISO , 08] [ISO 10007, 03] J [Jacobson 92] K [Kaplan et Norton, 98] L [Laleau, 02] Norme européenne NF EN ISO 9001 version 2000, «Système de management de la qualité Exigences», AFNOR, Norme ISO , «Ergonomie des interactions homme- Machine», conception centrée sur l humain des systèmes interfacés, Norme ISO 10007, «Systèmes de management de la qualité Lignes directrices pour la gestion de la configuration», Jacobson I., Christerson M., Jonson P., Övergaard G., Object- Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, Reading, March Kaplan R.S., Norton D.P., «Le tableau de bord prospectif. Pilotage Stratégique : les 4 axes du succès», Editions d Organisation, Laleau R., «Conception et développement formels d applications bases de données.», Habilitation à diriger des recherches, Université d Evry Val d Essonne, Page 210

211 Bibliographie [Le Duigou, 10] [Le Masson et Weil, 05] [Le Moigne, 90] [Lonchampt, 04] M [Mayer et al., 95] [Mayer et Auzelle, 07] [Midler, 97] [Millet et al, 05] [Millet, 08] [Morlay, 01] [Munoz, 02] N [Neubert, 09] O Le Duigou J., «Cadre de modélisation pour les systèmes PLM en entreprise étendue Application aux PME mécaniciennes», Thèse de doctorat, Ecole Centrale de Nantes, Le Masson P., Weil B., «De la conception réglée à la conception innovante : raisonnements et organisation pour domestiquer l innovation», Journées GPS, «Vers une conception et une conduite de projet intégrées», 30 juin et 1 ier juillet 2005, Toulouse. Le Moigne J. L., «La modélisation des systèmes complexes», Bordas, Lonchampt P., «Co-évolution et processus de conception intégrée de produits : Modèle et support de l'activité de conception», Thèse de l INPG de Grenoble, juin Mayer R.J., Crump J.W. Fernandes R., Keen A., Painter M.K., Information Integration for Concurrent Engineering (IICE) comprendium of methods report, Interim Technical Paper for Period February 1991 to March 1995, Mayer, F. and Auzelle, J-P., Is system of systems a candidate rationale artifact for entreprise information-intensive system modeling?, in 9th International Conference on The Modern Information Technology in the Innovation Processes of the Industrial Enterprise, MITIP 2007, Florence, Italie, Midler C., «Evolution des modèles d organisation et régulations économiques de la conception», Annales des mines, Millet P-A, Neubert G., Botta-Genoulaz V., «Une approche outillée de l'intégration», 6e Congrès international de génie industriel, Besançon, 7-10 juin Millet P-A, «Une étude de l intégration organisationnelle et informationnelle Application aux systèmes d informations de type ERP», Thèse de l INSA de Lyon, octobre Morlay C., «Gestion d un projet système d information Principes techniques mise en œuvre et outils», Dunod, Paris, Munoz Zarate S., «Coordination, intégration et innovation dans le système de conception international de l industrie des équipementiers automobiles», Thèse de doctorat de l INPG, Neubert G., «Intégration et collaboration dans les entreprise en réseau», Habilitation à diriger des recherches à Université Lumière Lyon II, décembre [O Brien et Marion, 97] O Brien J., Marion G., «Les systèmes d information de gestion», 1997 Page 211

212 Bibliographie [OMG, 03] [Ostergaard et Summers, 03] P [Parsaei et Sullivan, 93] Object Management Group, OMG Unified Modeling Language Specification, Version 1.5 formal/ , Mars Ostergaard K., Summers J.D., A taxonomic classification of collaborative design process, Proceedings ICED 03, Stockholm, août Parsaei H.R., Sullivan W.G., Principles of concurrent engineering, in Concurrent engineering contemporary issues and modern design tools, Chapman & Hall, [Paviot, 10] Paviot T., «Méthodologie de résolution des problèmes d interopérabilité dans le domaine du Product Lifecycle Management», Thèse de Doctorat de l Ecole Centrale de Paris, soutenue le 1 ier juillet [Porter, 86] Porter M.E., «Choix Stratégique et Concurrence», Economica, [Poveda, 01] [Prudhomme, 99] R [Robin et al., 05] [Robin et al., 07] [Robin, 10] [Roboam 93] [Ross, 77] [Rumbaugh 91] S [Sadfi, 02] Poveda O. Pilotage technique des projets d ingénierie simultanée, modélisation des processus, analyse et instrumentation, Thèse Institut National Polytechnique de Grenoble, Prudhomme G., «Le processus de conception de systèmes mécaniques et son enseignement La transposition didactique comme outil d une analyse épistémologique», Thèse de doctorat de l Université Joseph Fourier, Robin V., Sperandio S., Blanc S., Girard Ph., Interactions modelling between factors influencing performance of the design process, Proceedings ICED2005, Melbourne, Australie, Robin V., Rose B., Girard P., Modelling collaborative knowledge to support engineering design project manager, Computers in Industry, vol. 58, pp , Robin V., Girard P., An integrated product-process-organization model to manage design system, International Journal of Product Development, vol. 10, pp , Roboam M., «La méthode GRAI, principes, outils, démarche et pratique», Teknéa, Toulouse, Ross D.T., Structured Analysis (SA): A Language for communicating ideas, IEEETransactions on Software Engineering, Vol. SE-3, Rumbaugh J., Blaha M., Premerlani W, Eddy F., Object Oriented Modeling and Design, Sadfi C., «Problèmes d ordonnancement avec minimisation des encours», Thèse Institut National Polytechnique de Grenoble, Page 212

213 Bibliographie [Sansonnet 04] Sansonnet J-P., «Approches de l'hétérogénéité Sémantique entre Agents Informationnels», cours en ligne, dernier accès janvier 2012, cours mis en ligne en janvier [Sauser, 06] [Scheer 99] [Shorter 00] [Sudarsan et al., 05] [Sudarsan et al., XX] T Sauser, B., Boardman J., From Prescience to Emergence: Taking Hold of System of Systems Management 27th American Society for Engineering Management National Conference, October 26-28, Huntsville, USA, Scheer A.W., ARIS-Business Process Modeling, Springer-Verlag, Berlin, Shorter D., Enterprise Integration framework for Enterprise Modeling, Revision of ENV 40003, Second Internal Draft, Sudarsan R., Fenves S. J., Sriram R.D., Wang F., A product information modeling framework for product life cycle management, Computer-Aided Design, Vol. 37, n 13, pp , Sudarsan R., Fenves S. J., Sriram R.D., Wang F., A product information modeling framework for product life cycle management, Computer-Aided Design, Vol. 37, n 13, pp , [Tardieu et al., 83] Tardieu H., Rochfeld A. et Colletti R., «La méthode Merise : Principes et outils», tome 1, Paris, Éditions d'organisation, 328 p., ISBN X et , [Tardieu et al., 85] [Tomala, 02] [Topliceanu et.al, 08a] [Topliceanu et.al, 08b] [Topliceanu, 10] [Tudor, 06] Tardieu H., Rochfeld A., Colletti R., Panet G. et Vahéee G., «La méthode Merise : Démarches et pratiques», tome 2, Paris, Éditions d'organisation, 460 p., ISBN , Tomala F., «Proposition de modèles et méthodes pour l'aide à l'évaluation des performances d'une innovation dès sa conception», Thèse de Doctorat, Université de Valenciennes et du Hainaut Cambrésis, Topliceanu G. D., Robin V., Girard Ph., Ispas C., Ensuring design system efficiency by managing its performance inductors, Academic journal of manufacturing engineering, Timisoara, vol.6, n 1, 008 Topliceanu G. D., Robin V., Merlo C., Girard Ph., A preliminary approach to consider organizational culture in the strategic design project management, Proceedings of ERIMA08, 6-7 th November, Porto, Portugal, Topliceanu G., «Prise en compte de l influence de la culture organisationnelle pour la conduite des activités de conception collaboratives», thèse de Doctorat de l Université Bordeaux 1, soutenue le 6 janvier Tudor CRP H., «Modélisation des processus métiers : Etat de l'art et conseils pratiques», Rapport de veille et recommandations, CITI, Page 213

214 Bibliographie V [Vernadat 96] Vernadat F., Enterprise Modeling and Integration: Principles and Applications, Chapman&Hall, Londres, [Vernadat 99] Vernadat F.B., «Techniques de modélisation en entreprise : applications aux processus opérationnels», Economica, Paris, [Volle,06] Volle M., «De l Informatique : Savoir vivre avec l automate», Economica, 2006 W [WfMC 99] [Williams, 92] WfMC, Workflow Management Coalition, Interface 1: Process Definition Interchange Process Model Document WfMW-TC-1016-P, P_v11_IF1_Process_definition_Interchange.pdf, Williams T.J., The Purdue Enterprise Reference Architecture, Instrument Society of America, Research triangle Park, NC, Page 214

215 Annexes Annexes Annexe 1. Des solutions logicielles au cœur de la «r»évolution : ERP et PLM Longtemps la notion de Système d Information comme nous l avons décrite précédemment est demeurée assez floue pour les entreprise et lorsqu une société se lançait dans une politique «d informatisation» cela se traduisait souvent par la mise en place d un nouvel outil pour et dans un seul service, pour un cadre fonctionnel réduit indépendamment des autres services. C est ainsi qu aujourd hui les entreprises se retrouvent avec bon nombre de logiciels informatiques relativement dédiés qui permettent d assurer la gestion des relations clients (CRM), la gestion et les opérations de l entreprise (ERP), le suivi du cycle de vie des produits/projets (PLM), etc. [Sudarsan et al., 05]. Leur principal but est d aider au déploiement d une stratégie d entreprise en apportant, à l ensemble des utilisateurs, une automatisation d une démarche ou d une méthode et une base de connaissance issue de la capitalisation de l expérience. Nous assistons actuellement à une redéfinition des contours de ces outils avec pour visée l atteinte d une cohérence globale pour maximiser la mutualisation des applications et répondre à un niveau d interopérabilité important. Ce souci d inscrire efficacement les outils dans Système d Information (SI) efficace et efficient traduit le souhait des entreprises de voir en leur SI un élément primordial d aide au pilotage et à la conduite de leurs activités. Tout ceci semble devenir possible grâce à cette informatisation massive et transverse aux services de l entreprise qui contribue à faciliter et à centraliser les informations dans des outils appropriés sous un format exploitable voire exportable. Dans le cadre de nos travaux de recherche, nous allons essentiellement nous intéresser à deux types d outils : les ERP pour ce qui concerne la gestion intégrée des activités de l entreprise et les PLM qui participent au suivi du cycle de vie des produits Enterprise Ressource Planning (ERP) - Progiciel de gestion intégré Pendant longtemps les industriels se sont concentrés sur l optimisation de leur ligne de production en utilisant les moyens mis à leur disposition telle que l automatisation, la robotisation ou la délocalisation afin de diminuer le ratio coût/temps. Or la multiplicité et la complexité des produits à fabriquer ont rendu ces solutions insuffisantes pour accroître durablement la performance de l unité de production, tout en conservant une politique de réduction des coûts et sans risquer de provoquer l arrêt de la production pour des raisons matérielles. C est dans ce contexte que la première orientation stratégique d informatisation Page 215

216 Annexes massive au cœur des entreprises fut centrée sur le système de production (ordonnancement, achat, fabrication, assemblage) et ce grâce à l émergence de logiciels intégrés : les ERP (Enterprise Ressource Planning). Ces derniers calculent et surtout planifient les besoins en composants par période et ce, à partir des nomenclatures et stocks intermédiaires de niveau en niveau. Dès la saisie et le traitement de l information stockée dans la base de données, ce progiciel informatique de gestion impacte en temps réel l ensemble de la chaine de production, représentée par différents modules [Bidan, 04]. L objectif principal d un ERP est de simplifier les flux et processus d une entreprise et de diffuser l'information en interne de manière optimale. Cette facilité de circulation de l'information permet d'élaborer des outils puissants de gestion et d'analyse, et donc d'aide à la décision. Il doit ainsi permettre à l entreprise d être plus opérationnelle et plus réactive. S'il est difficile de quantifier avec précision le retour sur investissement et les bénéfices nets comptables, l'erp reste indispensable et sa contribution à la performance de l'entreprise n'a jamais été démentie. L'automatisation des processus de gestion qu'il couvre assure des gains de productivité essentiels, voire impératifs : meilleure qualité des données, réduction des stocks, diminution des coûts administratifs et de production. Cependant, après une période où les investissements étaient perçus comme d'éventuels leviers de croissance (création de valeur), les Directions des Systèmes d'information sont désormais systématiquement tenues de justifier leurs dépenses et de limiter les coûts. Or, un ERP représente un poste de dépenses lourd, tant lors de la mise en œuvre du projet que durant la période de fonctionnement. C est pourquoi au delà de l optimisation du système de production en termes de gestion, la capacité et la qualité de la collaboration de l ensemble des acteurs de la chaine deviennent des critères prépondérants dans le choix et la mise en place de ce type de progiciel. Autrement dit, il est crucial, en termes de flux, que la propagation et la réutilisation des informations au sein de ce logiciel, pour les différents services interconnectés, mais surtout au sein de l ensemble des applications métiers de l entreprise, fasse partie intégrante de la solution pour accélérer la production durablement. L objectif complémentaire de ce type d investissement est de répondre facilement et rapidement au besoin de gestion mais également aux nouveaux besoins des différents services à travers l ERP ou via le système d information dans lequel il s intègre Product Life Management (PLM) - Gestion du cycle de vie du produit La demande client croissante, en termes de nouveautés et de qualité, et la concurrence omniprésente se durcissant, l innovation devient le maitre mot pour toutes les entreprises en Page 216

217 Annexes respectant les contraintes temporelles, le «time to market» se réduisant de jour en jour, mais également les contraintes réglementaires tout au long du cycle de vie du produit (de sa conception à son recyclage). Après s être concentré sur ce qui semblait être les éléments clés de l entreprise (la ligne de production, puis le système de production), petit à petit les industriels ont perçu le besoin d optimiser l ensemble de la fabrication, c'est-à-dire en amont comme en aval de la production. En effet, la connaissance et la maitrise du produit se situent non seulement lorsque le produit est matérialisé, mais bel et bien tout au long de son cycle de vie, que les activités et les ressources soient internes ou externes à l entreprise. Dans la littérature on distingue deux définitions du cycle de vie : le virtuel et le réel [Le Duigou, 10], ce dernier correspondant aux composantes où le produit a une réalité physique. Ce cycle est décomposable en huit étapes chronologiques : l émergence d un besoin et son identification, la recherche des concepts permettant de répondre à ce besoin, la spécification des solutions envisagées, le prototypage des solutions sélectionnées, l industrialisation de la solution retenue, la fabrication et la mise sur le marché du produit fini, finalement extérieurement à l entreprise, l utilisation par le consommateur du produit et sa fin de vie. Inclure ces deux dernières étapes permet de prendre en considération les retours client, tant d un point de vue utilisation et (in)satisfaction que les besoins connexes initiés par cette nouveauté, dans le cycle de vie du produit. Ce sont les vecteurs principaux d identification des nouveaux besoins et les indispensables sources d innovation en termes de produit, de marketing, de conception, de recyclage Dans le cadre du cycle de vie réel, cette fois le bouclage est possible essentiellement en considérant l utilisation de matières recyclées. Geram [IFAC, 97] propose un découpage chronologique des phases (Figure 55) : Figure 55. Phase du cycle de vie d un produit Page 217

218 Annexes D un point de vue organisationnel, cette schématisation séquentielle correspond en réalité à une vue très simplifié de la figure 3 illustrant les interactions et de l ordonnancement des étapes, tout au long du cycle de vie du produit [Sudarsan et al., 05] (Figure 56). Figure 56. Cycle de vie d un produit Cette nouvelle considération du produit par les industriels signe un tournant stratégique important et sonne l arrivé du PLM (Product Life Management) au cœur des entreprises. CimData [CimData, 09] définit le PLM comme : une approche stratégique qui met en œuvre un ensemble cohérent de pratiques permettant de supporter la création collaborative ainsi que l organisation, la diffusion et l utilisation des informations relatives à la définition du produit au travers de l entreprise étendue, de la conception à la fin de vie, et d intégrer les hommes, les processus, les systèmes d organisation et d information. Ainsi le PLM est avant tout une stratégie qui englobe la définition du produit mais également la définition des moyens de production, des services liés au produit, (services durant son utilisation mais également services de maintenance, de traitement en fin de vie ), des technologies mises en œuvre, des organisations le concernant mais également les différentes ressources et toute l orchestration nécessaire aux différentes activités mises en œuvre pour donner «vie» au produit [Le Duigou, 10]. Or au vu de la croissance exponentielle de variétés et de variantes des produits, amplifiée par les résultats concluant de l ERP sur la fabrication, Page 218

219 Annexes l informatisation de cette démarche est devenue inévitable pour généraliser et capitaliser les connaissances détenues par chacun des acteurs de la naissance de l idée à la fabrication du produit et ce, pour chaque produit/projet. En cherchant à formaliser et standardiser une méthodologie, les entreprises ont pris conscience que leur savoir faire, selon ce point de vue, répondait d avantage aux contraintes d un produit/projet qu à une structure organisationnel hiérarchique comme précédemment. Cette fois le support logiciel doit être, pour répondre efficacement aux besoins, axé sur les différents produits/projets et leur environnement propre et doit favoriser la collaboration de l ensemble des acteurs agissant sur le produit. Fonctionnellement le logiciel support à cette systématisation méthodologique, quelque soit l équipe en charge (interne ou externe à l entreprise), doit : - Gérer une quantité importante d informations complexes pour chacun des produits/projets, - Gérer les différentes vues métiers, de ces informations, nécessaires aux différents intervenants, - Gérer l intégrité des données et la traçabilité des actions/modifications opérées sur le produit au cours du temps. Autrement dit, cette informatisation engendre la nécessité de structurer les données et de modéliser l organisation, pour mettre à disposition tout ou partie des informations nécessaires aux activités des utilisateurs et faciliter les recherches ponctuelles. L unicité des informations ainsi que la connexion de ces dernières entre elles, offrent la possibilité d étudier d impact de toutes modifications apportées et garantissent la traçabilité de ces dernières. De plus, l utilisation d un cadre formel identique doit également faciliter l analyse et la comparaison des produits/projets et par la même la mise en exergue des bonnes pratiques applicables à nouveau dans le futur en fonction d un certain nombre de caractéristiques. Au regard de la diversité des intervenants durant le cycle de vie du produit, il est essentiel d éviter les ressaisies d informations entre le PLM et les outils métiers. Cette infrastructure modélisée en fonction du besoin actuel, doit être modulaire et interopérable voir interactif avec les différents logiciels utilisés et le système d information de l entreprise pour garantir l utilisation et l utilité du PLM [Dutta, 05]. Finalement, le PLM représente qu un élément du système d information des entreprises industrielles et peut être considéré comme l ERP de la conception des produits. Il a pour rôle de centraliser et d organiser toutes les formes d informations concernant le produit, dont il assure la sécurité, la cohérence et l accessibilité. Les limites du PLM ne correspondent pas Page 219

220 Annexes aux frontières de l entreprise, mais à l ensemble de l environnement du produit. La gestion dynamique de ces informations contribue à la structuration des activités concourant aux différentes phases du cycle de vie et, par le suivi d exécution des projets, instaure une collaboration effective des équipes Comparaison de ces deux outils phares pour les industriels Finalement, l ERP et le PLM sont les deux outils de gestion intégrée les plus prisés par le monde industriel. Leurs implémentations et leurs utilisations croissantes par les entreprises, quelques soient leur domaine d activités et la taille de leur structure, reflètent un besoin de structuration, d uniformisation et de transparence des flux informationnel et transactionnel pour répondre aux contraintes de traçabilité réglementaire mais également pour faciliter la gestion globale de l entreprise. En effet, le premier, l ERP, privilégie l aspect organisationnel de la structure en adoptant une approche transactionnelle tandis que le second un aspect informationnel selon une approche collaborative. Selon la stratégie de l entreprise et les moyens mis en place, cette dernière a tendance à mettre en exergue un des deux modes de fonctionnement en présence l un permettant de gérer le cycle de vie des ressources et des ordres, tandis que l autre le cycle de vie des produits/projets en se basant sur les données techniques et les flux (Figure 57). Figure 57. Complémentarité de l ERP et du PLM Ces deux méthodes ne sont pas antinomiques, bien au contraire, ils sont complémentaires en se concentrant soit sur la production soit sur l innovation & la conception. Ce centrage implique une utilisation différente des données recueillies. D un côté, les aspects transactionnels de l ERP engendrent l exploitation des données immédiates pour Page 220

221 Annexes gérer la production tandis que les aspects informationnels du PLM créent une base de connaissance itérative nécessaire à la réutilisation et l amélioration. Ces différences font que l objectif de l ERP est de maintenir un état stable pour maximiser les profits alors que le PLM est de gérer les changements et les environnements dynamiques pour optimiser la conception. Pour répondre aux besoins de pilotage et de traçabilité, les industriels se tournent majoritairement vers l informatisation. Au regard de la description de ces deux outils, ils permettent non seulement de conserver la flexibilité et l adaptabilité des entreprises à leur environnement mais surtout de maximiser leurs profits. C est pourquoi ces deux outils présentent, individuellement et/ou associativement, un fort attrait pour les industriels en quête d uniformisation, fédération et optimisation de leur processus de gestion incitant l acquisition et l implémentation d un logiciel de gestion. Page 221

222 Annexes Annexe 2. Processus de déploiement d une solution PLM en PMI/PME [Bissay, 10] La mise en œuvre d'une infrastructure autour du PLM est un projet global du SI qui s'inscrit dans une logique de long terme. Aussi, tout projet de déploiement d'un système PLM nécessite de maîtriser les points suivants : - les processus métiers et les refontes éventuelles ; - les processus fonctionnels ; - les migrations de données ; - l'intégration globale avec les autres composantes du SI (comme l'erp) ; - la conduite de changement ; - les supports et la formation. Dans les projets autour des PLM, deux grandes orientations existent. Il y a les projets qui nécessitent de nombreux développements de par l'histoire de l'entreprise, sa complexité, ou les contraintes de son business. Ces projets demandent un fort accompagnement. L'autre tendance, la plus forte actuellement, vise à déployer rapidement son projet, tout en limitant le coût. Pour cela, on cherche en permanence l'adéquation entre les besoins, les gains espérés et les fonctionnalités standards des progiciels. Les restrictions de budgets poussent même à segmenter les projets en petits lots peu onéreux, au risque de dégrader l'objectif global [Debaecker, 04]. Il apparaît important de se situer, et de savoir ce que l'on veut et comment le projet s'intègre dans un projet d'entreprise Les étapes d'un projet PLM Même s'il est difficile d'établir un ensemble d'étapes exhaustif, un projet de type PLM se décompose en trois grandes phases : - la phase d'avant-projet qui débute de l'idée de mettre en place un tel projet jusqu'au choix de la solution, - la phase de mise en œuvre qui va correspondre à l'adaptation du système choisi à l'organisation de l'entreprise, - La phase d'accompagnement et d'adaptation du système qui est une phase transversale généralement incluse dans les deux précédentes et qui permet de garantir l'adéquation et l'adaptation du système aux évolutions du contexte industriel de l'entreprise. Dans cette section, nous définissons les principales caractéristiques de la mise en œuvre d'un système d'information centré sur le cycle de vie des produits. Page 222

223 Annexes 2.2. Méthodologie MPPI Approche globale Le déploiement d'un projet PLM est l'occasion pour une entreprise, même pour une PME/PMI, de remettre à plat certaines méthodes de travail. A défaut, il implique une formalisation de ce qui est actuellement en application dans l'entreprise. Face à ce constat, nous avons bâti notre approche en faisant l'hypothèse que ce travail d'analyse est une source information qui va permettre de faciliter la capitalisation du savoir-faire. Ainsi, la démarche proposée est une approche combinée qui prend en compte la capitalisation du savoir-faire pendant les réflexions menées lors de la mise en œuvre d'un projet PLM. Elle intègre deux aspects complémentaires : - Une approche globale centrée sur un processus de mise œuvre d'un système PLM en PME/PMI. Ce processus métier reprend en partie les trois grandes phases définies à la section précédente, - Une étape d'analyse combinée avec une approche de la capitalisation des savoir-faire. Figure 58. Principe de la méthode MPPI La figure précédente (Figure 58) schématise l'approche proposée dans MPPI [Bissay et al., 08a] [Bissay et al., 08b] [Bissay et al., 08c]. Ainsi, MPPI est structurée autour de deux processus : le processus d'avant-projet et le processus de déploiement. Il est à noter que le processus d'accompagnement et d'adaptation doit être considéré comme un sous-processus transversal, inclus dans les deux premiers. Page 223