Guider le choix d un formalisme de modélisation de processus : Démarche multicritère basée sur les patrons

Transcription

1 Guider le choix d un formalisme de modélisation de processus : Démarche multicritère basée sur les patrons Bessai Kahina * Selmin Nurcan *,** *. Centre de Recherche en Informatique, Université Paris1-Panthéon- Sorbonne 90, rue de Tolbiac Paris cedex 13 France, **. IAE de Paris, 21 rue Broca Paris France kahina.bessai@malix.univ-paris1.fr, Selmin.Nurcan@univ-paris1.fr RÉSUMÉ. Nous présentons, dans ce papier, un modèle multicritère d aide à la décision pour la comparaison d un ensemble de formalismes de modélisation de workflow. Cette comparaison s effectue selon la nature du processus à modéliser, en se basant sur la collection des pattern de workflow comme critères de comparaison. Plus précisément, notre objectif est l utilisation des méthodes ELECTRE (Elimination et Choix Traduisant le REalité) pour la classification des outils et des formalismes sous jacents, des meilleurs aux moins bons, suivant leurs capacité à supporter les patterns. Notre démarche est, essentiellement, justifiée par le fait qu aucun des formalismes existants ne supporte tous les patterns. L analyse multicritère d aide à la décision est alors la démarche la mieux appropriée pour leur comparaison. ABSTRACT. In this paper, we present a multicriteria-based framework for comparing Workflow modelling tools. Our model uses the nature of the process and the collection of workflow patterns as evaluation criteria. Specifically, our goal is to use ELECTRE method to rank the tools from best to worst according to their ability to support the workflow patterns. Our approach is justified by the fact that none of tools existing does support all the patterns. The multicriteria analysis seems us to be the appropriate approach for their comparison. MOTS-CLÉS : Patterns de workflow, Méthodes Multicritères, Processus métiers, Modèles de processus KEYWORDS: Workflow Patterns, Multicriteria methods, Business Process Modeling Actes du XXVIe congrès INFORSID 149 Fontainebleau, mai 2008

2 1. Introduction On a pu observer durant la dernière décennie un intérêt croissant pour la modélisation et l exécution des processus dans les entreprises. Les systèmes de gestion de workflow répondent à un besoin d optimisation des processus de travail en termes d utilisation des ressources humaines et temporelles et de leur coordination. La WFMC 1 définit le workflow comme étant " l automatisation d un processus d entreprise au travers duquel des documents, des informations et/ou des tâches sont transférés d un participant à un autre pour action, selon un circuit prédéfini". Ainsi, les systèmes de gestion de workflow sont des applications qui permettent la modélisation et le contrôle de l exécution d un processus métier automatisé. Pour atteindre ce but, le système a besoin d informations sur le processus métier. l organisation et l environnement technique dans lequel le processus va être exécuté. Différentes classifications ont été proposées pour catégoriser des applications workflow. Il existe en effet des types de workflow mettant en oeuvre des fonctionnalités et des architectures différentes. Ces applications tentent de répondre à des besoins organisationnels spécifiques et variés. Le critère principal de différenciation repose sur la mission fondamentale de l application de workflow, à savoir : L application s attache à automatiser un processus de production dont il est possible de définir les règles à l avance. L application s attache à automatiser un processus ad hoc dont il n est pas toujours possible de définir toutes les règles à l avance. Ainsi quatre types d applications workflow se distinguent : production, administratif, collaboratif et ad hoc (Alonso et al., 1997). Plusieurs outils de modélisation et d exécution sont disponibles sur le marché. Le choix d un outil en vue de modéliser un processus et d exécuter toutes ses instances peut dépendre de plusieurs critères : le coût, la performance ainsi que les fonctionnalités offertes. Dans (Russell et al., 2004, Russell et al., 2005, Aalst et al., 2000) les auteurs présentent un ensemble de patterns de workflow dont le but est de montrer les besoins fondamentaux et récurrents qui surviennent lors de la modélisation d un processus métier. Notre objectif dans ce papier est de montrer l adéquation et la pertinence de ces patterns de workflow selon la nature des processus à représenter (production, administratif, collaboratif, ad hoc), avec des besoins organisationnels spécifiques et variés. En effet, les outils de workflow ne se prêtent pas à toutes les situations et présentent de sérieuses limites. L objectif de ce papier est de : 1) décrire succinctement les patterns de workflow et leur importance d un type de processus à l autre (production, administratif, collaboratif, ad hoc ) ; 2) se repérer par rapport à cette importance (en terme de poids) pour classer les outils de modélisation et d exécution en prenant les familles de patterns comme critère de comparaison de ces outils ; 3) appliquer une méthode multicritère 1. Workflow Management Coalition Actes du XXVIe congrès INFORSID 150 Fontainebleau, mai 2008

