Approche du système d'information par les processus

26 décembre 2002

Le terme "processus" désigne l'enchaînement des tâches réalisées pour remplir une fonction de l'entreprise, donc pour produire une valeur ajoutée. Ces tâches sont soit mentales (perception, jugement, décision) soit physiques (fabriquer un produit, le livrer à un client, réaliser une opération de maintenance), les tâches mentales préparant et accompagnant les tâches physiques. On appelle "activité" l'ensemble des tâches réalisées par un même acteur lors d'une étape du déroulement du processus. 

Le système d'information a pour fonction d'assister l'utilisateur dans les tâches mentales liées aux processus. Partant de cette définition, on définira le système d'information à partir des processus qu'il faut d'abord formaliser.

Formaliser un processus conduit à définir un "workflow", c'est-à-dire à définir de façon explicite les activités et leur enchaînement. Cela aboutira à la réalisation d'un programme qui effectuera automatiquement les opérations suivantes  :

• fournir à l'utilisateur les interfaces nécessaires à chaque activité (regrouper sur un écran les plages de consultation et de saisie évitera à l'utilisateur de se connecter, déconnecter, reconnecter à de multiples applications, de faire des doubles saisies, de naviguer dans des codes et touches de fonction divers etc.),
• router les messages d'une activité à la suivante (lorsque l'utilisateur tape sur la touche "valider" à la fin de son travail, il n'a pas à chercher à qui envoyer le résultat : le workflow est équipé de tables d'adressage et assure automatiquement le routage).
• surveiller le délai de réalisation d'une activité : en cas de dépassement l'utilisateur est prévenu par une alarme, ou bien le dossier est expédié vers un autre utilisateur.
• produire les indicateurs (délais de réalisation, volumes traités, utilisation des ressources, satisfaction du client) qui alimentent le pilotage du processus et permettent de vérifier la bonne utilisation des ressources humaines et matérielles. 

Modéliser un processus, c'est décrire la succession des activités qu'il comporte et le contenu de chaque activité : ce que fait chaque acteur, les données qu'il manipule, les traitements qu'il ordonne, les délais dans lesquels son travail doit être exécuté ; c'est aussi décrire le routage des messages entre activités et les compteurs qui permettront à un animateur de contrôler la qualité du processus.

On peut représenter de la façon suivante un processus commercial :

La réalisation physique des tâches est décrite et balisée par le modèle du processus, mais elle nécessite des actions qui ne peuvent être réalisée que par un être humain et qui échappent donc à l'ordinateur, même si celui-ci aide leur préparation. Le processus relève de l'"assisté par ordinateur", non de l'automatisation intégrale ; il aide l'utilisateur sans se substituer à lui, tout en automatisant des tâches que l'on faisait auparavant à la main.

Représentation du processus

Un processus peut se décrire sous la forme d'un graphe. Les nœuds représentent les activités, les arcs représentent le trajet des messages émis à la fin d'une activité pour lancer la (ou les) activité(s) suivante(s).

Il est commode de donner à ce graphe la forme circulaire. Elle souligne que le processus est déclenché par un événement provenant de l'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 un autre événement émis vers l'extérieur (livraison, lettre, opération de maintenance). Le rôle du processus, c'est de réaliser l'ensemble des tâches qui concourent à l'élaboration de cette réponse, et qui constituent l'acte de production. Il convient de s'assurer que la réponse est émise dans un délai et sous la forme convenable, qu'elle est de bonne qualité : c'est le contrôle du bouclage du processus.

Les diverses activités qui s'enchaînent lors d'un processus comportent des saisies de données, des consultations de données, le lancement de traitements sur les données. Les données consultées et saisies lors du processus doivent être cohérentes : s'il s'agit de traiter une commande, il faut que les ordres de production ou de déstockage reprennent fidèlement les termes de la commande. Ainsi les activités "tournent autour des données", "font la ronde autour des données" ; nous avons représenté ci-dessus les données (et les traitements qui leur sont associées) par un rond marqué du mot "Objets" : nous verrons que l'une des façons les plus efficaces de représenter données et traitements est de les organiser en "objets". 

Le rôle du processus n'est pas de répondre à un événement isolé, mais à un flux d'événements de même nature : le processus de production répond à un flux de commandes ; le processus de réponse à une lettre répond à un flux de lettres. Le caractère répétitif du processus est analogue à celui d'un moteur (même si son rythme, dicté par l'arrivée aléatoire des événements, n'a pas la même régularité). La qualité du processus s'évalue non sur un événement particulier, mais sur une statistique (histogramme de délais, de satisfaction des clients etc.) représentant la façon dont l'ensemble des événements a été traité. 

