Pages

samedi 19 novembre 2011

Réconcilier la Maîtrise d'ouvrage et la Maîtrise d'oeuvre

Réconcilier la Maîtrise d'ouvrage et la Maîtrise d'oeuvre par Time Performance (28/05/2009)

L'organisation en MOA et MOE pour les projets informatiques est une exception française qui perdure malgré ses multiples inconvénients. MOA et MOE sont complémentaires. Alors pourquoi séparer les équipes ?
  
Les principaux inconvénients de cette séparation MOA/MOE sont:
  • le développement de visions divergentes et de malentendus
  • une communication très formelle entre les équipes donc moins rapide et moins efficace
  • responsabilités partagées et prises de décision difficiles
  • l'installation d'un climat de méfiance
  • risque d'avoir le projet contaminé par les dissensions entre les services
  
A la moindre difficulté, le projet risque de devenir le terrain d'une lutte où les 2 clans se retranchent derrière leurs positions: la satisfaction du client pour la MOA et la faisabilité technique pour la MOE.
   
Les avantages d'une équipe mixte MOA/MOE ? D'abord la simplicité. Les responsabilités et les décisions appartiennent à une seule équipe. Mais surtout cela fait ressortir en amont du projet les difficultés de coopération et de communication qui existent naturellement entre le métier et la technique. En amont du projet, l'effort pour surmonter ces difficultés est bien plus faible et le retour est plus important. Au final, l'Informatique a une meilleure compréhension du métier tandis que le Métier a une meilleure connaissance du fonctionnement de son outil. Enfin, des solutions optimales en termes de rapport valeur business sur coût peuvent être plus facilement trouvées.
  
On constate d'ailleurs que les méthodes modernes de gestion de projet informatique (Scrum, Prince2, Unified Process etc.) ne font pas la différence entre projet MOA et projet MOE.

MOA - MOE : un phénomène typiquement français ?

MOA - MOE : un phénomène typiquement français ? par Christophe Thiry
J'ai commencé à avoir des doutes sur l'existence "internationale" du concept de maîtrise (d'œuvre et d'ouvrage) lorsque j'ai cherché une traduction de ces termes en anglais. Et là, surprise : j'ai eu un mal de chien à trouver une seule traduction. Le seul document qui fait clairement référence à ces maîtres ne concerne même pas l'informatique, mais la construction. Il traduit :

  • maîtrise d'ouvrage par project owner ou client (presse francophone), plus rarement sponsor;
  • maîtrise d'œuvre par project supervisor ou project manager (presse francophone) ou lead contractor (lexiquegtr).

Ces traductions mettent bien en valeur une relation client-fournisseur, "celui qui paie" et "celui qui fait". Or cette façon de faire n'a pas vraiment cours dans la culture anglo-saxonne. Fait révélateur, le CIGREF (Club informatique des grandes entreprises françaises, qui existe depuis 1970 et dont la finalité est la promotion de l’usage des systèmes d’information comme facteur de création de valeurs pour l’entreprise) traduit bien, dans sa nomenclature 2001, maître d'œuvre,... mais pas maître d'ouvrage.

Un consultant d'une grande boite de conseil me le confirme : après avoir fait plusieurs missions en Belgique et au Luxembourg, de culture plus anglo-saxonne dans la conduite de leurs projets informatiques, il rentre à regret en France. En effet, me dit-il, cette distinction est plus une séparation de pouvoir qu'autre chose. Il s'agit de deux savoirs (le client et son métier face au fournisseur et sa technique) qui s'opposent. Le problème, c'est que ces deux savoirs s'affrontent sans proposer de réel savoir-faire.

La culture anglo-saxonne est beaucoup plus basée sur le savoir-faire ou "process" (avec les steps, milestones, ...), dirigé par un team leader, et comprenant des gens aussi bien fonctionnel (bonne connaissance métier) que technique. Leur process se base souvent sur des "streams" architecturaux, tels que ces sphères architecturales : des équipes "business", "fonctionnelles", "applicative" et "technique" qui se réorganisent ensuite par projet applicatif, avec dans chaque projet, des gens "business", "fonctionnel", "applicatif" et "technique".

Certes, la vision du client MOA qui dirige le fournisseur MOE peut marcher... mais engendre surtout des organigrammes de collaborateurs excessivement compliqués surtout quand :
  • la MOA décide de se faire assister (on a donc une assistance à maîtrise d'ouvrage qui dirige et conseille une maîtrise d'ouvrage qui elle-même dirige une maîtrise d'œuvre ! Cela peut d'ailleurs se révéler dangereux en cas de régie)
  • l'organigramme du projet devient virtuel, parce qu'un "vrai" organigramme montrerait telle personne au dessus de tel autre alors qu'il s'agit, dans la hiérarchie de l'entreprise, de son subordonné ! Du coup, on préfère publier de "faux" organigrammes pour ménager les susceptibilités de chacun !

