Passer du processus au logiciel est le meilleur moyen de valider leur réalisme

Buffer

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.

Buffer
Publié le 18 novembre 2008 à 23h07 Publié sous et Labels projet, processus, workflow, conception

À propos

Frédéric de Villamil

Je m'appelle Frédéric de Villamil, et quand je ne déploie pas ma mauvaise humeur et ma mauvaise foi sur le Web, je suis un super héros chargé de sauver le monde. Vous pouvez me suivre sur Twitter.

  1. jocelyn le 19 novembre 2008 à 16h31

    C’est clair que l’urbanisation d’un SI permet de mettre en évidences les lacunes dans les processus métier d’une entreprise. L’étape d’après c’est la convergence de l’outil et du processus et c’est souvent là que ça coince : citation de client : “C’est à l’outil de s’adapter à moi et pas le contraire”. Certe, mais de passer à un dans un environnement (normalement) cartésien met souvent en évidence de sérieux problème alors même que tout sembler fonctionner parfaitement sur le papier. La concrétisation d’un processus métier en informatique est structurant, l’outil fait avancer la façon d’apréhender l’objectif métier.

    Il serait intéressant d’étudier l’impact des nouvelles technologies futures sur l’organisation des sociétés : Le travail que nous faisons maintenant sera-t’il à refait dans 20 ans?

  2. Bertrand Duperrin le 20 novembre 2008 à 17h01

    Si c’est un des cas dont nous avons déjà parlé de visu, j’ai fait un audit Rh chez eux quelques temps après la refonte du processus, dans une “vie antérieure”. (Et si c’est un autre projet, les causes et les conséquences sont approchantes) :

    • Le processus de décision et de validation mis en place était sans queue ni tête avec un reporting tripartite qui rendait les utilisateurs squizos et finissait en guerre des (petits) chefs pendant les employés étaient abandonnés à eux-même sans possibilité d’agir. • Bref process “humainement impossible” mais nickel sur le papier. • Les concepteurs du dit processus ont été mis au placard mais il était trop tard pour revenir dessus, il a donc été mis en place parce que de toute manière on avait développé l’outil. • Pour des raisons évidentes je ne peux citer de chiffres ni de verbatim mais question inefficacité, turnover et détresse professionnelle on a atteint de rares sommets. • Réponse d’un dirigeant à la lecture de l’audit : on a oublié de prendre le compte le fait que les décisions étaient prises et exécutées par des humains…on pensait qu’un bon process et l’outil qui le mettait en oeuvre nous débarrasserait des questions rh.

Réagir à Passer du processus au logiciel est le meilleur moyen de valider leur réalisme

Afin de maintenir le niveau global de ce site, les commentaires font l'objet d'une politique de modération qualitative basée sur des critères non écrits et totalement subjectifs, donc injustes.

Les commentaires écrits en langage SMS, inutiles, déplacés, injurieux ou relevant du spam seront systématiquement supprimés sans avertissement préalable.

Les trackbacks sont fermés pour cause de spam.