BPMN vs. Diagrammes de flux : Quand et pourquoi utiliser le BPMN pour les débutants

Les diagrammes de flux et les diagrammes BPMN montrent tous deux comment le travail progresse d’une étape à l’autre. La différence réside principalement dans l’objectif et la précision:

Un diagramme de fluxest un diagramme à usage général pour représenter la logique, les étapes et les décisions.
BPMN, ou Modélisation et Notation des Processus Métiers, est un langage normalisé conçu spécifiquement pour modéliser les processus métiers, les responsabilités, les événements, les messages, les données et l’automatisation.

Un diagramme de flux est souvent le moyen le plus rapide d’expliquer une procédure simple. Le BPMN devient plus utile lorsqu’un processus implique plusieurs personnes, départements, organisations, exceptions, délais ou systèmes logiciels.

Le BPMN est maintenu en tant que spécification formelle par l’Object Management Group. Sa notation est conçue pour être compréhensible par les parties prenantes métier tout en restant suffisamment précise pour soutenir l’implémentation technique. La spécification formelle actuellement couramment utilisée est le BPMN 2.0.2.

1. Qu’est-ce qu’un diagramme de flux ?

Un diagramme de flux est une représentation visuelle d’une séquence d’étapes. Il utilise des formes simples reliées par des flèches pour montrer comment une tâche ou une décision progresse.

Un diagramme de flux typique comprend :

Ovale : Début ou fin
Rectangle : Processus ou activité
Losange : Décision
Flèche : Sens du flux
Parallélogramme : Entrée ou sortie
Forme de document : Document ou rapport

Par exemple, un diagramme de flux de remboursement de frais simple pourrait ressembler à ceci :

Début
  ↓
L'employé soumet un rapport de frais
  ↓
Le manager examine le rapport
  ↓
Est-ce approuvé ?
 ├── Non → Retourner le rapport à l'employé
 └── Oui → La finance émet le paiement
  ↓
Fin

Les diagrammes de flux sont faciles à créer et à comprendre car ils utilisent un petit nombre de symboles familiers. Ils sont utiles pour :

Expliquer une procédure simple
Documenter un algorithme
Décrire les étapes de dépannage
Cartographier un flux de travail personnel ou départemental
Former les employés
Montrer une séquence de décision de base

La principale limitation est que les organigrammes traditionnels ne représentent pas toujours clairement qui exécute chaque tâche, comment différentes organisations communiquent, ou ce qui se passe lorsque des événements interrompent le processus normal.

2. Qu’est-ce que la BPMN ?

BPMN signifie Modélisation et notation des processus métier. Il s’agit d’une notation normalisée pour décrire les processus métier de manière cohérente.

Les diagrammes BPMN peuvent représenter :

Activités et tâches
Événements de démarrage, intermédiaires et de fin
Décisions et logique de branchement
Travail parallèle
Participants et responsabilités
Communication entre départements ou organisations
Messages
Entrées et sorties de données
Minuteries, erreurs, annulations et escalades
Sous-processus réutilisables
Activités humaines et automatisées

La BPMN est basée sur les concepts des organigrammes, mais elle ajoute un vocabulaire beaucoup plus riche pour les opérations commerciales. Ses catégories principales comprennent les objets de flux, les objets de connexion, les couloirs de nage et les artefacts.

Un processus BPMN simplifié pourrait être décrit comme :

Le client soumet une commande
        ↓
Le système de vente enregistre la commande
        ↓
L'entrepôt vérifie les stocks
        ↓
L'article est-il disponible ?
 ├── Non → Informer le client
 └── Oui → Préparer et emballer la commande
                 ↓
           Le transporteur livre la commande

Dans un véritable diagramme BPMN, chaque participant pourrait apparaître dans un pool ou une voie distinct, et la communication entre eux pourrait être représentée par des flux de messages.

3. BPMN vs. Diagrammes de flux : un aperçu

