Pour chaque processus d'affaires, il est essentiel de repérer les processus de soutien qui contribuent directement à l'atteinte des objectifs définis par les jalons. Ces jalons, constitués de différents états d'objets dans le processus, sont des points de vérification cruciaux permettant de garantir la fourniture d'un produit ou service au client d'un processus d'affaires. Ces étapes marquent non seulement la réalisation des objectifs, mais aussi les moments où des décisions doivent être prises pour déterminer les prochaines actions. La cartographie des processus de soutien permet d'analyser chaque processus comme un projet ayant des objectifs spécifiques, avec des jalons définis par des états cibles des processus de soutien et des activités nécessaires, interconnectées par des relations logiques.

Dans cette cartographie, il existe généralement trois types principaux de processus de soutien, chacun ayant un rôle spécifique dans l'accomplissement des objectifs du processus principal :

  1. Les processus de soutien fournissant les entrées nécessaires à l'exécution du processus principal.

  2. Les processus de soutien responsables de la transformation de ces entrées en sorties cibles.

  3. Les processus de soutien qui facilitent la livraison de ces sorties au client final.

Prenons l'exemple d'une librairie en ligne pour illustrer cette dynamique. Parmi les jalons du processus de traitement des commandes de livres, nous trouvons par exemple : les livres en stock, les livres prêts à être expédiés, et les livres livrés au client. Chacun de ces jalons dépend de processus de soutien différents qui doivent être clairement identifiés et cartographiés.

Il est aussi important de déterminer les événements déclencheurs pour chaque processus de soutien. Ces événements sont les manifestations d’un besoin que le processus cherche à satisfaire. Parfois, l’identification de ces événements peut sembler évidente, étant liée à la nature même du processus. Cependant, il est toujours utile de se concentrer sur les moments où une unité de traitement du processus change, ce qui représente un événement déclencheur. Par exemple, dans le cas de notre librairie en ligne, l’événement déclencheur pourrait être l’absence d’un livre en stock, incitant ainsi à une commande de réapprovisionnement.

Une fois ces événements et processus de soutien identifiés, il est crucial de les inscrire dans un modèle de processus, en tenant compte des relations de synchronisation. Ces relations se manifestent lorsque l'exécution d'un processus est conditionnée par le début ou la fin d'un autre processus. Ainsi, chaque processus de soutien doit être lié au processus d'affaires principal ou à d'autres processus de soutien, selon leur interaction.

Prenons à nouveau l'exemple de la librairie en ligne : plusieurs processus de soutien, tels que l'achat des livres, l'emballage et la livraison des colis, interviennent directement pour soutenir le processus de commande de livres. Certains de ces processus, comme l'achat de livres, interviennent également indirectement en gérant les niveaux de stock, influençant ainsi à la fois le processus de commande et la gestion des inventaires. La cartographie des processus doit donc tenir compte de ces relations multiples et complexes entre les différentes étapes.

Il est également important de noter que les processus de soutien peuvent, à leur tour, être soutenus par d'autres processus de soutien. Par exemple, le processus de gestion des stocks dans notre librairie en ligne peut reposer sur des processus de gestion des achats et de contrôle des niveaux de stock. Cette hiérarchie de soutien doit être continuellement explorée à travers des analyses systématiques des jalons, jusqu’à atteindre des processus de soutien élémentaires, c'est-à-dire des processus qui ne sont eux-mêmes soutenus par aucun autre processus.

Les processus d'affaires, une fois cartographiés, doivent être continuellement analysés pour identifier les événements qui déclenchent des actions et les relations qui synchronisent les processus. Un processus de soutien mal cartographié ou mal compris peut entraîner des inefficacités majeures dans la réalisation des objectifs d'un processus d'affaires. Il est donc indispensable de s'assurer que tous les processus de soutien sont identifiés, qu'ils soient directs ou indirects, et que leurs interactions sont bien comprises.

