L’article original joliment illustré, détaille quel peut être (doit être ?) votre connaissance en matière de BPMN en fonction de ce que vous envisagez faire en tant que “Process Modeler”.

Ce qui est intéressant ensuite, et c’est là la toute puissance d’Internet et des blogs, c’est que cette note a engendré ces derniers jours un débat passionné avec les interventions des experts en la matière, entre autre Bruce Silver, avec une réponse de Michael, Sandy en parle sur son blog également. Si vous avez un avis, ne vous privez donc pas d’intervenir à votre tour !!

BPM Research » How much BPMN do you need?

C’est donc par ici …

ProcessWorld Day 1: Press/Analyst Briefing

et encore par là …

ProcessWorld Day 1: Keynote with Prof. Scheer

et d’autres notes encore à suivre …

Business Process Trends :: Reports ::

Tribune Michaël Ferrari - BPMS.info - Bilan 2006 des standards de modélisation des processus
Le secteur du BPM arrive peu à peu à maturité, générant de nombreuses consolidations. Tour d’horizon de l’état de l’art en matière de standardisation…

Ce qui était intéressant surtout était de voir comment les gens qui gravitent autour du monde de la modélisation de processus (là où BPM signifie ‘Business Process Modeling’ et non ‘Management’) abordent l’organisation de l’Entreprise et la cartographie des processus. Là où les éditeurs de BPMgt (et moi le premier :)) orientent leur discours sur l’exécution en offrant un moteur de BPM auquel on va greffer des outils périphériques, les gens qui viennent du monde de la modélisation orientent tout leur discours sur … la modélisation servie accessoirement (et le mot ‘accessoirement’ prend toute son importance) par un moteur d’exécution.

En gros, cela donne à peu près les schémas suivants :

La Gestion des Processus vue par les gens du Business Process Management :

La Gestion des Processus vue par les gens du Business Process Modeling :

Quelle conclusion en tirer ?

Premièrement que pour moi il n’y a pas de mauvaise approche ou de bonne approche. L’important est de prendre le problème par un bout et de le traiter. Il me semble aussi important de se préoccuper de la modélisation des processus - c’est un travail de longue haleine - que de leur exécution car les caractéristiques de cette exécution peuvent mener à des choix d’architecture et de progiciels différents.

Deuxièmement, il est important de traiter les deux sujets. En effet, se contenter de modéliser sans mettre en oeuvre c’est faire de l’Organisation d’Entreprise. C’est bien mais ce n’est pas suffisant. Mettre en exécution les processus, c’est rendre ce travail de modélisation ‘rentable’, c’est rentrer dans le coeur du problème et obtenir les résultats escomptés. Là on commence à parler ROI - Return On Investments, Retours sur Investissements - et c’est ce qui va parler aux Directions Générales sans l’appui desquelles aucun projet de BPMgt ne peut vraiment se mettre en place. De même, exécuter sans avoir modéliser au préalable, c’est aller très vite au-devant de véritables problèmes, en particulier des manques d’adoption par les utilisateurs propres à faire capoter tout projet BPMgt.
Enfin, il y a une vraie complémentarité entre modélisation et exécution, on le voit bien avec les offres logicielles qui arrivent consistant à favoriser les passerelles entre les différents outils. Cette complémentarité n’est pas qu’à simple effet, un processus mis en production doit être régulièrement revu et corrigé, optimisé, modifié pour tenir compte des impératifs commerciaux de l’Entreprise et le passage par la modélisation est alors nécessaire. On est dans un macro-process de Round-Trip Reengineering, et il convient donc de s’assurer que les choix faits en matière d’outils permettent ces allers-retours sans difficulté.

En conclusion, il est toujours intéressant de voir le domaine dans son intégralité et si vous avez un projet de BPM à mener, je vous engage vivement à prendre contact avec plusieurs acteurs “périphériques”, quelle que soit votre approche.