Cette "division" (pour mieux régner ?) permet sans doute aussi de mieux diluer la responsabilité en cas d'échec, à l'opposé du "process" anglo-saxon où les "leaders" (ou "managers") sont clairement identifiés et sont les premiers à sauter !

Les difficiles rapports DSI - Maîtrise d'ouvrage

Les difficiles rapports DSI - Maîtrise d'ouvrage par Le Journal du Net (15/11/2004)

Qui sont les maîtres d'ouvrage dans les entreprises ? Quelles sont leurs missions ? Pourquoi sont-ils souvent accusés de faire échouer les projets informatiques ? Une enquête pour faire le point.

"La quasi totalité des échecs sur les projets sont à imputer aux maitrises d'ouvrage" rapporte Michel Volle, consultant, fondateur du Club MOA et ancien responsable maitrise d'ouvrage chez Air France. Spécifications insuffisantes, évolution des besoins en cours de projets ou demandes irréalisables dans les délais sont quelques uns des reproches qui leurs sont adressés par les informaticiens. Les rapports entre MOA (maîtrise d'ouvrage - métiers) et MOE (maîtrise d'oeuvre - informatique) sur les projets informatiques ne sont pas toujours simples.
Mais la MOA tend à se professionnaliser. Le Club MOA s'est d'ailleurs mis en place en 1997 pour encourager cette professionnalisation, multiplier les échanges d'expérience et définir un guide des bonnes pratiques et des méthodes de travail communes. Comment sont composées les MOA dans les entreprises ? Quelles sont les rôles et zones de pouvoir exercés et occupés par MOA et MOE ? Quelles sont les difficultés rencontrées et les solutions à mettre en place ? Etat des lieux.

Composition et organisation des MOA dans les entreprises
A la Sodexho Chèques et Cartes de Services (CCS), filiale du spécialiste de la restauration d'entreprise Sodexho Alliance, il n'existe pas de maîtrise d'ouvrage permanente. "La maîtrise d'ouvrage évolue selon les personnes et selon les projets, si j'ai travaillé à ce poste pour un projet CRM, notre webmaster est amené à travailler sur un projet Web avec l'informatique" explique Sertaç Turan, rattaché au marketing et chef de projet opérationnel pour le CRM.
A l'inverse la MGEN (Mutuelle Générale de l'Education Nationale) qui compte 9.300 salariés, a, elle, mis en place dès 2000 des pôles d'assistance à MOA de taille différente (de 3 à 25 personnes) selon les directions. Six pôles sont spécialisés (Trésorerie Générale, RH, Activité Sanitaire & Social et trois sur les activités de RO - régime obligatoire - et RC - régime complémentaire) et un autre pôle assure la MOA pour les projets transversaux.
"Les utilisateurs étaient auparavant en dialogue direct avec la maitrise d'oeuvre informatique mais la direction a souhaité que les métiers s'impliquent davantage sur le développement de leurs applications" précise Thierry Augay, responsable de la MOA pour le pôle Trésorerie Générale qui compte 4 personnes. Les MOA du groupe sont toutes rattachées aux directions métiers sauf celle sur les projets transverses rattachée à l'informatique. Les membres de ces pôles ont souvent des profils informatiques ou métiers.
"En général dans les MOA, ce sont soit des informaticiens, soit des spécialistes du métier"
"En général dans les MOA, ce sont soit des informaticiens spécialisés dans un domaine d'activité - commercial, RH, production...-, soit des spécialistes du métier" confirme Michel Volle. "Ce sont dans les grandes entreprises, qui ont plusieurs dizaines de projets par an, que l'on trouve des pôles dédiés. Pour des petites structures, il n'y a pas besoin d'entité permanente" poursuit-il.
"Ce que je recommande, c'est que dans les grandes entreprises, chacun des directeurs soit assisté par une maitrise d'ouvrage déléguée - de 1 à 10 personnes - pour prendre les décisions sur l'évolution du système d'information et qu'une équipe se mette également en place auprès de la direction générale cette fois pour les projets transversaux comme la messagerie ou l'administration des données", ajoute le responsable de la MOA.