L’identification des processus de soutien jusqu’à leur niveau élémentaire est une étape cruciale pour une gestion efficace des processus d'affaires. Les processus qui soutiennent des fonctions spécifiques, comme la gestion des ressources humaines ou le stockage des livres dans notre exemple, peuvent eux aussi nécessiter d’autres processus de soutien, tels que l’évaluation des candidats pour un poste ou le contrôle des conditions de stockage.

Ainsi, l’objectif global de la cartographie des processus est de créer un modèle précis et détaillé qui permette d'identifier les jalons clés, les événements déclencheurs et les processus de soutien dans un cadre cohérent et interconnecté. Cette approche permet non seulement d’optimiser les processus existants, mais aussi d’anticiper et d’adapter les changements nécessaires pour maintenir une efficacité maximale dans la chaîne de production ou de services.

Comment la normalisation des processus peut-elle améliorer l'efficacité des diagrammes de flux de processus ?

L'un des aspects clés de la modélisation des processus d'affaires réside dans la manière dont les entrées et les sorties sont associées dans les diagrammes de flux de processus. Ce processus, bien qu'essentiel pour la représentation des activités d'une organisation, présente plusieurs pièges qui peuvent compromettre la clarté du diagramme. En effet, les informations supplémentaires, telles que les entrées et les sorties des activités, n'ont aucune influence directe sur la description du flux du processus lui-même, mais elles risquent de surcharger visuellement l'illustration. Pour garantir une lisibilité optimale, il est souvent préférable de lister ces éléments à l'extérieur du diagramme, par exemple, dans un outil CASE ou dans un tableau. Si cela s'avère nécessaire d'inclure ces éléments dans le diagramme, il est crucial d'éviter leur accumulation excessive, car cela pourrait obstruer les flux essentiels des activités elles-mêmes, comme le montre l'exemple de l'eEPC diagramme dans la figure 2.33, où les flux de données et de matériaux viennent encombrer les flux de séquences clés.

Cet encombrement visuel rappelle le principe fondamental des diagrammes : moins c'est plus. La simplicité et la clarté sont des éléments incontournables lorsqu'il s'agit de modéliser efficacement les processus. Cette idée de clarté s'étend également au concept de normalisation des processus, qui, bien que né de l'approche de normalisation des structures de données de Codd, trouve une application pertinente dans la modélisation des processus d'affaires. La normalisation des processus, inspirée de la normalisation des bases de données, cherche à réduire la redondance des activités, à éliminer les dépendances cachées et à assurer que toutes les activités dépendent de l'événement initial.

La normalisation des processus repose sur plusieurs objectifs clés. D'abord, il est crucial de réduire la redondance des activités de processus. En effet, la répétition inutile d'activités identiques dans différents processus indique souvent des dysfonctionnements dans les processus eux-mêmes. Ensuite, il est important de s'assurer que toutes les activités sont clairement dépendantes de l'événement initial. Cette approche permet non seulement de rendre les processus plus transparents et alignés avec les valeurs orientées client de l'entreprise, mais aussi d'ancrer les activités dans l'objectif principal du processus. Enfin, il s'agit d'éliminer les dépendances cachées, qui peuvent perturber la compréhension et la gestion des processus. Les processus clés, en tant que moteurs centraux des activités organisationnelles, doivent être clairement définis et non obscurcis par des relations cachées.

La normalisation des processus, à travers ces objectifs, permet également de distinguer les processus clés des activités non essentielles, révélant ainsi des processus de soutien qui peuvent fonctionner indépendamment mais de manière complémentaire. En retirant les éléments non essentiels des processus principaux et en les redéfinissant comme des sous-processus autonomes, l'approche normalisée permet de concentrer les efforts sur les activités centrales tout en assurant l'efficacité globale du système.

Pour mettre en œuvre cette normalisation, un certain nombre de conditions doivent être remplies. D'abord, le processus logique doit refléter une partie du monde réel, avec des séquences de processus interconnectées. Chaque activité du processus doit correspondre à une action spécifique dans une séquence naturelle ou à une relation entre ces séquences. De plus, chaque événement dans le processus doit être lié à un acteur externe ou à une séquence de processus collaboratifs. Enfin, toute séquence cachée dans le processus logique doit pouvoir être identifiée de manière distincte, généralement par un événement ou une structure d'événements. Ces critères permettent de définir des formes normales spécifiques, qui organisent le processus de manière à simplifier sa structure tout en en préservant la cohérence.

