Approche du système d'information par les processus

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 valeur des outputs et valeur des inputs. On peut calculer cette valeur 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 étant d’identifier le découpage qui correspond bien 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 bien naturellement pour chacune la question suivante : "  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.

Où est la nouveauté ?

L’approche par les processus n’a rien de nouveau, et il y a longtemps que l’on en fait sans le dire. Certains pourraient alors penser qu’il est déplacé de donner soudain tant d’importance à une démarche que l’on pratique depuis longtemps sans le dire.

Ils ont pour partie raison - et cette démarche colle d’ailleurs 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, l’élucider. 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.

Elucider 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 et sa communication entre les acteurs concernés.

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

L’élucidation est l’un des leviers les plus puissants de l’organisation. Il est par exemple plus efficace de rendre la qualité visible en produisant des indicateurs, que d’exhorter les gens à bien travailler. Comme le dit Claude Riveline, " chacun se comporte de façon à optimiser l’image que donnent de lui les critères selon lesquels il se sent ou se croit jugé ".

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.

• 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 arriver sur le bureau de chacun), le courrier sera traité en mode LIFO (" last in, first out ") ce qui introduit des délais de réponse aléatoires et des non réponses une fois le délai décent dépassé.
• 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, et 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.
• Si l’enchaînement des tâches ne " boucle " pas (c’est-à-dire si l’on n’a pas de mesure du 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.
• 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.
• Si la saisie des données se fait 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.
• S’il faut une ressaisie manuelle pour recopier dans une application certaines données résultant d’une autre, elles provoqueront des erreurs (taux d’erreur de un à deux pour mille) et introduiront des délais aléatoires dans les mises à jour.
• 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.
• Si une personne n’ouvre jamais sa boîte aux lettres, elle sera inopérante dans tout circuit de décision impliquant l’usage de la messagerie.
• Si une documentation technique est diffusée en mode papier, la prise en compte des corrections apportées par les versions successives supposera un travail de classement pénible de la part de l’utilisateur, et donc souvent elle ne sera pas faite.
• 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 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 rende 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 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 n’est pas trop fort) : l’élucidation clarifie en effet des questions qui se posaient confusément et 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.

Capitaliser sur l’élucidation des processus

Résumons ce qui précède :

· Les " processus " n’ont rien de nouveau : le travail dans une entreprise a toujours été organisé en processus ;

· Ce qui est nouveau par contre, c’est l’accent mis sur leur élucidation, c’est-à-dire sur leur explicitation et leur transparence.

· Cette élucidation, si elle est conduite par un animateur expérimenté, suscite un vif intérêt des participants et entraîne des améliorations substantielles.

Cependant il y a un risque : que l’opération soit un " coup pour rien ", que le " soufflé retombe " une fois l’animateur passé et l’excitation du travail calmée. La clarté acquise lors de l’élucidation s’estompe dans les mémoires, les nouveaux venus n’en bénéficient pas ; après quelques mois ou années le bénéfice de l’opération est perdu.

Si l’on veut capitaliser le progrès accompli lors de ce travail d’élucidation, il faut articuler une transformation du système d’information à l’élucidation du processus. C’est ce que certains consultants américains 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 entre consultants en organisation et consultants en informatique. Il leur est difficile de coopérer.

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’envisageront 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.

Dans le contexte culturel propre à certaines entreprises, celui qui évoque des principes de méthode, ou même des règles de simple bon sens, court le risque de se faire taxer d’" esprit de système ". Il serait certes trop facile de faire observer que l’" esprit de désordre " est notoirement improductif. Quoiqu’il en soit, voici le travail à faire :

Elucider le rôle du SI dans le processus

Tout processus comporte deux aspects inséparables et complémentaires comme les deux faces d’une médaille :

• le travail des personnes qui participent au processus par leur jugement, leurs décisions et leurs actions ;

• le système d’information, qui assiste ces personnes en apportant les éléments nécessaires à leur jugement, leurs décisions et leurs actions.

Au sens large, le système d’information comporte tous les supports de mémoire (papier, enregistrement magnétique), tous les modes de traitement (calcul à la main, machine à calculer, traitement de texte, tableur) et tous les modes de communication (parole d’homme à homme ou en réunion, téléphone, transfert de fichier etc.) Dans les organisations d’aujourd’hui, le système d’information fait un usage extensif de l’ordinateur. On est alors dans le monde du travail assisté par ordinateur (TAO) : l’ordinateur n’est pas un automate qui prend les décisions à la place de l’acteur, mais un outil qui l’aide dans la prise de décision en lui fournissant sous forme lisible les informations nécessaires et en réalisant les traitements requis.

Quand on dit TAO il faut considérer les deux faces de la médaille : ce que fait l’acteur, l’aide que lui apporte son ordinateur. Le jugement, la décision et l’action sont le fait de l’être humain, car l’ordinateur est inapte à ces tâches-là. Par contre la recherche et le tri de l’information, la compulsion de gros fichiers, l’affichage ergonomique, l’exécution des traitements et corrections lancés par l’opérateur humain, tout cela relève de l’ordinateur qui exécute ces tâches vite et sans erreur si elles ont été correctement programmées.

L’élucidation d’un processus comporte à la fois celle des tâches remplies par les êtres humains, et celle des opérations que réalisent les ordinateurs. L’amélioration du processus concerne donc aussi les outils informatiques mis à disposition des êtres humains.

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, lire les avis donnés, la relancer si elle s’enlise,

• contrôler les délais de bouclage sur l’ensemble du processus ou sur la production de livrables intermédiaires,

