Approche du système d'information par les processus

20 décembre 2003

Processus et pratique

Le mot " processus " est à la mode, ce qui entraîne des confusions : lorsque quelqu’un l’utilise, on a du mal à savoir quel sens exact il lui donne. Pourtant ce mot évoque non une théorie vague et vaporeuse, mais une action pratique et d’ailleurs de simple bon sens.

Toute entreprise est en effet organisée pour la production de valeur, cette production se concrétisant par la fourniture d’un output (que celui-ci soit désigné par les termes " produit ", " service " ou " livrable ") en consommant certains inputs, la valeur produite étant alors la différence entre la valeur des outputs et la valeur des inputs. On peut calculer la valeur produite soit en considérant l’entreprise comme un tout, soit en la subdivisant en métiers divers qui chacun produisent une valeur spécifique. On peut encore subdiviser ce découpage, l’important étant qu’à chaque classe de ce découpage on puisse associer un " output ", des " inputs ", et une valeur. Trouver le " bon " niveau de découpage est affaire d’expérience et de doigté. L’important est d’identifier le découpage qui correspond aux possibilités de l’entreprise en matière de gestion et qui permet une identification claire des responsabilités.

Une fois ce découpage effectué et les valeurs que produit l’entreprise identifiées, se pose pour chacune de ces valeurs une question simple et évidente : "  Comment s’y prend-on pour produire cette valeur ? ".

Pour répondre à cette question, il faut considérer les étapes de la production, les activités des divers acteurs (contenu, enchaînement), les moyens qu’ils utilisent (papier, téléphone, ordinateur, outils, machines, biens intermédiaires), les données qu’ils consultent, saisissent, traitent etc.

Lorsque l’on a décrit tout cela, on a décrit un " processus ", enchaînement des activités concourant à la production d’une valeur.

On commence donc à parler en termes de processus quand, après avoir répondu à la question " que faire ? ", on pose la question " comment faire ? ".

Où est la nouveauté ?

L’approche par les processus n’a rien de nouveau. Certains pourraient penser qu’il est déplacé de donner tant d’importance à une démarche que l’on pratique depuis longtemps.

Ils ont pour partie raison : cette démarche colle au bon sens, qui n’est pas chose récente ; mais il y a tout de même une nouveauté : mettre l’accent sur le processus en tant que tel, ce n’est pas seulement dire que l’on va s’occuper de " la façon dont on fait les choses " ; c’est dire aussi que l’on va la documenter, l’expliciter. La nouveauté, ce n’est pas de parler des processus - puisqu’il y a des processus depuis que l’être humain travaille - c’est de se donner pour but de les élucider.

Élucider un processus, c’est :
- porter sa description à un niveau de clarté et de simplicité qui l’illumine,
- rendre cette description transparente en facilitant son partage entre les acteurs concernés.

Faire passer l’organisation des tâches de l’implicite à l’explicite, c’est une démarche qui a des conséquences : elle n’est donc pas neutre.

NB : On dit parfois qu’il faut " optimiser les processus ". L'ambition d'optimiser tend la volonté dans la recherche de la perfection, et implique que l’on soit capable de déterminer l’optimum a priori. Il est préférable de suivre la démarche plus modeste de l’élucidation.

Améliorer les processus

Un des premiers résultats de cette démarche, c’est de rendre visibles les défauts éventuels d’un processus. Prenons quelques exemples.

1) Si le traitement du courrier comporte une phase pendant laquelle la lettre arrivée est posée sur une pile, et la pile de lettres est traitée du haut en bas (comme cela peut se produire sur le bureau de chacun), le courrier sera traité selon le mode LIFO (" last in, first out ") qui introduit des délais de réponse aléatoires et suscite des non réponses une fois le délai décent dépassé.

2) Si l’enchaînement des tâches ne permet pas le suivi d’une affaire (on ne peut pas savoir où est un dossier en cours de traitement, on ne sait donc pas quelles opérations ont été faites sur ce dossier, on ne peut pas consulter les avis donnés avant que l’ensemble du circuit n’ait été parcouru), on devra se livrer sur chaque dossier terminé à une vérification lourde ; on risque de relancer des démarches en fin de course parce telle étape intermédiaire aura été mal réalisée.

