Comment modéliser les processus d'entreprise dans une carte de processus ?

Un processus d'entreprise, dans son état cible, est représenté par un objet métier à un stade spécifique de son cycle de vie, qui indique la satisfaction des besoins spécifiques du client du processus. La relation de déclenchement représente le lien entre le processus d'entreprise et les événements ou les états cibles du processus qu'il génère ou résout. L'occurrence d'une valeur d'attribut particulière ou d'une instance d'association en est un exemple.

Lorsqu'on parle de la capture d'un processus d'entreprise dans une carte de processus, on fait référence à la représentation d'une série d'activités organisées pour atteindre un objectif spécifique, qui est de satisfaire les besoins d'un client. Ce processus couvre tout le cycle, depuis l'expression du besoin jusqu'à la satisfaction de ce besoin par la fourniture d'un produit ou d'un service. Ce processus est souvent qualifié d'"end-to-end" (E2E) dans la littérature. L'objectif principal d'un tel processus est de résoudre une demande spécifique, ce qui n'est jamais une certitude : un besoin peut ne pas être exprimé explicitement (comme dans le cas d'une commande entrante), ou bien il peut être implicite (par exemple, un incident dont la résolution est définie dans un SLA).

En ce qui concerne la modélisation des fonctions d'entreprise, il est essentiel de comprendre qu'elles regroupent des processus d'entreprise en un tout logique, visant à fournir des capacités nécessaires à la réalisation des objectifs de l'entreprise. Une carte de processus, par exemple, peut illustrer les fonctions de soutien de l'entreprise par rapport aux processus clés. Cela dépendra du niveau de détail requis pour l'analyse en cours, mais les processus clés de l'entreprise doivent toujours être pris en compte en priorité. Ainsi, l'identification des processus clés précède toujours l'analyse des fonctions de soutien.

Lors de la capture des relations entre les processus, il faut s'assurer que les processus de soutien soient explicitement indiqués dans la carte de processus. Dans la gestion des processus d'entreprise, on évite la tentation de cacher des sous-processus dans les détails des processus soutenus. Au contraire, les processus de soutien doivent être clairement spécifiés, ce qui permet d'étudier les relations de déclenchement entre les processus et la manière dont un processus soutient un autre. La synchronisation des processus, par exemple, peut se produire dans différents contextes : au moment du démarrage du processus de soutien, à la fin lorsqu'il atteint son état cible, ou encore lorsqu'un processus parallèle est impliqué. La carte de processus permet de capturer ces variations dans les synchronisations, offrant ainsi une vue d'ensemble plus complète de l'interaction entre les processus.

Pour créer une carte de processus, il est primordial de commencer par les processus clés de l'entreprise, tout en prenant soin de ne pas détailler inutilement toutes les fonctions secondaires, sauf si cela est pertinent pour l'objectif de l'analyse. La création d'un modèle de système d'entreprise n'est pas un processus linéaire, mais plutôt un processus itératif. Chaque modification dans l'un des modèles qui compose le système d'entreprise peut entraîner des ajustements dans d'autres modèles afin que l'ensemble du système reste cohérent.

Il est donc essentiel de toujours considérer la carte de processus comme un point de départ pour une analyse plus approfondie, tout en gardant à l'esprit que l'objectif principal reste la compréhension et l'optimisation des processus clés de l'entreprise.

Comment modéliser efficacement les processus métiers en tenant compte des intentions et des retours d'information négatifs ?

Les processus métiers sont souvent abordés comme des actions organisées et orientées vers un objectif spécifique. Cette approche repose sur l'idée que tout processus métier est intentionnel, c'est-à-dire qu'il est dirigé par une entité intéressée qui cherche à atteindre un but précis. Cette intentionnalité rend impératif l'intégration d'un mécanisme de retour d'information négatif dans le processus, permettant de réguler les actions du processus et de les maintenir dans les limites de l'objectif fixé.

Le retour d'information négatif joue un rôle clé dans la gestion des états du processus. Ces états représentent les moments où le processus attend un événement particulier, permettant de passer à l'étape suivante. Une fois qu'un événement a lieu, une décision est prise immédiatement pour déterminer la prochaine étape du processus. Cette décision réduit les options possibles à une seule, celle qui est la plus pertinente en fonction de l'événement survenu. Cette approche garantit que les processus restent alignés sur leurs objectifs et ne se dévient pas de leur trajectoire. C'est un aspect fondamental qui doit être intégré dans tout modèle de processus métier, quel que soit le standard de modélisation utilisé, qu'il s'agisse de BPMN ou d'autres méthodologies similaires.

En effet, la plupart des méthodologies de modélisation, y compris BPMN, ne fournissent pas un soutien suffisant pour la gestion des états de processus, notamment dans le cadre de la rétroaction négative. Cela souligne l'importance cruciale de toute méthodologie de modélisation des processus qui doit permettre la gestion efficace des états de processus. Il est donc essentiel de capturer ces moments où le processus attend un événement déclencheur pour avancer, car ce retour d'information joue un rôle central dans l'atteinte de l'objectif final du processus.

Une tâche, dans ce cadre, ne doit en aucun cas être un processus simple sans changement d'état substantiel de l'objet qu'elle affecte. Par exemple, des opérations comme l'ajout ou la suppression d'un paquet, qui n'entraînent aucun changement d'état essentiel de l'objet, ne peuvent pas être considérées comme des tâches à part entière. Ces actions doivent être intégrées dans une tâche plus grande qui, elle, affecte véritablement l'état de l'objet. Ainsi, chaque tâche dans le modèle doit être vue comme un ensemble cohérent d'activités qui vise à transformer un état d'un objet vers un autre état significatif, en accord avec le cycle de vie de cet objet.

Dans le même esprit, l'utilisation de portes logiques telles que la jonction ou la division de flux dans le modèle de processus doit être conforme aux règles de logique sous-jacente du système. Il est crucial d'éviter les constructions qui vont à l'encontre de la logique du processus. Par exemple, l'usage combiné de portes XOR et AND dans un même flux peut introduire une incohérence qui fausse la modélisation. De même, l'utilisation de chemins parallèles dans le processus doit être soigneusement évaluée, car elle peut souvent être résolue par l'intégration de processus de support.

Les processus peuvent également être enrichis de contextes supplémentaires, comme le rôle de l'acteur impliqué, l'unité organisationnelle responsable ou la durée moyenne d'exécution d'une tâche. Bien que ces informations ne modifient pas directement le flux du processus, elles fournissent des détails contextuels précieux pour mieux comprendre les enjeux de chaque tâche. Toutefois, il convient de noter que l'ajout de trop de symboles contextuels dans un diagramme peut rendre celui-ci difficile à lire. La clé réside donc dans la capacité à conserver une représentation claire et cohérente du flux de travail tout en incluant des informations contextuelles pertinentes.

En résumé, la modélisation des processus métier nécessite de prendre en compte la dynamique des états, les retours d'information négatifs, ainsi que la gestion précise des tâches et de leurs contextes. L'objectif est de maintenir la clarté et la cohérence du modèle tout en intégrant les détails qui permettent de comprendre pleinement le fonctionnement et l'efficacité du processus métier. L'absence de cette rigueur dans la modélisation peut entraîner des modèles trop complexes, difficiles à interpréter, voire inapplicables dans un contexte réel.