• rerouter automatiquement un dossier si l’un des acteurs est absent ou empêché, ou 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 capitaliser cette élucidation, 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 les messages émis à la fin d’une tâche pour lancer les tâches suivantes. Il est commode de donner à ce graphe la forme circulaire qui marque 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 le processus 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, opération essentielle.

Il faut souvent 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 souvent des sous-processus fournissant chacun des " livrables " intermédiaires (exemple : expertise fournie lors de l’instruction d’une demande d’autorisation d’investissement).

Tout processus a une existence de facto, avant la 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 que le processus " 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 le 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 auparavant de transmettre aux exécutants les consignes de la direction, et 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.

On fournit en annexe à ce rapport un document sur l’expérience " Infotel " , qui mieux que toute considération théorique illustre les conséquences pratiques de cette démarche, ainsi d’ailleurs que les difficultés que l’on rencontre dans son déroulement.

Marche à suivre

Pour articuler l’élucidation des processus à la démarche qualité associée à une production de valeur, il suffit donc de partir d’une question simple : " comment est produite cette valeur " ? Puis il faut travailler …

La réponse à cette question permet d’identifier les processus de travail, de les cartographier, de repérer les sous-processsus correspondant aux livrables intermédiaires. A chacune des classes du découpage de l’entreprise que nous avons décrit au début de ce chapitre correspond un processus spécifique. Il n’existe pas de règle logique pour déterminer le degré de finesse raisonnable de ce découpage, mais une règle pratique qui doit être appliquée au cas par cas : il faut que ce découpage corresponde à une claire identification des responsabilités, c’est-à-dire que l’on puisse identifier une personne responsable pour chaque processus, personne à qui l’entreprise donnera les moyens de contrôler le processus, et qui sera jugée selon la qualité de celui-ci.

L’élucidation des processus suppose ensuite qu’on les documente, selon un formalisme qui devra avoir été défini au préalable, en consultant des experts métiers. Ce travail doit être fait avec quelques experts seulement. La validation de cette élucidation permet ensuite de mettre à plat la description du processus, de repérer des erreurs éventuelles, d’encourager à les corriger. La validation prend la forme d’une animation avec les personnels du terrain, et contribue à la démarche qualité.

La mise en forme ultime du processus implique l’utilisation d’un workflow (" No Pro-cess Without Workflow ! "), et suppose donc des développements informatiques confortant son articulation avec le système d’information.

Il faut tenir compte de cette démarche dans la formulation des objectifs qualité des métiers.

Production de valeur et processus

Un processus est une suite d’opérations déclenchées par une action qui lui est extérieure, et aboutissant à une réponse à cette action. Par exemple l’action du monde extérieur peut être la réception d’une lettre de réclamation, et la réponse à cette action sera la réponse à cette lettre. Ou bien l’action du monde extérieur sera une commande, et la réponse sera une livraison.

Considérons une entreprise dont la fonction de production est

Y = f(K, L, X),

où K est le capital utilisé (biens d’équipement), L le travail et X la consommation intermédiaire nécessaire à la production de Y.

Typiquement, au reçu de la commande, l’entreprise doit réserver les facteurs de production nécessaires (équipement, travail, bien intermédiaire), puis utiliser ces facteurs pour obtenir la production qui sera ensuite livrée en réponse à la commande.

Ce schéma simple permet de voir la relation entre processus et production de valeur. La figure représentative d’un processus est une boucle, qui commence par une action venant de l’extérieur et se termine par une action vers l’extérieur. Lorsque cette boucle se referme, de la valeur aura été produite. Ici, elle est égale à la différence entre la valeur de la production et le coût de production :

V = pY – rK – wL – pX,

où p, r et w sont respectivement le prix des biens, le coût d’utilisation du capital et le salaire horaire.

La figure ci-dessus montre comment le processus s’articule à des sous-processus, qui chacun produisent une valeur consommée ou utilisée par le processus principal.

Si la production fait l’objet d’une organisation utilisant un stock comme tampon, le mécanisme est le suivant : en tablant sur la demande anticipée D^a, elle-même établie à partir de la série chronologique des commandes passées, on établit un programme de production qui alimente le stock. Le stock est utilisé pour faire les livraisons. Le niveau du stock est observé attentivement pour réviser D^a et modifier le programme de production (à la hausse si le stock baisse vite, à la baisse si le stock monte vite).

On a alors le schéma suivant :

Le programme de production mobilise à l’avance les équipements, les personnels et les consommations intermédiaires, et le flux de production est continu, régulé par l’observation du niveau de stocks qui conduit à déterminer le programme de production.

Chacune des boucles du processus correspond à une production de valeur, car elle débouche sur la fourniture d’une prestation qui concrétise la valeur ajoutée fournie pendant la boucle.

On peut représenter le schéma ci-dessus par un modèle en couches :

Observons enfin le graphique qui représente le processus. Les flèches rouges représentent des faits du monde réel (des biens ou services, des " livrables " sont produits et fournis). Les traits fins représentent la circulation d’information. Tout processus a ainsi deux faces : d’une part il implique des faits du monde réel, d’autre part il est instruit, soutenu, contrôlé par une circulation d’information.

Responsabilités

Le découpage des processus est déterminé principalement par la nécessité et la possibilité d’identifier le responsable (ou " propriétaire ") de chaque processus. Un des défauts de l’organisation implicite des processus, c’est la non identification des responsabilités, l’absence de contrôles objectifs permettant de vérifier leur bon fonctionnement (1). L’élucidation des processus suppose en premier lieu que l’on identifie leurs responsables.

