Pour une conception de processus réalistes et robustes

Depuis 2011 (2013 pour la version 2.0.2), nous disposons d’un standard international pour représenter les processus : BPMN (Business Process Model & Notation). C’est une bonne nouvelle… sous quelques conditions.

Une bonne nouvelle

Contrairement à UML – plutôt moins utilisé aujourd’hui que lors de sa parution en 1997 -, BPMN semble jouir d’une bonne réception sur le marché. C’est toujours une bonne nouvelle quand un standard vient unifier un formalisme et soutenir les pratiques de modélisation. Particulièrement à un moment où les entreprises se préoccupent de leur transformation. Si les principes de l’approche par les processus sont partagés par tous, du haut en bas de la pyramide hiérarchique, cette approche ne peut porter ses fruits que si elle s’appuie sur des représentations précises. BPMN doit nous y aider.

Des obstacles à surmonter

Encore faut-il que le formalisme standard soit utilisé correctement. Or, sa bonne utilisation se heurte à plusieurs obstacles :

  1. Tout d’abord, l’approche par les processus se contente, assez souvent, de représentations schématiques qui se limitent à décrire superficiellement les activités.
  2. Ensuite, cette attitude est parfois revendiquée, selon l’argument qu’une description complète d’un processus ne serait pas comprise par les acteurs du métier. En conséquence, une diapositive est préférable à un modèle ; une notation intuitive, à un formalisme rigoureux.
  3. Enfin, à l’intérieur même des pratiques de BPMN, s’est répandue l’idée que l’on n’a pas besoin de toute la notation.

Le premier obstacle n’est pas nouveau. Pour le détruire, il suffit de rappeler le niveau de complexité qu’atteignent, aujourd’hui, les chaînes de valeur, et les perspectives de transformations des organisations (notamment, du fait de la technologie). Les améliorations et les changements à venir exigent une maîtrise parfaite de nos processus, pas seulement de leur fonctionnement nominal, mais aussi des circonstances exceptionnelles. Les entreprises doivent donc, au minimum, décrire précisément leurs processus.

Deuxième point, la revendication de simplicité sombre vite dans un simplisme délétère. Elle confond deux moments, que la démarche doit distinguer : le temps de la communication ou de l’exposition ; le temps de la conception (je parle ici de la conception des processus et de l’organisation ; l’élaboration d’un processus exécutable informatiquement est un autre sujet). S’il est légitime de se soucier de la bonne communication vers les acteurs du processus ou les décideurs, il n’en reste pas moins essentiel de disposer d’une bonne description du processus. On ne peut pas sacrifier la qualité de la conception, au souci de la communication. Cette attitude – presque une culture – rend de très mauvais services à l’entreprise. Elle se pare de l’argument de pragmatisme… pour ne pas s’avouer paresse. De plus, un bon usage de la notation permet de concilier les deux aspirations : un modèle de processus peut contenir tous les détails nécessaires, tout en réservant des diagrammes synthétiques qui faciliteront sa communication, l’apprentissage, la prise de décision… BPMN autorise un effet de zoom, fort utile pour concilier ces deux exigences.

Le troisième obstacle résulte d’une réaction bien compréhensible face à la richesse de la notation BPMN : 7 types de branchements, 64 catégories d’événements (sur une matrice de 104), de nombreuses notions dont certaines ne correspondent même pas à des symboles graphiques, etc. Face à cette apparente complexité (le terme « richesse » est préférable), il est tentant de s’épargner l’effort d’apprentissage et d’exclure, a priori, une partie de la notation. Cette tendance est malencontreusement encouragée par la distinction que fait Bruce Silver dans son best-seller, BPMN, Method & Style, entre des palettes de niveaux 1 et 2. Tout à fait justifiée comme progression pédagogique, cette distinction ne vaut rien dans la pratique. Elle se révèle toxique (en ce qu’elle encourage, entre autres, la réduction de l’effort de formation à la palette de niveau 1). Retirer ne serait-ce qu’un type d’événement sur les 64, c’est prendre le risque de se retrouver devant une réalité, sans la bonne solution pour la représenter.

Une illustration

BPMN n’offre pas seulement une réponse unifiée face aux formalismes antérieurs (et aux notations propriétaires). Cette notation comporte aussi des innovations qui vont changer les pratiques de modélisation et la qualité de conception des processus. Ces nouveautés permettent de traiter des situations que les formalismes antérieurs se montraient impuissants à prendre en compte.

Pour illustrer le propos, prenons un exemple utilisé en introduction à mon cours : il s’agit d’une recette de cuisine. Quoi de plus simple, me direz-vous ! Une succession d’actions… Représentons graphiquement ce petit extrait :

Portez à ébullition et laissez bouillir, en ayant soin d’écumer souvent, jusqu’à ce qu’il ne se forme plus d’écume.