Caractéristique	Diagramme de flux	BPMN
Objectif principal	Afficher la logique ou la séquence générale	Modéliser les processus métier
Normalisation	Souvent informel ou spécifique à un outil	Notation de modélisation internationale formelle
Courbe d’apprentissage	Faible	Modérée
Nombre de symboles	Ensemble restreint	Vocabulaire plus vaste et spécialisé
Rôles et responsabilités	Généralement limité	Explicitement représentés par des pools et des voies
Communication inter-organisationnelle	Difficile à représenter avec précision	Représenté par des flux de messages
Exceptions et interruptions	Généralement simplifié	Les événements peuvent représenter des minuteries, des erreurs, des messages et des escalades
Activités parallèles	Possible mais souvent peu clair	Pris en charge par des passerelles parallèles
Support à l’automatisation	Limité	Peut être suffisamment détaillé pour soutenir la mise en œuvre
Meilleur usage	Procédures et logique simples	Processus complexes, collaboratifs et répétables
Public cible	Utilisateurs généraux, étudiants, équipes	Analystes, propriétaires de processus, développeurs, gestionnaires
Niveau de détail	Faible à moyen	Moyen à très élevé

4. La différence centrale : logique générale vs sémantique des processus métier

La distinction la plus importante est qu’un organigramme répond principalement à :

« Que se passe-t-il ensuite ? »

La BPMN peut répondre à plusieurs questions supplémentaires :

Qui effectue chaque activité ?
Quel département ou organisation est impliqué ?
L’interaction est-elle interne ou externe ?
L’étape suivante est-elle provoquée par un message, un minuteur, une erreur ou une condition ?
Les activités peuvent-elles se produire en parallèle ?
Quelles données sont requises ?
Que se passe-t-il si le processus échoue ?
Quelles tâches sont effectuées par des personnes, des systèmes ou des règles ?
Ce processus peut-il être automatisé ou surveillé ?

Par exemple, un organigramme pourrait indiquer :

Examiner la demande → Approuver la demande → Envoyer une confirmation

Un modèle BPMN pourrait distinguer :

Le client soumet la demande.
L’équipe du service client la valide.
Un système automatisé vérifie les informations de crédit.
Un gestionnaire approuve les demandes au-dessus d’un certain montant.
Un minuteur déclenche un rappel après trois jours ouvrables.
Un message est envoyé au client.
Un chemin d’erreur gère les documents manquants.

Le diagramme de flux communique le plan général. Le BPMN communique la structure opérationnelle.

5. Les principaux éléments BPMN dont les débutants ont besoin

Le BPMN contient de nombreux symboles, mais les débutants n’ont besoin que d’un petit ensemble de base au début.

Événements

Les événements représentent quelque chose qui se produit plutôt que quelque chose que quelqu’un fait.

Ils sont dessinés sous forme de cercles.

Les types courants incluent :

Événement de démarrage :Démarre un processus
Événement intermédiaire :Se produit pendant un processus
Événement de fin :Complète un processus
Événement de message :Un message est reçu ou envoyé
Événement de minuteur :Une date limite ou un moment planifié est impliqué
Événement d’erreur :Une erreur se produit
Événement d’escalade :Une question nécessite une attention de niveau supérieur

Exemples :

Un client passe une commande.
Une date limite de paiement expire.
Un e-mail est reçu.
Une erreur système se produit.

Activités

Les activités représentent un travail en cours d’exécution. Elles sont dessinées sous forme de rectangles aux coins arrondis.

Elles peuvent être :

Tâches : Unités individuelles de travail
Sous-processus : Groupes d’activités liées
Tâches utilisateur : Travail accompli par une personne via un système
Tâches de service : Travail effectué automatiquement par un logiciel
Tâches manuelles : Travail effectué sans assistance du système
Tâches de règles métier : Travail déterminé par une règle métier ou un service de décision

Pour un débutant, l’idée la plus importante est simple :

Des événements se produisent ; des activités sont réalisées.

Passerelles

Les passerelles contrôlent la manière dont le processus se divise ou se joint. Elles sont dessinées sous forme de losanges.

Les types de passerelles courants incluent :

Passerelle exclusive : Un seul chemin est sélectionné
Passerelle parallèle : Plusieurs chemins se produisent en même temps
Passerelle inclusive : Un ou plusieurs chemins peuvent être sélectionnés
Passerelle basée sur des événements : Le chemin suivant dépend de l’événement qui se produit en premier

Exemple de décision exclusive :

Paiement reçu ?
 ├── Oui → Expédier la commande
 └── Non → Envoyer un rappel de paiement

Exemple de travail en parallèle :

Commande approuvée
      ↓
 ┌───────────────┬────────────────┐
 │               │                │
