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

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

mardi, décembre 3 2013

Est-ce que la MOA va changer de moto ? Ou quand utiliser les techniques d'élicitation.

Parfois, vos parties prenantes vont vous prendre pour le Père Noël et vont vous soumettre un besoin, qui n'en est finalement pas un.

J'ai besoin d'une nouvelle moto pour aller bosser.

Alors, vous allez vous lancer dans une analyse détaillée de ce besoin. Votre demandeur va détailler un peu plus son besoin. souvent en parlant déjà d'une solution.

Je voudrais une Ducati Hypermotard SP

Puis, vous allez interviewer les différentes parties prenantes :

En tant que marketeux, je pense que vous devriez rouler en BMW R 1200 RT.

En tant qu'assureur je pense que le plus raisonnable serait une Honda CB 500 X.

En tant que banquier je pense que vous n'avez pas le budget.

En tant que Sécurité Routière, je pense que c'est trop risqué de rouler en 2 roues.

En tant qu'expert, je pense que ça tombe bien, c'est le salon de la moto, allons essayer une présélection de modèles puis on fera une analyse comparative.

...

Alors là, je dis STOP. On est allé trop vite. Avant de détailler, modéliser, valider ces exigences, il faut avoir vérifier que le besoin était bien compris. Dans le Business Analysis Body of Knowledge, on parle de "elicitation". Ce terme a été traduit dans la version en français par "élicitation" et est défini comme suit :

L’élicitation peut se définir de la manière suivante : se renseigner pour connaitre divers éléments (latents ou potentiels), poser des questions,  s’informer pour obtenir de l’information ou des réponses.

Les techniques à utiliser pour cette phase critique de la gestion des exigences sont : brainstorming, étude de la documentation existante, groupes de discussion, interviews, storyboards, sondage/questionnaire... Des techniques assez ouvertes qui facilitent la découverte.

Dans mon exemple, le vrai besoin de cette partie prenante est de se rendre au boulot en moins d'une heure. Et comme la batterie de sa moto actuelle est faible, elle ne démarre pas. Finalement il suffira juste de recharger la batterie de sa Honda Hornet, et ça roule.

Le Système d'Information, c'est pareil.

jeudi, août 25 2011

Comment la MOA peut dépasser la dépression post projet ?

Le baby blues survient entre le deuxième et le quatrième jour après l'accouchement, dure en moyenne deux jours. Une fois l'euphorie de l'aboutissement passée, et les premières mises en pratiques approximatives, on y est. Le projet est terminé. Alors que le stress redescend, comment dépasser la dépression post projet ?

 

Identifiez les réussites et les échecs de ce projet

Indépendamment de l'aspect affectif, cherchez à identifier les réussites et les échecs de ce projet. Pour la MOA, en premier lieu il faut identifier si les exigences ont été remplies. Si vous avez les outils adéquats, vous pouvez analyser les caractéristiques des exigences : ont-elles été volatiles ? combien ont été créées en cours de projet ? est-ce que les priorités ont beaucoup changé ? Et comme les parents trouvent toujours leur progéniture merveilleuse, vous pouvez essayer d'obtenir la perception des utilisateurs sur la réussite du projet. C'est moins quantitatif, mais finalement beaucoup plus objectif ! Attention, si vous recherchez le retour des utilisateurs, attendez que s'écoule quelques jours ou semaines. Les projets débutant en production avec quelques couacs (problèmes lors du déploiement, forte résistance au changement...) peuvent se transformer en réussite totale une fois les tensions des premiers jours passées.

Obtenez des retours sur votre travail

Profitez en également pour identifier comment vous avez participé à ces réussites et ces échecs. N'hésitez pas à solliciter vos sponsors ou vos responsables pour avoir un retour sur votre travail. Quand le projet a atterri, il est plus facile d'obtenir un retour objectif car les différentes parties prenantes ont tous les éléments pour juger votre travail, et ils auront la distance nécessaire. Pensez également à faire un point sur vos méthodes de travail et les techniques de la MOA. Avez vous trop voulu formaliser ? Ou au contraire avez-vous manqué de formalisme ? Étiez-vous à l'aise avec la méthode employée sur le projet ?

Capitalisez sur votre travail

