Introduction à la gestion des processus d'affaires

3. Analyse des processus

4. Processus de re-conception (To Be or As wished)

5. Procédé de mise en œuvre

6. Suivi du processus / contrôle

12

Phase 3: Analyse

Analyse Qualitative

• Analyse des causes • Représentation avec des graphiques • Registre des observations

Analyse Quantitative

• Analyse de flux • Analyse des files d’attente • Processus de simulation

13

Comment s'engager dans BPM?

1.

Identification des processus et évaluation des possibilités

2. Processus de découverte (As is)

3. Analyse des processus

4. Processus de re-conception (To Be or As wished)

5. Procédé de mise en œuvre

6. Suivi du processus / contrôle

14

Phase 4: Processus de Re-conception

Coûts

Temps

Flexibilité

Qualité

15

Comment s'engager dans BPM?

1.

Identification des processus et évaluation des possibilités

2. Processus de découverte (As is)

3. Analyse des processus

4. Processus de re-conception (To Be or As wished)

5. Procédé de mise en œuvre

6. Suivi du processus / contrôle

16

Phases 5-6. Quand la technologie arrive..

17

Workflow

• Définition: Automatisation de tout ou partie d’un

processus d’entreprise, au cours duquel l’information circule d’une activité à l’autre, c’est- à-dire d’un participant à l’autre, pour action en fonction d’un ensemble de règles de gestion. • Objectif : Rationnaliser, coordonner et contrôler

des processus d’entreprise impliquant des tâches humaines et automatisées dans un environnement organisationnel distribué et informatisé.

18

Système de Gestionde Workflow

• Système de Gestion de Workflow (SGWf,

WfMS)

• Un ensemble d’outils permettant la définition de

processus, l’exécution de workflow, et l’administration et la surveillance d’instances de processus.

19

20

Architecture Workflow : quelques standard

21

Exemple avec FlowMind

22

Moteurs processus d'exécution

• BPEL-based Business Process Execution

Language:

– Le fichier BPEL définit le processus, ou l'enchaînement et la logique des actions qui seront exécutées par le moteur (une machine virtuelle capable d'exécuter le code BPEL) . – La structure du fichier BPEL est la même que celle du

processus. Ce fichier est véritablement le code source de l'application que constitue le processus.

– Exemple: Oracle SOA Suite, ActiveVOS BPM

23

Moteurs processus d'exécution

• La balise <process> est l'élément racine (au sens XML) du

fichier BPEL. C'est à l'intérieur de cette balise que se retrouvera la description complète du processus. Grâce à l'attribut name, on peut donner un nom au processus.

Exemple: <process

name="processName" xmlns=http://docs.oasis-open.org/wsbpel/2.0/process/executable targetNamespace="http://example.com" xmlns:tns="http://example.com" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

[...] </process>

24

BPMN …

• Un modèle de processus BPMN est un

graphique composé de quatre types d'éléments (entre autres):

25

Processus de gestion des commandes dans BPMN, (premier essai)

26

Check stock availabilityReject orderConfirm orderSend invoiceShip goodsUn peu plus sur la notation ...

• Decision exclusive / fusion

– Indique, à l'intérieur d'un processus d'affaires, où le flux

de séquence peut prendre deux ou plusieurs voies alternatives.

– Seul l'un des chemins peut être pris. – Représenté par une forme de losange qui peut contenir

un marqueur qui a la forme d'un "X".

• Parallel Fork / Join

– Fournir un mécanisme pour synchroniser le parallèlisme

et pour créer un flux parallèle.

– Représenté par un losange qui doit contenir un

marqueur qui a la forme d'un signe plus.

27

Processus de gestion des commandes révisé

28

Check stock availabilityReject orderConfirm orderSend invoiceShip goodsBPMN Exercise: Cas”Assurance”

- Quand une demande est reçue, elle est d'abord vérifiée si le demandeur a une police d'assurance en cours de validité. Sinon, le demandeur est informé que sa demande est rejetée en raison d'une stratégie non valide.

- Dans le cas contraire, la gravité de la demande est évaluée. Basé sur les résultats (demandes simples ou complexes), les formulaires pertinents sont envoyés au demandeur. Une fois les formulaires sont renvoyés, ils sont vérifiés s’ils sont complets.

- Si les formulaires sont complets, la demande est enregistrée dans le système de gestion des réclamations et l'évaluation de la demande peut commencer. Sinon, le demandeur est invité à mettre à jour les formulaires. Lors de la réception des formulaires mises à jour, ils sont à nouveau contrôlés.

29

Éléments d'organisation dans les modèles de processus

Deux abstractions de base: Ressources: acteur (par exemple une imprimante) qui est

nécessaire pour exercer une activité Classe de ressources: ensemble de ressources avec des caractéristiques communes, par exemple, employés, gestionnaires, agents d'assurance

Classe de ressource peut être un:

Rôle (compétence, qualification)? Classification basée sur ce qu’une ressource peut faire ou devrait faire. Groupe (département, équipe, bureau, unité d'organisation)? Classification basée sur la structure de l'organisation.

30

Modélisation des ressources en BPMN

• Dans BPMN, les classes de ressources sont

représentées par: Pools - entités organisationnelles indépendantes, par exemple, Client, fournisseur, Lanes - classes de ressources dans le même espace d'organisation et des systèmes communs de partage par exemple: Service des ventes, Service Marketing, Directeur, Ingénieur

31

Lanes and Pools – Notation

32

Processus de gestion de commandes à travers la notation « Pool »

33

CustomerSupplierCheck stock availabilityConfirm orderReject orderSend invoiceShip goodsPlace purchase orderPurchaseorderOrder Rejection NotificationOrder confirmationnotificationInvoiceMake paymentShipment notificationProcessus de gestion de commandes à travers la notation « Lanes»

34

BPMN Exercise: Lanes, Pools Gestion de reclamation chez un assureur de voitures: travers une • Un client présente une demande à

documentation complète.

• Le service à la clientèle vérifie si les documents sont

complets et enregistre la demande.

• Le département de traitement des demandes les prend et

•

•

vérifie la politique de réclamation d'assurance. Ensuite, une évaluation est faite. Si l'évaluation est positive, un garage est autorisé à faire les réparations et le paiement est prévu parallelement . Dans tous les cas (si le résultat est positif ou négatif), un courrier électronique est envoyé au client pour informer du résultat.

35

Les Artifacts

• Data Objects sont un mécanisme pour

montrer comment les données sont prises ou produites par les activités. - Sont représentés par un rectangle qui a son coin supérieur droit replié. - Représenter l’entrée et la sortie d'une activité de processus.

• Data stores sont des conteneurs

d'objets de données qui doivent être conservés au-delà de la durée d'une instance de processus

• Associations sont utilisées pour lier des objets tels que Data Objects et Data Stores avec des objets de flux (par exemple, les activités).

36

Data Store

Data ObjectDirected associationUndirected association Processus de gestion de commandes à travers la notation « Pool »

37

CustomerSupplierCheck stock availabilityConfirm orderReject orderSend invoiceShip goodsPlace purchase orderPurchaseorderOrder Rejection NotificationOrder confirmationnotificationInvoiceMake paymentShipment notificationTraitement des commandes: Modèle avec Artefacts

38

Check stock availabilityConfirm orderReject orderSend invoiceShip goodsSet PO to approvedSet PO to rejectedPurchaseOrderElements principaux de BPMN

Connections

Swimlanes

Flow Objects

Artifacts

Data Store

39

GatewayEventActivityMessageFlowAssociationText AnnotationData ObjectPoolLane

Décrire tous les documents pertinents dans le modèle

Quand une réclamation liée à un grave accident de voiture est évaluée, le rapport d'accident de voiture

un employé récupère d'abord correspondant dans la base de données des rapports de police.

Si le rapport est récupéré, il est joint au dossier de réclamation. Le dossier de demande et le rapport de police servent comme entrée au gestionnaire de sinistres qui calcule une estimation de la demande initiale.

Ensuite, un "plan d'action" est créé sur la base d'une "liste de contrôle". Basé sur le plan d'action et l'estimation initiale des réclamations, un

gestionnaire de sinistres négocie un règlement avec le client.

Après cette négociation, le gestionnaire des sinistres rend une décision finale, met à jour le dossier de demande, enregistre cette décision, et envoie une lettre au demandeur pour l’informer de la décision.

40

BPMN Gateways

Exclusive (XOR)

Parallel (AND)

Inclusive (OR)

• Exclusive decision

prendre une branche

• Exclusive merge fonctionne quand une branche a été complétée

• Parallel split

prendre toutes les branches • Parallel join

procéde lorsque toutes les branches entrantes ont terminé

• Inclusive decision prendre une ou plusieurs branches en fonction des conditions

• Inclusive merge

procéder lorsque toutes les branches entrantes actives ont terminé

41

Exemple: Ou gateways

42

Exercice: Modéliser à l'aide de « OU Gateway »

• Quand une demande est reçue, elle est

enregistrée. Après l'enregistrement, la demande est classée menant à deux résultats possibles: simple ou complexe.

• Si la demande est simple, la politique est cochée. • Pour les demandes complexes, les dommages sont vérifiés et peuvent entrainer une étude de politique ou étude de dommages /collisions.

43

Quelque chose ne va pas avec ce modèle?

44

Est-ce mieux?

45

Encore…

46

Sous-processus

• Une activité dans un processus peut "invoquer"

un (sous-) processus distinct

• Utilisez cette fonction pour:

1. Décomposer les grands modèles en plus petits, ce qui

les rend plus faciles à comprendre et à maintenir

•  processus hierarchiques

2. Partager les fragments communs entre plusieurs

processus  Sous-processus partagé

3. Identifier les parties d'un processus qui devrait être:

• Répétée • plusieurs fois exécutées en parallèle • Annulée

47

Processus hierarchiques

48

Access Credit RecordProcess Inquity and QuoteReceive and Validate Order...Enter OrderReceive Order...Check CreditContact customer account rep.Clear OrderCredit Available?...Level 3Level 4Level 5Modélisation directive Commencer par une chaîne de valeur

• La bonne pratique est que la modélisation de

haut niveau doit être simple ( pas de passerelles « Gateway ») et doit montrer les principales phases du processus d’affaires

– Chaque phase est alors un sous- processus – Appelée une " chaîne de valeur « (“value chain”)

49

La chaîne de valeur avec des sous- processus

50

Purchase RequestApprovalPurchase OrderGoods ReceiptInvoice VerificationPurchase Request processCheck purchase request for 1st approvalCheck purchase request for 2nd approvalapprovedConsider re-submissionrejectedrejectedapprovedSend approved request to requestorPurchase RequestMake copy of purchase requestApproved Purchase RequestForward to purchase departmentPurchase Order processSous- processus partagé

51

Sous-processus et marqueur de boucle

Equivalent à:

52

Exercice

Après qu’une demande soit enregistrée, elle est examinée par un expert en sinistres . Ce dernier propose alors une «estimation de règlement ". Cette estimation est vérifiée par un autre expert en sinistres qui peut marquer la demande comme «OK: acceptée » ou « Not OK ».

Si elle est marquée comme " Not OK " , elle est renvoyé à l’agent de traitement de demandes et l'examen est répété .

Si la demande est marquée comme "OK" , l'agent de le client du

informe

traitement de demandes règlement.

53

Marqueur des “Multiple instances”

Utile lorsque la même activité doit être exécutée pour plusieurs

entités ou même type de données, par exemple,

- Demander un devis à plusieurs fournisseurs

- Vérifiez la disponibilité de chaque poste dans une commande

séparément

- Envoyer et recueillir les questionnaires pour plusieurs témoins

54

Exemple d’activité de type “Multiple instances”

55

For each supplierSelect Best QuoteSend POObtain QuoteTypes d’évenements: “Event types”

56

Start/End Event – Indicates that an instance of the process is created/terminated when an event occurs without specifying the cause of this eventIntermediate event – Indicates that an event is expected to occur during the process, without indicating the cause of the eventStart Message Event – Indicates that an instance of the process is created when a message is receivedEnd Message Event – Indicates that the process is terminated when a message is receivedIntermediate Message Event – Indicates that an event is expected to occur during the process the event is triggered when a message is received.Suite...

57

Start Timer Event – Indicates that an instance of the process is created at certain date(s)/time(s), e.g. start process at 6pm every FridayIntermediate Timer Event – Triggered at certain date(s)/time(s), or after a time interval has elapsed since the moment the event is “enabled”Intermediate/End Compensate Event – Indicates that the enclosing process must be compensated: the end version generates the compensation event while the “intermediate” version consumes itEnd Link Event – Indicates that the process flow continues elsewhere (e.g. in a separate diagram)Start/Intermediate Link Event – Indicates that the process flow is being picked up from a “previous” diagram”.Intermediate/End Exception Event – Indicates an error: the “end” version generates the exception event while the “intermediate” version consumes itModéliser avec les évenements

Un processus de traitement des commandes commence quand un bon de commande (PO) est reçu. Le PO est d'abord enregistré.

Si la date du jour n’est pas un jour de travail, le

processus attend le jour ouvrable suivant avant de continuer.

Sinon, un contrôle de disponibilité est effectué et une

"réponse de PO" est envoyée au client.

À tout moment au cours du processus, le client peut envoyer une "demande de changement PO". Lorsqu'une telle demande est reçue, elle est juste

enregistrée, sans autre action.

58

Modelling with events - Example

59

Register POReceive PONext working dayweekend/holidayCheck AvailabilityReceive PO ChangeRegister PO ChangeSend PO Response Caisse enregistreuse

• Un client arrive à la caisse avec des articles à payer. • Le caissier enregistre le numéro d’identification (CPU) de chaque article, ainsi que la

quantité si elle est supérieure à un.

• La caisse affiche le prix de chaque article et son libellé. • Lorsque tous les achats sont enregistrés, le caissier signale la fin de la vente. • La caisse affiche le total des achats. • Le client choisit son mode de paiement : – numéraire : le caissier encaisse l’argent

reçu, la caisse indique la monnaie à rendre au client ; – chèque : le caissier vérifie la solvabilité du client en transmettant une requête à un centre d’autorisation via la caisse ; – carte de crédit : un terminal bancaire fait partie de la caisse. Il transmet une demande d’autorisation à un centre d’autorisation en fonction du type de la carte.

• La caisse enregistre la vente et imprime un ticket. • Le caissier donne le ticket de caisse au client. Après la saisie des articles, le client

peut présenter au caissier des coupons de réduction pour certains articles. Lorsque le paiement est terminé, la caisse transmet les informations sur le nombre d’articles vendus au système de gestion de stocks.

• A la fin de chaque mois, un total de chiffre d’affaire par caisse est établi, à partir des

totaux journalier

60