Emballer la commande   Préparer la facture   Informer le client
 │               │                │
 └───────────────┴────────────────┘
      ↓
Commande prête à être expédiée

Flux de séquence

Une flèche pleine indique l’ordre dans lequel les activités, événements et passerelles se produisent au sein du même processus.

Tâche A → Tâche B → Tâche C

Flux de message

Une flèche en pointillés représente la communication entre des participants ou des pools distincts.

Par exemple :

Client ──message──> Entreprise
Entreprise ──confirmation──> Client

Un flux de message est différent d’un flux de séquence :

Flux de séquence :Montre l’ordre des travaux au sein d’un processus
Flux de message :Montre la communication entre les participants

Pools et couloirs

Les couloirs organisent le travail par participant ou par responsabilité.

Un poolreprésente généralement un participant, une organisation, une entité commerciale ou un processus indépendant.
Un couloirdivise un pool en rôles, équipes, départements ou systèmes.

Exemple :

Couloir Client :     Soumettre la commande ─────────────── Recevoir la confirmation
                         │                              ↑
Couloir Ventes :            Examiner la commande ─────── Envoyer la confirmation

Les pools et les couloirs répondent à l’une des questions les plus importantes sur le processus :

Qui est responsable de cette étape ?

Objets de données et annotations

Les objets de données montrent les informations utilisées ou produites par une activité.

Exemples :

Formulaire de candidature
Facture
Contrat
Fiche client
Étiquette d’expédition

Les annotations ajoutent du texte explicatif sans modifier la logique du processus.

6. Quand un organigramme est le meilleur choix

Utilisez un organigramme lorsque le processus est simple, linéaire ou principalement axé sur les décisions.

Un organigramme est généralement suffisant lorsque :

Il y a un seul participant principal
Le processus ne comporte que quelques étapes
Les responsabilités n’ont pas besoin d’être mises en évidence
Il n’y a pas d’interactions complexes avec des parties externes
Le diagramme sert à une explication rapide
Le processus est exploré de manière informelle
Vous documentez un algorithme ou une routine de dépannage
Votre public n’est pas familier avec la BPMN

Par exemple, « Comment réinitialiser un mot de passe » peut être mieux représenté par un simple organigramme :

Début
  ↓
Entrez le nom d'utilisateur
  ↓
Compte trouvé ?
 ├── Non → Afficher l'erreur
 └── Oui → Envoyer l'e-mail de réinitialisation
                ↓
          L'utilisateur crée un mot de passe
                ↓
               Fin

L’utilisation de la BPMN pour ce processus pourrait ajouter une complexité inutile, sauf si l’objectif est de modéliser l’ensemble de l’opération de service, y compris la vérification d’identité, les notifications, les tâches système, l’escalade et les registres d’audit.

7. Quand la BPMN est le meilleur choix

Utilisez la BPMN lorsque vous devez modéliser un véritable processus métier plutôt que de simplement décrire une séquence.

La BPMN est particulièrement utile lorsqu’un processus comporte :

Plusieurs départements
Plusieurs rôles ou participants
Clients, fournisseurs, régulateurs ou partenaires
Passations entre équipes
Activités parallèles
Messages externes
Minuteries ou délais
Gestion des erreurs ou des exceptions
Niveaux d’approbation
Tâches système automatisées
Exigences de conformité
Efforts répétés d’amélioration des processus
Un objectif futur de l’automatisation des flux de travail

Les cas d’utilisation typiques du BPMN incluent :

Approbation de bons de commande
Traitement des demandes de prêt
Dossiers d’assurance
Intégration des employés
Escalade du support client
Traitement des factures
Retours de produits
Orientations en matière de soins de santé
Examen des contrats
Exécution des expéditions
Déclarations réglementaires
Flux de travail de déploiement de logiciels

Une règle utile est :

Si le processus franchit une frontière — entre des personnes, des équipes, des systèmes ou des organisations — le BPMN vaut généralement la peine d’être envisagé.

8. Pourquoi utiliser le BPMN ?

Un langage commun

Différents groupes décrivent souvent le même processus différemment. Un responsable commercial peut parler d’approbations, un développeur de services, et un employé de tâches quotidiennes.

Le BPMN fournit un langage visuel commun qui peut aider ces groupes à discuter du même processus. Son objectif de conception est d’être utilisable par les parties prenantes commerciales tout en étant suffisamment précis pour être traduit en composants de processus logiciels.

