La MOA pragmatique du SI (Business Analysis, Analyse d'Entreprise, Maitrise d'Ouvrage)

Aller au contenu | Aller au menu | Aller à la recherche

Tag - MOA

Fil des billets - Fil des commentaires

mardi, mars 2 2010

La MOA est-elle une hôtesse de l'air ?

Par Olivier Durand le mardi, mars 2 2010, 08:20 - Supporter

Le support applicatif métier est difficilement externalisable, contrairement au support sur les applications dites "bureautiques" (gestion des courriers électroniques, traitement de texte...). Plus les applications métiers sont critiques pour l'entreprise, plus l'équipe support applicative doit avoir des profils de haut niveau et des compétences pointues. Ce sont parfois directement les maîtrises d'ouvrage qui exercent le rôle de support applicatif ou support fonctionnel, alors que d'autres organisations mettent en place des équipes dédiées à ce support très proche du métier (équipes que l'on peut considérer alors comme assistance à MOA). La MOA doit donc avoir le sens du service ?

Dans l'article Le « sens du service », une question d'organisation sur scienceshumaines.com l'auteur évoque les travaux d'Arlie Russel Hochschild qui dès 1983, dans The Managed Heart, définit le concept de travail émotionnel pour les hôtesse de l'air consistant à réélaborer leur ressenti et à influer sur celui des passagers, notamment en diffusant un sentiment de sécurité. La maîtrise d'ouvrage serait en fait un steward ou une hôtesse de l'air ? Il est vrai que face à un problème de production important ou face à une forte réticence au changement, la MOA peut avoir ce rôle de travail émotionnel : calmer l'utilisateur si ses craintes ne sont pas fondées, communiquer les informations nécessaires sans créer de panique, et éventuellement expliquer comme accéder aux toboggans de secours si le crash est inévitable !

Ensuite l'auteur de cet article parle des travaux du sociologue américain Ervin Goffman (Asile, 1968) pour définir la compétence de service : la capacité de prendre une décision non prévue par une procédure impérative et de la présenter comme professionnellement justifiée. Une telle décision n'est jamais facile à prendre car elle se prend toujours dans un contexte délicat. Donc plus qu'un sens du service commun une MOA doit avoir cette "compétence de service" afin d'être capable de réagir à des problèmes variés qui attendent des solutions spécifiques.

La notion de support informatique est souvent mal perçue car caricaturée en un centre de service outsourcé en Inde, en Afrique du Nord ou en Irlande, où les opérateurs de ces helpdesks sont notoirement incapables de résoudre un problème, ni même souvent de le comprendre. La faute sûrement aux grands opérateurs télécoms qui ont souvent eu des démarches assez radicales en terme d'outsourcing de ces services. Pourtant faire du support applicatif ou fonctionnel sur des applications très critiques demande des compétences pointues sur le domaine géré et également une grande compétence de service. Il me semble également qu'il est toujours bon pour une MOA même si elle est orientée projet d'être au contact de la production et de ses réalités de terrain, cela permettant de concevoir des solutions fonctionnellement adaptées à la réalité.

mardi, janvier 12 2010

Management transverse, comment vaincre les clivages ?

Par Olivier Durand le mardi, janvier 12 2010, 23:32 - Piloter

En tant que MOA, on est souvent amené à travailler en réseau, à utiliser le management transverse. Et quand l'organisation de notre entreprise est très hiérarchisée, ce travail en réseau n'est pas facilité. Autre contrainte au niveau SI, l'architecture orientée service a souvent été mise en place sans refonte de l'organisation. Voilà les pire cas que l'on peut rencontrer et quelques idées pour les gérer au mieux.

Gérer le clivage MOA/MOE

  • La caricature :

Il vaut mieux être au courant : La MOA pense que les MOE sont des "pisseurs de code", la MOE pense que la MOA sont des "pisseurs de slides".

  • Les solutions du point de vue de la MOA pour éviter d'en arriver là :

Utilisez le plus souvent possible un style de management participatif. Demandez "quel est le plan d'action à mettre en œuvre pour tenir la date de livraison ?" plutôt que d'imposer une échéance.

Utilisez également un style autocratique lorsqu'il le faut. La MOA a son expertise, les décisions en relevant doivent être clairement prises et actées de tous. Ceci n'empêche pas d'expliciter les tenants et les aboutissants bien sur.

De la même manière, ne remettez jamais en cause les décisions prises par la MOE qui relèvent de leur expertise. Par exemple, une MOA ne doit pas remettre en cause le chiffrage fourni par la MOE, même si elle est en droit de demander des détails ou des explications.

Gérer le clivage MOA/Sponsor

  • La caricature :

Le Sponsor n'a pas de temps à accorder à  la MOA. Pour lui, la MOA est un "informaticien" comme un autre. La MOA pense que son sponsor ne s'implique pas assez dans le projet.

  • Les solutions du point de vue de la MOA pour éviter d'en arriver là :

Usez de vos qualités relationnelles. Sachez apporter légèreté et humour quand les conditions sont réunies, soyez toujours d'humeur égale, traitez parfois de hors sujets...

Adaptez votre style à votre interlocuteur. Certains interlocuteurs peuvent faire attention aux détails : ponctualité, look, sachez vous adapter.

Optimisez votre temps. Organisez des réunions courtes (30 minutes sont souvent suffisantes) mais régulières. Préparez les en utilisant un support optimal (type "Flash report"), conduisez les réunions en évitant les écarts, rédigez et diffusez toujours le compte-rendu dans la foulée pour mettre noir sur blanc les résultats de ces réunions.

Gérer le clivage intergénérationnel

  • La caricature :

La différence essentielle entre un jeune con et un vieux con réside dans le temps qu'il leur reste à être cons. - Jean Dion.
En tant que MOA vous serez amener à travailler avec des gens qui ont des rôles bien différents, vous amenant à réaliser un grand écart générationnel.

  • Les solutions du point de vue de la MOA pour éviter d'en arriver là :

Soyez ouvert. Vous allez être tantôt le jeune, tantôt le vieux. Sachez rester ouvert aux points de vue de tous les intervenants. Un utilisateur qui a 30 ans d'expérience sur son poste ne vous fera pas les mêmes retours qu'un utilisateur qui sort de l'école. Mais tous sont bon à prendre.

Acceptez la critique. On vous prendra un jour pour un jeune prétentieux aux dents longues parce que vous souhaitez bouleverser un processus métier qui fonctionne très bien depuis 15 ans, et le lendemain pour un vieux de la génération X parce que vous ne pratiquez pas le twittering et que vous avez aimé connu le doux chant du modem 56K. Acceptez de recevoir toutes les critiques, vous n'avez rien à prouver.


dimanche, janvier 3 2010

Comment être sur d'être bien formé ?

Par Olivier Durand le dimanche, janvier 3 2010, 14:31 - Divers

Je profite de la dernière petite dose d'humour du site modernanalyst.com pour parler de la formation des MOA.

Pick your Business Analysis training provider Very Carefully

Je pense qu'assez peu d'écoles forment aux métiers de MOA. Sans parler des compétences fonctionnelle ou métiers spécifiques à chaque domaine, les MOA doivent avoir des compétences variées : compétences relationnelles, méthodologies, modélisation, pilotage de projet, architecture fonctionnelle... Pour que les choses bougent, encore faut-il que tous les acteurs se rendent compte que ces activités sont aussi importantes que les compétences métiers ou techniques pures comme souligné dans cet article de LeMondeInformatique.fr :

Des compétences nouvelles pour des SI durables

... il faut aussi que ces jeunes aient une formation allant au-delà de la technologie, qu'ils aient des notions d'architecture de SI et de modélisation, notamment. Sylvie Servigne, enseignante-chercheuse à l'Insa de Lyon, a ainsi expliqué que l'Institut national des sciences appliquées s'efforce, au-delà de la formation d'informaticiens généralistes, de dispenser des enseignements en méthodes de conception et en urbanisation et architecture. Mais elle le reconnaît elle-même, ces jeunes ne peuvent avoir, à la sortie de l'école, les compétences et la maturité nécessaires pour encadrer des projets de grande envergure. D'où l'intérêt, comme le soulignait Bruno Lanvin, de mettre l'accent sur ces formations pour préparer l'avenir.

Pour ce qui est de la formation continue, je crois qu'un grand nombre de MOA se contentent de l'expertise acquise au fil du temps. Il est bien évident que ces activités demandent de l'expérience et des connaissances pointues du métier. Mais selon moi une MOA doit tout autant faire de la veille technologique et se tenir à niveau pour faire face aux grands concepts soutenus par des fournisseurs habiles : Master Data Management, Business Rules Management Sytem, Business Process Management...

D'où l'importance des instituts de formation, mais encore faut-il tomber sur des acteurs sérieux !

mardi, décembre 16 2008

Bienvenue sur mon blog.

Par Olivier Durand le mardi, décembre 16 2008, 14:14 - Divers

Bienvenue sur mon blog.

La maitrise d'ouvrage (MOA) dans le contexte d’un système d’information (SI) est un concept assez flou, peu normé. Je vous renverrai vers Wikipedia pour une définition assez générique :

Contenu soumis à la GFDL. Source : Article Maîtrise d'ouvrage de Wikipédia en français (auteurs) 

Le maître d'ouvrage (MOA) ou la maîtrise d'ouvrage est le donneur d’ordre au profit de qui l’ouvrage est réalisé.
Cette notion, comme celle de maître d'œuvre, vient à l'origine du domaine de la construction. Elle s'est progressivement appliquée à d'autres domaines comme les partenariats industriels, les projets de système d'information, ...
Le maître d'ouvrage est une personne morale (administration, entreprise, etc.), une entité de l’organisation. Ce n’est en principe pas une personne physique, même si par abus de langage on dit souvent « untel est maître d’ouvrage », alors qu'il est plus exactement MOAD (maître d'ouvrage délégué), MOAO (maître d'ouvrage opérationnel) ou AMO (assistant au maître d'ouvrage). Ceux-ci ont le pouvoir de représenter juridiquement et financièrement le Maître d’Ouvrage.

Il y a souvent un débat sur ce que ce qu'on appelle MOA : est-ce un rôle IT ou business ? En tout cas c'est une fonction qui fait le lien entre les acteurs "métiers" d'un système et l'IT qui doit gérer et développer le système d'information. En anglais on parlera de rôles de Business Analyst et de Business System Analyst. Enfin, ces rôles ne définissent pas un poste. Ainsi dans une organisation une personne pourra jouer le rôle de chef de projet et de maitrise d'ouvrage opérationnelle, alors que dans une autre organisation il aurait uniquement joué le rôle d'assistant au maître d'ouvrage.


Je me contenterai pour ma part de simplement citer les activités que la MOA est amenée à pratiquer (en partie ou en totalité, en fonction de l’organisation des équipes) dans le cadre d’un projet SI :

- Etudier ;
- Spécifier ;
- Piloter ;
- Recetter ;
- Supporter.

Le but de ce blog sera simplement de discuter des problèmes très concrets rencontrés par la MOA dans le cadre de ces activités, et de les traiter de manière très pragmatique.

page 2 de 2 -