La cart(ographie) n'est pas le territoire !   

Il y a depuis toujours deux modes très différents d'approcher les organisations.

Une façon de voir mécaniste, qui voit l'organisation, l'entreprise comme une horloge, avec des pièces qui s'articulent mécaniquement les unes avec les autres, le mouvement de l'une déclenchant  l'action de la suivante, et une approche organique, qui voit l'organisation comme un système dynamique, auto-adaptatif, changeant, aux contours mobiles et fluctuants…

La description cartographique appartient souvent au premier mode. Surtout si on descend, à tort, trop bas, au-delà de la carte générale d'un processus, qui devrait toujours considérer les activités (ces blocs, à l'intersection du processus et des fonctions) comme des "boites noires", libres de leurs façons de faire.  La description ultérieure des activités en tâches, formalisées souvent en procédures, durcit clairement le jeu mécaniste!

Pas d'illusion, lorsque l'on cartographie un processus, pour refléter son fonctionnement, le "modélisateur" n'est jamais neutre. Quelque soit sa méthode, enquêtes sur les façons de faire, étude des workflows, il y aura toujours beaucoup de distance entre le réel et le décrit. On obtient souvent dans les enquêtes de faux consensus, les acteurs disent plus ce qu'ils pensent ce qu'ils devraient faire que ce qu'ils font en réalité, …

La carte, indispensable pour s'orienter, n'est en aucun cas le territoire réel (Korbyski, créateur de la sémantique générale, vers 1930).  Alors, quelle conduite adopter en tant que modélisateur?

Une carte doit rester en général assez macroscopique, décrivant les enchainements d'activités,  que l'on doit nommer en fonction de leur mission , ce qui permet  d'étudier leur contribution de valeur à la finalité du processus étudié, d'ouvrir le champ à l'étude de leur qualité, de leur coûts, de leur délai, de leurs risques, de leur agilité, etc.  Bien évidement cela permettra également de se focaliser  sur les liaisons inter-activités (transversalité), les goulets d'étranglements,…

Il y a certes beaucoup de situations où il faut en priorité fiabiliser, "durcir" les façons de faire, que ce soit pour maîtriser les risques ou parce que l'aspect mécaniste de certaines parties du métier amène naturellement à terme à de l'informatisation, là où la modélisation BPMN plus poussée, amenant éventuellement à de la description UML, proche de la programmabilité est assurément utile.

Il y a par ailleurs des limites aux descriptions en activités enchainées  de type BPMN. Il ya d'autres scénarios où, sur la base des informations existantes, des documents et de leur savoir les acteurs coopèrent, en parallèle et non plus en séquence, pour trouver une solution, concevoir un produit ou un service, … C'et le champ de l'ingénierie concourante en mode projet,  du "case management" (CMMN) en mode processus.

Réconcilier le mécaniste et l'organique,  savoir ou anticiper ce qui est suffisamment stable dans le temps et ce qui mérite d'être durci, et ce qui devrait rester organique, pour  s'adapter en permanence à la complexité montante, aux changements, déterminer où mettre la curseur entre le "dur" et le "souple" est ainsi au cœur de la responsabilité des modélisateurs.