Responsabilité claire

Les couloirs rendent la responsabilité visible.

Au lieu de montrer :

Examiner la demande → Approuver la demande → Créer un compte

Le BPMN peut montrer :

Le client soumet une demande
Le service client valide les informations
L’équipe de crédit effectue une évaluation
Le manager approuve l’exception
Le système informatique crée le compte

Cela peut révéler un travail en double, une propriété floue et des transferts inutiles.

Meilleure analyse des exceptions

De nombreux processus réels ne suivent pas le chemin idéal. BPMN facilite la modélisation :

Informations manquantes
Demandes rejetées
Délais expirés
Paiements échoués
Erreurs système
Annulations
Escalades client
Compensation ou action corrective

Un organigramme peut montrer les exceptions, mais BPMN fournit des types d’événements spécialisés et des conventions pour les représenter plus clairement.

Support pour l’automatisation

Les modèles BPMN peuvent contenir suffisamment de détails pour guider la mise en œuvre du flux de travail. Tous les diagrammes BPMN ne sont pas exécutables, mais BPMN est plus adapté qu’un organigramme de base lorsque le modèle peut être utilisé ultérieurement pour configurer ou concevoir un processus automatisé.

Par exemple, un concepteur de processus peut distinguer entre :

Une tâche effectuée par un employé
Une tâche effectuée par un service automatisé
Une décision évaluée par une règle métier
Un message reçu d’un autre système
Un minuteur qui déclenche une action

Amélioration améliorée du processus

Un diagramme BPMN peut aider à identifier :

Goulots d’étranglement
Longues chaînes d’approbation
Saisie de données répétée
Revisions inutiles
Tâches manuelles adaptées à l’automatisation
Cheminements d’exception manquants
Passations excessives
Propriété floue
Retards causés par des parties externes

Cela rend le BPMN précieux non seulement pour documenter les processus, mais aussi pour les analyser et les redessiner.

9. Les inconvénients du BPMN

Le BPMN est puissant, mais il n’est pas toujours le bon choix.

Il présente une courbe d’apprentissage plus raide

Les organigrammes peuvent souvent être compris immédiatement. Le BPMN oblige les utilisateurs à apprendre des distinctions telles que :

Flux de séquence vs. flux de messages
Événements vs. activités
Pools vs. couloirs
Passerelles exclusives vs. passerelles parallèles
Événements interrompant vs. événements non interrompant
Événements de capture vs. événements de lancement

Les diagrammes peuvent devenir encombrés

Un grand diagramme BPMN peut contenir des dizaines de symboles et de lignes qui se croisent. Des modèles mal conçus peuvent être plus difficiles à comprendre qu’un simple organigramme.

La précision peut créer une fausse confiance

L’utilisation de symboles BPMN ne rend pas automatiquement un modèle de processus précis. Le modèle dépend toujours d’informations correctes provenant des propriétaires de processus et des experts du domaine.

Tous les publics n’ont pas besoin de tous les détails

Les cadres supérieurs peuvent souhaiter une vue d’ensemble de haut niveau du processus, tandis qu’un développeur de flux de travail peut avoir besoin d’informations détaillées sur les tâches et les exceptions. Un seul diagramme sert rarement parfaitement les deux objectifs.

Il peut être surutilisé

Une procédure interne en cinq étapes ne nécessite pas nécessairement d’événements de message, de multiples pools et de sous-processus imbriqués. La notation doit correspondre au problème.

10. Un guide de décision pratique

Utilisez ces questions pour choisir entre un organigramme et le BPMN :

Combien de participants sont impliqués ?
- Une personne ou une équipe : un organigramme peut suffire.
- Plusieurs équipes ou organisations : le BPMN est plus approprié.
Les responsabilités sont-elles importantes ?
- Si non, utilisez un organigramme.
- Si oui, utilisez des couloirs ou des pools dans le BPMN.
Y a-t-il des communications externes ?
- Si non, l’une ou l’autre notation peut convenir.
- Si oui, le BPMN peut distinguer les messages du flux de processus interne.
Y a-t-il des temporisateurs, des erreurs ou des escalades ?
- Si non, un organigramme peut suffire.
- Si oui, le BPMN offre des outils de modélisation plus clairs.
Le processus sera-t-il automatisé ?
- Si non, un organigramme peut être suffisant pour un processus simple.
- Si oui, le BPMN est généralement une meilleure base.
Le processus doit-il être réutilisé comme norme formelle ?
- Si non, utilisez la notation la plus simple que votre public comprend.
- Si oui, le BPMN offre une plus grande cohérence entre les diagrammes et les outils.
Quel est le niveau de compétence de votre public ?
- Public général : commencez par un organigramme simple ou un BPMN de haut niveau.
- Analystes et équipes techniques : utilisez le BPMN avec le niveau de détail approprié.