La conduite d’un processus suppose que soient tenues les fonctions que nous décrivons ci-dessous. Il revient à l’analyse des charges de travail et des compétences de décider si ces fonctions doivent être réalisées par des personnes différentes, ou si certaines d’entre elles peuvent être réalisées par une même personne.

Il est important de prévoir dans la mise en place du processus les outils nécessaires à la bonne exécution de ces fonctions : la personne qui remplit une fonction doit pouvoir disposer d’une interface commode lui fournissant les informations utiles, ainsi que les moyens de définir et lancer les actions nécessaires.

On distingue quatre types différents de responsabilités : le propriétaire du processus, qui est le responsable d’ensemble et a autorité sur les autres ; l’administrateur qui gère les droits d’accès et de traitement, l’animateur qui veille au respect des règles de bonne pratique, l’éditeur qui assure le traitement et la diffusion des données fournies par les outils de contrôle.

Chacune de ces fonctions doit être doté d’outils appropriés.

Propriétaire

Il s’agit du responsable fonctionnel, chargé par l’entreprise du bon fonctionnement du processus. Il est destinataire des informations de pilotage, et doit diffuser vers les agents les messages (oraux, écrits), la documentation, la formation et les consignes nécessaires.

Les missions du propriétaire du processus sont, dans cet ordre, d’assurer :

le service final rendu par le processus : contrôler les conditions de délai et de qualité de son bouclage.

que le service est produit dans de bonnes conditions d’efficacité : contrôler le coût de fourniture du service.

que les ressources nécessaires à la production du service sont convenablement utilisées : contrôler et répartir la charge de travail des personnes.

Les indicateurs qu’il reçoit concernent les volumes produits, les ressources utilisées, ainsi que la qualité du service (pertinence, délais).

Le propriétaire du processus est assisté, dans l’exercice de sa responsabilité, par l’administrateur, l’animateur et l’éditeur.

Administrateur

Il gère les droits d’accès aux dossiers et aux outils de traitement. Ces droits sont différents selon que l’on considère un agent intervenant dans le processus, le propriétaire du processus, ou des responsables hiérarchiques de divers niveaux.

L’administrateur doit être outillé pour que la gestion des droits obéisse sans délais aux nominations et mutations des personnes, aux changements dans leurs missions et attributions.

Animateur

L’animateur du processus assure la surveillance des bonnes pratiques et du savoir-vivre dans l’utilisation des outils (exemple : la " Netiquette ").

Il surveille le respect des délais et la qualité du processus, et intervient avec pédagogie et diplomatie pour aider les agents dans la qualité de leur travail. Il surveille et anime l’utilisation de la messagerie, de la documentation, des forums, des agendas partagés, et de façon générale de tous les outils communicants.

Editeur

Il assure la sélection, le traitement, la présentation, le commentaire et la diffusion des informations fournies par le processus.

Il doit segmenter les destinataires de ces informations, et définir pour chaque segment la forme et la périodicité de la publication convenable. Il utilise à cette fin divers supports de diffusion (base documentaire, messages, papier) et diverses formes de présentation (données chronologiques ou en coupe instantanée, tableaux de nombres, graphiques, commentaires interprétatifs de synthèse, citations en texte intégral sur des cas particuliers illustratifs etc.).

C’est l’éditeur qui élabore, à partir des données recueillies par les capteurs, des indicateurs de qualité synthétiques dont il diffuse le suivi.

Système d’information et Processus (2)

Le système d’information s’organise désormais autour des processus de l’entreprise. Il s’agit là d’une innovation considérable. Toute l’organisation du système d’information se conçoit sur le mode du travail assisté par ordinateur : la coopération de l’acteur humain et de l’ordinateur devient centrale, ce qui fait passer au premier plan l’exigence de qualité des interfaces homme - machine, ainsi que du support aux utilisateurs, alors que la conception ancienne de l’informatique avait tendance à placer cette exigence au dernier plan.

De même, la modélisation des processus devient l’étape première et cruciale de la mise en forme d’un système d’information. Il en résulte une articulation précise du système d’information aux modes de travail de chaque métier. Pour que cette articulation soit réussie, il faut que les métiers s’impliquent activement dans la mise en forme et la maîtrise de leurs processus, et qu’ils adhèrent à la démarche d’élucidation des processus que nous avons décrite.

Pour illustrer ce changement, nous décrirons deux " modèles " appelés M₁ et M₂. Dans M₁, qui décrit les pratiques anciennes, le système d’information se construit autour des applications informatiques. Dans M₂, le système d’information se construit autour des processus des métiers.

Le rôle de l’informatique change lors du passage de M₁ à M₂ (3). Il est bien évident que ce changement n’est pas facile, mais toutefois il n’est pas impossible : à l’issue de ce changement, utilisateurs comme informaticiens se trouvent dans un monde où leurs responsabilités respectives sont mieux définies, leur coopération assainie, leur relation fondée sur le respect mutuel et la reconnaissance de l’expertise de l’autre.

Il est vrai que pour en arriver là il faut rompre avec des habitudes toutes différentes, ce qui d’aventure peut nécessiter quelques changements de personnes et d’organigramme, de ces changements qui sont à la fois espérés et craints de toute organisation, et qui ne se passent jamais aisément.

Modèle M₁ : les applications

Une application, c’est une suite de traitements appliqués sur des données initiales (" input ") pour fournir un résultat (" output "). Les données initiales sont soit introduites dans l’application par saisie ou comptage automatique, soit issues d’autres applications. Les traitements sont soit des tris et additions permettant de mesurer des agrégats à partir de données détaillées, soit des calculs plus spécifiques (4).

