SERGAM-Xpert vous présente son pôle d'expertise
AMOA transverse
Préambule
Ce document est destiné aux personnes souhaitant parfaire leur
culture générale et il vise à vulgariser le rôle de l’AMOA dans les projets informatiques pour les non spécialistes fonctionnels ou techniques du domaine. SERGAM-Xpert vous présente ici un échantillon de son expertise dans le domaine fonctionnel qu'est
l'AMOA transverse
Il s’adresse aux DSI, RSSI, chefs de projets informatiques et chefs
de projets fonctionnels. Mais aussi à tous ceux qui veulent comprendre le sujet sans forcément vouloir en devenir expert.
Volontairement, ce document est élaboré sur un schéma didactique et
ne prétend en aucun cas être la critique sous entendue d’un quelconque projet et du choix des Acteurs qui y collaboreront. Il est établi simplement pour éveiller la curiosité sur ce rôle majeur qui,
s’il est oublié dans un projet, peut entraîner des retards de livraisons ou des problèmes de relations entre les différents Acteurs du projet.
Ce document n’a pas vocation non plus à expliquer comment réaliser
les différentes activités et actions mais bien à présenter ce qu’elles contiennent.
Si vous souhaitez avoir des détails sur les savoir-faire, veuillez
contacter SERGAM-Xpert qui répondra à vos questions.
Les termes spécifiques employés sont simples mais s’inscrivent, bien
entendu, dans le vocabulaire de l’informatique de gestion.
Création : SERGAM-Xpert (2014)
Source : SERGAM-Xpert
Définition
L’assistance à maîtrise d’ouvrage (AMOA) consiste à intervenir là où la maîtrise d’ouvrage avoue ses limites, ne
possède pas de temps ou de compétence pour assurer la bonne rédaction de documents nécessaires à la bonne réalisation d’un projet. L’AMOA ne se substitue pas à la maîtrise d’ouvrage dans son métier
et ses activités quotidiennes. Il n’est pas là pour cela.
Il peut exister autant de forme d’assistance à maîtrise d’ouvrage qu’il existe de maîtrises
d’ouvrage. Autrement dit, de métiers.
Avant d'entrer dans le vif du sujet, il est important de rappeler une précision qui a une
sérieuse tendance à emmêler les esprits : distinguer les expressions "maîtrise d'ouvrage" de "l'assistance à maîtrise d'ouvrage".
En effet, dans le monde des projets informatiques, il
est courant d’entendre l’utilisation d’une expression à la place d’une autre. Notamment, lorsqu’il s’agit d’occuper un poste visant à intervenir au niveau d’un métier ou dans une maîtrise d’ouvrage
spécifique. Pour ce poste, il s’agira pour le consultant d’exercer le métier de la maîtrise d’ouvrage. Il devient alors celle-ci. Cependant, il arrive régulièrement qu’on entende que ce consultant
soit assimilé à un assistant à maîtrise d’ouvrage. Or, comme il a été vu plus haut, l’assistant à maîtrise d’ouvrage (AMOA) n’intervient que pour assister les équipes projet MOA dans les actions et
activités qui requièrent des compétences spécifiques et suffisamment d’objectivité pour fournir des documents clairs, précis et en reflet avec la réalité. De plus, on fait régulièrement intervenir
l’AMOA pour effectuer des tâches pour lesquelles la MOA liée au projet ou qui est purement métier, ne possède pas assez de temps, de disponibilité ou d’effectif (comme par exemple, pour la rédaction
de cahiers des charges, effectuer des études d’opportunité ou de faisabilité, rédiger des spécifications détaillées, recetter des livraisons de programmes fonctionnels ou techniques,
etc.).
Petits rappels sur les Acteurs majeurs d'un projet
Intéractions entre les Acteurs d'un projet informatique
Représentation schématisée des intéractions entre les Acteurs d'un projet informatique avec les flux d'informations, livrables et relations. (non
exhaustif...)
Interventions de l'AMOA dans un projet
Qu’il s’agisse des métiers de l’informatique, du bâtiment et de tout autre domaine technique et ou fonctionnel, les maîtrises d’ouvrage et
maîtrises d’œuvre existent et cohabitent dans la réalisation d’un projet, quel qu’il soit. Si on constate l’absence d’un de ces acteurs, la bonne réalisation du projet est compromise.
Une caractéristique importante de l’assistant à maîtrise d’ouvrage est qu’une fois le projet commencé, il « devient » maître ou
maîtrise d’ouvrage. Non pas qu’il prenne la place de la MOA dans ses activités quotidiennes mais il communique en son nom auprès des autres acteurs du projet.
L’AMOA doit s’investir fortement dans l’organisation / la structure qui a fait appel à ses services. Cela signifie qu’il passera la majeure
partie du temps allouée à la prestation, avec le client, dans ses locaux, afin d’en bien analyser tous ses éléments constitutifs : organisation, métiers, personnels, spécificités fonctionnelles,
données utilisées, outils et solutions techniques présents dans le SI du client, contraintes techniques et fonctionnelles.
L’AMOA est généralement un prestataire de services. Ce statut permet d’avoir des documents qui seront objectifs et sans affect et non
subjectifs. Ce qui ne dévalue nullement la qualité des livrables et des relations avec la MOA et les autres Acteurs contributeurs du projet.
Quelques activités demandées à l'AMOA
Les activités d’un AMOA en informatique de gestion sont multiples. Comme on l’a vu plus haut, il intervient là où le
client (le Maître d’ouvrage n’en possède pas les moyens), essentiellement pour :
- Analyser de manière objective le
fonctionnement de la structure du MOA
- Auditer l’existant : ensemble des éléments qui constitue une MOA ou d’une MOE. Le recensement se termine généralement par des préconisations d’améliorations.
- Préconiser des évolutions dans
les processus de fonctionnement de la MOA
- Etudier la faisabilité de
l'évolution du système d'informations d'un point de viue fonctionnel mais en tenant compte des contextes et contraintes techniques.
- Recueillir les besoins dans le
cas du désir de mettre en place un nouveau système d’information : cette tâche est naturellement lourde dans un projet. Elle impose la mobilisation d’un grand nombre d’individus lorsque la MOA
décide d’effectuer le recueil des besoins par elle-même. De plus, un AMOA pourra déceler des manques possibles dans les besoins car son regard sera transverse entre les différents métiers présents
dans la MOA.
- Rédiger les cahiers des charges : le cahier des charges rassemble l’ensemble des besoins exprimés en tant que cible à atteindre. Il ne critique pas l’existant mais présente ce que les MOA et MOE veulent voir
mis en place et en œuvre lorsque le projet sera terminé. Généralement, une erreur importante est commise dans un cahier des charges : la présentation des solutions technico-fonctionnelles. Le
cahier des charges de ne soucie pas des solutions à mettre en œuvre mais tient compte des contraintes fonctionnelles (workflow, données, règles de gestion) et des contraintes techniques présentes ou
souhaitées (technologies et outils informatiques à conserver).
- Rédiger les spécifications fonctionnelles générales et détaillées : il s’agit à partir d’un cahier des charges validé par le client, de détailler chaque point pour orienter les pistes de réflexions sur le « comment
on va le faire » et le « quelle solution technique sera utilisée ». Le travail partira du général (description des métiers et des fonctions) pour atteindre le détail (description
précise des informations et données utilisées, description des règles de gestion, de l’enregistrement des informations, etc.)
- Communiquer avec la MOE :
l’AMOA connaît à présent parfaitement les besoins de la MOA. Il sait communiquer avec elle et la MOE pour l’aider dans les choix des solutions techniques et des technologies qui seront utilisées pour
répondre parfaitement aux exigences de la MOA (produits du marché ou solutions spécifiques réalisées en interne ou sous-traitées).
- Effectuer les recettes fonctionnelles (et déceler les problèmes techniques consécutifs) : une fois que la MOE a livré tout ou partie des réalisations correspondant aux besoins exprimés par la MOA,
l’AMOA intervient avant la maîtrise d’ouvrage pour tester ce qui a été fait. Il s’agit généralement de versions d’outils qui seront en pré-production. Cette pré-production est utilisée dans un
environnement indépendant de celui de production quotidienne. Les tests qui reprennent point par point les besoins exprimés serviront à valider les versions successives des outils qui seront – une
fois validés par l’AMOA et la MOA – mis en production. Cette phase se nomme la « recette fonctionnelle ».
- Rédiger les comptes-rendus qui
sont de plusieurs types :
- Les comptes-rendus des comités de projet : réunions avec tous les intervenants du projet et appartenant à la MOA,
la MOE, l’AMOA et éventuellement l’AMOE. Il s’agit de connaître l’état d’avancement ou de possibles blocages du projet.
- Les comptes-rendus MOA : comptes-rendus des réunions faites avec la MOA pour valider les informations reçues,
comprises et analysées. Un compte-rendu est généralement fait au fil de l’eau, à l’issue de la réunion, avec les interlocuteurs concernés.
- Les comptes-rendus de recettes : état des recettes fonctionnelles effectuées avec liste des fonctionnalités
valides et les anomalies rencontrées. Ces comptes-rendus seront transmis à la MOE et devront être validés par celle-ci, la MOA et l’AMOA.
- Les tableaux de bord du projet : ensemble des indicateurs positionnés sur l’échelle du temps du projet avec la
mise en exergue des jalons atteints, les échéances dépassées, les points de blocage, les alertes, les solutions présentées, les résultats obtenus. Il va de soi qu’un projet qui se déroule
correctement possède tous ses indicateurs placés au vert. C’est extrêmement rare.
- Aider la MOA dans ses choix de solutions technico-fonctionnelles.
Cela signifie d’être informé des solutions correspondant aux besoins du client. Il peut s’agir de solutions existantes sur le marché ou de développements spécifiques, si la MOE et les finances du
client le permettent.
- Rédiger les protocoles de conduites du changement. Il s’agit de
rédiger les manuels d’utilisation qui informeront les MOA des modifications de comportement ou de travail qu’elles devront adopter pour utiliser parfaitement les solutions informatiques mises à leur
disposition.
Quelques actions et livrables de l'AMOA
Voici quelques exemples d’actions et de livrables réalisés par l’AMOA (liste non exhaustive) :
- L’acquisition de la connaissance de la maîtrise d’ouvrage.
- Les études de faisabilité.
- Les ateliers de travail avec les intervenants du projet.
- Les ateliers de travail avec les acteurs directement concernés par les besoins.
- Les recueils des besoins fonctionnels et/ou techniques :
- La rédaction de cahier des charges.
- La rédaction du ou des appels d’offres.
- Le dépouillement des offres.
- Le choix des offres retenues.
- La recherche de la ou des solutions correspondant aux besoins fonctionnels et techniques.
- L’analyse des différentes solutions (matrice décisionnelle).
- Le ou les choix de la ou des solutions fonctionnelles et techniques.
- L’étude des analyses d’écart entre les solutions existantes et les besoins de la MOA.
- La rédaction des spécifications fonctionnelles générales et détaillées, avec :
- La prise en charge des règles de gestion spécifiques du Métier et du SI.
- La prise en charge des contraintes réglementaires à considérer.
- Les conseils sur les réglementaires de sécurité ou Métiers à prendre en considération.
- Les conseils sur des expertises métiers.
- Les conseils sur des expertises liées à la Sécurité du SI (ex. IAM).
- La coordination avec la MOE en charge de l’intégration et/ou déploiement de la solution retenue.
- Les recettes fonctionnelles.
- La prononciation des GO-NO GO de mise en production.
- La prononciation des périodes de vérification d’aptitude.
- Prononciation des vérifications de service régulier
- L’assistance à la MOA pour la fourniture des données pour la solution retenue.
- La rédaction des comptes-rendus :
- D’ateliers
- De comités de projet
- La rédaction des notes spécifiques :
- Les alertes sur le projet (charges, planning, budget, organisation)
- Les préconisations (réglementaires, organisation du projet, suivi de production)
Mais aussi :
- L’assistance et le support aux différentes MOA sur certaines actions complexes du projet (ex. création et suivi des tableaux de bord de suivi de projet, définition
des droits et rôles d’habilitations, etc.)
Etc.
Devoirs et droits de l'AMOA
À ces activités peuvent s’en ajouter d’autres, connexes, nécessaires pour le bon déroulement du projet. Ces activités
complémentaires constituent en général des devoirs et des droits que l’AMOA se doit d’appliquer.
L’AMOA se doit d’être respectueux des procédures. En cela, il devra respecter les clauses définissant son périmètre
d’intervention dans le projet. Ces clauses sont décrites dans l’appel d’offres de la prestation. Également, il se devra, dans tous les cas de figures, de connaître et respecter la déontologie liée
aux métiers de la MOA et en n’aucun cas, proposer des solutions mettant soit en péril les activités du client, soit risquer de mettre celui-ci en porte-à-faux avec la loi.
Cet aspect étant très rigoureux, si l’AMOA doute de la faisabilité de certains de ses choix, il devra en rendre compte
à la MOA et au comité directionnel du projet, afin que toute ambiguïté soit levée et que les actions soient réalisées en toute connaissance de cause.
Les outils utilisés par l’AMOA sont ceux du client avec : les suites bureautiques (Word, Excel, PowerPoint,
Outlook, parfois Access), Microsoft Visio pour les schémas techniques et fonctionnels complexes, les outils de messagerie, Internet, le réseau interne de l’entreprise, les imprimantes. L’idéal est de
travailler avec des postes de travail équipés de deux écrans.
En ce qui me concerne, les documents et les projets peuvent être réalisés aussi bien en français qu’en anglais, selon
les contextes imposés par le Client.
Envisager l’intervention d’un AMOA restant à son domicile est très difficilement concevable. Cette possibilité est
envisageable une fois le recueil des besoins et des analyses effectués, pour rédiger ses comptes-rendus.
Un AMOA qui ne peut être en contact constant avec le client ne peut exercer ses activités. Une grande part du temps est
dédiée à l’acquisition de l’information et à la capitalisation de la connaissance qui sont présentes chez un client. Il s’agira de reproduire ce qui a déjà été fait et approuvé chez des clients afin
d’être sûr des résultats à obtenir. Il est très rare d’être obligé d’inventer de toutes pièces une solution présentant des caractéristiques communes avec un client du passé.
Les aspects humains de l'AMOA
Sur le plan humain, l’AMOA se doit de regrouper certaines qualités que l’on peut présenter et illustrer sous forme de
ce que j’appelle volontairement la « marguerite des valeurs et forces d’un AMOA ».
Cette figure représente ce que l'AMOA devrait porter comme valeurs et forces pour exercer correctement son
métier.
Cette carte des "valeurs" est une vision strictement personnelle.
"Marguerite" des valeurs et des forces d'un AMOA.
Prenons le temps de détailler les « pétales » de cette marguerite. Il n’existe aucun ordre de lecture de
cette « marguerite ». Nous prendrons donc les valeurs une par une.
- L’humilité : l’AMOA doit apprendre du
client. Il aura certes des connaissances et des savoir-faire qui proviennent d’expériences antérieures, il n’empêche que son Client est celui qui détient la Connaissance et le Savoir-faire sur le
projet. Des éléments qui appartiennent à ses activités quotidiennes et à celles regroupées pour réaliser le projet. L’AMOA se doit d’être humble face aux nouvelles connaissances et savoir-faire qui
seront présentés par son Client. S’il s’avère que des dysfonctionnements se présentent dans les modes opératoires, l’AMOA devra en faire part à titre de conseil et de suggestions mais en aucun cas,
il devra vouloir imposer ses points de vue ou ses connaissances.
- Conseiller : un AMOA intervient dans un
contexte particulier et pour un projet spécifique. Au-delà des simples actions qu’il a pour tâches, il a un devoir de conseil. Surtout s’il constate que son Client effectue des actions qui risquent
de perturber le bon déroulement du projet ou s’il enfreint certaines règles liées à l’État de l’Art. Ces conseils doivent être proposés et il est prudent de les communiquer par écrit s’ils sont
fondés. De même, ce qui tient des stratégies à mettre en œuvre pendant le projet ou après, doit être communiqué sous forme de conseils.
- Opérationnel : un AMOA intervenant chez un
client doit être opérationnel très rapidement sur les phases où le client peut montrer ses limites. Il doit prouver ses capacités à s’intégrer rapidement à l’équipe et montrer sa valeur ajoutée dans
le projet. Pour cela, il ne devra pas hésiter à prendre à sa charge certaines responsabilités ou la restitution de livrables afin de soulager au plus tôt le client, de ces actions qui pourraient
l’alourdir.
- Écouter : une des caractéristiques maîtresses de l’activité et de
la qualité d’un AMOA est sa capacité d’écoute. En effet, tout nouveau projet est source de nouvelles connaissances et savoir-faire à acquérir. Le devoir d’écoute et de respect du temps de parole des
différents intervenants est primordial pour bien comprendre et apprendre. Même, s’il est amené à conseiller, l’AMOA devra le faire avec intelligence en laissant à son client les temps de paroles
nécessaires à ses besoins d’expression. Et cette écoute se fera aussi envers les autres acteurs impliqués dans le projet. Il est impossible de comprendre correctement si on parle en même temps que
son interlocuteur.
- Créatif et astucieux : il est rare qu’un
projet fournisse l’ensemble des outils nécessaires à son bon suivi ou à la réalisation de certaines tâches spécifiques (tableaux de bord de suivi d’actions, etc.). Pour cela, l’AMOA doit avoir la
capacité de fabriquer de manière autonome ses propres outils et de les faire évoluer afin qu’ils répondent aux attentes du projet et du client. Voire, accessoirement, des autres acteurs du
projet.
- Communiquer : une autre caractéristique
importante de l’AMOA est la communication avec son client et l’ensemble des acteurs impliqués dans le projet, sur ses activités, ses avancements, voire ses difficultés. Cette communication est
importante à la bonne réalisation du projet. Elle permet d’avoir régulièrement, une visibilité sur l’avancement des réalisations ou des points de blocages. De plus, en communiquant tôt, il est plus
facile de prévoir et trouver les solutions des problèmes.
- Autonomie : très rapidement, l’AMOA doit
être autonome sur les parties dont il a la responsabilité. Il doit être facilement et rapidement en capacité de trouver la ou les informations qui lui permettront de travailler et de fournir ses
livrables. Pour cela, il devra s’inscrire dans l’organisation du client, quitte à adopter – peut-être, selon les cas et les capacités – des méthodes qui lui permettront de contourner des blocages qui
pourraient ralentir la fourniture des données. Mais avec une bonne communication et conseiller correctement, il est rare de ne pas obtenir les informations utiles et nécessaires.
- Déontologie : il est inconcevable qu’en sa
qualité de conseil et de support, un AMOA ne respecte pas les Règles de l’Art et l’État de l’Art dans la réalisation de ses activités. Il est prépondérant que l’AMOA ait une forte capacité à
respecter la déontologie liée à son métier, celui de son client et aux bonnes pratiques en termes de relations humaines et de réalisation de projet. Car dans le cas inverse, non seulement il
s’exposerait à de graves sanctions mais aussi et surtout, il exposerait son client à d’importants dommages. Il ne faut pas oublier qu’un AMOA intervient pour son client mais aussi, il agit en son nom
et il « devient le client » (il endosse son nom et ses besoins), en défendant ses intérêts pour la bonne réalisation du projet.
- Curiosité : il est important, pour être
AMOA, d’être curieux de nouveaux savoir-faire, de nouvelles techniques, d’évolutions de métiers ou de modes opératoires. Aussi, comme on l’a vu plus tôt avec l’humilité, l’AMOA ne doit pas hésiter à
poser les questions qui lui permettront de mieux connaître son client et ses activités professionnelles, mais aussi son organisation et son ou ses modes de fonctionnement. L’AMOA pourra ainsi
compléter son « catalogue » personnel de connaissances qui pourront lui servir plus tard de « bagage » utile aux retours d’expériences et de conseils. Cependant, l’AMOA doit
pouvoir les mettre en concurrence, en compétition afin de les analyser et les évaluer pour être bien certain que les Règles de l’Art sont respectées. Et dans le cas contraire, intervenir pour
conseiller et suggérer des corrections à apporter pour que le client s’inscrive à nouveau dans les règles de déontologie.
- Méthode et organisation : pour effectuer
ses activités, l’AMOA doit savoir être organisé et méthodique afin de s’inscrire dans les modèles de fonctionnement du projet, de son client mais aussi dans le planning de livraison de ses documents.
Au besoin et si le client ne l’a pas imposé sur le projet dans son mode opératoire, l’AMOA pourra utiliser les modèles ISO de documents pour les siens. De même, il devra maîtriser l’ordonnancement
des études et des réalisations propres à un projet informatique (par exemple, avant de choisir une solution ou un outil, on recueille et on consigne les besoins fonctionnels et techniques dans un
cahier des charges).
Enfin, par expérience, il est essentiel d’aimer l’humain
pour ne pas être foncièrement en contradiction avec le métier d’Assistant à Maîtrise d’ouvrage.