3) Si l’enchaînement des tâches ne " boucle " pas (c’est-à-dire si l’on ne contrôle pas son délai de traitement), on risque que le dossier se " perde dans les sables ", qu’il passe de main en main pour finir dans une discrète corbeille à papier.

4) Si les " livrables " intermédiaires (ce que doit fournir chacun des acteurs qui contribue au processus) sont définis de façon ambiguë, des allers et retours et récriminations entre acteurs successifs sont inévitables.

5) Si les données sont saisies sans que l’on dispose de moyens de vérification sur le poste de travail, des erreurs seront introduites dans les fichiers ; il faudra les détecter en batch et les corriger péniblement.

6) S’il faut une ressaisie manuelle pour recopier dans une application certaines données résultant d’une autre, elles provoqueront des erreurs (le taux d’erreur est de quelques fractions de pour mille) et introduiront des délais aléatoires dans les mises à jour.

7) Si une liste de diffusion n’est pas mise à jour sans délai en fonction des nominations et changements d’affectation, les circuits des documents et des informations seront mal ajustés.

8) Si une personne ne consulte jamais sa boîte aux lettres, elle sera inopérante dans tout circuit de décision impliquant l’usage de la messagerie.

9) Si une documentation technique est diffusée en mode papier, la prise en compte des corrections apportées par ses versions successives supposera un travail de classement pénible de la part de l’utilisateur, et souvent elle ne sera pas faite.

10) Si les données de référence sont stockées dans plusieurs endroits différents, il faudra les mettre à jour à la main simultanément lors de tout changement du contexte, ce qui entraîne des risques d’oublis suscitant des incohérences dans le système d’information.

De l’élucidation à l’animation

L’élucidation des processus ne comporte donc pas seulement la phase descriptive pendant laquelle on note ce qui se passe dans de petits diagrammes (avec des cases, titres, flèches entre les cases, commentaires etc.) ; c’est aussi une phase normative, mais naturelle, car elle fait apparaître des défauts qui sautent aux yeux et les participants aux travaux trouvent alors tout simple de les corriger.

" Faire apparaître ", " trouver tout simple ", cela ne va pas de soi : pour que cela marche, il faut un animateur habile qui rendra les choses perceptibles en éveillant l’intuition des participants.

La collecte de l’information sur les processus, la validation de leur élucidation, la discussion des résultats, supposent des contacts avec des experts du métier puis une animation plus large touchant finalement l’ensemble des praticiens concernés. L’expérience montre que les gens de métier participent avec enthousiasme à ces démarches (le mot "enthousiasme" n’est pas trop fort) : l’élucidation clarifie en effet des questions qu'ils se posaient confusément et qui les mettaient mal à l’aise ; elle leur permet de supprimer des dysfonctionnements irritants, ou de comprendre la rationalité sous-jacente à ce qu’ils prenaient pour un dysfonctionnement.

Si l’on veut capitaliser le progrès accompli lors de l’élucidation il faut articuler une transformation du système d’information à l’élucidation du processus. C’est ce que certains consultants résument par la règle " pas de processus sans workflow ", " No Process Without Workflow ".

Il y a là aujourd’hui une difficulté pratique. Les consultants spécialisés dans l’élucidation des processus (on dit " l’analyse des processus ") sont souvent des organisateurs et non des informaticiens et il existe, au sein des grands cabinets, une méfiance réciproque qui nuit à la coopération entre consultants en organisation et consultants en informatique.

A cette difficulté pratique correspond bien sûr un piège : d’excellents travaux peuvent être réalisés sur les processus sans que l’on se soucie de leur articulation avec le système d’information. Trop souvent ces travaux se concentreront sur des améliorations de détail et de court terme, utiles certes mais d’une utilité limitée car ils n’envisagent pas la totalité du processus mais seulement une partie ; par ailleurs, il sera impossible, sur la base de ces travaux, de disposer des outils de contrôle automatique permettant de vérifier leur application.

Mise en place d’un workflow