Le respect du délai de réponse implique souvent une délégation de responsabilité aux personnes qui réalisent les tâches. L'approche par les processus suscite donc une modification du rôle de l'encadrement : son intervention ne se fonde plus sur l'approbation des actes un par un, mais sur un contrôle statistique a posteriori et sur la mise à jour des consignes si un dysfonctionnement apparaît ou si il faut faire évoluer le processus. La transmission des consignes vers les exécutants, l'émission des rapports vers le haut sont remplacées en partie, l'une par la mise en forme du workflow, l'autre par l'édition semi-automatique de comptes rendus alimentés par les compteurs que le processus comporte. Le nombre des niveaux hiérarchiques se réduit alors, et la communication entre "base" et "sommet" est moins lointaine. 

La réalisation d'un processus suppose souvent des sous-processus fournissant chacun des produits intermédiaires ou "livrables" (exemple : expertise fournie lors de l'instruction d'une demande d'autorisation d'investissement ou d’une demande de crédit). En pratique, les sous-processus sont le plus souvent nombreux et comportent eux-mêmes des sous processus ; le dessin ci-dessous est donc schématique : 

Toute opération de production est une réponse à un événement extérieur et articule des activités diverses : le processus existe donc de facto dans l'entreprise avant toute description, de même qu'une langue existe avant que l'on n'ait rédigé sa grammaire. Mais un processus qui n'a pas été pensé présente souvent des défauts. Par exemple la succession des tâches se poursuivra sans que l'on vérifie s'il a été répondu à chaque événement ; le risque existe alors que le processus "se perde dans les sables" : c'est le cas lorsque la lettre d'un client passe de bureau en bureau, et attend dans des piles sans que personne ne contrôle le délai de réponse : on renoncera à répondre lorsque le délai décent aura été dépassé et la lettre ira à la corbeille. Les piles de documents sur les bureaux sont souvent traitées sous le mode LIFO ("last in, first out" : le dernier document arrivé est traité en premier), qui accroît la dispersion des délais de traitement. 

La modélisation d'un processus n'est pas la simple mise en forme du processus existant ; elle conduit souvent à repérer et corriger des défauts (bras morts où les délais s'accumulent : le processus finit par se "perdre dans les sables" ; redondance : la même tâche est réalisée par deux acteurs à la fois ; erreur d'adressage : le dossier parvient à une personne non concernée qui devra identifier son destinataire et le lui faire parvenir ; mauvaise répartition de la charge de travail : certaines personnes sont surchargées alors que d'autres n'ont rien à faire, etc.) Comme l'entreprise travaille selon des habitudes dont la raison d'être s'est souvent estompée, un processus qui n'a jamais été modélisé aura presque toujours défauts : la modélisation fait souvent gagner de l'ordre de 20 % en productivité et en qualité.  

On dit parfois que la modélisation doit "optimiser" le processus. L'expérience montre que le gain de qualité provient plutôt de la clarté que la modélisation apporte au processus, ainsi que de l'animation qu'elle permet de mettre en place (voir "Optimiser ou élucider ?" et "Élucider et animer"). 

Vers la programmation objet

Chaque utilisateur va, lors de l'activité qu'il accomplit, consulter et/ou saisir quelques données, déclencher un nombre limité de traitements : ceci conduit naturellement vers la programmation objet (on dit aussi "orientée objet"). Un objet est un petit programme qui rassemble les données et les traitements concernant un des êtres du monde réel sur lesquels l'entreprise entend agir (produit, client, fournisseur, partenaire etc.), ou des êtres intermédiaires (dossiers, rapports, feuilles de calcul) nécessaires à l'élaboration du produit. Pour comprendre la raison d'être et l'utilité de la programmation objet, voir "De la programmation fonctionnelle à la technologie objet". 

Dès lors on utilisera de préférence le langage UML pour modéliser les processus de production, car ce langage convient bien à la préparation d'une programmation objet (voir "Langage UML"). Pour les "petits" processus, les opérations qui peuvent être réalisées avec des outils bureautiques (demandes de congé ou de mutation, demandes de fournitures, préparation du budget annuel etc.), on peut se contenter des outils de workflow offerts sur le marché (voir par exemple l'offre de W4). (Nota Bene : si ces processus sont "petits" selon le volume des ressources informatiques consommées et selon le coût de leur mise en place, ils peuvent être importants pour l'efficacité de l'entreprise ; il ne faut donc pas les négliger.)