Le fondement d’une application, tel que le définit Merise, réside dans deux modèles : le modèle conceptuel de données comprend les définitions sémantique (5) et technique (6) des données ; le modèle applicatif décrit les traitements.

Nous allons décrire deux scénarios de mise en œuvre du modèle M₁ : le premier, " rose ", montre comment les choses sont censées se passer. Le second, " gris ", montre comment elles se passent trop souvent.

Scénario " rose "

L’application, dont la définition est fondée sur une expression des besoins des utilisateurs sobre, pertinente et sur des priorités clairement exprimées, limite la saisie au strict nécessaire, automatise les traitements, et affiche sur l’écran (ou imprime sur papier) les résultats dont l’utilisateur a besoin. La récupération des données issues d’autres applications est automatique, seules les données nouvelles faisant l’objet d’une saisie manuelle.

L’informaticien, qui reçoit les demandes de divers utilisateurs, construit son architecture de données et de traitements sous une double contrainte de qualité (7) et d’économie. Il répartit ainsi les ressources (mémoire, puissance de calcul, débit des liaisons télécoms) et définit des applications intermédiaires, ainsi que l’architecture des systèmes d’exploitation et langages. La cohérence des applications est alors réalisée au sein du système informatique, cœur du système d’information.

La qualité de l’écriture des programmes garantit qu’il sera facile de les faire évoluer lorsque les besoins changeront.

Scénario " gris "

L’urgence, l’insouciance, l’optimisme, le cloisonnement de l’organisation poussent à concevoir et développer les applications au coup par coup, selon l’arrivée des demandes, sans que la relation avec les autres applications soit maîtrisée ; des données de référence (8) sont redéfinies pour chaque application ; les plates-formes techniques (machines, système d’exploitation, langage) sont choisies en fonction des ressources disponibles lors du développement ; les interfaces présentées à l’utilisateur sont hétéroclites (touches de fonction et codages spécifiques à chaque application).

La " gestion de configuration " (documentation des versions successives d’une application) est laissée à la bonne volonté des chefs de lignes de produits, et certains la négligent. Beaucoup d’incidents restent inexpliqués.

Les métiers utilisateurs ont peu de prise sur l’évolution du système d’information, que l’informatique prétend piloter. Même si le cérémonial du programme budgétaire annuel du système d’information prévoit une sélection parmi les projets présentés par les métiers, et une discussion de leur utilité respective, rien ne garantit que ce programme sera effectivement réalisé. D’ailleurs le budget qui lui est consacré n’est pas un budget des métiers (qui ensuite considéreraient l’informatique comme un fournisseur), mais le budget de l’informatique, qui reste maître de l’affecter selon sa propre analyse des priorités, que sa technicité protège des contrôles, et qui d’ailleurs se refuse à fournir des reportings permettant de contrôler le respect de ses engagements.

L’entreprise, pour sa part, considère l’informatique comme un centre de coût, non comme un centre d’investissement au service des métiers. La pression budgétaire est exercée de façon mécanique et aveugle par une " enveloppe informatique ".

Une méfiance se crée entre les informaticiens et l’entreprise. Les engagements sur les coûts et délais ne sont jamais tenus.

L’informatique se divise en baronnies jalouses de leur indépendance : cette division est la sanction du désordre, et elle est sans doute politiquement opportune envers les métiers dans la mesure où elle interdit la clarté des reportings.

Modèle M₂ : les processus

Le terme de " processus " désigne l’enchaînement des tâches réalisées pour remplir une fonction de l’entreprise. Ces tâches sont soit mentales (perception, jugement, décision) soit physiques (imprimer un billet, le donner à un client, réaliser une opération de maintenance), les tâches mentales préparant les tâches physiques (9). Le système d’information vise à assister l’utilisateur dans la réalisation des tâches mentales liées aux processus, dans la logique du travail assisté par ordinateur.

Exemple d’interface utilisateur (10)

Formaliser un processus conduit à l’équiper d’un " workflow ", c’est-à-dire d’une documentation explicite des tâches et de leurs relations :

préciser les interfaces nécessaires à chaque activité (on regroupe sur le même écran les plages de consultation et de saisie nécessaires à une activité, ce qui évite à l’utilisateur la connexion à d’autres applications, ainsi que la navigation dans des codes et touches de fonction diverses),

programmer les tables d’adressage permettant de router automatiquement les messages à l’issue d’une tâche (lorsque l’utilisateur tape sur la touche " valider " qui marque la fin de son travail, il n’a pas à chercher à qui envoyer le résultat).

Le délai de réalisation d’une tâche est surveillé par un " timer " qui prévient l’utilisateur en cas de dépassement, ou qui reroute le message vers un autre utilisateur (11).

Modéliser un processus, c’est décrire la succession des tâches qui concourent à une mission : 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é, le routages de ses messages vers les autres acteurs, les compteurs qui permettent au responsable du processus d’en contrôler la qualité.

La réalisation physique des tâches est décrite dans le modèle, puisqu’il la documente, mais elle nécessite une action qui ne peut être réalisée que par un être humain et échappe donc à l’ordinateur même si celui-ci aide sa préparation. Le workflow aide l’utilisateur sans se substituer à lui, même s’il automatise des tâches que l’on faisait auparavant à la main.

Organisation transverse

