Pools et Swimlanes en BPMN

Introduction

En BPMN 2.0, les pools et swimlanes (appelées aussi lanes) servent à organiser les process et à représenter visuellement les rôles, départements ou entités impliqués dans un process métier. Ils clarifient qui est responsable de chaque tâche, et comment les participants interagissent.

Pools

• Objectif : Un pool désigne un participant principal du process ou une entité large, comme une organisation, un système ou un partenaire business. Les pools définissent les limites du process ; chacun pouvant représenter une organisation ou un département qui participe au workflow.

• Représentation visuelle : Grand rectangle englobant un process complet. Plusieurs swimlanes (lanes) peuvent être inclus, mais chaque pool marque un process ou un participant distinct.

• Exemple : Par exemple, un pool pour “Société A” et un autre pour “Société B” dans un process où ces deux entreprises interagissent.

• Cas d’usage : On utilise les pools pour la modélisation des interactions entre entités, par ex. quand une société traite avec un fournisseur, un partenaire ou un client externe. Chaque entité a son pool ; les message flows montrent la communication entre elles.

Swimlanes (Lanes)

• But : Une swimlane (ou lane) est une sous-partition dans une pool qui permet d’organiser les activités en les séparant selon des rôles, départements ou systèmes précis. Les lanes apportent de la clarté en montrant qui est responsable de chaque tâche dans la pool.

• Visualisation : Découpage horizontal ou vertical dans une pool, représenté par chaque participant (par exemple : un département, un rôle ou un système).

• Exemple : Dans une pool représentant une entreprise, on peut avoir des lanes pour “Ventes”, “Finance” et “Support Client”, avec les tâches affectées à chaque département.

• Cas d’usage : Les lanes servent à attribuer la responsabilité des tâches dans une pool, pour voir clairement qui effectue chaque activité. Par exemple, les tâches liées au traitement des factures seront dans la lane “Finance”, celles liées aux demandes clients dans la lane “Support Client”.

Collapsed Pool

• Objectif : Un collapsed pool représente un participant dans le process (entreprise, département ou système) dont le flow interne n’est pas affiché. Cela sert à montrer l’interaction entre différents participants sans dévoiler le détail de leur workflow.

• Représentation visuelle : Un grand rectangle sans activité interne visible. Généralement, seul le nom du participant apparaît, avec éventuellement des message flows entrant ou sortant pour illustrer l’interaction avec d’autres.

• Exemple : Un diagramme montre une entreprise en interaction avec un fournisseur. Les process internes de l’entreprise sont détaillés, mais le fournisseur est représenté par un collapsed pool, signalant son implication sans détailler ses étapes internes.

• Cas d’usage : Les collapsed pools sont pratiques pour mettre en avant l’interaction entre plusieurs participants sans détailler le process interne de certains. Par exemple, on montre comment un client échange avec un fournisseur externe sans afficher les procédures internes du fournisseur.

Caractéristiques clés

Pools :

• Interaction entre les process : Avec plusieurs pools, on utilise les message flows pour montrer les échanges entre les participants. Par exemple, un client envoie une commande à un fournisseur par un message flow entre leurs pools.
• Process indépendants : Chaque pool contient son propre process, indépendant des autres, même si certains échanges se font par message flows.

Swimlanes (Lanes) :

• Responsabilité et organisation : Les lanes d’un pool représentent rôles, participants ou départements responsables de tâches. Chaque lane précise qui fait quoi dans une même organisation.
• Affectation des tâches : En organisant les tâches via les swimlanes, le BPMN rend visible qui gère chaque étape du process.

Collapsed Pool :

• Représentation du participant : Un collapsed pool symbolise un participant sans montrer son workflow interne. Ça peut être une organisation externe, un département ou toute entité en interaction.
• Aucune activité interne : Le pool ne montre pas d’activités ni tâches internes, le process est masqué ou pas pertinent ici.
• Focus interaction : L’essentiel est l’interaction du collapsed pool avec les autres via des message flows, non ses étapes internes.
• Limites claires : Même si le process interne est caché, on voit clairement la frontière du participant pour indiquer sa présence dans le process.
• Vue simplifiée : Les collapsed pools simplifient les diagrammes en masquant les détails externes inutiles, pour mieux lire les échanges.

