L'ingénierie des processus

Ce texte appartient à la série L'ingénierie du système d'information.

Quittons le domaine de la sémantique pour pénétrer celui de l'action. Cette transition est logique mais non chronologique : dans la conception d'un SI la définition du langage et l'organisation de l'action s'entrelacent : tandis que le langage conditionne l'action effective, sa pertinence s'évalue selon son adéquation à l'action voulue.

Le mot « processus », qui signifie « processus de production », désigne la succession des tâches qui concourent à l'élaboration d'un produit – qu'il s'agisse d'un bien, d'un service ou d'un assemblage de biens et de services [11]. Ce mot émerge à l'horizon des systèmes d'information au début des années 90 [12] : il s'agit de maîtriser l'action productive en s'appuyant sur l'articulation du travail humain avec l'informatique et le réseau.

L'approche par les processus convient à des opérations répétitives ou périodiques qui tournent dans l'entreprise avec la régularité d'autant de moteurs. Elle ne convient pas aux opérations exceptionnelles ou peu fréquentes (comme une réorientation stratégique) : on ne peut donc pas dire « tout est processus dans l'entreprise », mais ils incorporent l'essentiel de son activité courante.

L'informatisation des processus s'appuie sur les acquis techniques de l'informatique (base de données, moniteur transactionnel, langages à objets, réseau) associés à une modélisation à la fois dynamique et organique du travail productif : dynamique par la définition de l'ordre chronologique des tâches et de la cadence de leur exécution, organique par la coopération des compétences nécessaires à l'élaboration du produit.

*     *

L'ingénierie des processus s'amorce par la question « quels sont nos produits ? » et il n'est pas toujours facile de répondre à cette question : beaucoup d'entreprises, ou d'entités de l'entreprise, travaillent en effet sans que leur produit ait été clairement défini. Que produit, par exemple, une direction des achats ? Que produit l'état-major des armées ?

Certes ces entités travaillent et produisent quelque chose, mais on ne s'est jamais soucié d'expliciter la nature exacte de cette « chose ». La question « quels sont nos produits » est salubre [13] car on peut, une fois le produit défini, lui associer des critères de qualité, puis associer à sa production des critères d'efficacité.

Tout processus est déclenché par un événement venant de l'extérieur (réception d'une commande, d'une lettre de réclamation, constat de la baisse d'un stock etc.) et se conclut par une réponse vers l'extérieur (respectivement : livraison et facturation, réparation et courrier, ajout au stock et inscription à l'inventaire).

Schéma d'un processus

Les processus, étant aussi anciens que la production elle-même, existent depuis le néolithique : ce qui est récent, c'est leur modélisation et leur informatisation. La modélisation, préalable nécessaire à l'informatisation, met en évidence leurs éventuels défauts et incite à les corriger.

Voici quelques-uns des défauts que l'on peut rencontrer dans un processus comme celui qui va de la réception d'une commande à la livraison et la facturation d'un produit :
- erreur d'adressage : il faudra réorienter le dossier, d'où perte de temps et travail superflu ;
- bras mort (conséquence possible de l'erreur d'adressage) : le dossier reste bloqué dans un service qui n'aurait pas dû le recevoir ;
- « perte dans les sables » (conséquence possible du bras mort) : le délai décent ayant été dépassé, le dossier est classé sans suite ;
- redondance : le même dossier a été envoyé à deux services différents qui font un travail en double ;
- LIFO (last in, first out) : les dossiers étant empilés, le dernier reçu est traité en premier et le plus ancien est soumis à un délai aléatoire.

Ces défauts sont certes grossiers mais étonnamment fréquents : l'expérience montre que la modélisation d'un processus qui n'avait jamais été modélisé fait économiser de 20 à 30 % du coût de production et qu'elle procure aussi une amélioration de la qualité du produit.