3 ELECTRE III dans le but de classer ces outils de modélisation selon leur appropriation à tel ou tel type de processus. Cet article est structuré comme suit : La section 2 offre une brève description des méthodes multicritères d aide à la décision. La section 3 présente quelques patterns de workflow définis dans (Russell et al., 2004, Russell et al., 2005, Aalst et al., 2000). La section 4 présente notre démarche multicritère pour le choix d un outil de modélisation de processus et son application à un ensemble d outils. La section 5 présente quelques travaux relatifs à ce domaine. La section 6 présente notre conclusion et offre quelques perspectives. 2. Analyse multicritère d aide à la décision L analyse multicritère est définie (Roy, 1991) comme étant " l activité de celui qui, prenant appui sur des modèles clairement explicités mais non nécessairement complètement formalisés, aide à obtenir des éléments de réponse aux questions que se pose un intervenant dans un processus de décision". Les méthodes d analyse multicritère sont souvent classées sur la base de l ensemble des actions (alternatives). On distingue les méthodes discrètes et les méthodes continues. Nous nous focalisons, dans ce papier, sur la première catégorie. Les méthodes appartenant à la première catégorie impliquent un ensemble fini (ou dénombrable) d actions : A = {a 1,a 2,,a n } ; où n est le nombre d actions. Les actions sont évaluées et comparées sur la base d un ensemble des critères d évaluation G = {g 1,g 2,,g m } ; où m est le nombre de critères. L évaluation d une action a i selon un critère g j est notée g j (a i ). La structure générale d une matrice de performance est donnée par le tableau suivant : Actions potentielles Critères de comparaison g 1 g m a 1 g 1(a 1) g m(a 1) a n g 1(a n) g m(a n) Figure 1. Schéma général d une matrice de performance Pour comparer les actions dans A, il est nécessaire d agréger les évaluations partielles (i.e. par rapport à chaque critère) en une évaluation globale en utilisant un mécanisme d agrégation donné. Dans la catégorie discrète, il existe deux approches d agrégation (Mayster et al., 1994) : (i) approche du critère unique de synthèse, et (ii) approche de surclassement de synthèse. Le principe général de la première approche est que le décideur a pour but de maximiser une fonction d utilité U(a) =U(g 1 (a),g 2 (a),,g m (a)) en agrégeant les évaluations partielles de chaque action a A en une évaluation globale. Cependant l approche du critère unique de synthèse présente des problèmes de compensation, de changement d échelle et n est pas appropriée dans le cas où les critères de comparaison sont qualitatifs (pour plus de Actes du XXVIe congrès INFORSID 151 Fontainebleau, mai 2008

4 détails voir par exemple (Roy, 1985)). À l opposé de la première famille, la deuxième utilise des fonctions d agrégation partielle. En effet, les critères sont agrégés en utilisant une relation binaire partielle S, tel que asb veut dire "a est au moins aussi bonne que b". La relation binaire S est appelée relation de surclassement. L une des méthodes les plus connues appartenant à cette deuxième famille est la méthode ELECTRE-III, elle relève de la problématique γ (procédure de classement) 2. Son but est de classer les actions potentielles, depuis les meilleures jusqu aux moins bonnes. Elle démarre avec une hypothèse de surclassement, affaiblie avec deux tests, un test de concordance et un test de discordance, en faisant apparaître une relation de surclassement, noté S. Tous les calculs qui suivent sont basés sur la matrice de performance de la figure 1. Nous nous limitons, dans ce qui suit, à des principes de base de cette méthode. Pour plus de détails, nous renvoyons le lecteur à une littérature plus spécifique (Roy, 1985) (Mayster et al., 1994). Indice de concordance ELECTRE III utilise deux indices de concordance :i) indice de concordance par critère, et ii) indice de concordance globale. Le premier permet d affirmer dans quelle mesure l action a i est au moins aussi bonne que l action a k, pour le critère j. Le deuxième permet d affirmer dans quelle mesure l action a i est au moins aussi bonne que a k, sur tous les critères. Indice de discordance La relation de concordance définie ci-dessus est affaiblie par une notion de discordance. Le moyen d exprimer cette discordance est l introduction d un seuil de veto. Le seuil de veto pour un critère j, noté υ j, est, par définition, la valeur de la différence g j (a k ) g j (a i ) à partir de laquelle il apparaît prudent de refuser toute crédibilité au surclassement de l action a k par l action a i. Relation de surclassement Il y a toujours une relation de surclassement qui est établie entre deux actions (alternatives) ; mais cette relation apparaît très peu convaincante pour certains couples d actions. Ceci est exprimé, en associant un indice à chaque surclassement, appelé indice de crédibilité, noté δ ij. Relation et graphe de surclassement Le but de cette étape est d arriver, en se basant sur la relation de surclassement, à un classement des actions des meilleures aux moins bonnes. Mais comment distinguer les relations de surclassement qui doivent être prises en compte? Il existe un moyen de sélectionner ces relations, par la définition d un seuil de discrimination, noté s. Le degré de crédibilité sert à apprécier la plus ou moins grande crédibilité du surclassement. Mais compte tenu de la part d arbitraire de la formule définissant ce degré, la signification des degrés de crédibilité ne peut donc être absolue. Autrement dit, il n est pas possible d admettre que, dès l instant où δ ik >δ ki, le surclassement de a k par a i est strictement plus crédible que le surclassement de a k par a i. Le seuil de discrimination, qui est une valeur comprise entre zéro et un, permet d affirmer si une proposition de surclassement est plus crédible qu une autre hypothèse. Un autre paramètre appelé seuil de qualification noté λ, qui a pour but de ne prendre en compte que les degrés de crédibilité supérieurs à ce seuil est défini. Le graphe de surclassement 2. Il existe d autres problématiques telles que α (problématique du choix) et β (problématique du tri) Actes du XXVIe congrès INFORSID 152 Fontainebleau, mai 2008