La répartition des rôles et des pouvoirs entre MOA et MOE
"Mon rôle consiste à évaluer avec les utilisateurs leurs besoins, établir un cahier des charges, assurer le lien avec l'informatique, contrôler le planning de réalisation produit par la MOE et de faire du reporting pour indiquer les retards éventuels. La MOE se charge de voir quels moyens techniques elle met en face du cahier des charges, si elle a les compétences en interne..." résume Sertaç Turan.
"Nous avons une méthode interne de conception générale, nous formalisons les besoins, installons, paramétrons et administrons les outils, faisons la recette et assistons les utilisateurs. Les budgets pour les outils dépendent des métiers et non de l'informatique. Cette dernière nous donne des pistes et des avis techniques mais tout le reste dépend des métiers" complète Thierry Augay.
"La MOA doit définir ce que le produit doit faire, donner des spécifications claires pour la MOE, ceci équivaut à fournir une version modélisée des besoins, si possible sous UML. La MOE doit ensuite introduire des contraintes techniques aux demandes métiers, rédiger la partie technique du cahier des charges et assurer la réalisation" atteste Michel Volle.
Pour Sonia Boittin, directeur associée du cabinet de conseil KLC, la répartition financière des projets est encore problématique. "La MOA est la seule entité à pouvoir justifier économiquement un projet et faire une étude de rentabilité. Ce n'est pas à l'informatique de définir le ROI or on assiste encore souvent à ces situations."

Les rôles de la MOA :
  • Spécifier les besoins
  • Choisir et lancer les moyens (lance le projet, le gère et le finance)
  • Suivre la réalisation (valide les solutions, participe à certains travaux)
  • Réceptionner (recette les livrables)
  • Exploiter l'oeuvre ou en confier l'exploitation
  • Maîtrise les risques

Les rôles de la MOE :
  • Concevoir techniquement (propose des solutions)  
  • Organiser et contrôler la réalisation (conduit les travaux, )
  • Contrôler le résultat et rapporte à la MOA sur l'avancement du projet
  • Livrer un projet réalisé conformément aux dispositions contractuelles et aux règles de l'art
  • Préparer l'exploitation
  • Gère les risques

Les principales difficultés rencontrées
"Le principal point sur lesquels il y a des accroches concernent les délais de mise en place. La MOA a également tendance à vouloir coller au maximum aux besoins exprimés par les utilisateurs alors que la MOE peut avoir tendance à les contourner si elle rencontre des difficultés techniques, il faut parvenir à un niveau d'acceptabilité" note le chef de projet CRM chez Sodexho CCS.
Au sein de la MGEN, les problèmes étaient davantage de nature structurelle, liés à la réorganisation de l'entreprise et à la création de pôles MOA dédiés. "L'informatique a plus ou moins bien vécu le changement et certains d'entre eux ont ressenti une perte de leur pouvoir. Les problèmes ont perduré jusqu'en 2003 où un audit a été réalisé à la demande de la direction générale pour évaluer les rapports MOA/MOE", explique Thierry Augay.
"Du côté MOE, certains informaticiens faisaient de la rétention d'information, et laissaient les projets échouer. Du côté MOA, certains n'ont pas su exprimer les besoins de manière suffisamment claire. Des personnes ont été remerciées des deux côtés et les problèmes se sont en partie résolus. En fait la grosse difficulté a été de faire admettre à la MOE qu'elle était au service de la MOA tout comme la MOA l'était des utilisateurs finaux" .

D'après Michel Volle, c'est l'effet tunnel qui est un des plus gros problèmes: les informaticiens s'engagent dans la réalisation d'un projet avec une définition des besoins approximative et livrent un produit sans étapes intermédiaires; la solution à l'arrivée ne correspond de ce fait rarement aux attentes des MOA.
"Il arrive souvent que les MOA ne définissent pas leurs besoins et accusent au final l'informatique en expliquant que le produit final ne correspond pas à ce qu'elles demandaient" confirme Sonia Boittin. Elle précise également que la majorité des utilisateurs ne connaissent pas l'impact de leurs demandes sur les coûts et ne les limitent de ce fait pas.

"En général ce sont plutôt des gens qui ne veulent pas s'écouter, les MOA ne veulent pas tenir compte des contraintes techniques, ne définissent pas des besoins et des spécifications de qualité et les MOE ont des priorités propres, favorisent les projets qui les intéressent davantage ou pensent savoir ce que les opérationnels ont besoin" poursuit Michel Volle.

Les solutions à mettre en place
Plusieurs solutions ont été mises en place dans les entreprises. Chez Sodexho, c'est la complémentarité des responsables MOA/MOE qui a été un atout. "Nous avons tous deux des compétences à la fois techniques et fonctionnelles. Au début on se marchait un peu sur les pieds, en empiétant sur les domaines de l'autre, il a fallu une période d'adaptation, mais quand nos rapports ont été davantage rodés, cette double compétence a été un avantage" retrace Sertaç Turan. Au sein de la MGEN, c'est une définition précise des rôles de chacun qui a aidé à débloquer la situation.

Définition d'une méthodologie, des missions des MOA et MOE et professionnalisation de la maitrise d'ouvrage sont aussi les arguments cités par les experts. "Il est essentiel de mettre en place une MOA professionnelle dans les entreprises et l'informatique doit accepter cette professionnalisation. Mais les opinions des MOE sur le sujet sont souvent contradictoires, ils veulent avoir affaire à une bonne maitrise d'ouvrage mais voit cette évolution également comme un empiètement de leur pouvoir. Il faut admettre que les deux métiers sont différents, la modélisation et l'organisation de l'entreprise pour la MOA, la réalisation et l'exploitation informatique pour la MOE", évalue Michel Volle.
Le cabinet KLC qui intervient souvent en amont ou en cours de projet définit plusieurs mesures à mettre en oeuvre. "Nous aidons les entreprises à organiser et définir une MOA. Nous mettons aussi en place des conventions de services qui définissent les rôles et responsabilités des directions informatiques et métiers, les niveaux de services attendus, les systèmes de contrôle, les procédures d'alertes et des pratiques pour la gestion des changements" détaille la directrice associée du cabinet.

Le rôle de la direction générale pour les rapports MOA/MOE est aussi essentiel, il doit faire comprendre à son entreprise que ce sont les MOA les responsables des projets. "Il est de la responsabilité de la direction générale de faire les arbitrages. Avant, on rencontrait surtout des problèmes entre direction commerciale et production dans les entreprises, aujourd'hui c'est entre MOA et MOE", conclut Michel Volle.
 

Rôle de la MOA (Michel Volle)

Rôle de la Maîtrise d'Ouvrage par Michel Volle (27/07/2002)

Il revient d’abord à la maîtrise d’ouvrage de définir les besoins du métier. Cette définition doit être adéquate aux besoins (pertinence), sobre, et conforme à la cohérence sémantique du SI (respect du référentiel).

Lorsque le SI existe, l’ensemble de ses fonctionnalités (processus, composants, interfaces homme-machine) constitue un « portefeuille » (le « portefeuille applicatif ») qui doit être géré comme tout actif de l’entreprise. Le portefeuille est un stock, alors que la réalisation des projets constitue un flux. Il ne convient pas de faire évoluer le portefeuille trop souvent, et tout investissement doit être précédé d’une évaluation de sa rentabilité mettant en regard le coût complet (y compris les dépenses de la MOA et le coût d’exploitation une fois le projet réalisé) ainsi que ses effets attendus. Comme pour un portefeuille financier, il faut évaluer les synergies entre divers projets : la solidité du SI vient souvent du fait que les applications s'appuient l'une sur l'autre, comme les deux parties d'une voûte. L'approche "système" du SI vise précisément à tirer parti de ces synergies. 

Si le projet est lancé, la MOA doit modéliser les processusspécifications générales ») dans des termes assez précis pour que l’informatique puisse se mettre au travail. L’informatique établit ensuite des spécifications détaillées que la MOA doit valider.

La MOA dirige la réalisation du projet, avec l’assistance de la MOE. Si le projet dérape, si durant sa réalisation les exigences fonctionnelles évoluent, si le MOE ne remplit pas bien sa mission, c’est à la MOA qu’il revient de prendre les décisions nécessaires. La MOA est donc toujours responsable lorsqu’un projet échoue : soit elle aura été imprécise ou versatile dans l’expression des besoins, soit elle aura manqué de vigilance face à un MOE défaillant. Une MOA qui dit "l’informatique a échoué" reconnaît implicitement qu’elle n’a pas correctement assumé ses responsabilités, et en outre elle a tort de chercher à en faire porter la responsabilité à la MOE. Il faut dire, toutefois, que les entreprises donnent rarement à la MOA les moyens de ses responsabilités ; elles ont trop tendance à penser que "tout ça, c'est de l'informatique", et à confier la totalité des responsabilités à la MOE.

A la fin de la réalisation, la MOA vérifie que le produit rendra aux utilisateurs les services attendusrecette fonctionnelle »). Elle doit ensuite assurer la formation des utilisateurs, le déploiement du produit, la conduite du changement, l’animation des bonnes pratiques, l’écoute des réclamations et suggestions éventuelles, etc.

mercredi 16 novembre 2011

Consultant MOA - Définition (Les Jeudis)

Consultant MOA - Définition selon Les Jeudis

La maîtrise d’ouvrage (MOA) traite des points non techniques et non informatiques d’un projet tels que l’organisation des procédures, la conduite du changement ou encore la formation. Le consultant MOA a pour mission d’accompagner le client dans son changement de système d’information : de sa mise à plat jusqu’à la validation du nouvel outil en passant par la formation auprès des utilisateurs. Le consultant MOA intervient, chez le client, généralement comme un prestataire externe. Il est peu fréquent qu’il y soit salarié, à moins qu’il ne s’agisse d’un grand groupe.