Le modèle d'un processus indique les éléments suivants :
- l'événement extérieur au processus et qui le déclenche (réception d'une commande, d'une lettre de réclamation etc.) ;
- la suite des activités qui constituent le processus en précisant les pré- et post-conditions du passage d'une activité à la suivante ;
- les sous-processus éventuellement nécessaires à une activité ;
- les relations entre chaque activité et la plate-forme du SI (données saisies, données consultées, traitements lancés : l'IHM fournit à chaque activité les plages de saisie et de consultation nécessaires ainsi que des boutons pour lancer les traitements) : les activités « font la ronde » autour de la plate-forme informatique, qui assure la cohérence des données pendant le processus ;
- les éventuelles communications interpersonnelles entre acteurs du processus (messages, échanges de documents) ;
- les indicateurs de volume (charge des ressources, productivité), de coût et de qualité (respect des délais, satisfaction du client et contrôle de bonne fin lors du « bouclage » du processus) qui permettent à un administrateur de piloter le processus.

Les droits de lecture, écriture et traitement de chaque agent sont définis par sa liste d'habilitations.

L'itinéraire des dossiers est balisé par une table d'adressage : l'agent qui a terminé son travail clique sur une case et le dossier est automatiquement acheminé vers l'agent suivant. Chaque activité est munie d'une horloge qui mesure le temps écoulé depuis l'arrivée du dossier, des messages d'alerte sont éventuellement émis, le dossier peut être transféré automatiquement vers un autre agent si le délai jugé normal est dépassé.

Gestion des habilitations

La sécurité du SI exige que chaque agent puisse disposer, dès qu'il a authentifié son identité par la saisie d'un mot de passe, de tous les droits nécessaires à son travail et d'eux seuls.

La technique qui consiste à tenir à jour pour chaque application la liste des habilitations de chaque agent est lourde et onéreuse : dans l'attente de la mise à jour l'agent ne peut pas se mettre au travail.

L'annuaire électronique est souvent mis en place d'abord pour remplacer l'annuaire téléphonique sur papier. Si on l'enrichit du profil des agents (service auquel l'agent est affecté, fonction, projets auxquels il participe etc.), cet annuaire devient un référentiel des agents que l'on peut associer à une table d'habilitation indiquant les droits qui correspondent à chaque profil. Il suffit, après un recrutement ou une mutation, de mettre à jour le profil d'un agent pour qu'il dispose de ses droits.

Le référentiel des agents est l'un des piliers porteurs de l'architecture d'un SI.

La cellule élémentaire du processus, c'est ce que nous avons nommé « l'activité », suite des opérations que réalise un même agent. Il est utile de la regarder de près :

L'activité

Chargée de réaliser une tâche au sein du processus, l'activité met en relation l'être humain organisé (EHO) et l'automate programmable doué d'ubiquité (APU) à travers l'interface homme-machine (IHM) qui fonctionne comme une synapse entre les deux parties du système. Chacun des deux acteurs est complémentaire de l'autre : l'APU classe, trie, calcule et traite ; l'EHO écoute, comprend, explique, conçoit et décide. Enfin, alors que la centralité du SI au cœur du processus garantit la cohérence des données dans l'APU, la communication interpersonnelle des EHO favorise la cohésion du discernement et de la décision.

La répartition du travail entre l'APU et l'EHO obéit à une fine dialectique : que l'on pense à la relation entre le superviseur d'une centrale nucléaire et le SI de cette centrale, ou entre le pilote humain et le pilote automatique d'un avion de ligne. Dans chaque cas il ne faut automatiser ni trop ni trop peu, et en outre l'automatisation doit être judicieuse.

La dialectique de l'EHO et de l'APU est, dans chaque activité, le reflet de l'autre dialectique qui, au niveau de l'entreprise entière, articule deux personnes morales : la maîtrise d'ouvrage (MOA) de chaque métier et la maîtrise d'œuvre (MOE) de l'informatique.

« Maîtrise d'ouvrage » et « maîtrise d'œuvre »

Ces deux expressions sont empruntées au secteur du BTP : le maître d'ouvrage est celui qui fait construire une maison, le maître d'œuvre est celui qui en organise la construction. La comparaison avec le BTP ne suffit cependant pas pour éclairer le cas du SI.

Les mots « ouvrage » et « œuvre », aujourd'hui à peu près synonymes, ont étymologiquement un sens différent : l'ouvrage est le fait de produire (« avoir du cœur à l'ouvrage ») tandis que l'œuvre est un produit. Toute entité de l'entreprise est ainsi à la fois MOA (business owner) de ses processus et MOE de ses produits.

Le service informatique, en particulier, est en général le produit de la DSI qui en est la MOE. Il est fourni aux autres entités, MOA des processus que le SI outille. La relation entre la MOA et la MOE doit être coopérative plutôt que contractuelle : dans les étapes dont l'une des deux a la responsabilité, l'autre doit être présente.

Leur dialectique connaît des épisodes conflictuels comme il en existe entre le commercial et la production, la R&D et le marketing etc. De telles dialectiques sont le ressort de l'entreprise et il revient au DG de les arbitrer. Certains, préférant « ne voir qu'une seule tête », placent à la DSI l'expertise sur les métiers ou au contraire externalisent l'informatique. C'est prendre le risque de briser un des ressorts de l'entreprise.

En cas d'échec enfin, la MOA doit être tenue pour responsable : il ne faut jamais accepter qu'elle dise « c'est la faute de l'informatique ».

Au plan technique, le modèle est la première étape de la réalisation du SI, tout comme le plan d'un immeuble est la première étape de sa construction.

Au plan intellectuel, la modélisation permet à l'entreprise de partager une représentation de son propre fonctionnement : les processus sont alors élucidés. Des animations audiovisuelles, accompagnées d'outils d'autoformation, facilitent la compréhension du modèle tant par les dirigeants que par les agents. Un modèle bien fait, convenablement approprié par les agents, permet à chacun de se représenter le processus auquel il contribue, de comprendre son propre rôle ainsi que celui des autres acteurs.

On néglige parfois cette finalité intellectuelle parce qu'on ne voit que l'aspect technique du modèle, mais cette négligence se paie par des incompréhensions et des conflits lors de la mise en œuvre du SI.

Démarche de modélisation

Pour pouvoir informatiser un processus il faut disposer d'un langage de modélisation qui permette à chacune des parties concernées de s'exprimer pleinement et qui fournisse à l'informatique des spécifications exactes : c'est le but d'UML [14] (Unified Modeling Language).

La réalisation du modèle doit procéder par enrichissement progressif, sans bousculer l'ordre des étapes [15] : il ne faut pas se lancer dans la modélisation proprement dite sans disposer de l'expression de besoin, ni documenter les cas d'utilisation avant d'avoir produit le diagramme d'activité etc. Chaque étape aboutit à un « livrable » qui doit être validé par les parties prenantes pour éviter l'effet de tunnel dans la modélisation [16], et cette validation conditionne le passage à l'étape suivante.

Il faut associer plusieurs techniques informelles et formelles pour saisir les diverses facettes du problème sans le dénaturer, puis pour le détailler dans un modèle que l'on pourra ensuite préciser et modifier. Cela permet de s'adresser à des interlocuteurs ayant des intuitions de forme différente.

Il se peut que l'on découvre lors d'une étape des contraintes qui obligent à réviser le résultat des étapes antérieures. Si la documentation est correcte, si les outils facilitent la cohérence entre les étapes, si le modèle est modulaire, le travail nécessaire à ces révisions restera raisonnable.

Une fois l'expression des besoins formulée, il convient d'établir le dictionnaire du domaine considéré ; puis une approche systémique en fournit une vue globale. La définition des modèles conceptuels, enrichie par la prise en compte des règles de gestion, accompagne la modélisation. Enfin, les cas d'utilisation détaillent ce que le modèle doit effectuer au sein du système global.

Tout comme une base de données le modèle est un être informatique que personne ne peut percevoir dans son entier mais seulement à travers des « vues » adaptées chacune à une catégorie d'interlocuteurs et qui en révèlent un aspect particulier. Ces vues sont fournies par des diagrammes : nous présenterons les principaux d'entre eux.

L'expression de besoin

Il faut d'abord savoir ce que l'entreprise veut faire, ce qu'elle veut produire et comment elle veut le produire. Cette « ingénierie des besoins » (requirement engineering) doit fournir une « expression de besoin » pertinente, sobre et cohérente avec le reste de l'entreprise et du SI.

L'expression de besoins est un document court (quelques pages) en langage naturel. Ce document est crucial car tout projet se découpe en travaux parcellaires durant lesquels on risque, ayant perdu conscience du but visé, de ne pas savoir faire des arbitrages de bon sens : il sera alors utile de revenir à l'expression de besoins, référence fondamentale pendant toute la durée du projet.

La demande n'est pas le besoin, elle n'en est qu'un symptôme. Il faut donc, pour diagnostiquer le besoin, interpréter ce que demandent les dirigeants et les utilisateurs.

Souvent en effet leur demande spontanée n'est pas pertinente : « je veux un bouton sur l'écran pour déclencher tel traitement », « il nous faut un serveur Unix pour fidéliser les clients » etc.

On doit mettre de telles demandes de côté pour poser la question « que voulez-vous faire » ou « à quel problème voulez-vous répondre ? ». Cette question s'adresse aux « métiers » de l'entreprise, maîtrises d'ouvrage.

Chaque métier est un être organique et donc complexe : les agents opérationnels, utilisateurs du SI, sont les plus nombreux sur le terrain où ils sont encadrés par des managers opérationnels ; à la DG, le directeur est un stratège qui oriente le métier, entouré d'experts et concepteurs qui le conseillent et l'assistent. Cette pyramide se découpe encore, ainsi que les missions et processus du métier, en sous-directions et services que le stratège coordonne. Chaque métier est ainsi comme une entreprise dans l'entreprise, et comme elle il fédère des spécialités mutuellement jalouses : le stratège doit arbitrer entre des services qui rivalisent pour le partage des ressources.

Il faut faire émerger de cette complexité une expression de besoin claire, résultant d'un consensus autour des priorités : la produire est une des tâches de la « maîtrise d'ouvrage déléguée ».

Beaucoup de projets souffrent de l'imprécision ou de la versatilité de l'expression de besoin ainsi que de conflits « politiques ». C'est pourquoi il faut s'assurer du consensus des dirigeants concernés ainsi que de l'authenticité de la validation par le stratège.

La maîtrise d'ouvrage déléguée (MOAD)

La décision comme la responsabilité appartiennent, en ce qui concerne le SI, au dirigeant (ou « stratège ») de l'entité considérée (DG, directeur, chef de service etc.).

Il délègue une mission d'expertise à une MOAD, personne morale placée sous son autorité qui lui soumet, puis met en œuvre, les décisions concernant les expressions de besoin, la modélisation, le pilotage des projets, le déploiement des solutions, la formation des utilisateurs et la dissémination des bonnes pratiques.

La MOAD doit savoir parler trois langages : celui du stratège, celui de la MOE et celui des utilisateurs, afin de les aider à communiquer et à se comprendre. Elle doit notamment être pour l'informatique un client compétent.

D'une entreprise à l'autre le vocabulaire varie mais quelle que soit sa dénomination la présence d'une MOAD qualifiée dans chacun des métiers de l'entreprise conditionne la qualité du SI.

La « gouvernance » du SI culmine dans la personne du DG, assisté par une MOAD qui assure en outre l'animation et la coordination des MOAD des « métiers ». L'expérience montre que l'implication personnelle du DG est condition nécessaire de la qualité d'un SI.

La rédaction d'une expression de besoin passe par plusieurs étapes :
- recueil de la demande spontanée auprès de personnes qui représentent les utilisateurs (« experts métier ») et des dirigeants ;
- classement des demandes par ordre de priorité, sélection de celles qui sont absolument nécessaires ;
- confrontation à l'état de l'art des SI et aux exigences de la cohérence ;
- recueil des avis des dirigeants, obtention d'un consensus ;
- validation par le directeur, stratège du métier.

Pour que la validation soit authentique (c'est-à-dire pour que le stratège se sente vraiment engagé par sa signature), il faut que l'expression de besoin lui présente clairement le but visé, la façon dont on envisage de l'atteindre, et pourquoi cette façon-là est jugée préférable à d'autres éventuellement possibles.

Dictionnaire

Le dictionnaire rassemble les définitions des termes relatifs au système considéré. On doit être tolérant lors du recueil de la terminologie du métier et accepter de noter les homonymes et synonymes qui coexistent dans l'organisation. La construction du modèle apportera une réduction terminologique, en n'associant plus qu'un nom et un seul à une même chose ou à un même concept : l'amélioration du vocabulaire est l'un des apports de la modélisation.

Approche systémique

Un schéma général, validé par les acteurs, met en évidence les structures de l'entreprise impliquées, leurs responsabilités et leur mode de coopération en utilisant la notion de « flot d'information » dans UML.

La notion de « contrainte » dans UML permet de modéliser des règles de gestion qui autorisent, provoquent ou empêchent le déroulement d'un processus (« une direction départementale ne doit pas comporter plus de dix agences », « un client ne peut commander via le Web que s'il a été enregistré au préalable », « un employé marié ne doit être muté qu'en dernier recours » etc.)

Diagramme d'activité

Décrire un processus, c'est décrire l'événement qui le déclenche, les étapes (ou activités par lesquelles il doit passer, les ressources qu'il doit consommer et l'événement final auquel il doit aboutir. Ces informations sont rassemblées et documentées dans le diagramme d'activité qui montre la succession des activités, les messages qu'elles échangent, les éventuels sous-processus et les livrables intermédiaires que ceux-ci fournissent.

Des diverses vues sur le modèle, le diagramme d'activité est la plus lisible et la plus facilement compréhensible pour les personnes qui ne participent pas à son élaboration mais doivent le valider.

Diagramme de cas d'utilisation

L'étape suivante consiste à décrire les cas d'utilisation, chaque activité en comportant un ou plusieurs. Un cas d'utilisation regroupe des opérations que l'acteur exécute et qui forment un ensemble cohérent : recevoir des messages, consulter des données ou du texte, saisir des données ou du texte, lancer des traitements, envoyer des messages.

On a défini le cas d'utilisation lorsque (1) on l'a nommé et désigné par sa finalité au sein de l'activité, (2) on a décrit son contenu en définissant les données consultées, saisies ou traitées, la nature des traitements, les messages échangés, (3) on a identifié les composants qu'il met en oeuvre au sein du système informatique.

Il arrive que des cas d'utilisation divers comportent des éléments semblables, ou qu'ils soient des cas particuliers de cas d'utilisation plus généraux : on définit alors une hiérarchie de cas d'utilisation qui, par abstraction, simplifie le modèle : c'est le diagramme des cas d'utilisation.

Pour valider un cas d'utilisation on présente aux utilisateurs futurs une succession d'écrans simulant l'exécution du processus.

Diagramme de classe

Dans les langages à objet, chacune des populations que le SI décrit (clients, produits etc.) est une « classe » et la représentation de chacun des individus est un « objet ». Chaque objet contient les attributs qui décrivent l'individu ainsi que des fonctions (« méthodes ») qui agissent sur ces attributs, notamment les interfaces qui permettent de les tenir à jour.

Le diagramme de classe indique les relations entre classes : l'emboîtage conceptuel des classes filles dans les classes mères est nommé « héritage » (les classes « particulier » et « entreprises » ont les attributs de la classe « client », plus d'autres qui leur sont propres), la relation organique entre deux classes est nommée « agrégation » (la classe « adresse » est agrégée à la classe « client »).

Diagramme de classe

Le diagramme de classe exprime sous une forme commode pour l'informaticien la structure conceptuelle des populations que le processus considère : il est bien adapté à la programmation dans un langage à objets. Cependant ce diagramme sera, contrairement au diagramme d'activité, d'une lecture difficile pour les autres parties concernées.

Diagramme de séquence

Le diagramme de séquence représente la succession chronologique des opérations réalisées par un agent lors d'une activité : saisir une donnée, consulter une donnée, lancer un traitement ; il indique les objets que l'agent va manipuler et les opérations qui font passer d'un objet à l'autre.

Diagramme d'état

Le diagramme d'état représente la façon dont évoluent durant le processus les objets appartenant à une même classe (« cycle de vie »). La modélisation du cycle de vie est essentielle pour représenter et mettre en forme la dynamique du système avec les pré-conditions et post-conditions vérifiant les unes qu'une activité peut commencer, les autres qu'elle est terminée.

Modélisation et évaluation du coût

L'évaluation du coût du projet progresse à mesure que sa définition se précise.

1) l'expression de besoin n'est accompagnée d'aucune évaluation ; on peut tout au plus lui associer une indication qualitative comme « petit projet », « projet moyen », « gros » ou « très gros » ;

2) si l'expression de besoins passe le cap de la sélection, une « étude préalable » est lancée. La maîtrise d'œuvre fournit une esquisse de solution et une évaluation du coût : la marge d'erreur est alors de l'ordre de 50 % par rapport au coût réel [17]. Quoique imprécise, cette estimation sert à évaluer la rentabilité du projet (à ce stade l'évaluation des gains que l'on peut en attendre est tout aussi imprécise) ;

3) si l'étude préalable est convaincante, l'entreprise lance la modélisation et elle permet de resserrer l'évaluation ;

4) si l'entreprise décide de lancer le projet au vu du modèle, la maîtrise d'œuvre consulte des entreprises dont les réponses permettent de la préciser encore ;

