Découvrez comment capturer, communiquer et valider des exigences complexes ou ambiguës dans des diagrammes BPMN. Suivez ces conseils et bonnes pratiques pour améliorer vos compétences BPMN.

BPMN is a modeling language, so the purpose of using BPMN should be on par with the activity. Not all requirements need to be modeled in BPMN, and not all process modeling needs to be done in a formal modeling language. In my experience, informal process model visuals work very well to get critical conversations happening about requirements. Complexity, well it depends on what the complexity is. If it is complex logic conditions, I have found that a Decision Table/Tree works better than a Process model for that piece of complex logic.

Much of the value in using BPMN is that it forces you to resolve ambiguities to build the model. Ultimately, BPMN is designed to create executable models of a process. If you are aiming for that, remember that a BPMN model is always triggered by a business event and should continue until that event is resolved. A clear definition of the event in question and what it means to resolve it is crucial. The rest should flow from that.

Comment gérez-vous les exigences complexes ou ambiguës dans BPMN ?

Généré par l’IA et la communauté LinkedIn

Notation de modélisation des processus métier (BPMN) est un langage graphique pour la conception et la documentation des processus métier. Il peut vous aider à capturer, communiquer et valider les exigences de vos parties prenantes. Cependant, toutes les exigences ne sont pas claires, simples ou cohérentes. Parfois, vous pouvez rencontrer des exigences complexes ou ambiguës qui mettent à l’épreuve vos compétences BPMN. Comment les gérez-vous efficacement? Voici quelques conseils et bonnes pratiques à suivre.

Des experts chevronnés contribuent à cet article

Sélectionnés par la communauté pour 5 contributions. En savoir plus

1 Clarifier la portée

Avant de commencer la modélisation, vous devez définir la portée de votre processus. Quel est l’objectif, le déclencheur et le résultat du processus? Qui sont les acteurs, les rôles et les responsabilités impliqués? Quelles sont les limites, les hypothèses et les contraintes du processus? En clarifiant ces questions, vous pouvez éviter la complexité et l’ambiguïté inutiles dans vos diagrammes BPMN. Vous pouvez également utiliser une instruction de portée ou un diagramme de contexte pour documenter et communiquer la portée de votre processus.

Ajoutez votre point de vue

Angela Wick

| 2+ Million Trained | Helping BAs Navigate AI | BA-Cube.com Founder & Host | LinkedIn Learning Instructor | CBAP, PMP, PBA | ICP-ACC
Signaler la contribution
BPMN is a modeling language, so the purpose of using BPMN should be on par with the activity. Not all requirements need to be modeled in BPMN, and not all process modeling needs to be done in a formal modeling language. In my experience, informal process model visuals work very well to get critical conversations happening about requirements. Complexity, well it depends on what the complexity is. If it is complex logic conditions, I have found that a Decision Table/Tree works better than a Process model for that piece of complex logic.

Texte traduit

J’aime
Kevin Brennan

Business Architect & Professor, Led creation of BABOK
Signaler la contribution
Much of the value in using BPMN is that it forces you to resolve ambiguities to build the model. Ultimately, BPMN is designed to create executable models of a process. If you are aiming for that, remember that a BPMN model is always triggered by a business event and should continue until that event is resolved. A clear definition of the event in question and what it means to resolve it is crucial. The rest should flow from that.

Texte traduit

J’aime

Charger plus de contributions

2 Utiliser la notation standard

BPMN a une notation riche et expressive qui couvre divers aspects des processus métier, tels que les événements, les activités, les passerelles, les flux, les pools, les voies et les artefacts. Cependant, l’utilisation de symboles trop nombreux ou inappropriés peut rendre vos diagrammes confus et difficiles à lire. Pour éviter cela, vous devez utiliser la notation standard et suivre la spécification BPMN 2.0. Vous devez également utiliser des noms, des étiquettes et des couleurs cohérents et significatifs pour vos éléments. En outre, vous devez éviter d’utiliser à mauvais escient ou à mauvais escient des fonctionnalités avancées, telles que les sous-processus, les flux de messages ou les sous-processus d’événements, sauf si elles sont nécessaires et pertinentes.

Ajoutez votre point de vue

Eniola Ogunsola