Le processus, c’est la succession des activités des acteurs avec leurs délais, leur qualité etc. Un " workflow ", c’est une application informatique qui a pour but de rendre visible cette succession et d’en permettre le contrôle. Lorsqu’un processus est équipé d’un workflow, il est possible de :
- savoir à tout moment où en est la procédure appliquée à un dossier, consulter les avis qui ont été donnés, relancer la procédure si elle s’enlise,
- contrôler les délais de bouclage sur l’ensemble du processus comme sur la production de livrables intermédiaires,
- rerouter automatiquement un dossier si l’un des acteurs est absent ou empêché, ou encore s’il met trop de temps à le traiter,
- produire automatiquement des indicateurs de délais et de volume permettant à l’animateur de contrôler la qualité du processus et de redéfinir l’allocation des ressources si des goulets d’étranglement apparaissent.

Le workflow, avec son formalisme et ses outils, concrétise l’élucidation du processus et permet de la capitaliser, c’est-à-dire de la garder vivante en mémoire, de la mettre à jour et de la communiquer.

Représentation du processus

Quand on utilise le formalisme du workflow, un processus se décrit sous la forme d’un graphe. Les nœuds représentent les tâches élémentaires (" activités "), les arcs représentent le trajet des messages émis à la fin d’une tâche pour lancer les tâches suivantes. Il est utile de donner à ce graphe la forme circulaire qui marquera que le processus est déclenché par un fait extérieur (réception d’une commande, d’une lettre de réclamation, franchissement du délai de maintenance d’un équipement) auquel il répond par une action sur l’extérieur (livraison, lettre, opération de maintenance). Il convient de s’assurer que cette réponse a lieu dans un délai et sous une forme convenable : c’est le contrôle du bouclage du processus.

Il faut aussi introduire d’autres compteurs (volume, délai, valeur etc.). En effet, la formalisation du processus suscite une organisation impliquant une délégation de responsabilité aux personnes qui réalisent les tâches. Dès lors l’intervention de l’encadrement ne se fonde plus sur l’approbation des actes un par un, mais sur un contrôle statistique a posteriori et sur la diffusion de consignes nouvelles si des dysfonctionnements apparaissent ou si l’on veut faire évoluer le processus.

On peut aussi représenter le processus par un modèle en couches :

La réalisation d’un processus suppose le plus souvent des sous-processus fournissant chacun un " livrable " intermédiaire (exemple : expertise fournie lors de l’instruction d’une demande d’autorisation d’investissement).

Tout processus a une existence de facto, avant sa description. Mais un processus qui n’a pas été décrit ni pensé présente souvent des défauts. Par exemple il ne boucle pas : la succession des tâches se poursuit sans que l’on vérifie qu’il a été répondu à chaque événement extérieur, et le risque existe qu'il " se perde dans les sables " (c’est le cas lorsqu’une lettre de client passe de mains en mains, sans que personne ne contrôle le délai de réponse : on finit par renoncer à lui répondre lorsque le délai décent a été dépassé).

Situation cible

Comment se présente une entreprise dont les processus ont été élucidés et équipés de workflows permettant un contrôle de leur qualité (ainsi que les évolutions liées à celles des missions de l’entreprise) ?

1) D’une part, et c’est ce qui frappe le plus, les personnes qui travaillent dans cette entreprise trouvent leur travail simple, logique, efficace. L’organisation de la succession des tâches leur est connue, ainsi que la démarche à suivre en cas d’incident. Elles savent ce qu’elles ont à faire et ce que doivent faire les personnes avec qui elles coopèrent. Elles disposent d’un espace de responsabilité dans lequel elles peuvent exercer leur jugement et leur esprit d’initiative.

2) Le nombre des niveaux hiérarchiques a diminué : la transparence, l’automatisation des indicateurs rendent en effet inutiles les " petits chefs " dont le rôle était de transmettre aux exécutants les consignes de la direction, puis de faire des rapports à la direction sur l’exécution des tâches.

3) Les structures ainsi organisées sont " qualifiantes " : l’agent accroît ses compétences en travaillant.

4) Leur pilotage est facilité par la transparence du processus. Cette transparence facilite aussi les démarches qualité en faisant clairement apparaître les performances de chaque entité.