11. Une méthode de modélisation BPMN adaptée aux débutants

Étape 1 : Définir les limites du processus

Décidez où le processus commence et se termine.

Par exemple :

Début : Le client soumet une demande d’assistance
Fin : Le client reçoit une résolution

Évitez d’essayer de modéliser l’ensemble de l’organisation en une seule fois.

Étape 2 : Identifier les participants

Listez les personnes, les équipes, les organisations et les systèmes impliqués.

Exemple :

Client
Agent d’assistance
Équipe de support technique
Système de facturation
Responsable de service

Celles-ci peuvent devenir des pools ou des couloirs.

Étape 3 : Écrivez d’abord le chemin heureux

Documentez le processus normal sans exceptions.

Recevoir la demande
  ↓
Classifier la demande
  ↓
Enquêter sur le problème
  ↓
Résoudre le problème
  ↓
Informer le client
  ↓
Clôturer la demande

Cela vous offre une base claire avant d’ajouter de la complexité.

Étape 4 : Ajoutez des événements de début et de fin

Tout processus BPMN complet doit avoir un début et une fin clairs.

Exemples :

Début : Message reçu
Début : Minuteur atteint
Début : Le client soumet le formulaire
Fin : Dossier clos
Fin : Demande rejetée
Fin : Paiement terminé

Étape 5 : Attribuez les tâches aux participants

Placez chaque activité dans le couloir approprié.

Par exemple :

Client :       Soumettre la demande ───────────── Recevoir la résolution
Support :                    Classifier ─ Enquêter ─ Résoudre
Système :                                      Envoyer une notification

Étape 6 : Ajoutez des passerelles pour les décisions

Utilisez une passerelle exclusive lorsqu’un seul chemin doit être suivi.

Problème résolu ?
 ├── Non → Escalader
 └── Oui → Informer le client

N’utilisez pas une passerelle simplement parce qu’une tâche contient une question dans son nom. Utilisez-en une lorsque le processus se divise réellement.

Étape 7 : Ajoutez un travail parallèle avec précaution

Utilisez une passerelle parallèle lorsque les activités peuvent réellement se produire en même temps.

Par exemple, après qu’une commande est approuvée :

Réserver l’inventaire
Générer la facture
Aviser l’entrepôt

Si une activité doit se produire avant une autre, ne les modélisez pas comme parallèles.

Étape 8 : Ajouter des messages et des données

Afficher les messages lorsque les participants communiquent.

Exemples :

Le client envoie la demande
Le fournisseur envoie l’avis d’expédition
Le système envoie un e-mail d’approbation

Ajoutez des objets de données lorsque l’information est importante pour l’activité.

Étape 9 : Ajouter des exceptions

Demandez :

Que se passe-t-il si les informations requises manquent ?
Que se passe-t-il si le client ne répond pas ?
Que se passe-t-il si le paiement échoue ?
Que se passe-t-il si le délai expire ?
Que se passe-t-il si le système est indisponible ?
Que se passe-t-il si un employé rejette la demande ?

Modélisez uniquement les exceptions qui sont importantes pour comprendre ou améliorer le processus.

Étape 10 : Examiner le diagramme avec les propriétaires du processus

Un diagramme doit être examiné par les personnes qui effectuent le travail. Elles peuvent identifier :

Étapes manquantes
Responsabilités incorrectes
Solutions de contournement informelles
Exceptions non documentées dans les procédures
Retards et approbations inutiles

12. Exemple : Version organigramme vs. Version BPMN

Organigramme simple

Supposons qu’un client retourne un produit :

Début
  ↓
Le client demande un retour
  ↓
Le retour est-il éligible ?
 ├── Non → Rejeter la demande
 └── Oui → Envoyer l'étiquette de retour
                ↓
          Recevoir l'article retourné
                ↓
          Émettre un remboursement
                ↓
               Fin