Les fonctions de la hiérarchie intermédiaire (transmission des consignes vers le bas et des rapports vers le haut) sont remplacées par le workflow, ses compteurs et l’édition semi-automatique des comptes rendus. Le nombre des niveaux hiérarchiques est donc réduit, la communication entre " base " et " sommet " devient plus facile. Par ailleurs, l’approche par les processus est " qualifiante ", car elle facilite l’acquisition de compétences nouvelles par les acteurs du processus (cf. l’annexe " Infotel "). La transparence, la diffusion de l’information suppriment l’opacité des procédures, la rétention, les mille abus que ces pratiques permettent.

Processus et objets

Pour décrire une interface 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 (12), 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.

Le modèle complet des processus est plus précis que les spécifications fonctionnelles fournies à l’informatique dans le modèle M₁. 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 les interfaces. Ces analogies et regroupements font 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 réduisent les coûts de maintenance et facilitent 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 bien maîtriser la documentation des versions successives, les mises à jour à introduire lors des évolutions, et facilite donc 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 " (13) 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 aussi que l’informatique soit capable de dominer l’articulation du monde objet avec les anciennes applications, dont l’adaptation à l’objet prendra plusieurs 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 un professionnalisme élevé des informaticiens.

Si cette nouvelle 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 une forme de coopération intéressante avec les utilisateurs. La plupart des informaticiens considèrent cette évolution avec intérêt.

Passage de M₁ à M₂

Le passage de M₁ à M₂ suppose un changement, tant pour le système d’information que pour l’organisation.

La responsabilité du système d’information passe de l’informatique, qui la détenait traditionnellement, aux métiers qui définissent son contenu fonctionnel en modélisant leurs processus.

L’informatique cesse d’être un centre de coûts et devient centre d’investissement au service des métiers. L’entreprise renonce à la notion d’ " enveloppe informatique ".

Le soutien aux utilisateurs, qui confine aujourd’hui trop souvent au bizutage, devient l’activité prioritaire de l’informatique. Les éléments essentiels du système d’infor-mation sont les processus, objets et composants, non plus les applications.

Ces changements de priorités ont des conséquences sur la façon dont les informaticiens perçoivent leur rôle.

Transition de l’organisation

L’approche par les processus fait passer l’entreprise du contrôle a priori (" le chef signe tout ") au contrôle a posteriori (" on agit d’abord, on fait le debriefing ensuite "), de l’opacité à la transparence (les retards deviennent visibles, qu’il s’agisse de la signature du décideur ou du travail de l’exécutant), de la rétention à la diffusion d’information.

Il ne faut pas sous-estimer les difficultés de cette évolution. Ceux qui pratiquent la rétention d’information, qui se protègent sous l’opacité des procédures, ne sont pas pour autant de mauvaises gens : ils se sont adaptés à l’entreprise et se protègent contre son comportement spontané. Passer de M₁ à M₂ suppose une traversée du désert pendant laquelle ils ne bénéficieront plus des protections que comporte M₁ et n’auront pas encore atteint l’équilibre que permet M₂.

L’exhortation morale serait ici dérisoire : cet effort n’est raisonnable que si chacun comprend qu’il peut y gagner personnellement. La communication, au sens médiatique du terme, est un épisode crucial de la migration. Il faut susciter l’espoir, éveiller l’intuition, avant de chercher à régler les problèmes techniques : ils se régleront souvent d’eux-mêmes (ou plutôt ils seront réglés dans la foulée) si l’espoir est présent.

Processus et système d’information

Dans M₁, la définition des applications reposait sur l’" expression de besoins ". Elle suppose une interprétation du travail à faire par les utilisateurs, mais cette interprétation n’est pas nécessairement explicite et reste donc abstraite. Rien ne garantit qu’elle permettra un bon contrôle du processus puisqu’elle n’est pas construite pour cette fin.

Si l’on considère les processus, on ne part pas de la question " quels sont les résultats qu’il me faut pour travailler ", mais de la question " comment est-ce que je travaille " : on découvre alors que tel processus ne boucle pas, ou n’est pas contrôlable, ou comporte une redondance (un même travail repris plusieurs fois), que certains points sont fragiles (lorsqu’une décision dépend d’un avis externe dont le délai n’est pas contrôlable). Structurer le processus rend visibles certains phénomènes: un acteur doit répondre à un message dans un délai donné, ou bien la décision lui échappera. C’en est fini des rétentions d’information et de signature qui constituaient autant de monnaies d’échange.

Système d’information et système informatique

Le système d’information est essentiellement sémantique et fonctionnel ; il est défini par le " modèle complet  " en langage UML, qui fait abstraction des moyens techniques. La maîtrise d’ouvrage doit se doter d’une expertise spécifique, fonctionnelle, garantissant la pertinence des demandes en regard des exigences du métier.

Le système informatique, par contre, organise ces moyens ; il choisit les plates-formes, langages, interfaces, architectures (centralisée, client serveur à deux ou trois niveaux), la localisation des traitements et mémoires, les niveaux de conservation des données, la couche de middleware et la gestion de la persistance. Il repose sur une expertise attentive à la diversité des outils du marché, aux innovations, à la pérennité des solutions.

Dans M₁, la frontière entre maîtrise d’ouvrage et maîtrise d’œuvre était confuse : certes la première était responsable de l’expression des besoins, et la seconde de la réalisation technique ; cependant la solidarité des applications, et donc du système d’information, se concrétisait au sein de l’informatique. La tentation était alors grande de confier à celle-ci davantage qu’une mission de maîtrise d’œuvre, et d’en faire le concepteur du système d’information se substituant aux utilisateurs pour définir leurs besoins.