Project Manager and Business Analysis Coach
(modifié)
Signaler la contribution
Although BPMN is very rich, we often find that it's mostly technology stakeholders that enjoy the full benefits of the richness. What I have seen is that standard BPM 2.0 is more universally used as it can be more easily understood by both Business and Technology folks. It is a less complex model to use. Creating the associated BMP table also helps to clarify any ambiguities or complexities.

Texte traduit

J’aime
Tom Tomasovic

Freelance Instructor/Trainer | Business Analysis, Data Analytics | "I enjoy helping BAs do their job better!"
Signaler la contribution
I find this section somewhat confusing. The stated implication is that there is a “standard” BPMN 2.0 specification that is somehow different from the full, rich BPMN taxonomy. If that exists, I am not aware of it. I am aware, however, that the full taxonomy can be very intimidating and, in many cases, unnecessary. The goal should be to provide the appropriate level of detail to facilitate stakeholder understanding. A technique such a sub-processes can actually make a process diagram EASIER to understand, and the tools that allow for drilling in to a sub-process allow the stakeholders to see the level of detail they want or need when they want it. Start simple and embellish, expand, and extend as it makes sense for your audience!

Texte traduit

J’aime

3 Simplifier la structure

Une autre façon de gérer des exigences complexes ou ambiguës consiste à simplifier la structure de vos diagrammes BPMN. Vous pouvez le faire en appliquant certains principes de conception, tels que la modularité, la hiérarchie et l’abstraction. La modularité signifie diviser votre processus en modules plus petits et indépendants qui peuvent être réutilisés ou modifiés facilement. La hiérarchie consiste à organiser vos modules en différents niveaux de détail, tels que le processus principal, le sous-processus et la tâche. L’abstraction signifie cacher ou montrer les détails de vos modules en fonction du public et du but de vos diagrammes.

Ajoutez votre point de vue

4 Valider la logique

Une fois que vous avez modélisé votre processus, vous devez valider la logique et l’exactitude de vos diagrammes BPMN. Pour ce faire, vérifiez la syntaxe, la sémantique et le comportement de vos diagrammes. La syntaxe fait référence aux règles et conventions de la notation BPMN. Vous pouvez utiliser un outil BPMN ou un validateur pour rechercher des erreurs de syntaxe, telles que des éléments, des flux ou des étiquettes manquants ou non valides. La sémantique fait référence à la signification et à l’intention de vos diagrammes. Vous pouvez utiliser un glossaire, un dictionnaire ou une légende pour définir et expliquer les termes et les symboles utilisés dans vos diagrammes. Le comportement fait référence à l’exécution et au résultat de vos diagrammes. Vous pouvez utiliser un simulateur, un testeur ou un débogueur pour exécuter et vérifier vos diagrammes.

Ajoutez votre point de vue

5 Examiner et affiner

La dernière étape pour gérer des exigences complexes ou ambiguës consiste à examiner et à affiner vos diagrammes BPMN. Vous pouvez le faire en sollicitant les commentaires, les suggestions et l’approbation de vos parties prenantes, telles que les clients, les utilisateurs, les responsables ou les développeurs. Vous pouvez également utiliser une liste de contrôle de la qualité, une évaluation par les pairs ou une révision formelle pour évaluer et améliorer vos diagrammes. En examinant et en affinant vos diagrammes, vous pouvez vous assurer qu’ils répondent aux exigences, aux attentes et aux normes de votre projet.

Ajoutez votre point de vue

6 Voici ce qu’il faut prendre en compte

Il s’agit d’un espace pour partager des exemples, des histoires ou des idées qui ne correspondent à aucune des sections précédentes. Que voudriez-vous ajouter d’autre?

Ajoutez votre point de vue

Collecte des exigences

+ Suivre

Notez cet article

Nous avons créé cet article à l’aide de l’intelligence artificielle. Qu’en pensez-vous ?

Il est très bien Ça pourrait être mieux

Signaler cet article

Tout voir

Comment gérez-vous les exigences complexes ou ambiguës dans BPMN ?

1

2

3

4

5

6

1 Clarifier la portée

2 Utiliser la notation standard

3 Simplifier la structure

4 Valider la logique

5 Examiner et affiner

6 Voici ce qu’il faut prendre en compte

Collecte des exigences

Notez cet article

Nous vous remercions de votre feedback

Plus d’articles sur Collecte des exigences

Lecture plus pertinente