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

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

samedi, janvier 1 2011

Que faut-il souhaiter à la MOA du SI pour 2011 ?

Pour 2011, la croissance sera globalement faible en France (Croissance 2011 : le scénario de Bercy fragilisé par les prévisions de l'Insee). Mais certaines industries auront de belles perspectives de d'évolutions voire transformations de leur business (et si Apple achetait facebook ?). Alors pour commencer, je souhaite que votre entreprise - SSII, cabinet de conseil, éditeur de logiciel ou client final - puisse vous proposer des projets ambitieux de transformation de leurs métiers.

Indépendamment de ces projets business, cette année sera rythmée par la percée de nombreuses technologies dans l'environnement professionnel : tablettes, mobilité accrue, cloud computing privé (voir Les dix prédictions d'IDC pour 2011 sur fond d'expansion numérique)... Cela amènera de nouvelles réflexions sur la stratégie IT et de beaux projets à mener pour 2011. 

Mon dernier souhait pour 2011 est que la Maitrise d'ouvrage soit reconnue comme un métier à part entière qui demande des compétences particulières qui ne sont pas celles d'un chef de projet, pas celles d'un architecte, ni celles d'un expert métier. C'est un rôle qui demande des techniques d'analyse, de formalisation, de management transverse qui sont propres à ce rôle. On peut souhaiter que les formations en informatique intègrent cette dimension de manière plus explicite. Même la terminologie n'est pas claire. Par exemple la définition du France IIBA chapter est différente du terme Maitrise d'ouvrage:

Nous traduisons ici business analysis par « analyse d’entreprise ». En fait, c’est le domaine d’application de l’approche qui dira comment le traduire exactement : métier, marché, affaire etc.

En ce qui me concerne, je vais continuer à promouvoir ce métier au travers de ce blog, et comme bonne résolution 2011 : participer davantage aux communautés qui traitent de ce sujet !


vendredi, octobre 15 2010

Lean, Six sigma, Kanban... la MOA peut-elle rester un artisan du SI ?

Lean, Six sigma, Kanban... les méthodes et outils de l'industrie "lourde" ont débarqué sur le front du SI. Avez-vous déjà visité une usine de production ? Il n'y a que peu de similitudes avec un open space où l'on fait évoluer un système d'information. C'est une critique assez souvent entendue de ces méthodes appliquées à l'informatique : "Un développeur n'est pas un ouvrier sur une chaîne de production, c'est un artisan.". Et la maitrise d'ouvrage du système d'information ? Elle travaille sur des sujets qui sont tous différents, impossible de reproduire une méthode à l'identique, chaque projet a ses contraintes et ses spécificités, aucune solution ne marche deux fois. Alors, comment conserver un esprit créatif quand ces méthodes poussent à l'uniformisation et à la rationalisation ?

Conserver son esprit critique

Un cadre méthodologique permet d'avoir des repères et d'être opérationnel plus rapidement. Mais si cela nous semble nécessaire, il ne faut pas hésiter à sortir de ce cadre. Il n'y a pas de vérité absolue sur la manière de recueillir un besoin ou de modéliser un processus métier. Il faut absolument conserver son esprit critique et remettre en cause le process si celui-ci ne semble pas efficace. D'ailleurs le Lean se base sur le principe Kaizen (amélioration continue)  pour atteindre ses objectifs de performance.

Prendre son temps

Certaines activités intellectuelles ne sont pas compatibles avec le micro management. Parfois, seul le temps permet de démêler des sujets complexes, et une méthode centrée sur le "à faire" / "fait" ne prends pas forcément bien en compte ces temps de réflexion. Il faut apprécier le temps où l'on ne réalise rien comme un temps nécessaire et non pas du temps perdu.

Utiliser les outils de la créativité

Brainstorming, veille concurrentielle, cartes heuristiques... Il existe plein d'outils pour catalyser la créativité. Une ambiance d'équipe sereine permet aussi de laisser libre cours à l'initiative et la créativité, alors qu'une ambiance tendue risque de freiner les propositions de peur d'être rabroué.

Je suis convaincu que l'utilisation de méthodologies et d'outils adéquats permettent de faciliter le travail de la MOA et d'augmenter les performances d'une équipe projet. Mais il ne faut pas agir sans comprendre, et il ne faut pas oublier que ce n'est pas aux équipes projet de s'adapter aux méthodes, mais que ce sont les méthodes qui doivent être adaptées aux équipes. 

L'ordre est le plaisir de la raison, mais le désordre est le délice de l'imagination.
Paul Claudel.

vendredi, août 27 2010

La MOA doit-elle donner du relief ?

Nous avons vécu beaucoup d'innovations dans les interfaces homme-machine ces dernières années : terminal tactile multipoint, moniteurs informatiques et téléviseurs en 3D relief, réalité augmentée (pour faire son shopping par exemple), retour des "tablettes"... Mais est-ce que la MOA doit s'intéresser à ces technologies ?

Pas de Système d'Information sans technologie...

Sur ce blog, je traite plutôt du rôle de MOA vis à vis du système d'information. Il est de plus en plus difficile de trouver un processus métier dans une entreprise qui n'utilise pas l'informatique. Et le premier contact des utilisateurs avec leur SI, c'est via les interfaces graphiques des systèmes. Il est donc très important d'être curieux dans ce domaine : essayer les dernières versions des navigateurs Internet, suivre l'évolution des applications open source majeures... et également assurer une veille technologique ! Même si la MOA analyse le fonctionnel ou le métier, il est bon de savoir ce qu'il est possible ou sera possible de faire avec l'outil informatique. Par exemple, la puissance des téléphones portables permet aujourd'hui de développer de nouvelles interfaces en 3D plus immersives (voir cette news sur pcinpact .com : Intel et Nokia travaillent sur des téléphones à interface 3D). Ne voyez-vous pas des applications possibles dans votre domaine ?

... mais n'oublions pas nos objectifs

Mais attention, on croit que les rêves, c'est fait pour se réaliser. C'est ça, le problème des rêves : c'est que c'est fait pour être rêvé (Coluche). Car vous avez un budget à tenir, et les stratégies IT des grands groupes ne doivent pas simplement suivre les modes. Inutile donc de lancer des POC (Proof Of Concept) à tout va, il faut savoir cibler en fonction de la stratégie du SI. N'oubliez pas également que vos utilisateurs sont toujours réfractaires au changement. Alors, évitez les interfaces trop éloignées des standards de fait.

Vidéo : Hiro III, un robot hyptique et une interface tactile en trois dimensions

mardi, décembre 16 2008

Bienvenue sur mon blog.

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.