Vous avez réalisé un manuel utilisateur de qualité ? Vous avez amélioré la description de vos use case ? N'hésitez pas à reprendre vos documents afin d'en faire des templates ou des exemples en corrigeant leurs défauts. Cela vous permettra d'une part d'améliorer la qualité de vos livrables au fil du temps et d'autre part de gagner du temps sur votre prochain projet. Vous pouvez ensuite partager vos templates avec les autres MOA de votre société.

Cherchez les projets suivants

Faites un point avec vos sponsors habituels pour voir quels sont les besoins stratégiques qui ne sont pas encore couverts. Faites le tour des utilisateurs également, afin d'identifier des problèmes opérationnels qui ne seraient pas encore remontés.  Le meilleur moyen de travailler sur un projet intéressant, c'est encore d'aller le chercher.

 

La fin d'un projet n'est jamais simple. C'est souvent une phase fortement chargée pour la MOA qui doit gérer la conduite du changement. Il faut être très présent. Et assez rapidement, tout s'arrête. Il faut alors savoir gérer la transition avant le ou les projets suivants. Soyez fort, on passe tous par là, surtout lorsque le projet est une réussite. Bizarrement, plus le projet est un échec, moins on a de mal à s'en défaire...


dimanche, juin 12 2011

La MOA doit-elle tout automatiser ?

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.

mercredi, juillet 21 2010

Dans quels cas utiliser les cas d'utilisation ?

"Les cas d'utilisation, c'est bien, mais leur description détaillée est un peu lourde. Finalement, nous ce qui nous intéresse c'est la spécification des écrans.", voilà ce qu'un développeur m'a récemment dit concernant des spécifications fonctionnelles que j'avais rédigées. L'approche par cas d'utilisations (use case) pour expliciter les exigences fonctionnelles d'un système est un grand classique de la MOA. Mais alors si les développeurs les jugent indigestes, à qui et à quoi servent-ils ? C'est en lisant ce billet Use cases: a personal history (and a bit of a love affair) de Laura Brandenburg, que je me suis rendu compte que je n'étais pas le seul à me poser ces questions.

Rappels sur les cas d'utilisation

Un diagramme de cas d'utilisation en UML permet de figurer le comportement d'un système face aux stimulations d'acteurs externes, le tout avec un formalisme extrêmement simple.Voilà un exemple décrivant le fonctionnement d'un restaurant :

Diagramme de cas d'utilisation

Un cas d'utilisation est représenté par une "patate". Chaque cas d'utilisation peut ensuite être décrit de manière détaillée avec par exemple le formalisme suivant :

Description détaillée d'un cas d'utilisation

Les cas d'utilisation pour discuter avec le métier

L'avantage d'un diagramme de cas d'utilisation est qu'il est très simple à comprendre. Hormis les associations de type "extends" ou "includes", le formalisme se comprend de lui même. Donc pour appréhender un système existant ou pour expliciter le périmètre d'un projet, ce genre de diagramme me parait indispensable. Et même si on travaille avec des "user stories" dans le cadre d'une méthode agile, réaliser un diagramme de cas d'utilisation permet d'avoir une vision d'ensemble, nécessaire pour les discussions au niveau d'un processus.

Les cas d'utilisation comme outil d'analyse

A moins d'être sur une évolution très simple ou d'être un expert du sujet, il me parait impossible de passer directement du besoin exprimé par l'utilisateur à une maquette détaillée de l'interface prête à être réalisée par l'équipe de développement. Alors comment mener l'analyse qui permettra de rédiger une spécification fonctionnelle détaillée ? Et bien par exemple en utilisant le modèle présenté précédemment pour expliciter les cas d'utilisations car il permet de :

  • Formaliser l'exécution normale du cas d'utilisation ;
  • Découvrir les cas alternatifs, qui sont souvent oubliés par les différentes parties-prenantes ;
  • Découvrir les règles métiers, même celles qui ne se traduiront pas par une règle dans l'interface graphique.

Même si finalement les développeurs auront tendance à se focaliser sur la description des IHM, les cas d'utilisation facilitent la conception de ces IHM et permettent d'avoir rapidement une vision globale du système ou processus étudié. Alors oui, ils peuvent paraitre trop simplistes sous forme de diagramme et trop complexes lorsqu'ils sont explicités de manière détaillée, mais il me semble que c'est un outil indispensable à toute analyse fine du métier.

jeudi, mars 25 2010

Comment découvrir les besoins ?

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.

dimanche, février 7 2010

Comment améliorer l'alignement IT/métier en utilisant un outil de gestion des exigences ?

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!