Je ne parlerai pas de « méthodologie », mais bien de « méthode » de travail. Je ne cherche pas à philosopher sur les mots, mais j’estime qu’il y a une différence de taille entre « méthodologie » et « méthode ». La méthodologie, c’est celle des intégrateurs : les sociétés de service informatique (SSII) qui vendent des projets dans lesquels une obligation de résultat est attendue. C’est peut être aussi la vôtre, chers clients ou sociétés utilisatrices, dans la mesure où vous menez vous-même votre projet. Dans ce cas, la méthodologie coordonne les techniques, les outils, les normes, les rôles, etc …dans le but de parvenir au résultat convenu. Il est bien entendu que je dois, comme tout intervenant du projet, respecter cette méthodologie qui fait partie du produit vendu par l’intégrateur, et qui représente souvent, son label Qualité.
La Méthode – sous entendue, la Méthode de travail – c’est celle du Consultant. La mienne a une origine : elle vient d’un déclic que j’ai eu, lorsque SAP vint balayer en un projet colossal, les systèmes GPAO de mon employeur Aéronautique de l’époque. Dès 1997, ce fut la découverte d’un mot barbare, sur lequel repose maintenant l’essentiel de mon comportement en clientèle : BPR !
BPR, pour Business Process Re-engineering ! L’art de tout décortiquer pour mieux comprendre. L’art de tout exprimer pour mieux concevoir. Et, lorsque le projet le permet, l’art de tout casser pour mieux reconstruire ! Derrière ce mot inquiétant, synonyme de chamboulement maximal, se cache l’essentiel, la finalité : Formaliser tout ce qui a été dit. Sans pour autant « tout casser », on peut formaliser, sous forme de diagramme, des Processus métier qui ne changeront pas forcément avec SAP. Avec ce même formalisme, on peut dessiner aussi les Processus SAP cible, qui confirmeront, dans le futur système, le métier du client. Rien n’a été cassé, mais tout a été repensé. Cette finalité de Processus repensés à laquelle je m’efforce de parvenir, constitue l’objectif principal de toutes les réunions de travail que je suis chargé d’animer, principalement durant les phases conceptuelles du projet.
De tels documents dans le Dossier de Conception constituent une voie royale pour faire valider la solution cible. C’est comme si on disait : « Monsieur le client, voilà ce que nous avons compris de votre métier, et voilà comment vous allez l’exercer dans SAP ». Ne vous méprenez pas. Ce que je viens d’écrire vous fait peut-être penser à une autre phrase, malheureusement plus connue, et qui colle tristement au métier du Conseil et à certaines SSII : « Exprimer votre besoin, et je vous dirai comment vous en passer ». Non, le Conseil, ce n’est pas ça ! Si parfois SAP ne sait pas faire, il y a d’autres moyens pour prendre en compte le besoin, sans refouler systématiquement ce que l’outil ne sait pas faire. Nous pourrons parler ensemble du plus évident, le développement spécifique, mais aussi nous pourrons nous poser la question de conserver certaines applications existantes. Les deux idées sont généralement délicates, puisqu’elles impactent directement le périmètre négocié du projet. Par contre, ce que je m’efforce de faire sans pour autant augmenter la facture, c’est d’entamer une réflexion sur l’organisation. SAP ne sait pas faire, certes, mais comment peut-on s’organiser en interne pour s’en affranchir, sans trop de dégâts, sans trop de mécontentements, et surtout, sans ruptures abusives de flux. Le client final n’ira pas reprocher à SAP de ne pas gérer un sujet, si son processus métier reste fluide.
Pour estimer cette fluidité, le meilleur moyen reste la représentation du Processus sous forme de logigramme. En voici ci-dessous quelques extraits. Pour des raisons de confidentialité, ils sont volontairement limités à une image restreinte.
Au-delà de cette animation d’ateliers qui mène au formalisme attendu, il y a la phase de réalisation qui va générer des travaux de paramétrage et de développement. Ces travaux se font généralement seuls, et les réunions de travail qui peuvent avoir lieu ne sont là que pour traiter les points délicats ou les oublis éventuels à la Conception. Personnellement, je mets un point d’honneur à la rédaction des fiches de paramétrage. Trop souvent ces fiches ne sont remplies que par des copies d’écran, sans autre explication, sans doute dans la précipitation de restituer une solution en temps et en heure. De tels documents rédigés de cette manière ne servent à rien. Pour ma part, quel que soit les modèles de livrables de l’intégrateur, j’écris, à chaque point de paramétrage, pourquoi le paramètre a été réglé de cette manière. Cette explication peut être précise, ou tout simplement beaucoup plus générale, en se référant par exemple, au paragraphe correspondant du dossier de Conception. C’est une composante essentielle, pour que toute personne arrivant sur le sujet (dans le cadre d’une TMA notamment), puisse reprendre le flambeau dans de bonnes conditions !
Si dessous un exemple de point de paramétrage rédigé. Quelle que soit la méthodologie de l’intégrateur ou du client, je m’efforce d’y aborder, sur chaque customising, trois parties distinctes : Argumentaire fonctionnel (la définition, la raison, l’origine, la justification du paramétrage), Chemin d’accès (Chemin, transactions et ordres de transports) et Paramétrage (la copie d’écran du paramétrage effectué).
Lorsqu’un programme spécifique est nécessaire, il faut que le Consultant fonctionnel transmette au Consultant technique (développeur), le besoin en termes de fonction à réaliser. Je ne suis pas Consultant technique, mais je ne conçois pas, sous ce prétexte, laisser le développeur partir seul à la chasse aux renseignements. Une « spec de développement » doit être précise. Elle ne doit pas se limiter à deux ou trois phrases exprimant littéralement le besoin. Elle doit parler de tables, de zones, de clés, de modules fonctions, de dynpros (écrans), de user exit, etc … C’est ce que je m’efforce de faire, car en tant que fonctionnel, je sais où est l’information, sur quel écran, et quel impact cela peut avoir sur d’autres objets SAP.
Une spécification doit être précise, mais sans toutefois canaliser le développeur sur notre logique. Personnellement, je mets toujours ma petite phrase magique faisant comprendre au développeur que ma logique, c’est ça, mais s’il trouve autre chose de mieux pour parvenir au résultat, qu’il y aille !
Ci-dessous, un extrait d’une spec pour le développement d’un état « 8D » (formulaire Qualité) à partir d’un Avis QM :
