Pierre Mammosser

J'ai, dans les précédents articles de mon "carnet de route", abordé successivement le positionnement des référentiels COBIT, ITIL et CMMI dans la gouvernance SI, l'élaboration de tableaux de bords prospectifs au service de cette même gouvernance SI, la clarification de mes méthodes de formalisation des processus métiers et SI, et un approfondissement du contenu du CMMI. Il me restait, pour boucler la boucle (au moins provisoirement) de cette démarche de remise à niveau de mon expertise en matière de concepts et d'outils de gouvernance SI, à aborder la problématique de l'urbanisation du SI et à travailler la prise en main de COBIT.

Le présent article traite du premier volet de ce "reste à faire". Et comme j'en ai pris l'habitude, c'est par l'intermédiaire de la lecture d'un livre, "Le projet d'Urbanisation du SI - Démarche pratique avec cas concret" de Christophe LONGEPE, que je me suis livré à cet excercice. Je dois également confesser que, n'étant pas un expert en modélisation, j'ai en plus eu recours aux lumières de l'ouvrage "UML2 par la pratique" de Pascal ROQUE.

C'est peut-être une Lapalissade, mais urbaniser pour urbaniser est une perte de temps et donc une perte d'argent. L'urbanisation du SI doit être au service de la stratégie d'entreprise. Christophe LONGEPE l'inscrit même clairement dans une démarche de type schéma directeur, avec alignement de la cible sur les objectifs stratégiques de l'entreprise et définition d'un "plan de convergence" pour la mise en oeuvre. La nécessité d'agilité n'est pas uniforme sur l'ensemble du SI et l'élaboration de la cible doit en tenir compte. Un projet d'urbanisation a avant tout pour objectif de pouvoir ordonnancer la rénovation des blocs applicatifs du SI en fonction des priorités de l'entreprise, tout en sauvegardant la cohérence de l'ensemble.

Le livre propose toute une méthodologie de conduite de cette étude débouchant sur la délivrance du "plan de convergence". Chemin faisant j'ai pu remettre en perspective l'ensemble des outils que j'utilise depuis que j'exerce le métier de consultant. Je ne reviens pas sur la formalisation de la mission, de la vision, et des objectifs de l'entreprise que j'ai déjà abordés par ailleurs. Ni sur la formalisation de l'architecture métier même si je me suis, à ce niveau, rappelé que je dispose aussi d'une méthode d'optimisation des processus. Par contre la formalisation des niveaux fonctionnel et applicatif m'a plus particulièrement intéressé en me permettant de réinscrire mes pratiques concernant ces domaines dans l'état de l'art d'aujourd'hui. Sachant tout de même que pour la définition de la cible fonctionnelle je serai toujours plus enclin à m'appuyer sur l'adaptation de modèles d'architecture existants que de reconstruire totalement une architecture en partant de la feuille blanche.

Je ne voudrais pas terminer ce propos sans évoquer le coût, souvent important, de l'urbanisation d'un SI. L'expérience montre que le coût de mise en oeuvre d'un EAI n'est pas neutre, loin s'en faut. Mais au delà de cet outil, l'enjeu réside également dans la mise à niveau des blocs applicatifs, y compris ceux qui ne sont pas "rénovés". Une mission récente m'a appris combien des évolutions en profondeur de données référentielles pouvaient mettre en difficulté le plus louable des projets d'évolution progressive de SI et/ou d'environnement best of breed. Et j'ai l'impression que dans un certain nombre de secteurs d'activité l'urbanisation se résume souvent à l'organisation de blocs applicatifs satellites, anciens ou nouveaux, autour d'un ERP !

La formalisation des processus métiers et SI fait généralement partie des missions que j'ai  à conduire et à réaliser. Le travail sur les processus peut même constituer le coeur de certaines interventions. L'élaboration des processus de fonctionnement de la centrale d'achat française du groupe Louis DELHAIZE en est un exemple parmi d'autres.

J'utilise les techniques de formalisation acquises lors de mon passage dans le groupe EDS/ATKearney. Des techniques que j'ai néanmoins adaptées, comme il se doit pour tout consultant qui se respecte, à ma propre perception des choses.

Il était donc intéressant de comparer la boite à outils que je me suis ainsi constitué aux principes pronés par les langages de formalisation d'un certain nombre de méthodes du marché. Je me suis, pour ce faire, appuyé sur l'ouvrage intitulé "Processus métiers et SI" rédigé par un groupe d'auteurs : Chantal MORLEY, Jean HUGUES, Bernard LEBLANC et Olivier HUGUES. Ce groupe d'auteurs se donne pour objectif, à travers ce livre, "de proposer des repères pour un usage rigoureux et précis de l'approche processus dans le système d'information". Tout en précisant, une centaine de pages plus loin, que "Dans les années 1980, les méthodes étaient souvent appréhendées avec dogmatisme et devaient être appliquées intégralement. Depuis une dizaine d'années, l'application stricte des méthodes a laissé place à une utilisation plus pragmatique des modèles et diagrammes en fonction des besoins rencontrés".

