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

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

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

dimanche, janvier 3 2010

Comment être sur d'être bien formé ?

Par Olivier Durand le dimanche, janvier 3 2010, 14:31 - Divers

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 !

vendredi, février 27 2009

Comment spécifier une interface graphique de manière détaillée ?

Par Olivier Durand le vendredi, février 27 2009, 10:12 - Spécifier

L'étude fonctionnelle de cette application de gestion a été faite. Vous avez un beau cahier des charges. La spécification générale a été réalisée, vous connaissez vos cas d'utilisation sur le bout des doigts. Il est donc temps de passer à la spécification fonctionnelle détaillée, et l'un des éléments clé, quelque soit la méthodologie mise en œuvre, c'est la spécification des écrans.

1) Le papier et le crayon :

Pour mettre un peu ses idées au clair, rien de tel qu'une feuille, un crayon à papier et une gomme. Commencer par dessiner au brouillon ses IHM permet de poser ses idées.

2) L'outil pour designer ses écrans :

Une fois qu'on voit grosso modo ce que l'on souhaite faire, on peut utiliser un outil pour dessiner ses écrans en mode "fil de fer" voire pour effectuer un story board (un genre de prototype pour illustrer la navigation).

Une suite bureautique standard permet de réaliser des dessins sommaires (OpenOffice.org - http://fr.openoffice.org/) de même qu'un outil dédié à la réalisation de schémas (Visio - http://office.microsoft.com/fr-fr/visio/default.aspx). Seulement ces outils très généralistes ne sont pas les plus performants pour cette tâche spécifique.

Il est beaucoup plus efficace d'utiliser un outil dédié à la réalisation de maquettes et de prototypes d'écrans comme par exemple :
Axure RP - http://www.axure.com/.

Cet outil est plutôt fait pour les applications Web à la base, mais fait très bien son office pour les applications "lourdes" également. Il vous permettra :
- De designer vos écrans à l'aide contrôles simples et d'autres personnalisés que vous pouvez créer et réutiliser.
- De spécifier le fonctionnement de vos écrans à l'aide d'annotations personnalisables.
Par exemple, vous pouvez créer des annotations pour créer un tableau ICAR (Intention - Contrôle - Action - Réponse). Exemple :
Intention = Supprimer un billet du blog
Contrôle = Menu contextuel, Item supprimer
Action = Clic
Réponse = Ouverture d'une fenêtre de confirmation "Etes vous sur de vouloir supprimer ce billet", puis suppression du billet si bouton OK cliqué.
- De définir la navigation entre vos écrans.
- De créer un prototype navigable en HTML pour présenter la navigation entre les écrans à vos utilisateurs par exemple.
- De générer un dossier de spécification fonctionnelle détaillée des écrans au format Word par exemple, à partir d'un template personnalisable.

Axure permet donc d'industrialiser la gestion des spécifications fonctionnelles détaillées des écrans. Il permet également de réaliser des prototypes à moindre coût. Les écrans sont une excellente base pour valider des concepts au départ un peu abstrait avec des utilisateurs. Organiser une réunion de validation des écrans permet de corriger certaines erreurs en tout début de projet, ce qui coute beaucoup moins cher que lorsque tous les développements on été effectués. Bien sur les écrans ne sont que la partie visible de l'iceberg, mais je pense que pour des projets d'applications de gestion classiques, une bonne spécification de l'IHM est un élément clé de la réussite. Un outil comme Axure est une bonne assurance contre les échecs dus à des spécifications trop imprécises.

mardi, décembre 16 2008

Bienvenue sur mon blog.

Par Olivier Durand le mardi, décembre 16 2008, 14:14 - Divers

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.

page 4 de 4 -