C’est facile à comprendre et peut suffire pour la formation ou un aperçu rapide.

Version orientée BPMN

Un modèle BPMN plus détaillé distinguerait les participants :

Client

Demander un retour
Emballer le produit
Envoyer le produit

Service client

Valider la demande de retour
Approuver ou rejeter le retour
Envoyer les instructions de retour

Entrepôt

Recevoir le produit
Inspecter l’état

Finance

Émettre un remboursement

Système

Envoyer une confirmation
Mettre à jour l’inventaire
Enregistrer le remboursement

Le modèle pourrait également représenter :

Un message du client
Un minuteur pour la date limite de retour
Une passerelle basée sur l’état du produit
Une erreur si l’article n’est pas reçu
Des activités d’inventaire et de remboursement parallèles
Un message confirmant le remboursement

Le diagramme de flux explique la logique générale. Le BPMN explique la collaboration opérationnelle.

13. Erreurs courantes des débutants

Erreur 1 : Utiliser tous les symboles BPMN

Les débutants essaient parfois d’utiliser autant de symboles que possible. Cela rend les diagrammes plus difficiles à lire.

Commencez par :

Événements de début et de fin
Tâches
Portes exclusives
Flux de séquence
Pools et couloirs
Flux de messages lorsque nécessaire

Ajoutez des éléments avancés uniquement lorsqu’ils résolvent un problème de modélisation réel.

Erreur 2 : Confondre le flux de séquence et le flux de message

Le flux de séquence montre la progression à l’intérieur d’un processus. Le flux de message montre la communication entre des participants distincts.

N’utilisez pas les flux de message simplement pour donner un aspect différent aux lignes.

Erreur 3 : Mélanger incorrectement les pools et les couloirs

Utilisez des couloirs pour diviser les responsabilités au sein d’un participant. Utilisez des pools séparés lorsque les participants sont des entités ou des processus indépendants.

Par exemple :

Les ventes, la finance et les opérations peuvent être des couloirs au sein d’une même entreprise.
Le client et le fournisseur peuvent être des pools séparés.

Erreur 4 : Traiter chaque décision comme exclusive

Une porte exclusive signifie qu’un seul itinéraire est sélectionné. Si plusieurs itinéraires peuvent se produire simultanément, utilisez une porte parallèle. Si un ou plusieurs itinéraires optionnels peuvent survenir, envisagez une porte inclusive.

Erreur 5 : Omettre le déclencheur

Un processus doit expliquer ce qui le déclenche. « Traiter une commande » est vague à moins que le modèle ne montre si le déclencheur est :

Une commande client
Un lot planifié
Une confirmation de paiement
Un message provenant d’un autre système

Erreur 6 : Modéliser uniquement le processus idéal

Les processus réels incluent les retouches, les rejets, les délais et les escalades. Un modèle qui ne montre que le chemin idéal peut être attrayant mais opérationnellement incomplet.

Erreur 7 : Mettre trop de texte à l’intérieur des activités

Les libellés des tâches devraient généralement utiliser un format verbe-objet concis :

Examiner la candidature
Valider l’adresse
Approuver le remboursement
Envoyer la confirmation

Évitez les longs paragraphes à l’intérieur des cases de tâche. Placez les explications de soutien dans les annotations ou la documentation.

Erreur 8 : Créer un seul diagramme géant

Les grands processus doivent être divisés en sous-processus. Un diagramme de haut niveau pourrait montrer :

Recevoir la commande → Traiter le paiement → Exécuter la commande → Clôturer la commande

Chaque étape peut être liée à un diagramme plus détaillé.

14. Meilleures pratiques BPMN pour des diagrammes lisibles

Commencez par un événement de départ clair.
Terminez par un ou plusieurs états de fin significatifs.
Organisez le flux principal de gauche à droite ou de haut en bas.
Gardez les lignes de flux de séquence aussi droites que possible.
Évitez les lignes qui se croisent.
Utilisez des noms de tâches cohérents.
Gardez le diagramme principal à un niveau de détail lisible.
Utilisez des couloirs uniquement lorsque la responsabilité est importante.
Étiquetez les passerelles avec des questions ou des conditions significatives.
Étiquetez les chemins de sortie des passerelles lorsque le sens n’est pas évident.
Utilisez des sous-processus pour masquer les détails inutiles.
Distinguez les chemins normaux des chemins d’exception.
Gardez les flux de messages entre des bassins appropriés.
Utilisez les annotations avec parcimonie.
Validez le modèle avec les personnes qui exécutent le processus.
Créez des diagrammes séparés pour l’état « actuel » et l’état « futur » lors de la refonte d’un processus.

