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

Recueillir les exigences des différentes parties prenantes d'un projet, c'est comme construire les fondations de votre projet. C'est sur ces exigences que l'ensemble du projet va reposer. Dans le billet "Comment améliorer l'alignement IT/métier en utilisant un outil de gestion des exigences ?", j'ai essayé d'expliquer l'intérêt d'un outil pour gérer ces exigences. Mais avant de les formaliser un minimum, il faut déjà les découvrir.

Organisez des entretiens Top-Down

Je conseillerai plutôt de commencer par rencontrer les personnes ayant une vision plus globale du processus concerné pour finir par les utilisateurs clés des systèmes supportant le processus (par exemple dans une salle des marchés commencer par s'entretenir avec un directeur de l'exploitation ou un directeur d'une ligne métier, ensuite voir un responsable de table pour finir par un opérateur de marché et enfin un assistant). Cela permet de commencer par découvrir les exigences stratégiques pour finir par les exigences fonctionnelles et non fonctionnelles. Je pense également que le temps à passer doit être moins important avec le top management qu'avec les opérateurs au cœur du processus.

Préparez vos entretiens

Une réunion demande toujours d'être préparée, d'être conduite, puis il faut en rédiger un compte-rendu. Le compte-rendu d'un entretien de recueil de besoins est la matière première qui va permettre de construire le référentiel des exigences. Le point clé de la préparation de la réunion, afin d'avoir un compte-rendu copieux, c'est de prévoir les questions qui vont cadencer l'entretien. Ces questions doivent être adaptées à votre interlocuteur et suivre une évolution du plus global au plus précis. Vous trouverez des idées de questions génériques dans cet article de Mr. Monteleone lu sur modernalyst.com : Generic Questions for Interviewing Stakeholders.

Pensez processus métier et architecture orientée service (et non pas système)

On ne cherche pas encore à spécifier un système ou une solution même si les utilisateurs auront tendance à se rattacher à du concret. Posez vos questions afin qu'elles soient le plus possible absolue vis à vis des solutions (pour caricaturer, demandez quelles sont les informations nécessaires pour remplir un dossier plutôt que de demander quel écran de saisie est nécessaire). Gardez également toujours en tête comment cette partie s'inclut dans un processus métier complet. Voir par exemple cet article sur business analyst times qui décrit cette approche avec une jolie métaphore du temple grec : Breaking Down the Silos for Better Requirements Elicitation. Et comme je le disais déjà dans mon billet précédent La MOA doit elle comprendre SOA ?, penser "services" vous permettra de poser les bonnes questions pour identifier les réutilisations possibles. Certaines MOA vont jusqu'à prôner une approche où l'on va tenter de conformer les besoins aux services existants comme dans cet article de John Moe lu sur modernalyst.com : Service Oriented Analysis. J'ai un peu de mal avec cette approche car tordre ainsi le besoin c'est risquer d'aboutir sur une solution qui ne saura satisfaire votre sponsor.  Mais dans certains cas ça pourrait marcher, si le SI est déjà organisé en SOA d'un bon niveau, comme le dit l'auteur de cet article.

Une exigence n'est donc pas simplement une information qui est venue à nous sans aucun travail. Le recueil des besoins est une phase clé du projet. Se contenter d'un mail succinct (le fameux Post-it) envoyé par le sponsor pour se lancer dans une phase de spécification fonctionnelle n'est pas suffisant. Il est vrai que cette phase de projet n'est pas "technique" mais exploite plutôt les compétences d'analyse et le relationnel de la MOA, et on peut donc parfois la sous-estimer sur un planning. Mais attention alors au risque de retard, car entre la préparation, la planification des entretiens, et l'analyse des résultats, cette phase peut être très consommatrice de temps.

L'informatique ne doit plus simplement suivre le métier. On attend aujourd'hui d'un SI qu'il soit capable de s'adapter à toutes les évolutions du business même ceux qui n'ont pas été anticipés par les opérationnels. Dans une étude concernant l'état de l'art de l'aligement IT / Métier en France publiée en 2008 par le cabinet PAC - Pierre Audoin Consultants, on apprend que La collaboration entre maîtrises [maîtrises d'ouvrage et maîtrises d'œuvres] est un point crucial, qui pourrait être le fil rouge de cette étude. Elle est jugée critique à 94%. On note également dans cette étude que l'intégration MOA/MOE est le deuxième levier juste derrière le projet stratégique au niveau de l'entreprise pour améliorer l'alignement IT / Métier.

Il existe des outils qui peuvent aider à plusieurs niveaux sur ce sujet. Ce sont les outils de gestion des exigences (requirements management). Une exigence fait référence à un besoin d'une des parties prenantes du projet. Une exigence peut être fonctionnelle ou non fonctionnelle. Concernant les outils, on peut par exemple citer Entreprise Architect. Dans leur document Requirements Management with Enterprise Architect, ils expliquent comment UML est utilisé pour modéliser les exigences. Dans un autre style, moins graphique, IBM propose DOORS. Dans leur livre blanc Ten steps to better requirements management, IBM nous explique ce qu'une exigence doit être :

• Correcte (techniquement et juridiquement possible) ;
• Complète (exprime une idée ou un fait dans sa totalité) ;
• Claire (sans ambiguïté) ;
• Non contradictoire (pas en conflit avec une autre exigence ) ;
• Vérifiable (il est possible de définir si le système répond à cette exigence) ;
• Traçable (identifié de manière unique et tracé) ;
• Faisable (peut être accompli dans les coûts et délais prévus) ;
• Modulaire (peut être changé sans impact excessif) ;
• Indépendant de la conception (ne parle pas de solution concernant la conception).

(la traduction est un métier)

Une fois que les exigences sont exprimées, tout l'intérêt d'un outil de gestion des exigences est de permettre la traçabilité afin de pouvoir répondre aux questions suivantes :

• Est-ce que tous mes besoins ont été couverts par le système ?
• Quels besoins étaient mal exprimés et donc volatiles ?
• Quel est l'impact si je modifie une exigence ?

C'est en étant capable d'analyser ces points qu'on pourra ensuite améliorer l'alignement IT / Métier. Par exemple si un des besoins était trop volatile, l'IT ne pourrait pas s'aligner. Il peut donc être nécessaire par exemple de chercher une autre organisation qui permette d'avoir une expression des besoins plus pérenne. Un besoin peut-être exprimé sur un Post-It  (heu pardon je voulais dire papillon adhésif amovible) par une des parties prenantes du projet, mais la MOA se doit ensuite de formaliser ces besoins sous forme d'exigences. Un bon outil permettra de tirer profit d'une telle démarche.

Modernanalyst.com - There's an app for that!

Pour modéliser un processus métier, l'OMG propose sa Business Process Modeling Notation (http://www.bpmn.org/). La dernière version des specs nous éclaire sur l'objectif de cette notation :

http://www.omg.org/spec/BPMN/2.0/

The Object Management Group (OMG) has developed a standard Business Process Modeling Notation (BPMN). The primary goal of BPMN is to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes. Thus, BPMN creates a standardized bridge for the gap between the business process design and process implementation.

Les enjeux du BPM vont bien au delà de la simple représentation d'un processus métier. Mais avant d'investir dans des usines à gaz qui vont implémenter, exécuter et monitorer vos processus métiers à partir de beaux diagrammes, il faut déjà modéliser ces processus métiers. Que ce soit le processus existant ou le cible, il est toujours utile de réunir les différents acteurs sur un diagramme que tout le monde peut comprendre. Cela permet de comprendre rapidement les problèmes les plus importants et de trouver donc les meilleures optimisations.

Pour modéliser vos processus métiers, un outil comme BizAgi Process Modeler peut vous aider. Cet outil vous permet d'exporter vos diagrammes sous formes d'images, de document Word... Dans cette version gratuite vous serez limités à la réalisation des diagrammes, sans aller jusqu'à l'exécution de vos processus. Voilà un exemple de réalisation :

Pour aller plus loin, voilà un tutoriel sur BPMN réalisé par IBM.

Tout comme UML, BPMN n'est pas une méthodologie. C'est une notation très efficace pour modéliser les processus métiers, mais ce n'est qu'un outil. D'ailleurs on peut aussi utiliser Merise et ses MCT (Modèle conceptuel des traitements) et MOT (Modèle organisationnel des traitements) qui même s'ils sont moins tendances, permettent également de représenter des processus métiers. Par contre au delà de la modélisation, BPMN est plus intéressant puisqu'il est une base pour tous les outils qui permettent ensuite de gérer complètement les processus métiers (voir par exemple ce que propose la suite BPM d'IBM), mais là on sort de la thématique de ce blog qui se veut "pragmatique".