Guide BPMN avec Visual Paradigm

1. Qu’est-ce que le BPMN

Modélisation et notation des processus métier (BPMN)est un langage visuel normalisé pour décrire comment le travail circule dans un processus. Il aide les parties prenantes métier, les analystes et les équipes techniques à discuter du même flux de travail en utilisant des symboles cohérents. Le BPMN est maintenu par l’Object Management Group ; le BPMN 2.0.2 est publié en tant que norme ISO/IEC 19510.

Un diagramme BPMN est plus qu’un organigramme : ses symboles ont des significations définies, et ses règles de connexion distinguent le flux de processus des messages entre les participants. Un modèle utile peut documenter le processus actuel (« tel quel »), clarifier un processus proposé (« tel que prévu »), et aider les équipes à repérer les retards, les transferts, les retouches ou les chemins d’exception manquants.

2. Concepts fondamentaux du BPMN

Les principaux blocs de construction du BPMN sont les objets de flux, les objets de connexion, les couloirs de nage (swimlanes), les données et les artefacts.

Événements

Le contour et le marqueur d’un événement communiquent son rôle et son déclencheur :

• Événement de début :Démarre un chemin de processus.

• Événement intermédiaire :Se produit pendant le processus, par exemple la réception d’un message ou l’expiration d’un minuteur.

• Événement de fin :Termine un chemin. Différents types d’événements de fin peuvent indiquer différents résultats, tels qu’une terminaison normale ou une erreur.

• Événement de bordure :Attaché à une activité ou un sous-processus pour montrer un événement qui peut l’interrompre ou l’affecter, comme un délai d’attente.

Utilisez un événement de messagelorsque le processus répond à une communication, et un événement de minuteurlorsque le timing fait partie de la règle du processus, comme une date limite.

Activités

Nommez les activités avec un verbe + objet, par exemple « Vérifier l’inventaire », « Approuver le paiement » ou « Envoyer une confirmation ». Utilisez :

• Tâchepour une étape unique.

• Sous-processuslorsqu’une étape possède suffisamment de détails pour être modélisée séparément.

• Activité d’appellorsque vous réutilisez un processus défini globalement, si votre approche de modélisation le permet.

Les marqueurs de tâche courants peuvent spécifier le type de travail, tel qu’un travail effectué par un utilisateur, manuel ou automatisé. Ajoutez ce détail uniquement lorsqu’il aide les lecteurs ou la mise en œuvre.

Passerelles

Choisissez une passerelle en fonction de la logique du processus, et non pas simplement de la forme que vous souhaitez dessiner :

• Exclusif (XOR) :Empruntez l’un des chemins sortants. Exemple : « En stock ? » → Oui ou Non.

• Parallèle (ET) :Démarre tous les chemins sortants ; une jonction correspondante peut attendre tous les chemins requis.

• Inclusive (OU) :Empruntez un ou plusieurs chemins sortants, selon les conditions.

• Basé sur les événements :Le prochain chemin est déterminé par l’événement qui se produit en premier, comme une réponse de paiement ou un délai d’attente.

Étiquetez les flux de décision sortants avec des conditions, telles que Oui / Non ou Approuvé / Rejeté. Lorsqu’une passerelle divise un flux, clarifiez la logique de fusion. Une fusion exclusive réunit les chemins alternatifs ; une jonction parallèle synchronise les chemins qui ont été démarrés en parallèle.

Connexion des objets et des pools

Un flux de séquence montre l’ordre du processus et reste généralement à l’intérieur d’un seul pool. Un flux de message montre la communication entre des pools distincts, par exemple un client envoyant une commande à une entreprise. N’utilisez pas un flux de message pour montrer la tâche interne suivante, ni un flux de séquence pour représenter la communication entre des participants distincts.

Les pools peuvent représenter des participants indépendants, tels qu’un client, une entreprise et un fournisseur de paiement. Les couloirs à l’intérieur d’un pool montrent les rôles ou les départements. Gardez les limites de responsabilité significatives : un couloir doit clarifier qui effectue le travail, et non simplement décorer le diagramme.

3. Un flux de travail de modélisation pratique

