Si l’on devait concéder une qualité à l’être humain sur l’ordinateur, ce serait certainement sa souplesse d’esprit, face à la logique purement binaire de l’ordinateur. Elle permet, et ce n’est pas rien, de ramener dans le domaine du faisable les processus les plus irréalistement parfaits à la moindre velléité de mise en application.

Je vois évidemment deux éléments de contradiction avec cette assertion, et, bien que je les ai inclus dans mon raisonnement, ils ne l’affectent en rien.

Le premier est la notion de prise de décision, adaptation directe de la logique floue, qui permet d’ajuster la décision d’un système informatique au contexte, et ainsi, d’assouplir éventuellement certains processus afin de ne pas rentrer dans une situation de blocage. Une telle souplesse ne peut s’adapter à des domaines particulièrement critiques, dans lesquels les processus doivent être impérativement suivis à la lettre.

Le second est cette propension mise en évidence par Michel Crozier à remplacer les objectifs par la mise en application pure et simple des processus dans les organismes fortement bureaucratiques, au moins en France. La lourdeur bureaucratique vient alors annuler – voire contrer – toute velléité d’assouplissement des processus définis par ailleurs.

J’ai pu diriger il y a quelques années un projet de refonte des processus et des outils métier associés pour un grand nom de l’industrie. Le projet avait été divisé en quatre parties :

  1. Audit des différents services et départements dans chacune des business units impliqués dans le projet.
  2. Élaboration du nouveau processus à partir de l’audit et en conformité avec les contraintes réglementaires.
  3. Validation des conclusions de l’audit par le client.
  4. Conception puis réalisation de l’outil permettant la mise en application du processus.

Le processus tiré de 3 mois d’audit était clair, parfaitement cadré, et rationnel à souhait. Les informations fournies à chacune des étapes par des intervenants définis étaient validées avant d’être transmises au maillon suivant de la chaîne, et une ultime étape de validation venait couronner ou invalider le processus.

Quand je regarde, avec le recul, la parfaite logique du mode opératoire choisi, je me dis que ce projet ne pouvait se terminer qu’en catastrophe. Une étape importante avait été oubliée entre les points 2 et 4 : l’étude de faisabilité. Cela se traduit par plusieurs symptômes que l’on retrouve un peu partout, et auxquels on peut toujours opposer certaines solutions, quand elles sont envisageables dans le contexte, évidemment.

Je ne reviendrai pas sur le décalage entre le rapport d’audit et ses préconisations, son acceptation à la lettre par le client, la réalité de l’entreprise, et les problèmes liés à la dynamique de changement. Toujours est-il que la – très longue – phase de conception de l’application qui devait permettre la mise en application du nouveau processus métier en a montré les limites et les faiblesses.

Il n’y a notamment pas mieux que la transposition d’un workflow dans la réalité pour en voir tous les points de blocage. Que se passe-t-il quand la personne devant effectuer une tâche critique, non assignable à quelqu’un d’autre et bloquante pour le processus est malade, n’a pas le temps de faire son travail, ou, tout simplement, n’existe pas dans l’organigramme de l’entreprise ?

On se retrouve dans une situation de blocage qui va nécessiter des mesures d’urgence non satisfaisante.

Soit on assouplit des règles de gestion de l’application par délégation de droits à des utilisateurs qui ne devraient pas les avoir. On arrive alors à un système de gestion de droits certes extrêmement souples, mais confinant à l’usine à gaz. Mais surtout, on détourne le processus mis en place en amont, avec tous les problèmes que cela présuppose en termes de sécurité ou de droit.

Soit on court-circuite les étapes du processus afin d’arriver à une unique validation finale. Cette solution est encore plus dangereuse quand chacune des étapes du workflow réutilise les informations transmises par le chaînon précédent. Pour peu que les informations fournies à une étape soient erronées, c’est l’ensemble de la chaîne qui est corrompue, sans qu’il soit forcément possible de le vérifier.

Il ne reste alors pas 36 solutions : soit on conserve un processus bancal jusqu’à la catastrophe qui ne manquera pas d’arriver, loi de Murphy oblige, soit on réécrit complètement les processus de travail afin de les rendre réalistes, c’est à dire applicables. C’est souvent un bon moyen de soulever les faiblesses structurelles de l’entreprise coté métier, et d’y remédier afin de travailler “au carré”. Malheureusement, cela n’arrive presque jamais.

Perry the Platypus wants you to subscribe now! Even if you don't visit my site on a regular basis, you can get the latest posts delivered to you for free via Email: