Les processus métiers : concepts, modèles et systèmes Organisation du cours Concepts et notations Modélisation des processus Systèmes de gestion de processus Processus transactionnels Découverte de processus Intelligence des processus processus interentreprises processus sur le Web Validation des modèles de processus Dimension managériales des processus Conclusion 1
Chapitre 3 : Modélisation des processus Dimensions de la modélisation 2
Contenu (1) De fait, il existe assez peu d approches de modélisation spécifiques aux processus métiers opérationnelles couvrant toutes ces dimensions (voir cependant OSSAD http://dumas.univtln.fr/ossad/appel%20vol%201.htm ) Aussi, le chapitre présente plus des notations formelles qu une méthodologie d analyse/conception Mais, le fait de modéliser en se demandant si le processus est bien structuré, bien parenthèse, à choix libre supporte une discipline de conception efficace Contenu (2) Le chapitre introduit la notion de processus bien structuré et bien parenthésé Il présente l essentiel des concepts des modèles Réseaux de Petri, UML et EPC pour modéliser des processus bien structurés 3
Notion de processus bien structuré (1) Un seul point d entrée et un seul point de sortie Toute activité est sur un chemin allant du point d entrée au point de sortie Les connecteurs de flot de contrôle sont bien parenthésés (AND-Split-AND-Join; XOR-Split, XOR-Join; OR-Split-Jonction ) Notion de processus bien structuré (2) 4
Notion de processus bien structuré (3) Dans le cas (a), une parenthèse OR-Split est fermée par une parenthèse AND-Join, il y a risque de blocage : si une seule branche est activée, la porte AND-JOIN n est jamais franchie Le graphe de processus contient une «impasse» Dans le cas (b), une parenthèse AND-Split est fermée par une parenthèse OR-Split. quel est l interprétation de cet OR-Split? Le graphe de processus «manque de synchonisation» Processus avec blocage (impasse) [SAD 00] 5
Processus avec manque de synchonisation [SAD 00] Processus corrects [SAD 00] 6
Tout processus peut-il être transformé un processus bien structuré? (Presque) oui Certains ne peuvent être transformés qu en dupliquant des activités Il existe des cas non transformables mais très particuliers Duplication d une activité 7
A structurer!? Modéliser avec des Réseaux de Pétri (RdP) 8
Pourquoi les RdP? Fondements mathématiques techniques d analyse Notations graphiques plus facilement accessible à des non spécialistes Similarités avec les langages et outils BPM choisi pour développer une sémantique formelle de ces langages (EPC, diagrammes d activité UML, WS-BPEL) Plus implicite et compacte que les modèles à transitions RdP Principes de modélisation 9
Définition On appelle réseau de Petri places/transition tout triplet N = (P,T,W) où : P est un ensemble fini de places : P = {p1,, pn} T est un ensemble fini de transitions, disjoint de P : T = {t1,, tm} W : PxT U TxP N (entiers naturels) est la fonction de valuation des arcs Graphiquement, par convention, les arcs de valuation nulle ne sont pas représentés; les valuations égales à 1 sont omises (valeur par défaut); dans les autres cas, les valuations sont explicites. Symboles et principes de base 10
Exemple «Service» Modélisation d un service (imprimante, coiffeur) Service Demande Service fait Demande Service fait En_cours Libre Demande Service fait En_cours Exemple «Service» (P,T,W) P = {Demande, Libre, En_cours, Service fait} T = {Début_service, Fin _service} W = {{Demande, Début_service, 1}, {Libre, Début_service, 1}, {Début_service, En_cours, 1}, {En_cours, Fin_service, 1}, {Fin_service, Libre, 1}, {Fin_service, Services fait, 1}} 11
Place d entrée et place de sortie Une place p est une place d entrée d une transition t si (p,t) appartient à W. l ensemble t = {(p,t,?) de W} définit les places d entrée de t Une place p est une place de sortie d une transition t si (t,p,?) appartient à W L ensemble t = {(t,p,?) de W} définit les places de sortie de t Exemple «Service» ( t, t ) Début_service = {Demande, Libre} Fin _service = { En_cours} Début_service = {En_cours} Fin_service = {Service fait, Libre} 12
Marquage, transition tirable, franchissement d une transition On appelle marquage d un RdP (P,T,W) toute fonction m : P N (entiers naturels). Dans un RdP (P,T,W), une transition t est tirable dans un marquage M si et seulement si, pour toute place p de t, m(p) > w(p,t) Le franchissement d un transition t conduit à un nouveau marquage tel que : m (p) = m(p) w(p,t) + w(t,p) Exemple «Service» (Marquage) Marquage initial : {m(demande) =3, m(libre) =1, m(en_cours) = 0, M(Service fait) = 0} 1 er pas : m (Demande) = m(demande) w(demande, Début_service) + w(début_service, Demande) = 3-1 + 0 = 2 m (Libre) = m(libre) w(libre, Début_service) + w(début_service, Libre) = 1-1 + 0 = 0 m (En_cours) = m(en_cours) w(en_cours, Début_service) + w(début_service, En_cours) = 0-0 + 1 = 1 13
Modéliser des processus avec des réseaux de Petri. Rôle des jetons Un jeton peut représenter : Un objet (un produite, une personne ) Une information (message, signal ) Un indicateur d état (d un artefact, d une activité, d un processus ) Un indicateur de condition (la présence d un jeton dit si une condition ou une partie de condition est remplie, y compris pour la mise en œuvre de patron de flot de contrôle ) 14
Rôle des places Une place peut représenter : un media de communication un buffer (une queue de messages ) un emplacement géographique un état, un événement Le rôle des transitions Une transition représente : une activité en général Un événement : le début, la fin d une activité La transformation d un objet Le transport d un objet Les alineas 1 et 2 présentent-il deux approches de modélisation différentes? (cf. Exemple «Service») 15
Processus vs. Réseau de Pétri Les activités sont représentées par des transitions, ou des sous RdP Les connecteurs de flots de contrôle sont représentés par des (sous)-rdp Les cas sont représentés par des jetons Représentation des activités : Une activité comme une transition Une activité comme un RdP Demande Service Service fait Demande Service fait En_cours 16
Exemple Limites des RdP classiques Passage à l échelle Pouvoir d expression limité Pas de modélisation du temps RdP hierarchisés RdP colorés RdP temporisés 17
Les RdP hiérarchisés permettent de Plier/déplier un modèle De représenter le raffinement d une activité composée en sous-activité 18
Les RdP colorés Associer hôtel et vol avec un même numéro de dossier permettent de De qualifier les jetons avec des attributs De distinguer les cas Sur lesquelles peuvent porter des conditions de franchissement 19
Les RdP temporisés permettent de D associer des timestamps aux jetons (date à partir de laquelle un jeton peut être consommé) D associer des temps de franchissement aux transitions (d exécution aux activités) D ajouter des délais aux activités Pour faire de la simulation temporelle 20
RdP Modélisation du flot de contrôle Constructions classiques des RdP Causalité : la transition y ne peut être franchie qu après la transition x x y Concurrence : y et z sont concurrente x y z 21
Constructions classiques des RdP Synchronisation : y x Exclusion mutuelle z y y x z z Patrons de base avec des RdP 22
Patrons avancés avec des RdP RdP Modélisation du flot de données 23
Représentation du flot de données Le flot de données est porté par : les couleurs associées aux jetons le flot des jetons dans le RdP et les conditions associées aux transitions Remarquons que plus les jetons portent d information, et plus les RdP ont tendance à perdre leur lisibilité (graphique) RdP Modélisation des ressources 24
Les rôles comme des places, les ressources comme des jetons On ajoute des places spécifiques pour définir les rôles Les ressources sont les jetons dans ces places spécifiques Les transitions qui représentent les activités consomment ces ressources On peut associer des places/ressources à plusieurs transitions L ajout de ces places complexifie le RdP qui devient moins lisible et plus difficile à valider Modélisation de ressources avec des RdP 25
Validation d un modèle de processus RdP RdP Propriétés classiques 26
RdP borné L absence d une borne limite pour le nombre de jetons dans une place est généralement source de problème Un RdP est k-borné si, depuis le marquage initial, il ne peut atteindre aucun marquage dans lequel il y a plus de k jetons; dans le cas contraire, il est non borné Un RdP borné a toujours un nombre de marquages fini SI K=1, le RdP est dit sûr. RdP qui termine Un RdP termine s il atteint toujours un marquage terminal duquel aucune transition ne peut être tirée Un RdP avec graphe d atteignabilité fini et acyclique termine 27
RdP sans deadlock Un RdP est sans deadlock si et seulement si au moins une transition peut être tirée dans n importe quel état RdP vivace Une transition est morte si et seulement si elle n est pas tirée dans aucun marquage possible Une transition est vivante si, depuis n importe quel marquage, on peut atteindre un marquage dans lequel la transition est tirable Un RdP est vivace si et seulement si toutes ses transitions sont vivantes Vivacité et terminaison s excluent. 28
(RdP réversible) Un marquage a la propriété home-marking s il peut toujours être à nouveau atteint Un RdP est réversible si son état initial est un home-marking RdP Validation 29
WF-Net Un WF-Net est un RdP qui a les propriétés suivantes : Une seule place d entrée et une seule place de sortie Chaque place et chaque transition se trouve sur un chemin allant de la place initiale à la place finale La consommation d un jeton dans la place initiale produit un et un seul jeton dans la place finale Processus sain Un processus sain est un processus qui ne contient pas d activité inutile et où chaque cas se termine complètement sans laisser de référence à lui-même La vérification brute de cette propriété conduit à une explosion combinatoire Mais un WF-net vivace (sans blocage et sans boucle) et borné est sain On sait vérifier ces propriétés 30
Blocage, Boucle, Borne Un RdP est sans blocage s il n y a pas de cas où l activité finale ne peut pas s exécuter et où le processus ne peut plus progresser Un RdP est sans boucle si tous les cas terminent Un RdP est borné s il n existe pas un cas où le nombre de jeton croit indéfiniment Blocage, Boucle, Borne 31
Processus-RdP bien structuré Bonnes pratiques qui éliminent par construction bien des risques Bonnes et mauvaises structurations de réseaux avec des RdP (1) 32
Bonnes et mauvaises structurations de réseaux avec des RdP (2) (a) combine un AND_Split et un AND-join, (b) combine un XOR-Split et un XOR-JOIN (a) et (b) sont bien structurés (c) et (d) sont mal structurés WF-Net Un WF-Net est un RdP qui a les propriétés suivantes : Une seule place d entrée et une seule place de sortie Chaque place et chaque transition se trouve sur un chemin allant de la place initiale à la place finale La consommation d un jeton dans la place initiale produit un et un seul jeton dans la place finale 33
WF-net à libre choix Un WF-net est en libre choix si toutes les transitions en concurrence dépendent des mêmes places (a) n est pas à libre choix, (b) l est Well-structured WF-Net Un WF-Net bien structuré est un WF-Net bien parenthésé 34
RdP sains par construction On connaît un ensemble de RdP de base sains Leur composition produit un RdP sain Application : ayant un RdP, peut-on le reconstruire en itérant la composition de RdP de base sains RdP de base sains 35
36
Et celui-ci? 37
Analyse quantitative Analyse par simulation évaluation de propriétés recherchées par visualisation de cas évaluation de traces d exécution Réseaux temporisés pour l évaluation de performance Réseaux stochastiques pour l évaluation de probabilités de franchissement d une transition Exemple (2) 38
Exemple (2) Dans la variante (a), plusieurs activités de réservation d hôtels et de vols s exécutent en parallèle, dans la variante (b) une seule activité pour toutes les réservations L analyse peut permettre d évaluer quelle est la stratégie la plus efficace, éventuellement en fonction de circonstances Conclusion RdP Certainement le fondement principal pour la gestion des flots de contrôle Quelques outils utiles, mais la validation automatique est loin d être atteinte en particulier pour les réseaux colorés Les RdP sont souvent embarqués de façon cachée dans bons nombres d outils associés aux SGWf. 39
Modéliser avec Unified Modelling Language (UML) UML : Principes de modélisation Ce sont les diagrammes d activité qui sont au cœur de la modélisation des processus métiers, en particulier du flot de contrôle Les diagrammes de classes et d objets sont indispensables à la modélisation des flots de données Les diagrammes de séquence permettent ici d étudier les flots de contrôle alternatifs Mais tous les diagrammes peuvent être utilisés de façon classique, en particulier dans une démarche d analyse/conception globale d un logiciel plus large que la modélisation d un processus 40
UML Modélisation du flot de contrôle. Les diagrammes d activité Discordance du vocabulaire «Processus» «Activité» en UML «Activité» «Action» en UML 41
UML : concepts de base (1) UML : concepts de base (2) 42
Modélisation du flot de contrôle Patrons avancés (1) 43
Patrons avancés (2) UML Modélisation du flot de données 44
Diagramme de classes Classique Indispensable à la modélisation du flot de données Utilisé pour la méta-modélisation (modélisation des modèles de processus) Et la modélisation du modèle organisationnel Diagrammes de classes (Exemple) 45
Diagramme de séquence Les différents scénarios permettent de découvrir les différentes alternatives dans le flot de contrôle Diagrammes de séquence (1) 46
Diagrammes de séquence (2) Flots d objets (1) 47
Flots d objets (2) UML Modélisation du modèle organisationnel 48
Méta-modèle organisationnel Instance du modèle organisationnel 49
Swimlanes Différentes organisations 50
Validation Le processus est-il bien structuré? Est-il sain (sans blocage, borné)? Peu outillé, mais se poser néanmoins la question et utiliser des principes de modélisation qui limite les risques en s inspirant des RdP Processus UML bien structuré (2) 51
Conclusion UML Moins adapté et outillé que les RdP Mais les diagrammes d activités empruntent aux RdP Permettent une bonne intégration à l analyse et à la conception avec les autres aspects d un logiciel, en particulier dans le contexte de développement orienté objet Modéliser avec Event Process Chain (EPC) 52
Principes de modélisation 4 perspectives : Organisationnelle Donnée Activité Contrôle 3 niveaux d abstraction Définition des besoins Conception Implantation Perspectives et niveaux d abstractions 53
Eléments de notation Flot de données et flot organisationnel 54
Éléments du flot de contrôle Un modèle EPC est un graphe ordonné d événements et d activités alternés et connectés par des connecteurs de flot de contrôle Connecteur ET (1) 55
Connecteur ET (2) Connecteur OU Exclusif (1) 56
Connecteur OU Exclusif (2) Connecteur OU (1) 57
Connecteur OU (1) Chemin de processus 58
Flot de données et flot organisationnel Conclusion EPC Très utilisé dans le monde ERP, SAP Fondement dans les RdP 59
Exemple récap. (1) Une compagnie d assurance souhaite modéliser le processus défini comme suit : A l arrivée d une déclaration de sinistre, elle fait en parallèle deux vérifications dans deux départements différents : la police d assurance couvre t-elle le sinistre? La déclaration permet-elle de décider du remboursement? Si la police d assurance couvre le sinistre (police acceptée) et que la déclaration est acceptée, l assurance paye. Dans le cas où soit la police d assurance n est pas valide, soit la déclaration n est pas acceptée, un courrier est envoyé à l adhérent. Exemple récap. (2) En donner un modèle BPMN! 60
Exemple récap. (3) En donner un modèle BPMN! Exemple récap. (4) Un concepteur a fait le réseau de Pétri suivant : commentaires! 61
Autre solution Exemple récap. (5) Conclusion (1) Le chapitre présente plus des notations formelles qu une méthodologie d analyse/conception comme introduite dans Cependant, le fait de modéliser en se demandant si le processus est bien structuré, bien parenthèse, à choix libre supporte une discipline de conception efficace De fait, il existe assez peu d approches de modélisation spécifiques aux processus métiers opérationnelles (voir cependant OSSAD http://dumas.univ-tln.fr/ossad/appel%20vol%201.htm ) 62
Conclusion (2) RdP est probablement le modèle formel le mieux outillé UML est utilisé en phase d analyse et de conception lorsque le processus est embarqué dans un contexte logiciel plus large EPC est très utilisé en pratique dans le contexte ERP, mais les outils EPC «emballent» les concepts des RdP Références [AAL 00] VAN DER AALST W. M. P., TER HOFSTEDE A. H. M., «Verification of Workflow Task Structures : A Petri-net-baset Approach», Inf. Syst., vol. 25, n 1, p. 43-69, 2000. [AAL 02] VAN DER AALST W. M. P., VAN HEE K. M., Workflow Management : Models, Methods, and Systems, MIT Press, Cambridge, 2002. [AAL 11] VAN DER AALST W. M. P., STAHL C. Modelling Business Processes : A Petri Net- Oriented Aproach, MIT Press, Cambridge, 2011. [DON 05] VAN DONGEN B. F., VAN DER AALST W. M. P., VERBEEK H. M. W., «Verification of EPCs : Using Reduction Rules and Petri Nets», CAiSE, p. 372-386, 2005. [DUM 12a] DUMAS M. and al. Understanding Business Process Models: The Costs and Benefits of Structuredness, CAISE 2012 [DUM 90a] DUMAS P., CHARBONNEL G., La méthode OSSAD : pour maîtriser les technologies de l information - Tome I : Principes, Editions d Organisation, Paris, 1990. [DUM 90b] DUMAS P., CHARBONNEL G., La méthode OSSAD : pour maîtriser les technologies de l information - Tome II : Guide pratique, Editions d Organisation, Paris, 1990. [EPC 08] EPC, «Event-driven Process Chain», en.wikipedia.org/wiki/event-driven_process- Chains, 2008. [FAW 97] FAWLER M., Uml distilled. Applying the standard object modeling language, Addison- Wesley, Reading, 1997. [FAW 05] FAWLER M., Uml distilled. A brief guide to the standard object modeling language, Addison-Wesley, Reading, 2005. [FOS 05] FOSTER H., UCHITEL S., MAGEE J., KRAMER J., HU M., «Using a Rigorous Approach for Engineering Web Service Compositions : A Case Study», IEEE Service Computing Conference, p. 217-224, 2005. [FU 04] FU X., BULTAN T., SU J., «Analysis of interacting BPEL web services», Wold Wide Web conference, p. 621-630, 2004. [GEF 08] GEFFROY J. C., Introduction aux réseaux de Petri, cyranac.free.fr/pub/cours/cnammoca/ch10.pdf, 2008. 63
Références [LIA 07] LIANG-JIE ZHANG JIA ZHANG H. C., Services Computing, Springer, Berlin, 2007. [MAR 95] MARSAN M. A., BALBO G., DONATELLI S., FRANCESCHINIS G., Modelling with Generalized Stochastic Petri Nets, Springer-Verlag, Heidelberg, 1995. [OBE 96] OBERWEIS A., SANDER P., «Information system behavior specification by high level Petri nets», ACM Transactions on Information Systems, vol. 14, n 4, p. 380-420, ACM, 1996. [OMG 06] OMG, «Business Process Definition Metamodel», www.omg.org/docs/bei/03-01- 06.pdf, 2006. [PAP 07] PAPAZOGLOU M. P., VAN DEN HEUVEL W. J., «Business process development life cycle methodology», Communication of ACM, vol. 50, n 10, p. 79-85, 2007. [PET 08] PETRI, «Réseaux de Petri», fr.wikipedia.org/wiki/r%c3%a9seau_de_petri, 2008. [RUM 00] RUMBAUGH J., BOOCH G., JACOBSON I., Le guide de l utilisateur UML, Eyrolles, Paris, 2000. [SAD 00] SADIQ W., ORLOWSKA M. E., «Analysing Process Models Using Graph ReductionTechniques», Information Systems, vol. 25-2, p. 117-134, 2000. [SAL 04] SALAÜN G., BORDEAUX L., SCHAERF M., «Describing and Reasoning on Web Services using Process Algebra», International conference on Web Services, 2004. [SAP 08a] SAP, «SAP NetWeaver», en.wikipedia.org/wiki/netweaver, 2008. [SAP 08b] SAP, «SAP R/3», en.wikipedia.org/wiki/sap_r/3, 2008. [SCH 98] SCHEER A. W., Business Process Engineering : Reference Models for Industrial Enterprises, Springer-Verlag, Heidelberg, 1998. [TUR 07] TURNER K. J., «Representing and analysing composed web services using Cress», J. Network and Computer Applications, vol. 30, n 2, p. 541-562, 2007 64