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

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

Tag - Processus métier

Fil des billets - Fil des commentaires

lundi, juin 11 2012

Comment la MOA peut-elle obtenir l'adhésion des utilisateurs sans vendre son âme au diable ?

Par Olivier Durand le lundi, juin 11 2012, 23:16 - Supporter

L'accompagnement du changement (plutôt que la conduite) n'est pas l'épilogue d'un projet. C'est une démarche qui s'exécute sur toute la durée d'un projet. Comment la MOA peut-elle obtenir l'adhésion des utilisateurs sans vendre son âme au diable ?

Définir sa stratégie, ses objectifs

En fonction de la dimension du changement (à l'échelle d'une application, d'un process, d'une organisation, de l'entreprise) et en fonction de la criticité de l'adhésion des utilisateurs finaux pour la réussite du projet, les exigences de l'accompagnement du changement ne seront pas les mêmes. Il est donc important de bien identifier la nature du changement pour identifier la bonne stratégie à adopter. Le déploiement worldwide d'une nouvelle application métier dans le but d'améliorer la qualité d'un processus ou la modification d'un processus métier pour optimiser les coûts avec des réductions d'effectifs ne seront pas gérés de la même manière.

Impliquer les utilisateurs en amont

L'accompagnement du changement ne se fait pas à la fin du projet, comme une cerise sur le gâteau. C'est un facteur clé de la réussite qui se négocie dès le début du projet. Plus les utilisateurs sont inclus tôt dans le projet, moins vous risquez le syndrome du "NIH". Pour cela, certains utilisateurs clés, appelés parfois les "champions", doivent être embarqués afin de convaincre les autres utilisateurs de l'intérêt du changement. Ces "champions" aiment le risque et prendre des responsabilités supplémentaires ou ont un intérêt personnel à ce que le projet réussisse. Il ne faut pas passer à côté de cette opportunité, un "champion" charismatique permettra de convaincre bien plus de monde que la meilleure des présentations par une équipe projet. 

Utiliser les technologies du 21ème siècle

Pour la phase de formation, pensez à utiliser les outils les plus efficaces : visioconférences, webinar... En ces temps difficiles, oubliez La Première et les grands hôtels. 

Enfin, conservez une fois de plus votre bon sens et vos qualités humaines. Je citerai cet utilisateur qui m'a dit aujourd'hui : "Vous facilitez la communication entre les systèmes, c'est très bien, mais n'oubliez pas de faciliter la vie des humains !". Heureusement, même si je ne suis pas parfait, je suis humain et comprend ses problématiques... tant qu'on ne me remplace pas par un avatar robotique humanoïde...

dimanche, juin 12 2011

La MOA doit-elle tout automatiser ?

Par Olivier Durand le dimanche, juin 12 2011, 18:46 - Divers

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.

vendredi, septembre 17 2010

La MOA doit-elle définir ses écrans en mode fil de fer ?

Par Olivier Durand le vendredi, septembre 17 2010, 14:04 - Spécifier

Le processus qui amène à la spécification détaillée des écrans d'une application de gestion, n'est pas principalement un travail sur le graphisme. C'est essentiellement un travail de conception fonctionnelle centrée sur l'utilisateur. Et avant de définir le design final de l'application, il peut être intéressant de concevoir ses écrans en mode fil de fer (wireframe). Voilà un petit schéma revu sur le blog de usercentric.fr - Suivez le chemin de l’User Experience :

Valider la sémantique

En mode fil de fer, les écrans seront représentés avec tous les contrôles nécessaires, avec la vraie sémantique. Mais par contre on évitera de mettre trop d'éléments graphiques. Ainsi cela permet de se concentrer sur le fonctionnel. Le premier avantage est de faire valider par les utilisateurs la sémantique utilisée, avec son contexte.

Vérifier la compréhension des exigences

Les besoins exprimés par les utilisateurs pendant les entretiens de recueil des besoins ne sont pas toujours bien analysés et compris par la MOA. Discuter d'une exigence sur un écran dépouillé du superflu permet de vérifier qu'on a bien compris le fond du problème.

Le storyboard pour valider le processus métier

Un tout petit peu plus loin qu'un simple écran en mode fil de fer, le storyboard permet de valider que la solution prévue permettra bien de supporter le processus métier concerné. En effet, montrer les enchainements qui seront possibles entre les écrans de l'application permet de concrétiser l'informatisation d'un processus métier. Ainsi on peut dérouler le processus avec les utilisateurs et valider que cela fonctionne comme imaginé.

Améliorer l'utilisabilité

Une fois qu'on a validé l'efficacité de la réponse au besoin, on peut commencer à penser à l'utilisabilité. Les ergonomes et les graphistes auront bien évidemment un grand rôle à jouer dans ce travail, car là on rentre dans leur domaine. Mais la MOA doit avoir des notions sur cette utilisabilité pour éviter de proposer des solutions trop nuisibles. Voilà quelques pistes de lecture sur le sujet de de l'utilisabilité :

Définir ses écrans en mode fil de fer, avant de passer à la spécification détaillée des écrans, offre donc de grands bénéfices. On peut en revanche se demander si c'est à la MOA de définir de manière très détaillée les écrans. Si dans l'organisation il n'y a ni ergonome, ni designer, ni développeur sensibilisés à l'utilisabilité, alors il faut bien que quelqu'un le fasse. Mais si il existe ces spécialistes dans votre organisation, restez concentrés sur votre expertise : le métier et le fonctionnel. Laissez alors le graphisme et l'ergonomie aux vrais experts.

jeudi, mars 25 2010

Comment découvrir les besoins ?

Par Olivier Durand le jeudi, mars 25 2010, 17:20 - Etudier

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.

mardi, janvier 5 2010

Comment modéliser un processus métier ?

Par Olivier Durand le mardi, janvier 5 2010, 22:37 - Etudier

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".

un commentaire