Intégration des Applications d Entreprises. métier flexibles. Thèse. Pour l'obtention du Doctorat en Sciences. Spécialité : Informatique.

République Algérienne Démocratique et Populaire Ministère de l Enseignement Supérieur et de la Recherche Scientifique Université Mentouri Constantine Faculté des Sciences de l Ingénieur Département d Informatique N ordre : N série : Intégration des Applications d Entreprises Une approche basée objectif pour la gestion des processus métier flexibles Thèse Pour l'obtention du Doctorat en Sciences Spécialité : Informatique Par ADLA BENTELLIS Epouse FEDJKHI Composition du Jury: M. Mahmoud Boufaïda Professeur, Université Mentouri Constantine Président M. Ammar Balla M.C. Ecole Supérieur d Informatique Alger Examinateur M. Tahar Bouhadada M.C. Université Badji Mokhtar Annaba Examinateur M. Nacereddine Zarour Professeur, Université Mentouri Constantine Examinateur Mme Zizette Boufaïda Professeur, Université de Constantine Rapporteur Soutenue le 07/ 02/ 2010

Résumé L entreprise doit actuellement répondre à des besoins de changements très fréquents. Ces changements peuvent être d ordre organisationnels, opérationnels ou autres. Les processus métier sont alors de plus en plus complexes et sujets à ces changements fréquents, d où le recours à la flexibilité afin de permettre au processus de s adapter. Afin de répondre à ce besoin de flexibilité et d adaptabilité des processus de l entreprise, ce travail propose une Gestion basée objectif des Processus Métier Flexibles GoPMF qui supporte l ensemble des étapes du cycle de vie d un processus. Cette approche propose une méthode basée objectif pour les phases d analyse et de modélisation du processus métier. La phase d analyse considère le processus métier en termes d objectifs, eux-mêmes décomposés en sous-objectifs. La phase de conception et de modélisation est basée sur l utilisation du modèle de la carte dans la définition et la représentation du processus métier. La carte est une modélisation intentionnelle, donc orientée selon les objectifs à réaliser. Dans cette phase tous les plans de déroulement connus et possibles qui peuvent mener à l objectif final du processus métier sont modélisés d une manière modulaire. Le modèle de la carte est étendu afin de permettre une adaptation du processus en pleine exécution aux exceptions et altérations qui peuvent survenir. Le processus métier ainsi construit est ultérieurement déployé tardivement et exécuté sur un Système de Gestion basée objectif des Processus Métier Flexibles SGoPMF dont nous proposons l architecture et le fonctionnement. 3

Abstract Actually companies must recover the needs for very frequent changes. These changes can be of organizational, operational, or other natures. Business process are then increasingly complex and prone to these frequent changes, that is why needs for flexibility appear in order to allow the process to adapt it self to face this changes. In order to meet this need for flexibility and adaptability of business processes of the company, this work proposes a objective based Management for the Flexible business Processes (GoPMF) which supports the whole lifecycle of a process. This approach proposes an objective based method for the analysis and modelling phases of business process. The phase of analysis considers the business process in terms of objectives, which are themselves broken up into sub-objectives. The phase of design and modeling is based on the use of the Map model for the definition and representation of the business process. The map is an intentional modeling, therefore it is directed according to objectives to realize. In this phase all the known and possible plans of unfolding which can lead to the final objective of the business process are modelled in a modular way. The map model is extended in order to allow an adaptation of the process to the exceptions and deteriorations that can occur at execution time. The so built business process is later deployed and carried out on a Management based objective of the Flexible business Processes System (SGoPMF) for which we propose an architecture and operation. 4

A Mon père, ma mère et ma belle mère, Salouh, Marouane et Maamoun Ttous ceux que j aime, Adla. 5

Remerciements La réalisation de cette thèse de doctorat est une expérience de vie qui s est nourrie de nombreuses et diverses influences. Puisse Dieu le Tout Puissant recevoir ma gratitude pour m avoir donné la force morale et physique pour l achever. Beaucoup de personnes ont participé de prés ou de loin à sa concrétisation, qu ils soient tous et toutes vivement remerciés, quel que soit, le degré de leur investissement. J insisterai néanmoins sur des personnes sans qui je n en serai pas à cette étape. D un point de vue professionnel, je remercie, en premier lieu, le professeur Zizette Boufaïda pour la patience qu elle a eu avec moi et le travail qu elle a effectué à mes côtés, emprunt de conseils pour orienter mes recherches et de critiques pertinentes pour m améliorer. Merci d avoir dirigé jusqu au bout ce travail et de m avoir poussé à dépasser mes limites. Mes remerciements vont aussi au Professeur Mahmoud Boufaida, chef de l équipe SIBC et directeur du laboratoire LIRE pour sa patience, ses conseils sincères ainsi que ses encouragements. Je tiens aussi à le remercier pour les efforts qu il a consenti pour nous procurer à tous, les meilleures conditions de travail dès qu il a pu et part de là même, nous a redonné l amour de ce travail qu est la recherche. Je le remercie encore pour avoir accepté de présider le jury. Qu il trouve ici l expression de ma profonde gratitude. Je souhaite également remercier mes examinateurs les maîtres de conférence messieurs: Amar Bella, Tahar Bouhadada et le professeur Nacereddine Zarour pour avoir accepté de lire et d évaluer mon travail et surtout pour les commentaires qu ils ont formulés afin de le perfectionner. Je tiens aussi à remercier les nombreux collègues qui ont partagé mon quotidien que ce soit au département d informatique, au laboratoire LIRE mais surtout au sein de l équipe SIBC. Je citerai, en particulier, Dr Salima Hacini qui m a beaucoup soutenu dans la finalisation de la rédaction. Je leur suis, à tous reconnaissante pour le soutien moral qu ils m ont prodigué tout le long de la réalisation de cette thèse. D un côté plus personnel, je ne saurais montrer assez de reconnaissance à chacun des membres de ma famille pour leur soutient indéfectible, leur amour inconditionnel et leur patience durant la réalisation de ce travail. Que tous ceux qui n apparaissent pas dans ces quelques lignes et qui font partie de ma vie, soient aussi remerciés : ils m aident à poursuivre mon chemin jour après jour. 6

Table des matières Résumé.. 3 Abstract. 4 Chapitre 1 : Introduction générale.. 14 1. Contexte.. 14 2. Problématique.. 14 3. Motivation et objectifs.. 16 4. Organisation de la thèse.. 19 Chapitre 2 : De l Intégration des Applications d Entreprise à la Gestion des Processus Métier. 21 1. Introduction.. 21 2. Intégration des Applications d Entreprise.. 22 2.1. Problématique. 22 2.2. Présentation. 23 2.2.1. Objectifs de l EAI.. 24 2.2.2. Fonctions de l EAI.. 25 2.3. Différents niveaux de l EAI.. 26 2.3.1. Intégration des données.. 26 2.3.2. Intégration des applications.. 26 2.3.3. Intégration des processus métier.. 26 3. Notion de processus métier.. 27 3.1. Entreprise centrée sur ses processus métier. 27 3.2. Différentes définition du processus métier. 29 3.2.1. Processus.. 29 3.2.2. Processus métier. 29 3.2.3. Processus collaboratif.. 30 3.2.4. Processus exécutable.. 31 3.3. Catégorisation des processus métier. 31 7

3.3.1. Processus à processus.. 32 3.3.2. Personne à processus.. 32 3.3.3. Personne à personne.. 32 4. Gestion des Processus Métier BPM... 33 4.1. Objectifs de la BPM.. 33 4.2. Mécanismes d une BPM.. 34 4.2.1. Orchestration.. 34 4.2.2. Chorégraphie.. 34 4.3. Equipes intervenant dans la BPM.. 34 4.3.1. Equipe méthode.. 35 4.3.2. Equipe métier. 35 4.3.3. Equipe technique.. 35 4.4. Cycle de vie d un processus métier. 36 4.4.1. Modélisation.. 36 4.4.2. Déploiement. 37 4.4.3. Exécution.. 37 4.4.4. Suivi et optimisation.. 38 4.5. Différents types de langages de modélisation d un processus métier. 38 5. Système de Gestion des Processus métier. 41 5.1. Fonctionnalités d un BPMS. 41 5.2. Architecture générale d un BPMS. 42 6. Quelques outils standards.. 45 6.1. Acteurs de la Standardisation autour des processus métier. 46 6.2.1. WfMC.. 46 6.2.2. BPMI. 46 6.2.3. Microsoft. 47 6.2. Standards pour la représentation des processus métier. 47 6.2.1. Standard pour la modélisation conceptuelle : UML, BPMN... 47 6.2.2. Standard pour l exécution : XPDL, BPML, BPEL.. 47 8

7. Autres solutions pour la BPI. 48 7.1. Workflow.. 49 7.1.1. Définition de Logiciels de WorkFlow... 49 7.1.2. Types de workflow... 49 7.2. Intégration métier à métier (B2Bi). 50 7.3. Progiciels intégrés. 50 7.4. Moteurs de règles métier. 50 7.5. Services Web. 51 8. Conclusion.. 52 Chapitre 3 : Etude de la flexibilité des Processus métier...54 1. Introduction.. 54 2. Flexibilité des processus métier. 55 3. Niveaux de flexibilité.. 56 4. Besoins en flexibilité dans les processus métier. 57 5. Taxonomies de flexibilité.. 58 5.1. Taxonomie selon l école Sulmin Nurcan.. 59 5.1.1. Flexibilité par sélection.. 59 5.1.2. Flexibilité par adaptation.. 60 5.2. Taxonomie selon l école van der Aalest 60 5.2.1. Flexibilité par conception.. 61 5.2.2. Flexibilité par déviation.. 61 5.2.3. Flexibilité par spécification incomplète.. 62 5.2.4. Flexibilité par changement. 63 5.3. Comparaison des taxonomies. 64 6. Quelques Approches de modélisation de la flexibilité des processus métier. 65 7. Conclusion.. 66 Chapitre 4 : Approche pour la Gestion basée objectif de Processus Métier Flexibles 67 9

