Modélisation des processus
La modélisation des processus est la représentation graphique de la façon dont un travail se déroule: la suite des activités, les rôles qui les tiennent et les décisions qui en aiguillent le cours, du déclencheur au résultat. Une même réalité se dessine en logigramme, en BPMN, en diagramme d'activités UML ou en schéma IDEF/IGOE, quatre notations qui expriment le même petit ensemble d'éléments et se départagent sur le public, le domaine, le degré de formalité et l'usage. Régler le niveau de détail pèse autant que choisir la notation.
Objectif
Un modèle de processus est un modèle graphique normalisé de la séquence des activités par lesquelles un travail est réalisé. Dans sa forme la plus simple, un événement le déclenche, une suite d'activités s'enchaîne, un résultat le termine; une forme plus riche y ajoute les données et les matières que les activités consomment et produisent. Le livrable est un diagramme, le plus souvent accompagné d'un texte qui le documente.
La technique sert à mettre une organisation d'accord sur ce qu'elle fait. Elle décrit le périmètre d'une solution en montrant les activités et les acteurs qu'elle touche, elle donne d'un travail une lecture qu'un observateur extérieur suit sans connaître le métier, et elle fournit la base sans laquelle l'analyse de processus n'a rien à mesurer. On dresse un modèle de l'état actuel, l'as-is, pour bâtir une compréhension partagée de ce qui se fait aujourd'hui et un modèle de l'état visé, le to-be, pour fixer ce que l'on veut atteindre. Les deux emploient les mêmes éléments et la même notation, seuls diffèrent le moment du projet et la question posée.
Usage
Quand l'utiliser
- Comprendre un processus avant de le changer: donner à toutes les parties une même image de ce qui se passe réellement.
- Cadrer le périmètre d'une solution: montrer les activités et les acteurs concernés avant d'éliciter les exigences.
- Aligner les parties prenantes: obtenir un accord explicite sur l'état actuel ou sur l'état visé.
- Préparer une amélioration de processus: la mise à plat est le préalable de toute mesure et de toute comparaison.
- Alimenter une automatisation: donner à un moteur d'exécution le modèle formel dont il a besoin.
Quand ne pas l'utiliser
- La complexité tient à la logique de décision: traiter les règles à part avec la modélisation des décisions.
- La question porte sur la structure des données: préférer un modèle de données ou un diagramme de flux de données.
- Processus très mouvant et jetable: un modèle entretenu sera périmé avant d'être lu, s'en tenir à un texte court ou à une liste de contrôle.
Le critère de choix
Puisque les quatre notations expriment le même vocabulaire, ce qu'elles permettent de dire ne les départage pas: le choix se joue sur le public que le modèle doit atteindre et sur l'usage qu'on en fera. Quatre critères le tranchent, et un seul suffit souvent.
Le public d'abord: un lecteur non technique suit un logigramme sans effort, là où une notation riche le perd. Le domaine ensuite: un processus métier appelle une notation d'entreprise, un processus qui vit dans un logiciel appelle une notation de conception. La formalité exigée: un alignement rapide se contente d'une esquisse, un modèle qui franchit des frontières d'organisation ou qui pilote une machine réclame une notation précise et sans ambiguïté. L'usage enfin: un modèle destiné à la discussion, un modèle destiné à l'exécution et un modèle destiné à cadrer un périmètre ne demandent pas les mêmes moyens.
Quatre notations couvrent la quasi-totalité des cas, chacune avec ses propres symboles, ses règles de lecture et ses exemples travaillés. Le logigramme est la notation la plus simple et la plus universellement comprise, celle vers laquelle on va d'abord pour une image partagée et peu cérémonieuse. Le BPMN est la langue standard, lisible par le métier comme par la technique, capable de décrire des processus internes ou collaboratifs entre organisations et d'alimenter une automatisation. Le diagramme d'activités UML appartient au domaine du logiciel et sert quand le processus s'inscrit dans une conception déjà exprimée en UML. Le schéma IDEF/IGOE établit le périmètre et les frontières, ce qui entre, ce qui guide le travail, ce qui en sort et ce qui l'outille, avant que l'on déroule la séquence.
Vous trouverez plus de détails dans notre tutoriel BPMN.
| Votre intention et votre public | Notation | Pourquoi elle convient |
|---|---|---|
| Obtenir une image partagée et peu formelle, pour un public non technique, et s'accorder sur ce qu'est le processus. | Logigramme | La notation la plus simple et la plus lue; les couloirs y ajoutent couramment les rôles. |
| Un modèle précis, lisible par le métier comme par la technique, éventuellement inter-organisationnel ou destiné à l'exécution. | BPMN | Langue standard, riche en événements et en points de décision; pools et couloirs séparent les acteurs; elle peut alimenter un moteur d'automatisation. |
| Un processus situé dans une conception logicielle déjà décrite en UML. | Diagramme d'activités UML | Diagramme UML de réalisation de cas d'utilisation; partitions pour la responsabilité, synchronisation du parallélisme. |
| Établir le périmètre et les frontières d'un processus avant d'en détailler la séquence. | IDEF / IGOE | Cadre les entrées, les guides, les sorties et les moyens; conçu pour le contour, non pour le flux détaillé. |
Les niveaux de représentation
Le choix de la notation engage d'ailleurs moins qu'il n'y paraît. Un même processus se dessine à plusieurs niveaux de détail, chacun servant un point de vue différent, et régler ce niveau pèse autant que choisir la notation. C'est souvent là que le modèle rate sa cible: un niveau trop élevé cache les problèmes opérationnels, un niveau trop fin devient illisible et personne ne peut plus le valider.
| Niveau | Ce qu'on y voit | À quoi il sert |
|---|---|---|
| Contexte / entreprise | Le processus dans son ensemble et ses liens avec les processus voisins, sans le détail des étapes. | Une compréhension générale et le positionnement du processus dans l'organisation. |
| Opérationnel | Les activités au grain fin, les exceptions et les chemins alternatifs. | Analyser le travail réel, repérer les points de friction, préparer une amélioration. |
| Système | La séquence formalisée jusqu'au niveau où une machine peut la simuler ou l'exécuter. | Servir de base à une simulation ou à une automatisation. |
Un vocabulaire commun en quatre alphabets
Si le choix engage peu, c'est que les notations diffèrent par leurs symboles, non par ce qu'elles décrivent. Le BABOK énumère les éléments que chacune exprime, et ce sont toujours les mêmes. Une activité est une étape du processus, qui peut se décomposer en un sous-processus. Un événement est une occurrence sans durée qui déclenche, interrompt ou termine le flux. Le flux directionnel est la séquence logique qui relie les étapes, tracée dans le sens de lecture. Un point de décision divise le flux en chemins exclusifs ou parallèles ou les rejoint. Un lien raccorde le modèle à un autre modèle de processus. Un rôle désigne la personne ou le groupe impliqué et se rattache au modèle d'organisation.
Cette proximité avec l'intuition ordinaire d'une suite d'actions explique pourquoi la modélisation parle à des parties prenantes sans formation et pourquoi le passage d'une notation à l'autre reste possible. Le modèle a de surcroît une valeur que le tracé ne montre pas: il impose des libellés cohérents, il rend visibles les responsabilités et les passages de main, et il fait apparaître des groupes que personne n'avait pensé à consulter.
Les pièges à éviter
Trois défauts guettent quelle que soit la notation retenue. Mêler la logique de décision au flux d'abord: quand chaque règle métier devient une branche, le modèle enfle jusqu'à l'illisibilité, alors que les règles se tiennent mieux séparément. La sur-décomposition ensuite, ce modèle si détaillé qu'aucune personne seule ne le comprend, ne le valide ni ne le signe. L'obsolescence enfin: dans un environnement qui bouge, un modèle qui n'est que de la documentation s'écarte du processus réel et devient une archive que plus personne ne consulte. À ces trois s'ajoute une résistance culturelle, la modélisation étant parfois perçue dans l'informatique comme une approche ancienne et lourde en documents à laquelle on ne réserve pas de temps; on la désamorce en tenant le modèle au bon niveau et en le rattachant à une décision qu'il sert.
Considérations IA
Un modèle de langue est utile à plusieurs étapes de cette technique. Il dresse un premier jet à partir d'une matière existante: le compte rendu d'un entretien, une procédure écrite ou un mode opératoire deviennent un flux candidat qu'un analyste corrige plus vite qu'il ne partirait d'une page blanche. Il signale des chemins d'exception qu'un premier passage humain néglige souvent, le rejet, l'annulation, le délai dépassé. Il harmonise les libellés d'activités entre plusieurs modèles d'un même domaine, et il traduit un modèle d'une notation vers une autre quand le public change.
Sa limite est de nature métier et elle ne se négocie pas. La machine déduit un flux de ce qu'on lui donne à lire, avec les erreurs et les silences de la source; elle ignore ce que fait réellement l'organisation quand aucun document ne le dit, or c'est là que logent les détours et les exceptions qui font l'intérêt du modèle as-is. Valider qu'un modèle reflète le travail réel revient aux personnes qui l'exécutent. Choisir le bon niveau et la bonne notation pour un public donné reste un jugement, comme l'est le fait d'écarter une branche que l'IA a inventée sans qu'aucune règle ne la soutienne. Chaque proposition de la machine est un brouillon soumis aux parties prenantes.
Coût
L'effort dépend de la notation et du niveau plus que de la technique en soi. Un logigramme de cadrage coûte quelques heures; un modèle BPMN exécutable et maintenu coûte cher et longtemps.
| Phase | Niveau | Justification |
|---|---|---|
| Préparation | Faible à moyen | Réunir les personnes qui connaissent le processus et rassembler les procédures existantes. L'état actuel demande surtout de l'accès aux bons interlocuteurs. |
| Exécution | Faible à élevé | Une séance suffit pour un logigramme de cadrage; un modèle opérationnel détaillé, avec ses exceptions et ses chemins alternatifs, réclame plusieurs ateliers et une validation par les acteurs. |
| Documentation | Moyen à élevé | Un modèle support de discussion se jette après usage. Un modèle qui doit rester le miroir du processus ou en piloter l'exécution se met à jour à chaque changement. |
Outils
L'outillage suit l'ambition du modèle et la notation choisie. Un tableau blanc et des papillons repositionnables restent le moyen le plus rapide de faire parler une équipe et de dresser un état actuel. Un outil de diagrammes générique produit un modèle propre et versionnable, suffisant pour un logigramme ou un premier jet BPMN. Une suite BPM spécialisée s'impose quand le modèle doit être précis, relié à un dépôt de processus et tenu dans la durée, avec validation de la notation, simulation et gestion des versions. La notation contraint l'outil: un modèle BPMN destiné à l'exécution suppose un moteur capable de l'interpréter, qu'un simple éditeur de dessin ne remplace pas.
Sources
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.35 Process Modelling: la définition de la technique et l'énumération des éléments communs aux notations.
- ABPMP, Guide to the Business Process Management Common Body of Knowledge (BPM CBOK), domaine de connaissance Process Modeling: le corpus qui fait autorité sur la modélisation des processus et ses notations, y compris la lignée IGOE.
- OMG, Business Process Model and Notation (BPMN) 2.0.2: la spécification qui définit le BPMN.
- OMG, Unified Modeling Language (UML) Specification: la spécification qui définit le diagramme d'activités.
- NIST, FIPS PUB 183, Integration Definition for Function Modeling (IDEF0): le standard fédéral qui définit la modélisation de fonctions IDEF0.