5) Les informations accumulées à l’occasion du déroulement des processus constituent une source éditoriale qui peut être exploitée pour alimenter les systèmes d’information décisionnels.

L'étude du cas " Infotel " illustre les conséquences pratiques de cette démarche ainsi que les difficultés que l’on rencontre dans son déroulement.

Processus et objets

Pour décrire l'activité d'un utilisateur, il suffit d’indiquer les données que celui-ci consulte, celles qu’il saisit, les traitements qu’il lance, ainsi que l’ordre (éventuellement souple) dans lequel il réalise ces opérations. Chaque utilisateur va consulter ou saisir quelques données, déclencher un nombre limité de traitements : ceci conduit naturellement vers la programmation orientée objet.

Le langage UML (" Unified Modeling Language " ; cf. Martin Fowler, UML distilled, Addison Wesley 1997), qui fédère les langages de modélisation en matière d’approche objet, fournit les documents nécessaires pour décrire les activités (" use cases  " selon le vocabulaire de Jacobson), les classes (" diagrammes de classes ") et la succession des opérations (" diagrammes de séquences "). On construit ainsi un " modèle complet " qui, établi par un maître d’ouvrage et communiqué au maître d’œuvre informatique, indique à ce dernier ce qui doit apparaître sur les écrans des utilisateurs, les actions que ceux-ci vont réaliser, ainsi que les compteurs utilisés à des fins de contrôle. Un outil comme le logiciel Rose de Rational facilite la mise en forme du modèle et permet en outre de générer automatiquement une grande partie du code source une fois le processus modélisé.

Le modèle complet des processus est plus précis que les spécifications fonctionnelles fournies à l’informatique. Il indique sans ambiguïté ce que l’utilisateur veut faire et aide à découper le développement en petits modules, les classes, clairement reliées chacune à une finalité pratique (c’est pour cela que l’on parle d’" objets métier ").

L’analyse des activités fait apparaître que les mêmes classes sont utiles à plusieurs acteurs ou que l’on peut satisfaire les besoins de plusieurs acteurs en construisant des classes dont la forme logique est identique ou analogue (héritage, polymorphisme). Elle fait également apparaître que les mêmes classes sont souvent articulées au sein de " composants " qui les regroupent, ce qui permet de fédérer leurs interfaces. Ces analogies et regroupements font parfois apparaître des êtres sémantiques nouveaux concrétisant des concepts inédits. Les langages de développement " orientés objet " exploitent ces possibilités qui allègent le développement au bénéfice de la conception. Ils visent à réduire ainsi les coûts de maintenance et à faciliter l’évolution du système d’information.

La mise en œuvre du modèle par l’informatique suppose que les développements soient réalisés en utilisant un des langages qui supportent le formalisme objet (Java, C++). Une articulation intelligente entre les outils de développement et les langages de modélisation UML permet de maîtriser la documentation des versions successives, les mises à jour à introduire lors des évolutions, et facilite l’évolutivité du logiciel selon les versions successives du modèle métier.

Les échanges de messages entre objets ou avec les bases de données sont réalisés par un " broker " (exemples de produits du marché : Tuxedo de BEA, Orbix d’Iona) qui traite les problèmes d’adressage, de transcodage, ainsi que les questions délicates de " persistance " pendant la durée de la transaction (notamment les questions de " concurrence " qui se posent lorsque deux utilisateurs travaillent en même temps sur le même composant ). Ceci suppose que l’informatique soit capable de dominer l’articulation du monde objet avec les anciennes applications, dont l’adaptation aux langages "orientés objet" prendra quelques années. Les techniques à maîtriser pour assurer un service de qualité convenable en univers hétérogène sont délicates et nécessitent une compétence élevée chez les informaticiens.

Si cette conception de l’informatique implique l’acquisition de compétences nouvelles de la part des informaticiens (apprentissage des langages Java et C++, de la maîtrise des " brokers " et du "middleware", de la programmation des interfaces (Java et HTML), de l’articulation de la gestion de configuration avec les modèles métiers en UML), elle offre à la profession informatique un terrain d’expansion nouveau et renouvelle les conditions du dialogue avec les utilisateurs. Beaucoup d'informaticiens considèrent cette évolution avec intérêt.