1. Introduction.. 67 2. Approche conceptuelle.. 68 2.1. Notion d objectif dans un processus métier.. 69 2.1.1. Objectif. 69 2.1.2 Objectif d un processus métier. 69 2.1.3. Utilisation de l objectif dans la GoPMF.. 70 2.2. Le modèle de la carte. 71 2.2.1. Présentation générale.. 71 2.2.2. Métamodèle de la carte.. 71 2.2.3. Exemple de modélisation avec la carte.. 72 3. Aperçu général de la GoPMF.. 74 4. Phase d analyse.. 77 4.1. Motivation. 78 4.2 Méthode d analyse. 79 4.3. Exemple de déroulement 81 5. Modélisation Conceptuelle.. 84 5.1. Motivation. 84 5.2. Processus de modélisation. 84 5.3. Exemple de déroulement 88 5.4. Extension du modèle de la carte. 89 6. Conclusion.. 91 Chapitre 5 : Architecture du SGoPMF.. 92 1. Introduction.. 92 2. Fonctionnalités du SGoPMF.. 93 2.1. Déploiement du processus métier. 95 2.2. Exécution du processus métier. 96 3. Architecture du SGoPMF..97 3.1. Composants du SGoPMF. 98 3.1.1. Assistant de modélisation.. 99 3.1.2. Interface de configuration technique.. 100 10

3.1.3. Interface d exécution et de suivi..100 3.1.4. Référentiel des processus métier...100 3.1.5. Aiguilleur... 101 3.1.6. Générateur de code BPEL.. 102 3.1.7. Base de traces.. 102 3.1.8. Superviseur d exécution.. 102 3.2. Paramètres de diagnostic. 103 4. Mise en œuvre du SGoPMF.. 105 5. Apports de la contribution.. 105 5.1. Types de variations pris en compte par la GoPMF...106 5.2. Types de flexibilité supportés par la GoPMF. 106 5.3. Evaluation...107 6. Conclusion.. 109 Chapitre 6: Conclusion générale.. 110 1. Bilan.. 110 2. Perspectives.. 112 Références bibliographiques. 113 11

LISTE DES FIGURES Figure 2.1. Problème d interconnections des applications de l entreprise Figure 2.2. La solution EAI 20 Figure 2.3. Fonctions de l EAI 21 Figure 2.4. Quatrième Niveau de l EAI : Intégration des processus métier Figure 2.5. Catégories de processus 27 Figure 2.6. Equipes intervenant dans la définition d un processus métier Figure 2.7. Cycle de vie d un processus métier dans une BPM 30 Figure 2.8. Architecture d un BPMS 35 Figure 2.9. Composants d un service web 43 Figure 3.1. Perspectives de flexibilité 48 Figure 3.2. Points d impact de la flexibilité sur le cycle de vie du processus métier Figure 4.1. Métamodèle de la carte 61 Figure 4.2. Exemple de carte 62 Figure 4.3. Cycle de vie du processus métier dans la GoPMF 64 Figure 4.4. Formalisme de représentation d un objectif 69 Figure 4.5. Un processus hiérarchique 73 Figure 4.6. Représentation hiérarchique de la carte du processus métier Figure 4.7. Extraction des stratégies et intentions depuis le format de l objectif Figure 4.8. Modélisation du processus «Création d un nouveau catalogue voyage» Figure 4.9 : Intention et stratégie blanches 77 Figure 5.1. Diagramme de contexte dynamique du SGoPMF 82 Figure 5.2. Architecture du système SGoPMF 85 Figure 5.3. Modèle du référentiel des cartes 88 Figure 5.4. Le diagnostic dans le cycle de vie du processus métier 91 Figure 5.5. Différents états d un processus dans le SGoPMF 91 19 22 29 49 74 75 76 12

LISTE DES TABLES Table 3.1. Différents types de stimuli pour les processus métier flexibles 48 Table 3.2. Comparaison des taxonomies de flexibilité. 54 Table 4.1. liste des sections 62 Table 4.2. Liste des intentions 63 Table 4.3 Liste des stratégies 63 Table 4.4. Expression des objectifs 71 Table 4.5. Interprétation des stratégies de la carte «Création nouveau catalogue voyage» 76 Table 5.1. Evaluation de la GoPMF 94 13

Chapitre 1 : Introduction générale 1. Contexte L Intégration et la Gestion des Processus Métier, plus connues par BPI 1 et BPM 2, sont aujourd hui importantes et nécessaires pour transformer et actualiser le fonctionnement des entreprises. Ces entreprises ont besoin de solutions de bout en bout pour relier effectivement leurs applications métier internes et externes, les SIs 3 et les équipes de gestion et d opération. Cependant, beaucoup d'entreprises font le constat que la BPM traditionnelle ne suffit plus à les rendre performantes et à assurer leur pérennité. En effet, les exigences des clients et du marché sont si multiples et si évolutives et les intervenants dans la chaîne si nombreux et si variés, que l entreprise se trouve en situation de changements et remise à niveau perpétuelle. C'est la raison pour laquelle l'enjeu aujourd hui est de se munir de nouveaux moyens nécessaires pour réagir aux changements et rester à jour dans un monde en constante évolution. Les formalismes développés pour la spécification de workflow puis des processus métier, étaient et sont toujours systématiquement orientés activité. Par conséquent la définition du processus métier résultante a l avantage d être facilement transformable en code exécutable et l inconvénient d être rigide. Pour être efficace, un processus métier doit être capable de s accommoder aux changements de l environnement où il opère comme l arrivée de nouvelles lois, de nouvelles stratégies, ou plus simplement d exceptions. Les entreprises les plus compétitives doivent aujourd hui satisfaire leurs clients et rester à la tête de la compétition en répondant à un refrain récurrent: du nouveau, du meilleur, rapidement. 2. Problématique A mesure que l'on s'approche de marchés où l'instantanéité devient la règle, les entreprises semblent prendre peur de la pression et de la vitesse, peur de mettre en péril leur intégrité, d'augmenter les risques et de voir leur profitabilité s'éroder. La raison est simple. La 1 Business Process Integration 2 Business Process Management 3 Système d Information 14

plupart des entreprises n'ont pas été capables d'accélérer la mise à jour de leurs processus métier internes pour répondre à temps à la complexité actuelle de ses relations internes et celles avec les clients et les partenaires commerciaux [Ferchichi 2008]. Pour extraire une valeur ajoutée de la BPM à long terme, l organisation doit être capable de modéliser et exécuter des processus métier complexes qui évoluent en réponse à un climat métier hautement imprédictible. Ceci peut être difficile à accomplir en utilisant la BPM traditionnelle qui est plus adaptée à des processus statiques et qui se trouve incapable de modéliser des formalismes supportant le changement dans le domaine. Aussi, elle souffre d un manque de techniques de modélisation facilement compréhensibles [Russel 2007]. La flexibilité des processus métier est un nouveau paradigme qui tente d apporter cette valeur ajoutée à la gestion des processus, et ce, en permettant la construction et l exécution de processus plus réactifs et capables d anticiper les hypothèses de changements et de les couvrir en cours d exécution. De nombreux travaux de recherche se sont penchés sur la flexibilité des processus métier et l ont proposé à différents niveaux et sous différentes formes. La flexibilité du modèle qui apporte une modélisation facilement changeable [Bhat 2005], la flexibilité par sélection [Nurcan 2005] ou encore à la conception [Shonenberg 2008]. Ce dernier type de flexibilité a été investi grâce à un formalisme de modélisation qui permet de recenser toutes les exécutions possibles d un processus au moment de sa définition. Comme tous les processus métier ne sont pas bien définis, il en existe certains pour lesquels on ne peut pas connaître à l avance toutes les possibilités d exécution. Ainsi, de nombreux travaux se sont intéressés à ce problème pour apporter de la flexibilité et une capacité d adaptation à un processus en cours d exécution. Cette capacité étant introduite et apportée au processus, soit dans une phase de définition ou durant une phase d analyse et d optimisation [Edme 2004], [Anderson 2005], [Daoudi 2005], [Saidani 2006, Saidani 2009] et [Boukhebouze 2009]. Tous ces travaux ont l avantage d apporter un degré de flexibilité dans les processus métier. Cependant, ils ont l inconvénient de compliquer les modèles et de recourir à des formalismes qu un expert métier ne peut ni suivre ni maîtriser. Le principal intérêt est de pouvoir, en théorie du moins, orchestrer les processus métier selon le contexte d utilisation et les évolutions du métier. Ceux-ci doivent pouvoir être rapidement et facilement modifiables, si possible par les acteurs métier, sans avoir à repasser par la cascade de modifications généralement imposées par le cycle de développement du logiciel des informaticiens [Soulier 2005]. 15

Parmi les objectifs non complètement atteints par la BPM, Il y a, le fait qu elle vise à réduire les deux principaux verrous qui empêchent l alignement dynamique du SI sur la stratégie de l entreprise. Le premier verrou se situe dans le passage de témoin entre la modélisation et l exécution des processus. Généralement, deux cas de figures se présentent: soit les acteurs métier ne parviennent pas à s approprier les formalismes proposés par les informaticiens pour spécifier simplement les processus à automatiser, soit les outils de modélisation utilisés par les acteurs métier ne sont pas capables d exécuter les processus modélisés. Rares sont les supports d analyse de processus qui vont jusqu à l informatisation des processus ou leur exécution [Gartner 2004] et [Soulier 2005], et donc rien ne garantit que le modèle de processus soit informatisable. Ces deux cas de figure s additionnent souvent dans la réalité. Le second verrou apparaît dans la phase d optimisation après analyse des paramètres d exécution. A ce niveau le rôle de l acteur métier est complètement réduit du fait qu il ne maîtrise pas la description du processus exécuté. La problématique majeure que cette thèse tente de traiter est de participer au mouvement de recherche pour proposer un modèle de flexibilité avec en plus d une forme sélective, une forme adaptative dans une modélisation qui soit la plus proche possible des experts et analystes métier. Ces derniers ont pour principales fonctions la construction et la définition du processus métier et ils doivent être totalement impliqués dans toutes les étapes de son cycle de vie. C est là l unique manière d aligner la modélisation des processus métier de l entreprise et donc sa stratégie métier avec son SI. 3. Motivation et objectifs L objectif de ce travail est de contribuer à offrir à l entreprise un outil pour lui permettre d être plus réactive aux changements rapides et incessants du marché actuel et ce en lui permettant de définir plus aisément des processus métier flexibles facilement adaptables à l évolution socio-économique. Nous soutenons que c est la conception et la modélisation qui apportent la flexibilité et l adaptabilité au processus métier. Cette thèse présente une Gestion basée objectif pour des Processus Métier Flexibles (GoPMF), avec les concepts sous-jacents, les processus de développement en phases d analyse et de conception, la technique de déploiement, ainsi que l architecture du système qui permet de mettre en œuvre cette nouvelle approche. Elle décrit les capacités apportées par la gestion basée objectif des processus métier flexibles, en termes d adaptabilité et de flexibilité. 16

La notion de processus métier, telle que nous l appréhendons dans cette thèse, se réfère à un ensemble d'activités mises en œuvre par un ensemble de moyens dans le cadre d'une finalité définie par un objectif. C est le cas des processus rencontrés dans les entreprises industrielles de production de biens ou de services, les hôpitaux ou les établissements de santé, de formation ou de recherche. Etant donné que l une des promesses les plus importantes des technologies du BPM est la possibilité pour un analyste métier de définir des processus métier sans aucune compétence de programmation, un autre objectif de ce travail est de proposer une méthode de conception basée sur le concept stable d objectif métier pour assister les experts et analystes métier dans la définition de processus métier complexes et flexibles. Une fois défini, le processus est déployé sur le Système de Gestion basée objectif des Processus Métier Flexibles SGoPMF proposé pour supporter cette gestion. En outre, la gestion des processus métier flexibles, proposée dans cette thèse, se base sur les objectifs métier de l entreprise pour définir et modéliser les processus. Notre choix de se baser sur les objectifs métier pour construire des processus métier est un concept puissant. Le degré de flexibilité apporté ne permettra pas au processus métier de sortir du cadre des objectifs initialement définis. Lorsqu une variation apparaît entre la définition et le déroulement contextuel du processus, le modèle de flexibilité que nous proposons permet d assurer que le processus évolue en accord avec ses attentes et ses objectifs initiaux. La gestion des processus métier orientée objectifs propose aux acteurs métier des éléments constitutifs permettant de créer de nouveaux processus destinés à fournir de nouveaux produits, des groupes de produits, des services, etc. La facilité avec laquelle cette opération peut être effectuée offre aux entreprises la possibilité de réagir aux opportunités de changement ou aux menaces dès qu elles se présentent. Les processus construits peuvent être réutilisées dans des situations similaires, tant que le but visé est le même. La gestion des processus métier orientée objectifs garantit donc le passage d une spécification haut niveau vers un processus exécutable qui réagit aux fluctuations de son contexte d exécution. Cette gestion proposée, depuis la définition choisie jusqu à l exécution, est responsable de la génération de l exécution adéquate qui répond au mieux aux besoins en cours, et aux conditions prévalentes de l entreprise. Elle offre aussi un ensemble de paramètres dont l étude va permettre d améliorer la définition des processus. La GoPMF aide l entreprise à optimiser son fonctionnement en étant plus rapidement réactive aux changements et aussi à capitaliser une partie de son savoir-faire sous forme de 17

modèles de processus métier bien définis, réutilisables et partageables par les différents acteurs de la chaîne d entreprises. La contribution consiste en est une approche pour la Gestion de Processus Métier Flexibles basée sur les objectifs métier dans le but de permettre une adaptation rapide des processus aux changements et à l évolution des pratiques métier contemporaines. Cette approche se concrétise par un Système de Gestion des Processus Métier Flexibles SGoPMF. Ce dernier se base sur le modèle de la carte que nous avons étendu et prend en charge le processus depuis sa définition jusqu à son exécution et son suivi. Notre contribution intervient donc, sur quatre parties principales : Une première partie propose une méthode d analyse pour la construction de processus métier flexibles basée sur les objectifs métier de l entreprise. Cette méthode est fondée sur l identification des objectifs métier globaux, puis sur leur raffinement en sous-objectifs pour chaque processus. Elle permet aussi de découvrir toutes les alternatives de déroulement possibles. L expression des objectifs identifies est formaté dans un format textuel proposé. Une deuxième partie propose une modélisation conceptuelle décrite par un processus de génération du modèle qui représente le processus métier préalablement analysé. La modélisation se fait dans le modèle de la carte, promu par Nurcan dans [Nurcan2005a, Nurcan2005b]. C est une représentation intentionnelle du processus métier qui permet de capturer la perspective objectif du processus. Le processus proposé, guide l expert métier, l analyste ou l expert IT 1 depuis l identification des objectifs métier, jusqu à la carte qui représente toutes les possibilités d exécution du processus. Une troisième partie propose l extension du modèle de la carte par la stratégie et l intention blanches. Ces dernières représentent une stratégie ou une intention dont le contenu est ignoré en phase de construction et instancié en cours d exécution. Cette extension du modèle de la carte lui permettra de supporter outre la flexibilité par sélection une autre forme de flexibilité par adaptation qui est la flexibilité la spécification incomplète. Une quatrième partie présente l architecture du système SGoPMF qui supporte la gestion GoPMF proposée. Ce système permet de créer la carte du processus et de l exécuter d une manière flexible et ouverte aux changements qui peuvent survenir en cours d exécution. Ce système gère un référentiel des processus de l entreprise 1 Information Technology 18

qui permet de capitaliser sur le SI existant par la réutilisation des processus fonctionnels pour la création de nouveaux processus. Une étude de cas a été réalisée pour expérimenter les étapes d analyse et de conception dans une agence de voyage «Numidia Voyage» à Constantine. Elle a permis de construire les processus métier de l entreprise en accord avec les objectifs métier globaux de celle-ci. 4. Organisation de la thèse Le travail fruit de ces années est présenté dans cette thèse. Elle se présente en chapitre et est organisée comme décrit dans cette section. Après un premier chapitre qui présente une introduction générale avec le contexte, la problématique et les objectifs, cette thèse se décline en six autres chapitres. L état de l art inventorie les concepts de base manipulés et présente une étude classifiant les méthodes et les procédés suivis pour introduire la flexibilité dans la définition des processus métier. Il comprend deux chapitres. Le second chapitre mène le lecteur depuis l Intégration des Applications d Entreprise jusqu à l intégration des Processus Métier et la Gestion des Processus Métier. Il présente aussi le processus métier et le système de gestion de processus métier BPMS 1 avec ses différentes fonctionnalités et les standards existants. Tandis que le troisième chapitre présente la flexibilité des processus métier et étudie et classifie ses différentes formes. Il consiste en un état de l art des différentes taxonomies des méthodes de modélisation de processus métier flexibles existantes. Deux chapitres viennent, ensuite, dévoiler la contribution à une gestion de bout en bout de processus métier flexible depuis l analyse des objectifs métier à l exécution et au suivi du processus. Ils sont présentés en détail comme suit : Le quatrième chapitre, explique l approche de gestion basée objectif GoPMF en général et insiste sur ses concepts de base, à savoir l objectif du processus métier et le modèle de la carte. Il expose la méthode d analyse et le processus de modélisation dans le modèle de la carte présenté. L extension apportée au modèle de la carte y est aussi présentée. Elle permet au modèle de supporter une nouvelle forme de flexibilité qui vient doter le 1 Business Process Management system 19

processus métier d une capacité de s adapter aux changements qui surviennent en pleine exécution. Le cinquième chapitre, présente en détail l architecture et le fonctionnement du système SGoPMF proposé. Il décrit aussi les mécanismes de déploiement, d exécution et du suivi du processus métier flexible. Le sixième et dernier chapitre conclut, enfin, cette thèse. Il comporte une synthèse de la contribution ainsi que la suggestion de quelques perspectives. 20

Chapitre 2 : De l Intégration des Applications d Entreprise à la Gestion des Processus Métier 1. Introduction Le SI est l un des moyens dont dispose l'entreprise pour améliorer ses performances économiques. En effet, disposer d'une information plus complète, plus analytique, plus fiable, et plus rapide constitue un enjeu stratégique. Il doit être assez souple pour absorber rapidement les nouveaux besoins du marché tout en accompagnant les évolutions technologiques. Pour garder la maîtrise de leur organisation et respecter leurs objectifs économiques, les entreprises doivent faire évoluer leur SI en évitant de faire table rase du patrimoine applicatif, tout en évitant de sacrifier la cohérence de leur système informatique au moment de relier les applications entre elles. Les SIs sont en réalité hétérogènes en termes d architectures (centralisée, client-serveur, Internet, etc.), de plates-formes (Mainframe, Windows, UNIX, etc.), de Bases de Données (Oracle, DB2, Sybase, SQL Server ), d environnements de développement (C/C++, Java, ASP 1 ). Par ailleurs, ils utilisent des applications répondant à des besoins fonctionnels précis, certaines ayant fait l'objet d'un développement spécifique, et d'autres étant des solutions packagées qui ont pu nécessiter des investissements importants (ERP 2, SCM 3 ou CRM 4 ). L EAI 5 est venue offrir aux entreprises le moyen de capitaliser sur les SIs existants sans se lancer dans des opérations coûteuses de rénovation. Elle est basée sur la centralisation des échanges de données, ainsi que de la supervision des systèmes, des processus et des flux. Elle répond simplement aux problématiques d évolution, de productivité, de sécurité et de fluidité de l information. L EAI doit cependant, être abordée comme une problématique 1 Active Server Pages 2 Enterprise Resource Planning 3 Supply Chain Management 4 Customer Relationship Management 5 Enterprise Application Integration 21

moins technique que métier. Elle doit répondre à une problématique triple de fédération des sources de données, d unification d entreprise, mais surtout d alignement des processus métier mis en place. Le fonctionnement efficace des organisations impose de s appuyer sur des processus métier robustes, et adaptés à leurs activités. La définition et l exécution de ces processus nécessitent respectivement un modèle et des outils pour permettre la définition, le déploiement, l exécution et le contrôle de ces processus. La gestion des processus métier BPM consiste à gérer de bout en bout les processus de l entreprise pour en avoir une meilleure vue globale. Elle est mise en œuvre par un Système informatique de Gestion de Processus Métier BPMS qui est un outil informatique qui permet la conception, l'analyse, l'optimisation et l'automatisation des processus métier. Pour y parvenir, il sépare la logique du processus des applications qui le soutiennent, il gère les relations entre les différents intervenants, et intègre les ressources internes et externes de l'entreprise nécessaires pour le déroulement du processus. Aussi, il surveille le déroulement du processus métier pour en tirer une analyse des performances qui servira à le faire évoluer. Il est une évolution directe des solutions EAI. 2. Intégration des Applications d Entreprise L EAI Acronyme de Enterprise Application Integration, ou intégration des applications d'entreprise, est une discipline qui a pour objectif de capitaliser sur l existant de l entreprise afin d éviter de reconstruire les applications et le système d information lorsque l on désire étendre le SI de l entreprise. Son objectif primordial est de connecter les applications existantes et de les faire travailler ensemble pour répondre aux nouveaux besoins de l entreprise. L EAI apparaît à différents niveaux : données, application jusqu au processus métier de l entreprise, et elle est mise en œuvre par un ensemble de mécanismes depuis le bas niveau et les connectivités jusqu'à des niveaux plus abstraits. 2.1. Problématique Les systèmes d'information ayant atteint un certain stade de complexité sont confrontés à un problème classique : comment intégrer les applications entre elles? Lorsqu une application de vente a besoin de données présentes dans l'erp, et qu une gestion des commandes a besoin de données présentes dans les SGBDR 1, ou le CRM. Les solutions traditionnelles n abordent le problème de l intégration entre applications que par les données : transferts périodiques de fichiers, partage de base de données, réplication et transformation des données utilisées par les applications. Ainsi sont développées des 1 Système de Gestion de Bases de Données Relationnelles 22

solutions d'intégration spécifiques capables de répondre rapidement au besoin d'intégration. Les applications se parlent alors en face à face "point à point" via des interfaces qui doivent être paramétrées et maintenues une à une : c'est l'approche «spaghetti» [Giaccari 2002] représentée dans la Figure 2.1. Par rapport à la logique de développement d un nouveau système, cette approche en «spaghetti» est initialement peu coûteuse et rapide à mettre en oeuvre, et a l avantage de s appuyer sur l existant. En revanche le nombre d'intégration point à point augmente de manière exponentielle lorsque de nouveaux systèmes doivent être intégrés. L administration et surtout la maintenance deviennent alors problématiques, les risques d'erreurs augmentent, et les coûts totaux de changement s accroissent d autant. L EAI fournit une approche structurée de l'intégration qui a comme conséquence des solutions plus pérennes. Figure 2.1. Problème d interconnections des applications de l entreprise [Zhu 2004] 2.2. Présentation l EAI concerne l intégration de multiple processus, applications, et systèmes pour créer un flux continu d information. L'EAI regroupe un ensemble de solutions techniques permettant à des systèmes informatiques de natures hétérogènes d'échanger des informations selon un processus normalisé. Elle prend en charge les échanges entre des 23

applications développées indépendamment et qui n'ont jamais été conçues pour s'entendre, de telle façon qu elles fonctionnent comme une seule, comme illustré dans la Figure 2.2. La logique métier est bien traitée par l application dédiée qui la concerne, mais toutes les traitements tels que : Ordonnancement, Extraction, Transformation, Emission, Routage, Suivi, Réplication, Synchronisation, ou Remontée d alertes, sont pris en charge et ont leur interface déporté dans l EAI. Aujourd hui, les progiciels EAI ont pour vocation la collaboration des applications d une entreprise pour accomplir des objectifs métier, mais dans les faits leur utilisation est beaucoup plus technique [Ferchichi 2008] et [Manouvrier 2007]. Figure 2.2. La solution EAI [Zhu 2004] 2.2.1. Objectifs de l EAI L EAI a pour objectifs de : Intégrer le front-office et le back-office Intégrer les nouvelles applications à l existant Synchroniser les données dispersées Maîtriser l évolution du système d information Gérer les processus métier transversaux 24

2.2.2. Fonctions de l EAI Pour atteindre ses objectifs, l EAI présente différents niveaux de fonctionnement comme représenté dans la Figure 2.3 [Ferchichi 2008]. Connectivité : fournir les interfaces d accès aux applications, généralement par l utilisation de connecteurs propriétaires difficilement maintenables. Transformation : fournir les services de transformation de données permettant de créer un niveau d abstraction au dessus des applications du SI à l aide d un format pivot pour représenter les données du SI (factures, bons de commande, etc.), et des transformations pour les mapper vers les formats propriétaires attendus par les applications. XML 1 est fortement utilisé à cette fin. Routage : fournir les services permettant de localiser dynamiquement le destinataire d un message en fonction de son contexte. Gestion des processus métier : Assure le contrôle, l exécution et le cadencement des processus métier au sein d un moteur de workflow associé à une base de données. Il permet aussi de les modéliser et de les faire évoluer. La logique de gestion des flux inter-applicatifs est alors extraite des applications qui peuvent évoluer d une manière indépendante. Figure 2.3. Fonctions de l EAI [Ferchichi 2008] 1 extensible Markup Language 25

2.3. Différents niveaux de l EAI Intégrer les applications d entreprise peut se faire à différents niveaux du SI. Depuis l intégration basique des données jusqu'à la forme la plus abstraite d intégration des processus métier, en passant par une intégration des applications. 2.3.1. Intégration des données C est la forme la plus simple de l intégration. Elle apparaît au niveau des bases de données. Elle est assurée par la duplication d une partie ou de toute la base de données dans une ou plusieurs applications. L intégration est assurée par un transfert de données en utilisant des outils qui permettent aux données de migrer d une application à une autre. Le mécanisme le plus utilisé est l ETL 1. 2.3.2. Intégration des applications Elle traite l interconnexion des applications hétérogènes. Applications crées de manières indépendantes voire même incompatibles. Cette forme d intégration permet de faire communiquer tout type d application. Elle est principalement intéressante dans les entreprises dotée d un important applicatif. 2.3.3. Intégration des processus métier Connue par son acronyme BPI, c est la forme la plus complexe et sans doute la plus abstraite de l EAI. Elle traite des processus métier de l entreprise. Son objectif principal est de réutiliser les processus métier de l entreprise pour en construire de nouveaux. Les données circulant dans la nouvelle organisation sont accédées et maintenues selon une logique métier dont les règles sont correctement prises en charge dans l applicatif. Les données échangées dans cette forme d intégration sont alors, sécurisées et manipulées dans le respect des règles métier de l entreprise. 1 Extract Transform and Load 26

Figure 2.4. Quatrième Niveau de l EAI : Intégration des processus métier [Giaccari 2002] L EAI a, avec ce dernier niveau, eu l avantage d apporter une réponse au souci de réutilisation des processus de l entreprise, en leur permettant de capitaliser sur les applications existantes : l application de facturation récupère les bons de commande pour générer automatiquement les factures, etc. C est une réponse possible au souci technique d intégration. La BPI ainsi présenté doit nécessairement être soutenue par tout un processus de gestion de processus métier ou BPM qui va gérer les différentes phases depuis la construction des processus métier jusqu au déploiement et exécution. 3. Notion de processus métier Durant ces dernières années, il est de plus en plus reconnu que la notion de processus métier est un concept clé qui soutient l activité de l entreprise. Le fonctionnement efficace de celle-ci est aujourd hui basé sur une bonne définition de ses processus métier. 3.1. Entreprise centrée sur ses processus métier Quelle que soit la structure d'une organisation de fabrication, de service ou de vente, celleci est sous-tendue par ses processus métier. Simplement dit, un processus métier définit comment les employés effectuent leurs tâches quotidiennes. De nombreuses transactions commerciales mettent en jeu une succession complexe d informations et de décisions où chaque participant peut affecter la suite du déroulement du processus. Comme les 27

processus sont entremêlés, un processus mineur déficient peut par cascade induire de grandes inefficacités et donc devenir coûteux pour l'entreprise. Une entreprise qui est basée sur ses processus métier est une entreprise qui a clairement identifié et défini les procédures qui entrent en ligne dans son fonctionnement efficace et dans ses relations commerciales [Giaccari 2002]. Lorsqu une entreprise atteint cet état, elle a une base solide pour évaluer son cadre de travail et adopter des changements bénéfiques. Toute tâche qui n appartient pas ou ne supporte pas un processus métier est considérée comme redondante et peut être éliminée. Par la suite, tout processus peut être amélioré dans le but de diminuer les coûts et augmenter les performances. Dans une entreprise centrée sur ses processus métier, un employé devient l analogue d un poste dans une chaîne d assemblage. Il se préoccupe alors uniquement des parties de processus qui lui sont attribuées, car il est assigné à des rôles spécifiques et ne remplit que les tâches dévolues à ses rôles. De plus, un groupe de personnes peut prendre en charge différents rôles pour éviter tout goulot d étranglement et permettre une distribution des tâches. Les avantages d une telle approche sur le travail du personnel sont, principalement : des cycles de transactions plus courts, une plus grande facilité pour l employé de savoir ce qu il a à faire des besoins moindres de formation. Lorsqu'une une entreprise entame une démarche de recentrage sur ses processus métier, et que l'adaptation de son infrastructure IT pour supporter ces processus est complètement achevée, de nombreux bénéfices sont perçus tels que [Ferchichi 2008] : Un déroulement et une gestion en temps réel des transactions Une disponibilité des informations pour des prises de décision marketing plus rapides et mieux ciblées Une meilleure coordination des opérations anciennes et nouvellement initiées Une implication plus facile de l entreprise dans de nouvelles organisations d ordre stratégique. Une meilleure vision globale du fonctionnement de l entreprise en vu de nouvelles planifications et de plus de réactivité face aux changements. Une intégration avec des outils pour une gestion décentralisée facilitée avec des données toujours à jour. 28

3.2. Différentes définition du processus métier Plusieurs définitions du terme processus métier sont présentées dans la littérature. Il est vrai que cette notion est suffisamment générale pour être utilisée dans différents domaines scientifiques ou applicatifs. Aussi, le terme de processus métier est souvent utilisé pour désigner des notions différentes : processus exécutable, processus métier, processus collaboratif, etc. Ces différentes notions sont définies. L'étude des définitions de ces différentes notions permet d'avoir une idée plus claire de ce qui est désigné par un «processus métier» 3.2.1. Processus Un nombre de définitions existent dans la littérature pour décrire cette notion de processus. Il a été retenu : Définition 1 : Un processus est une séquence d'évènements qui englobe les actions, les personnes et l'enchaînement du travail. [Giaccari 2002]. Définition 2 : Le processus est un plan d ensemble indiquant comment les acteurs collaborent au moyen des informations gérées pour accomplir l objectif de production [Abdmoulah 2004]. L origine du concept processus provient des chaînes de fabrication. Actuellement, il s applique également aux transactions commerciales et aux procédés de gestion en général. On parle dans ces derniers cas, de processus métier. 3.2.2. Processus métier Les processus métier sont les processus représentatifs des activités de l entreprise indépendamment des moyens humains et techniques. Ces processus interfèrent de manière transversale dans le système d information et peuvent même traverser les frontières organisationnelles internes de l entreprise. Ils traversent même les limites de l entreprise pour collaborer avec les partenaires comme les fournisseurs et les distributeurs. Un processus métier est une chorégraphie d activités incluant une interaction entre participants sous la forme d échange d informations. Les participants peuvent être : des applications / services du SI des acteurs humains d autres processus métier 29

