C’est drôle de constater comment le petit monde des bloggeurs « BPM » peut s’enflammer subitement sur un sujet commun. Si vous suivez un peu l’actualité de la blogosphère BPM ces derniers jours, vous n’êtes pas sans avoir remarqué cette série de notes sur l’analogie entre les applications développées sur Excel et le souhait des utilisateurs métiers de s’approprier la modélisation des processus.

Tout commence par une note de David Ogren’s sur le développement d’applications non-traditionnelles, David fait en effet l’analogie entre les utilisateurs métiers qui se sont approprié les tableurs pour « développer » des applications selon leurs besoins en se passant des services de leur département IT. Je le rejoins sur ce point, je vois en effet régulièrement des feuilles de calcul utilisées pour gérer des pans entiers d’activités, des utilisateurs tous fiers de parler de leur capacité à « programmer » dans Excel pour mettre au point des tableurs toujours plus complexes. Et il est vrai également que ces tableurs embarquent bien souvent une bonne part de logique métier et de données capitales pour l’Entreprise. David va même jusqu’à avancer que bon nombre d’entreprises s’appuient de fait sur ces applications pour garantir leur conformité à SOX par exemple, et là aussi je le rejoins, il est stupéfiant parfois de voir ce que l’on fait avec ces feuilles de calcul (en bien comme en mal d’ailleurs).

Le sujet a été en fait initié par Keith Swenson, et repris depuis par Phil Ayres, Jesper Joergensen, et même Bruce Silver, sur leurs blogs respectifs. Sandy elle n’a pas encore réagi, mais elle me semble bien occupée ces jours-ci :).

De quoi parle-t-on réellement ? De la possibilité offerte aujourd’hui aux utilisateurs métiers de prendre le contrôle de leurs processus et surtout de les modéliser à l’aide d’outils conviviaux interagissant avec le moteur de workflow sans nécessairement utiliser les services des développeurs et des experts du système. Il est vrai que les outils de modélisation sont de plus en plus à la portée des utilisateurs, que leur intégration avec les moteurs workflow est de plus en plus fine (à ce sujet FileNet a récemment annoncé son nouveau partenariat avec Mega), et qu’il est donc aujourd’hui à la portée de tous de concevoir, modéliser et surtout mettre en service un processus de son propre chef.

Chacun des intervenants cités ci-dessus donne sa position avec tout naturellement deux clans, ceux qui croient ceci possible et … les autres. Je ne rentrerai pas dans le détail des positions respectives de chacun, mais personnellement je reste sceptique quant à la faisabilité technique réelle de la chose tout en l’espérant vivement sur un plan purement fonctionnel.

Selon moi, la différence majeure entre une « application Excel » et la modélisation d’un processus métier, c’est la portée de cette application. De ce que j’en vois chez mes clients, ces tableurs évolués sont utilisés par des individus ou des petits groupes de travail, au sein d’un service ou d’une entité de taille restreinte, moins souvent par l’organisation dans sa globalité. Le contrôle en est difficile, voire impossible, la sauvegarde est aléatoire, la gestion de l’évolution est précaire pour ne pas dire inexistante et surtout, la pérennité des informations ainsi consolidées n’est pas garantie. La modélisation d’un processus métier, toujours selon moi, c’est autre chose. Il s’agit d’un travail pour lequel l’ensemble des intervenants ont abouti à un consensus sur la définition et les données associées et surtout, différence principale je pense, cette modélisation va être employée à grande échelle, très fréquemment, avec un fort besoin de stabilité et de pérennité, ce que ne peut être une « application Excel ».

Maintenant un point m’interpelle tout particulièrement au-delà de ce débat, c’est ce besoin des utilisateurs de pouvoir s’approprier la définition des processus. Jusqu’à il y a peu, et même encore bien souvent, la mise en oeuvre du BPM passait par l’implication des utilisateurs – on leur fait concevoir le processus – mais ce n’est pas eux qui le mettent en oeuvre. Or un des freins justement à l’adoption massive du BPM est le fait que ces mêmes utilisateurs ne retrouvent pas nécessairement à la sortie le processus tel qu’ils l’avaient initialement conçu et ne cherchent pas à s’approprier l’application résultante si elle leur semble ne pas correspondre à ce qu’ils ont décrit. Quand bien même la mise en oeuvre soit fidèle à la description, mais c’est le reflet qui compte et que les utilisateurs voient, qu’ils jugent. Il me paraît donc crucial de leur rendre la main sur la modélisation et je pense sincèrement que les éditeurs l’ont bien compris au vu des dernières avancées technologiques en la matière (BPMN et autres intégrations entre outils). Je ne sais pas si cette analogie Excel-BPM a du sens mais je crois que s’il y a un secteur pour lequel il reste au BPM des progrés à faire, c’est bien là : donner le pouvoir à ceux qui utilisent l’application, leur permettre de modifier le processus s’ils le jugent nécessaire, sous le contrôle des outils gérés eux par l’IT, donner ainsi à l’organisation la souplesse et l’agilité tant recherchées, et faire en sorte que, tout comme avec Excel, chacun pense que l’application qu’il a sous les yeux est celle qu’il a conçue, et non la retranscription par un « étranger » – technicien de surcroît – des actions et enchaînements initialement décrits.

Finalement, cet enchaînement de notes est plutôt agréable à suivre, et constructif car il apporte son lot d’idées toutes aussi intéressantes les unes que les autres, visions différentes de gens différents, j’y met mon grain de sel avec plaisir et j’espère vous voir réagir en nombre à cette note, ne doutant pas que vous aussi vous avez des choses à dire sur le sujet. Affaire à suivre ?