Tutorial Business Process Bpm
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Tutorial Business Process Bpm as PDF for free.
More details
- Words: 7,905
- Pages: 63
TUTORIAL Win’Design Modélisation des processus Nous vous proposons à travers ce tutorial, de vous guider dans la modélisation d’un processus métier. Le Module de Win’Design utilisé est le Module BUSINESS PROCESS.
1 Préparation de l’utilisation de Win’Design 1.1 Lancement de Win’Design Lorsque vous lancez la version d’évaluation de Win’Design pour la première fois, l’assistant « Merlin » s’affichera, pour vous présenter le contenu de la version en cours.
Fermer cette fenêtre, en cochant éventuellement la case en bas de la boîte pour ne plus afficher l’assistant à chaque lancement. La partie gauche de la fenêtre affiche un arbre hiérarchique qui présente l’ensemble des modèles contenus dans l’espace de travail. Dans ce cas, il s’agit de l’espace de travail « Accueil Win’Design », qui contient des exemples illustrés que vous pourrez parcourir pour voir l’ensemble des modélisations gérées par Win’Design. Les exemples traités sont le cas « Société X » et le cas « Risquetout ».
© Cecima
1/63
Vous allez donc d’abord créer votre propre espace de travail de test. Pour cela, utiliser le menu contextuel de l’espace de travail, et cliquer sur « Nouveau » (ou utiliser le menu « Fichier – Espace de travail – Nouveau … »).
Votre environnement de travail se présente alors comme suit :
© Cecima
2/63
1.2 Ouverture d’un nouveau diagramme Positionner le curseur sur la racine de l’arbre « Espace de travail » et activer la fonction « Nouveau modèle » à partir du menu contextuel (ou activer la fonction « Nouveau » du menu « Fichier » ou cliquer sur fenêtre).
© Cecima
dans la barre d’outil en haut à gauche de la
3/63
La boite de choix du module de Win’Design s’affiche :
Cliquer sur le bouton « Business Process » ; les catégories de diagrammes disponibles de ce module s’affichent.
Nous allons dans cet exemple utiliser la notation BPMN (Business Process Management Notation)
© Cecima
4/63
Déplier le nœud « BPM » et choisir « Processus métier niveau n » On va, dans un 1er temps, se situer à un niveau détaillé du processus
Une fenêtre s’affiche permettant de décrire notre modèle
La référence du modèle (MGA1 par défaut) ainsi qu’un nœud du 1er diagramme (ou sous modèle) s’affichent également dans l’espace de travail.
Nota : MGA désigne tous les types de modèle du module Business Process (Modèle Général d’Activité).
© Cecima
5/63
1.3 Enregistrement Avant de poursuivre la modélisation, nous vous conseillons d’enregistrer votre espace de travail et votre modèle. Pour enregistrer votre espace de travail : Positionner le curseur sur la racine de l’arbre (Espace de travail), utiliser le menu contextuel de l’espace de travail et activer la fonction « Enregistrer ». Sélectionner le répertoire dans lequel vous voulez sauvegarder votre espace de travail. Nommer et enregistrer le fichier dont l’extension est .ws. Pour enregistrer votre modèle : Activer dans le menu général « Fichier/ Enregistrer » ou cliquer sur
dans
la barre d’outils. Sélectionner le répertoire dans lequel vous voulez sauvegarder votre modèle. Nommer et enregistrer le fichier dont l’extension est .mga. Pour renommer l’espace de travail, le modèle ou le sous-modèle, le sélectionner dans la liste par simple clic, et saisir le nouveau nom. Cette action est sans effet sur le nom des fichiers enregistrés correspondant.
Nota : nous vous conseillons de sauvegarder régulièrement votre travail en activant pour enregistrer le modèle courant, ou l’icône ouverts et l’espace de travail courant.
pour enregistrer tous les modèles
2 Le cas de gestion d’une commande client Le processus que nous allons illustrer est celui de la prise en charge de l’arrivée d’une commande provenant d’un client . Pour simplifier, l’organisation du travail (qui fait quoi ?) n’est pas pris en compte (Cette partie est illustrée au paragraphe 4.3 : Organisation)
Les étapes de la prise en charge d’une commande sont les suivantes : 1) Réception de la commande et contrôles préalables : Dès la réception de la commande, on effectue des contrôles sur l’existence et la situation du client : • S’il s’agit d’un nouveau client, on le crée avec les données présentes sur la commande (si les informations sont insuffisantes on arrête le processus) • Si le client existe déjà, on va vérifier que le montant total de ses commandes en cours ne dépasse pas un plafond autorisé
© Cecima
6/63
2) Création de la commande : • Dans le cas où l’encours de commande est trop élevé, on crée une « pré-commande » (on signalera au client que sa commande est refusée). • Dans les autres cas (en cours acceptable ou nouveau client) - on enregistre la commande avec ses informations de base (client, adresse de livraison, mode de règlement, date de livraison souhaitée, …). - pour chaque article commandé, on vérifie sa disponibilité. Dans le cas où un des articles n’est pas disponible (pas de livraison partielle), la commande est mise en attente (un autre processus gère la gestion des commandes en attente, en liaison avec la gestion des stocks). 3) Traitement du retour de prise en compte de la commande : Suivant l’état de la commande : • On envoie au client un courrier d’acceptation de la commande avec la date de livraison possible • On envoie au client un courrier de rejet de sa commande • On téléphone au client pour lui signaler que sa commande est en attente • On transmet au service « Achat » une demande de réapprovisionnement
3 Modélisation simplifiée 3.1 Début du processus
Un « client » envoie une « commande »qui déclenche le processus de gestion de la commande. Le « client » se modélise par un acteur externe au système d’information décrit.
Pour dessiner un acteur, cliquer sur
dans la barre des symboles de
diagrammes pour sélectionner l’outil Acteur, puis cliquer dans la fenêtre de dessin à l’endroit où vous souhaitez positionner l’acteur. Le dessin
apparaît.
Le curseur de la souris indique la fonction courante ; ici le curseur indique que l’on peut dessiner un autre acteur. Pour continuer notre exemple nous allons désactiver la fonction courante, soit en faisant un clic droit sur la souris (curseur dans un espace vide), soit en . cliquant dans la barre d’outil sur Par défaut tous les objets ont un nom (ici Acteur_1). Pour changer le nom de l’acteur, double cliquer sur le symbole de l’acteur. La boite de dialogue (dite pop up) s’affiche :
© Cecima
7/63
Saisir dans le champ « Nom » : Client (valider la saisie par la touche « Entrée » ou en sortant de la boite par , ou en cliquant n’importe où dans la fenêtre de dessin) Pour obtenir une aide complémentaire sur l’utilisation de cette boite de dialogue (ainsi que toutes les autres par la suite), cliquer sur
.
Nota : On remarque que le type d’acteur sélectionné par défaut est « Externe », coïncidant avec notre souhait de modélisation. La « commande » représente un flux d’information ou message Le terme « commande » représente dans le langage « métier » plusieurs sens : ici on s’intéresse à l’événement de la réception d’une commande, qui contient toutes les informations nécessaires au traitement de cette commande. C’est donc le « message » de l’arrivée de la commande que l’on modélise. et nommer le message « Commande » avec le même mode opératoire Dessiner que pour l’acteur.
Tracer le lien entre l’acteur et le message : Il existe deux fonctions de tracé de lien : , lien formel, qui contrôle la possibilité du tracé (dépendant des La fonction objets reliés) et induit aussi, dans certains cas, des dessins complémentaires ou le déclenchement d’assistant. La fonction
, lien libre, qui permet de relier tous objets sans contrôle.
Pour l’instant nous utiliserons la 1ère fonction : dans la barre d’outil. Cliquer sur le symbole de l’acteur , puis Choisir la fonction cliquer de nouveau sur le symbole du message (attention, l’ordre indique le sens du flux).
© Cecima
8/63
Indiquer le début du processus : Le marquage du début du processus est facultatif ; on pourrait directement relier le message à la 1ère tâche. et nommer l’événement de « début » avec le même mode opératoire que Dessiner pour l’acteur, puis tracer le lien entre le message « Commande » et le début du processus, indiquant ainsi que le processus est déclenché par l’arrivée d’une commande.
3.2 Etape de contrôles préalables On va maintenant modéliser le début du scénario de la prise en charge de la commande :
Dès la réception de la commande, on effectue des contrôles sur l’existence et la situation du client : • •
S’il s’agit d’un nouveau client, on le crée avec les données présentes sur la commande (si les informations sont insuffisantes on arrête le processus) Si le client existe déjà, on va vérifier que le montant total de ses commandes en cours ne dépasse pas un plafond autorisé.
L’ « identification du client » est la 1ère tâche à effectuer et nommer la tâche « Identification client » avec le même mode opératoire Dessiner que pour l’acteur, puis relier le début du processus et la tâche :
•
un branchement (décision) décrit les cas possibles
Dessiner un branchement amont)
© Cecima
et le nommer (fréquemment du même nom que la tâche
9/63
Utiliser l’onglet « Expression » pour saisir l’expression d’évaluation à afficher
Puis relier la tâche « Identification client » à ce branchement conditionnel. Lors du tracé la boite suivante s’affiche.
© Cecima
10/63
Elle est destinée à traiter le cas des conditions et alternatives différemment. Pour l’instant nous allons l’ignorer. Cliquer sur OK ou sur la touche « Entrée » pour continuer.
Si le client n’existe pas il faut le créer et nommer la tâche « Création client » avec le même mode opératoire que Dessiner pour la tâche précédente.
© Cecima
11/63
Relier la décision et la tâche « Création client » pour exprimer la condition de branchement vers la tâche. Pour tracer un lien coudé comme sur l’illustration, cliquer un point intermédiaire sur le schéma avant de cliquer sur la tâche « Création client ». Lors du tracé du lien la boite de dialogue s’affiche :
Saisir la valeur de condition « non » correspond à la réponse à l’expression « client connu ? » et signifiant que la séquence suivante concernera les clients à créer. Valider. La valeur de la condition s’affiche sur le lien.
© Cecima
12/63
Si la création du client n’est pas possible, le processus est arrêté , le nommer « retour création client » et mettre dans Dessiner un branchement l’expression affichée « Création OK ? ». Relier la tâche « Création client » avec le branchement (décision).
L’arrêt du processus est marqué par un événement de type « Fin ». Déplier la liste des symboles comme indiqué :
représentant une « Fin » de processus. Dessiner et nommer et choisir le dernier l’événement « fin création client impossible ». On peut également préciser, à partir de la liste déroulante « Déclencheur » la nature de l‘arrêt, dans ce cas « Erreur de traitement ».
© Cecima
13/63
Le symbole de la fin s’affiche alors comme suit :
de condition entre le branchement « Création OK ? » et la fin en erreur Tracer un lien du processus, avec comme valeur de condition « non », indiquant que la « création client » n’est pas possible :
Si la création du client est ok, on crée la commande et nommer la tâche « Création commande» avec le même mode opératoire Dessiner que pour la création des autres objets.
© Cecima
14/63
Tracer un lien de condition entre le branchement « Création OK ? » et la tâche « Création commande » avec comme valeur de condition « oui » , indiquant que la « Création client » s’est bien passée.
Si le client existe il faut vérifier son encours de commandes et nommer la tâche « Vérification Encours commande» avec le même mode Dessiner opératoire que pour la création des autres objets :
Nota : On peut afficher les noms des objets sur plusieurs lignes pour faire varier la taille des symboles : , après avoir sélectionné Dans la barre d’outil des styles : un symbole (par exemple la tâche « Vérification Encours commande »), cliquer sur la fonction
. La boite de dialogue s’affiche.
Choisir le nombre de ligne d’affichage du nom dans la liste déroulante comme ci dessus, et valider par OK. On obtient l’affichage suivant :
© Cecima
15/63
Tracer un lien de condition entre le branchement « client connu ? » et la tâche « Vérification Encours commande » avec comme valeur de condition « oui », indiquant que le client existe déjà et à été identifié.
, le nommer « vérification encours commande» et mettre Dessiner un branchement dans l’expression affichée « plafond dépassé ? » Relier la tâche « Vérification Encours commande » avec le branchement (décision).
Si le plafond autorisé est dépassé on crée une « pré-commande » et on arrête le processus et nommer la tâche « création pré-commande» avec le même mode Dessiner opératoire que pour la création des autres objets * et nommer la « fin » : « fin processus plafond dépassé». Dessiner Relier
© Cecima
la tâche et la fin du processus pour arriver à la modélisation suivante :
16/63
Si le plafond autorisé n’est pas dépassé on crée la « commande ».
© Cecima
17/63
3.3 Etape de création de la commande La « création de la commande » a déjà été représentée à l’issue de la « création d ‘un nouveau client ». la décision « plafond dépassé ? » à la tâche « Création Il reste donc à relier commande », avec une valeur de condition égale à « non » .
On remarque que la tâche « Création commande » peut être déclenchée à partir de 2 séquences différentes, l’une à partir de la « création client » l’autre à partir de la « vérification Encours commande ». Dans la mesure où ces 2 chemins sont mutuellement exclusif , il n’est pas nécessaire d’exprimer « une synchronisation » pour le déclenchement de la tâche. Vérification de la disponibilité des articles :
Pour chaque article commandé on vérifie sa disponibilité. Dans le cas où un des articles n’est pas disponible (pas de livraison partielle), la commande est mise en attente , (un autre processus gère la gestion des commandes en attente, en liaison avec la gestion des stocks)
et nommer la tâche « vérification disponibilité article» avec le même mode Dessiner opératoire que pour la création des autres objets :
© Cecima
18/63
Puis la relier avec la tâche « Création commande » : Ici nous exprimons un enchaînement inconditionnel entre deux tâches. Lors du tracé du lien, une boite de dialogue s’affiche pour permettre de choisir le contexte du tracé :
Opter pour le choix par défaut ,et valider par la touche « OK ». La boite des conditions de sortie s ‘affiche. Ne rien saisir et valider par la touche « OK ».
Cette tâche doit être faite pour chacun des articles composant la commande. On va donc exprimer la répétitivité (il existe d’autres façons de faire) par une « boucle » partant et arrivant sur la même tâche. le départ de la boucle à partir du bas de la tâche et faire 4 points Tracer intermédiaires, à la fin du tracé la boite d’option du tracé du lien s’affiche. Confirmer l’option d’enchaînement d’activités, puis cocher la case « Ne plus afficher ce message » (pour qu’elle ne s’affiche plus systématiquement). La boite des conditions s’affiche. Nous allons l’utiliser pour illustrer une autre manière d’exprimer un branchement conditionnel : Dans le cas présent, on veut modéliser le fait que la tâche va être réalisée plusieurs fois, tant qu’il reste un article à vérifier dans la commande. On va donc spécifier la condition « article suivant » qui sera la condition de déclenchement de la boucle.
© Cecima
19/63
Créer la condition puis valider par la touche OK. Le tracé du lien s’affiche .
Si lors du tracé la condition n’a pas été définie, on peut le faire à posteriori, par la boite de définition du lien (double clic sur le lien).
On peut soit choisir la liste déroulante une condition existante, soit accéder à la définition des conditions à partir du bouton « Définir… » permettant de créer une condition comme ci dessus. © Cecima
20/63
Puis après validation, dans la boite du lien, sélectionner la nouvelle condition pour l’associer au lien.
Un autre mode opératoire existe pour créer des conditions sans tracer de liens : Ouvrir la boite de définition de la tâche « vérification disponibilité article ».
et cliquer sur le bouton « Condition ». La boite de définition des conditions s’affiche et permet de créer plusieurs conditions. Créer la condition « fin ou article indisponible» :
© Cecima
21/63
Décrivons maintenant la suite du processus : • Si tous les articles sont disponibles, on valide la commande • Si un des articles manque on met la commande en attente Dessiner et nommer le branchement « disponibilité commande » avec le même mode opératoire que pour la création des autres objets , mettre dans l’expression « disponible ? »
Tracer le lien entre la tâche (cliquer vers le haut gauche) et la décision, puis sélectionner dans la boite des conditions la condition « fin ou article indisponible » exprimant que la sortie de la tâche s’effectue après vérification de tous les articles. Si l’affectation n’a pu se faire pas ce mode opératoire, passer par la boite de définition du lien en utilisant la liste déroulante « condition d’émission »
© Cecima
22/63
Nota : Dans la boite de définition de la tâche, l’onglet « Références croisées » permet de voir, vues du dictionnaire, les entrées et sorties de la tâche.
Dans ce formalisme (BPMN) les conditions de sorties exprimées dans la tâche sans utiliser de branchement conditionnel (décision) ne sont pas représentées graphiquement, contrairement au formalisme de type Merise qui positionne les conditions « en râteau » au pied de la tâche :
ou en supprimant le branchement et en rajoutant une condition.
© Cecima
23/63
Le processus se poursuit avec la validation de la commande, ou sa mise en attente suivant la condition de disponibilité : Construire la fin du schéma pour arriver au résultat suivant :
3.3 Etape de gestion du retour commande Traitement du retour de prise en compte de la commande :
Suivant l’état de la commande : • On envoie au client un courrier d’acceptation de la commande avec la date de livraison possible • On envoie au client un courrier de rejet de sa commande • On téléphone au client pour lui signaler que sa commande est en attente • On transmet au service « Achat » une demande de réapprovisionnement
Pour traiter cette dernière partie du processus, il faut prendre un peu parti dans le mode d’organisation. On peut par exemple décider que le traitement du retour se fait dans le processus en fonction des cas du traitement de la commande :
© Cecima
24/63
L’acteur « Client » existe déjà dans le graphique. Pour un motif d’esthétique graphique (éviter de tirer un lien remontant en tête du schéma), on va créer un «duplicata » de l’acteur existant et le positionner à proximité de la tâche « valider la commande ». Pour créer un duplicata, sélectionner l’acteur « Client » et appeler son menu contextuel (clic droit), choisir la fonction « Duplicata » :
Cette fonction est présente pour tous les autres types d’objet. Elle permet de représenter plusieurs fois le même objet dans le même graphique. Chacune de ses représentations peut avoir un style différent, mais la définition de l’objet est la même. On obtient le résultat suivant :
Sélectionner le duplicata, le déplacer à l’endroit choisi. de la tâche « valider la commande » vers l’acteur Tracer directement un lien « Client ». Un message est automatiquement créé. Nommer ce message « acceptation commande ». Nota: Ce mode opératoire est un raccourci pour : dessiner
et nommer un message,
tracer un lien
entre la tâche et le message,
tracer un lien
entre le message et l’acteur.
Ici on a représenté par le message « acceptation commande » le courrier d’acceptation envoyé au client. Dans la boite de définition du message choisir dans la liste déroulante « support » : courrier
© Cecima
25/63
Une icône représentative du support s’affiche à côté du message.
Nota : par défaut l’icône peut se déplacer sans déplacer l’objet auquel elle est rattachée. Pour la « fixer », utiliser le menu contextuel de l’icône et décocher « icône flottante »
On peut également changer d’icône avec la fonction du menu contextuel « changer icône ». Nota : D’autres options dans le « profil standard » permettent de paramétrer la forme, le style, l’affichage de chaque type d’objet. Pour appliquer localement à un objet un style utiliser la barre d’outil :
ou dans la boite de définition de l’objet les onglets « affichage » et « styles »
© Cecima
26/63
Poursuivre la modélisation des retours de la commande, avec les autres cas de retour de la commande : • • •
© Cecima
On envoie au client un courrier de rejet de sa commande On téléphone au client pour lui signaler que sa commande est en attente On transmet au service « Achat » une demande de réapprovisionnement
27/63
© Cecima
28/63
4 Modélisation complémentaire 4.1 Décomposition hiérarchique Dans l’exemple que nous venons de traiter, le niveau de détail choisi est celui de la description de tâche que l’on peut qualifier d’intermédiaire. Voyons maintenant comment introduire un degré de détail supplémentaire.
Prenons le cas d’une des tâches précédemment modélisée : « la mise en attente » d’une commande. Dans cette tâche, on réalise plusieurs actions que l’on pourrait détailler : -
mettre en attente la commande (on peut imaginer qu’il s ‘agit d’une saisie complémentaire par rapport à celle de la commande), téléphoner au client pour lui signaler la mise en attente de sa commande, créer une demande d’achat pour les produit en rupture de stock, transmettre la demande d’achat au Service Achats.
En fait pour détailler une tâche on peut être amené à décrire un véritable sous modèle, avec ses propres tâches et enchaînements. Avant d’effectuer cette modélisation, on peut compléter la description de la tâche « mettre la commande en attente » pour indiquer le contenu de cette tâche et faciliter ensuite la description de son détail. Dans l’onglet « Détail » de la boite de définition de la tâche, saisir dans le champ de texte le futur détail de la tâche, comme suit :
Nous allons maintenant utiliser ce « pré-découpage » pour composer la modélisation détaillée de la tâche, grâce à un assistant à la décomposition hiérarchique. Dans l’onglet « Définition » de la boite de description de la tâche, cliquer sur le bouton « Décomposer… »
© Cecima
29/63
La boite de dialogue s’affiche :
L’assistant de décomposition permet de choisir la manière dont la décomposition s’effectue et propose d’utiliser le texte de détail de la tâche comme point de départ : Chaque ligne du texte est considérée comme « tâche » de détail candidate. Par défaut tout est sélectionné. Si certaines lignes ne correspondent pas au découpage souhaitée, il suffit de les désélectionner. Valider la proposition par la touche « OK ». Un nouveau diagramme (sous modèle) s’ouvre avec certains objets affichés :
© Cecima
30/63
Chacune des lignes du texte de détail est devenue une tâche. Le contexte d’entrée et de sortie de l’opération décomposée est également pré positionné. Un cartouche a été créé automatiquement , avec pour titre le nom de la tâche amont, la flèche
permet en cliquant (double clic) dessus de « remonter » à la tâche d’origine.
Le diagramme contenant la tâche s’affiche en positionnant en son centre la tâche concernée, qui apparaît avec une flèche vers le bas. Cette flèche permet en cliquant (double clic) de « descendre » dans le diagramme représentant sa décomposition
Nous allons maintenant représenter les enchaînements entre les tâches détaillées : Pour le démarrage, on peut comme pour l’exemple principal traité, utiliser un « Evénement » de type « début ».
© Cecima
31/63
Puis utiliser la tâche proposée de mise en attente qui s’enchaîne avec l’appel au client pour le prévenir :
Dans le diagramme « amont » nous avons déjà représenté l’appel au client par le message « information sur commande en attente ». Ce message nous a été proposé lors de la décomposition. Nous allons le réutiliser en le déplaçant, ainsi que l’acteur « client », à côté de la tâche :
On suppose à ce niveau que : -
-
Si le client souhaite annuler sa commande, il en informe la société et doit envoyer un courrier d’annulation ; un autre processus traitera de la gestion de ces annulations S’il accepte, on enchaîne alors vers la création d’une demande d’achat et sa transmission au Service achat.
On complète donc le modèle en ajoutant un branchement (Décision) « acceptation attente ? » qui permet de traduire la dernière alternative :
© Cecima
32/63
© Cecima
33/63
4.2 Recomposition On vient de voir que l’on peut détailler une activité modélisée (pas de limite de profondeur) dans un nouveau diagramme. Nous allons voir maintenant la possibilité de procéder dans l’autre sens, à savoir représenter un regroupements d’activités, dont la décomposition est définie par un diagramme existant. Il faut au préalable créer un nouveau diagramme dans lequel nous allons représenter des « sous processus » de gestion des commandes :
4.2.1 Nouveau diagramme Pour créer un autre diagramme (en restant dans le même modèle) utiliser la fonction de la barre d’outil « sous modèles » , ou à partir du menu « Modèle », activer la fonction « Sous modèle / Création sous modèle… ». Dans la boite de choix des types de modèles, choisir dans le groupe « BPM » le type de diagramme « Processus métier niveau 1 » dont le paramétrage permet de décrire des « sous processus ».
Un nouveau diagramme s’ouvre.
Nous allons créer les « sous processus » évoqués dans notre exemple :
© Cecima
34/63
-
la prise en charge de la commande dont nous avons modélisé le détail, l’annulation de commande, la gestion des commandes en attente, qui gère les commandes dont les articles n’étaient pas disponibles.
On peut les représenter simplement comme une cartographie :
On peut également faire figurer les principales entrées/sorties de chacun des sous processus et orienter le diagramme comme un diagramme de contexte (seul le sous processus « Prise en charge commande » est décrit complètement dans l’exemple suivant).
Nota : les messages et l’acteur « Client » ont été réutilisés et copiés dans ce diagramme à partir du dictionnaire, comme suit :
© Cecima
-
. cliquer sur l’onglet de l’espace de travail La liste des types d’objet concernés par les diagrammes présents dans l’espace de travail s’affiche :
-
déplier le nœud « Acteur » et sélectionner : « Client » :
35/63
-
-
faire un « glisser-déposer » de l’acteur « Client » dans la fenêtre du diagramme et relâcher le bouton de la souris à l’endroit voulu : l’acteur se dessine procéder de la même manière avec le « Message » « Commande » :
Le résultat est le suivant :
On remarque que le lien entre le « Client » et la « Commande » est tracé automatiquement. Tout objet collé dans un diagramme provoque ce comportement de tracé de lien. Dans certains cas le collage entraîne le collage d’autres objets indissociables du contexte de l’objet collé.
4.2.2 lien de décomposition sous processus / détail Dans la boite de définition du sous processus « Prise en charge commande », cliquer sur le bouton « Décomposer… » pour afficher l’assistant de décomposition :
© Cecima
36/63
Par rapport au cas précédent de décomposition, il s’agit maintenant d’associer un diagramme existant. Pour cela il faut : -
-
-
© Cecima
choisir le type de modèle ; prendre « Processus métier niveau n » (utiliser l’ascenseur dans la liste des modèles type) que nous avons utilisé pour décrire le détail du sous processus, la liste des diagrammes de ce type s’affiche, cliquer sur le radio bouton « Un sous modèle existant » et sélectionner le diagramme « Détail Prise en charge commande » comme indiqué ci dessous, valider par la touche OK.
37/63
Le diagramme de détail s’affiche avec un cartouche complémentaire comportant le nom du diagramme et le dispositif (flèche) permettant de « remonter » au sous processus :
Dans le diagramme du sous processus , on remarque que la flèche de décomposition a été rajoutée sur le symbole du sous processus :
Dans la mesure où le lien de décomposition a été fait à posteriori, il faut vérifier dans le niveau de détail que toutes les tâches représentées font bien partie de la décomposition (on peut représenter dans un diagramme des tâches provenant d’autres processus) : Dans la boite de définition des tâches, vérifier la case à cocher « Appartient à la décomposition ».
On peut voir également dans les références croisées l’effet de la décomposition. Exemple d’un niveau intermédiaire issu d’une décomposition et lui-même décomposé : la tâche « mettre la commande en attente » :
© Cecima
38/63
Nota : le terme « Activité » est un terme générique couvrant tous types d’action ou de traitement (processus, tâche, procédure, fonction, …). Le type d’ activité est précisé à côté du nom : « Prise en charge commande : Sub Process ».
L’opération de recomposition peut encore être faite en montant d’un niveau, en construisant un diagramme qui recense les différents processus (non exhaustif) de l’entreprise, dont la « Gestion des commandes ». Créer un nouveau diagramme comme précédemment en choisissant «Processus métier niveau 0 » Nommer le diagramme « Principaux processus » Représenter les différents processus.
Décomposer le processus « Gestion des commandes » dans le diagramme « Sous processus Gestion des commandes »
© Cecima
39/63
Pour se donner une idée de la hiérarchie de navigation dans ces diagrammes, on peut utiliser un outil de visualisation :
© Cecima
-
Cliquer dans la barre des « sous modèles » (en bas de l’écran) l’outil la fenêtre suivante s’affiche
-
Déplier le nœud « Gestion des commandes » puis celui du sous processus « prise en charge commande » puis celui de la tâche « mettre la commande en attente ».
40/63
Cet outil permet aussi, par double clic sur un élément, d’afficher le diagramme dans lequel se trouve cet élément
© Cecima
41/63
4.3 Organisation Jusqu’à présent, pour simplifier la prise en main de Win’Design, l’aspect organisationnel des processus (en général cette dimension est présente dès le début, surtout pour la modélisation de l’existant), n’a pas été abordé.
4.3.1 Qui fait quoi ? Prenons un diagramme déjà réalisé dans l’exemple ci dessus : « mettre la commande en attente » :
On va s’intéresser dans un 1er temps à la répartition du travail : qui effectue quelle tâche ? Suivant les formalismes, la notion utilisée peut être un « Rôle », un « Acteur », une « Unité organisationnelle », un « Poste de travail » . Nous utiliserons dans la suite de l’exemple la notion de « Poste de travail ». Scénario :
© Cecima
42/63
On va supposer que la 1ère tâche « mise en attente » est faite par le « Secrétariat commercial » et que les tâches suivantes sont réalisée par le « Commercial » Les intervenants ou profils de compétence ou postes de travail sont représentés par dans la barre d’outil des symboles . Ceci correspond à des colonnes de tableaux dans lesquelles les tâches sont représentées. Pour « organiser » le diagramme existant, nous allons simplement déplacer les éléments dans les colonnes concernées Prendre l’outil existant :
-
© Cecima
et cliquer dans la fenêtre du diagramme à la droite du schéma
nommer le poste de travail (double clic sur le rectangle supérieur du symbole) : « Secrétariat commercial » sélectionner le début et la tâche « mise en attente » et déplacer la sélection dans le poste
43/63
créer un autre poste de travail nommé « Commercial » et déplacer le reste du schéma à l’intérieur du poste Nota : on remarquera que le nouveau poste vient se positionner automatiquement accolé à droite du précédent -
-
© Cecima
aménager éventuellement le schéma pour obtenir la présentation ci dessous :
44/63
Nota : Le positionnement des tâches dans un poste provoque automatiquement l’agrandissement de la colonne (en largeur et hauteur). Attention : Une fois positionnées dans un poste, le déplacement de tâches provoque l’agrandissement de sa colonne. Si on souhaite les changer de poste, il faut : - soit, au moment du déplacement, appuyer en même temps sur la touche « Ctrl » - soit choisir le nouveau poste dans la boite de définition de la tâche, par la liste déroulante : « poste de travail »
© Cecima
45/63
Nota : lorsque l’aspect de l’organisation est pris en compte dès le début de la modélisation, les postes sont dessinés d’abord, puis les objets sont représentés directement dans le poste concerné.
4.3.2 Quand, comment ? D’autres caractéristiques permettent d’affiner le mode d’organisation du travail. On peut les préciser, au niveau de chaque tâche, en sélectionnant dans la boîte pop up l’onglet « Compléments » (dans certains cas, suivant les extensions de paramétrage, d’autres informations peuvent être décrites à partir de l’onglet « Caractéristiques étendues »).
Degré d’automatisation Il s’agit de la manière dont le travail est exécuté par les ressources techniques et humaines affectées, en particulier l’aspect automatisation. On retient 3 types d’automatisation : - Automatique : représente un tâche 100% informatisée (sans l’aide de ressource humaine) - Manuel : représente un tâche 100% humaine (sans l’aide de ressource technique)
© Cecima
46/63
-
Conversationnel ou interactive : tâche mixant les 2 types de ressources, typiquement, une saisie d’information à partir d’un écran d’ordinateur.
Délai de réponse : Il s’agit du délai mis, par le responsable du travail pour déclencher un travail, alors que toutes les conditions pour le faire sont réunies : - synchronisation des événements de déclenchement, - ressources disponibles. La qualification du délai de réponse est : - Immédiat : dès que les conditions sont réunies le travail est déclenché - Différé : le travail est différé dans le temps ; la seule condition à remplir est en général l’attente d’un moment (par exemple, tous les jours à 14h) , choisi comme favorable pour l’organisation du travail. Mode de fonctionnement Il s’agit de préciser la nature de l’organisation du travail : - Unitaire : le travail s’effectue unitairement (par exemple, une commande à la fois ) ; une fois terminé, les ressources sont de nouveau disponibles pour une autre instance ou un autre travail - par Lot : préalablement au déclenchement du travail, on cumule plusieurs instances à traiter (par exemple plusieurs commandes) ou lot ; la tâche sera exécutée tant que le lot ne sera pas épuisé. Outre ces caractéristiques de mode de fonctionnement, on peut également préciser : - la fréquence de la tâche, - la durée de la tâche.
4.3.3 Conséquences des choix d’organisation Prenons comme exemple un scénario d’organisation. Tâche Mise en attente
Poste Secrétariat commercial Prévenir le client Commercial de la mise en attente Créer une Commercial commande d’achat Transmettre la Commercial demande d’achat
Automatisation Délai conversationnelle Immédiat
Fonctionnement Unitaire
conversationnelle Différé
Lot
automatique
Différé
Lot
automatique
Différé
Lot
On suppose que : - La secrétaire commerciale qui traite l’arrivée des commandes, saisit chaque commande (dès leur arrivée) et, pour celles dont un article est en rupture de stock, indique par une information que la commande est en attente, puis la commande est enregistrée . - En début d’après midi, le Commercial consulte la liste des commandes mises en attente et consacre son temps à l’appel de tous les clients dont une commande est en attente - A l’issue de chaque conversation, il enregistre sur la commande l’acceptation ou le refus du délai.
© Cecima
47/63
-
Le commercial, suivant les résultats des ses appels, et pas avant la fin de journée, décide de déclencher la fonction automatique de création et de transmission des demandes d’achats basée sur les commandes « en attente » et « acceptée ».
Saisir ces caractéristiques d’organisation pour chaque tâche (onglet « Compléments » de la boite de définition) comme par exemple :
Compte tenu de ces choix d’organisation, le modèle doit être modifié. En effet il faut revoir le déclenchement de la tâche « prévenir le client » qui est provoquée par un « timer » « début d’après midi » et non plus par la suite de la tâche « mise en attente ». On effectue les actions suivantes:
© Cecima
-
Supprimer définitivement le lien entre la tâche « mise en attente » et « prévenir le client… »
-
Créer un événement de type « intermédiaire » : Le nommer « début après midi » Choisir (boite de définition) dans la liste déroulante «déclencheur » le type « timer » :
-
Relier le « timer » et la tâche « prévenir le client... »
48/63
De la même manière, il faut modifier les enchaînements des tâches affectées au Commercial pour tenir compte des modes d’organisation différents : -
-
Le branchement « acceptation attente ? » n’a plus lieu d’être, puisque le Commercial appelle les clients et saisit sur les commandes les décisions des clients. Une fois ce travail terminé (pour toutes les commandes en attente) il est de nouveau disponible et n’est pas obligé d’enchaîner sur la création des demandes d’achat Le déclenchement de la création des demandes d’achat s’effectue par décision du commercial en fin de journée La création et la transmission des demandes d’achat ont les mêmes modes d’organisation et doivent être réalisées dans une même session. Il n’est donc pas utile de les distinguer en 2 tâches : elles peuvent être fusionnées en une seule. (Supprimer la tâche de transmission des demandes et changer le nom de la tâche de création en « créer des demandes d’achat »)
Dans un 1er temps procéder aux suppressions pour obtenir le résultat :
© Cecima
49/63
-
Créer ensuite 2 évènements intermédiaires comme précédemment : un timer « fin de journée » un événement « décision commercial »
Après quelques aménagements graphiques, on obtient :
© Cecima
50/63
Synchronisation Ces 2 événements doivent être synchronisés. En effet il faut que les deux soient réunis pour déclencher la tâche. Suivant le formalisme retenu une « synchronisation » peut être décrite de plusieurs manière : - style BPMN : c’est à partir de la notion de branchement (« Gateway ») que la synchronisation est représentée. - Choisir dans la palette d’outils le symbole - Le dessiner et le nommer « synchro création demande achat » - Dans la boite de définition sélectionner dans la liste déroulante « stéréotype » : BPMN / AND
- Relier les événements « fin de journée » et « décision commercial » à la tâche « créer demande d’achat »
Autres exemples de synchro avec : -
© Cecima
Merise :
51/63
-
UML :
On obtient en final :
On a vu par cet exemple que la vision « fonctionnelle » ou « conceptuelle » est assez différente de la vision « organisationnelle » . Ce qui apparaissait s’enchaîner « naturellement » se trouve désynchronisé, en raison des ruptures des modes d’organisation entre chaque tâche. Dans l’approche MERISE, ces 2 aspects sont particulièrement bien développés, en différenciant les niveaux « conceptuel » et « organisationnel » avec chacun des règles de construction répondant à des critères différents. Commentaire : Nous reviendrons ensuite sur cette modélisation organisationnelle après avoir vu le concept suivant d’Etat.
© Cecima
52/63
4.4 Gestion des Etats 4.4.1 Définition Certains objets « métier » (la commande , la facture , le contrat, …) passent au cours du temps par un certain nombre d'états traduisant leur cycle de vie. Ces états expriment la situation de l'objet par rapport à son évolution dans le temps, à travers les traitements qu’il subit. Exemple : la " Commande " est gérée de manière différente au cours des différentes étapes de sa vie, comme : l'arrivée de la commande, la livraison, la facturation, le règlement, l'archivage. Ces différentes étapes se traduiront par une information, en général mémorisée, reflétant l'état de la commande (commande arrivée, livrée, facturée, réglée, archivée). Ces caractéristiques d'état peuvent être modélisées : •
•
Soit dans un modèle spécifique explicitant les modes de passage d'un état à un autre. Ces types de modèles se dénomment " Diagramme d'état " ou " Cycle de vie d'un objet " et contiennent tous les états d'un même objet. Soit dans les autres modèles de traitement, conceptuel, organisationnel ou logique.
Dans ce deuxième cas, l'état exprime alors : •
Soit une pré-condition permettant de déclencher un traitement de manière analogue à un événement. Cette pré-condition indique que le traitement ne peut s'exécuter que si un état particulier de l'objet ou du système est atteint. Les états et les événements peuvent contribuer à la synchronisation d’une activité.
•
Soit un résultat, produit sous condition par un traitement. Ce résultat permet à l'objet ou au système d'atteindre un autre état.
En réalité, le diagramme d'état rassemble toutes les transitions effectuées sur l'objet, transitions que l'on devrait retrouver dans tous les modèles de traitements utilisant l'objet. La différence entre l'approche par le diagramme d'état et l’approche par les procédures, réside essentiellement dans l'angle de vue de construction des modèles ; la première étant vue d'un objet, la seconde étant vue par rapport à la fonction ou à l'organisation. Le formalisme et les outils de conception restent les mêmes.
4.4.2 Illustration
Pour illustrer l’utilisation de la notion d’état dans Win’Design, prenons l’ « objet métier » : Commande, vue à travers le processus que nous avons modélisé .
© Cecima
53/63
Nous avons déjà identifié quatre situations finales du processus : - la commande est rejetée (règle du plafond autorisé) - la commande n’est pas prise en compte (création client impossible) - la commande est validée - la commande est en attente (article indisponible) Il y a aussi des situations initiales ou intermédiaires : - la commande est arrivée - la commande est enregistrée Pour mettre en oeuvre un état, on va se situer dans un le 1er diagramme que nous avons élaboré : le détail de la prise en charge d’une commande. Sélectionner l’outil dans la barre d’outil des symboles et cliquer dans la fenêtre du diagramme. Une boite de dialogue spécifique à l’état s’affiche.
Nota : On peut également définir la notion d’état dans le Module DATA BASE, à partir des entités , des relations ou des tables. Dans ce cas, la liste des états existant est proposée. Travaillant de manière autonome dans le module BUSINESS PROCESS, nous allons utiliser le choix « Objets non définis ». Cliquer sur le radio bouton correspondant et saisir les informations d’un des états de la commande comme ci dessous :
© Cecima
54/63
Valider par la touche OK
Nota : On peut modifier les options d’affichage pour réduire la place prise par le dessin
Positionner l’état à proximité de la tâche « création pré-commande » et tracer le lien de la tâche vers l’état signifiant ainsi que c’est la tâche qui conduit cette situation.
© Cecima
55/63
Cet état sera probablement à son tour à l’origine du déclenchement d’un autre processus gérant les commandes rejetées, jusqu’à leur annulation ou leur validation ultérieure. En procédant de la même manière, on peut rajouter d’autres états dans le diagramme comme ci dessous :
© Cecima
56/63
4.4.3 Illustration dans l’organisation
La modélisation organisationnelle réalisée en p. 52 a mis en évidence la désynchronisation des tâches. La rupture entre ces tâches s’est matérialisée par la présence d’événements « fin de tâche » qui traduisent en fait des états successifs du cycle de gestion de la mise en attente des commandes : -
à l’issue de la tâche « mise en attente » du secrétariat, la commande est enregistrée avec un état « en attente ».
-
c’est à partir de la liste de ces commandes « en attente » qu’en début d’après-midi, commercial prévient les clients ; suivant la réponse du client, la mise en attente est « annulée » ou « acceptée ».
-
en fin de journée et su décision du commercial, les commandes « acceptées » font l’objet de demandes d’achat ; la commande se retrouve en « achat demandé ».
Le diagramme est alors enrichi par l’introduction des états comme suit.
© Cecima
57/63
© Cecima
58/63
4.5 Contraintes et règles de gestion
Nous avons évoqué dans notre exemple des comportements du système et l’impact des choix de gestion (des règles du « métier »). On a notamment évoqué : - L’évaluation de l’encours des commandes d’un client avant d’accepter une nouvelle commande. - La validation de la commande dans sa totalité : pas de livraison partielle. - Les conditions de création d’un client. - Les conditions d’émission d’une demande d’achat,…
Une partie de ces choix de gestion se matérialise par des séquences différenciées du processus. Nous avons représenté jusqu’à présent les branchements conditionnels permettant de traiter chaque conséquence ou situation relative à ces choix. Ces branchements ne sont que l’expression finale des résultats de condition ou règle évaluée. La notion de « règle de gestion » que nous allons maintenant utiliser permet d’exprimer et de cataloguer la démarche d’évaluation de ces conditions.(mais aussi des calculs des réglementations, des décisions, des contrôles,…) Il existe dans Win’Design deux manières de créer des règles : -
, en liaison avec les modèles de données gérés dans le module l’une DATABASE, formalise des règles à contenu informationnel explicite. Dans ce cas l’expression des règles est associée aux données.
-
, directement dans le module BUSINESS PROCESS, à partir de l’autre la notion plus générale de « Contrainte », permet de prendre en compte des règles à contenu exprimé textuellement.
C’est cette dernière que nous allons utiliser pour décrire la règle d’évaluation de « l’encours » dans le diagramme « détail Prise en charge commande ». dans la barre d’outil des symboles et cliquer dans la fenêtre du Sélectionner l’outil diagramme à proximité de la tâche « Vérification Encours commande »
Nommer et décrire la contrainte comme ci dessous (le texte descriptif est libre et peut être structuré ou non. Pour une gestion du contenu formel de la règle il faudrait utiliser la création de la règle avec le module DATABASE).
© Cecima
59/63
Après la validation on obtient :
Pour la lisibilité du diagramme, on peut retirer l’affichage du libellé et du texte descriptif (utiliser l’onglet « affichage » de la boite de définition de la contrainte).
© Cecima
60/63
On remarquera qu’au passage de la souris la bulle d’aide affiche le contenu de la contrainte.
Relier la règle avec la tâche, indiquant ainsi que la tâche déclenche l’exécution de la règle :
On peut vérifier ce lien par les référence croisées :
© Cecima
61/63
© Cecima
62/63
Le diagramme complet devient :
© Cecima
63/63
1 Préparation de l’utilisation de Win’Design 1.1 Lancement de Win’Design Lorsque vous lancez la version d’évaluation de Win’Design pour la première fois, l’assistant « Merlin » s’affichera, pour vous présenter le contenu de la version en cours.
Fermer cette fenêtre, en cochant éventuellement la case en bas de la boîte pour ne plus afficher l’assistant à chaque lancement. La partie gauche de la fenêtre affiche un arbre hiérarchique qui présente l’ensemble des modèles contenus dans l’espace de travail. Dans ce cas, il s’agit de l’espace de travail « Accueil Win’Design », qui contient des exemples illustrés que vous pourrez parcourir pour voir l’ensemble des modélisations gérées par Win’Design. Les exemples traités sont le cas « Société X » et le cas « Risquetout ».
© Cecima
1/63
Vous allez donc d’abord créer votre propre espace de travail de test. Pour cela, utiliser le menu contextuel de l’espace de travail, et cliquer sur « Nouveau » (ou utiliser le menu « Fichier – Espace de travail – Nouveau … »).
Votre environnement de travail se présente alors comme suit :
© Cecima
2/63
1.2 Ouverture d’un nouveau diagramme Positionner le curseur sur la racine de l’arbre « Espace de travail » et activer la fonction « Nouveau modèle » à partir du menu contextuel (ou activer la fonction « Nouveau » du menu « Fichier » ou cliquer sur fenêtre).
© Cecima
dans la barre d’outil en haut à gauche de la
3/63
La boite de choix du module de Win’Design s’affiche :
Cliquer sur le bouton « Business Process » ; les catégories de diagrammes disponibles de ce module s’affichent.
Nous allons dans cet exemple utiliser la notation BPMN (Business Process Management Notation)
© Cecima
4/63
Déplier le nœud « BPM » et choisir « Processus métier niveau n » On va, dans un 1er temps, se situer à un niveau détaillé du processus
Une fenêtre s’affiche permettant de décrire notre modèle
La référence du modèle (MGA1 par défaut) ainsi qu’un nœud du 1er diagramme (ou sous modèle) s’affichent également dans l’espace de travail.
Nota : MGA désigne tous les types de modèle du module Business Process (Modèle Général d’Activité).
© Cecima
5/63
1.3 Enregistrement Avant de poursuivre la modélisation, nous vous conseillons d’enregistrer votre espace de travail et votre modèle. Pour enregistrer votre espace de travail : Positionner le curseur sur la racine de l’arbre (Espace de travail), utiliser le menu contextuel de l’espace de travail et activer la fonction « Enregistrer ». Sélectionner le répertoire dans lequel vous voulez sauvegarder votre espace de travail. Nommer et enregistrer le fichier dont l’extension est .ws. Pour enregistrer votre modèle : Activer dans le menu général « Fichier/ Enregistrer » ou cliquer sur
dans
la barre d’outils. Sélectionner le répertoire dans lequel vous voulez sauvegarder votre modèle. Nommer et enregistrer le fichier dont l’extension est .mga. Pour renommer l’espace de travail, le modèle ou le sous-modèle, le sélectionner dans la liste par simple clic, et saisir le nouveau nom. Cette action est sans effet sur le nom des fichiers enregistrés correspondant.
Nota : nous vous conseillons de sauvegarder régulièrement votre travail en activant pour enregistrer le modèle courant, ou l’icône ouverts et l’espace de travail courant.
pour enregistrer tous les modèles
2 Le cas de gestion d’une commande client Le processus que nous allons illustrer est celui de la prise en charge de l’arrivée d’une commande provenant d’un client . Pour simplifier, l’organisation du travail (qui fait quoi ?) n’est pas pris en compte (Cette partie est illustrée au paragraphe 4.3 : Organisation)
Les étapes de la prise en charge d’une commande sont les suivantes : 1) Réception de la commande et contrôles préalables : Dès la réception de la commande, on effectue des contrôles sur l’existence et la situation du client : • S’il s’agit d’un nouveau client, on le crée avec les données présentes sur la commande (si les informations sont insuffisantes on arrête le processus) • Si le client existe déjà, on va vérifier que le montant total de ses commandes en cours ne dépasse pas un plafond autorisé
© Cecima
6/63
2) Création de la commande : • Dans le cas où l’encours de commande est trop élevé, on crée une « pré-commande » (on signalera au client que sa commande est refusée). • Dans les autres cas (en cours acceptable ou nouveau client) - on enregistre la commande avec ses informations de base (client, adresse de livraison, mode de règlement, date de livraison souhaitée, …). - pour chaque article commandé, on vérifie sa disponibilité. Dans le cas où un des articles n’est pas disponible (pas de livraison partielle), la commande est mise en attente (un autre processus gère la gestion des commandes en attente, en liaison avec la gestion des stocks). 3) Traitement du retour de prise en compte de la commande : Suivant l’état de la commande : • On envoie au client un courrier d’acceptation de la commande avec la date de livraison possible • On envoie au client un courrier de rejet de sa commande • On téléphone au client pour lui signaler que sa commande est en attente • On transmet au service « Achat » une demande de réapprovisionnement
3 Modélisation simplifiée 3.1 Début du processus
Un « client » envoie une « commande »qui déclenche le processus de gestion de la commande. Le « client » se modélise par un acteur externe au système d’information décrit.
Pour dessiner un acteur, cliquer sur
dans la barre des symboles de
diagrammes pour sélectionner l’outil Acteur, puis cliquer dans la fenêtre de dessin à l’endroit où vous souhaitez positionner l’acteur. Le dessin
apparaît.
Le curseur de la souris indique la fonction courante ; ici le curseur indique que l’on peut dessiner un autre acteur. Pour continuer notre exemple nous allons désactiver la fonction courante, soit en faisant un clic droit sur la souris (curseur dans un espace vide), soit en . cliquant dans la barre d’outil sur Par défaut tous les objets ont un nom (ici Acteur_1). Pour changer le nom de l’acteur, double cliquer sur le symbole de l’acteur. La boite de dialogue (dite pop up) s’affiche :
© Cecima
7/63
Saisir dans le champ « Nom » : Client (valider la saisie par la touche « Entrée » ou en sortant de la boite par , ou en cliquant n’importe où dans la fenêtre de dessin) Pour obtenir une aide complémentaire sur l’utilisation de cette boite de dialogue (ainsi que toutes les autres par la suite), cliquer sur
.
Nota : On remarque que le type d’acteur sélectionné par défaut est « Externe », coïncidant avec notre souhait de modélisation. La « commande » représente un flux d’information ou message Le terme « commande » représente dans le langage « métier » plusieurs sens : ici on s’intéresse à l’événement de la réception d’une commande, qui contient toutes les informations nécessaires au traitement de cette commande. C’est donc le « message » de l’arrivée de la commande que l’on modélise. et nommer le message « Commande » avec le même mode opératoire Dessiner que pour l’acteur.
Tracer le lien entre l’acteur et le message : Il existe deux fonctions de tracé de lien : , lien formel, qui contrôle la possibilité du tracé (dépendant des La fonction objets reliés) et induit aussi, dans certains cas, des dessins complémentaires ou le déclenchement d’assistant. La fonction
, lien libre, qui permet de relier tous objets sans contrôle.
Pour l’instant nous utiliserons la 1ère fonction : dans la barre d’outil. Cliquer sur le symbole de l’acteur , puis Choisir la fonction cliquer de nouveau sur le symbole du message (attention, l’ordre indique le sens du flux).
© Cecima
8/63
Indiquer le début du processus : Le marquage du début du processus est facultatif ; on pourrait directement relier le message à la 1ère tâche. et nommer l’événement de « début » avec le même mode opératoire que Dessiner pour l’acteur, puis tracer le lien entre le message « Commande » et le début du processus, indiquant ainsi que le processus est déclenché par l’arrivée d’une commande.
3.2 Etape de contrôles préalables On va maintenant modéliser le début du scénario de la prise en charge de la commande :
Dès la réception de la commande, on effectue des contrôles sur l’existence et la situation du client : • •
S’il s’agit d’un nouveau client, on le crée avec les données présentes sur la commande (si les informations sont insuffisantes on arrête le processus) Si le client existe déjà, on va vérifier que le montant total de ses commandes en cours ne dépasse pas un plafond autorisé.
L’ « identification du client » est la 1ère tâche à effectuer et nommer la tâche « Identification client » avec le même mode opératoire Dessiner que pour l’acteur, puis relier le début du processus et la tâche :
•
un branchement (décision) décrit les cas possibles
Dessiner un branchement amont)
© Cecima
et le nommer (fréquemment du même nom que la tâche
9/63
Utiliser l’onglet « Expression » pour saisir l’expression d’évaluation à afficher
Puis relier la tâche « Identification client » à ce branchement conditionnel. Lors du tracé la boite suivante s’affiche.
© Cecima
10/63
Elle est destinée à traiter le cas des conditions et alternatives différemment. Pour l’instant nous allons l’ignorer. Cliquer sur OK ou sur la touche « Entrée » pour continuer.
Si le client n’existe pas il faut le créer et nommer la tâche « Création client » avec le même mode opératoire que Dessiner pour la tâche précédente.
© Cecima
11/63
Relier la décision et la tâche « Création client » pour exprimer la condition de branchement vers la tâche. Pour tracer un lien coudé comme sur l’illustration, cliquer un point intermédiaire sur le schéma avant de cliquer sur la tâche « Création client ». Lors du tracé du lien la boite de dialogue s’affiche :
Saisir la valeur de condition « non » correspond à la réponse à l’expression « client connu ? » et signifiant que la séquence suivante concernera les clients à créer. Valider. La valeur de la condition s’affiche sur le lien.
© Cecima
12/63
Si la création du client n’est pas possible, le processus est arrêté , le nommer « retour création client » et mettre dans Dessiner un branchement l’expression affichée « Création OK ? ». Relier la tâche « Création client » avec le branchement (décision).
L’arrêt du processus est marqué par un événement de type « Fin ». Déplier la liste des symboles comme indiqué :
représentant une « Fin » de processus. Dessiner et nommer et choisir le dernier l’événement « fin création client impossible ». On peut également préciser, à partir de la liste déroulante « Déclencheur » la nature de l‘arrêt, dans ce cas « Erreur de traitement ».
© Cecima
13/63
Le symbole de la fin s’affiche alors comme suit :
de condition entre le branchement « Création OK ? » et la fin en erreur Tracer un lien du processus, avec comme valeur de condition « non », indiquant que la « création client » n’est pas possible :
Si la création du client est ok, on crée la commande et nommer la tâche « Création commande» avec le même mode opératoire Dessiner que pour la création des autres objets.
© Cecima
14/63
Tracer un lien de condition entre le branchement « Création OK ? » et la tâche « Création commande » avec comme valeur de condition « oui » , indiquant que la « Création client » s’est bien passée.
Si le client existe il faut vérifier son encours de commandes et nommer la tâche « Vérification Encours commande» avec le même mode Dessiner opératoire que pour la création des autres objets :
Nota : On peut afficher les noms des objets sur plusieurs lignes pour faire varier la taille des symboles : , après avoir sélectionné Dans la barre d’outil des styles : un symbole (par exemple la tâche « Vérification Encours commande »), cliquer sur la fonction
. La boite de dialogue s’affiche.
Choisir le nombre de ligne d’affichage du nom dans la liste déroulante comme ci dessus, et valider par OK. On obtient l’affichage suivant :
© Cecima
15/63
Tracer un lien de condition entre le branchement « client connu ? » et la tâche « Vérification Encours commande » avec comme valeur de condition « oui », indiquant que le client existe déjà et à été identifié.
, le nommer « vérification encours commande» et mettre Dessiner un branchement dans l’expression affichée « plafond dépassé ? » Relier la tâche « Vérification Encours commande » avec le branchement (décision).
Si le plafond autorisé est dépassé on crée une « pré-commande » et on arrête le processus et nommer la tâche « création pré-commande» avec le même mode Dessiner opératoire que pour la création des autres objets * et nommer la « fin » : « fin processus plafond dépassé». Dessiner Relier
© Cecima
la tâche et la fin du processus pour arriver à la modélisation suivante :
16/63
Si le plafond autorisé n’est pas dépassé on crée la « commande ».
© Cecima
17/63
3.3 Etape de création de la commande La « création de la commande » a déjà été représentée à l’issue de la « création d ‘un nouveau client ». la décision « plafond dépassé ? » à la tâche « Création Il reste donc à relier commande », avec une valeur de condition égale à « non » .
On remarque que la tâche « Création commande » peut être déclenchée à partir de 2 séquences différentes, l’une à partir de la « création client » l’autre à partir de la « vérification Encours commande ». Dans la mesure où ces 2 chemins sont mutuellement exclusif , il n’est pas nécessaire d’exprimer « une synchronisation » pour le déclenchement de la tâche. Vérification de la disponibilité des articles :
Pour chaque article commandé on vérifie sa disponibilité. Dans le cas où un des articles n’est pas disponible (pas de livraison partielle), la commande est mise en attente , (un autre processus gère la gestion des commandes en attente, en liaison avec la gestion des stocks)
et nommer la tâche « vérification disponibilité article» avec le même mode Dessiner opératoire que pour la création des autres objets :
© Cecima
18/63
Puis la relier avec la tâche « Création commande » : Ici nous exprimons un enchaînement inconditionnel entre deux tâches. Lors du tracé du lien, une boite de dialogue s’affiche pour permettre de choisir le contexte du tracé :
Opter pour le choix par défaut ,et valider par la touche « OK ». La boite des conditions de sortie s ‘affiche. Ne rien saisir et valider par la touche « OK ».
Cette tâche doit être faite pour chacun des articles composant la commande. On va donc exprimer la répétitivité (il existe d’autres façons de faire) par une « boucle » partant et arrivant sur la même tâche. le départ de la boucle à partir du bas de la tâche et faire 4 points Tracer intermédiaires, à la fin du tracé la boite d’option du tracé du lien s’affiche. Confirmer l’option d’enchaînement d’activités, puis cocher la case « Ne plus afficher ce message » (pour qu’elle ne s’affiche plus systématiquement). La boite des conditions s’affiche. Nous allons l’utiliser pour illustrer une autre manière d’exprimer un branchement conditionnel : Dans le cas présent, on veut modéliser le fait que la tâche va être réalisée plusieurs fois, tant qu’il reste un article à vérifier dans la commande. On va donc spécifier la condition « article suivant » qui sera la condition de déclenchement de la boucle.
© Cecima
19/63
Créer la condition puis valider par la touche OK. Le tracé du lien s’affiche .
Si lors du tracé la condition n’a pas été définie, on peut le faire à posteriori, par la boite de définition du lien (double clic sur le lien).
On peut soit choisir la liste déroulante une condition existante, soit accéder à la définition des conditions à partir du bouton « Définir… » permettant de créer une condition comme ci dessus. © Cecima
20/63
Puis après validation, dans la boite du lien, sélectionner la nouvelle condition pour l’associer au lien.
Un autre mode opératoire existe pour créer des conditions sans tracer de liens : Ouvrir la boite de définition de la tâche « vérification disponibilité article ».
et cliquer sur le bouton « Condition ». La boite de définition des conditions s’affiche et permet de créer plusieurs conditions. Créer la condition « fin ou article indisponible» :
© Cecima
21/63
Décrivons maintenant la suite du processus : • Si tous les articles sont disponibles, on valide la commande • Si un des articles manque on met la commande en attente Dessiner et nommer le branchement « disponibilité commande » avec le même mode opératoire que pour la création des autres objets , mettre dans l’expression « disponible ? »
Tracer le lien entre la tâche (cliquer vers le haut gauche) et la décision, puis sélectionner dans la boite des conditions la condition « fin ou article indisponible » exprimant que la sortie de la tâche s’effectue après vérification de tous les articles. Si l’affectation n’a pu se faire pas ce mode opératoire, passer par la boite de définition du lien en utilisant la liste déroulante « condition d’émission »
© Cecima
22/63
Nota : Dans la boite de définition de la tâche, l’onglet « Références croisées » permet de voir, vues du dictionnaire, les entrées et sorties de la tâche.
Dans ce formalisme (BPMN) les conditions de sorties exprimées dans la tâche sans utiliser de branchement conditionnel (décision) ne sont pas représentées graphiquement, contrairement au formalisme de type Merise qui positionne les conditions « en râteau » au pied de la tâche :
ou en supprimant le branchement et en rajoutant une condition.
© Cecima
23/63
Le processus se poursuit avec la validation de la commande, ou sa mise en attente suivant la condition de disponibilité : Construire la fin du schéma pour arriver au résultat suivant :
3.3 Etape de gestion du retour commande Traitement du retour de prise en compte de la commande :
Suivant l’état de la commande : • On envoie au client un courrier d’acceptation de la commande avec la date de livraison possible • On envoie au client un courrier de rejet de sa commande • On téléphone au client pour lui signaler que sa commande est en attente • On transmet au service « Achat » une demande de réapprovisionnement
Pour traiter cette dernière partie du processus, il faut prendre un peu parti dans le mode d’organisation. On peut par exemple décider que le traitement du retour se fait dans le processus en fonction des cas du traitement de la commande :
© Cecima
24/63
L’acteur « Client » existe déjà dans le graphique. Pour un motif d’esthétique graphique (éviter de tirer un lien remontant en tête du schéma), on va créer un «duplicata » de l’acteur existant et le positionner à proximité de la tâche « valider la commande ». Pour créer un duplicata, sélectionner l’acteur « Client » et appeler son menu contextuel (clic droit), choisir la fonction « Duplicata » :
Cette fonction est présente pour tous les autres types d’objet. Elle permet de représenter plusieurs fois le même objet dans le même graphique. Chacune de ses représentations peut avoir un style différent, mais la définition de l’objet est la même. On obtient le résultat suivant :
Sélectionner le duplicata, le déplacer à l’endroit choisi. de la tâche « valider la commande » vers l’acteur Tracer directement un lien « Client ». Un message est automatiquement créé. Nommer ce message « acceptation commande ». Nota: Ce mode opératoire est un raccourci pour : dessiner
et nommer un message,
tracer un lien
entre la tâche et le message,
tracer un lien
entre le message et l’acteur.
Ici on a représenté par le message « acceptation commande » le courrier d’acceptation envoyé au client. Dans la boite de définition du message choisir dans la liste déroulante « support » : courrier
© Cecima
25/63
Une icône représentative du support s’affiche à côté du message.
Nota : par défaut l’icône peut se déplacer sans déplacer l’objet auquel elle est rattachée. Pour la « fixer », utiliser le menu contextuel de l’icône et décocher « icône flottante »
On peut également changer d’icône avec la fonction du menu contextuel « changer icône ». Nota : D’autres options dans le « profil standard » permettent de paramétrer la forme, le style, l’affichage de chaque type d’objet. Pour appliquer localement à un objet un style utiliser la barre d’outil :
ou dans la boite de définition de l’objet les onglets « affichage » et « styles »
© Cecima
26/63
Poursuivre la modélisation des retours de la commande, avec les autres cas de retour de la commande : • • •
© Cecima
On envoie au client un courrier de rejet de sa commande On téléphone au client pour lui signaler que sa commande est en attente On transmet au service « Achat » une demande de réapprovisionnement
27/63
© Cecima
28/63
4 Modélisation complémentaire 4.1 Décomposition hiérarchique Dans l’exemple que nous venons de traiter, le niveau de détail choisi est celui de la description de tâche que l’on peut qualifier d’intermédiaire. Voyons maintenant comment introduire un degré de détail supplémentaire.
Prenons le cas d’une des tâches précédemment modélisée : « la mise en attente » d’une commande. Dans cette tâche, on réalise plusieurs actions que l’on pourrait détailler : -
mettre en attente la commande (on peut imaginer qu’il s ‘agit d’une saisie complémentaire par rapport à celle de la commande), téléphoner au client pour lui signaler la mise en attente de sa commande, créer une demande d’achat pour les produit en rupture de stock, transmettre la demande d’achat au Service Achats.
En fait pour détailler une tâche on peut être amené à décrire un véritable sous modèle, avec ses propres tâches et enchaînements. Avant d’effectuer cette modélisation, on peut compléter la description de la tâche « mettre la commande en attente » pour indiquer le contenu de cette tâche et faciliter ensuite la description de son détail. Dans l’onglet « Détail » de la boite de définition de la tâche, saisir dans le champ de texte le futur détail de la tâche, comme suit :
Nous allons maintenant utiliser ce « pré-découpage » pour composer la modélisation détaillée de la tâche, grâce à un assistant à la décomposition hiérarchique. Dans l’onglet « Définition » de la boite de description de la tâche, cliquer sur le bouton « Décomposer… »
© Cecima
29/63
La boite de dialogue s’affiche :
L’assistant de décomposition permet de choisir la manière dont la décomposition s’effectue et propose d’utiliser le texte de détail de la tâche comme point de départ : Chaque ligne du texte est considérée comme « tâche » de détail candidate. Par défaut tout est sélectionné. Si certaines lignes ne correspondent pas au découpage souhaitée, il suffit de les désélectionner. Valider la proposition par la touche « OK ». Un nouveau diagramme (sous modèle) s’ouvre avec certains objets affichés :
© Cecima
30/63
Chacune des lignes du texte de détail est devenue une tâche. Le contexte d’entrée et de sortie de l’opération décomposée est également pré positionné. Un cartouche a été créé automatiquement , avec pour titre le nom de la tâche amont, la flèche
permet en cliquant (double clic) dessus de « remonter » à la tâche d’origine.
Le diagramme contenant la tâche s’affiche en positionnant en son centre la tâche concernée, qui apparaît avec une flèche vers le bas. Cette flèche permet en cliquant (double clic) de « descendre » dans le diagramme représentant sa décomposition
Nous allons maintenant représenter les enchaînements entre les tâches détaillées : Pour le démarrage, on peut comme pour l’exemple principal traité, utiliser un « Evénement » de type « début ».
© Cecima
31/63
Puis utiliser la tâche proposée de mise en attente qui s’enchaîne avec l’appel au client pour le prévenir :
Dans le diagramme « amont » nous avons déjà représenté l’appel au client par le message « information sur commande en attente ». Ce message nous a été proposé lors de la décomposition. Nous allons le réutiliser en le déplaçant, ainsi que l’acteur « client », à côté de la tâche :
On suppose à ce niveau que : -
-
Si le client souhaite annuler sa commande, il en informe la société et doit envoyer un courrier d’annulation ; un autre processus traitera de la gestion de ces annulations S’il accepte, on enchaîne alors vers la création d’une demande d’achat et sa transmission au Service achat.
On complète donc le modèle en ajoutant un branchement (Décision) « acceptation attente ? » qui permet de traduire la dernière alternative :
© Cecima
32/63
© Cecima
33/63
4.2 Recomposition On vient de voir que l’on peut détailler une activité modélisée (pas de limite de profondeur) dans un nouveau diagramme. Nous allons voir maintenant la possibilité de procéder dans l’autre sens, à savoir représenter un regroupements d’activités, dont la décomposition est définie par un diagramme existant. Il faut au préalable créer un nouveau diagramme dans lequel nous allons représenter des « sous processus » de gestion des commandes :
4.2.1 Nouveau diagramme Pour créer un autre diagramme (en restant dans le même modèle) utiliser la fonction de la barre d’outil « sous modèles » , ou à partir du menu « Modèle », activer la fonction « Sous modèle / Création sous modèle… ». Dans la boite de choix des types de modèles, choisir dans le groupe « BPM » le type de diagramme « Processus métier niveau 1 » dont le paramétrage permet de décrire des « sous processus ».
Un nouveau diagramme s’ouvre.
Nous allons créer les « sous processus » évoqués dans notre exemple :
© Cecima
34/63
-
la prise en charge de la commande dont nous avons modélisé le détail, l’annulation de commande, la gestion des commandes en attente, qui gère les commandes dont les articles n’étaient pas disponibles.
On peut les représenter simplement comme une cartographie :
On peut également faire figurer les principales entrées/sorties de chacun des sous processus et orienter le diagramme comme un diagramme de contexte (seul le sous processus « Prise en charge commande » est décrit complètement dans l’exemple suivant).
Nota : les messages et l’acteur « Client » ont été réutilisés et copiés dans ce diagramme à partir du dictionnaire, comme suit :
© Cecima
-
. cliquer sur l’onglet de l’espace de travail La liste des types d’objet concernés par les diagrammes présents dans l’espace de travail s’affiche :
-
déplier le nœud « Acteur » et sélectionner : « Client » :
35/63
-
-
faire un « glisser-déposer » de l’acteur « Client » dans la fenêtre du diagramme et relâcher le bouton de la souris à l’endroit voulu : l’acteur se dessine procéder de la même manière avec le « Message » « Commande » :
Le résultat est le suivant :
On remarque que le lien entre le « Client » et la « Commande » est tracé automatiquement. Tout objet collé dans un diagramme provoque ce comportement de tracé de lien. Dans certains cas le collage entraîne le collage d’autres objets indissociables du contexte de l’objet collé.
4.2.2 lien de décomposition sous processus / détail Dans la boite de définition du sous processus « Prise en charge commande », cliquer sur le bouton « Décomposer… » pour afficher l’assistant de décomposition :
© Cecima
36/63
Par rapport au cas précédent de décomposition, il s’agit maintenant d’associer un diagramme existant. Pour cela il faut : -
-
-
© Cecima
choisir le type de modèle ; prendre « Processus métier niveau n » (utiliser l’ascenseur dans la liste des modèles type) que nous avons utilisé pour décrire le détail du sous processus, la liste des diagrammes de ce type s’affiche, cliquer sur le radio bouton « Un sous modèle existant » et sélectionner le diagramme « Détail Prise en charge commande » comme indiqué ci dessous, valider par la touche OK.
37/63
Le diagramme de détail s’affiche avec un cartouche complémentaire comportant le nom du diagramme et le dispositif (flèche) permettant de « remonter » au sous processus :
Dans le diagramme du sous processus , on remarque que la flèche de décomposition a été rajoutée sur le symbole du sous processus :
Dans la mesure où le lien de décomposition a été fait à posteriori, il faut vérifier dans le niveau de détail que toutes les tâches représentées font bien partie de la décomposition (on peut représenter dans un diagramme des tâches provenant d’autres processus) : Dans la boite de définition des tâches, vérifier la case à cocher « Appartient à la décomposition ».
On peut voir également dans les références croisées l’effet de la décomposition. Exemple d’un niveau intermédiaire issu d’une décomposition et lui-même décomposé : la tâche « mettre la commande en attente » :
© Cecima
38/63
Nota : le terme « Activité » est un terme générique couvrant tous types d’action ou de traitement (processus, tâche, procédure, fonction, …). Le type d’ activité est précisé à côté du nom : « Prise en charge commande : Sub Process ».
L’opération de recomposition peut encore être faite en montant d’un niveau, en construisant un diagramme qui recense les différents processus (non exhaustif) de l’entreprise, dont la « Gestion des commandes ». Créer un nouveau diagramme comme précédemment en choisissant «Processus métier niveau 0 » Nommer le diagramme « Principaux processus » Représenter les différents processus.
Décomposer le processus « Gestion des commandes » dans le diagramme « Sous processus Gestion des commandes »
© Cecima
39/63
Pour se donner une idée de la hiérarchie de navigation dans ces diagrammes, on peut utiliser un outil de visualisation :
© Cecima
-
Cliquer dans la barre des « sous modèles » (en bas de l’écran) l’outil la fenêtre suivante s’affiche
-
Déplier le nœud « Gestion des commandes » puis celui du sous processus « prise en charge commande » puis celui de la tâche « mettre la commande en attente ».
40/63
Cet outil permet aussi, par double clic sur un élément, d’afficher le diagramme dans lequel se trouve cet élément
© Cecima
41/63
4.3 Organisation Jusqu’à présent, pour simplifier la prise en main de Win’Design, l’aspect organisationnel des processus (en général cette dimension est présente dès le début, surtout pour la modélisation de l’existant), n’a pas été abordé.
4.3.1 Qui fait quoi ? Prenons un diagramme déjà réalisé dans l’exemple ci dessus : « mettre la commande en attente » :
On va s’intéresser dans un 1er temps à la répartition du travail : qui effectue quelle tâche ? Suivant les formalismes, la notion utilisée peut être un « Rôle », un « Acteur », une « Unité organisationnelle », un « Poste de travail » . Nous utiliserons dans la suite de l’exemple la notion de « Poste de travail ». Scénario :
© Cecima
42/63
On va supposer que la 1ère tâche « mise en attente » est faite par le « Secrétariat commercial » et que les tâches suivantes sont réalisée par le « Commercial » Les intervenants ou profils de compétence ou postes de travail sont représentés par dans la barre d’outil des symboles . Ceci correspond à des colonnes de tableaux dans lesquelles les tâches sont représentées. Pour « organiser » le diagramme existant, nous allons simplement déplacer les éléments dans les colonnes concernées Prendre l’outil existant :
-
© Cecima
et cliquer dans la fenêtre du diagramme à la droite du schéma
nommer le poste de travail (double clic sur le rectangle supérieur du symbole) : « Secrétariat commercial » sélectionner le début et la tâche « mise en attente » et déplacer la sélection dans le poste
43/63
créer un autre poste de travail nommé « Commercial » et déplacer le reste du schéma à l’intérieur du poste Nota : on remarquera que le nouveau poste vient se positionner automatiquement accolé à droite du précédent -
-
© Cecima
aménager éventuellement le schéma pour obtenir la présentation ci dessous :
44/63
Nota : Le positionnement des tâches dans un poste provoque automatiquement l’agrandissement de la colonne (en largeur et hauteur). Attention : Une fois positionnées dans un poste, le déplacement de tâches provoque l’agrandissement de sa colonne. Si on souhaite les changer de poste, il faut : - soit, au moment du déplacement, appuyer en même temps sur la touche « Ctrl » - soit choisir le nouveau poste dans la boite de définition de la tâche, par la liste déroulante : « poste de travail »
© Cecima
45/63
Nota : lorsque l’aspect de l’organisation est pris en compte dès le début de la modélisation, les postes sont dessinés d’abord, puis les objets sont représentés directement dans le poste concerné.
4.3.2 Quand, comment ? D’autres caractéristiques permettent d’affiner le mode d’organisation du travail. On peut les préciser, au niveau de chaque tâche, en sélectionnant dans la boîte pop up l’onglet « Compléments » (dans certains cas, suivant les extensions de paramétrage, d’autres informations peuvent être décrites à partir de l’onglet « Caractéristiques étendues »).
Degré d’automatisation Il s’agit de la manière dont le travail est exécuté par les ressources techniques et humaines affectées, en particulier l’aspect automatisation. On retient 3 types d’automatisation : - Automatique : représente un tâche 100% informatisée (sans l’aide de ressource humaine) - Manuel : représente un tâche 100% humaine (sans l’aide de ressource technique)
© Cecima
46/63
-
Conversationnel ou interactive : tâche mixant les 2 types de ressources, typiquement, une saisie d’information à partir d’un écran d’ordinateur.
Délai de réponse : Il s’agit du délai mis, par le responsable du travail pour déclencher un travail, alors que toutes les conditions pour le faire sont réunies : - synchronisation des événements de déclenchement, - ressources disponibles. La qualification du délai de réponse est : - Immédiat : dès que les conditions sont réunies le travail est déclenché - Différé : le travail est différé dans le temps ; la seule condition à remplir est en général l’attente d’un moment (par exemple, tous les jours à 14h) , choisi comme favorable pour l’organisation du travail. Mode de fonctionnement Il s’agit de préciser la nature de l’organisation du travail : - Unitaire : le travail s’effectue unitairement (par exemple, une commande à la fois ) ; une fois terminé, les ressources sont de nouveau disponibles pour une autre instance ou un autre travail - par Lot : préalablement au déclenchement du travail, on cumule plusieurs instances à traiter (par exemple plusieurs commandes) ou lot ; la tâche sera exécutée tant que le lot ne sera pas épuisé. Outre ces caractéristiques de mode de fonctionnement, on peut également préciser : - la fréquence de la tâche, - la durée de la tâche.
4.3.3 Conséquences des choix d’organisation Prenons comme exemple un scénario d’organisation. Tâche Mise en attente
Poste Secrétariat commercial Prévenir le client Commercial de la mise en attente Créer une Commercial commande d’achat Transmettre la Commercial demande d’achat
Automatisation Délai conversationnelle Immédiat
Fonctionnement Unitaire
conversationnelle Différé
Lot
automatique
Différé
Lot
automatique
Différé
Lot
On suppose que : - La secrétaire commerciale qui traite l’arrivée des commandes, saisit chaque commande (dès leur arrivée) et, pour celles dont un article est en rupture de stock, indique par une information que la commande est en attente, puis la commande est enregistrée . - En début d’après midi, le Commercial consulte la liste des commandes mises en attente et consacre son temps à l’appel de tous les clients dont une commande est en attente - A l’issue de chaque conversation, il enregistre sur la commande l’acceptation ou le refus du délai.
© Cecima
47/63
-
Le commercial, suivant les résultats des ses appels, et pas avant la fin de journée, décide de déclencher la fonction automatique de création et de transmission des demandes d’achats basée sur les commandes « en attente » et « acceptée ».
Saisir ces caractéristiques d’organisation pour chaque tâche (onglet « Compléments » de la boite de définition) comme par exemple :
Compte tenu de ces choix d’organisation, le modèle doit être modifié. En effet il faut revoir le déclenchement de la tâche « prévenir le client » qui est provoquée par un « timer » « début d’après midi » et non plus par la suite de la tâche « mise en attente ». On effectue les actions suivantes:
© Cecima
-
Supprimer définitivement le lien entre la tâche « mise en attente » et « prévenir le client… »
-
Créer un événement de type « intermédiaire » : Le nommer « début après midi » Choisir (boite de définition) dans la liste déroulante «déclencheur » le type « timer » :
-
Relier le « timer » et la tâche « prévenir le client... »
48/63
De la même manière, il faut modifier les enchaînements des tâches affectées au Commercial pour tenir compte des modes d’organisation différents : -
-
Le branchement « acceptation attente ? » n’a plus lieu d’être, puisque le Commercial appelle les clients et saisit sur les commandes les décisions des clients. Une fois ce travail terminé (pour toutes les commandes en attente) il est de nouveau disponible et n’est pas obligé d’enchaîner sur la création des demandes d’achat Le déclenchement de la création des demandes d’achat s’effectue par décision du commercial en fin de journée La création et la transmission des demandes d’achat ont les mêmes modes d’organisation et doivent être réalisées dans une même session. Il n’est donc pas utile de les distinguer en 2 tâches : elles peuvent être fusionnées en une seule. (Supprimer la tâche de transmission des demandes et changer le nom de la tâche de création en « créer des demandes d’achat »)
Dans un 1er temps procéder aux suppressions pour obtenir le résultat :
© Cecima
49/63
-
Créer ensuite 2 évènements intermédiaires comme précédemment : un timer « fin de journée » un événement « décision commercial »
Après quelques aménagements graphiques, on obtient :
© Cecima
50/63
Synchronisation Ces 2 événements doivent être synchronisés. En effet il faut que les deux soient réunis pour déclencher la tâche. Suivant le formalisme retenu une « synchronisation » peut être décrite de plusieurs manière : - style BPMN : c’est à partir de la notion de branchement (« Gateway ») que la synchronisation est représentée. - Choisir dans la palette d’outils le symbole - Le dessiner et le nommer « synchro création demande achat » - Dans la boite de définition sélectionner dans la liste déroulante « stéréotype » : BPMN / AND
- Relier les événements « fin de journée » et « décision commercial » à la tâche « créer demande d’achat »
Autres exemples de synchro avec : -
© Cecima
Merise :
51/63
-
UML :
On obtient en final :
On a vu par cet exemple que la vision « fonctionnelle » ou « conceptuelle » est assez différente de la vision « organisationnelle » . Ce qui apparaissait s’enchaîner « naturellement » se trouve désynchronisé, en raison des ruptures des modes d’organisation entre chaque tâche. Dans l’approche MERISE, ces 2 aspects sont particulièrement bien développés, en différenciant les niveaux « conceptuel » et « organisationnel » avec chacun des règles de construction répondant à des critères différents. Commentaire : Nous reviendrons ensuite sur cette modélisation organisationnelle après avoir vu le concept suivant d’Etat.
© Cecima
52/63
4.4 Gestion des Etats 4.4.1 Définition Certains objets « métier » (la commande , la facture , le contrat, …) passent au cours du temps par un certain nombre d'états traduisant leur cycle de vie. Ces états expriment la situation de l'objet par rapport à son évolution dans le temps, à travers les traitements qu’il subit. Exemple : la " Commande " est gérée de manière différente au cours des différentes étapes de sa vie, comme : l'arrivée de la commande, la livraison, la facturation, le règlement, l'archivage. Ces différentes étapes se traduiront par une information, en général mémorisée, reflétant l'état de la commande (commande arrivée, livrée, facturée, réglée, archivée). Ces caractéristiques d'état peuvent être modélisées : •
•
Soit dans un modèle spécifique explicitant les modes de passage d'un état à un autre. Ces types de modèles se dénomment " Diagramme d'état " ou " Cycle de vie d'un objet " et contiennent tous les états d'un même objet. Soit dans les autres modèles de traitement, conceptuel, organisationnel ou logique.
Dans ce deuxième cas, l'état exprime alors : •
Soit une pré-condition permettant de déclencher un traitement de manière analogue à un événement. Cette pré-condition indique que le traitement ne peut s'exécuter que si un état particulier de l'objet ou du système est atteint. Les états et les événements peuvent contribuer à la synchronisation d’une activité.
•
Soit un résultat, produit sous condition par un traitement. Ce résultat permet à l'objet ou au système d'atteindre un autre état.
En réalité, le diagramme d'état rassemble toutes les transitions effectuées sur l'objet, transitions que l'on devrait retrouver dans tous les modèles de traitements utilisant l'objet. La différence entre l'approche par le diagramme d'état et l’approche par les procédures, réside essentiellement dans l'angle de vue de construction des modèles ; la première étant vue d'un objet, la seconde étant vue par rapport à la fonction ou à l'organisation. Le formalisme et les outils de conception restent les mêmes.
4.4.2 Illustration
Pour illustrer l’utilisation de la notion d’état dans Win’Design, prenons l’ « objet métier » : Commande, vue à travers le processus que nous avons modélisé .
© Cecima
53/63
Nous avons déjà identifié quatre situations finales du processus : - la commande est rejetée (règle du plafond autorisé) - la commande n’est pas prise en compte (création client impossible) - la commande est validée - la commande est en attente (article indisponible) Il y a aussi des situations initiales ou intermédiaires : - la commande est arrivée - la commande est enregistrée Pour mettre en oeuvre un état, on va se situer dans un le 1er diagramme que nous avons élaboré : le détail de la prise en charge d’une commande. Sélectionner l’outil dans la barre d’outil des symboles et cliquer dans la fenêtre du diagramme. Une boite de dialogue spécifique à l’état s’affiche.
Nota : On peut également définir la notion d’état dans le Module DATA BASE, à partir des entités , des relations ou des tables. Dans ce cas, la liste des états existant est proposée. Travaillant de manière autonome dans le module BUSINESS PROCESS, nous allons utiliser le choix « Objets non définis ». Cliquer sur le radio bouton correspondant et saisir les informations d’un des états de la commande comme ci dessous :
© Cecima
54/63
Valider par la touche OK
Nota : On peut modifier les options d’affichage pour réduire la place prise par le dessin
Positionner l’état à proximité de la tâche « création pré-commande » et tracer le lien de la tâche vers l’état signifiant ainsi que c’est la tâche qui conduit cette situation.
© Cecima
55/63
Cet état sera probablement à son tour à l’origine du déclenchement d’un autre processus gérant les commandes rejetées, jusqu’à leur annulation ou leur validation ultérieure. En procédant de la même manière, on peut rajouter d’autres états dans le diagramme comme ci dessous :
© Cecima
56/63
4.4.3 Illustration dans l’organisation
La modélisation organisationnelle réalisée en p. 52 a mis en évidence la désynchronisation des tâches. La rupture entre ces tâches s’est matérialisée par la présence d’événements « fin de tâche » qui traduisent en fait des états successifs du cycle de gestion de la mise en attente des commandes : -
à l’issue de la tâche « mise en attente » du secrétariat, la commande est enregistrée avec un état « en attente ».
-
c’est à partir de la liste de ces commandes « en attente » qu’en début d’après-midi, commercial prévient les clients ; suivant la réponse du client, la mise en attente est « annulée » ou « acceptée ».
-
en fin de journée et su décision du commercial, les commandes « acceptées » font l’objet de demandes d’achat ; la commande se retrouve en « achat demandé ».
Le diagramme est alors enrichi par l’introduction des états comme suit.
© Cecima
57/63
© Cecima
58/63
4.5 Contraintes et règles de gestion
Nous avons évoqué dans notre exemple des comportements du système et l’impact des choix de gestion (des règles du « métier »). On a notamment évoqué : - L’évaluation de l’encours des commandes d’un client avant d’accepter une nouvelle commande. - La validation de la commande dans sa totalité : pas de livraison partielle. - Les conditions de création d’un client. - Les conditions d’émission d’une demande d’achat,…
Une partie de ces choix de gestion se matérialise par des séquences différenciées du processus. Nous avons représenté jusqu’à présent les branchements conditionnels permettant de traiter chaque conséquence ou situation relative à ces choix. Ces branchements ne sont que l’expression finale des résultats de condition ou règle évaluée. La notion de « règle de gestion » que nous allons maintenant utiliser permet d’exprimer et de cataloguer la démarche d’évaluation de ces conditions.(mais aussi des calculs des réglementations, des décisions, des contrôles,…) Il existe dans Win’Design deux manières de créer des règles : -
, en liaison avec les modèles de données gérés dans le module l’une DATABASE, formalise des règles à contenu informationnel explicite. Dans ce cas l’expression des règles est associée aux données.
-
, directement dans le module BUSINESS PROCESS, à partir de l’autre la notion plus générale de « Contrainte », permet de prendre en compte des règles à contenu exprimé textuellement.
C’est cette dernière que nous allons utiliser pour décrire la règle d’évaluation de « l’encours » dans le diagramme « détail Prise en charge commande ». dans la barre d’outil des symboles et cliquer dans la fenêtre du Sélectionner l’outil diagramme à proximité de la tâche « Vérification Encours commande »
Nommer et décrire la contrainte comme ci dessous (le texte descriptif est libre et peut être structuré ou non. Pour une gestion du contenu formel de la règle il faudrait utiliser la création de la règle avec le module DATABASE).
© Cecima
59/63
Après la validation on obtient :
Pour la lisibilité du diagramme, on peut retirer l’affichage du libellé et du texte descriptif (utiliser l’onglet « affichage » de la boite de définition de la contrainte).
© Cecima
60/63
On remarquera qu’au passage de la souris la bulle d’aide affiche le contenu de la contrainte.
Relier la règle avec la tâche, indiquant ainsi que la tâche déclenche l’exécution de la règle :
On peut vérifier ce lien par les référence croisées :
© Cecima
61/63
© Cecima
62/63
Le diagramme complet devient :
© Cecima
63/63
Related Documents
Tutorial Business Process Bpm
October 2019 17
Bpm - Business Process Management
October 2019 14
Bpm Bussiness Process Managament
August 2019 25
Bpm
May 2020 18
Bpm
November 2019 28