Une autre définition stipule qu un processus métier est un enchaînement d activités à exécuter pour réaliser un objectif de l entreprise. Cet enchaînement forme ce qu il est convenu d appeler le flux de contrôle du processus, c est à dire sa logique d exécution [Ferchichi 2008]. A titre d exemple, on parlera du processus de fabrication d un produit comme une suite prédéfinie d activités d usinage et d assemblage. On peut parler aussi du processus de conception d un produit comme un ensemble d activités concourant à la définition puis à la spécification technique du produit et de ses composants. Il s agit dans les deux cas de processus métier. Ould, dans [Ould 1995], distingue entre les processus noyau, les processus de management et les processus support. En effet, les processus noyaux sont liés à la fourniture du produit ou du service aux clients et représentent le coeur du métier. Par exemple, pour une société de service, ces processus sont appelés les processus de réalisation. Les processus de management sont les processus de direction qui permettent de piloter l entreprise et d en améliorer le fonctionnement. Les processus support contribuent au bon fonctionnement de tous les processus. Ceci concerne, par exemple, la gestion des collaborateurs. La gestion de chacun de ces processus a une finalité : les processus noyau améliorent la satisfaction du client ; les processus support améliorent l efficacité de l entreprise ; les processus de management améliorent la structure de l entreprise. Un processus métier peut être interne à une entreprise tel une gestion des demandes de congés, ou mettre en jeu des entreprises partenaires, on parle alors de processus collaboratifs. 3.2.3. Processus collaboratif Un processus collaboratif est un processus métier mettant en jeu des entreprises partenaires. Un processus collaboratif incluant n partenaires est composé de deux parties : une interface et n implémentations [Crusson 2003]. L interface définit la partie visible du processus, qui représente le contrat entre les partenaires. Celui-ci comporte la définition des documents métier échangés, du séquencement des activités, des rôles et responsabilités de chaque partenaire. L exécution spécifique de chaque partenaire est abstraite grâce à cette interface. Un processus collaboratif est plus communément appelé processus métier B2Bi. Il met en jeu une interface publique et des implémentations privées qui sont souvent appelées processus métier EAI. 30

3.2.4. Processus exécutable Un processus peut être rendu exécutable de différentes manières. Il peut orchestrer des applications, des services du SI, ainsi que des actions utilisateurs pour rendre une tâche automatique. Par exemple, un processus de gestion de bons de commande va recevoir les bons de commande via des messages XML, les transmettre aux personnes adéquates, se renseigner sur la disponibilité des éléments commandés dans les bases de données de l entreprise, etc. Ainsi, rendre un processus exécutable ne signifie pas nécessairement l automatiser. A titre d exemple un processus peut représenter uniquement l automatisation de la transmission d informations entre acteurs (Workflow basic 1 ), les actions étant effectuées manuellement par les utilisateurs. L avantage de la BPM est de pouvoir mélanger les concepts de workflow et d intégration. Rendre un processus exécutable peut aussi signifier introduire des points de contrôle pour permettre le contrôle de son déroulement. On parle alors de processus de BAM 2. Ainsi, les outils de la BPM peuvent être utilisés pour construire des tableaux de bord à destination des décideurs leur permettant de suivre les processus et d anticiper les erreurs. L'aspect le plus complexe à maîtriser des processus métier est qu'ils interfèrent de manière transversale dans le système d'information et traversent toutes les frontières organisationnelles internes de l'entreprise. Les processus métier traversent même les limites de l'entreprise pour collaborer avec les partenaires commerciaux comme les fournisseurs et les distributeurs. Le département IT a besoin d'intégrer les applications, les utilisateurs finaux et les partenaires dans des processus métier et favoriser leur interaction. Il a également besoin d'adapter les processus aux changements qui interviennent dans le système d'information et dans l'organisation. Il doit contrôler la modification des processus et veiller à minimiser l'impact pour garantir la consistance des flux existants. 3.3. Catégorisation des processus métier Les processus métier peuvent être classés dans un espace à deux dimensions suivant le temps nécessaire à l'exécution complète du processus et suivant la complexité de celui-ci (de simple et direct à hautement complexe). A partir de ce classement, il ressort trois catégories bien distinctes de processus métier : processus à processus, personne à processus et enfin personne à personne [Giaccari 2002]. Le passage d'une catégorie à l'autre s'accompagne d'une augmentation du temps nécessaire et d une complication du processus. 1 Automatisation du processus métier par prise en charge des échanges de messages entre les différents acteurs pour action. 2 Business Activity Monitoring 31

3.3.1. Processus à processus Dans la majorité des cas, les processus appartenant à cette catégorie sont peu complexes et ne durent que très peu de temps. Il s'agit de processus discrets qui se concentrent sur des transformations de données. Leur but est de transférer un objet métier d'une application vers une autre. Il est alors nécessaire de définir la logique métier de transformation des objets métier. Un exemple serait la supervision d'une transaction avec un ERP. 3.3.2. Personne à processus Les interactions personne à processus découlent le plus souvent d'un processus de type transactionnel tel qu une demande de validation ou la résolution d'une exception dans une tâche automatisée. Pour cette raison, ce type de processus est très répétitif avec peu de différences entre les différentes instances du processus. Ces processus sont souvent basés sur des états. Ils impliquent des interactions personnes à processus à des étapes spécifiques alors que les autres étapes sont automatisées. Un exemple serait l'acceptation d'accorder un crédit lors d'une vente. Figure 2.5. Catégories de processus [Giaccari 2002] 3.3.3. Personne à personne Les processus de type personne à personne relient les employés d'une entreprise dans un but collaboratif comme, par exemple, le processus de développement de nouveaux produits. La planification des ressources est centrée sur des processus et des connaissances explicites alors que la gestion des projets est plutôt guidée par des connaissances tacites. 32

Une autre classification est proposée par Nurcan dans [Nurcan 2008]. Elle classifie les processus métier en deux catégories, en fonction de leur nature. Les processus métier bien définis : ce sont des processus généralement répétitifs avec un besoin important en automatisation et en coordination. Les processus métier mal-définis : Ce sont des processus moins bien définis centrés sur l échange d information et de connaissance entre les participants impliqués dans le processus plutôt que sur la coordination des tâches. Ce genre de processus a besoin d être défini d une manière flexible. Dans la plupart des organisations, ces deux classes de processus coexistent. Une démarche BPM complète devrait englober toutes les catégories de processus puisque chacune d elle joue un rôle approprié et nécessaire dans l'entreprise. Actuellement, une telle solution BPM nécessite la combinaison de plusieurs des meilleurs produits BPM du marché car ceux-ci sont encore trop spécialisés. 4. Gestion des Processus Métier BPM La BPM est définie par une application informatique qui permet l intégration des données, des gens et des applications à travers un processus métier commun. C est une approche globale de la gestion des processus d entreprise. Elle couvre la modélisation, l informatisation, l exécution, l administration et l optimisation des processus d entreprise. Un modèle BPM comporte les mécanismes d identification, de description et de gestion des processus métier de l entreprise. 4.1. Objectifs de la BPM L introduction de la BPM dans une entreprise est perçue comme une remise en cause, pouvant être fondamentale, des processus opérationnels de l entreprise. Son but est d apporter des gains significatifs en termes d efficacité et de productivité. Les objectifs de la BPM sont : Automatiser les processus métier de l entreprise Eliminer où faire ce peut les délais d attentes à l intérieur de ces processus Accélérer grandement les étapes de décisions en apportant en temps réel les informations pertinentes aux bonnes personnes. 33

Un autre objectif de la BPM est de capitaliser sur les applications du système d information : le mot d ordre est la réutilisation. Contrairement aux autres initiatives architectures objets, Services Web la réutilisation est rendue effectivement possible, tant au niveau technique (connecteurs, règles techniques, transformation de données) que fonctionnel (réutilisation d un processus de facturation dans un processus de gestion de bons de commande par exemple). 4.2. Mécanismes d une BPM Les principaux mécanismes de la BPM sont fondé sur deux concepts utiles qui sont : l orchestration et la chorégraphie. 4.2.1. Orchestration Elle définit comment les activités au sein d un processus peuvent interagir les unes avec les autres, et précise la logique métier ainsi que l ordre d exécution de ces interactions. Il est possible d imaginer une orchestration comme un processus métier exécutable. Dans ce cas, la BPM nécessite un langage définissant un format d exécution portable pour les processus métier, reposant uniquement sur les ressources liées aux services Web et aux données XML. 4.2.2. Chorégraphie Elle est plus collaborative par nature, et implique que chaque participant décrive son rôle dans l interaction étudiée. Typiquement, une chorégraphie est associée aux séquences de messages faisant intervenir de multiples sources, incluant des clients, des fournisseurs et des partenaires. Il ne s agit plus d exécuter un processus métier unique par un unique participant, mais d organiser l échange de messages produits par de multiples sources. La BPM doit permettre de répondre à ces deux types de scénarios. Finalement, un processus orchestre des interactions avec des personnes et des interactions avec des systèmes de manière synchrone. 4.3. Equipes intervenant dans la BPM La définition et la modélisation des processus métier qui doivent supporter le fonctionnement d une entreprise n est pas la tâche d une seule personne mais le résultat d une coopération entre différentes équipes. Chacune d elles apporte sa vision et sa conception de ce que doit faire le processus métier [Ferchichi 2008]. Ces équipes sont principalement les équipes méthode, métier et techniques. 34

4.3.1. Equipe méthode Elle définit les recommandations pour la modélisation des processus métier. Il peut s agir d équipes internes à l entreprise ou d organismes de normalisation. L équipe méthode définit un formalisme pour la modélisation des processus métier, et peut définir des processus normalisés de manière verticale spécifique à un corps de métier, ou de manière horizontale indépendante du corps de métier de l entreprise. 4.3.2. Equipe métier Elle se Compose d analystes métier dont le rôle est de définir les processus métier de haut niveau, les cas d utilisation et les scénarios détaillés en s appuyant sur les recommandations de l équipe méthode. Ils doivent avoir la possibilité de suivre le déroulement des processus via des points de contrôle métier. 4.3.3. Equipe technique Elle traduit les processus définis en terme d applications, services et intégration de l existant, en capitalisant sur le système d information de l entreprise Figure 2.6. Equipes intervenant dans la définition d un processus métier [Crusson 2003] Ces trois équipes métier, méthode et technique doivent collaborer pour décrire les processus métier et les définir en termes d activités à réaliser et d intervenants dans cette réalisation. Cette description est alors modélisée dans un langage de modélisation adéquat. Malheureusement, il existe un décalage important qui empêche l équipe métier de mener son travail à bout. Car dès que le processus métier passe chez l équipe IT, il est représenté dans des modèles pas toujours compréhensibles par l équipe métier et là se crée un gap qui va empêcher cette dernière d intervenir dans le suivi et l optimisation des processus métier. 35

