Lire également la première partie

Distinguer processus métier et processus outil
Voici donc apparaître le processus sur le banc de accusés. Mais de quel processus parle-t-on ? Du processus métier qu’il faut instrumenter ou des processus outils qui seront effectivement mis en œuvre ?

Ceux qui travaillent à la modélisation des processus sont familiers avec cette disctinction entre "fonction métier" et "fonction informatique", les premières pouvant, dans le cadre de la définition de cahier des charges par exemple, servir de base à la description des secondes. La mise en œuvre d’un ERP revient à transposer un certain nombre de processus métier en processus capables d’être exécutés par le progiciel.

De ce point de vue, le concept même de best practice est trompeur : quel que soit le progiciel, il n’y a pas pour un processus donné, la gestion des demandes d’achat par exemple, un processus type à mettre en œuvre mais une multitude de possibilités. C’est cette flexibilité de paramétrage qui a fait le succès des ERP mais c’est aussi la raison pour laquelle l’ERP, hormis pour sa structure de données, n’est pas si structurant que cela. Les outils les plus performants font même preuve d’une telle flexibilité qu'ils parviennent avec aisance à reproduire les dysfonctionnements organisationnels du passé. Voilà à quoi conduit l’absence de réflexion préalable en la matière. On voit bien que ce n’est pas tant l’outil que l’usage qui en est fait qui pose problème.

C’est là qu’interviennent les outils d’analyse des processus métier : en rassemblant les données processus au sein d’un ensemble structuré (le référentiel), ils permettent, via des analyses d’impact simples à mettre en œuvre, de mettre en évidence les dysfonctionnements ou les potentiels d’amélioration. Sur cette base, il est plus aisé de définir un processus organisationnel cible qui constitue la véritable expression des besoins en amont du paramétrage de l’outil. Charge alors à l’équipe projet de trouver la combinaison de paramètres permettant d’approcher ce résultat.

Ne pas confondre le processus et son modèle
Cette mise au point étant faite, revenons à la réalité du processus métier. Le processus n’est pas cette conception figée d’un ensemble de tâches entièrement prédéfinies qui nierait à l’individu la capacité à prendre des décisions… ni celle des processus exécutés au quotidien à sortir des sentiers battus de la modélisation auxquels on aimerait les cantonner. En résumé, le processus ne peut se résumer aux contours d’un modèle statique, forcément réducteur. Au contraire, c’est une matière "vivante", très imprégnée des interactions humaines.

C’est d’ailleurs parce qu’il est dynamique, qu’il n’est pas simple ni de l’automatiser ni d’en mesurer la performance. C’est même l’enjeu des éditeurs de work flow ou d’intégration, pardon d’ "orchestration", de résoudre la quadrature du cercle entre les cas à anticiper pour une gestion efficace et la flexibilité qu’il convient de laisser au modèle pour éviter les cas bloquants.

En matière de mesure, c’est le rôle des outils de suivi continu de la performance (Business Activity Monitoring) que de refléter les variations, souvent significatives, de la performance tout au long de la semaine (le mercredi et le vendredi après-midi correspondant souvent à des pertes de performance, conséquence directe d’effectifs réduits).

A "l’entreprise ne peut se résumer à un ensemble de processus", je répondrai plutôt que l’entreprise est constituée, pour l’essentiel, de processus, comme le corps humain de cellules, et qu’à l’instar des différences entre une cellule cérébrale et une cellule de foie, on retrouve une grande diversité au sein des processus.

L’individu, au cœur du processus
A l’exception de quelques processus entièrement automatisés, tels ceux d’une chaîne de traitement bancaire, qui limitent l’intervention humaine à la gestion des exceptions de second niveau (qui ne peuvent faire l’objet d’une gestion automatique), la place des acteurs au sein du processus est tout simplement centrale.

C’est même un leitmotiv de BPMS.info que de souligner que la gestion des processus est avant tout une problématique organisationnelle. Qui peut croire que les tâches assurées dans les services soient si formattées et répétitives que l’on s’achemine vers du taylorisme administratif ?

La modélisation du processus n’a pas pour objectif de mettre en œuvre un mauvais remake des "Temps modernes" mais bien de mieux maîtriser qui fait quoi… et d’y mettre un peu d’ordre. A condition qu’il fasse preuve d’un minimum d’adaptabilité, condition impérative de survie dans l’entreprise du XXIe siècle, l’individu peut – et même doit, si l’on veut que le projet réusisse - y retrouver son compte.

En évitant de se disperser sur des tâches qui ne sont pas de son ressort, en formalisant l’éventail de ses compétences, en mettant en évidence les domaines où un complément de formation le rendra plus efficace, il tirera un bénéfice direct et personnel de la formalisation des processus auxquels il participe. Sans parler du principal enjeu : une meilleure organisation de son travail au quotidien.

Les analyses de performance opérationnelle mettent souvent en évidence une grande perte d’énergie due à une trop grande framentation du travail (nombre d’interruptions de tâches) et à une trop grande dispersion (nombre de tâches). Elle mettent aussi en relief que les goulots d’étranglement sont souvent concentrés sur les éléments les plus performants, comme si, par un mouvement d’équilibre naturel, l’organisation cherchait à niveller le niveau de performance de ses acteurs.

A défaut d’obtenir une augmentation de salaire pour les tâches supplémentaires qu’il assume (ne rêvons pas), la modélisation des processus peut contribuer à décharger l’individu de tâches parasitaires qui doivent être assumées par d’autres et à lui donner une meilleure maîtrise de son travail.

Vu sous cet angle, la "dictature du tout processus" apparaît comme plus qu’une nécessité imposée par le contexte : une opportunité à saisir.