5) il arrive enfin souvent qu'on la révise lors de la réalisation : on ne connaîtra vraiment le coût qu'à la fin du projet.

Un « modèle de coût » étalonné et condensant l'expérience des informaticiens ne supprime pas l'incertitude, mais il peut la réduire et améliorer d'autant la qualité des décisions relatives au lancement des projets. Lorsque les décisions sont prises sur la base d'une évaluation imprécise, cette imprécision doit être considérée comme l'un des risques associés au projet.

L'informatique de communication

Outre l'informatisation des processus, le SI offre aux agents des outils qui, permettant une communication informelle, complètent utilement le formalisme des processus. Il ne s'agit plus de traiter des données : les ordinateurs sont utilisés pour envoyer du courrier (messagerie), partager les agendas, diffuser la documentation, etc.

L'informatique de communication utilise des données structurées (dans le carnet d'adresse de la messagerie, dans les masques de saisie ou de consultation de la documentation électronique), mais elles ne représentent qu'une faible partie du volume total de l'information manipulée. Les textes envoyés par messagerie, ou consultables sur l'Internet, écrits en langage naturel, utilisent sa souplesse et sa puissance de communication.

Messagerie

La messagerie permet une communication asynchrone en langage naturel. Elle comporte des pièges : l'expérience montre qu'elle est un amplificateur de l'agressivité et que de mauvais usages risquent d'annuler son apport à l'entreprise.