1. Définissez le périmètre.Énoncez le déclencheur, le résultat et les limites du processus. Par exemple : « De la réception d’une commande à la confirmation de l’expédition. »

2. Identifiez les participants et les rôles.Décidez quels participants nécessitent des pools séparés et quelles responsabilités doivent être attribuées aux couloirs.

3. Décrivez le scénario idéal.Listez les étapes ordinaires dans l’ordre avant d’ajouter des passerelles et des chemins d’exception.

4. Ajoutez des événements et des décisions. Affichez des déclencheurs, des résultats, des règles métier et des chemins alternatifs significatifs.

5. Ajoutez des transferts et des données.Marquez les communications entre les participants et les informations nécessaires ou produites là où cela améliore la compréhension.

6. Vérifiez l’exhaustivité.Parcourez chaque chemin d’un point de départ à un point d’arrivée. Confirmez que les passerelles ont des conditions compréhensibles et que les chemins d’exception ne disparaissent pas de manière ambiguë.

7. Examinez avec les utilisateurs du processus.Validez le modèle avec les personnes qui exécutent ou reçoivent le travail. Révisez-le lorsqu’il diffère de la pratique réelle.

8. Gardez le diagramme lisible.Utilisez une nomenclature cohérente, minimisez les lignes qui se croisent et déplacez les sous-processus détaillés vers des diagrammes séparés si nécessaire.

Commencez par un modèle qui répond à la question métier. Ajouter tous les symboles BPMN ou détails d’implémentation d’un coup rend souvent le diagramme plus difficile à examiner.

4. Exemple : exécution de commande en ligne

Périmètre :De la soumission de la commande par le client jusqu’à la confirmation de l’expédition. Cet exemple se concentre sur le processus de l’entreprise et utilise une piscine client distincte pour montrer la commande entrante et la confirmation sortante.

Récit du processus

1. Le client soumet une commande.

2. L’entreprise reçoit la commande et vérifie les stocks.

3. Si un article n’est pas disponible, l’entreprise informe le client et termine ce chemin de commande.

4. Si l’article est disponible, l’entreprise traite le paiement.

5. Si le paiement est refusé, l’entreprise informe le client et termine ce chemin.

6. Si le paiement est approuvé, l’entrepôt prépare et emballe la commande.

7. L’entreprise remet le colis au transporteur et envoie une confirmation d’expédition.

Diagramme textuel

Piscine client :
(Début) → Soumettre une commande ──message──▶

Piscine entreprise :
(Début de message : commande reçue)
  → Vérifier les stocks
  → XOR : En stock ?
      Non  → Informer le client : indisponible → (Fin)
      Oui → Traiter le paiement
             → XOR : Paiement approuvé ?
                 Non  → Informer le client : paiement refusé → (Fin)
                 Oui → Préparer et emballer la commande
                         → Remettre le colis au transporteur
                         → Envoyer une confirmation d'expédition ──message──▶ Client
                         → (Fin)

Code PlantUML personnalisé BPMN (Uniquement pris en charge par l’éditeur VPasCode)

