Attention, auto-promo à l'intérieur de ce billet !

Cela faisait longtemps que je n'avais pas écrit sur ce blog ! Je vais essayer de contribuer plus régulièrement.

J'ai profité de cette absence sur ce blog pour co-écrire un livre sur la maitrise d'ouvrage du SI. Pour cela, nous avons utilisé la plateforme Leanpub qui permet d'écrire un ouvrage de manière collaborative, en suivant les principes du Lean. L'idée c'est donc d'écrire une première version du livre que l'on publie assez tôt afin d'obtenir un retour rapide des lecteurs.

Donc si vous êtes intéressés par les sujets évoqués sur ce blog, vous aimerez ce livre qui présente des techniques très utiles pour réussir en tant que MOA. Il y est notamment question de : gestion des exigences, valeur métier, Minimum Viable Product, vision, business case, modélisation UML, story-board, maquette, user story, Behavior Driven Development, Acceptance Tests Driven Development, conduite du changement, rétrospective... En téléchargeant ce livre maintenant, vous pourrez l'avoir pour 0€ et en plus vous pourrez influencer son contenu en nous faisant vos commentaires sur ce qu'il faut étoffer, ajouter ou corriger. 

Si vous souhaitez plus d'information, c'est par ici :

Faut-il automatiser tous les processus manuels ? Informatiser un processus manuel répond souvent à des exigences de traçabilité, de reporting, de pilotage. Mais faut-il éliminer toute action manuelle ? Quels sont les risques lorsque l'on remplace l'homme par la machine ? On sait faire danser les robots, mais sont-il capables d'improviser ?

CEBIT 2011: A Nao robot performs at Intel's Cebit news conference

Les règles métiers doivent rester la propriété du métier

Il existent des systèmes dédiés à la gestion de règles métiers, et quoi qu'il en soit, tous les systèmes d'information implémentent des règles métier. Mais parfois certaines parties prenantes refusent la mise en place de règles métiers exécutées automatiquement. Pourquoi ? Parce qu'elles ne veulent pas perdre la connaissance et la gouvernance de leurs processus. Il faut faire très attention à ce que la mise en place d'outils de gestion des règles métiers et des processus métiers se fasse sans déposséder les "métiers".

Calculer le retour sur investissement selon l'axe financier et celui de la flexibilité

Calculer le retour sur investissement selon l'axe financier est une chose primordiale, mais il ne faut pas oublier celui de la flexibilité. Développement durable, agilité sont des termes souvent entendus associés à de lourds projets d'automatisation de processus métiers. N'oublions pas que l'être humain est très adaptable, bien plus que le meilleur SI aussi agile soit-il.

Inutile donc de vouloir tout automatiser à tout prix. N'oublions pas que le SI supporte les règles métiers et les processus métiers, mais qu'il n'est pas le métier.

La MOA doit-elle être un expert fonctionnel ? Est-il bon d'être spécialisé sur un seul domaine ? Voilà une idée de sujet pour mon blog que l'on m'a soufflée aujourd'hui. La personne qui m'a posé cette question n'est pas la seule à se la poser ! Michelle Swoboda répondait à une question similaire sur le blog de Bridging the Gap : Help a BA! What is the difference between a subject matter expert and a business analyst?

Oui, la MOA peut être un expert fonctionnel...

Les MOA peuvent être au départ un expert fonctionnel qui est monté en compétences sur les aspects projet et les techniques de la maîtrise d'ouvrage. Par exemple, en finance de marché, un ancien opérateur Front ou Middle Office peut devenir maîtrise d'ouvrage sur un projet SI (comme Jérôme Kerviel : "consultant informatique" au revenu de "2.300 euros"). Dans ce cas c'est un expert fonctionnel et métier qui est monté en compétences pour apprendre ce qu'était un projet SI et quelles étaient les activités d'une MOA et les livrables à fournir dans le cadre d'un projet SI. Plus souvent les MOA acquièrent l'expertise fonctionnelle avec le temps, en restant plusieurs années dans le même domaine fonctionnel. Elle devient alors un expert fonctionnel.

... mais être un expert fonctionnel ne signifie pas qu'on est une bonne MOA...

Être un expert fonctionnel ne signifie pas que l'on est une bonne MOA. La maîtrise d'ouvrage est un domaine fonctionnel à part entière. Il y a énormément de compétences à acquérir propres à ce domaine, les process de développement informatiques sont spécifiques à cette industrie. De plus quand on est MOA sur des projets SI, il faut avoir une culture informatique importante pour pouvoir comprendre les enjeux IT.

... alors finalement faut-il changer de domaine fonctionnel ?

Recrutez des gens d'autres industries ! Je vous invite à lire cet article Why Innovation Is Beginner's Luck qui parle des défauts que l'on peut avoir lorsqu'on est depuis trop longtemps dans une même industrie (The Myopia of Experts). Il est vrai qu'un regard neuf amène toujours des solutions qu'on n'arrive pas à faire émerger quand on est depuis trop longtemps sur le même sujet. Mais si vous choisissez de recruter une MOA qui n'est pas un expert du domaine, il vous faudra quelqu'un d'autre pour remplir ce rôle ! Donc cela ne fonctionnera que si vous avez des utilisateurs expérimentés et disponibles avec qui travailler ou alors si votre organisation a la maturité nécessaire pour formaliser ce type de rôle.

Finalement, en tant que MOA, je pense qu'il vaut mieux être spécialisé dans un domaine plutôt que d'être complétement généraliste. Il est important d'être passionné par le domaine dans lequel on travaille et d'essayer d'en apprendre un maximum afin d'être critique vis à vis des demandes des sponsors et des utilisateurs. Mais pourquoi ne pas construire sa carrière sur deux ou trois domaines de prédilection ? Cela permet de garder de la fraicheur et de rester innovant. L'inconvénient c'est que cela demande de se remettre en cause et de prendre des risques...

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

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 !