L’approche Processus, un potentiel négligé

La culture “processus” a largement diffusé sur le marché, tous secteurs d’activité confondus. Hélas, l’idée originelle semble oubliée : la promesse faite aux dirigeants résidait dans le remède qu’apportent les processus au cloisonnement organisationnel.

Or, après des décennies de pratiques, que constate-t-on ?

Beaucoup d’efforts ont été consentis – et le sont encore – à décrire des processus. Cependant, à 90%, ces efforts portent sur des processus intra-fonctionnels, voire des activités très réduites. Les “vrais” processus, au sens donné initialement, ont une portée inter-fonctionnelle. Pour que les choses soient claires, on est obligé, aujourd’hui, d’ajouter l’adjectif “transverse”.

En guise de test, demandez-vous :

Combien y a-t-il de processus dans l’entreprise ?

Si la réponse est plusieurs dizaines, voire de l’ordre de la centaine, alors on n’est certainement pas en train de parler des “vrais” processus, à la hauteur des attentes de la direction. Les processus inter-fonctionnels s’identifient à partir des grandes finalités de l’entreprise ; on en trouve une demi-douzaine, environ.

La figure ci-dessous symbolise la notion de processus, dans son acception initiale.

Par Cth027 — Travail personnel, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=55543545

Certes, il n’est pas inutile de s’intéresser aux activités à l’intérieur d’un domaine fonctionnel (les processus RH, la comptabilité, etc.), mais il convient de rappeler que l’originalité de l’approche par les processus et sa valeur pour la transformation des entreprises résident dans sa capacité à dépasser les cloisonnements organisationnels et à mettre en place la coopération entre acteurs qui ne se rencontrent pas spontanément.

Pour avoir une chance de voir se réaliser la promesse derrière l’approche processus, il est donc impératif de voir les choses dans leur totalité, c’est-à-dire d’adopter une vision d’architecture métier. Or, cette vision manque souvent. Quand une carte des processus existe préalablement au lancement des projets, elle manque souvent de rigueur, elle fait fi des articulations entre processus, elle ne résulte pas d’un questionnement sur la meilleure façon d’organiser les activités. Au lieu de repenser de fond en comble l’organisation des activités, la coopération, la circulation des informations, elle se contente de reproduire l’organigramme et les pratiques en place.

Un autre défaut qui obère les retombées de l’approche par les processus est le manque de rigueur dans la représentation. L’exigence de maîtrise ne peut pas se contenter de descriptions textuelles ou de représentations graphiques intuitives. Elle appelle l’exigence de la modélisation. Sur ce point, la notation standard BPMN apporte un outil redoutablement puissant, qui encourage la conception de processus réalistes et robustes. Encore faut-il la maîtriser et ne pas se contenter d’un usage superficiel.

Business Process Model & Notation

Voir notre offre sur la modélisation des processus.

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 : https://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.