BPMN 2.0 : pour les simples aussi
(Jean Bureau)
Un bon formalisme pour modéliser un métier permet de dire beaucoup avec peu. Avec BPMN, a priori, pour dire beaucoup il faut mobiliser un grand nombre d'éléments. Mais beaucoup trop de ces éléments ne servent qu'à pré-mâcher la conversion du schéma en exécutable.
Si le but de votre modélisation est de mettre au clair le métier en s'interdisant toute hypothèse d'implémentation, on s'aperçoit que nombre d'éléments BPMN peuvent rester dans le stencil. Exemple avec les événements. Le fait de préciser qu'un événement est "au début", "au milieu" ou "à la fin" ne sert à rien : c'est évident ! Et jamais un expert métier ne vous en voudra de ne pas lui révéler ces merveilleuses propriétés des événements...
Autre exemple avec les gateways. On peut s'en passer sans (presque pas) perdre en richesse de modélisation. Il suffit de brancher directement sur les activités les flux que l'on place ordinairement en sortie des gateways.
Au reste, cette modélisation simplifiée correspond à l'entendement naturel de l'homme de l'art. En effet, une fois qu'il a travaillé (ça s'est passé dans l'activité) il ne se demande pas ce qu'il vient de produire, il le sait parfaitement et, s'il y a lieu, il sait vous dire quelle activité va prendre la suite. Comme on le voit, le pullulement d'objets dans BPMN, version 1.2, 2 - ou supérieure !- n'empêche pas de s'en servir volontairement comme d'un formalisme à jeu réduit d'éléments. Et ce parti pris ouvre sur une modélisation de grand intérêt pour les maîtrises d'ouvrage. (11/09/2009)
BPMN 2.0 : pour les simples aussi
(Jean Bureau)Un bon formalisme pour modéliser un métier permet de dire beaucoup avec peu. Avec BPMN, a priori, pour dire beaucoup il faut mobiliser un grand nombre d'éléments. Mais beaucoup trop de ces éléments ne servent qu'à pré-mâcher la conversion du schéma en exécutable.
Si le but de votre modélisation est de mettre au clair le métier en s'interdisant toute hypothèse d'implémentation, on s'aperçoit que nombre d'éléments BPMN peuvent rester dans le stencil. Exemple avec les événements. Le fait de préciser qu'un événement est "au début", "au milieu" ou "à la fin" ne sert à rien : c'est évident ! Et jamais un expert métier ne vous en voudra de ne pas lui révéler ces merveilleuses propriétés des événements...
Autre exemple avec les gateways. On peut s'en passer sans (presque pas) perdre en richesse de modélisation. Il suffit de brancher directement sur les activités les flux que l'on place ordinairement en sortie des gateways.
Au reste, cette modélisation simplifiée correspond à l'entendement naturel de l'homme de l'art. En effet, une fois qu'il a travaillé (ça s'est passé dans l'activité) il ne se demande pas ce qu'il vient de produire, il le sait parfaitement et, s'il y a lieu, il sait vous dire quelle activité va prendre la suite. Comme on le voit, le pullulement d'objets dans BPMN, version 1.2, 2 - ou supérieure !- n'empêche pas de s'en servir volontairement comme d'un formalisme à jeu réduit d'éléments. Et ce parti pris ouvre sur une modélisation de grand intérêt pour les maîtrises d'ouvrage. (11/09/2009)