4.4. Cycle de vie d un processus métier Un processus métier est pris en charge dans une BPM depuis sa définition jusqu à son exécution et son suivi. Durant son cycle de vie, il passe par des étapes dont les plus importantes sont représentées dans la Figure 2.7. Figure 2.7. Cycle de vie d un processus métier dans une BPM [Crusson 2003] 4.4.1. Modélisation Dans une entreprise idéale, les analystes métier se chargent d ordonnancer les activités de l'entreprise composant les processus métier, car ces personnes sont les mieux placées pour appréhender et reproduire la complexité des processus. De son côté, le département technique se préoccupe uniquement de donner les moyens et les responsabilités aux analystes métier pour définir les processus [Giaccari 2002]. Représenter un processus métier est utile pour trois raisons : 1. Décrire un processus: la modélisation d un processus permet de le décrire et le documenter. Cette description peut avoir plusieurs cibles pour : a. des humains : dans ce cas la compréhension est importante ; b. des machines : dans ce cas le formalisme de modélisation est plus important. 36

2. Analyser un processus: l analyse d un processus consiste en l évaluation de ses propriétés. L amélioration des processus se base sur l analyse des processus existants pour identifier les étapes redondantes ou non optimales. Si le processus est décrit en utilisant une méthode formelle, nous pouvons vérifier les propriétés structurelles des processus telles le couplage ou la cohésion ou encore les propriétés dynamiques telles l absence d interblocage ou la viabilité du processus. 3. Exécuter un processus: à l aide d un outil capable aussi bien d offrir une interface homme/machine pour l exécution des tâches par des personnes que d intégrer et de faire appel aux applications du système d information de l entreprise, et ceci malgré leur hétérogénéité, leur disparité géographique et leur appartenance à des entités différentes. Ceci explique pourquoi dans une BPM, la modélisation d un processus métier a généralement été considérée à trois niveaux : Le niveau métier: vue métier de haut niveau du processus, définissant ses principales étapes et l impact sur l organisation de l entreprise. Ce niveau est défini par les décideurs, les analystes métier avec l aide des équipes méthodes de l entreprise. Le niveau fonctionnel: formalisation des interactions entre les participants fonctionnels du processus, où sont formalisées les règles métier conditionnant son déroulement. Ce niveau est modélisé par les analystes métier et les équipes techniques. Le niveau technique: lien entre les activités et participants modélisés dans le niveau fonctionnel, et les applications ou services du SI, ainsi que les tâches utilisateurs (Workflow). Ce niveau est réalisé par les architectes et les équipes techniques de l entreprise (IT). 4.4.2. Déploiement Cette phase supporte la création explicite de modèle exécutable et la fixation qui va indiquer clairement l applicatif qui va supporter les processus métier identifiés dans la phase de modélisation. Dans la BPM, le déploiement est pris en charge par les équipes techniques. 4.4.3. Exécution Cette phase supporte l exécution proprement dite du processus avec ses différentes activités, jusqu à sa terminaison normale ou anormale. 37

4.4.4. Suivi et optimisation Cette phase suit l exécution du processus et enregistre les paramètres de suivi. L analyse ultérieure de ces paramètres permettra l étude des différents déroulements du processus modélisé et orientera son optimisation. Les capacités de modélisation des outils, à un niveau métier et technique, devraient permettre de déployer directement les processus modélisés sans passer par une phase d implémentation. La rupture existant entre la modélisation métier et la modélisation technique entraîne généralement des décalages entre les besoins exprimés au départ et les applications effectivement réalisées. Une fois le processus déployé, la phase d interaction permet de l optimiser. Cette phase permet, au niveau technique et métier, d identifier les modifications à effectuer. Pour les réaliser, on entre alors dans une nouvelle phase de modélisation, et le cycle se répète. Comme il existe une rupture entre la modélisation fonctionnelle et la modélisation technique, il est complexe de maintenir les deux spécifications cohérentes et de les rendre évolutives. Généralement, après trois itérations, il est plus simple de re-développer l application hébergeant le processus que d en modifier l implémentation. Cette constatation d un ingénieur d une entreprise qui propose des solution BPM, résume assez bien la situation: «Suivant le poids des utilisateurs et des informaticiens dans la décision, on est confronté soit à la dégénérescence forcée d'une conception et d un modèle initiaux mettant en danger la qualité et la maintenance des solutions, soit à des situations de blocages, où pour préserver une conception, on s'interdit des modifications» [Giaccari 2002]. Pour résumer, il est nécessaire de fournir un modèle et des outils permettant aux équipes métier, méthode, et technique de collaborer pour la définition, le déploiement, l exécution et le contrôle de processus permettant de capitaliser sur les applications du système d information (intégration) et de mettre en jeu des actions utilisateurs (workflow). 4.5. Différents types de langages de modélisation d un processus métier Un modèle est par définition une représentation simplifiée consensuelle d une partie du monde réel, exprimée dans un langage de représentation dans un but défini. Ce langage peut être : formel, c est à dire ayant une syntaxe et une sémantique bien définies comme la logique du premier ordre ou le langage B; semi-formel, la plupart des formalismes sont semi-formels, exemple UML; 38

informel, description en langage naturel (texte, schéma...) [Ferchichi 2008]. Les langages de modélisation des processus d entreprise proviennent de différentes communautés scientifiques et permettent d atteindre plusieurs objectifs et de représenter sous différentes vues les processus de l entreprise. Puisque les processus métier sont généralement complexes, les concepteurs des langages de modélisation fournissent différentes vues pour les modéliser, chacune se focalise sur un aspect du processus. Curtis dans [Curtis 1992] a identifié quatre vues : la vue fonctionnelle, dynamique, informationnelle, et organisationnelle. Nurcan dans [Nurcan 2008] les a étendu par une cinquième vue qui est la vue intentionnelle. une vue fonctionnelle: cette vue représente les dépendances fonctionnelles entre les composants d un processus (activités, sous-processus, tâches). Ces dépendances résultent du fait que certains composants du processus consomment (ou nécessitent) des données (ou des ressources) produites par d autres composants (ou processus). Les notations typiques utilisées dans la vue fonctionnelle incluent des diagrammes d échange de données. une vue dynamique (comportementale): la vue dynamique fournit l ordonnancement et les paramètres d exécution d un processus. Cette vue permet de répondre à deux questions : quand certaines activités sont-elles exécutées (synchronisation, conditions préalables) et comment sont-elles exécutées (par exemple, en décrivant la logique d exécution). une vue informationnelle: cette vue inclut la description des éléments qui sont produits, consommés ou manipulés par le processus. Ces éléments incluent des données, des artefacts, des produits... une vue organisationnelle: cette vue décrit les acteurs et rôles qui exécute chaque tâche ou fonction, et où cela se passe dans l organisation (fonctionnellement et physiquement). Une vue intentionnelle : elle décrit les objectifs et stratégies que l entreprise implémente dans ses processus métier. Une approche de modélisation n offre pas nécessairement tous les concepts pour couvrir les cinq vues. Elle peut insister sur certaines vues plus que d autres en fonction des objectifs de modélisation fixés. Un certain nombre de langages de modélisation ont été développés pour décrire les processus métier avec des objectifs différents. Ces langages représentent différentes vues 39

du processus métier (dynamique, fonctionnelle, informationnelle, organisationnelle) d une façon plus ou moins formelle. Ces langages peuvent être classés comme suit : 1. Langages de modélisation traditionnels: Ces langages proviennent la plupart du temps des travaux de la mise en place des systèmes d information et l ingénierie des processus métier. Ces langages ne sont pas tous typiquement formels, mais peuvent se prêter à diverses analyses heuristiques ou informelles. Parmi ces langages, on trouve : ICAM 1 DEFinition (IDEF) avec ses différentes versions, les réseaux de Petri, Event Process Chains (EPC), Role Activity Diagrams (RAD), Resource-Event-Agent (REA), le modèle de la carte (MAP) et les plus récents Business Process Modeling Language (BPML) et Business Process Modeling Notation (BPMN). 2. Langages de modélisation des Workflow : Un Workflow peut être défini comme "l automatisation de processus métier par échange de documents, informations et tâches entre acteurs pour action"[wfmc]. Le workflow a pour objectif la coordination automatisée de tâches réalisées par des intervenants humains. Le moteur de workflow transfère des documents entre les participants aux processus en leur assignant des tâches (valider le document, effectuer une modification). En général, un langage de modélisation des Workflow permet de décrire les opérations de façon à être supportées par un système de gestion de Workflow. Ces langages sont, pour la plupart, formels et exécutables. Parmi les langages de description et d exécution de workflow, le Workflow Process Description Language (WPDL) et les formats d échange tels que Process Interchange Format (PIF) et Process Specification Language (PSL). 3. Langages d intégration de processus : L apparition des outils de B2B 2 a stimulé l intérêt pour la modélisation des processus métier dans les buts d intégrer les processus de deux partenaires ou plus. De tels langages se concentrent sur les mécanismes d intégration en termes d abstraction, des interfaces de programmation et des formats d échange de données. Cette intégration doit être réalisée indépendamment de la technologie. Dans cette catégorie de langages, on peut citer electronic business exchange Modeling Language (ebxml) et Business Process Execution Language for Web Services (BPEL4WS). 4. Langages orientés objets : En dépit que ces langages soient plus utilisés pour la modélisation des solutions logicielles, ils peuvent aussi être utilisés pour la modélisation d entreprise grâce à un certain nombre de mécanismes. Le langage orienté objet le plus utilisé est Unified Modeling Language (UML). Il permet de 1 Integrated Computer Aided Manufacturing 2 Business to Business 40