@startuml
title Diagramme de processus métier d'exécution de commande
<style>
    element { MaximumWidth 160 }
    start   { Backgroundcolor #00695C }
    stop    { Backgroundcolor #C2185B }
    activity{ Backgroundcolor #81D4FA; MaximumWidth 150 }
    diamond { Backgroundcolor #FFB74D; MaximumWidth 80 }
    arrow   { LineColor #424242; Fontcolor #000000 }
    swimlane{ Fontcolor #000000; FontSize 14 }
</style>

|#F0F8FF|Client|
start
:<<SendTask>>
Soumettre une commande;

|#E8F5E9|Entreprise|
:<<ReceiveTask>>
Commande reçue;
:<<UserTask>>
Vérifier les stocks;
if (En stock ?) then (oui)
  :<<ServiceTask>>
  Traiter le paiement;
  if (Paiement approuvé ?) then (oui)
    :<<ManualTask>>
    Préparer et emballer la commande;
    :<<SendTask>>
    Remettre le colis au transporteur;
    :<<SendTask>>
    Envoyer une confirmation d'expédition;
  else (non)
    :<<SendTask>>
    Informer le client : paiement refusé;
  endif
else (non)
  :<<SendTask>>
  Informer le client : indisponible;
endif
stop
@enduml

Utiliser flux de séquence pour les étapes internes de l’entreprise et flux de messages entre les pools Client et Entreprise. Étiqueter chaque flux sortant de chaque passerelle XOR avec ses conditions. Dans Visual Paradigm, les questions « En stock ? » et « Paiement approuvé ? » peuvent être placées comme étiquettes de passerelle, tandis que les flèches sortantes portent « Oui » et « Non ».

Extensions possibles : Ajouter un événement de limite de temporisation au traitement du paiement si l’entreprise dispose d’une date limite de paiement ; ajouter un chemin d’exception en cas d’échec de la remise au transporteur ; ou modéliser la préparation et l’emballage comme un sous-processus s’il nécessite son propre flux de travail détaillé.

5. Construction du modèle dans Visual Paradigm

Visual Paradigm fournit un outil de modélisation BPMN 2.0 et prend en charge le drill-down des sous-processus, de sorte qu’un processus de haut niveau peut être lié à un diagramme de processus plus détaillé. Ses fonctionnalités BPMN incluent également la documentation des procédures de travail et la modélisation des processus « tel quel » et « tel que prévu ».

Séquence de construction pratique :

1. Créer un diagramme de processus métier BPMN dans Visual Paradigm.

2. Ajouter un pool Client et un pool Entreprise; diviser le pool Entreprise en couloirs tels que Service Client, Entrepôt et Expédition si ces responsabilités sont importantes.

3. Placer l’événement de démarrage et les activités, puis ajouter les passerelles d’inventaire et de paiement.

4. Dessiner les flux de séquence au sein du pool Entreprise ; utiliser les flux de messages pour les échanges avec le Client.

5. Étiqueter les tâches et les chemins conditionnels dans un langage clair. Ajouter des objets de données, tels qu’une Commande ou un Résultat de Paiement, uniquement là où ils aident les lecteurs à comprendre le processus.

6. Organiser le diagramme de manière à ce que le flux principal soit lu de manière cohérente — souvent de gauche à droite — et minimiser les connecteurs qui se croisent.

7. Examiner le diagramme avec les parties prenantes. Si les détails d’une étape obscurcissent le chemin principal, envisager de placer ces détails dans un diagramme de sous-processus.

8. Enregistrer et partager le modèle dans le format et l’espace de travail appropriés à votre équipe.

Visual Paradigm met en avant la modélisation de diagrammes BPMN, le drill-down des processus, la documentation des procédures de travail et la modélisation « tel quel » / « tel que prévu ». La disponibilité de certaines fonctionnalités peut dépendre de l’édition.

6. Erreurs courantes de modélisation

• Utilisation du mauvais connecteur : le flux de séquence représente l’ordre interne du processus ; le flux de message représente la communication entre les participants.

• Utilisation d’une passerelle sans logique claire : étiquetez la décision et ses conditions de sortie.

• Traiter chaque action comme un pool distinct : utilisez des couloirs pour les responsabilités au sein d’un même participant ; des pools séparés pour des participants distincts.

• Laisser les chemins flous : montrez ce qui se produit en cas de refus, d’expiration, de données manquantes et d’autres exceptions pertinentes.

• Surcharger un seul diagramme : utilisez des sous-processus pour séparer les travaux détaillés de la vue d’ensemble.

• Modéliser l’idéal au lieu de la réalité : documentez le processus actuel avec précision avant de proposer des améliorations.

• Ajouter des détails sans but : incluez des données, des événements et des marqueurs de tâche lorsqu’ils répondent à une question de modélisation ou d’examen.

7. Liste de vérification rapide

• Le diagramme a-t-il un début et une fin clairs pour chaque chemin pertinent ?

• Un lecteur peut-il identifier qui réalise chaque activité ?

• Les décisions et les conditions de sortie sont-elles explicites ?

• Les flux de séquence et les flux de messages sont-ils utilisés de manière appropriée ?

• Les exceptions et les résultats alternatifs sont-ils représentés ?

• Le diagramme est-il lisible à la taille de visualisation prévue ?

• Les personnes qui exécutent le processus ont-elles confirmé qu’il est exact ?