Exemples

Pool Exemple : Dans un process de supply chain :

• Un pool représente le “Fournisseur” et un autre le “Client”.
• Le process côté “Client” inclut la création de commande, tandis que le process “Fournisseur” gère le traitement et l’expédition.
• Message flows entre les pools illustrent la communication comme l’envoi de la commande et la réception de la confirmation d’expédition.

Swimlane Exemple : Dans un process interne d’entreprise :

• Un seul pool représente “Entreprise XYZ”.
• Les swimlanes représentent différents départements : “Commercial”, “Opérations”, “Comptabilité”.
• Des tâches comme “Générer la facture” sont pour “Comptabilité”, alors que “Préparer l’expédition” est assignée à “Opérations” – cela montre clairement la répartition des responsabilités.

Collapsed Pool Exemple : Collaboration internationale :

• Un collapsed pool pour “Partenaire International A”, un autre pour “Partenaire International B”.
• Les process internes d’“A” et “B” ne sont pas montrés, car non pertinents ici.
• Message flows illustrent l’échange : contrat envoyé par “A”, reçu signé par “B”.
• Le focus est sur l’interaction et la communication, pas sur le détail interne de traitement du contrat.

Points clés

• Pools :

  • Représentent des participants distincts : entreprises, départements, systèmes.
  • Utilisés pour modéliser les interactions entre différentes organisations ou entités.
  • Contiennent des process complets et communiquent via des message flows avec d’autres pools.

• Swimlanes (Lanes) :

  • Sous-divisions dans un pool, représentant rôles, départements ou systèmes d’une même organisation.
  • Organisent les tâches et indiquent la responsabilité de chaque activité.
  • Facilitent la clarté sur l’affectation des tâches à chaque participant du même process.

• Collapsed Pools :

  • Montrent des participants dont les activités internes sont cachées ou non concernées par la vue actuelle.
  • Se concentrent sur les interactions avec d’autres participants, simplifiant le diagramme.
  • À utiliser quand seules les communications principales ou échanges externes sont à modéliser.
  • Les message flows servent à indiquer la communication entre collapsed pools et autres participants.
  • Simplifient les diagrammes tout en clarifiant les interactions entre participants.

Cas d’utilisation

• Pools : Pour modéliser les interactions entre différentes entités, comme une entreprise et son fournisseur ou client.
• Swimlanes : Pour modéliser les processus internes d’une organisation et montrer comment les rôles ou départements participent au workflow.
• Collapsed Pools : Pour représenter des participants externes quand le détail de leurs processus n’est pas pertinent, par exemple un client en interaction avec un prestataire, en se concentrant uniquement sur la communication entre eux.

Exemple

[IMAGE PLACEHOLDER FOR POOLS AND SWIMLANES EXAMPLE]

• Pool 1 : “Client”

  • Lane 1 : “Département commercial” (Task : “Soumettre une commande”)
  • Lane 2 : “Département comptabilité” (Task : “Envoyer une confirmation de paiement”)

• Pool 2 : “Fournisseur”

  • Lane 1 : “Entrepôt” (Task : “Préparer l’expédition”)
  • Lane 2 : “Facturation” (Task : “Émettre la facture”)

Dans ce diagramme, le pool Client communique avec le pool Fournisseur via des message flows (ex. : envoyer une commande, recevoir une facture), tandis que les tâches de chaque pool sont réparties dans les lanes en fonction de chaque département.

Pools et swimlanes sont essentiels pour organiser des process métiers complexes, en montrant clairement comment chaque entité et rôle contribue au workflow, et en clarifiant les responsabilités dans et entre les organisations.