Bien entendu, cette capacité d’abstraction est l’une des raisons même pour laquelle le modélisateur occupe ce poste : c’est une compétence spécifique et donc tout le monde ne peut s’improviser modélisateur. Ajoutons à cela une nécessaire connaissance des méthodes et outils associés à la modélisation et vous comprendrez qu’il est difficile de confier ce rôle au premier venu.

Malgré cela, le côté abstrait des choses peut être frustrant. Lorsqu’on travaille sur quelque chose de concret, il est plus facile de savoir quand s’arrêter. Il est plus facile de mesurer la progression. L’équipe qui fabrique l’Airbus peut voir se concrétiser le fruit de leur travail. Ils peuvent voir les pièces se réaliser pour finalement être assemblées pour obtenir le produit fini. Même si la production de l’avion ne marque pas la fin du processus ou du travail des équipes, c’est un jalon notable que n’ont pas la plupart des modélisateurs, tant du côté des processus métier que du côté des urbanistes du SI. Le produit fini est très souvent un nouveau système et restera donc encore une fois… abstrait.

Parmi les tâches que j’ai réalisé récemment, le portage de processus métier dans le but de le rendre exécutable est un exercice que j’apprécie. Certes, rendre exécutable un processus ne le rend pas réel mais admettez que son niveau d’utilité progresse énormément entre son état de processus modélisé dans un référentiel et celui de processus exécutable : il devient utilisable.

Le processus exécutable prend vie puisqu’il entre en interaction avec d’autres personnes que le modélisateur ou son sponsor. Comment arrive-t-on ici ? Comment passe-t-on d’un processus métier à un processus exécutable ?

Tout comme dans les théories économiques, il existe plusieurs courants de pensée autour de l’exécution des processus. Certains outils vont être axés sur l’interaction homme-homme, d’autres sur l’intégration entre homme et machine ou bien encore sur la simple automatisation de tâches.

Ainsi, on peut distinguer les outils qui servent à gérer la collaboration entre personnes de ceux qui servent à gérer l’exécution pure et simple d’un processus. Dans le second cas, l’outil permet un traçage et une interaction plus avancée avec l’utilisateur. Vous l’aurez deviné, dans l’idéal un outil doit faire les 2.

Lorsqu’on réalise le portage d’un processus métier, plusieurs choses vont être frappantes :
- le processus apparait comme théorique et donc non exécutable directement (dépend beaucoup de la méthode de modélisation)
- toutes les informations pour l’exécuter ne sont pas disponibles (délais, personnes…) et seront difficiles à obtenir
- le processus théorique est plus compliqué que le processus réel

J’appelle « processus théorique» le processus qui se trouve dans le référentiel d’entreprise. C’est le modèle théorique qui est né de l’esprit et d’une interprétation de la réalité. Cette opération le rend à la fois plus complexe que la réalité mais tout en le gardant non exécutable. Autrement dit, il est décrit pour être théorique et non pour être exécutable. Si vous n’êtes pas familier de la pratique cela peut vous paraître contre-productif mais ça ne l’est pas : chaque modélisation à son objectif. Celui du processus théorique, c’est l’analyse et il n’y a donc rien de choquant à ce qu’il ne soit pas exécutable.

Beaucoup de personnes pensent cependant que le processus théorique est le processus exécutable, au prix de quelques adaptations mineures. Encore une fois tout dépend de la méthode de modélisation utilisée au départ. Certains partiront avec une notation BPMN et un méta-modèle orienté exécution : cela facilitera le portage mais rendra difficile une analyse en profondeur.

Ce sont 2 mondes séparés : la théorie et la pratique. C’est le gap que des langages comme BPEL essaient de combler.

Pour rendre exécutable un processus nous allons nous intéresser principalement aux actions et donc aux acteurs. Chaque tâche sera ainsi prise en charge par un acteur au travers d’un écran utilisateur. Cet écran est un formulaire web qui affiche les informations dont a besoin l’utilisateur pour exécuter la tâche ainsi que les informations attendues de sa part.

Une règle simple peut-être énoncée : s’il n’y a pas d’interaction humaine, il n’y a pas d’écran de dialogue (évident mais bon à rappeler!). Autrement dit, si le processus théorique contient 20 tâches, le processus exécutable en aura surement moins (15 ou 10).

Ce qui est intéressant dans l’exécution, c’est la mise en oeuvre du système et son effet sur l’entreprise. Par exemple, pour chaque assignation de tâche entre 2 acteurs (Je valide ma demande de congés, mon supérieur doit la vérifier) il faudra définir une personne remplaçante, un délai d’exécution, un chemin par défaut en cas de problèmes… Aucun chemin d’exécution ne pourra être laissé ouvert.

Il s’agit véritablement d’une opération de transformation du processus et il y a vraiment autant de manière de rendre exécutable un processus que de manière de le modéliser. Récemment j’effectuais le portage d’un processus ITIL (Change Management) et de très nombreuses questions doivent être posées pour que le client obtienne le résultat qui lui convient.

L’exécution est l’aboutissement du travail de modélisation et c’est une étape très intéressante. Les outils en mode SaaS (hébergé sur le web) permettent de faciliter grandement l’intégration des processus dans les entreprises (CMlight, Xpert.Ivy, RunMyProcess…), notamment de taille modeste puisque celle-ci n’a plus à mettre en place les solutions techniques pour supporter le tout : elle se concentre sur le résultat attendu et surtout sur l’organisation du métier. Après tout, c’est comme ça que ça devrait être non ?

Par Michael Ferrari
urbanisation-soa-bpmn.com