Il faut reconnaître que "le métamodèle des concepts retenus pour modéliser les processus" ne manque pas d'intérêt et recadre un certain nombre de fondamentaux. Quelques éléments qui se sont estompés à force de pragmatisme vont d'ailleurs retrouver une meilleure place dans ma boite à outils. La confrontation avec des méthodes comme IDF0, OSSAD, UML et MERISE contribue également à l'intérêt de la réflexion. Sachant qu'in fine je me sens plutôt à l'aise avec l'orientation qui semble mise en avant dans l'ouvrage : utiliser le diagramme d'activité d'UML pour la description des processus détaillés, complété d'une expression rédigée pour la description interne de chaque activité (tâches, règles de gestion, choix d'informatisation, ressources informationnelles, et volumétries) et éventuellement, d'un diagramme d'état-transition et d'un diagramme de classe si les ressources informationnelles l'exigent. Je suis à l'aise avec cette formalisation parce qu'elle a montré sa pertinence sur le terrain, notamment au niveau de l'appropriation par les représentants métier.

Reste une dernière question : comment faire pour que l'effort de formalisation consenti par une entreprise traverse le temps, aille au-delà d'une "simple" opération d'alignement stratégique ou de schéma directeur, et contribue à l'amélioration continue de la performance de l'organisation ? Il est vraisemblable qu'il faut, pour ce faire, pouvoir s'appuyer sur un outil. A condition de mettre également en oeuvre les moyens humains et organisationnels nécessaires.

Mon approche de ces réfétentiels est assez récente. 

Elle remonte à18 mois environ, par l'intermédiaire de la lecture d'un ouvrage de référence sur ITIL :"ITIL pour un service informatique optimal". J'ai consolidé cette initiation en participant à un cours "ITIL Foundation". Sans être révolutionnaire, et parfois un peu compliqué, ce référentiel est tout de même particulièrement intéressant, notamment dans le domaine de la gestion des services. Sa mise en oeuvre constitue cependant, à mon avis, un projet d'envergure. Pour avoir restructuré un département production et systèmes et, à deux reprises, conduit un projet d'externalisation, je peux mesurer l'apport d'ITIL, mais aussi les ressources nécessaires à sa mise en oeuvre. Et pour qui a, par le passé, implémenté un progiciel de gestion de parc peut également se rendre compte de l'effort à fournir pour faire fonctionner les outils "haut de gamme" de support de ce référentiel.

Mais ITIL ne constitue pas, loin s'en faut, l'essentiel de la gouvernance SI. Chemin faisant je me suis rapidement rendu compte que c'est COBIT qui est la référence, l'armature centrale, du pilotage et du contrôle du SI. De consultations de sites web en lectures de livres blancs de toutes sortes le doute n'était plus permis : COBIT est bien l'outil de base de la gouvernance SI. Il ne suffisait plus que de décortiquer l'ouvrage de Frédéric Georgel, "IT Gouvernance", pour valider ce constat, boucler la boucle, et repartir sur un troisième acteur... CMMI.

CMMI, le référentiel qui permet de mesurer la maturité des processus d'élaboration des logiciels, est plutôt simple de compréhension. Familier des études mesurant la maturité des organisations, je trouve que cette affaire tombe un peu sous le sens. Sauf que pour ingurgiter l'ensemble il va encore falloir faire un petit effort, en l'occurence la lecture de 571 pages en anglais.

Après plus de 30 ans d'accumulation d'expériences qui m'ont forgé, je le crois sincèrement, une solide expertise en matière de pilotage des SI  je vais poursuivre cette quête pour intégrer le plus complètement possible ces référentiels qui fondent, utilement, le vocabulaire, la démarche et l'environnement global de la gouvernance SI.

Après 24 ans passés dans des postes opérationnels et un apprentissage de 3 ans du métier de Consultant au sein du groupe EDS, j'entame en 2001 une nouvelle étape de ma trajectoire professionnelle dans le cabinet IGROUP Consulting, constitué d'une dizaine de Consultants intervenant en mode freelance.

Deux clients principaux sont au centre de ces six ans d'activités : le groupe DELHAIZE (CORA, MATCH, ...) et POMONA, un des leaders du secteur grossiste alimentaire en France.

L'essentiel des missions a été constitué par de l'assistance à maîtrise d'ouvrage où à maîtrise d'oeuvre : élaboration et optimisation de processus métier, choix de progiciels / ERP, assistance à maîtrise d'ouvrage pour une conception générale SAP, assistance à maîtrise d'oeuvre pour une préparation de projet SAP, assistance au déploiement et à la conduite du changement, PMO, optimisation de la fonction informatique groupe, ...

Dans toutes ces missions, et au-delà des livrables traditionnels, c'est la volonté d'alignement sur les objectifs stratégiques de l'entreprise et les questions de valeur SI, de performance SI et de gestion des risques qui ont été au centre de ma contribution.

Les différentes missions de choix de progiciel / ERP ont également comporté, à chaque fois, un volet d'urbanisation du SI existant pour intégrer le progiciel choisi dans les meilleures conditions.

Réussir une activité de Conseil c'est, tôt ou tard, savoir se spécialiser dans un domaine pour apporter une incontestable valeur ajoutée au client. Le temps est venu, pour moi, de capitaliser sur toute cette expérience que j'ai accumulée jusqu'à présent au cours de ma trajectoire professionnelle et de la mettre au service de la gouvernance SI. 

Après le rachat de Docks de France par AUCHAN, la Direction Générale de cette dernière entreprise me confie le poste de Directeur des Etudes Informatiques France.

En m'appuyant sur l'expérience acquise lors du rachat de SASM par Docks de France je vais conduire la convergence du SI des deux entités et mener à bien ma seconde opération d'externalisation avec, cette fois-ci, un périmètre restreint à la production informatique.