Principales missions
Définir les spécifications générales et détaillées
Rédiger le cahier des charges
Planifier le projet
Valider les tests fonctionnels
Proposer aux utilisateurs formation et support


Formation
École de commerce
École d’ingénieurs
Diplôme universitaire

Compétences professionnelles
Avoir des compétences métier

Connaître la gestion de projet
Posséder les bases en informatique

Profil
Capacité d’écoute

Esprit d’analyse et de synthèse
Capacités rédactionnelles
Aptitudes au management et au travail en équipe

Salaire (2009)
Le salaire d’un consultant MOA est en moyenne de 45 k€ (la fourchette est comprise entre 35 et 55 k€). Il peut atteindre 80 k€ après 5 à 10 ans d’expérience.

Evolution professionnelle
Un consultant MOA va généralement évoluer vers la direction de projets complexes. Par la suite, il pourra envisager d’intégrer une SSII et devenir associé. Une évolution vers la formation est également envisageable.

AMOA - Définition - Wikipedia

L’assistant à maîtrise d’ouvrage (AMOA ou AMO) a pour mission d’aider le maître d'ouvrage à définir, piloter et exploiter le projet réalisé par le maître d'œuvre. L’assistant a un rôle de conseil et de proposition, le décideur restant le maître d'ouvrage. Il facilite la coordination de projet et permet au maître d’ouvrage de remplir pleinement ses obligations au titre de la gestion du projet.

Le recours à une assistance à maîtrise d'ouvrage se justifie par la taille, la complexité ou certaines spécificités du projet concerné. Il est souhaitable chaque fois que le maître d’ouvrage identifie un risque en termes de pilotage de projet, notamment dans les cas suivants :

  • défaut de compétences ou de temps dans la conduite de projet ;
  • besoin d'apport d'expertise durant la durée de vie d'un projet ;
  • besoin organisationnel en compétences spécifiques le temps d'un projet, pour en assurer la conduite de projet,
  • nature de la mission confiée au prestataire: par exemple, le recours à un consultant externe s'impose pour un audit ou une recette de projet.

Quand la mission d'AMOA court de l'amont du projet à son achèvement et qu'elle porte sur l'ensemble des aspects du projet (finance, technique, règlementation, passation et gestion des marchés, gestion du planning, management des acteurs...), elle est alors qualifiée de conduite d'opération (opérations de conception-réalisation). Dans le cas de la conduite d'opération, l'assistance à maîtrise d'ouvrage exclut toute prestation de maîtrise d'œuvre. Hormis ce cas, la mission d'AMOA ne constitue pas une fonction de maitrise d'œuvre, l'assistance ayant pour objectif d'apporter au maitre d'ouvrage un conseil éclairé et indépendant des constructeurs/réalisateurs.

L'assistant à maîtrise d'ouvrage délégué remplit les fonctions suivantes :

  • Il participe à la définition des objectifs stratégiques et des besoins fonctionnels et techniques au regard des besoins du Maître d'ouvrage. Cette définition des besoins est une mission stratégique spécifique qui peut être réalisée dans le cadre d'une mission de programmation indépendante de l'assistance maîtrise d'ouvrage au sens strict
  • Il identifie les contraintes et les exigences de qualité en fonction des attentes des utilisateurs
  • Il identifie les impacts organisationnels au sein du projet
  • Il s'assure de la faisabilité de la mise en œuvre du projet sur tous les aspects : organisationnels, juridiques, budgétaires, de planification et de ressources.
  • Il préconise et aide au choix de la solution et des prestataires le cas échéant ;
  • Il garantit la coordination et le pilotage durant toute la durée de vie du projet ;
  • Il contrôle et réceptionne les prestations fournies par le maître d'œuvre, ses sous-traitants le cas échéant, depuis les phases de spécifications d'avant-projet, de rédaction des cahiers des charges jusqu'aux dossiers des ouvrages exécutés (DOE)

Les fonctions dans la MOA - Wikipedia

Quelques extraits de la définition "Les fonctions dans la MOA" sur Wikipedia ...

Le maître d’ouvrage stratégique (MOAS)
À la tête de toute entité se trouve un dirigeant : PDG (Président-directeur général) ou DG (Directeur général) pour l’entreprise, DGA (Directeur Général Adjoint) ou directeur pour une direction de l’entreprise, chef de service pour les unités qui constituent la direction, etc. Là aussi, les appellations varient d’une entreprise à l’autre, mais se rapportent à l’organisation hiérarchique.