Dans M₂, la séparation devient claire. A l’un la responsabilité du modèle complet, à l’autre celle de la solution technique. Cette répartition n’interdit pas le dialogue, au contraire elle ne nécessite : la maîtrise d’ouvrage doit s’intéresser aux solutions techniques qui étendent le domaine du possible fonctionnel, le maître d’œuvre doit avoir des idées sur ce qui est utile au plan fonctionnel et les exprimer. Cependant à ce dialogue succède la décision, et alors chacun doit prendre ses responsabilités propres, dans son domaine propre.

Processus et qualité

A partir du moment où la conception du système d’information de l’entreprise pivote autour de la notion de processus, on doit s’interroger sur la relation entre processus et qualité.

On peut voir la question sous deux angles : la qualité du processus ; l’apport de l’approche par les processus à la démarche qualité

Qualité du processus

Un processus, dans une entreprise, c’est d’abord un état de fait : l’enchaînement des tâches qui visent à produire de la valeur, qui sont déclenchées par un événement extérieur au processus (commande d’un client, décision d’un responsable) et qui se terminent par un événement extérieur au processus (livraison d’un produit, remise d’un rapport, etc.).

La notion de " livrable " est utile pour désigner les produits (au sens large : rapports écrits, logiciels, comptes rendus, produits physiques etc.) par lesquels s’achève un processus.

Un processus comporte des sous-processus dans la mesure où sa progression nécessite la production de plusieurs livrables : ainsi dans un projet complexe la livraison de divers blocs de logiciels scande la réalisation du produit.

L’approche du système d’information par les processus vise à rendre explicite la structure du processus, c’est-à-dire non seulement l’enchaînement des tâches mais aussi les délais impartis à chaque étape, l’identification des personnes auxquelles il faut envoyer un message lorsqu’une étape est terminée pour qu’elles puissent commencer leur travail, les délais ou autres indicateurs de qualité qu’il convient de mesurer, et les personnes responsables du contrôle du processus auxquelles ces indicateurs doivent être envoyés.

Il s’agit donc de documenter le processus, et de l’équiper des indications qui lui permettent de fonctionner automatiquement et d’être contrôlé :

• plan de l’enchaînement des tâches ;

• interfaces propres à la réalisation de chaque tâche, permettant d’accéder aux données et objets correspondants ;

- " timers " qui programment le délai maximum imparti à chaque tâche ;

• tables d’adressage qui indiquent l’adresse à laquelle le travail doit être transmis lorsque la tâche est achevée ; ces tables indiquent aussi les personnes à qui il faut envoyer la tâche si le timer a été dépassé ;

• compteurs et indicateurs permettant le contrôle du processus ;

• outil d’administration comportant l’enregistrement des adresses auxquelles il convient de faire parvenir les indicateurs.

Bien souvent, les processus " de facto " (qui n’ont pas été équipés en termes de système d’information) présentent des défauts que le système d’information doit corriger.

L’approche du système d’information par les processus permet de repérer les défauts des processus opérationnels et donc de les corriger.

Apport de l’approche par les processus à la démarche qualité

En outre le fonctionnement du processus engendre, si le processus a été convenablement doté d’outils de contrôle, une production d’information qui sert à contrôler la qualité du processus : mesure des délais, mesure des volumes de flux, mesures de qualité.

Ces indications peuvent servir au propriétaire du processus, qui définit alors les actions nécessaires pour redresser d’éventuelles mauvaises pratiques ou dérives en cours.

Le pilotage d’un processus se fait typiquement a posteriori. Les opérateurs disposent d’un devoir d’initiative et des droits correspondants, l’accent étant mis sur la fluidité et la rapidité du fonctionnement du processus. Cependant il faut que ce fonctionnement soit contrôlé pour éviter les dérives ; il le sera a posteriori, le propriétaire recevant les mesures des indicateurs et prenant les mesures nécessaires, soit en agissant sur les réglages du processus, soit en communiquant avec les acteurs pour leur indiquer les corrections à apporter à leurs pratiques.

Les indicateurs fournis par le fonctionnement du processus peuvent aussi servir à d’autres fins. Ils constituent une source d’information fine, en temps réel, qui peut être exploitée pour faire des comptes rendus destinés à divers types de responsables.

Ainsi, le processus de la relation clientèle peut fournir à une entreprise des indicateurs qui vont alimenter des comptes rendus définis :

- par région, à l’intention des directeurs régionaux, en fournissant des tableaux comparatifs entre les régions pour que chacun puisse se situer par rapport à la moyenne;

- par produit, à l’intention des chefs de ligne de produit, pour que chaque produit puisse être suivi dans son évolution.

Les comptes rendus utilisent une présentation synthétique de l’information (graphiques, petits tableaux de nombres) et privilégient la présentation sous forme de série chronologique pour faire apparaître les évolutions (qui souvent importent plus que les niveaux). Ils comportent des commentaires, qui paraphrasent le graphique ou lui apportent un complément explicatif. Enfin, ils comportent la citation d’exemples illustratifs précis " en texte intégral " (par exemple : lettre de réclamation particulièrement typique), choisis pour leur représentativité et permettant de donner à l’information un contenu concret et vivant.

La tâche de préparation et diffusion des comptes rendus, qui suppose l’élaboration de tables de diffusion et la gestion des droits d’accès à l’information, est une tâche de type éditorial qui requiert des compétences intellectuelles élevées.

Mise en œuvre pratique

Les considérations ci-dessus ne sont pas " théoriques " ni " à long terme ". Elles ont un rapport direct avec la réalité concrète des tâches quotidiennes et les urgences de l’entreprise.

Du point de vue applicatif

