Modèle et notation des processus métiers, ou BPMN, est un langage visuel standardisé pour décrire comment le travail est accompli. Il aide les analystes métiers, les gestionnaires, les développeurs et les participants au processus à comprendre le même processus sans avoir à s’appuyer sur des procédures écrites longues.
Un diagramme BPMN est constitué de quatre grandes catégories :
-
Objets de flux :Événements, activités et passerelles
-
Objets de connexion :Flux de séquence, flux de messages et associations
-
Piscines et lits :Piscines et lits
-
Artéfacts :Objets de données, groupes et annotations textuelles
Ce guide se concentre sur la catégorie la plus importante :Objets de flux BPMN. Les objets de flux décrivent ce qui se produit dans un processus, quel travail est effectué et comment le processus passe d’un chemin à un autre.
1. Qu’est-ce que les objets de flux BPMN ?
Les objets de flux sont les éléments centraux d’un diagramme de processus BPMN. Ils sont reliés par des flux de séquence et représentent le comportement d’un processus.
Il existe trois types :
| Objet de flux | Forme de base | Objectif principal |
|---|---|---|
| Événement | Cercle | Quelque chose qui se produit |
| Activité | Rectangle arrondi | Travail effectué |
| Passerelle | Losange | Une décision, un point de séparation, de fusion ou de synchronisation |
Un processus simple pourrait avoir conceptuellement l’aspect suivant :
Événement de départ → Activité → Passerelle → Activité → Événement de fin
Par exemple :
Commande reçue → Vérification du stock → L'article est-il disponible ?
├── Oui → Expédier la commande
└── Non → Informer le client
Les formes sont simples, mais les symboles à l’intérieur d’elles apportent un sens supplémentaire.
2. Événements : des choses qui se produisent
Un événementreprésente quelque chose qui se produit au cours d’un processus. Contrairement à une activité, un événement n’est pas un travail effectué par une personne ou un système. Il peut déclencher un processus, interrompre une activité, signaler une condition ou indiquer la fin d’un processus.
Les événements sont représentés par des cercles. La bordure indique où se produit l’événement dans le processus :
| Type d’événement | Apparence de la bordure | Signification |
|---|---|---|
| Événement de départ | Ligne fine simple | Montre comment un processus commence |
| Événement intermédiaire | Ligne double | Se produit entre le début et la fin |
| Événement de fin | Ligne simple épaisse | Montre comment un chemin de processus se termine |
Un événement de départ peut capturer un déclencheur, tel qu’un message entrant ou un moment planifié. Un événement intermédiaire peut attendre ou envoyer quelque chose. Un événement de fin produit le résultat final d’un chemin de processus.
2.1 Événements de départ
Un événement de départindique le déclencheur qui démarre un processus ou un sous-processus.
Il est représenté par un cercle avec une bordure fine.
Les exemples courants incluent :
-
Un client soumet une commande
-
Un employé soumet une demande de congé
-
Une minuterie atteint une date planifiée
-
Un message arrive
-
Un système détecte une condition
-
Un nouveau dossier est créé
Événement de départ sans déclencheur
Un cercle de départ simple signifie que le processus commence sans déclencheur spécifiquement modélisé.
○
Exemple :
○ → Examiner la demande
Utilisez un événement de départ sans déclencheur lorsque le déclencheur précis est soit inconnu, soit sans importance, soit volontairement laissé général.
Événement de départ par message
Un symbole de message à l’intérieur de l’événement de départ indique que le processus commence lorsqu’un message est reçu.
Exemple :
◉ symbole enveloppe → Traiter la demande du client
Cas d’utilisation typiques :
-
Réception d’un courriel
-
Réception d’une requête API
-
Réception d’une commande d’achat
-
Recevoir une demande d’un autre participant
Événement de démarrage avec minuterie
Une horloge à l’intérieur de l’événement de démarrage indique que le processus commence selon un planning ou une date.
Exemples :
-
Démarrer la génération des factures tous les mois
-
Commencer le processus de renouvellement 30 jours avant l’expiration
-
Exécuter un processus de réconciliation quotidien
Événement de démarrage conditionnel
Un événement de démarrage conditionnel démarre lorsque une condition métier devient vraie.
Exemple :
Le niveau de stock tombe en dessous du point de réapprovisionnement
Événement de démarrage par signal
Un événement de démarrage par signal démarre lorsqu’un signal diffusé est reçu. Contrairement à un message, un signal n’est généralement pas destiné à un destinataire spécifique.
Exemple :
Recevoir le signal « Fermeture d'urgence » → Fermer toutes les agences
Événement de démarrage multiple
Un événement de démarrage multiple indique que plusieurs déclencheurs différents peuvent initier le même processus.
Par exemple, un cas de support peut commencer lorsque :
-
Un client soumet un formulaire web
-
Un agent saisit un cas manuellement
-
Un système automatisé de surveillance détecte un problème
2.2 Événements intermédiaires
Un événement intermédiairesurvient après le démarrage d’un processus mais avant sa fin. Il peut mettre en pause le processus, attendre quelque chose, envoyer un message, créer un chemin d’exception ou répondre à une condition.
Il est dessiné avec une bordure double.
Les événements intermédiaires peuvent être :
-
Réception :Attente ou réception de quelque chose
-
Envoi :Envoi ou production de quelque chose
Un événement de réception a généralement un marqueur vide ou en trait plein, tandis qu’un événement d’envoi utilise généralement un marqueur rempli.
Événement intermédiaire temporisateur
Un événement temporisateur représente un délai, une échéance, une durée ou un calendrier récurrent.
Exemples :
-
Attendre trois jours ouvrables
-
Attendre jusqu’à une date précise
-
Passer en mode d’escalade si aucune réponse n’arrive dans les 24 heures
-
Effectuer une action répétée pendant que le processus est actif
Exemple :
Envoyer un devis → Attendre 3 jours → Vérifier la réponse
Événement intermédiaire de message
Un événement intermédiaire de message attend soit un message, soit en envoie un.
Exemples :
Envoyer une demande d'approbation → Attendre la réponse d'approbation
Un événement de message est particulièrement utile lorsque un processus interagit avec un autre participant, département, organisation ou système.
Événement intermédiaire d’erreur
Un événement d’erreur représente une condition d’erreur qui affecte le déroulement normal du processus.
Il est couramment utilisé comme événement de bord attaché à une activité ou à un sous-processus.
Exemple :
Traiter le paiement
│
└── Erreur → Gérer l'échec du paiement
Événement intermédiaire d’escalade
Un événement d’escalade indique qu’un problème nécessite une attention à un niveau supérieur sans nécessairement représenter une panne technique.
Exemple :
Résoudre une réclamation client
│
└── Escalade → Revue par le superviseur
Événement intermédiaire conditionnel
Un événement conditionnel attend qu’une condition spécifiée devienne vraie.
Exemple :
Attendre que le compte client soit vérifié
Événement intermédiaire de signal
Un événement de signal diffuse ou reçoit un signal pouvant être pertinent pour plusieurs participants au processus.
Exemple :
Diffuser le signal d'appel de produit
Événement intermédiaire de lien
Un événement de lien connecte deux points éloignés au sein du même diagramme de processus sans devoir tracer une longue ligne de flux de séquence à travers la page.
Utilisez les événements de lien avec précaution. Ils peuvent améliorer la lisibilité du diagramme, mais une utilisation excessive peut rendre le processus plus difficile à suivre.
Événement intermédiaire de compensation
Un événement de compensation déclenche des travaux correctifs pour annuler ou compenser une activité antérieure.
Exemple :
Annuler la réservation d'hôtel
La compensation est différente d’un chemin d’erreur ordinaire. Elle est spécifiquement axée sur l’inversion ou la compensation du travail déjà accompli.
2.3 Événements limites
Un événement limite est directement attaché au bord d’une activité ou d’un sous-processus. Il représente quelque chose qui peut se produire pendant que cette activité est en cours.
Exemple :
┌────────────────────┐
│ Application du processus │
└────────────────────┘
○
│
└── Délai dépassé → Escalader le cas
Les événements limites sont utiles pour modéliser :
-
Délais dépassés
-
Annulations
-
Erreurs
-
Escalades
-
Messages entrants
-
Indemnisation
-
Signaux externes
Événements limites interrompant
Un événement limite interrompant arrête l’activité associée lorsqu’il se produit.
Exemple :
Processus Paiement
│
└── Erreur de paiement → Gérer l’échec
L’activité de paiement se termine lorsque l’erreur se produit.
Événements limites non interrompant
Un événement limite non interrompant démarre un chemin supplémentaire tandis que l’activité d’origine continue.
Il est généralement représenté avec une bordure pointillée.
Exemple :
Processus Candidature
│
└── Rappel du minuteur → Envoyer le rappel
Le processus de candidature continue pendant que le chemin de rappel s’exécute.
Cette distinction est importante :
| Type d’événement limite | Effet sur l’activité associée |
|---|---|
| Interrompant | Arrête l’activité |
| Non interrompant | Laisse l’activité en cours |
2.4 Événements de fin
Un événement de fin indique la conclusion d’un chemin de processus. Il est représenté par un cercle avec une bordure épaisse.
Un processus peut avoir plus d’un événement de fin, car des résultats différents peuvent terminer le processus.
Exemples :
-
Commande terminée
-
Demande rejetée
-
Paiement échoué
-
Affaire annulée
-
Client informé
-
Processus terminé avec compensation
Événement de fin sans
Un événement de fin simple indique que le chemin est terminé sans préciser de résultat particulier.
●
Événement de fin par message
Un événement de fin par message envoie un message lorsque le processus se termine.
Exemple :
Commande approuvée → Envoyer la confirmation → Fin du message
Événement de fin d’erreur
Un événement de fin d’erreur met fin au processus en lançant une erreur vers un processus ou un gestionnaire de niveau supérieur.
Utilisez-le pour les conditions d’échec au niveau du processus qui doivent être gérées ailleurs.
Événement de fin d’escalade
Un événement de fin d’escalade met fin au chemin actuel du processus et indique qu’une escalade a eu lieu.
Événement de fin de terminaison
Un événement de fin de terminaison met immédiatement fin à toute l’instance du processus, y compris aux autres chemins actifs.
Cela est plus fort qu’un événement de fin ordinaire. Il doit être utilisé lorsque tout travail restant doit s’arrêter.
Événement de fin de compensation
Un événement de fin de compensation déclenche les activités de compensation avant la conclusion du chemin du processus.
3. Activités : Travail effectué
Une activitéreprésente un travail effectué par une personne, une équipe, un système ou un service automatisé. Les activités sont représentées par des rectangles arrondis.
Exemples incluent :
-
Examiner la demande
-
Approuver la facture
-
Envoyer la confirmation
-
Valider les coordonnées du client
-
Calculer le coût d’expédition
-
Mettre à jour le compte
-
Générer un rapport
Les activités forment l’ossature opérationnelle d’un diagramme BPMN car elles montrent où le temps, les efforts, les coûts et la responsabilité sont concentrés.
3.1 Nommer les activités
Un bon nom d’activité suit généralement ce modèle :
Verbe + objet
Exemples :
-
Examiner la demande
-
Approuver la facture
-
Créer un enregistrement client
-
Valider le paiement
-
Envoyer un courriel de confirmation
Évitez les noms vagues tels que :
-
Traitement
-
Gérer la demande
-
Étape 1
-
Autres tâches
-
Administration
Un nom d’activité clair doit décrire une action et son sujet.
| Nom faible | Meilleur nom |
|---|---|
| Traitement | Traiter le paiement |
| Examiner | Examiner la demande |
| Étape du client | Vérifier l’identité du client |
| Courriel | Envoyer le courriel d’approbation |
| Mettre à jour | Mettre à jour l’état de la commande |
Une tâche représente normalement une unité de travail qui ne peut pas ou ne doit pas être décomposée davantage. Un sous-processus représente une collection d’activités liées.
3.2 Tâches
Une tâcheest le type d’activité le plus simple. Elle représente une unité unique de travail.
Une tâche basique est représentée par un rectangle arrondi :
╭────────────────────╮
│ Examiner la demande │
╰────────────────────╯
Les tâches peuvent inclure des indicateurs qui identifient le type de travail effectué.
Tâche utilisateur
Une tâche utilisateur est effectuée par une personne humaine utilisant un système ou une application.
Exemples :
-
Approuver le rapport de frais
-
Saisir les informations du client
-
Examiner le contrat
-
Attribuer un dossier d’assistance
Tâche manuelle
Une tâche manuelle est effectuée par une personne sans l’aide d’un moteur de processus métier ou d’une application.
Exemples :
-
Inspecter l’équipement
-
Signer un document papier
-
Emballer un produit physique
-
Remettre un document en main propre
Tâche de service
Une tâche de service est effectuée automatiquement par un système, une application, un service web ou une API.
Exemples :
-
Récupérer le score de crédit
-
Envoyer un courriel automatisé
-
Calculer les taxes
-
Créer un enregistrement de base de données
-
Appeler le service de paiement
Tâche de script
Une tâche de script exécute un script ou un morceau de code dans l’environnement du processus.
Exemples :
-
Transformer les données
-
Calculer une valeur
-
Mettre en forme un message
-
Appliquer une règle simple sur les données
Tâche de règle métier
Une tâche de règle métier évalue des règles métier, souvent à l’aide d’un moteur de règles.
Exemples :
-
Déterminer la limite de crédit
-
Calculer la prime d’assurance
-
Décider si une commande est éligible à la livraison gratuite
-
Déterminer le niveau d’approbation
Tâche d’envoi
Une tâche d’envoi envoie un message à un autre participant ou système.
Exemples :
-
Envoyer la facture
-
Envoyer la confirmation de commande
-
Envoyer une notification au entrepôt
Recevoir une tâche
Une tâche de réception attend un message provenant d’un autre participant ou système.
Exemples :
-
Recevoir le contrat signé
-
Recevoir la confirmation de paiement
-
Recevoir l’état d’expédition
3.3 Sous-processus
Un sous-processus est une activité qui contient un processus plus détaillé.
Il peut être représenté de deux façons :
-
Sous-processus réduit : Un rectangle arrondi avec une marque plus
-
Sous-processus étendu : Un rectangle arrondi plus grand affichant le flux interne
Utilisez un sous-processus lorsque plusieurs tâches sont liées et que le diagramme de haut niveau deviendrait trop détaillé si toutes étaient affichées.
Exemple :
╭──────────────────────────────╮
│ + Achèvement de l'inscription du client │
╰──────────────────────────────╯
Le sous-processus peut contenir :
Recueillir les informations
↓
Vérifier l'identité
↓
Créer un compte
↓
Envoyer un message de bienvenue
Quand utiliser un sous-processus
Utilisez-en un lorsque :
-
Un groupe d’étapes a un objectif commercial clair
-
Le groupe peut être réutilisé de manière conceptuelle
-
Le diagramme principal devient encombré
-
Les parties prenantes ont besoin à la fois d’une vue d’ensemble et d’une vue détaillée
-
Le processus interne dispose de sa propre logique de démarrage, de fin, d’exception ou de décision
Sous-processus intégré
Un sous-processus intégré est défini à l’intérieur de son processus parent et fait partie du flux de ce processus.
Activité d’appel
Une activité d’appel invoque un processus réutilisable défini séparément ou une tâche globale.
Utilisez-le lorsque la même logique de processus est appelée depuis plusieurs endroits, par exemple :
Vérifier l'identité du client
Si la vérification du client apparaît dans plusieurs processus commerciaux, une activité d’appel réutilisable peut être plus appropriée que de dupliquer toutes ses étapes internes.
Sous-processus d’événement
Un sous-processus d’événement est activé par un événement de démarrage pendant que son processus ou sous-processus conteneur est actif. Il est utile pour gérer des situations exceptionnelles ou parallèles, telles que des demandes d’annulation, des escalades urgentes ou des mises à jour entrantes. Les sous-processus d’événement peuvent être interrompant ou non interrompant.
Exemple :
Process principal : Exécuter la commande
Sous-processus d'événement :
Demande d'annulation → Annuler l'exécution → Rembourser le client
3.4 Symboles d’activité
Les activités peuvent inclure de petits symboles qui ajoutent des informations sur leur comportement.
Symbole de boucle
Un symbole de boucle indique qu’une activité se répète jusqu’à ce qu’une condition soit remplie.
Exemple :
Examiner le document
↻
Utilisez-le pour des activités telles que :
-
Examiner jusqu’à approbation
-
Essayer la livraison jusqu’à succès
-
Contacter le client jusqu’à ce qu’il soit joint
Symbole d’instance multiple parallèle
Cela indique que plusieurs instances de la même activité s’exécutent en même temps.
Exemple :
Obtenir trois approbations
L’activité peut être effectuée simultanément par plusieurs validateurs.
Symbole d’instance multiple séquentielle
Cela indique que plusieurs instances s’exécutent une après l’autre.
Exemple :
Examiner les éléments un par un
Marqueur de compensation
Cela identifie une activité utilisée pour compenser un travail précédemment effectué.
Exemple :
Rembourser le client
Marqueur ad hoc
Un sous-processus ad hoc est représenté par un marqueur ressemblant à un tilde. Il indique que les activités à l’intérieur du sous-processus peuvent être effectuées dans un ordre souple ou peu structuré, plutôt que suivre une séquence fixe.
4. Passerelles : Décisions, divisions et regroupements
Une passerellecontrôle la manière dont le flux du processus diverge ou converge. Les passerelles sont dessinées sous forme de losanges.
Une passerelle n’est normalement pas une tâche. Elle ne réalise pas elle-même le travail de prise de décision. Elle représente plutôt la manière dont le flux du processus est contrôlé après qu’une décision, une condition ou un événement a été évalué.
Par exemple :
Examiner la demande → La demande est-elle complète ?
L’activité d’examen rassemble ou évalue des informations. La passerelle redirige ensuite le processus selon le résultat.
Les passerelles peuvent :
-
Diviser un chemin en plusieurs chemins
-
Fusionner plusieurs chemins en un seul
-
Synchroniser le travail parallèle
-
Attendre un ou plusieurs événements
-
Acheminer le travail en fonction de conditions ou de règles
4.1 Porte exclusive : XOR
Une porte exclusive sélectionne exactement un chemin sortant.
Elle est généralement représentée par un losange contenant un « X », bien que le marqueur puisse être omis sur certains diagrammes.
Exemple :
┌── Approuvé → Créer un compte
Vérifier la demande ─◇
└── Rejeté → Envoyer le rejet
Un seul chemin est suivi.
Utilisations courantes :
-
Si le paiement est approuvé, poursuivre ; sinon, rejeter
-
Si le client est éligible, proposer une réduction
-
Si la demande est complète, la traiter ; sinon, la renvoyer
Les chemins sortants doivent normalement comporter des conditions ou des étiquettes claires :
-
Approuvé
-
Rejeté
-
Complété
-
Incomplet
-
Montant > 10 000 $
-
Montant ≤ 10 000 $
Fusion exclusive
Une passerelle exclusive peut également fusionner des chemins alternatifs en un seul chemin. Elle ne patiente pas pour tous les chemins, car un seul des chemins alternatifs devrait avoir été emprunté.
Flux par défaut
Un chemin par défaut peut être utilisé lorsque aucune des conditions spécifiées n’est vraie.
Par exemple :
Approuvé
Rejeté
Par défaut → Revue manuelle
Un chemin par défaut est utile pour les cas imprévus ou non classés.
4.2 Passerelle parallèle : ET
Une passerelle parallèlesépare le processus en plusieurs chemins qui s’exécutent en parallèle.
Elle est représentée par un losange contenant un signe plus.
Exemple :
┌── Préparer la facture ──┐
Approuvé commande ─◇ ◇── Expédier la commande
└── Réserver l'inventaire ┘
Les deux activités commencent, et le processus peut plus tard attendre que les deux soient terminées.
Division parallèle
Une division parallèle démarre tous les chemins sortants.
Utilisez-la lorsque toutes les activités doivent avoir lieu, indépendamment des conditions.
Exemples :
-
Envoyer la confirmation et mettre à jour l’inventaire
-
Notifier la comptabilité et notifier les opérations
-
Effectuer une vérification de sécurité et une vérification de fraude
Jointure parallèle
Une jointure parallèle attend que toutes les voies entrantes soient terminées avant de continuer.
Cela est parfois appelé synchronisation.
Préparer la facture ──┐
◇── Exécuter la commande
Réserver les stocks ┘
Si une branche entrante est retardée, la jointure l’attend.
4.3 Passerelle inclusive : OU
Une passerelle inclusive sélectionne une ou plusieurs voies sortantes en fonction des conditions qui sont vraies.
Elle est représentée par un losange contenant un cercle.
Exemple :
Le client est éligible à :
- Remise standard
- Remise fidélité
- Remise promotionnelle
Plus d’une action liée aux remises peut être sélectionnée si plusieurs conditions sont remplies.
Utilisez une passerelle inclusive lorsque :
-
Une ou plusieurs conditions peuvent être vraies
-
Plusieurs chemins peuvent s’exécuter en même temps
-
Le processus doit continuer après la fin de tous les chemins sélectionnés
Contrairement à une passerelle exclusive, une passerelle inclusive ne choisit pas nécessairement un seul chemin. Contrairement à une passerelle parallèle, elle ne choisit pas nécessairement tous les chemins.
4.4 Passerelle basée sur un événement
Un passerelle basée sur un événement oriente le processus selon l’événement qui se produit en premier.
Il est généralement suivi par des événements intermédiaires de capture ou des tâches de réception.
Exemple :
Envoyer le devis → Passerelle basée sur un événement
├── Message reçu → Traiter l'acceptation
└── Délai expiré → Envoyer un rappel
Seul le premier événement qui se produit détermine le chemin.
Utilisez une passerelle basée sur un événement lorsque le processus attend un comportement externe plutôt qu’une évaluation d’une condition métier connue. Par exemple, le processus pourrait attendre soit une réponse du client, soit un délai d’expiration.
Passerelle basée sur un événement versus passerelle exclusive
| Question | Passerelle exclusive | Passerelle basée sur un événement |
|---|---|---|
| Qu’est-ce qui détermine le chemin ? | Une condition ou une règle métier | Le premier événement qui se produit |
| Question typique | « La demande est-elle approuvée ? » | « Qu’est-ce qui se produit en premier ? » |
| Éléments suivants courants | Activités ou flux de séquence | Événements de capture ou tâches de réception |
| Source de décision | Données ou logique | Événement externe |
4.5 Passerelle complexe
Une passerelle complexe gère la logique avancée de routage qui ne peut pas être clairement exprimée avec les types standards de passerelles.
Exemples incluent :
-
Continuer lorsque au moins deux des trois approbations sont reçues
-
Choisir un chemin en fonction d’une combinaison complexe de conditions
-
Synchroniser les chemins sélectionnés selon des règles personnalisées
Les passerelles complexes doivent être utilisées avec parcimonie. Dans de nombreux cas, plusieurs passerelles plus simples ou une tâche de règle métier clairement nommée seront plus faciles à comprendre et à maintenir.
4.6 Variantes de passerelle basée sur les événements
BPMN prend également en charge des variantes de passerelle basée sur les événements, notamment :
-
Passerelles basées sur les événements exclusives
-
Passerelles basées sur les événements parallèles
-
Passerelles basées sur les événements d’instanciation
Une passerelle basée sur les événements parallèles peut attendre plusieurs conditions d’événements, tandis qu’une passerelle basée sur les événements exclusives procède en fonction du premier événement qui se produit. La variante appropriée dépend de savoir si le processus attend un événement ou une combinaison d’événements.
5. Comment les objets de flux fonctionnent ensemble
Le sens d’un diagramme BPMN provient des relations entre les événements, les activités, les passerelles et les flux de séquence.
Considérez un processus de commande :
Début
↓
Recevoir la commande
↓
Vérifier le stock
↓
L'article est-il disponible ?
├── Oui → Emballer la commande → Expédier la commande → Fin
└── Non → Informer le client → Fin
Cet exemple contient :
-
Un événement de départ qui démarre le processus
-
Des activités de réception, de vérification, d’emballage, d’expédition et d’information
-
Une passerelle exclusive qui choisit un chemin
-
Deux événements de fin ou chemins de fin représentant des résultats différents
Une version plus avancée pourrait être :
Début
↓
Recevoir la commande
↓
Vérifier le stock
↓
L'article est-il disponible ?
├── Non → Informer le client → Fin
└── Oui → Passerelle parallèle
├── Réserver le stock
├── Préparer la facture
└── Vérifier la fraude
↓
Fusion parallèle
↓
Expédier la commande
↓
Fin
Ici :
-
La passerelle exclusive détermine si la livraison peut continuer.
-
La passerelle parallèle lance trois activités.
-
La fusion parallèle attend que les trois activités soient terminées.
-
L’expédition ne commence qu’après la synchronisation complète.
6. Événements, activités et passerelles : une comparaison rapide
| Élément | Question clé | Exemple |
|---|---|---|
| Événement | Qu’est-ce qui s’est produit ou va se produire ? | Paiement reçu |
| Activité | Quel travail est effectué ? | Vérifier le paiement |
| Passerelle | Quelle route le processus doit-il suivre ? | Le paiement est-il valide ? |
Une règle utile est :
-
Les événements se produisent
-
Les activités sont effectuées
-
Les passerelles contrôlent le chemin
Si vous n’êtes pas sûr du symbole à utiliser, demandez :
-
S’agit-il de quelque chose qui se produit sans être traité comme un travail ? Utilisez un événement.
-
Quelqu’un ou quelque chose effectue-t-il une action ? Utilisez un activité.
-
Le processus se divise-t-il, se fusionne-t-il ou attend-il une condition de routage ? Utilisez un passerelle.
7. Connexion correcte des objets de flux
Les objets de flux sont connectés par différents types de lignes. Utiliser le mauvais connecteur peut rendre un diagramme trompeur.
7.1 Flux de séquence
Un flux de séquence est une ligne pleine avec une flèche à l’extrémité. Elle indique l’ordre dans lequel les objets de flux sont exécutés au sein du même processus.
Activité A → Activité B
Utilisez le flux de séquence pour connecter :
-
Événements aux activités
-
Activités aux passerelles
-
Passerelles aux activités
-
Activités aux événements de fin
Un flux de séquence ne devrait normalement pas croiser la frontière entre des piscines séparées.
7.2 Flux de message
Un flux de message est une ligne pointillée avec une flèche ouverte. Elle représente la communication entre des participants ou des piscines séparés.
Exemples :
-
Le client envoie une commande au vendeur
-
Le vendeur envoie une confirmation au client
-
La banque envoie le résultat du paiement au marchand
Utilisez le flux de message pour la communication, et non pour montrer l’ordre interne du processus.
7.3 Association
Une association est une ligne pointillée utilisée pour relier des artefacts, des notes ou des représentations de données aux objets de flux.
Exemples :
-
Attacher un document à une tâche
-
Lier une annotation texte à une activité
-
Montrer qu’une tâche utilise un objet de données
Les trois principaux types d’objets de connexion sont les flux de séquence, les flux de message et les associations.
8. Piscines et voies
Bien que les pools et les lanes ne soient pas des objets de flux, ils fournissent un contexte essentiel pour comprendre qui réalise chaque activité.
Pool
Un pool représente un participant dans un processus.
Exemples :
-
Client
-
Fournisseur
-
Banque
-
Société
-
Organisme gouvernemental
-
Système externe
Un pool peut contenir un processus entier ou être représenté comme un participant en boîte noire sans détails internes.
Lane
Une lane divise un pool selon la responsabilité, le rôle, le département, le système ou l’emplacement.
Exemples :
-
Service client
-
Finance
-
Entrepôt
-
Gérant
-
Système de paiement
Les lanes aident à répondre à la question :
Qui est responsable de cette activité ?
Ils peuvent également révéler les transferts, les retards, le travail redondant et la propriété floue.
9. Objets de données et autres éléments de soutien
Les objets de données ne sont pas des objets de flux, mais ils fournissent un contexte utile concernant les informations utilisées, créées ou modifiées par les activités.
Exemples :
-
Formulaire de demande
-
Facture
-
Bon de commande
-
Dossier client
-
Document d’approbation
-
Étiquette d’expédition
Un objet de données pourrait être connecté à une activité de cette manière :
Formulaire de demande → Examiner la demande
Les objets de données identifient les informations pertinentes, mais ils ne représentent pas nécessairement chaque élément de données traité par le processus.
Les autres éléments de soutien incluent :
-
Magasins de données :Emplacements persistants où les données sont stockées
-
Annotations textuelles :Notes explicatives
-
Groupes : Organisation visuelle des éléments connexes
-
Associations :Liens entre les éléments d’appui et les objets de flux
10. Une méthode étape par étape pour modéliser un processus
Étape 1 : Définir le périmètre du processus
Déterminez où le processus commence et se termine.
Par exemple :
De : Le client soumet une commande
À : La commande est expédiée ou rejetée
Évitez de modéliser l’ensemble de l’organisation dans un seul diagramme.
Étape 2 : Identifier les participants
Listez les personnes, départements, systèmes ou organisations impliqués.
Exemples :
-
Client
-
Équipe commerciale
-
Département financier
-
Entrepôt
-
Passerelle de paiement
Ces éléments peuvent devenir des pools ou des voies.
Étape 3 : Identifier le déclencheur de départ
Demandez :
Qu’est-ce qui fait commencer ce processus ?
Utilisez l’événement de départ approprié :
-
Message
-
Chronomètre
-
Déclencheur conditionnel
-
Signal
-
Aucun
Étape 4 : Liste des activités principales
Écrivez chaque activité au format verbe et objet :
-
Réceptionner la commande
-
Valider la commande
-
Calculer le total
-
Approuver le paiement
-
Expédier la commande
À ce stade, ne vous inquiétez pas de chaque exception.
Étape 5 : Ajouter des décisions
Recherchez des questions telles que :
-
La commande est-elle complète ?
-
Le paiement est-il approuvé ?
-
Le stock est-il disponible ?
-
Le client est-il éligible ?
-
La date limite est-elle dépassée ?
Utilisez des passerelles pour représenter l’impact de la réponse sur le processus.
Étape 6 : Ajouter un travail parallèle
Identifiez les activités qui peuvent se produire simultanément.
Par exemple :
-
Mettre à jour le stock
-
Envoyer une confirmation
-
Créer une facture
Utilisez des passerelles parallèles lorsque toutes les branches doivent être terminées ou synchronisées.
Étape 7 : Ajouter des événements intermédiaires et des événements limites
Demandez ce qui peut se produire pendant que le travail est en cours :
-
L’activité a-t-elle une date limite ?
-
Peut-elle être annulée ?
-
Une erreur peut-elle survenir ?
-
Un message externe peut-il arriver ?
-
Le processus doit-il être escaladé s’il prend trop de temps ?
Étape 8 : Ajouter des événements de fin
Identifiez tous les résultats significatifs :
-
Terminé
-
Rejeté
-
Annulé
-
Échoué
-
Escaladé
-
Compensé
Étape 9 : Ajouter des données et des annotations
Inclure les documents, les systèmes, les notes et les règles métier uniquement là où elles améliorent la compréhension.
Étape 10 : Examiner le diagramme
Vérifiez que :
-
Chaque chemin de processus a un début clair
-
Chaque chemin se termine finalement
-
Les conditions des passerelles sont compréhensibles
-
Les activités ont des responsables clairs
-
Les flux de séquence montrent l’ordre réel
-
Les flux de messages sont utilisés uniquement entre les participants
-
Aucune passerelle n’est utilisée comme une tâche
-
Le diagramme n’est pas surchargé de détails inutiles
11. Erreurs courantes de modélisation BPMN
Erreur 1 : Utiliser une passerelle comme activité de décision
Une passerelle doit orienter le processus, et non effectuer l’analyse.
Modèle faible :
◇ Vérifier le score de crédit
Meilleur modèle :
Vérifier le score de crédit → Approbation du crédit ?
L’activité effectue la vérification. La passerelle effectue le routage en fonction du résultat.
Erreur 2 : Utilisation d’un flux de séquence entre des pools séparés
Le flux de séquence représente l’ordre interne du processus. La communication entre participants distincts doit utiliser un flux de message.
Concept incorrect :
Pool Client ── flux de séquence plein ── Pool Vendeur
Meilleur concept :
Pool Client ── flux de message pointillé ── Pool Vendeur
Erreur 3 : Laisser les chemins de passerelle non étiquetés
Une passerelle non étiquetée crée une ambiguïté.
Plutôt que :
◇ → Chemin A
→ Chemin B
Utilisez :
◇
├── Approuvé
└── Rejeté
Erreur 4 : Utilisation d’une passerelle exclusive pour un travail parallèle
Si toutes les activités doivent avoir lieu, ne pas utiliser une passerelle exclusive.
Incorrect :
◇ ├── Envoyer la confirmation
└── Mettre à jour l'inventaire
Cela signifie qu’un seul chemin est sélectionné.
Utilisez une passerelle parallèle si les deux activités doivent avoir lieu :
+ ├── Envoyer la confirmation
└── Mettre à jour l'inventaire
Erreur 5 : Utiliser une passerelle parallèle pour un travail conditionnel
Une passerelle parallèle active chaque chemin sortant. Si seulement certains chemins doivent s’exécuter, utilisez une passerelle exclusive ou inclusive.
Erreur 6 : Modéliser chaque action mineure
Un diagramme peut devenir illisible si chaque clic, saisie de champ et action système interne est inclus.
Modélisez au niveau adapté à votre public :
-
Les cadres ont besoin des étapes majeures
-
Les responsables de processus ont besoin des responsabilités et des décisions
-
Les développeurs peuvent avoir besoin de détails au niveau de l’implémentation
-
Les auditeurs peuvent avoir besoin de contrôles et de preuves
Erreur 7 : Créer des chemins sans issue
Chaque chemin de flux de séquence doit finalement atteindre un événement de fin approprié ou une frontière de sous-processus clairement définie.
Erreur 8 : Mélanger inutilement la logique métier et l’implémentation technique
Un diagramme de processus métier doit expliquer d’abord le processus. Les détails techniques ne doivent être inclus que lorsqu’ils aident le public cible.
12. Conventions pratiques de nommage
Un nommage cohérent rend les diagrammes plus faciles à lire.
Événements
Nommez les événements avec un résultat, une occurrence ou une condition :
-
Commande reçue
-
Paiement confirmé
-
Délai atteint
-
Client a annulé
-
Une erreur s’est produite
Activités
Utilisez :
Verbe + objet
Exemples :
-
Examiner le contrat
-
Approuver la demande
-
Mettre à jour le compte
-
Envoyer une notification
Passerelles
Les passerelles sont souvent les plus claires lorsqu’elles sont associées à une question :
-
La demande est-elle complète ?
-
Le paiement est-il approuvé ?
-
Le stock est-il disponible ?
-
Le délai est-il dépassé ?
Les chemins sortants doivent contenir les réponses :
-
Oui / Non
-
Approuvé / Rejeté
-
Disponible / Indisponible
Événements de fin
Nommez les événements de fin selon le résultat :
-
Commande terminée
-
Demande rejetée
-
Paiement échoué
-
Affaire annulée
13. Choix du bon passerelle
Utilisez ce guide de décision :
| Besoin de modélisation | Passerelle à utiliser |
|---|---|
| Choisissez exactement un chemin en fonction des conditions | Passerelle exclusive |
| Démarrez chaque chemin sortant | Passerelle parallèle |
| Choisissez un ou plusieurs chemins en fonction des conditions | Passerelle inclusive |
| Suivez le chemin du premier événement qui se produit | Passerelle basée sur les événements |
| Appliquer des règles de routage très spécialisées | Passerelle complexe |
Un test mental rapide :
-
Un seul chemin ? Exclusive
-
Tous les chemins ? Parallèle
-
Certains chemins ? Inclusive
-
Premier événement ? Basé sur les événements
-
Logique personnalisée inhabituelle ? Complexe
14. Un exemple complet : Processus de remboursement client
Considérez un processus de remboursement client.
Début : Demande de remboursement reçue
↓
Examiner la demande de remboursement
↓
La demande est-elle éligible ?
├── Non
│ ↓
│ Envoyer une notification de rejet
│ ↓
│ Fin : Remboursement rejeté
│
└── Oui
↓
Approuver le remboursement
↓
Passerelle parallèle
├── Émettre le remboursement
└── Mettre à jour le compte client
↓
Fusion parallèle
↓
Envoyer la confirmation du remboursement
↓
Fin : Remboursement terminé
Ce modèle illustre :
-
Un événement de démarrage par message
-
Activités utilisateur ou manuelles
-
Une passerelle exclusive
-
Un chemin de rejet
-
Une séparation parallèle
-
Une jonction parallèle
-
Une activité de confirmation
-
Différents résultats finaux
Si le service de remboursement peut échouer, ajoutez un événement d’erreur à la limite à Émettre un remboursement:
Émettre un remboursement
│
└── Erreur → Créer une demande de revue manuelle
Si le remboursement doit être effectué dans les cinq jours ouvrables, ajoutez un événement temporisateur à la limite :
Émettre un remboursement
│
└── Délai de 5 jours → Escalader le remboursement
15. Une feuille de mémoire compacte des symboles BPMN
| Catégorie de symbole | Signification | Utilisation typique |
|---|---|---|
| Cercle fin | Événement de départ | Commencer un processus |
| Cercle double | Événement intermédiaire | Attendre, envoyer, recevoir ou réagir |
| Cercle épais | Événement de fin | Terminer un chemin de processus |
| Rectangle arrondi | Tâche ou activité | Effectuer un travail |
| Rectangle arrondi avec un plus | Sous-processus réduit | Regrouper les travaux détaillés |
| Losange avec X | Passerelle exclusive | Choisir un chemin |
| Losange avec un plus | Passerelle parallèle | Exécuter tous les chemins |
| Losange avec un cercle | Passerelle inclusive | Exécuter un ou plusieurs chemins |
| Losange avec marqueur d’événement | Passerelle basée sur un événement | Suivre le premier événement |
| Flèche pleine | Flot de séquence | Afficher l’ordre interne |
| Flèche pointillée | Flot de message | Afficher la communication |
| Connecteur pointillé | Association | Lier des notes ou des données |
| Pool | Participante | Représenter une organisation ou un processus |
| Ligne | Rôle ou responsabilité | Attribuer la propriété |
| Forme de document ou de données | Objet de données | Afficher les informations utilisées ou produites |
16. Principes finaux de modélisation
Les diagrammes BPMN les plus efficaces suivent quelques principes fondamentaux :
-
Utilisez des événements pour les choses qui se produisent.
-
Utilisez des activités pour le travail effectué par les personnes ou les systèmes.
-
Utilisez des passerelles pour contrôler ou synchroniser les chemins.
-
Utilisez des flux de séquence pour l’ordre interne du processus.
-
Utilisez des flux de messages pour la communication entre les participants.
-
Libellez clairement les décisions et les conditions sortantes.
-
Utilisez des sous-processus pour contrôler la complexité.
-
Montrez la responsabilité à l’aide des piscines et des files.
-
Utilisez des événements limites pour les délais d’attente, les erreurs et les interruptions.
-
Modélisez au niveau adapté au public.
-
Donnez à chaque chemin significatif un résultat clair.
-
Préférez des diagrammes simples et compréhensibles aux diagrammes trop complexes.
Dès que ces trois idées fondamentales deviennent familières —les événements se produisent, les activités sont exécutées et les passerelles contrôlent le flux—la plupart des diagrammes BPMN deviennent beaucoup plus faciles à lire et à créer.
Cette publication est également disponible en Deutsch, English, Español, فارسی, English, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, Việt Nam, 简体中文 : liste des langues séparées par une virgule, 繁體中文 : dernière langue.