5.1 Modélisation des exceptions et des erreurs
La gestion des exceptions et des erreurs est un aspect crucial de la modélisation des processus métier. Dans le monde réel, les processus ne se déroulent pas toujours comme prévu, et il est essentiel de modéliser comment gérer ces situations exceptionnelles.
5.1.1 Types d’exceptions
Dans le contexte du BPMN, on peut distinguer plusieurs types d’exceptions :
- Exceptions métier : Situations anormales du point de vue métier (ex. crédit client insuffisant, stock épuisé)
- Exceptions techniques : Problèmes liés aux systèmes informatiques (ex. panne de serveur, timeout)
- Exceptions temporelles : Dépassements de délais ou contraintes de temps non respectées
- Exceptions de compensation : Nécessité d’annuler ou de compenser des actions déjà effectuées
5.1.2 Modélisation avec les événements d’erreur
Les événements d’erreur sont utilisés pour capturer et gérer les exceptions dans un processus BPMN :
- Événement intermédiaire d’erreur (capture) : Généralement attaché à la frontière d’une activité, il intercepte une erreur qui se produit pendant l’exécution de cette activité.
- Événement de fin d’erreur : Termine un chemin de processus en signalant une erreur qui peut être capturée à un niveau supérieur.
La modélisation typique consiste à :
- Attacher un événement intermédiaire d’erreur à la frontière d’une activité susceptible de générer une erreur
- Connecter cet événement à un flux de séquence qui définit le traitement de l’erreur
- Éventuellement, terminer ce flux par un événement de fin normal ou rejoindre le flux principal
5.1.3 Utilisation des sous-processus d’événement
Les sous-processus d’événement offrent un mécanisme puissant pour gérer les exceptions :
- Sous-processus d’événement d’erreur : Déclenché lorsqu’une erreur spécifique se produit dans le processus parent
- Sous-processus d’événement de compensation : Déclenché pour compenser (annuler) les effets d’activités déjà complétées
- Sous-processus d’événement de message : Déclenché lorsqu’un message spécifique est reçu pendant l’exécution du processus parent
Les sous-processus d’événement peuvent être :
- Interruptifs : Ils interrompent le processus parent lorsqu’ils sont déclenchés
- Non-interruptifs : Ils s’exécutent en parallèle du processus parent sans l’interrompre
5.2 Modélisation des transactions
Les transactions représentent des ensembles d’activités qui doivent être traitées comme une unité atomique, soit toutes les activités sont exécutées avec succès, soit aucune ne l’est (principe du « tout ou rien »).
5.2.1 Sous-processus de transaction
Un sous-processus de transaction est un type spécial de sous-processus qui suit un protocole de transaction. Il est représenté graphiquement par un sous-processus avec une double bordure.
Caractéristiques principales :
- Il peut se terminer normalement (commit)
- Il peut être annulé (rollback)
- Il peut nécessiter une compensation si certaines activités ont déjà été complétées
5.2.2 Protocole de transaction
Le protocole de transaction en BPMN comprend trois types d’événements spécifiques :
- Événement de fin de réussite : Indique que la transaction s’est terminée avec succès (commit)
- Événement de fin d’annulation : Déclenche l’annulation de la transaction (rollback)
- Événement de compensation : Utilisé pour compenser les effets d’activités déjà complétées
5.2.3 Compensation
La compensation est le mécanisme qui permet d' »annuler » les effets d’activités déjà complétées lorsqu’une transaction échoue :
- Les activités qui peuvent nécessiter une compensation sont marquées d’un indicateur de compensation
- Pour chaque activité compensable, une activité de compensation correspondante doit être définie
- L’ordre de compensation est généralement inverse à l’ordre d’exécution des activités originales
5.3 Modélisation des processus parallèles et asynchrones
De nombreux processus métier impliquent des activités qui peuvent ou doivent être exécutées en parallèle, ou des interactions asynchrones avec d’autres participants.
5.3.1 Utilisation des passerelles parallèles
Les passerelles parallèles permettent de modéliser l’exécution simultanée de plusieurs activités :
- Divergence : Une passerelle parallèle divise le flux en plusieurs chemins qui sont tous exécutés en parallèle
- Convergence : Une passerelle parallèle synchronise les flux parallèles, attendant que tous les chemins entrants soient complétés avant de continuer
Bonnes pratiques :
- Toujours équilibrer les passerelles parallèles (chaque divergence doit avoir une convergence correspondante)
- Éviter les flux croisés entre différentes branches parallèles
- Utiliser des passerelles inclusives si certains chemins peuvent ne pas être exécutés
5.3.2 Événements intermédiaires et attente
Les événements intermédiaires de capture permettent de modéliser l’attente d’un événement externe avant de poursuivre le processus :
- Événement intermédiaire de message : Attend la réception d’un message
- Événement intermédiaire de signal : Attend la réception d’un signal
- Événement intermédiaire temporel : Attend jusqu’à un moment spécifique ou pendant une durée définie
- Événement intermédiaire conditionnel : Attend qu’une condition métier soit remplie
Ces événements sont particulièrement utiles pour modéliser des interactions asynchrones, où le processus doit attendre une réponse qui peut arriver à un moment indéterminé.
5.3.3 Corrélation des messages
Dans les processus impliquant des échanges de messages asynchrones, la corrélation des messages est essentielle pour s’assurer que chaque message est associé à la bonne instance de processus :
- La corrélation utilise des propriétés spécifiques du message (comme un ID de commande)
- Elle permet de gérer plusieurs instances de processus en parallèle
- Elle est particulièrement importante dans les scénarios B2B où plusieurs échanges peuvent avoir lieu simultanément
5.4 Modélisation des processus ad hoc et dynamiques
Certains processus métier ne suivent pas un flux prédéfini strict, mais sont plutôt caractérisés par un ensemble d’activités qui peuvent être exécutées dans un ordre flexible, déterminé par les exécutants ou par les circonstances.
5.4.1 Sous-processus ad hoc
Un sous-processus ad hoc est un type de sous-processus où les activités peuvent être exécutées dans n’importe quel ordre, ou même en parallèle, sans flux de séquence explicites entre elles. Il est représenté par un sous-processus avec un marqueur tilde (~).
Caractéristiques :
- Pas de séquence prédéfinie entre les activités
- Les activités peuvent être exécutées zéro, une ou plusieurs fois
- Des conditions de complétion définissent quand le sous-processus est considéré comme terminé
Cas d’utilisation typiques :
- Processus créatifs ou de résolution de problèmes
- Activités de recherche et développement
- Traitement de cas complexes nécessitant une approche flexible
5.4.2 Règles métier et décisions dynamiques
Pour les processus qui nécessitent des décisions complexes ou dynamiques, le BPMN peut être complété par d’autres standards comme le DMN (Decision Model and Notation) :
- Les tâches de règles métier dans BPMN peuvent faire référence à des modèles de décision DMN
- Cela permet de séparer la logique de décision complexe du flux de processus
- Les règles peuvent être modifiées sans changer le modèle de processus
5.4.3 Événements et réactivité
Les processus dynamiques sont souvent pilotés par des événements plutôt que par une séquence prédéfinie :
- Utilisation extensive d’événements intermédiaires pour réagir à des changements de situation
- Passerelles basées sur les événements pour déterminer le chemin à suivre en fonction de l’événement qui se produit en premier
- Sous-processus d’événement non-interruptifs pour gérer des situations parallèles au flux principal
5.5 Modélisation des processus inter-organisationnels
De nombreux processus métier s’étendent au-delà des frontières d’une seule organisation, impliquant des interactions avec des clients, des fournisseurs ou des partenaires.
5.5.1 Utilisation des piscines et des messages
Dans les processus inter-organisationnels, chaque organisation est généralement représentée par une piscine distincte :
- Les piscines séparées indiquent clairement les limites organisationnelles
- Les flux de messages (et non les flux de séquence) connectent les activités entre différentes piscines
- Les piscines externes peuvent être représentées comme des « boîtes noires » (sans détails internes) si les processus internes de l’autre organisation ne sont pas connus ou pertinents
5.5.2 Chorégraphies et conversations
Pour les processus fortement axés sur les interactions entre organisations, le BPMN 2.0 offre des types de diagrammes spécialisés :
- Diagrammes de chorégraphie : Se concentrent sur les échanges de messages entre participants, montrant la séquence des interactions sans détailler les processus internes
- Diagrammes de conversation : Offrent une vue de haut niveau des ensembles logiques d’échanges de messages entre participants
5.5.3 Gestion des délais et des exceptions
Dans les processus inter-organisationnels, la gestion des délais et des exceptions est particulièrement importante :
- Utilisation d’événements temporels pour gérer les délais d’attente (timeouts)
- Définition de chemins alternatifs en cas de non-réponse d’un partenaire
- Mécanismes d’escalade pour gérer les situations exceptionnelles
- Protocoles de compensation pour annuler des transactions partiellement complétées
5.6 Intégration avec d’autres standards et notations
Le BPMN 2.0 peut être utilisé en conjonction avec d’autres standards et notations pour modéliser différents aspects des systèmes d’entreprise.
5.6.1 BPMN et DMN (Decision Model and Notation)
Le DMN est un standard complémentaire au BPMN qui se concentre sur la modélisation des décisions :
- Le BPMN modélise le flux de processus, tandis que le DMN modélise la logique de décision
- Les tâches de règles métier dans BPMN peuvent référencer des modèles DMN
- Cette séparation permet une meilleure gestion de la complexité et facilite la maintenance
5.6.2 BPMN et CMMN (Case Management Model and Notation)
Le CMMN est un autre standard complémentaire qui se concentre sur la gestion de cas :
- Le BPMN est orienté processus (séquence d’activités), tandis que le CMMN est orienté données (état du dossier)
- Le CMMN est particulièrement adapté aux processus non structurés ou ad hoc
- BPMN et CMMN peuvent être utilisés ensemble pour modéliser différents aspects d’une même solution
5.6.3 BPMN et ArchiMate
ArchiMate est un langage de modélisation d’architecture d’entreprise qui peut être utilisé en conjonction avec BPMN :
- ArchiMate offre une vue plus large de l’architecture d’entreprise (stratégie, organisation, applications, infrastructure)
- BPMN fournit une vue détaillée des processus métier
- Les deux notations peuvent être alignées pour assurer la cohérence entre les différents niveaux de modélisation
Résumé du chapitre
Dans ce chapitre, nous avons exploré les techniques avancées pour modéliser des processus métier complexes avec BPMN 2.0 :
- Modélisation des exceptions et des erreurs : Utilisation d’événements d’erreur et de sous-processus d’événement pour gérer les situations exceptionnelles.
- Modélisation des transactions : Utilisation de sous-processus de transaction et de mécanismes de compensation pour assurer l’intégrité transactionnelle.
- Modélisation des processus parallèles et asynchrones : Utilisation de passerelles parallèles, d’événements intermédiaires et de mécanismes de corrélation pour gérer l’exécution simultanée et les interactions asynchrones.
- Modélisation des processus ad hoc et dynamiques : Utilisation de sous-processus ad hoc, de règles métier et d’événements pour modéliser des processus flexibles et réactifs.
- Modélisation des processus inter-organisationnels : Utilisation de piscines, de flux de messages, de chorégraphies et de conversations pour représenter les interactions entre organisations.
- Intégration avec d’autres standards : Combinaison du BPMN avec DMN, CMMN et ArchiMate pour modéliser différents aspects des systèmes d’entreprise.
Ces techniques avancées permettent de modéliser des processus métier complexes et réalistes, couvrant un large éventail de scénarios d’entreprise. Dans le prochain chapitre, nous explorerons des cas d’usage concrets qui illustrent l’application de ces concepts dans différents contextes métier.