Ainsi, la normalisation des processus permet une meilleure gestion des ressources et une optimisation des processus d'affaires. Chaque étape de normalisation vise à simplifier et clarifier le processus tout en maintenant une relation directe avec l'objectif principal. Cette approche permet de mieux comprendre les interactions entre les différentes étapes du processus, et garantit une gestion plus efficace des activités, tant pour les processus primaires que pour les processus de soutien.

L'application de la normalisation des processus dans la modélisation des systèmes d'information offre une vue d'ensemble plus cohérente et logique des activités organisationnelles. Elle permet non seulement de simplifier les processus internes mais aussi d'améliorer la communication et la transparence dans l'ensemble de l'organisation.

Comment modéliser les objets métier et leurs cycles de vie dans un système

Les classes agissent dans des rôles différents au sein des associations. Par exemple, le salarié et son supérieur hiérarchique (Fig. 3.10) ou les différents rôles associés à une adresse (Fig. 3.26). Pour distinguer ces rôles, il est essentiel d’utiliser la spécification du rôle au sein de l’association. Si un rôle spécifié possède des attributs propres, il est nécessaire de l’intégrer dans une classe distincte. Par exemple, dans notre modèle de librairie, nous enregistrons les adresses de livraison et de facturation pour chaque partenaire, qui peuvent varier non seulement par leurs valeurs (adresse spécifique), mais aussi par le nombre d'adresses qu'un partenaire peut posséder dans un rôle donné. Cette distinction est capturée par la multiplicité et la spécification des rôles des associations, comme illustré dans la Fig. 3.26.

Lorsqu’il s’agit de définir les attributs d’une classe, il convient de spécifier quels sont ceux qui sont obligatoires et ceux qui sont facultatifs. Tous les attributs représentant les caractéristiques essentielles de la classe pour le modèle d’entreprise doivent être capturés. L’obligation d’un attribut est exprimée par la multiplicité : 1..1 pour un attribut obligatoire, et 0..1 pour un attribut optionnel. Il n’est pas nécessaire de spécifier le type de données à un niveau conceptuel. Dans le cas de notre modèle de librairie, les attributs des classes ont été spécifiés dans la Fig. 3.27. Prenons l’exemple d’une commande client. Il faut d’abord prendre en compte que la commande client est une spécialisation de la commande de livres. Par conséquent, tous les attributs communs à toutes les commandes de livres sont listés comme propriétés de cette classe générique. Dans notre exemple, sur les trois attributs identifiés pour la commande client, deux appartiennent à la commande de livres, et un est spécifique à la commande client. Il est également important de préciser l’obligation des valeurs des attributs. Dans cet exemple, tous les attributs sont obligatoires, sauf pour la Date de Completion et la Date de Remise.

Lors de la définition des opérations de classe, il est nécessaire d’examiner les attributs et les associations de chaque classe, y compris les agrégations et compositions, et de spécifier les opérations qui modifient leurs valeurs. Ces opérations doivent être capturées dans le modèle des concepts. Pour chaque classe d’objets, il est également nécessaire de déterminer s’il existe un modèle de cycle de vie d’objet associé. Si tel est le cas, il faut examiner ce modèle et capturer les opérations répertoriées dans les transitions d’état comme des opérations de cette classe dans le modèle de concepts. Les opérations de classe doivent être spécifiées sur la base d’éléments concrets, et non simplement sur des intuitions. Les principales sources pour spécifier les opérations sont les modèles de cycle de vie des objets et le modèle des concepts lui-même.