Le dirigeant de l’entité, le patron, c’est le « maître d’ouvrage stratégique » (MOAS). C’est lui qui prend les décisions importantes concernant la MOA, qui arbitre les différents entre ses collaborateurs, qui signe le contrat avec la Maîtrise d'œuvre (MOE), qui participe au (ou même préside) le Comité de pilotage ou le comité directeur du projet. Comme le système d'information (SI) est, dans la plupart des entreprises, à la fois la concrétisation de la stratégie et la condition de sa mise en œuvre, les décisions essentielles sont prises par le MOAS (notamment pour le lancement des grands projets et des programmes d'entreprise).

Cependant le MOAS n’est pas, en général, un expert en matière de système d'information. Même s’il a pu être un expert par le passé, ses responsabilités ne lui permettent pas de se tenir au courant de l’état de l’art. C’est pourquoi il se fait assister par un maître d’ouvrage délégué (MOAD) auquel il délègue (c’est le sens même de l’expression) le soin de l’expertise dans le domaine du système d'information.

Le principe qui sous-tend cette organisation, c’est la séparation de l’expertise et de la décision. L’expert n’a pas à porter le poids de la décision, mais il la prépare en fournissant au décideur les éléments d’information nécessaires ; le décideur n’a pas à se tenir au courant de l’état de l’art, mais il est attentif aux priorités de l’entreprise, vigilant quant à la perception de l'environnement, et il peut ainsi arbitrer entre les diverses solutions possibles en replaçant les informations que fournit l’expert dans un contexte plus large.
Le maître d’ouvrage délégué (MOAD)
Le « maître d’ouvrage délégué » (MOAD) est une personne, soit seule, soit à la tête d’une équipe si l’entité est importante. Il assiste le MOAS dont il est un des plus proches collaborateurs. Sa fonction est de veiller à la qualité du SI de l’entité, tant pour la conception que pour la façon dont il est utilisé. Il assiste le MOAS en lui fournissant, les éléments nécessaires aux prises de décisions. Il peut représenter le MOAS au Comité de pilotage, voire au comité directeur de projet. Dans certains cas de figure, le maître d'ouvrage délégué joue le rôle d'un directeur de projet.

Le MOAD est, au sein de l’entité, le responsable de la qualité des méthodes utilisées pour l’expression des besoins, la sélection des priorités, la réalisation des études préalables ou des cahiers des charges, la conduite de projet et la recette finale. Ses interlocuteurs naturels au sein de l’entité sont les chefs de service et les MOAO (voir ci-dessous). Son interlocuteur naturel au sein de la direction informatique est le responsable de domaine (voir MOE).
Le MOAD assure une « veille SI » : il se tient informé de ce que font en matière d'évolution du SI les entités comparables à la sienne pour s’assurer que celle-ci ne prend pas de retard par rapport à l’état de l’art, à l'évolution des marchés ou à la concurrence, ou même pour formuler des suggestions qui lui permettront de prendre de l’avance.
Le MOAD n’est pas un informaticien (c'est plutôt un méthodologue), mais il est bon qu’il ait assez de connaissances en informatique pour être, face à la direction informatique, un « client compétent », un client qui sait se faire comprendre et qui comprend ce qu’on lui expose.

Souvent, le MOAD est un ancien informaticien : l'informaticien, avec l'ouverture d’esprit nécessaire, assimile en peu de temps les caractéristiques essentielles du métier dans lequel il est appelé à évoluer (il serait plus difficile à un expert du métier de s'acclimater à l'informatique). Souvent le MOAD sera le bras droit du MOAS : placé à ses côtés, il connaît bien les diverses activités de l’entité. En fonction de sa compétence, le MOAD peut avoir vocation à devenir MOAS.

Le maître d’ouvrage opérationnel (MOAO)
Le « maître d’ouvrage opérationnel » (MOAO) est, dans l’entité, un expert qui connaît parfaitement l’un des grands processus du métier. Lorsque le SI est organisé en applications, le MOAO est celui qui connaît parfaitement l’application. Il sait, quand on veut faire des choses nouvelles, s’il sera possible d’y parvenir en modifiant des paramètres, ou s’il faudra un développement important ; il connaît les référentiels utilisés, les règles de gestion, les traitements en batch (dit traitements par lot), les échanges et interfaces avec les autres applications, etc. Il peut jouer le rôle d'accompagnateur du changement.

Il recueille les besoins des utilisateurs et établit ou supervise les spécifications générales. Il a pour interlocuteur naturel à la direction informatique le « chef de projet MOE » avec qui il entretient une relation permanente (voir MOE). Trop souvent, le MOAO est une personne seule qui possède une expertise précieuse. La situation peut être catastrophique s’il tombe malade, ou quand il prend sa retraite. Trop peu d’entreprises pensent à ce type de risque, mais souvent le MOAO lui-même n'est pas enclin à partager son savoir.

L’assistant à maîtrise d’ouvrage (AMO ou AMOA)
Le travail que doivent réaliser un MOAD ou un MOAO comporte des périodes de surcharge lorsqu’il faut spécifier, suivre ou recetter une importante évolution du système d'information ; lorsqu’il faut concevoir ou mettre en place des méthodes nouvelles ; lorsqu’il faut mettre en œuvre une expertise que l’entité ne possède pas.
Dans ces cas, l’entité fait appel, pour réaliser les travaux dévolus à la maîtrise d’ouvrage, à des consultants externes ou à des personnes que l'entreprise a mis à sa disposition : elles rédigent les spécifications ou documents méthodologiques, tiennent à jour les tableaux de bord, etc. On appelle ces personnes « assistants à maîtrise d’ouvrage » (AMO ou AMOA). Elles assistent la MOA dans l'accompagnement du changement.

L’expert métier
Pour garantir la pertinence du SI, c'est-à-dire son adéquation à la pratique professionnelle, il faut recueillir une information détaillée sur les conditions pratiques du travail quotidien. Le MOAO s’adjoint à cette fin d' « experts métier » venus du terrain qui contribuent au travail de spécification et de recette. Les indications fournies par ces experts métier sont indispensables mais il faut les interpréter : les praticiens ne sont pas les mieux placés pour définir les priorités, pour distinguer l'essentiel du secondaire.

L’utilisateur
La finalité du SI, c’est d’être un outil efficace entre les mains de l’utilisateur final. Cependant la population des utilisateurs est souvent trop nombreuse, trop dispersée pour participer à la conception du SI. Elle sera représentée dans cette tâche par les experts métier.

Les utilisateurs doivent recevoir une formation peu de temps avant que le nouveau produit ne soit mis en service ; leurs avis doivent être recueillis lors du déploiement du produit, et aussi lors de son exploitation courante, en procédant à des enquêtes périodiques.

La coordination des maîtrises d'ouvrage
La maîtrise d'ouvrage, telle que nous l'avons définie, relève de chacun des métiers de l'entreprise : seront maîtres d'ouvrage la direction commerciale, la direction de la production, la direction technique, la direction de la recherche, et - nous l'avons vu - la direction informatique elle-même, qui est par ailleurs maître d'œuvre par rapport aux autres directions.

Cependant le système d'information concerne non pas chaque métier pris séparément, mais l'ensemble de l'entreprise. Sa cohérence exige que les divers métiers utilisent le même référentiel pour l'identification des personnes de l'entreprise, produits et clients, ainsi que pour l'organisation. Certains processus transitent d'un métier à l'autre, ce qui implique des échanges de données. Les méthodes à utiliser par les diverses maîtrises d'ouvrage sont analogues. Le poste de travail, l'informatique de communication sont partagés par tous. Enfin, la gestion du portefeuille applicatif de l'entreprise suppose un arbitrage ultime pour sélectionner, parmi les projets présentés par chaque métier, ceux qui seront effectivement réalisés.

Ces diverses questions relèvent de la responsabilité du directeur général, qui est ainsi le MOAS suprême de l'entreprise. Il est assisté par une MOAD spécifique, chargée de la coordination et de l'animation des diverses MOA. Elle assiste le DG par ses avis, ses expertises, et elle a le devoir de l'alerter lorsque des risques ou opportunités se présentent.

Les décisions essentielles concernant le SI sont prises lors de réunions du comité de direction générale, dans une configuration spécifique que l'on baptise « Comité Système d'Information » (CSI). Le CSI est composé des MOAS (c'est-à-dire du DG et des patrons des divers métiers de l'entreprise, DGA ou directeurs. Chaque MOAS est accompagné au CSI par son MOAD qui lui sert de « sherpa » : le MOAD n'a pas pouvoir de décision lors des réunions du CSI, mais son expertise s'exprime.

Maîtrise d'Ouvrage (MOA) - Définition - Club des MOA des SI

La fonction de maître d'ouvrage par le Club des MOA de Systèmes d'Information
  
L'origine de la fonction

Une distinction entre "système d'information" et "système informatique" apparaît progressivement au sein des entreprises depuis quelques années : le système d'information comporte les processus de l'entreprise, les informations manipulées par ces processus et les fonctions qui traitent ces informations le système informatique comporte les composants techniques (traitements, données, matériels) qui supportent le système d'information en permettant de l'automatiser et le distribuer. Dans ce contexte, la fonction de maîtrise d'ouvrage du système d'information émerge et se structure de façon à assurer progressivement la responsabilité du système d'information, en s'appuyant sur un maître d'œuvre interne ou externe du système informatique.

Maîtrise d'ouvrage stratégique et maîtrise d'ouvrage opérationnelle
Le maître d'ouvrage stratégique (parfois appelé maître d’ouvrage commanditaire, ou simplement maître d'ouvrage) est le responsable opérationnel de l'activité qui s'appuie sur un système d'information. Il s'agit donc d'une (ou d'un ensemble de) personne(s) qui ne sont pas des professionnels du système d'information. Le maître d'ouvrage opérationnel (parfois appelé maître d'ouvrage délégué, voire aussi simplement maître d'ouvrage) assiste le maître d'ouvrage stratégique dans l'exercice de sa fonction. C'est un professionnel du système d'information.


Les activités de la maîtrise d'ouvrage opérationnelle
Les activités de la maîtrise d'ouvrage opérationnelle concernent :
  • Les projets d'évolution du SI : c'est historiquement la première activité qui a été structurée
  • Le fonctionnement du SI : cette activité a pour objet de piloter les systèmes en exploitation et de garantir le bon fonctionnement au quotidien
  • La gestion de l'évolution du SI : cette activité a pour objet le pilotage de l’articulation des plans d'évolution, en particulier autour des idées récentes d'urbanisation
Habituellement, les équipes de maîtrises d'ouvrage opérationnelle sont rattachées aux différents responsables d'activités ("responsables métiers").

Maîtrise d'Ouvrage (MOA) - Définition - Wikipedia

Quelques extraits de la définition "MOA" sur Wikipedia ...

(De manière générale) Le maître d'ouvrage (abrégé en MO ou MOA) ou la maîtrise d'ouvrage est le donneur d’ordre au profit duquel l’ouvrage est réalisé - Le maître d'ouvrage est celui qui commande (et qui paie) l'ouvrage à construire.

(Concernant l’univers informatique) La maîtrise d’ouvrage est responsable de l’efficacité de l'organisation et des méthodes de travail autour des systèmes d'information. Elle fait appel à un maître d'œuvre (MOE) interne et/ou externe pour obtenir les produits (matériels, logiciels, services et solutions) nécessaires à la réalisation de sa mission.
La maîtrise d'ouvrage joue un rôle clé dans l'organisation des entreprises, car elle est responsable de la bonne compréhension et des bonnes relations entre les directions métier et les directions informatiques (études et exploitation).
L'expression maître d'ouvrage est employée en France. L'expression entrepreneur général est employée au Canada.

Il existe pour chaque direction métier une maîtrise d'ouvrage qui : 

  • Décrit les besoins, le cahier des charges
  • Etablit le financement et le planning général des projets
  • Fournit au MOE les spécifications fonctionnelles générales (le « modèle métier ») et valide la recette fonctionnelle des produits
  • Coordonne les instances projets entre les utilisateurs métiers et la MOE
  • Assure la responsabilité de pilotage du projet dans ses grandes lignes
  • Adapte le périmètre fonctionnel en cas de retard dans les travaux, pour respecter la date de la livraison finale

Au niveau de l'entreprise dans son ensemble, la coordination des maîtrises d'ouvrage (voir ci-dessous) prend les grandes décisions sous l'autorité du directeur général ; elle :
  • Décrit les exigences générales, les révise le cas échéant
  • Contrôle la gestion par le maître d'œuvre (MOE) du portefeuille de projets
  • Identifie avec la direction les problèmes juridiques pouvant se poser
  • Participe à la politique de sécurité du système d'information
  • Contrôle l'exécution par le MOE des contrats d'infogérance passés avec les fournisseurs
  • Assure avec le MOE les tâches d'urbanisation du système d'information

La fonction de maîtrise d'ouvrage a été mise en avant dans les projets de système d'information pour mieux prendre en compte les dimensions « non informatiques » ou « non techniques » des projets :
  • Organisation et modification des processus ou procédures,
  • Conduite du changement (voir accompagnateur du changement),
  • Formation des utilisateurs, etc.

On distingue quelquefois différentes fonctions dans la maîtrise d'ouvrage :
  • Le maître d’ouvrage stratégique (MOS)
  • L'architecte métier
  • Le maître d’ouvrage délégué (MOD)
  • Le sponsor
  • Le maître d’ouvrage opérationnel (MOO)
  • L’assistant à maîtrise d’ouvrage (AMO)
  • L'expert métier
  • Enfin l’utilisateur, au service duquel se trouvent toutes les autres fonctions

Le rôle de la maîtrise d'ouvrage, et plus précisément de la maîtrise d'ouvrage stratégique, est de s'assurer de la bonne adéquation entre :
  • d'une part la stratégie « métier » de l'entreprise ou de l'organisation (les objectifs, les enjeux...)
  • et d'autre part le système d'information qui doit se mettre au service de cette stratégie
C'est ce qu'on appelle parfois : l'alignement stratégique.