La conception habituelle du système d’information, qui se concentre sur " les applications ", est peu pratique et coûteuse. En effet lorsque l’on suit cette approche, la priorité n’est pas d’expliciter, documenter et maîtriser la succession logique et chronologique des tâches accomplies par les utilisateurs, mais de leur présenter des informations et outils de traitement censés leur faciliter la tâche. La mise au point des applications est scandée par le calendrier budgétaire, et suit une procédure plus formelle et administrative que rationnelle (14).

Rien n’empêche en principe de s’intéresser aux tâches accomplies par les utilisateurs lorsque l’on développe et maintient une application. Dans un monde idéal la remarque ci-dessus ne s’appliquerait pas (15). Cependant en pratique les applications sont conçues sans que l’on considère le processus que constitue la succession de ces tâches.

On s’efforce de supprimer les dysfonctionnements en perfectionnant, enrichissant, compliquant les applications, ou encore en achetant des progiciels sur le marché, censés apporter la solution de tous les problèmesn(16). Mais tout le monde est mécontent : les managers voient la persistance des dysfonctionnements malgré des efforts coûteux, les utilisateurs disent que l’informatique répond mal à leurs besoins, l’informatique pense faire son devoir et s’étonne qu’on lui fasse des reproches. En somme, chacun fait de son mieux et cela ne marche pas.

Du point de vue des processus

La réponse réside dans un changement de perspective :

Il faut demander au système d’information non de fournir des applications, mais d’équiper les processus de travail des utilisateurs.

C’est déjà possible avec les outils que fournit le marché. Mais rien n’est plus difficile que de changer de point de vue. Des problèmes qu’il serait parfaitement possible de traiter restent en plan, parce que :

• l’approche par les processus n’est pas familière,

• la compétence en la matière n’est pas assez répandue (17),

• cette approche conduit à modifier les méthodes de travail et suscite naturellement des réticences.

Exemples

Nous décrirons d’abord les apports d’un workflow et de la documentation partagée, puis nous donnerons un exemple opérationnel.

Nous verrons apparaître des fonctions nouvelles : animateur de forum, administrateur de processus, etc.

Gérer les dépenses

Il est facile d’utiliser Lotus Notes pour outiller le processus de traitement des demandes d’autorisation d’achat (DAA) et les demandes d’autorisation d’investissement (DAI), ainsi que pour la préparation du budget. Tous ces processus sont analogues: une demande est formulée par quelqu’un, elle doit être validée par le responsable hiérarchique, vérifiée par le contrôle de gestion, puis éventuellement soumise à des avis d’experts, enfin proposée à l’approbation d’un décideur ; des tableaux doivent être construits pour obtenir une vue synthétique des budgets demandés et accordés, des engagements de dépense etc.

Nous allons ici décrire en détail la façon dont les choses se passent, puis comment elles se passeraient si l’on utilisait un workflow.

Sur papier

Les dossiers sur papier sont établis selon des formats variables, les calculs sont parfois erronés, des allers retours avec le demandeur sont nécessaires pour obtenir une formulation compréhensible de la demande. Puis le dossier part dans le circuit des avis et signatures. Il peut rester longtemps sur un bureau, le traitement des dossiers papier se faisant selon le mode LIFO qui suscite des délais aléatoires. Il est difficile de savoir où en est un dossier. Certains font attendre longuement une signature qu’ils utilisent comme monnaie d’échange dans leurs négociations. Il arrive qu’un dossier se perde.

Les comptes résultant de ce flux d’affaires sont établis par des personnes qui se trouvent en fin de processus, en général au contrôle de gestion, et utilisent des tableurs. Des erreurs de saisie sont possibles, ainsi que des oublis matériels. Des vérifications et recoupements sont donc nécessaires. Ils consomment un temps de travail important, et ne suppriment pas toute incertitude.

Avec un Workflow

Les dossiers électroniques sont établis sur des masques de saisie qui comportent une aide en ligne, les calculs (totaux, taux de rentabilité, ratios, reports etc.) sont faits automatiquement, les données de référence (montant du budget disponible, nomenclatures etc.) sont fournies par des services contextuels. Le dossier comporte une indication sur l’urgence et le délai souhaité de traitement.

Lorsqu’une activité est terminée, le dossier est transmis automatiquement vers l’activité suivante, dont l’utilisateur est prévenu par une alerte sur son écran. La file d’attente des dossiers à traiter tient compte de leur urgence. L’utilisateur consulte le dossier, le traite, note ses avis et décisions, les authentifie par une signature électronique. Le délai de traitement du dossier par une activité est programmé ; si le dossier n’est pas traité dans les délais, il sera routé vers une autre personne. En cas de non traitement persistant, une alarme est émise vers le responsable du processus.

Les droits d’accès aux documents ou à des parties des documents sont gérés par l’administrateur du processus. Une personne autorisée peut, à tout moment, consulter le workflow pour savoir où en est un dossier, connaître les avis donnés, et intervenir si nécessaire.

Le processus articule plusieurs sous-processus (demandes d’expertise etc.), mais il boucle finalement sur la réponse à la demande initiale. La réponse à une demande budgétaire, c’est le montant accordé. La réponse à une demande d’achat, c’est la livraison du bien demandé, qui doit faire l’objet d’un message de la part du demandeur.

Le propriétaire du processus reçoit régulièrement des statistiques : affaires traitées classées par nature, histogramme des délais, montants concernés selon les nomenclatures comptables, incidents, anomalies, etc. Il a les moyens de repérer les activités qui dépassent souvent les délais, et peut soit allonger le délai qui leur est accordé, soit émettre un rappel à l’ordre.