Prenons l’exemple de la commande de livraison dans notre modèle de librairie. En fonction de la relation entre la commande de livraison et le colis, nous avons spécifié les opérations addPackage() et removePackage(). La raison pour laquelle deux opérations sont nécessaires est due à la relation 1:N, ce qui implique qu’il doit y avoir des opérations permettant l’ajout et la suppression itérative des éléments dans le conteneur. De plus, selon les attributs de la commande de livraison, nous avons identifié l’opération setDateOfHandover(). L’attribut Numéro de livraison est obligatoire et sa définition est réalisée au moment de la création de l’objet (opération create()). Toutes les autres opérations spécifiées pour la commande de livraison sont basées sur le modèle de cycle de vie de l’objet associé.

Les spécialisations dynamiques doivent également être spécifiées en fonction du modèle de cycle de vie de l’objet. Il s’agit de capturer les états de l’objet dans le modèle des concepts en tant que spécialisations des classes auxquelles les états du cycle de vie de l’objet appartiennent (Fig. 3.29). Ces sous-types sont étiquetés avec le stéréotype « phase » pour les états d’objet et « end » pour les états finaux pseudo-finis, afin d’indiquer qu’il s’agit d’une structure de généralisation dynamique. Les cycles de vie des objets permettent d’enrichir le modèle des concepts avec une dimension temporelle, ce qui permet de définir comment les contraintes structurelles évoluent au fil du temps. Pour chaque étape du cycle de vie de l’objet (spécialisation), les obligations des associations et des attributs peuvent être définies individuellement. Ainsi, dans l’exemple de la librairie (Fig. 3.29), capturer les étapes de la vie d’un objet permet de définir que la commande de livraison a une relation avec le protocole de livraison, mais seulement lorsque la commande de livraison est « terminée », cette association devient obligatoire pour la commande de livraison.

Il est important de comprendre que l’essence même de la modélisation des concepts repose sur l’identification des attributs et des opérations d’une classe en fonction des règles d’affaires qui régissent l’objet métier. La classification des objets se fait par spécialisation et non par duplication des attributs ou opérations. Chaque classe est définie par ses attributs et opérations, et elle ne doit pas contenir de clés artificielles comme attributs. Dans les cas où une instance de classe peut agir sous plusieurs rôles simultanément (par exemple, client, fournisseur, salarié), ces rôles sont capturés par les noms des rôles dans les associations représentant chaque rôle. Si ces rôles ont des attributs spécifiques, il convient d’utiliser le modèle de spécialisation.

Les cycles de vie des objets jouent un rôle central dans la modélisation des concepts. Ils permettent de représenter l’évolution d’un objet métier tout au long de sa vie, en fonction des événements qui se produisent à chaque phase de son existence. Ce modèle permet de formaliser les règles d’affaires associées aux objets métiers et d’étudier la dynamique des objets dans un système d’entreprise.

Comment les tâches de message et les événements interagissent dans les processus de gestion du transport

Les processus métier complexes, tels que la gestion des demandes de transport, reposent sur une architecture technologique qui permet de coordonner efficacement les actions entre différents systèmes et processus. Au cœur de cette coordination se trouvent les "tâches de message", qui jouent un rôle crucial dans l'envoi et la réception d'événements, permettant ainsi une communication fluide entre différents processus.

Dans le cadre du processus de gestion des demandes de transport, par exemple, le processus initial commence dès qu'un événement est déclenché par un processus en amont, comme la gestion des commandes ou le réapprovisionnement des stocks. Le tout premier acte du processus est un appel à un service, spécifiquement pour l'inclusion d'une demande dans un lot de transport. Ce service génère un événement intitulé "INCLUDE INTO THE TRANSPORTATION BATCH" qui est destiné à un autre processus de soutien, celui de la création des lots de transport à partir des demandes. Cette interaction entre les processus est orchestrée grâce à une fonction Camunda spécifique, la fonction correlate(), qui permet de relier les différentes instances de processus.

L'expression associée à cette fonction est une commande de message qui inclut l'identifiant de la demande, représenté ici par le Request_ID, afin de l'envoyer au processus ciblé. Cette communication repose sur l'utilisation de la fonction setVariable(), qui permet de transmettre des variables essentielles à l'exécution d'une autre tâche. Le nom de l'événement — dans ce cas "INCLUDE INTO THE TRANSPORTATION BATCH" — sert d'identifiant pour la "correlation du message". Ce mécanisme permet de lier de manière unique chaque instance d'un processus à l'événement qu'il doit gérer, garantissant ainsi que le bon processus est sollicité au moment voulu.