Il est utile d'avoir un administrateur de la messagerie, personne morale chargée de superviser le service. Il dispose d'outils qui, sans qu'il ait à ouvrir les messages, lui permettent de détecter les mauvaises pratiques et de conseiller les utilisateurs : abus des listes de diffusion, boîtes aux lettres jamais ouvertes, émission de messages trop longs, réception de messages trop nombreux etc.

La messagerie sert utilement de poisson pilote au transfert de fichiers et elle peut servir aussi de plate-forme de workflow pour des processus simples.

Annuaire électronique

Les adresses des utilisateurs de la messagerie sont stockées dans un annuaire qui peut être enrichi et contenir également le numéro de téléphone, l'adresse postale, la photographie, la description des fonctions etc. de la personne. On peut introduire dans l'annuaire assez d'informations pour alimenter le profil de la personne : l'annuaire joue alors, nous l'avons vu, un rôle central dans le SI en facilitant la gestion des habilitations.

Agenda partagé

L'agenda électronique permet aux personnes d'organiser leur emploi du temps ; couplé à un ordinateur de poche, il remplace avantageusement l'agenda papier. Mis en réseau, il facilite l'organisation des réunions et la prise de rendez-vous par une assistante ou un collègue.

Documentation électronique

La documentation électronique, mise à la disposition des agents sur l'Intranet, remplace avantageusement la documentation sur papier : elle permet de mettre à disposition sans délai des textes à jour, elle évite les oublis de la diffusion sur papier ainsi que l'empilage des notes apportant des corrections aux versions antérieures, elle compense dans une certaine mesure l'inégalité qui existe entre les divers établissements de l'entreprise (directions régionales, direction générale) en ce qui concerne l'accès à l'information. Le moteur de recherche aide à trouver facilement la réponse à une question, les liens hypertexte permettent de relier entre eux les documents concernant des thèmes voisins.