modéliser des processus métier grâce à un mécanisme d extensibilité permettant de spécialiser les diagrammes généraux. 5. Système de Gestion des Processus métier Le système de gestion des processus métier BPMS est une plateforme logicielle de production pour modéliser, informatiser, déployer, exécuter, superviser, contrôler et optimiser les processus métier de bout en bout dans une organisation. Le BPMS apporte aux analystes métier une interface pour la conception précise et facilitée des processus métier, basée sur des outils graphiques. Il offre à l équipe IT une aide pour la connexion des processus avec les applications existantes. Un BPMS aide au suivi des activités, ordonnancées par processus, en donnant la possibilité d'intervenir de manière précise lorsque se produit une erreur dans le déroulement du processus. Finalement, cet outil offre aux analystes métier des rapports précis des activités des différents processus pour permettre de les améliorer constamment. Pour atteindre ses objectifs, un BPMS se base sur la séparation de la logique métier du processus des applications qui le soutiennent. Il gère les relations entre les différents intervenants, intègre les ressources internes et externes de l entreprise nécessaires pour le déroulement du processus, et enfin surveille le déroulement du processus pour en tirer une analyse des performances qui servira à le faire évoluer. 5.1. Fonctionnalités d un BPMS Une plateforme BPMS doit fournir les fonctionnalités suivantes : Un environnement de modélisation des processus où les processus sont construits et modifiés de manière graphique et où sont définis les rôles et les acteurs qui peuvent remplir ces rôles, les règles qui définissent comment doit se dérouler les processus et les liens entre les différents processus. Un moteur d exécution des processus qui est un environnement d exécution où les processus définis dans l environnement de modélisation sont démarrés, suivis puis terminés avec une gestion des différents intervenants (applications ou humains), des délais et des exceptions. Un environnement de gestion des processus, où, pour un utilisateur donné, sont répertoriées les tâches à exécuter avec toutes les informations nécessaires à la réalisation de la partie qui lui incombe au sein du processus global. 41

Un environnement de contrôle des processus qui permet de suivre en temps réel le déroulement des différents processus métier en cours et qui permet également de fournir des analyses de performances synthétiques à l usage des managers. Une des promesses la plus importante des technologies de BPM est la possibilité pour un analyste métier de définir les processus métier sans aucune compétence de programmation. Les analystes métier conçoivent les processus par l'entremise d'une interface utilisateur facile d'utilisation qui apporte une grande assistance dans la définition de processus métier complexes. Une fois défini, le processus est déployé sur le système d'information par le département IT. Dans de nombreux cas, l'utilisation d'objets métier, présents dans une bibliothèque de l'entreprise et maintenu par le département IT, permet la définition de processus directement fonctionnel sans devoir passer par une autre personne. 5.2. Architecture générale d un BPMS Figure 2.8. Architecture d un BPMS [Giacarri 2002] L'architecture générale d'une solution BPMS est présentée dans la Figure 2.8 avec les principales fonctionnalités qui sont : la définition de processus, l exécution de processus, la gestion de processus, l analyse et la création de rapport sur les processus. Cette figure présente également certaines parties complémentaires d'une solution BPM nécessaires à 42

son fonctionnement et qui sont : la console d'administration, la couche de connexion et le dépôt de données. Les fonctionnalités de chaque composant sont : a) Modélisation des processus : propose une interface graphique qui permet la conception la plus intuitive possible de processus métier. Un module performant de création (ou modification) de processus métier doit supporter toutes les parties d'un processus (informations et personnes), les sous-processus, les processus parallèles, la création de règles et la gestion des exceptions. b) Exécution des processus : Un moteur de workflow permet le déroulement des tâches définies dans les processus. L'exécution est programmée ou déclenchée par des évènements. Comme exemples de tâches on peut citer le transfert de fichier, le lancement d'un script, la lecture de message dans une file de messages, la transformation du type de données ou une demande de confirmation d'un employé. Les tâches sont basées sur des transactions qui mettent en jeux des applications ou la livraison asynchrone à un utilisateur ou une application externe. Plusieurs possibilités sont offertes par les outils actuels : Possibilité de modifier un processus lorsqu'il est en cours d'exécution, ce qui permet à un utilisateur d effectuer rapidement des changements dans un processus lorsqu'il se produit un problème, sans avoir à arrêter le processus et le recommencer au début après modification. Possibilité d'équilibrer la charge de travail, que ce soit pour l'infrastructure informatique avec la gestion de clusters de machines et des environnements distribués mais également et surtout la gestion des employés et des rôles qu'ils représentent en tenant compte de leur disponibilités (horaires, vacances, ). Possibilité de gérer les différentes versions des processus métier et donc possibilité de pouvoir revenir en arrière sur l'évolution qu'a suivi un processus donné (pour des raisons légales ou lors d'optimisation). c) Surveillance des processus : La surveillance des processus est fondamentale. Un des buts majeurs du BPM est de permettre un contrôle permanent et une amélioration constante des processus. Les processus sont suivis en temps réel. Lorsqu'une erreur ou une exception se produit, une alerte est envoyée par l'outil de surveillance aux utilisateurs concernés (métier et IT), ce qui permet une meilleure communication et une amélioration facilitée des processus. d) Analyse et création de rapport sur les processus : Les analystes métier ont besoin d'indicateurs complets sur les différentes instances des processus qu'ils suivent (en cours 43

ou terminés). Ceci leur permet de comparer les activités basées BPM sur les processus par rapport aux attentes. Sur la basée de solides analyses, l'amélioration continue des processus métier devient possible. e) Autres composants : Un système de BPM doit également gérer les éléments suivants : Console d'administration : Une console d'administration qui permet aux administrateurs IT de gérer la partie technique du système. La console rend possible la gestion des connecteurs avec les autres applications (internes ou externes) et l'intégration avec l'infrastructure de sécurité de l'entreprise. Outils d'intégration : Une couche de connexion qui permet l'intégration des applications de l'entreprise (ERP, CRM, bases de données, etc) et des partenaires (B2Bi) dans les processus métier. Les connexions sont rendues possibles par l'adoption de protocoles et de langages standard comme le HTTP 1, le SMTP 2 et le FTP 3. Des connecteurs spécifiques et des adaptateurs sont utilisés pour certaines applications ou les services Web. Pour connecter les applications informatiques, les fournisseurs de BPMS utilisent également les API 4 s ou des services de messagerie. Interface utilisateur : Actuellement, les utilisateurs se trouvent confrontés à de multiples interfaces pour les diverses applications de l'entreprise comme un ERP et un CRM. Une solution adéquate de BPM permet d'unifier en une seule interface utilisateur tout ce dont il a besoin, au regard des rôles qu'il joue. De plus, la simplification de l'interface pour les utilisateurs réduit considérablement les coûts de formation. Généralement, c est une interface utilisateur au travers du navigateur Internet représentant un espace de travail qui ressemble à un outil de gestion des e- mails. Des processus auxquels doivent participer les différents usagers selon les différents rôles qui leur sont assignés y sont rapportés. Dépôt de données : Un dépôt électronique qui contient la définition des processus business et les états dans lesquels se trouve chaque instance existante. Tous les composants d'un système de BPM interagissent avec ce dépôt lors de la conception, la modification, l'exécution et l'analyse des processus. 1 Hyper Text Transfer Protocol 2 Simple Mail Transfer Protocol 3 File Tranfer Protocol 4 Application Programming Protocol 44

6. Quelques outils standards Ces dernières années ont vu l avènement de la standardisation dans le monde informatique. Le temps où chaque éditeur proposait une solution monolithique, totalement intégrée et propriétaire est révolu. Les capacités d intégration d un outil dans le SI de l entreprise sont le gage de son adoption. L exemple le plus parlant est celui des Web Services. En effet, les éditeurs proposant des solutions concurrentes coopèrent désormais pour la définition des spécifications permettant à leurs outils de communiquer. La BPM n échappe pas à cette règle. Un standard existe avant tout pour faciliter l interopérabilité et c est un objectif difficile à atteindre. Outre la couverture des différents cas d emploi, un standard pour l analyse des processus métier doit répondre à un certain nombre de critères propre à tout standard de modélisation : une notation intuitive et assez expressive à l usage des acteurs de l organisation et de la gestion d entreprise; un métamodèle et un vocabulaire - ensemble de concepts et de relations - rigoureusement définis pour fournir un socle robuste à l outillage des approches processus ; une déclinaison du métamodèle et de la notation pour chacun des niveaux d analyse des processus métier : chaîne de valeur, organisation, intégration informatique. Cette déclinaison doit s accompagner d un mécanisme de navigation entre les différents niveaux d analyse ; un format d échange à la fois pour les modèles de processus et pour leurs diagrammes. Il y a un véritable besoin pour l'industrie informatique de se mettre d'accord sur une approche commune pour la BPM. La standardisation de la BPM doit se faire à différents niveaux : Modélisation du processus: il est nécessaire d avoir une notation graphique commune à tous les outils de modélisation, et un format d import / export, pour que les outils de modélisation et les outils d implémentation puissent communiquer. La notation graphique doit permettre la modélisation métier, et le renseignement des informations techniques pour rendre les processus exécutables. Exécution du processus: les éléments déployés et exécutés sur les serveurs BPMS doivent être standards pour garantir une portabilité des processus réalisés sur différentes plateformes. On peut faire un rapprochement avec la standardisation 45

Java: toute application java développée sur une machine virtuelle compatible Java comme la JVM 1 Sun peut être déployée sur une autre machine virtuelle comme la JVM IBM. Cela permet aux entreprises de s affranchir d un éditeur particulier pour choisir les outils pour leur valeur ajoutée coût, robustesse, facilité de prise en main, réactivité du support, etc. Connectivité: les applications participant au processus doivent si possible fournir des connecteurs standards et indépendants de toute architecture : systèmes d exploitation, bases de données, plateforme (Java,.Net), etc. 6.1. Acteurs de la Standardisation autour des processus métier Comme sur tout sujet novateur, il existe deux types d acteurs pour la standardisation les innovateurs, et les organismes d industrialisation. 6.2.1. WfMC Fondée en 1993, la WfMC (WorkFlow Management Coalition ) a défini et standardisé un modèle de référentiel, d'interopérabilité, de connectivité, de terminologie et de définition des processus. Les spécifications clés ont été édictées en 2000. La définition des processus, XPDL, se présente comme un format d'échange entre les fournisseurs d'application BPM. La WfMC compte 200 membres et déjà quelques produits comme Vitria se proclament compatibles avec les standards de l'association. 6.2.2. BPMI Fondée en août 2000, l'association BPMI (Business Process Management initiative) à but non lucratif, cherche à pousser les entreprises de toutes tailles, dans toutes les industries à développer et à utiliser les processus métier qui traversent par définition, différentes applications informatiques, les hommes et les partenaires commerciaux de l'entreprise. Elle ne cherche pas à standardiser tout ce qui touche aux processus business, mais se concentre sur la manière de sauvegarder de manière persistante la représentation des processus. La version 1.0 du BPML 2 a été éditée en décembre 2001. BPMI est composée de 100 membres avec plus de 20 organisations qui travaillent à l'implémentation du BPML. L'initiative BPML et ebxml couvrent des aspects complémentaires de la gestion des processus business. Tandis que ebxml apporte une manière standard de décrire l'interface publique (Public Interface) du processus, le BPML arbore une manière standard de décrire la partie privée de l'implémentation (Private Implementation). 1 JaVa Machine 2 Business Process Modeling Language 46