Une fois que l'événement est envoyé et que le processus ciblé est activé, le processus initial crée un autre événement à la fin de son cycle pour notifier le résultat du service. Cette notification prend la forme d'un autre "message task", dans lequel l'événement "ORDER_TRANSPORTED" est généré, indiquant que le transport a été effectué. Encore une fois, cette tâche utilise l'identifiant de la demande, Request_ID, pour assurer que l'événement est corrélé correctement avec l'instance du processus cible, ici le processus de gestion des demandes de transport.

Le processus de gestion des demandes de transport peut également inclure des rappels temporels, qui sont déclenchés par un événement "timer" lorsque les délais sont dépassés. Ces rappels sont nécessaires pour signaler les retards dans l'exécution des tâches, garantissant ainsi que les acteurs humains prennent les mesures appropriées. Les rappels sont généralement configurés comme des tâches humaines, où des acteurs spécifiques sont avertis d'un retard dans le processus. La technologie permet ainsi une gestion des délais flexible, où les rappels sont contextuellement adaptés en fonction des différents états du processus.

Dans les processus de soutien, comme la gestion des lots de transport, la logique reste similaire. Le processus est organisé autour de tâches de message et de script, où chaque "message task" invoque un service spécifique (comme le transport d'un lot ou la gestion des échecs de transport) et chaque "script task" informe les processus concernés des actions entreprises. Cela permet de maintenir une cohérence et une communication claire entre les différents sous-processus. Par exemple, dans le cas de la gestion des lots de transport, chaque demande contenue dans un lot est traitée séparément, ce qui nécessite l'envoi de messages individuels pour chaque demande présente dans le lot.

Il est également essentiel de noter que certains processus techniques, comme le processus "Batch Organizer", n'ont pas d'impact direct sur les résultats métiers. Ces processus existent uniquement au niveau technologique, assurant des fonctions de coordination sans apporter de valeur métier directe. Ils sont lancés parallèlement aux processus métier pour compenser certaines limitations techniques, comme l'absence d'une base de données centralisée, et leur rôle est de garantir le bon déroulement de l'ensemble de la chaîne de traitement.

Une autre nuance importante réside dans la gestion des délais dans ces processus de soutien. Contrairement au processus de gestion des demandes de transport, où chaque demande est suivie individuellement, certains processus de soutien comme la création des lots de transport surveillent spécifiquement les délais globaux, comme celui de la fin de la journée de travail, pour forcer l'achèvement des tâches restantes. Le processus peut également utiliser des timers artificiels pour garantir que des événements spécifiques, comme l'envoi d'un lot, ne soient pas déclenchés trop tôt ou trop tard, une précision qui est parfois nécessaire pour éviter des erreurs de synchronisation.

Les processus métiers utilisant des événements et des tâches de message sont donc essentiels pour assurer une gestion fluide et intégrée des tâches complexes dans des systèmes interconnectés. L'utilisation de la fonction correlate() de Camunda permet une communication entre les différents processus en permettant d'envoyer et de recevoir des événements de manière ordonnée et fiable, tout en respectant les délais et les exigences spécifiques de chaque tâche. De plus, bien que ces mécanismes soient en grande partie automatiques, la présence de tâches humaines et de rappels temporels assure que les processus restent sous contrôle humain à tout moment, et que les anomalies ou les retards sont rapidement traités. Il est crucial de comprendre que chaque événement et chaque tâche sont interdépendants, et la précision dans leur gestion détermine en grande partie le succès de l'ensemble du système.

Comment l'IoT Gère l'Échelle des Données et l'Hétérogénéité des Objets
Quel rôle les terres et les villes ont-elles joué dans la société nord-indienne du VIe siècle avant notre ère?
Qu'est-ce qui détermine la conductivité des matériaux dans la physique des solides ?