5 A est alors construit en exploitant les degrés de crédibilité et les seuils de crédibilité et de qualification. Ce graphe est défini par la relation suivant : { a i Ss λ δik > λ et a k [1] δ ik δ ki > s,. La dernière étape consiste à exploiter la relation de surclassement et de définir ainsi un classement des différentes actions considérées. 3. Patterns de workflow L application d approches basées sur les patterns pour l identification de constructeurs génériques de workflow a été en premier proposée par Van Der Aalst et al (Aalst et al., 2000). Elle a permis initialement l identification de 20 patterns de contrôle correspondant aux perspectives de flux de contrôle des systèmes de workflow, étendu dans (Russell et al., 2006a) à 43 nouveaux patterns. Ces travaux ont déclenché d autres études dans deux directions : la première est l utilisation des patterns pour établir une base formelle pour déterminer les besoins de représentation selon la perspective de flux de contrôle, la seconde est l utilisation des patterns pour évaluer des langages de modélisation de processus métier et des standards de services Web. D après (Aalst et al., 2000) "les patterns de workflows sont une abstraction d une forme concrète, qui est récurrente dans un contexte spécifique non arbitraire". Les patterns ont été très populaires aussi bien chez les théoriciens que les praticiens pour avoir permis de comparer, de discuter et d enrichir les systèmes de gestion de workflow selon leur capacité à supporter ces patterns (car ils ne dépendent d aucun formalisme de modélisation ou d implémentation technologique). On distingue trois familles de patterns : contrôle, données et ressources (Russell et al., 2005, Russell et al., 2006a, Russell et al., 2004) Patterns de contrôle On distingue six classes de patterns de contrôle (Russell et al., 2006a) : Les patterns de flux de contrôle basiques capturent les aspects élémentaires d un processus et sont similaires aux opérateurs proposés par l organisme de standardisation des solutions workflow (WfMC). On dispose de constructeurs basiques présents dans la plupart des langages de workflow pour modéliser les cheminements séquentiel, parallèle et conditionnel. Les patterns de synchronisation et de branchements avancés décrivent des comportements plus complexes de branchements et de convergence. Les patterns structurels caractérisent des situations de restrictions : le cycle arbitraire et la terminaison implicite. Les patterns invoquant des instances multiples permettent le traitement des cas où une activité d un processus peut avoir plusieurs instances s exécutant en même temps. Ils permettent de satisfaire les situations où il est nécessaire de : Actes du XXVIe congrès INFORSID 153 Fontainebleau, mai 2008

6 - exécuter un certain nombre d instances d une activité, - synchroniser les instances de l activité avant de passer à la suite du processus. Les patterns basés sur les états décrivent des situations où le processus supporte la notion d état ( choix différé, cheminement parallèle intercalé). Les patterns de suppression permettent l annulation d une activité ou d un cas Patterns de ressources Les patterns de ressources (PR) ont pour objectif de modéliser et de représenter les différentes manières dont les ressources humaines sont représentées et utilisées dans un workflow. Les patterns de création permettent de fournir une précision sur la manière dont les work items (instances d activités) doivent être gérés après leur création durant les phases de proposition et d allocation aux ressources. Les push patterns caractérisent les situations où des work items nouvellement créés sont progressivement alloués aux ressources. Les pull patterns caractérisent les situations où des ressources individuelles sont informées d un ensemble de work items qui doivent être exécutés. Les patterns de détournement s intéressent aux situations où l allocation d un work items à une ressource est interrompue soit par le système de gestion de workflow soit par la ressource. Plusieurs scénarii d évolution sont alors possibles. Les auto-start patterns décrivent les situations où l exécution des work items est déclenché par des événements spécifiques dans leur cycle de vie. Un tel événement peut inclure la création ou l allocation des work items. Les patterns de visibilité représentent les différentes étendues des work items rendues visibles par les ressources. Les patterns sont décrits succinctement en annexe. Pour plus de détails voir (Russell et al., 2005, Aalst et al., 2000, Russell et al., 2006a). 4. Framework pour le choix d un outil de modélisation de Workflow Dans une démarche d ingénierie de solution logicielle de type workflow, la première étape consiste à identifier les domaines de l entreprise susceptibles de tirer bénéfice de la mise en place d une application workflow. En second lieu, vient la question du choix d un outil approprié selon le type d application workflow à instaurer. Sachant que les processus métiers sont de natures différentes (production, administratif, collaboratif, ad-hoc), ceci implique des besoins différents lors du choix de l outil, pour leur pouvoirs de modélisation et leurs paradigmes d exécution. Notre but est d aider un responsable informatique à choisir un outil approprié pour modéliser des processus en utilisant la collection de patterns comme un ensemble de Actes du XXVIe congrès INFORSID 154 Fontainebleau, mai 2008

7 critères de comparaison. La solution que nous proposons est basée sur l élaboration d un modèle multicritère d aide à la décision pour le choix de l outil adéquat pour chaque type de processus, où les critères de comparaison sont les patterns de workflow et les actions (alternatives) sont les outils et langages. Nous prenons en compte l importance des patterns qui diffère d un type de workflow à un autre Présentation de notre démarche Étant donné qu aucun outil ne supporte tous les patterns 3, l analyse multicritère d aide à la décision s impose comme meilleure démarche de résolution du problème. Le cheminement de notre approche est illustré par la figure 2, sous la forme d un diagramme d activité UML. Figure 2. Schéma général de notre démarche Notre approche pour comparer des outils est définie dans le but de répondre aux questions suivantes : Quels sont les critères d évaluation? Quelle méthode choisir pour sélectionner un outil/formalisme adéquat pour la représentation dun type de processus? 3. La solution optimale au sens propre du terme n existe pas. Actes du XXVIe congrès INFORSID 155 Fontainebleau, mai 2008

8 Comment prendre en compte le type du processus lors du choix de cet outil? Pour répondre à ces questions, les points à considérer sont résumés dans ce qui suit : Soit un type de processus (l un des quatres types). Soit un ensemble d outils de workflow (à comparer). Soit un ensemble de patterns auxquels nous attribuons des poids. Le poids attribué à un même pattern peut être différent d un type de processus à un autre. Ceci est justifié par le fait que ce pattern n a pas la même importance dans la modélisation de chacun des types de processus Les concepts du modèle Les concepts manipulés dans cette approche sont représentés par le modèle de données de la figure 3. Figure 3. Concepts de base pour la comparaison d outils de modélisation Les patterns Plusieurs théoriciens se sont inspirés des patterns de workflow pour évaluer différents outils/formalismes (Russell et al., 2006b, Wohed et al., 2006, Wohed et al., 2002). Cependant, toutes ces études s arrêtent à ce niveau et aucune ne propose une démarche pour le choix du "meilleur" outil. Notre démarche consiste à classer les outils existants du plus adapté au moins adapté pour un type de processus, et de faciliter ainsi le choix du meilleur outil (avec son formalisme de modélisation sous jacent). Nous utilisons les patterns non seulement comme critères d evaluation mais aussi de comparaison. Ces critères sont au nombre de 63 parmi lesquels : 20 patterns de contrôles et 43 patterns de ressources (énumérés en annexe). Les études que l on Actes du XXVIe congrès INFORSID 156 Fontainebleau, mai 2008

9 trouve dans la littérature, dont l objectif est d évaluer des outils, ont pour point commun de définir une échelle à trois niveaux à savoir : un pattern est supporté (noté +), est plus au moins supporté (+/ ) et n est pas supporté (noté ). On nous basant sur ces évaluations, nous avons défini une échelle cardinale de 1 à 3, où +, +/ et sont représentés respectivement par 1, 2 et 3. Nous obtenons ainsi une matrice de performance permettant l application de la méthode ELECTRE III Les outils Les actions (ou alternatives), du modèle multicritère que nous proposons, sont les outils et langages de modélisation de processus. Les outils retenus pour faire partie de l étude sont choisis sur la base des évaluations faites dans (Russell et al., 2004), (Russell et al., 2005), (Aalst et al., 2000) concernant leurs capacités à supporter les patterns. Ce sont les outils pour lesquels nous disposons d informations quant à leur capacité à supporter les patterns de workflow. Les outils choisis pour cette étude sont : Staffware,WebSphere MQ, FLOWer, COSA, iplanet, UML, BPMN. Notons que cet ensemble peut être étendu en incluant d autres outils de modélisation et d exécution de processus. Une étude préalable sur leur capacité à supporter les différents patterns de workflow sera alors à faire Evaluation de l importance des patterns selon le type du processus Pour pouvoir donner des poids différents aux patterns en fonction du type de processus, nous avons évalué l importance des patterns qui diffère d un type de processus à un autre. Les tableaux 1 et 2 présentent notre évaluation de cette pertinence respectivement pour des patterns de contrôle et de ressource. Cette importance est représentée sur une échelle à quatre valeurs allant du "pattern très important (++)" au "pattern pas du tout important(- -) ", avec deux valeurs intermédiaires "pattern peu important (-)" et "pattern important (+)". Notons que cette évaluation est indépendante des outils. Elle est basée uniquement sur les caractéristiques des différents types de processus/workflow 4 (Alonso et al., 1997, Nurcan, 2008) : Workflow de production (WP) Les tâches sont répétitives, les procédures sont pré-établies et supportent peu de changement dans le temps. Workflow administratif (WA) Il est caractérisé par la simplicité de l enchaînement des tâches, la clarté dans la définition des tâches (ce type de workflow est donc aisément automatisable) et il est basé en général sur une infrastructure de messagerie. 4. Notre usage des notions de processus et de workflow qui peut paraître "invariant" vient du fait que les formalismes étudiés sont tous dirigés par "les activités". Autrement dit le processus se définit toujours comme un enchaînement de tâches avec un mécanisme de coordination plus au moins riche selon le pouvoir d expression du formalisme de modélisation (mesuré ici pas les patterns de workflow). Cela ne signifie nullement que nous affirmons qu un processus est un workflow. Pour plus de précision voir (Nurcan, 2008) Actes du XXVIe congrès INFORSID 157 Fontainebleau, mai 2008

10 workflow/ WP WA WC WAH workflow WP WA WL WAH pattern patterns PC PC PC PC PC PC PC PC PC PC PC PC PC PC PC PC PC PC PC PC Tableau 1. Importance des patterns de contrôle pour les quatres types de workflow. Workflow collaboratif (WC) Les principaux enjeux du travail coopératif sont : favoriser la coordination des participants, faciliter la communication entre les participants et le partage des données, ainsi que de faciliter l organisation du groupe. Workflow ad hoc (WAD) Le workflow ad hoc ne repose pas sur des procédures formalisées ( processus non déterministe ou non structuré) et sa structure est définie pendant l exécution en fonction des décisions humaines prises suite à la réalisation des tâches. Prenons quelques exemples justifiant notre évaluation : Etant donné que le nombre de branches à activer simultanément (pattern parallèle PC2) n est pas connu à la conception d un processus ad hoc, le pattern décrivant un parallélisme figé est alors peu important pour ce type de processus, il en est de même pour le pattern de synchronisation PC3. Le pattern instances multiples avec connaissance à l exécution PC14, ainsi que le pattern étape importante PC18, sont très importants, pour un processus ad-hoc, car ils permettent de prendre en compte la construction dynamique dans ce type de processus. Le pattern cheminement parallèle intercalé PC17 est aussi très important pour ce type de processus, car les processus se construisent par pas en suivant le rythme de l exécution. En effet, la réalisation d un processus non structuré (ad-hoc) peut impliquer à chaque fois l exécution d un nouvel enchaînement des tâches, voire la création de nouvelles tâches (instances multiples sans connaissance à l exécution PC15). Les cinq premiers patterns de contrôle sont très importants, pour un workflow de production, car les tâches dans ce cas sont prévisibles et récurrentes. Ceci justifie, aussi, le peu d importance des patterns choix multiple PC6, donc fusion synchronisée PC7 et fusion multiple PC8. Lorsque l on considère un workflow administratif, les patterns choix différé PC16 et cheminement parallèle intercalé PC17 ne sont pas du tout importants, car dans ce Actes du XXVIe congrès INFORSID 158 Fontainebleau, mai 2008

11 workflow/ WP WA WC WAH workflow WP WA WC WAH pattern patterns PR PR PR PR PR PR PR PR PR PR PR PR PR PR PR PR PR PR PR PR PR PR PR PR PR PR PR PR PR PR PR PR PR PR PR PR PR PR PR PR PR PR PR Tableau 2. Importance des patterns de ressource pour les quatres types de workflow type de processus, les tâches sont très prévisibles et les règles d enchaînement des tâches sont très simples et clairement définies (c est notre hypothèse de travail). Etant donné que le workflow collaboratif est axé sur la communication et le partage d information entre les différents acteurs, le pattern PC13 allocation d un work item à un groupe est très important, ce qui n est pas le cas pour un processus administratif ou de production, axés plus sur des affectations à des ressources individuelles Les poids des critères L attribution des poids aux différents critères d un modèle multicritère d aide à la décision est l une des étapes les plus importantes du processus 5 Les poids nous montrent l importance de l utilisation d un critère (pattern dans notre cas). Les poids des différents critères pris en compte dans notre modèle sont ainsi déterminés en se basant sur les caractéristiques de chacun des types de processus considérés, à savoir production, administratif, collaboratif et ad-hoc. Concrètement, ces poids 5. Généralement, c est au décideur de les fixer, reflétant ainsi ses préférences. Actes du XXVIe congrès INFORSID 159 Fontainebleau, mai 2008

12 sont définis, en attribuant à chacun des critères qualitatifs (très important, important, peu important, pas du tout important) un poids compris entre zéro et un (voir table 3). Critère qualitatif Très important Important Peu important Pas du tout important Poids Tableau 3. Poids des critères. Les résultats (classements) obtenus pour les différents types de processus après application de la méthode multicritère d aide a la décision ELECTRE III, sont présentés par les figures 4, 5, 6 et 7, respectivement pour les processus de type production, administratif, collaboratif et ad-hoc. Ainsi, comme nous pouvons le lire sur la Figure 4, COSA est l outil le mieux approprié pour un processus de production. Staffware, iplanet et Websphere occupent la troisième place et sont ex-equos...etc. Figure 4. Classement des outils pour un processus de production Figure 5. Classement des outils pour un processus administratif Figure 6. Classement des outils pour un processus collaboratif Figure 7. Classement des outils pour un processus ad-hoc Actes du XXVIe congrès INFORSID 160 Fontainebleau, mai 2008

13 5. Travaux similaires Plusieurs travaux se sont intéressés à l évaluation ou à la comparaison d outils de modélisation et d exécution de processus. Les auteurs dans (Aalst et al., 2000, Russell et al., 2004, Russell et al., 2006a, Russell et al., 2005), ont défini la collection de patterns présentée précédemment en se basant sur les besoins des processus. Ces patterns ont été, ensuite, utilisés pour voir de quelle manière un ensemble d outils les supportent (Staffware, FLOWer, COSA, iplanet, SAP Workflow, FileNet, BPEL,BPMN, XPDL, UML ADs, EPC... ). Dans ces études les auteurs se sont limités à une discussion de la capacité de ces formalismes ou outils à supporter ou non un pattern (Wohed et al., 2003, Russell et al., 2006b, Wohed et al., 2006, Wohed et al., 2002, Russell et al., 2006a). Dans ce papier nous présentons un modèle dont le but est d aider à choisir le formalisme le mieux approprié pour un processus. Dans (Benali et al., 2007), les auteurs présentent un modèle de comparaison de moteurs de workflow, où les critères de comparaison sont les propriétés d exécution et la méthode utilisée pour les agréger est la méthode de la somme pondérée qui présente de nombreux inconvénients dont la compensation entre les critères et le changement d échelle. Ainsi, le modèle présenté dans ce papier surpasse ces limitations, en utilisant les méthodes d analyse multicritère d aide à la décision, conçues pour ce type de problème. 6. Conclusion Le travail présenté dans cet article a permis dans un premier temps d étudier la pertinence des patterns de workflow en nous basant sur les caractéristiques des différents type de processus. En second lieu, cet evaluation a permis de classer un ensemble de formalismes selon leurs aptitude à modéliser un type donné de processus (production, administratif, collaboratif, ad hoc). L analyse multicritère d aide à la décision a été utilisée pour effectuer cette classification. Nous avons ainsi démontré par les différents résultats, que suivant le type de processus à modéliser un (ou ensemble) d outil(s) technique(s) est(sont) mieux approprié(s) qu un autre. Le framework proposé est basé sur les patterns de workflow et utilise la méthode multicritère d aide à la décision ELECTRE III pour permettre la prise en compte de tous ces patterns pour la classification des outils, tout en permettant de prendre en compte leurs pertinence grâce à des pondérations qui varient d un type des processus à un autre. Le framework proposé peut être étendu, en prenant en compte les autres familles de patterns (de données) ainsi que d autres critères de comparaison. La pertinence des patterns qui varie d un contexte de processus à un autre, peut être aussi utilisée comme base pour la réingénierie des processus. Actes du XXVIe congrès INFORSID 161 Fontainebleau, mai 2008

14 7. Bibliographie Aalst V., Barros A., ter Hofstede A., Kie-puszewski B., «Advanced Workflow Pattern», 7th International Conference on Cooperative Information Systems (CoopIS 2000), Alonso G., Abbadi D. E., Mohan.C, «Fonctionality and Limitation of Current Workflow Management Systems», IEEE Expert, Benali K., Baïna K., Azayite F.-Z., Belakbir N., Srir H., «Workflow Engines Comparison Model», IEEE RCIS, IEEE International Conference on Research Challenges in Information Science, Ouarzazate, Morocco, Mayster L., J.Pictet, Méthodes multicritères ELECTRE, Presses Polytechniques et Universitaires Romandes (PPUR), Nurcan S., «Business Process Modeling for developing Process Oriented IT Systems, The "Business Process Management Tools and Technologies», track of the 2004 IRMA International Conference- May 23-26, New Orleans, USA., Nurcan S., «A survey on the flexibility requirements related to business processes and modeling artifacts», Proceedings of the 41st Annual Hawaii International Conference on System Sciences, Big Island, Hawaii, USA, 7-10 January, Roy B., «Méthodologie multicritère d aide à la décision», Economica, collection "Gestion", Roy B., «The outranking approach and the foundations of ELECTRE methods», Theory and Decision, Russell N., A.Hofstede, D.Edmond, Aalst V., «Workflow Data Patterns», QUT Technical report, Queensland University of Technology, Russell N., ter Hofstede A., van der Aalst W., Mulyar N., «Workflow Control-Flow Patterns», BPM Center Report BPM-06-22, BPMcenter.org, 2006a. Russell N., van der Aalst W. M., Hofstede A. H., Wohed P., «On the Suitability of UML 2.0 Activity Diagrams for Business Process Modelling», Proceedings of the Third Asia-Pacific Conference on Conceptual Modelling (APCCM2006), 2006b. Russell N., van der Aalst W., ter Hofstede A., Edmond D., «Workflow Resource Patterns : Identification, Representation and Tool Support», Proceedings of the 17th Conference on Advanced Information Systems Engineering, volume 3520 of Lecture Notes in Computer Science, pages , WfMC, «http :// Wohed P., Perjons E., Dumas M., ter Hofstede A., «Pattern-Based Analysis of EAI Languages : The Case of the Business Modeling Language», In Proceedings of the 5th International Conference on Enterprise Information Systems (ICEIS), Wohed P., van der Aalst W., Dumas M., ter Hofstede A., «Pattern-Based Analysis of "BPEL4WS"», QUT Technical report,queensland University of Technology, Wohed P., van der Aalst W., Dumas M., ter Hofstede A., Russell N., «On the Suitability of BPMN for Business Process Modelling», In Proceedings of the 4th International Conference on Business Process Management, pages pp , Vienna, Austria., Actes du XXVIe congrès INFORSID 162 Fontainebleau, mai 2008

15 Annexe Patterns de contrôles Nom Description PC1 Séquence Une activité ne s exécute que si toutes les activités qui la précèdent sont exécutées. PC2 Parallèle Il permet pour un lien de contrôle de s activer en plusieurs en parallèle. PC3 Synchronisation Plusieurs branches fusionnent en un seul lien synchronisant, ainsi toutes ces branches. PC4 Choix exclusif Un chemin est choisi entre plusieurs. PC5 Fusion simple Un point dans lequel deux ou plusieurs branches se joignent sans synchronisation PC6 Choix multiple Un chemin ou plusieurs sont exécutés à l aide d une décision prise à l exécution. PC7 Fusion synchronisée Plusieurs flux de contrôle convergent vers un seul. PC8 Fusion multiple Une ou plusieurs branches d un workflow convergent sans besoin de synchronisation. PC9 Discriminateur On attend qu une des branches entrantes se termine pour activer la suivante PC10 Cycle arbitraire Une partie ou un sous ensemble d activités peuvent être exécutées plusieurs fois. PC11 Terminaison On dit qu un processus est terminé si toutes implicite les activités qui le composent sont terminées. PC12 Instances multiples Certaines instances d une activité sont exécutées, sans synchronisation de manière indépendante, sans besoin de synchronisation. PC13 Instances multiples Exécuter une activité ou une partie avec connaissance d un workflow plusieurs fois. à la conception PC14 Instances multiples Exécuter une activité ou une partie d un workflow plusieurs avec connaissance fois. Les instances s exécutent de manière à l exécution concurrente et sont indépendantes. PC15 Instances multiples Une activité d un processus s exécute plusieurs fois sans connaissance Le nombre d exécutions peut changer au cours à l exécution de l exécution d une instance. PC16 Choix différé Le choix d une branche est effectué à l aide d une information non disponible au moment où ce point est atteint le choix est alors retardé PC17 Cheminement on ne connaît pas l ordre d exécution parallèle intercalé des activités, qui est déterminé à l exécution PC18 Étape importante Permet l exécution d une activité lorsqu une étape importante est atteinte PC19 Annulation d activité Permet d annuler une activité PC20 Suppression d un cas Permet la suppression de toute une instance Patterns de ressources Nom Description PR1 Allocation Directe Spécifier l identité de la ressource qui va exécuter une tâche PR2 Allocation basée sur les rôles Une tâche peut être seulement exécutée par une ressource ayant un rôle donné. PR3 Allocation reportée L identification de la ressource est reportée au moment de l exécution PR4 Autorisation spécifier le rang des ressources qui sont autorisées à exécuter une tâche. PR5 Séparation des fonctions Spécifier que deux tâches doivent être allouées à différentes ressources. PR6 Manipulation de cas Allouer des work items dans un cas de workflow à la même ressource PR7 Maintenir le plus familier un work item, dans un cas, est attribué à la même ressource qui a réalisé le précédent. Actes du XXVIe congrès INFORSID 163 Fontainebleau, mai 2008

16 PR8 PR9 PR10 Allocation basée sur les aptitudes Allocation basée sur l historique Allocation organisationnelle Se baser sur les aptitudes spécifiques des ressources pour faire l affectation Attribuer un work item à une ressource sur la base de ses expériences réussies. Sur la base de la position dans l organisation et de la relations avec les autres ressources PR11 Exécution automatique Exécuter une instance d une tâche sans utiliser une ressource humaine. PR12 PR13 PR14 Distribution par offre ressource singulière Distribution par offre ressources multiple Distribution par allocation ressource singulière Proposer un work item à une ressource individuelle sélectionnée Proposer un work item à un groupe de ressources sélectionnées. Allouer un work item à une ressource spécifique PR15 Allocation aléatoire Allouer les taches à des ressources sur une base aléatoire PR16 Allocation cyclique Allouer les tâches à des ressources sur une base cyclique. PR17 La file d attente la plus Allouer la tâche à la ressource qui a la file la plus courte. courte PR18 Distribution à priori Allouer potentiellement des tâches avant le moment de leur exécution. PR19 Distribution à l exécution Assigner les tâches aux ressources au moment où elles sont autorisées à être exécutées. PR20 Distribution tardive Assigner des tâches aux ressources, après qu elles soient autorisés à s exécuter PR21 PR22 PR23 PR24 PR25 Allocation initiée par une ressource Exécution initiée par la ressource Exécution initiée par une ressource Le système détermine le contenu de file de travail Les ressources déterminent le contenu de leur file de travail s engager à travailler sur une tâche sans commencer à l exécuter immédiatement. Une ressource commence à travailler sur une tâche qui lui a été allouée. Une ressource sélectionne une tâche et commence à la réaliser immédiatement. Le moteur d exécution de workflow gère le contenu et l ordre dans lequel les tâches sont présentées aux ressources Le format, le contenu et l ordonnancement des tâches sont spécifiés par la ressource. PR26 Autonomie de selection La ressource choisit ses work items. PR27 Délégation La ressource peut déléguer une tâche qui lui a été allouée. PR28 Escalation Allouer une tâche à une ressource autre que celle qui a été choisie précédemment PR29 Désaffectation Une ressource abandonne la tâche qui lui a été allouée et l affecte à une autre. PR30 Réallocation Une ressource assigne une tâche à une autre sans perte de données de l état d avancement de la tâche. PR31 Reallocation Une ressource réoriente une tâche vers une autre ressource sans conservation de son état. PR32 Suspension/reprise Une ressource suspend et reprend par la suite l exécution de tâche. PR33 Saut Une ressource peut sauter une tâche qui lui a été alloué et la considérer accomplie. PR34 Refaire Une ressource peut exécuter un work item qu elle a déjà accompli. PR35 PR36 Avant le temps d exécution Commencement à la création Une ressource peut exécuter une tâche avant le temps qui a été alloué aux ressources qui travaillent sur le cas. Une ressource commence l exécution d un work item au moment où il est créé. Actes du XXVIe congrès INFORSID 164 Fontainebleau, mai 2008

17 Commencement dès l affectation Commencer l exécution d une tâche dès son affectation à une ressource. PR38 Exécution empilée Lancer la prochaine instance d une tâche une fois la précédente accomplie. PR39 Exécution enchaînée On commence automatiquement la prochaine tâche, dès que la précédente est accomplie. PR40 Configuration de la Limiter la visibilité des tâches non affectées. visibilité de tâches non affectées PR41 Configuration de la Limiter la visibilité des tâches déjà affectées à une ressource. visibilité des tâches affectées PR42 Execution simultanée Une ressource exécute plus d une tâche à la fois. PR43 Ressource Additionnelle Une tâche peut nécessiter les services de plusieurs ressources. Actes du XXVIe congrès INFORSID 165 Fontainebleau, mai 2008

18 !!! Actes du XXVIe congrès INFORSID 166 Fontainebleau, mai 2008