Dissémination sélective

La dissémination sélective vise à fournir à chacun la documentation dont il a besoin et uniquement celle-là. L'une des solutions les moins coûteuses consiste, en partant d'une démarche de marketing interne visant à classifier les agents selon leurs besoins, à diffuser des newsletters contenant des liens hypertexte vers les documents dont la consultation est utile et les associant à un bref commentaire. Elles font connaître les nouveautés de la documentation électronique, elles en publient des revues thématiques etc.

Rédaction coopérative

Lorsque plusieurs personnes concourent à la production d'un même document la gestion des versions successives est toujours délicate. Il faut éviter la collision entre des corrections portant sur un même paragraphe (« concurrence »), les incohérences résultant de révisions mal coordonnées, les ruptures de ton et de forme résultant de la diversité des rédacteurs.

Forum

Le forum permet aux agents de poser des questions à la cantonade lorsque la documentation est incomplète ou ambiguë, et aux experts d'apporter des réponses qui entoureront la documentation d'un halo de commentaires.

Un forum doit être animé : l'animateur purge les messages obsolètes (ou non pertinents en regard du thème du forum), introduit dans le corps de la documentation le contenu des messages importants et sollicite les experts pour que toute question reçoive une réponse dans un délai décent.

Exploitation d'enquête

Pour réaliser une enquête interne à l'entreprise (par exemple, une enquête de satisfaction sur les apports du SI à l'activité professionnelle), on peut construire un échantillon par tri dans l'annuaire puis envoyer aux personnes enquêtées un message contenant un lien vers le formulaire stocké sur un serveur Web. On peut ensuite programmer des relances vers les personnes qui n'ont pas répondu.

