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 dans la barre d’outil en haut à gauche de la
fenêtre).

© Cecima 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

l’icône pour enregistrer le modèle courant, ou pour enregistrer tous les modèles
ouverts et l’espace de travail courant.

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.

Dessiner et nommer le message « Commande » avec le même mode opératoire

que pour l’acteur.

Tracer le lien entre l’acteur et le message :

Il existe deux fonctions de tracé de lien :

La fonction , lien formel, qui contrôle la possibilité du tracé (dépendant des

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 :

Choisir la fonction dans la barre d’outil. Cliquer sur le symbole de l’acteur , puis
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.

Dessiner et nommer l’événement de « début » avec le même mode opératoire que

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

Dessiner et nommer la tâche « Identification client » avec le même mode opératoire

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 et le nommer (fréquemment du même nom que la tâche

amont)

© Cecima 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

Dessiner et nommer la tâche « Création client » avec le même mode opératoire que
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é

Dessiner un branchement , le nommer « retour création client » et mettre dans

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é :

et choisir le dernier représentant une « Fin » de processus. Dessiner et nommer

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 :

Tracer un lien de condition entre le branchement « Création OK ? » et la fin en erreur

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

Dessiner et nommer la tâche « Création commande» avec le même mode opératoire

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

Dessiner et nommer la tâche « Vérification Encours commande» avec le même mode

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 :

Dans la barre d’outil des styles : , après avoir sélectionné

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é.

Dessiner un branchement , le nommer « vérification encours commande» et mettre

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

Dessiner et nommer la tâche « création pré-commande» avec le même mode

opératoire que pour la création des autres objets
*
Dessiner et nommer la « fin » : « fin processus plafond dépassé».

Relier la tâche et la fin du processus pour arriver à la modélisation suivante :

© Cecima 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 ».
Il reste donc à relier la décision « plafond dépassé ? » à la tâche « Création
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)

Dessiner et nommer la tâche « vérification disponibilité article» avec le même mode

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.

Tracer le départ de la boucle à partir du bas de la tâche et faire 4 points

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.

Tracer directement un lien de la tâche « valider la commande » vers l’acteur

« 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 :

• 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

© Cecima 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 :

- 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 » :

© Cecima 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 :

- 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.

© Cecima 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 :

- 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 ».

© Cecima 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 et cliquer dans la fenêtre du diagramme à la droite du schéma

existant :

- 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

© Cecima 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

- aménager éventuellement le schéma pour obtenir la présentation ci

dessous :

© Cecima 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 Poste Automatisation Délai Fonctionnement

Mise en attente Secrétariat conversationnelle Immédiat Unitaire
commercial
Prévenir le client Commercial conversationnelle Différé Lot
de la mise en
attente
Créer une Commercial automatique Différé Lot
commande
d’achat
Transmettre la Commercial automatique Différé Lot
demande
d’achat

 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:

- 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... »

© Cecima 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 :

- Merise :

© Cecima 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 :

- l’une , en liaison avec les modèles de données gérés dans le module

DATABASE, formalise des règles à contenu informationnel explicite. Dans
ce cas l’expression des règles est associée aux données.

- l’autre , directement dans le module BUSINESS PROCESS, à partir de

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 ».

Sélectionner l’outil dans la barre d’outil des symboles et cliquer dans la fenêtre du
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