Soulignons que la description ci-dessus ne relève pas de la science fiction, mais correspond à l’état de l’art d’aujourd’hui : dès qu’une entreprise utilise des PC en réseau, et si elle a installé sur ces PC une plate-forme comme Lotus Notes, elle peut utiliser le workflow.

Documentation

La documentation papier présente de nombreux défauts : on ne sait jamais si elle est à jour, elle s’égare le long des circuits de diffusion, les versions successives s’empilent souvent sans classement, il est difficile d’y faire des recherches.

La documentation électronique résidant sur un serveur accessible via le réseau est toujours consultable et à jour. Elle est dotée d’outils facilitant la recherche. Le document électronique peut être imprimé si l’on veut l’utiliser commodément.

La documentation électronique est complétée par un forum où les utilisateurs peuvent poser des questions et recevoir des réponses. Un animateur du forum veille à ce que les réponses soient fournies rapidement, et purge le forum des redondances ou banalités. Progressivement, le forum entoure la documentation d’un commentaire précieux (18).

Entreprise étendue

L’expression " entreprise étendue " désigne une entreprise dont le système d’information communique avec celui de ses clients, fournisseurs et partenaires.

Historiquement, les premières entreprises étendues se sont mises en place grâce à l’EDI entre grandes entreprises et fournisseurs réguliers (constructeurs automobiles et fabricants de pièce détachés) : il s’agissait de faire communiquer des applications informatiques.

L’Extranet permet de faire communiquer des processus, ce qui introduit une souplesse et une puissance nouvelles dans l’entreprise étendue.

Le processus essentiel est celui de la relation commerciale. Vers les partenaires et les fournisseurs se bouclent des sous-processus qui permettent de constituer l’offre.

Les apports d’une gestion du processus à la relation avec les fournisseurs sont connus (19) notamment dans le cas des pièces détachées.

Le fonctionnement d’un partenariat demande d’une part un bon raccordement des processus opérationnels, et la transparence du processus de répartition des coûts et recettes. Si le processus opérationnel ne marche pas, le partenariat est inopérant. Si le processus financier est opaque, le partenariat sera peu durable, car il sera pollué par la fraude ou le soupçon de fraude.

Autres exemples

Citons quelques autres dispositifs utiles et dont l’implantation ne pose aucun problème technique (mais sans doute des problèmes d’organisation).

1) Relevé des décisions prises lors d’une réunion, validé par la personne qui présidait cette réunion, accessible aux participants à la réunion, bouclant sur le compte rendu d’exécution des décisions.

2) Relation entre informatique et utilisateurs : équiper le processus de traitement des demandes des utilisateurs de sorte que l’informatique puisse gérer les files d’attente des travaux selon le degré d’urgence de la demande, et que l’utilisateur sache où en est le traitement de sa demande.

3) Mise à disposition des résultats statistiques (enquête sur la satisfaction des passagers, statistiques commerciales, statistiques commerciales etc.)

4) Traitement des réclamations : un workflow permettrait de contrôler le délai de traitement, d’établir automatiquement des statistiques etc.

5) Gestion des incidents : il est avantageux de mettre la documentation sur support électronique, et de la compléter par un relevé des incidents permettant d’établir des statistiques et de faire évoluer les procédures.

6) Le commissariat implique divers acteurs (Servair, escales, partenaires, réservation) dont les actions doivent être coordonnés pour éviter les gaspillages.

7) Indicateurs : un Datawarehouse permettrait de constituer et documenter les agrégats. Un workflow ferait circuler synthèses, graphiques et commentaires.

8) Régulation : il manque un processus assurant la réactivité de la chaîne de production à la disponibilité des ressources. Le cloisonnement des applications a conduit a sous-estimer le besoin de communication entre informations d’origines diverses.

9) Formation professionnelle : les stages devraient être complétés par du télé-enseignement (accès aux supports de cours, auto-évaluation, forum).

Conclusion

L’approche de l’entreprise par ses processus est cruciale pour le suivi de la qualité, pour la clarté du partage des responsabilités et des rôles, pour la maîtrise de la production de valeur, etc.

Cette approche ne porte tous ses fruits que si elle est articulée à la définition du système d’information, dont elle devient une étape essentielle.

Dès lors la maîtrise d’ouvrage devient responsable de la modélisation de ses processus, tâche pour laquelle le marché offre des outils efficaces. L’informatique est maître d’œuvre de la transcription de ces modèles métiers en programmes, de préférence en utilisant les langages orientés objet, et de la fourniture des services correspondants sur une architecture performante.

Il en résulte une reformulation, sur des bases solides et claires, du rôle du système d’information dans l’entreprise, ainsi que du rôle des acteurs impliqués dans la définition et l’exploitation de ce système.

L’itinéraire ainsi décrit ne relève pas de la science fiction, comme peuvent le croire ceux qui ne suivent pas l’actualité, mais de la réalité technique et professionnelle d’aujourd’hui. Les entreprises les plus performantes utilisent les procédés que nous avons décrits, qui sont devenus chez elles des banalités sur lesquelles on ne s’interroge plus.

Une entreprise reste libre, bien sûr, de refuser cet itinéraire si elle estime que les adaptations qu’il suppose sont trop lourdes, ont des conséquences " politiques " trop délicates et risquent de " poser trop de problèmes de personnes ". C’est un choix stratégique, et il peut se justifier : on juge parfois en médecine l’état du malade trop grave pour lui appliquer le traitement qui serait salutaire pour d’autres. Mais il importe que ce choix soit fait lucidement, avec une vue claire de ses implications.

Notes