(emprunté au site Marmiton) – Voici la représentation à laquelle on arrive spontanément, en général :

L’activité principale, suivie d’un test, puis déclenchement éventuel de « écumer » et retour sur la première activité.

Or, cette représentation ne convient pas du tout. Elle s’interprète comme suit : il faut arrêter la première activité pour évaluer la condition (donc, couper le gaz, puis regarder s’il y a de l’écume) ; le cas échéant, on écume, puis on exécute une nouvelle instance de la première activité (donc, on rallume le gaz). Je ne m’y connais pas beaucoup en cuisine, mais cela me paraît quelque peu aberrant !

BPMN offre un moyen fort simple pour représenter correctement cette situation : l’événement-frontière non interrupteur (de type « condition », dans notre cas). La notion d’événement-frontière compte parmi les apports de BPMN qui sont méconnus ou sous-exploités – sacrifiées sur l’autel idolâtre du simplisme. C’est fort dommage, car elle fournit le moyen élégant de traiter toutes sortes de situations concrètes, dont les perturbations qui peuvent affecter le déroulement d’un processus.

Quelques points particuliers

D’autres notions passent à la trappe, alors qu’elles simplifient le travail du modélisateur, ou même qu’elles rendent possibles la représentation de phénomènes réels. Citons :

  • les sous-processus événementiels (pas vraiment une innovation puisqu’ils existaient dans le modèle de traitement de Merise, mais un peu oubliés) ;
  • le branchement basé sur événement (typique du style de modélisation de BPMN) ;
  • la compensation (mécanisme le plus sophistiqué dans BPMN, que l’on retrouve tel quel dans BPEL) ;
  • la chorégraphie (enfin ! un moyen simple de représenter les activités collectives) ;
  • la notion de « définition d’événement » (EventDefinition, dans le méta-modèle) qui n’a pas de correspondant graphique (seul l’événement se visualise), mais qui permet d’assurer la cohérence dans une conception de processus, ou d’un ensemble de processus.

Toutefois, si l’objectif est de représenter tout le métier, BPMN révèle vite ses limites. Ce constat soulève un autre point, celui de l’articulation entre BPMN et d’autres notations, pour obtenir un outillage complet de modélisation.

Conclusion : un nécessaire effort d’apprentissage

La modélisation des processus a quelque chose de vicieux : elle se prête à toutes les manipulations. Trois symboles sur une diapositive et deux flèches : voilà que le processus existe ! A contrario, un diagramme peut s’étendre sur plusieurs pages, et on s’imagine que la conception est complète… mais on ne peut plus en discuter parce que c’est trop complexe !

Comme nous en avons l’habitude, maintenant, avec les standards de l’OMG, BPMN est un outil puissant, appuyé sur un méta-modèle qui condense le savoir-faire de méthodologues au niveau mondial, mais… ce n’est pas une méthode. Donc, il laisse le praticien démuni, sujet aux sirènes du simplisme, et sous l’influence des marchands d’orviétan. Pour répondre à ses besoins, la meilleure démarche pédagogique consiste à partir du besoin de représentation : que faut-il représenter ? à quel moment ? sous quelle forme ?

Ainsi, le coeur de la formation « BPMN, modéliser les processus » repose sur une logique d’action. Chaque séquence soulève des besoins de représentation, à partir d’une étude de cas qui embrasse de plus en plus large, jusqu’à la dimension « organisation » :

  1. « Esquisser le processus », où l’on démontre que le formalisme aide à révéler les manques de l’expression textuelle ;
  2. « Ordonnancer les activités », où l’on découvre les principaux types de branchements (gateways) offerts par BPMN ;
  3. « Structurer le processus », qui règle la question de la présentation du modèle ;
  4. « Introduire la temporalité dans les processus », dimension évidente et pourtant négligée ;
  5. « Prendre en compte les perturbations », au-delà du fonctionnement nominal, afin de concevoir des processus robustes et d’anticiper les crises ;
  6. « Distribuer les activités et décrire la coopération » ;
  7. « Architecturer l’activité métier », et passer à la portée « entreprise » (ce qui soulève quelques questions de méthode et d’outillage) ;
  8. « Modéliser l’activité métier », récapitulatif des actions du modélisateur.

Pour plus d’information sur cette formation : http://www.praxademia.com/formation/modelisation-des-processus/

Prochaine session, du 7 au 9 février 2018 : inscription

Les six impasses de la conception de processus

L’importance d’une approche par les processus ne se discute plus. Pourtant, si on évalue les retombées des projets de modélisation des processus, on peut parfois se demander si les promesses en matière de productivité, de simplification ou d’innovation, ont été tenues.

Ce bref article examine les six impasses qui réduisent la portée de l’approche par les processus. Un deuxième partie introduit le procédé de conception des processus, proposé par Praxeme.