Des programmes produisent automatiquement des tris à plats, tris croisés et représentations graphiques qui facilitent l'interprétation des résultats.

Accès externe au SI

Les cadres, les commerciaux en déplacement chez les clients, les partenaires, veulent pouvoir accéder au SI de l'entreprise. Cela pose d'évidentes questions de sécurité auxquelles on peut répondre par un contrôle du mot de passe et par une gestion particulièrement stricte des habilitations.

Plateau téléphonique

Des plateaux téléphoniques sont utilisés pour la communication interne (notamment le dépannage des utilisateurs du SI) et ils sont aussi une composante importante de la relation transcanal avec les clients. La pertinence de l'interface fournie aux opérateurs du plateau téléphonique est l'un des enjeux importants du SI.

Beaucoup d'entreprises croient faire une économie en externalisant les plateaux
téléphoniques. Elles perdent ainsi les informations et l'expérience précieuses que l'on y acquiert.

Dans les entreprises efficaces, un directeur ne pense pas déchoir en passant quelques jours au plateau téléphonique et en coiffant le micro-casque pour répondre lui-même aux clients et aux utilisateurs du SI.

À suivre :

Le contrôle

La stratégie

Les méthodes

Le SI et le système informatique

---

[11] S'il s'agit d'un produit intermédiaire, on dira que c'est un « sous-processus » du processus qui conduit au produit final.

[12] Peter G. W. Keen, Shaping the Future : Business Design Through Information Technology, Harvard Business School Press, 1991.

[13] Dans le cas particulier de la direction des achats, voici la réponse : elle produit (a) des contrats avec les fournisseurs, (b) le suivi de l'exécution de ces contrats.

[14] Grady Booch, Ivar Jacobson, James Rumbaugh, Jim Rumbaugh, The Unified Modeling Language User Guide, Addison-Wesley 1998 ; Pascal Roques et Franck Vallée, UML en action, Eyrolles 2003.

[15] « L'optimisation prématurée est la racine de tous les maux » (Donald Knuth, 1974).

[16] L'effet de tunnel doit être évité également dans la réalisation : si l'automatisation du processus requiert un travail lourd (et donc long) il faut définir des « livrables exploitables », produits intermédiaires que l'on pourra mettre en exploitation dans les mains des utilisateurs.

[17] Si l'on estime à ce stade le coût à 10 millions d'euros, le coût final sera vraisemblablement dans la fourchette de 5 à 20 millions.