Un diagramme de processus BPMN décrit le travail à l’aide de Business Process Model and Notation, un langage standard pour les activités, événements, décisions et communications. Sa valeur lors d’une revue d’équipe est sa précision. Un modèle partagé permet aux participants de questionner une transition précise au lieu de débattre d’affirmations vagues comme « les validations sont lentes ».
Cet article présente de petits exemples descriptifs pour alimenter la discussion. Ce ne sont pas des modèles de processus exécutables. Utilisez un outil de modélisation compatible avec BPMN pour créer et valider le diagramme réel. NextRetro facilite les rétrospectives et leur suivi ; ce n’est ni un éditeur BPMN ni un moteur de processus.
Comprendre la notation avant d’interpréter le schéma
La spécification OMG BPMN 2.0.2 est la référence officielle. L’aperçu ci-dessous se limite volontairement aux concepts utilisés dans notre exemple ; BPMN permet davantage de détails que cette introduction n’en couvre.
| Élément | Signification dans cet exemple |
|---|---|
| Pool | Participant à une collaboration |
| Couloir | Partition d’un processus, utilisée ici pour montrer les responsabilités |
| Tâche | Activité, comme vérifier une demande |
| Événement de début ou de fin | Début ou fin du chemin de processus modélisé |
| Passerelle | Point de contrôle qui sépare ou réunit des chemins |
| Flux de séquence | Ordre du travail dans un processus ; il ne franchit pas les limites d’un pool |
| Flux de message | Communication entre participants distincts, représentés par des pools séparés |
Un flux de séquence peut traverser des couloirs d’un même pool. N’utilisez pas un flux de message entre deux couloirs de ce pool au seul motif que des équipes différentes réalisent le travail. Les couloirs ne sont pas interchangeables avec des participants indépendants.
Pour les symboles et comportements détaillés, consultez la spécification normative. Un modèle destiné à piloter une automatisation nécessite une validation plus stricte qu’un croquis d’atelier.
Exemple 1 : une demande d’accès interne
Imaginons une organisation qui examine la façon dont son personnel demande l’accès à un système de reporting. Modélisez l’organisation dans un seul pool, avec des couloirs pour le service d’assistance et l’administration des accès. Le salarié peut être représenté séparément si la vue de collaboration choisie le considère comme un autre participant ; choisissez et documentez la limite de manière cohérente.
Pour le processus de l’organisation, un parcours simple est le suivant :
- Une demande arrive et déclenche le processus.
- Le service d’assistance vérifie si les informations nécessaires sont présentes.
- Une passerelle exclusive sépare les demandes complètes des demandes incomplètes.
- Les demandes incomplètes sont renvoyées pour clarification selon l’interaction définie avec le demandeur.
- Les demandes complètes passent à la vérification des droits d’accès.
- Les demandes approuvées donnent lieu à un accès ; les refus sont accompagnés d’une explication.
- Le processus se termine par l’enregistrement du résultat approprié.
Étiquetez les chemins de décision avec des conditions telles que « informations requises complètes » et « informations manquantes ». « Oui » et « Non » deviennent difficiles à interpréter si le diagramme est partagé sans sa question d’origine.
Il s’agit d’une description à modéliser, pas de l’affirmation que ces étapes respectent la politique de sécurité d’une organisation particulière. Les exigences d’autorisation et de preuve doivent provenir des contrôles approuvés de cette organisation.
Exemple 2 : un fournisseur contribue au processus
Imaginons maintenant qu’un fournisseur distinct doive activer un compte sous licence après l’autorisation de l’organisation. Représentez le fournisseur dans un autre pool. La demande d’activation de l’organisation et la confirmation du fournisseur sont des communications entre participants ; modélisez-les donc avec des flux de messages.
Ne tracez pas de flèche de séquence d’une tâche interne directement vers une tâche du fournisseur. Cela confondrait l’ordre interne du processus d’un participant avec la communication qui franchit une limite.
Vous pouvez masquer le processus interne du fournisseur s’il est hors du périmètre de la revue. L’équipe peut avoir besoin de savoir quel message déclenche l’interaction et quelle réponse est attendue sans prétendre connaître le fonctionnement interne du fournisseur.
Une question de revue utile apparaît alors : que se passe-t-il si aucune confirmation n’arrive ? Définissez le traitement prévu de cette exception avant d’ajouter un temporisateur ou un autre événement au modèle formel. La seule étiquette « expiration du délai » ne dit pas qui relance ni quelle décision cette personne peut prendre.
Parcourir des cas dans le modèle avant de le modifier
Choisissez trois cas réels et suffisamment anonymisés : une demande traitée sans incident, une demande nécessitant des précisions et une exception. Gardez les renseignements personnels ou confidentiels dans le système de cas approuvé ; utilisez des références ou des résumés pendant l’atelier.
Pour chaque cas, demandez aux personnes qui ont réalisé le travail d’en retracer le parcours. Où le travail s’est-il réellement arrêté ? Quelle information manquait ? Quel participant pensait qu’une autre personne était responsable de l’étape suivante ? Consignez les différences entre le processus documenté et les pratiques observées.
Ne modifiez pas discrètement le modèle pour en faire le processus idéal à venir. Distinguez le parcours actuel et le changement proposé. Sinon, l’équipe pourrait repartir avec un diagramme soigné qui n’explique plus les cas qu’elle devait étudier.
Un modèle de processus est une hypothèse sur le déroulement du travail. Les horodatages et l’historique des cas permettent de tester cette hypothèse. Ni le diagramme ni le souvenir d’un participant ne constituent à eux seuls une preuve complète.
Exemple détaillé de décision d’amélioration
Dans cet exemple hypothétique, l’équipe examine douze demandes. Ce nombre est illustratif ; ce n’est ni une référence ni un résultat client de NextRetro. Plusieurs demandes ont attendu entre la vérification des informations et l’autorisation d’accès parce que le transfert n’indiquait pas la personne chargée de la décision.
La première proposition consiste à automatiser toutes les approbations. Le modèle montre pourquoi c’est prématuré : l’équipe n’a pas encore défini quelles demandes exigent quelles autorisations. Automatiser une décision non définie pourrait accélérer un travail incomplet sans clarifier les responsabilités.
L’équipe choisit une expérience plus limitée. Pour les dix prochaines demandes admissibles, le service d’assistance désignera la personne chargée de l’autorisation avant d’envoyer le transfert. Il consignera séparément le temps d’attente lié à la clarification du responsable et le temps consacré à l’autorisation.
La protection reste le contrôle d’accès en vigueur. Accélérer le traitement ne justifie pas de sauter l’autorisation. Lors de la prochaine revue, l’équipe vérifiera si les retards dus à l’absence de responsable ont diminué et si la préparation supplémentaire a créé un nouveau goulot d’étranglement.
Le diagramme de processus est ainsi relié à un changement observable, au lieu de traiter sa propre finalisation comme une amélioration.
Utiliser une fiche de revue avec le diagramme
Pour chaque problème suspecté, consignez les éléments suivants :
Emplacement : Quelle tâche, décision ou quel transfert est concerné ?
Cas observé : Quel exemple montre la difficulté ?
Déclencheur attendu : Qu’est-ce qui devrait démarrer l’étape suivante ?
Obstacle réel : Qu’est-ce qui l’en a empêché ?
Changement proposé : Qu’est-ce qui sera différent pour les prochains cas admissibles ?
Contrainte : Quel contrôle ou quelle exigence de qualité doit rester intact ?
Preuve à examiner : Qu’examinera l’équipe, et quand ?
Choisissez un format de rétrospective qui laisse aux participants le temps de remettre le modèle en question avant de prioriser les changements. Utilisez ensuite le guide des actions pour garder l’expérience choisie visible après la réunion.
Foire aux questions
Dans BPMN, les pools et les couloirs sont-ils la même chose ?
Non. Un pool représente un participant à une collaboration. Un couloir partitionne un processus. Un flux de séquence peut traverser des couloirs d’un même pool, tandis que la communication entre des pools distincts utilise un flux de message.
Tout organigramme de processus est-il un diagramme BPMN ?
Non. Un organigramme général peut utiliser des symboles et conventions informels. Appelez un modèle BPMN uniquement s’il suit les règles pertinentes de la notation, et validez-le correctement s’il doit servir à l’automatisation.
NextRetro peut-il créer des modèles BPMN exécutables ?
NextRetro n’est ni un outil de modélisation BPMN ni un moteur de processus. Conservez le modèle de référence dans un éditeur adapté et utilisez un tableau de rétrospective pour discuter des problèmes observés, des explications concurrentes et des expériences d’amélioration convenues.