15. Quelle quantité de BPMN un débutant doit-il apprendre ?

Vous n’avez pas besoin d’apprendre l’intégralité de la spécification BPMN pour créer des diagrammes utiles.

Niveau débutant

Apprenez :

Événements de départ
Événements de fin
Tâches
Flux de séquence
Passerelles exclusives
Passerelles parallèles
Pools
Couloirs
Flux de messages
Objets de données de base

Cela suffit pour de nombreux diagrammes de processus métier.

Niveau intermédiaire

Ajouter :

Événements temporisés
Événements de messages
Événements d’erreur
Sous-processus
Activités d’appel
Tâches utilisateur
Tâches de service
Événements de bordure
Passerelles basées sur des événements
Chemins de compensation

Niveau avancé

Étude :

Diagrammes de chorégraphie
Diagrammes de conversation
Événements non interrupteurs
Sous-processus événementiels
Transactions
Compensation
Activités multi-instance
Corrélation
Sémantique d’exécution
Règles d’implémentation spécifiques à l’outil

BPMN prend en charge plusieurs types de modèles, notamment les diagrammes de processus, de collaboration, de chorégraphie et de conversation. Les débutants devraient généralement commencer par les diagrammes de processus et de collaboration ordinaires avant d’étudier les types plus spécialisés.

16. BPMN, organigrammes et notations apparentées

BPMN n’est pas la seule notation de modélisation.

Organigrammes :Idéaux pour une logique et des procédures simples
BPMN :Idéal pour les processus métier et la collaboration de flux de travail
Diagrammes d’activité UML :Utile pour le comportement des logiciels et des systèmes
DMN :Utile pour les décisions et règles métier formelles
CMMN :Utile pour un travail flexible et basé sur des cas où le chemin n’est pas entièrement prédéfini
Cartes de flux de valeur :Utile pour analyser la valeur de bout en bout et les gaspillages
Diagrammes SIPOC :Utile pour une analyse de haut niveau des fournisseurs, intrants, processus, extrants et clients

BPMN peut indiquer qu’une décision est prise, tandis qu’une notation axée sur la décision telle que DMN peut décrire les règles utilisées pour prendre cette décision. Ces notations peuvent se compléter plutôt que de se concurrencer.

17. Une règle simple

Choisissez un organigrammelorsque :

Vous devez expliquer une séquence d’étapes ou de décisions aussi rapidement et simplement que possible.

Choisissez BPMNlorsque :

Vous devez comprendre, communiquer, analyser, améliorer ou automatiser un processus métier impliquant des responsabilités, des événements, des systèmes ou des organisations.

Vous pouvez également utiliser les deux :

Commencez par un organigramme simple pour comprendre le processus global.
Convertissez-le en BPMN lorsque les rôles, les messages, les exceptions, la chronologie ou l’automatisation deviennent importants.
Créez un diagramme BPMN de haut niveau pour les dirigeants et une version détaillée pour les analystes ou les développeurs.

Conclusion

Les organigrammes et le BPMN ne sont pas des outils concurrents dans toutes les situations. Un organigramme est une explication visuelle légère. Le BPMN est un langage de modélisation structuré pour les processus nécessitant plus de clarté, de responsabilité et de détails opérationnels.

Pour les débutants, la meilleure approche consiste à commencer simplement :

Définissez les limites du processus.
Identifiez les participants.
Cartographiez le chemin normal.
Ajoutez des décisions.
Attribuez les responsabilités.
Ajoutez des messages, des minuteries, des données et des exceptions uniquement lorsqu’ils sont pertinents.
Utilisez des sous-processus pour maîtriser la complexité.

Si votre processus est court et géré par une seule personne ou une seule équipe, un organigramme est probablement suffisant. Si le processus implique plusieurs rôles, départements, systèmes, parties externes, délais ou automatisation, le BPMN fournira généralement un modèle plus clair et plus durable.

Cette publication est également disponible en Deutsch, English, Español : liste des langues séparées par une virgule, فارسی : dernière langue.