6.2.3. Microsoft Microsoft a développé, pour BizTalk 1, le XLANG 2 pour être le concurrent du BPML. Les spécifications des deux langages ont une base théorique semblable et il est potentiellement possible de les faire converger. Par contre, le but du BPMI est de fournir une spécification plus générale et surtout moins liée aux concepts de BizTalk. C est d ailleurs ce qui a réduit l intérêt de la communauté des utilisateurs de logiciels d'automatisation pour entreprise à XLANG. 6.2. Standards pour la représentation des processus métier Un certain nombre de langages de modélisation conceptuelle ou d exécution de processus métier ont été adoptés, par la communauté des constructeurs de processus métier, comme des standards. Chacun de ces langages est promu par l un des groupe présentés dans la section précédente et est utilisé par un certain nombre de produits BPM existant sur le marché. Parmi ces produit, on cite sans être exhaustive : UML et BPMN comme langages de modélisation et XPDL, BPML et BPEL comme langage d exécution. 6.2.1. Standard pour la modélisation conceptuelle : UML, BPMN Proposé par l OMG (Object Management Group) pour la conception orientée objet, UML dispose d un modèle d activité qui présente certaines fonctionnalités pour la modélisation des processus. Il présente l avantage d offrir à la fois un métamodèle, une notation et un format d échange pour les modèles avec XMI 3. Toutefois, sa portée reste limitée à la conception objet. La nouvelle version UML 2.0 offre une bonne base pour l analyse des processus. Cependant, par son caractère technique, il s adresse encore essentiellement à des concepteurs de processus automatisés. Le langage BPMN modélise des processus business qui seront décrit en BPML. Alors que le BPML est utilisé pour transporter la sémantique du processus entre plusieurs ordinateurs et applications. Le BPMN permet la communication entre les personnes par une version graphique du processus. 6.2.2. Standard pour l exécution : XPDL 4, BPML, BPEL 5 Ces langages de modélisation de processus sont des langages dédiés à l exécution de processus. Ils ne sont généralement pas utilisés directement dans les phases de conception. 1 Serveur de gestion des processus metier de Microsoft 2 XML Business Process LANGuage 3 extensible Markup Interchange 4 XML Processing Description Language 5 Business Process Execution Language 47

Exprimés dans une syntaxe XML, ils disposent ainsi d un format d échange natif. Par définition, ils n ont pas vocation de couvrir tous les niveaux d analyse des chaînes de valeur de l organisation. Le premier standard d exécution XPDL est apparu sous l égide de la WFMC et a ensuite été publié en 2002 dans une version XML. Le groupe BPMI a lancé un langage concurrent BPML. Ceci a relancé les travaux sur les langages d exécution de processus et a apporté de nombreuses contributions à son successeur, le langage BPEL. Ce dernier a été lancé à l initiative de Microsoft et IBM en réponse à l initiative de BPMI. Depuis ce langage a reçu le soutien de la plupart des acteurs du marché, y compris de BPMI. BPEL est devenu le standard de facto. Il vient en complément de la spécification sur les services webs. De nos jours le couple de langage modélisation, exécution qui est le plus promu et le plus cité pour faire office de standard est le couple BPMN, BPEL pour lequel on promet un avenir de standards de consensus. Les entreprises ont intérêt à implémenter les services Web en même temps que les technologies de BPM, afin d exploiter leurs avantages dans l'apport de nouvelles ressources d'applications et d'information. A mesure que les entreprises vont codifier et modifier leurs processus internes et ceux partagés avec leurs partenaires, les services Web vont s'imposer pour intégrer ces processus, tout autant au niveau du contenu que celui des applications, en apportant des conditions de travail optimales. Les systèmes de BPMS sont de bons candidats pour interagir avec les services Web que l'on voit émerger actuellement. Les solutions BPM qui supportent les standards à la base des services web vont faciliter l'intégration des processus avec le contenu et les applications de sites à distance ou de partenaires. Les BPMS pourront servir de chef d'orchestre de grand processus business basé sur le Web, quel que soit le système d'information sous-jacent. 7. Autres solutions pour la BPI L intégration des applications d entreprise à travers une gestion de processus métier n est pas la seule solution pour la gestion des processus métier. D autres solutions ont existé avant elle, telles que le workflow et ont existé après elle, telle que le B2Bi avec des objectifs différents. La BPM a été adoptée pour son caractère global apporté par le fait qu elle a intégré certaines des solutions concurrentes comme solutions complémentaires. 48

Parmi ces solutions on s intéresse au Workflow, à la B2Bi, aux logiciels intégrés, au moteur de règles et finalement aux services web. 7.1. Workflow Le workflow ou flux de travail traite de la gestion informatique de l'ensemble des tâches à accomplir et des différents acteurs impliqués dans la réalisation d'un processus métier. Il représente l automatisation de processus métier par échange de documents, informations et tâches entre acteurs pour action. Le workflow a pour objectif la coordination automatisée de tâches réalisées par des intervenants humains. Le moteur de workflow transfère des documents entre les participants d un processus en leur assignant des tâches (valider le document, effectuer une modification, etc.). Cette approche pragmatique a l avantage de l efficacité ; les concepts sont clairs et les outils relativement aisés à mettre en place. 7.1.1. Définition de Logiciels de WorkFlow Ils représentent l ensemble des logiciels proactifs permettant de gérer les processus métier, de coordonner les charges et les ressources, et de superviser le déroulement des tâches. Ils ont pour objectifs de: Gérer et archiver les instances de processus Gérer les données manipulées au sein d'une instance de processus Orchestrer les différents modules qui composent une instance de workflow (briques métier) 7.1.2. Types de workflow Différentes classifications ont été proposée pour les applications workflow. La plus communément utilisée a été définie dans [McCready 1992] et propose trois classes en fonction du type de processus métier supporté. Une nouvelle classe (collaboratif) a par la suite été ajoutée dans [Alonso 1997], ramenant ainsi la classification à quatre classes. Workflow administratif : concerne les processus métier répétitifs et prédictibles avec une simple coordination des tâches et qui ne concerne pas le métier de l entreprise. Ils peuvent être automatisés par un workflow orientés messages. Workflow production : concerne les processus métier répétitifs et prédictibles qui implémentent le noyau du métier de l entreprise et comprennent dans leurs 49

activités, différents accès au Sis de l entreprise. C est dans cette classe que peuvent être classifiés la plupart des systèmes workflow du marché. Workflow collaboratif : concerne les processus métier comprenant des activités itératives sur la même étape jusqu à arriver à une forme d agrément. Les workflows classiques, basés activité dans la modélisation du processus, ne peuvent pas supporter cette classe puisque la séquence d activités n est connu qu après coordination. Cette dernière étant généralement faite par des participants humains. Workflow ad hoc : concerne les processus métier ne possédant aucune structure prédéfinie. Le support workflow est, dans ce cas, limité à fournir la communication, à router les données entre les participants, et gérer les accès et états. Ce genre de workflow semble être dédié à la gestion des exceptions. 7.2. Intégration métier à métier (B2Bi) Les outils de B2Bi visent à définir les processus de collaboration entre entreprises partenaires, partant du principe que les processus intra-entreprise, donc d EAI, n ont pas les mêmes contraintes que les processus extra-entreprise. Il en résulte, que ces outils fournissent surtout un moyen technique pour le contrôle d une collaboration avec un partenaire. Ce contrôle assure des fonctionnalités telles que : la gestion de la sécurité des échanges, la fiabilité du transport (le bon de commande a bien été envoyé, et reçu par le partenaire), le support des protocoles EDI 1. 7.3. Progiciels intégrés Les progiciels intégrés sont une solution «clé en main» : des progiciels tels que ceux de SAP 2 ou Commerce One 3 fournissent une solution complète d eprocurement 4, de comptabilité, de facturation, etc. Ils obligent les entreprises à adapter leurs fonctionnements à ces progiciels, parce qu ils n ont pas la possibilité de s adapter eux au fonctionnement de l entreprise. Ceci fait que toute extension ou changement est difficile à prendre en compte par ces progiciels. 7.4. Moteurs de règles métier Les moteurs de règles métier (Business Rules Engine) permettent de modéliser les règles métier de l entreprise. A titre d exemple, un bon de commande reçu de la part d un client particulier doit être traité par la division du service commercial concernée. Ces outils sont 1 Electronic Data Interchange 2 Systems, Applications and Products for data processing fournisseur de progiciel de gestion integer. 3 Fabricant de logiciels, il a été à l origine de XML 4 Approvisionnement électronique 50

indispensables pour automatiser les processus métier de l entreprise. Ils permettent en particulier de formaliser et automatiser les prises de décisions sur la branche du processus à choisir, en fonction du contexte du processus. Néanmoins, ces solutions doivent obligatoirement être couplées à d autres outils, permettant de gérer les processus tels que BPMS ou Système workflow. 7.5. Services Web Il y a actuellement autant de définition des services Web que de sociétés qui en proposent. La définition communément admise définit un service Web comme un objet XML avec du contenu, du code applicatif, de la logique de traitement et toute combinaison des trois [Giacarri 2002] et [Crusson 2003]. Cet objet est accessible à travers le réseau par le protocole TCP/IP 1 en utilisant les standards SOAP 2 pour l intégration, WSDL 3 pour l auto description et UDDI 4 pour l enregistrement et la découverte dans l'arborescence publique et privée. La Figure 2.9 présente les différents standards des services web. Pratiquement, les services Web offrent une bibliothèque d'objets de travail ainsi que les mécanismes de distribution de ces objets. Une vision plus abstraite définit un service Web par une activité (une capacité métier) de l'entreprise qui peut être partagée, combinée, et utilisée par les ressources informatiques hétérogènes de l'entreprise ou de ses partenaires. Le bénéficiaire d'un service Web peut être un humain ou une machine. Un exemple simple de service web est un processus (ou étape d'un processus complexe) comme l'approbation d'un ordre d'achat ou le remplissage d'une heure de travail. Figure 2.9. Composants d un service web [Giaccari 2002] 1 Transmission Control Protocol / Internet Protocol: protocols de communication de Internet 2 Simple Object Access Protocol 3 Web Services Description Language 4 Universal Description Discovery and Integration 51