GESTION DE PROCESSUS AVEC SOA ET BPM

Transcription

1 Université de Fribourg, Suisse Département d'informatique Bachelor en informatique de gestion GESTION DE PROCESSUS AVEC SOA ET BPM DANS UNE PME Travail de bachelor Matthieu Borloz Mettlenweg Biel/Bienne (Dr. Stefan Hüsemann) Mars 2013

2 ABSTRACT Ce travail de bachelor en informatique de gestion va s intéresser à la problématique de l intégration d un processus automatisé entre le système d information d une entreprise de type PME et la douane Suisse. Pour être concurrentielles, les entreprises ont à gérer des interactions qui nécessitent des échanges d information de plus en plus riches avec des parties prenantes. Ces relations, qui existent sous forme de processus, poussent les systèmes d information des entreprises à être à même de supporter une collaboration avec d autres SI. Ce travail va s intéresser aux concepts SOA et BPM qui établissent des standards pour rendre possible cette collaboration. MOTS CLÉS SOA, BPM, BPM Lifecycle, BPMN 2.0, BPMS, e-dec exportation, Architecture des SI, SOAP, WSDL, processus, web services.. Introduction 1

3 TABLE DES MATIERES 1. Introduction Problématique Questions de recherche et démarche Méthodologie Public cible L entreprise et le SI Définitions Système d information Classification des SI Typologie selon le niveau de décision et vision OLAP OLTP Découpage fonctionnel d un SI : métiers et besoins Architecture des SI Définition Un modèle d architecture des SI : Le modèle de référence de l urbanisation SOA : Emergence d un modèle d architecture SI La réponse SOA Motivation et Définition de SOA Les principes conceptuels de SOA Orientation service Modularité et composition des services Réutilisabilité Couplage faible Promotion de l Agilité Valorisation des systèmes déjà existants Les composants et standards de SOA Niveaux de service de l architecture SOA Utilisation des web services Un format pilier : XML Echange de messages avec SOAP WSDL...28 Introduction 2

4 3.3.6 UDDI BPEL BPM : gérer l organisation par les processus Bases conceptuelles Définition Historique Le but du BPM : l agilité BPM Lifecycle Concept général La phase Goal Specification / Strategy Definition La phase Design La phase Implementation La phase de Process Runtime La phase de Process Improvement BPMM Concept Représentation des niveaux Niveau 1 : initial Niveau 2 : Managed Niveau 3 : Standardized Niveau 4 : Predictable Niveau 5 : Inovating Level Liens entre BPMM et le BPM Lifecycle BPMN Avènement de BPMN Principaux constituants d un diagramme de BPMN Exécution de BPMN BPMS Principe Comparatif des outils existants...47 Introduction 3

5 5 Partie pratique : Application du BPM Lifecycle dans une PME BPM Lifecycle Phase 1 : Goal specification / Strategy definition Business Case Specification du but Alignement stratégique BPM Phase 2 : Process Design Description du processus d export du point de vue de l entreprise Description du processus d export du point de vue de la douane suisse Web service e-dec e-dec web Processus d export entre l ERP, le BPMS et e-dec BPM Phase 3 : Implementation Création des interfaces de vérification des données issues de l ERP Mise en fonction du mock service e-dec avec SOAP UI Configuration du webservice dans Bonita Réponse du web service Intégration des résultats dans le BPMS BPM Phase 4 : Process Runtime Utilisation de la User XP Contrôle et saisie des données par l utilisateur Phase 5 : Process Improvement Envoi des données par l ERP Utilisation de fichiers XML dans le BPMS Gestion des réponses de déclaration par le BPMS Définition des rôles autour du processus dans la perspective d une implémentation Gestion des ressources Conclusion Bibliographie Annexes Annexe 1 : Prototype d implémentation dans BonitaSoft Annexe 2 : Documents issus du service e-dec...79 Introduction 4

6 LISTE DES FIGURES Figure 1 : Fonctionnement générique d un système Figure 2 : Décomposition en sous-systèmes Figure 3: Niveau décisionnels Figure 4 : OLTP vs OLAP (Zaiaine, 2013) Figure 5: Découpage fonctionnel (CSB, 2013) Figure 6: Modele de l'urbanisation (Jozwiak, 2013) Figure 7: Avant et après SOA ( 2011) Figure 8: Couches SOA (Erl, 2005) Figure 9: XML Schema avec fichier XML (Wikipedia, 2012) Figure 10: Requête et reponse SOAP simple (Quaine, 2012) Figure 11: Fonction de WSDL (Haas, 2012) Figure 12: Forme d'un document WSDL (IBM, 2012) Figure 13: Implémentation de UDDI (Krawler, 2009) Figure 14: BPM Lifecycle Figure 15: Niveaux du BPMM Figure 16: Avant et après BPMN Figure 17: Types d'évènement BPMN Figure 18: Tâches BPMN Figure 19: Branchements BPMN Figure 20: Pools et Lanes BPMN Figure 21: Tableau comparatif des outils BPMS en accès libre Figure 22: Canaux de distribution et imputation de la marge sur prix de vente final Figure 23: Incoterms Figure 24: Processus de commande dans l'erp Figure 25: Procédure d'export actuelle chez Hans Werk Figure 26: Fonctionnement de e-dec export du point de vue de la douane Figure 27: Portail e-dec web (e-dec, 2013) Figure 28 : Processus d export avec ERP, BPMS et e-dec Figure 29 : Facture ERP Figure 30: Configuration de SOAP ui avec fichier WSDL Figure 31: interface SOAP UI Figure 32: Interface connecteur service web de bonita Figure 33: Definitions du fichier e-dec WSDL Figure 34: Déclaration en format XML Figure 35: Configuration du retour des données dans Bonita Figure 36: User Experience Bonita Figure 37: Formulaire de saisie et de contrôle des données Figure 38: Interface de connexion web service payante de bonita (BonitaSoft, 2011) Introduction 5

7 Introduction 6

8 1. INTRODUCTION 1.1 Problématique L implémentation d un processus avec le concept de BPM (Business Process Management) entre l administration des douanes et une PME (Petites et Moyennes Entreprises) va être le sujet de ce travail. Le processus dont il sera question consiste en la déclaration pour l export de marchandise qui est exigé par toute exportation de marchandise depuis la Suisse. Ce processus verra l ERP (Entreprise Ressource Planning) de l entreprise collaborer avec e- dec, la plateforme de déclaration de douane de la Confédération suisse. Exporter des marchandises depuis la Suisse n est de loin pas une sinécure. Les processus administratifs nécessaires aux opérations de douane représentent une charge de travail importante. L entreprise exportatrice devra disposer d un important savoir-faire dans son organisation qui sera à même d exécuter des tâches administratives spécialisées pour lesquelles les erreurs sont proscrites. Cette compétence occasionnera des coûts qui se répercuteront inévitablement sur le prix du produit ainsi qu un temps de traitement qui aura une influence sur le délai de livraison du produit. Le prix et la disponibilité du produit étant des éléments clés de la compétitivité d une entreprise, ces démarches ont, du point de vue de l entreprise, tout intérêt à être optimisées. Consciente de l impact de ces tâches administratives pour ses déclarants et soucieuse d un mode de gestion efficace, la douane suisse a mis sur pied un système de type SOA (Service Oriented Architecture) nommé e-dec qui permet de réaliser les déclarations de douane (export et import) en ligne et gratuitement. Mais l utilisation de ce service semble pour le moment surtout privilégiée par de grandes entités à même de développer des solutions informatiques à l interne et par des entreprises spécialisées dans la logistique, offrant un service d export facturé à leurs clients. Or si le modèle d affaire de l entreprise exige de nombreux envois et par conséquent de nombreuses déclarations, les frais engendrés par ceux-ci deviendront importants et il pourrait être pertinent que l entreprise réalise elle-même ces déclarations avec le concours de son SI. Afin de s assurer d un traitement optimal et d éviter une saisie manuelle des données qui serait à la fois source d erreurs et de coûts, l entreprise aura tout intérêt à interfacer son propre système et ainsi à faire transiter les données entre les deux systèmes de manière automatique. Or la plupart des entreprises exportatrices sont des PME. Celles-ci comptent généralement sur un système de type ERP dont les possibilités de configuration sont limitées. Introduction 7

9 La problématique de ce travail sera d évaluer comment il est possible par le biais de BPM de faire collaborer un système de type SOA et un ERP pour réaliser le processus de déclaration de marchandises exigé par la loi. Afin de répondre à cette problématique, il sera premièrement question d explorer et d expliciter les concepts théoriques inhérents à SOA et BPM pour disposer des bases conceptuelles nécessaires à la mise sur pied d une approche processus avec des SI pour cible. Ensuite, l intégration même du processus sera abordée en utilisant les concepts définis dans la partie théorique. 1.2 Questions de recherche et démarche Ce travail s intéressera dans un premier temps au concept général d architecture des SI et la place que SOA occupe dans celle-ci. Pour cela, les questions de recherche suivantes seront traitées : Pourquoi un SI est-il un élément essentiel d une entreprise et, particulièrement, de sa stratégie? Pourquoi le concept d architecture des SI a-t-il émergé comme une nécessité? En quoi SOA est-elle une architecture de référence à ce jour et quels sont ses principes de fonctionnement? La démarche pour traiter ces trois premières questions sera de d abord comprendre le lien fondateur entre les systèmes d information et l entreprise. Cette première question permettra alors de comprendre la nécessité d un recours au niveau d abstraction qu est l architecture des SI. Suite à cela, un type particulier d architecture, SOA, sera exposé en détail. L objectif sera de partir de la notion de SI au sens le plus générique et d offrir au lecteur des clés de compréhension pour appréhender les problèmes d architecture des SI et les solutions offertes par l industrie informatique. Après s être intéressé au fonctionnement technique des SI, ce travail va opérer un changement de perspective en mettant le focus sur l organisation et ses processus par le biais des concepts et outils du BPM. Ces derniers seront abordés avec les questions de recherche suivantes : Qu est-ce que BPM, pourquoi l utiliser? Comment le BPM Lifecycle permet-il à l entreprise de gérer ses processus et de les améliorer? Comment le niveau de sensibilité d une organisation aux processus peut-il être évalué et amélioré? Quelles bases conceptuelles et technologiques rendent possible l exécution de Business Process sur une SOA? Introduction 8

10 Quel outil BPMS open source ou en accès libre est-il le plus à même de permettre une modélisation et une exécution de processus? La démarche consistera ici à présenter quelles approches managériales ont permis la naissance de BPM et sa reconnaissance comme une pratique utile pour les organisations. La méthodologie du BPM Lifecycle servira à présenter les différentes phases relatives à la gestion des processus. Des normes utilisées dans le cadre de cette démarche seront également traitées. La présentation de celles-ci permettra notamment d expliciter le lien entre SOA et BPM et ainsi de pouvoir évaluer des solutions logicielles BPMS. Suite à cette approche théorique de BPM et SOA, il sera question de mettre en pratique cette implémentation avec le cas d un processus concret d exportation de marchandises. Les questions de recherche suivantes seront alors traitées : Quels sont les besoins qui vont nécessiter une approche processus au sein de la PME et comment le web service e-dec pourra-t-il y participer? Quelle forme prendra la modélisation de ce processus avec le standard BPMN 2.0? Quelles tâches de configuration seront nécessaires depuis la modélisation pour réaliser l exécution et les phases suivantes du BPM Lifecycle? La partie pratique s intéressera dans un premier temps au contexte particulier d une entreprise active dans l industrie horlogère et aux besoins qui motivent une approche processus. Une fois cela défini, il sera possible de modéliser le processus d export avec BPMN 2.0. Cette modélisation amènera à l implémentation d un prototype de processus dont les résultats et la description des limitations serviront à une prochaine itération du BPM Lifecycle qui aura pour objectif une implémentation fonctionnelle. Ces tâches seront réalisées avec le concours de la solution BPMS préalablement retenue. Introduction 9

11 1.3 Méthodologie Les questions de recherche de la partie théorique seront traitées de manière scientifique en faisant référence à de la littérature spécialisée, à des sources académiques et des sites internet de référence. Les concepts seront illustrés à l aide de figures qui seront soit issues des sources, soit réalisées dans le cadre du travail. La partie pratique sera l occasion de vérifier les hypothèses retenues et formulées dans la partie théorique. La partie pratique sera illustrée par des diagrammes de modélisations et des copies d écran des interfaces de configuration. Ces illustrations permettront au lecteur de se figurer de manière visuelle les enjeux liés au passage de la théorie au concret. 1.4 Public cible Ce travail a été écrit avec la volonté de s adresser aux personnes pour qui les thèmes de SOA et de BPM représentent une thématique générale de questionnement et qui aimeraient disposer de la base théorique nécessaire pour implémenter dans une organisation de type PME une approche processus par le biais du BPM Lifecycle. Ce travail part d une approche fondamentale des SI. De la sorte, il permettra au décideur de PME qui n est pas spécialiste des problèmes d architecture des SI de pouvoir les appréhender sans grands prérequis. Il lui servira ensuite à formuler son opinion sur l éventuel recours aux concepts de SOA et de BPM dans son organisation. Introduction 10

12 2 L ENTREPRISE ET LE SI Sous ce point, la question de recherche suivante sera abordée : «pourquoi un SI est-il un élément essentiel d une entreprise et particulièrement, de sa stratégie?». Afin de répondre à cette question une définition des concepts fondamentaux y sera proposée. Celle-ci servira de base pour s intéresser aux types que peuvent prendre les SI dans une entreprise. Ces typologies vont amener à traiter la seconde question de recherche, s interrogeant sur «pourquoi le concept d architecture des SI a-t-il émergé comme une nécessité?». 2.1 Définitions SYSTÈME D INFORMATION Pour définir un système d information, il convient d abord de s intéresser à la notion de système. On peut définir un système comme étant un «ensemble d'éléments considérés dans leurs relations à l'intérieur d'un tout fonctionnant de manière unitaire» (Larousse, 2012). Le fonctionnement d un système implique des flux qui sont des inputs et des outputs. Les premiers rentrent dans le système et sont traités par celui-ci. Les seconds ressortent du système et sont la conséquence du traitement de celui-ci. Ce fonctionnement est illustré à la Figure 1. FIGURE 1 : FONCTIONNEMENT GÉNÉRIQUE D UN SYSTÈME Cette approche est dite celle de la boîte noire, soit une approche où l on s intéresse uniquement aux liens entre les systèmes. Or il est aussi possible de considérer qu un système se décompose en sous-systèmes qui vont s occuper du traitement de l information. Cette vision est appelée boite blanche. Elle est illustrée par la Figure 2 ci-dessous. L entreprise et le SI 11

13 FIGURE 2 : DÉCOMPOSITION EN SOUS-SYSTÈMES Il est à noter que les liens entre les systèmes, soit les flèches à deux pointes qui relient chaque sous-système sont ici notées comme de possibles interactions. Il serait aussi envisageable que les différents sous-systèmes disposent d un type d organisation qui soit basé sur un nouveau découpage en sous-systèmes, voire en séquence, comme ce sera le cas pour un processus. Le type de système auquel va s intéresser ce travail sera les systèmes dont les inputs et les outputs seront de l information. La notion d information telle qu elle est présente dans ce contexte est tout aussi générique que celle de système. On peut définir l information comme étant «un élément de connaissance susceptible d'être représenté à l'aide de conventions pour être conservé, traité ou communiqué» (Larousse, 2012). Pour définir un système d information (SI) la définition suivante sera retenue pour ce travail : «Un Système d Information (SI) est un ensemble de composantes interreliées qui recueillent ou récupèrent de l information, la traitent, la stockent et la diffusent afin d aider à la prise de décision, à la coordination et au contrôle au sein d une organisation» (Laudon, 2010) Il faut encore opérer une distinction entre un système d information et un système informatique. Le premier regroupe tout ce qui a trait à de l information dans l entreprise tandis que le second concerne l infrastructure technique qui va permettre de traiter cette information. L entreprise et le SI 12

14 2.2 Classification des SI Après avoir vu des définitions concernant les SI de nature relativement abstraite, il faut maintenant s intéresser à la forme que peuvent prendre les SI dans la réalité. Pour cela, une approche présentant des typologies vues dans le cours Systèmes d Informations (Hüsemann, 2012) a été retenue dans ce travail TYPOLOGIE SELON LE NIVEAU DE DÉCISION ET VISION OLAP OLTP On reconnaît dans le management trois niveaux décisionnels qui sont illustrés à la Figure 3. Le but du niveau de décision stratégique est de faire en sorte que l entreprise soit à même de réussir ses objectifs sur une perspective de long terme. Le niveau tactique s intéresse à la mise en œuvre de ressources sur une échelle temporelle moins étendue que celle du niveau stratégique, alors que le niveau opérationnel concerne toutes les décisions qui permettent le fonctionnement à court terme de l organisation. Niveau stratégique Niveau tactique Niveau opérationnel FIGURE 3: NIVEAU DÉCISIONNELS Chaque niveau décisionnel possède des exigences et des besoins en information différents. Ces besoins influencent directement la structuration des SI. Alors que les besoins en informations du niveau stratégique vont tendre vers la consultation de données agrégées, ceux du niveau opérationnel vont privilégier la disponibilité et la vitesse de traitement. Ces deux besoins vont nécessiter la mise sur pied de systèmes de constitutions différentes. Les deux grandes orientations données ici, amènent à la classification qui distingue OLAP (OnLine Analytical Process) et OLTP (OnLine Transactional Process). Cette typologie est illustrée à la Figure 4 ci-dessous. L entreprise et le SI 13

15 FIGURE 4 : OLTP VS OLAP (ZAIAINE, 2013) On remarque dans ce tableau que les exigences ne sont pas les mêmes pour ces deux systèmes. Dans le cas de l OLTP, le défi est de proposer une disponibilité à une multitude d utilisateurs et un temps de réponse qui soit le plus bref possible afin de permettre à l activité de l entreprise d être soutenue le mieux possible par les SI. Dans le cas de l OLAP, c est la quantité de données, sa consultation et sa qualité à soutenir le processus d aide à la décision qui est primordiale. Cette typologie permet de comprendre qu une même organisation peut avoir besoin de systèmes qui sont d une conception différente, car les besoins en information divergent selon le niveau décisionnel. Cette hétérogénéité représente un important défi technique qui devra être traité par la discipline de l architecture des SI présentée au point DÉCOUPAGE FONCTIONNEL D UN SI : MÉTIERS ET BESOINS Le SI d une entreprise est en général composé d applications qui permettent un traitement spécifique de l information, selon les besoins inhérents à un secteur d activité de l entreprise. Ce secteur d activité et de compétence est nommé métier. Une application en charge de la comptabilité va ainsi être conçue pour respecter les règles comptables, tandis qu une application visant à la production aura des règles et une implémentation propre à son domaine. Cette approche permet de réaliser un découpage fonctionnel du SI de l entreprise, c est-à-dire de classifier le SI de l entreprise selon la nature fonctionnelle des applications. Cette démarche est illustrée à la Figure 5. Celle-ci reprend le concept de niveau décisionnel présent à la Figure 3 et procède à une division du spectre décisionnel selon les grandes fonctions de l entreprise. L entreprise et le SI 14

16 FIGURE 5: DÉCOUPAGE FONCTIONNEL (CSB, 2013) Si cette typologie permet de comprendre les besoins hétérogènes en SI en fonction des activités d une entreprise, elle laisse des questions ouvertes. Premièrement, le découpage ici présenté ne tient pas compte qu une même information peut être utilisée par plusieurs fonctions de l entreprise. En effet, si l on prend l exemple d une personne qui est recrutée dans une entreprise, le processus qui va amener à lui verser un certain salaire va concerner autant les ressources humaines, que la finance et la comptabilité. C est ce type de problèmes qui a fait naître les solutions de types intégrées nommées ERP (Enterprise Ressource Planning). Ces solutions ont pour avantage de faire partager la même base de données à toutes les fonctions de l entreprise intégrées dans l ERP. Elles permettent ainsi un partage d une source unique d information qui permet des transactions à travers les métiers. Mais le découpage fonctionnel, même lorsqu il est soutenu par un ERP, pose encore un autre problème. Dans la pratique, les business process d une entreprise sont généralement amenés à changer sans cesse. Or les solutions informatiques et notamment les ERP ont été conçues pour les besoins d une organisation à un moment donné. L éditeur de la solution logicielle va certes proposer de nouvelles versions, mais celles-ci ne seront pas à même de couvrir adéquatement les besoins des organisations. Il faudra alors recourir à des développements spécifiques. Dans ce cas de figure le découpage par fonction des activités de l entreprise et de sa prise en charge peut servir de problème fondateur auquel ce travail va apporter des solutions conceptuelles par les biais de SOA au point 3 et de BPM au point 4. Les deux typologies ici présentées sont des concepts qui peuvent se comprendre de manière complémentaire : la première permet d expliciter un axe vertical qui est lié à la L entreprise et le SI 15

17 hiérarchie des organisations, tandis que la seconde pratique un découpage horizontal du spectre des fonctions de l entreprise. Ensemble, elles permettent de comprendre que les SI et l organisation possèdent un rapport de dépendance réciproque. C est-à-dire que les SI doivent le plus possible être à même de soutenir l organisation et ses processus, l organisation doit quant à elle intégrer les SI dans sa stratégie si elle entend avoir du succès. Afin que cela soit possible, il faudra gérer la structuration des SI par une discipline particulière : l architecture des SI qui est présentée au point 2.3. L entreprise et le SI 16

18 2.3 Architecture des SI DÉFINITION L architecture des SI peut être définie comme une démarche visant à «décrire la structuration d un système informatique en terme de composants, d organisation et de fonctions» (Hüsemann, 2012). Il s agit d une discipline qui a pour objectif de permettre que l interdépendance entre SI et organisation vue au point 2.2.2, amène à un alignement des SI sur la stratégie de l entreprise. Cela tant en considérant les besoins qui émanent de la stratégie, qu en permettant à l organisation de pouvoir intégrer de nouvelles technologiques qui lui soient profitables. L architecture des SI représente une discipline à part entière de l informatique qui est à même de par ses décisions d influencer en totalité l organisation d une entreprise. Cette thèse peut être illustrée par l idée que «ce qu une entreprise fera d ici 2 ou 3 ans, c est ce que son système d information sera capable de faire» (Laudon, 2010). L architecture des SI a recours à des modèles pour décrire la structuration des SI. Le point suivant décrira un des modèles fondateurs de la discipline appelé Le modèle de référence de l urbanisation (Longépé, 2004). Ce modèle a été retenu dans ce travail car il a pour qualité de représenter les SI et la problématique de l architecture SI de manière exhaustive en utilisant l allégorie de la ville UN MODÈLE D ARCHITECTURE DES SI : LE MODÈLE DE RÉFÉRENCE DE L URBANISATION Le modèle de référence de l urbanisation est issu de la théorie de l urbanisation qui compare la problématique de l organisation d un SI à celle de l organisation d une ville, soit le problème traité par l urbanisation au sens littéral du terme. Le SI - tout comme la ville - est susceptible d héberger des services. La ville propose par exemple un service de construction d infrastructures, un service de transport et service un de sécurité. Ceux-ci sont rendus disponibles par celui qui gère la ville à l utilisateur et organisés en couches qui se cumulent. En reprenant cette forme, le modèle de l urbanisation propose une vision de l architecture informatique en 4 couches distinctes. Il est représenté sur la Figure 6. Né dans les années 1990 suite à une prise de conscience du développement chaotique de celui-ci, ce modèle développe une vision en couches de l architecture informatique qui offre une vision holistique du problème architectural, notamment en y intégrant une couche technique, absente de SOA. L entreprise et le SI 17

19 FIGURE 6: MODELE DE L'URBANISATION (JOZWIAK, 2013) La vue métier La vue métier est la partie qui concerne les utilisateurs du système. Elle «recense les événements métiers que l entreprise doit traiter, les processus métiers répondants à ces événements, les documents utilisés dans les processus, en consultant/élaborant les documents» (Fournier-Morel, 2011). Cette première couche du modèle de référence de l urbanisme permet de traiter les besoins en SI de l organisation en analysant les inputs et les outputs ainsi que les acteurs et les règles de décision présentes en son sein. L entreprise et le SI 18

20 La vue fonctionnelle La vue fonctionnelle «décrit les fonctions du système d Information, telles qu on les décrit dans un cahier des charges en vue de la mise en œuvre d une nouvelle application» (Fournier-Morel, 2011). Il s agit donc d une couche qui interface le fonctionnement de l entreprise et l informatique à proprement parler en traduisant la logique de l entreprise en logique informatique. Cette couche représente SOA dans le modèle de l urbanisation. Les fonctions étant les services. La vue applicative La vue applicative s intéresse à décrire les fonctions logicielles qui sont présentes dans l entreprise et qui servent aux deux couches supérieures. La problématique de cette couche sera donc le développement logiciel et la programmation d éléments informatiques à même de s agréger en fonctions dans la couche supérieure. La vue physique La vue physique décrit les composants (ordinateurs, routeurs, imprimantes, etc.) qui constituent l infrastructure sur laquelle les trois niveaux précédents s exécutent. Ces éléments sont garants de la performance générale d un SI en termes de disponibilité et de capacité. Leur considération est donc des plus importantes, notamment selon le type du SI développé (voir 2.2.1). Limites du modèle La vision en couches offerte par l urbanisation aura permis de réaliser une abstraction des systèmes d informations qui aide à maîtriser leur niveau de complexité élevé. Mais de l avis de Fournier-Morel cette démarche aura surtout amené à «une documentation littéraire de la cible du SI urbanisé qui ne débouchait sur aucune mise en œuvre concrète» (Fournier- Morel, 2011). Pour reformuler, on peut dire que le modèle de l urbanisation aura permis une prise de conscience face aux problèmes rencontrés par l architecture des SI. Son apport se sera limité à la description des problèmes architecturaux et à leur explication. Mais l industrie informatique se devait de répondre avec autre chose que l identification du problème et la description de comment les choses devraient être. Son rôle était de formuler une solution. C est ce qu elle a fait avec SOA. Cette émergence d une solution à la fois conceptuelle et technique est le sujet du chapitre 3. L entreprise et le SI 19

21 3 SOA : EMERGENCE D UN MODÈLE D ARCHITECTURE SI Dans cette partie, la troisième question de recherche est traitée: «En quoi SOA est-elle une architecture de référence à ce jour et quels sont ses principes de fonctionnement?». 3.1 La réponse SOA MOTIVATION ET DÉFINITION DE SOA Le concept de SOA qui désigne en français une architecture orientée service est né du besoin de pouvoir gérer l architecture des SI avec plus de souplesse et ainsi permettre un meilleur alignement stratégique des SI. La structuration fondamentale de SOA est d ordre systémique. La définition générale suivante est retenue pour ce travail : «SOA est une forme d architecture technologique qui adhère au principe d orientation service. Lorsqu elle est réalisée par le biais d une plateforme de web services, SOA parvient à soutenir et promouvoir l orientation service au sein des business process et domaines d automation d une entreprise.» (Erl, 2005) Cette définition permet de comprendre que SOA est avant tout un concept de structuration des SI. Son adoption va donner aux SI une forme particulière qui sera la conséquence d une réorganisation des fonctions informatiques qui est illustrée à la Figure 7. Sur celle-ci on peut constater que si le modèle de l urbanisation et notamment sa représentation visible à la Figure 6 s était intéressé à la structuration verticale du SI en couches, SOA va intégrer des concepts de structuration horizontale en utilisant l approche d orientation service et d autres principes qui seront décrits sous le point 3.2. Il faut aussi remarquer à ce stade que cette description représente un état idéal qui a vu la totalité des fonctions de l entreprise obéir à SOA. Dans la réalité, SOA doit notamment son succès au fait qu il est un projet qui se réalise progressivement. La Figure 7 à droite représente schématiquement le degré idéal de structuration SOA. Dans la réalité la plupart des entreprises qui intègrent SOA se trouvent à quelque part entre la situation décrite à gauche et la situation idéale. Afin de situer le niveau d intégration de SOA dans une entreprise, il est possible de recourir à un outil intitulé le SOA Maturity Model (BPtrends, 2007). Le sujet n étant pas l intégration SOA, mais celle d un processus, ce modèle ne sera pas décrit ici. SOA : Emergence d un modèle d architecture SI 20

22 FIGURE 7: AVANT ET APRÈS SOA (TRIDENS, 2011) Si SOA est un concept de structuration des SI, son intégration va nécessiter le recours et l acquisition d infrastructures techniques. Le présent travail ne traitera que de manière sommaire ces infrastructures car elles sont intégrées dans des solutions distribuées par des éditeurs informatiques. En revanche, les composants structurels de SOA et les standards des web services qui permettent un échange d information entre les constituants de SOA et l extérieur du système seront traités sous le point 3.3. SOA : Emergence d un modèle d architecture SI 21

23 3.2 Les principes conceptuels de SOA Les principes conceptuels ici exposés sont ceux présentés dans l ouvrage de Thomas Erl (Erl, 2005). Ils ne sont pas présentés à titre exhaustifs, mais avec l intention de décrire le comportement et les propriétés d un système qui se revendique être une SOA ORIENTATION SERVICE Un service peut se définir en informatique comme «[ ] une fonctionnalité ou partie de fonctionnalité offerte (ie mise à disposition) par un composant logiciel pour assurer une tâche particulière.» (Wikipedia/Service, 2012). Un service fait appel à une logique de type client-serveur où le client consomme le service et le serveur le met à disposition. Entre le client et le serveur se trouve une interface, soit un moyen standardisé d accéder au service qui est toujours le même pour le client et qui respecte le principe d encapsulation. C est-à-dire que le client ne doit pas savoir comment le service est implémenté pour l utiliser. Il doit savoir où il se trouve et quels paramètres il doit lui donner pour l utiliser. Entre le client et le serveur, les interactions se font par le biais d un contrat, c est-à-dire d une description de ce que chaque partie (client et serveur) doit faire. L orientation service consiste à décrire la disposition de tous les éléments du système à tendre vers cet état de fait. Toute fonctionnalité logicielle de SOA repose sur ce principe. Un service permet aussi une abstraction de l implémentation. C est-à-dire que l utilisateur n a pas besoin de connaître la nature de l implémentation pour accéder au service. Le principe de base d orientation service est fondateur, dans le sens où il permet l existence des principes de modularité, de réutilisation et de couplage faible MODULARITÉ ET COMPOSITION DES SERVICES Une architecture SOA dans son ensemble est une composition de modules. Ces modules sont en fait tous des services qui ont la capacité de s agréger en des fonctionnalités plus étendues. Chaque module possède les deux propriétés fondamentales suivantes : Il est un service qui est accessible par son interface. Il peut être composé d une ou de plusieurs unités. La modularité et la composition des services sont des principes essentiels à la mise sur pied d une architecture. Leur recours amène à des problèmes de structuration qui peuvent faire intervenir des patterns de structuration qui vont permettre la création de services dans les différentes couches d une SOA (voir 3.3.1). SOA : Emergence d un modèle d architecture SI 22

24 3.2.3 RÉUTILISABILITÉ Les applications rendues possibles par SOA reposant sur la composition de services peuvent servir de base pour réaliser de nouvelles fonctions. L utilisation d éléments déjà existants permet de tirer profit au maximum d une réalisation générique des modules : c est le principe de la réutilisabilité COUPLAGE FAIBLE Derrière le principe de couplage se trouve l idée suivante : un module ne doit pas être trop interdépendant des autres. De la sorte, il peut facilement être remplacé par un autre en cas d indisponibilité de service. Le couplage faible permet aussi de respecter le principe d orientation service. Il permet de rendre l accès à un service, sans que l utilisateur doive se préoccuper de son implémentation PROMOTION DE L AGILITÉ L agilité qualifie une entreprise qui «s adapte rapidement aux changements et aux opportunités d affaires et qui améliore de manière continue l optimisation des coûts, de la qualité et la vitesse de livraison.» (Cummins, 2009). SOA n est pas uniquement compatible avec l agilité. Elle propose d être un moteur d implémentation de ce concept dans toute l organisation VALORISATION DES SYSTÈMES DÉJÀ EXISTANTS La démarche SOA n est pas une démarche ex nihilo. Le recours à SOA peut se faire en utilisant les fonctions déjà présentes dans l entreprise dont le fonctionnement est jugé adéquat. SOA permet de valoriser ces systèmes en les intégrant, en les faisant communiquer avec d autres fonctionnalités et en leur permettant de devenir évolutifs grâce à une interface qui standardise leur accès par le biais de l orientation service. SOA : Emergence d un modèle d architecture SI 23

25 3.3 Les composants et standards de SOA NIVEAUX DE SERVICE DE L ARCHITECTURE SOA Le concept d orientation service décrit au point concerne tous les éléments de l architecture SOA. Mais ce concept est soumis à un principe d organisation interne de SOA : les niveaux de service (Erl, 2011). Cette logique d implémentation peut être expliquée avec un modèle qui empreinte la forme de couches du modèle de l urbanisation (voir 2.3.2) et qui est illustré à la Figure 8. FIGURE 8: COUCHES SOA (ERL, 2005) Le business process layer Il s agit du niveau qui concerne l exécution des processus au niveau des fonctions de l entreprise. Son rôle est de mettre à disposition de l organisation des processus composés par les fonctions de l entreprise. Il peut s agir à la fois de processus internes, mais ceux-ci sont souvent instanciés par des end-to-end process, c est-à-dire des processus qui SOA : Emergence d un modèle d architecture SI 24

26 traversent l entreprise en entier et qui atteignent le client à la fin. La forme constituant ces processus est sujette à un changement continu car elle est directement reliée à la manière dont l organisation crée de la valeur. C est ici dans SOA que la problématique de l architecture des SI rencontre celle des business process et qui avait été identifiée au point de ce travail. L abstraction du business process layer permet donc aux personnes du business de penser et d organiser les processus qui concernent le modèle d affaire de l entreprise, avec des outils conceptuels et particulièrement ceux offerts par le BPM. Ces outils seront décrits dans le chapitre 4. Le service interface layer Le service interface layer est un niveau d abstraction de SOA dans lequel a lieu la composition des services. Cette composition de service commence par l établissement de services de bas niveau qui soient les plus génériques et réutilisables possibles. Ensuite, ceux-ci sont agrégés en fonctions opérationnelles au niveau du business service layer. On distinguera les trois sous niveaux suivants : o o o Le niveau application service layer qui interface les applications issues de la couche applications. Cet interfaçage permet d utiliser les applications indépendamment de leur nature et leur implémentation. Elles permettent ainsi d utiliser les fonctionnalités de l application de SOA. Le niveau de composition qui va être garant que des services génériques soient développés dans la SOA, afin de s assurer un niveau de modularité qui permette une réutilisabilité la plus large possible. Le niveau d orchestration va quant à lui s assurer que les services soient appelés de manière cohérente pour s offrir à la couche processus. Il est à noter qu il existe plusieurs niveaux d orchestration. Un niveau technique qui a lieu dans la couche de service et un niveau métier qui a lieu au niveau du business process layer. Il est à noter que les niveaux qui sont ici décrits représentent des niveaux conceptuels et qu une implémentation de la couche service pourra, selon les besoins et les choix faits par l architecte, utiliser plus ou moins un niveau de service, voire ne pas distinguer les trois souscatégories ici. On remarquera aussi que pour réaliser la couche service, il peut être nécessaire de créer une plateforme technique qui soit dédiée à l exécution de services. Celle-ci prend le nom d ESB (Enterprise Bus Service). Elle est une importante constituante technique d une architecture SOA. La description de son fonctionnement ne fera toutefois pas partie de ce travail. SOA : Emergence d un modèle d architecture SI 25

27 Le niveau application Le niveau application est constitué de fonctions informatiques exploitables par les couches supérieures. Il s agit de l input du service layer. La nature selon laquelle sont constituées les applications va fortement influencer le besoin de traitement de celles-ci par le service interface layer UTILISATION DES WEB SERVICES Si «SOA est une approche d architecture et ne fait pas d hypothèse sur la technologie mise en œuvre» (Fournier-Morel, 2011), il existe une technologie qui dispose de spécification particulièrement adaptée à SOA. Il s agit des web services. Le principe des services web est de proposer un service à distance par le biais d une relation client serveur. Cette relation est rendue possible par l utilisation d un format d échange de documents qui soit clair tant pour le client que le serveur. Il s agit généralement de la technologie XML qui est utilisée. La première génération de web services XML-RPC (extensible Markup Langage - Remote Process Call) a vu le jour en Comme sa dénomination l indique, il s agit d une technique d appel de procédure à distance utilisant le format XML. Si cette norme considérée comme désuète est ici mentionnée, c est que le système ERP (Open ERP) de l entreprise qui sera l objet de la partie pratique est basé sur ce format d échange au niveau de son organisation interne. Dans ce travail, c est une nouvelle génération de web intitulée WS*- qui va être utilisée. Celle-ci désigne des services web qui respectent les spécifications WS-*, soit un standard défini par le W3C (World Wide Web Consortium). Les principales normes qui permettent l échange d information et l exécution de processus seront traitées ici UN FORMAT PILIER : XML Le XML (exchange Markup Langage) est le format des messages et des normes dans le monde des web services. Il s agit d un format générique qui est extensible dans des syntaxes propres à n importe quelle utilisation. Il est composé des balises qui sont contenues entre < > et qui sont paramétrables. Le paramétrage de celles-ci se fait par le biais d un XML-Schema. Celui-ci est toujours décrit dans l en-tête sous forme d une URL qui l héberge. Lui-même contient un XML Schema. La Figure 9 permet de voir un fichier XML associé à son XML Schema. On voit dans celle-ci que les champs sont créés dans le XML Schema, avec la balise <xs : element /> et que ceux-ci sont repris dans le fichier XML avec la syntaxe de balise suivante : <nom></nom>. SOA : Emergence d un modèle d architecture SI 26

28 Le fichier XML fait quant à lui référence au fichier XML Schema dans son entête par le biais de la balise <personne xmlns :xsi=url xsi :.../>. FIGURE 9: XML SCHEMA AVEC FICHIER XML (WIKIPEDIA, 2012) ECHANGE DE MESSAGES AVEC SOAP Le web service SOAP (Simple Object Access Protocol) est un protocole qui gère l échange de messages entre les composants d une SOA. Il permet la standardisation des échanges dans des infrastructures informatiques qui disposent d interfaces de sécurité. Les messages SOAP peuvent utiliser divers protocoles de transports tels que HTTP, mais aussi SMTP, FTP et d autres protocoles d échanges présents dans la couche application du modèle OSI (Tannenbaum, 2008). Les messages représentent une enveloppe composée de deux parties : Le HEADER qui est composé des informations nécessaires au traitement de données ; le BODY qui, lui contient les données elles-mêmes sous une forme propre au service invoqué et à l exécution de ce dernier. Il est possible d apercevoir deux fichiers SOAP constitués d une requête simple et de sa réponse par le service invoqué à la Figure 10. On notera dans les balises XML les balises : <?xml version > qui définit le recours au format XML et ses paramètres. <SOAP-ENV : Envelope> </SOAP-ENV : Envelope> qui contient une suite de métadonnées nécessaires au traitement du message, ainsi que le Body. <SOAP-ENV : Body> </SOAP-ENV : Body> qui contient les informations à proprement parler du message. SOA : Emergence d un modèle d architecture SI 27

29 On notera que la requête et la réponse respectent strictement les mêmes balises. FIGURE 10: REQUÊTE ET REPONSE SOAP SIMPLE (QUAINE, 2012) WSDL Si SOAP gère la standardisation des communications entre deux entités dans une relation client serveur, il ne prend pas en charge le traitement des informations au niveau du service à proprement parler. C est la norme WSDL (Web Service Description Langage) qui va s en charger. Celle-ci propose de définir «un contrat qui définisse le fonctionnement technique du service web en termes d opérations, de paramètre et de typage» (Fournier-Morel, 2011). Comme cela est illustré à la Figure 11, WSDL prend la forme d un fichier XML qui régit les échanges entre le client et le service provider. FIGURE 11: FONCTION DE WSDL (HAAS, 2012) SOA : Emergence d un modèle d architecture SI 28

30 Le fichier WSDL, décrit à la Figure 12, définit un service qui implémente un contrat de service. Celui-ci est constitué de deux types d informations. Les informations de type abstraites qui sont relatives à l interface et indépendantes de la technologie et les relations de type concrètes qui sont quant à elles, relatives à l implémentation concrète du service. Le contrat de service sera très important dans la partie pratique de ce travail lorsqu il s agira d implémenter un web service par le biais du BPMS. Cette norme joue aussi un rôle primordial dans l avènement du BPMN 2.0 comme un langage d exécution (voir 4.4.3). FIGURE 12: FORME D'UN DOCUMENT WSDL (IBM, 2012) UDDI SOA promeut la découverte des services de son architecture. UDDI (Universal Description, Discovery and Integration) est une norme qui permet la mise sur pied d un annuaire de services. Son implémentation, décrite à la Figure 13 est basée sur l utilisation de SOAP et de WSDL. Le premier va permettre la communication avec l annuaire et le second servira à la description des services disponibles. FIGURE 13: IMPLÉMENTATION DE UDDI (KRAWLER, 2009) SOA : Emergence d un modèle d architecture SI 29

31 3.3.7 BPEL Si SOAP, WSDL et UDDI sont des normes fondamentales qui offrent des standards de communication fondamentaux à SOA, il reste un service de la norme WS-* qui doit être mentionné ici car il est spécialisé dans ce qui est l objet d implémentation de ce travail. Il s agit de BPEL (Business Process Execution Langage). BPEL est un service spécialisé dans l exécution des business process. Basé sur la norme XML, il permet d exécuter des fonctions successives en régissant leur appel, les éventuelles conditions et les séquencements. Il ne sera néanmoins pas utilisé dans ce travail car l avènement d une norme telle que BPMN 2.0 qui sera décrite au point 4.4 et qui permet à la fois la modélisation et l exécution n a pas rendu son recours pertinent. Toutefois, de nombreuses solutions SOA et BPM l utilisent encore pour instancier des processus. Les solutions se chargeant de transformer par un fonctionnement complexe des graphiques de modélisation en fichiers BPEL exécutables. SOA : Emergence d un modèle d architecture SI 30

32 4 BPM : GÉRER L ORGANISATION PAR LES PROCESSUS 4.1 Bases conceptuelles Au point 4.1, la question de recherche se demandant «Qu est-ce que BPM, pourquoi l utiliser?» sera traitée DÉFINITION Pour Gartner, le Business Process Management (BPM) est «une discipline du management qui traite des business process à titre d actifs qui contribuent directement à la performance de l entreprise par le biais d excellence opérationnelle et d agilité» (Gartner, 2013). En prêtant attention à cette définition, on constate qu il s agit donc d une approche qui considère l entreprise dans son entier sous le prisme des processus. Qu ils soient définis comme des actifs leur donne la qualité d être les moyens mis à disposition du management pour réaliser une performance économique. En devenant ces moyens, ils deviennent donc aussi les variables de décision par lesquelles une entreprise va être capable de maximiser la valeur qu elle pourra générer. En parlant d excellence opérationnelle et d agilité, cette définition donne aussi une direction aux objectifs managériaux pour faire du BPM une approche à même de faire performer l entreprise d un point de vue économique. On notera que le concept de BPM a une qualité holistique : en effet, c est l organisation dans son entier qui est vue par le biais des processus et non pas une partie de cette dernière. En considérant les processus, le management considère toute sa structure et peut réfléchir à l organisation de celle-ci en termes de totalité, même si son action pourra par la suite ne concerner qu une sous-partie de l organisation HISTORIQUE Pour expliquer dans quel contexte l approche BPM a éclos, il est nécessaire de faire un détour par l histoire de la théorie des organisations. Susan Morley considère que l approche BPM doit son existence à 4 sources principales (Morley, 2011) qui sont reprises et dont elle a de chacun hérité d un concept. La première de ces sources est le Just in Time (JIT) développé dans l industrie japonaise dans la première moitié du XXème siècle. Cette théorie qui veut que la production d un produit succède à la commande et ne génère pas de stock a été la première à considérer le liage des besoins entre consommateurs et producteurs. Un élément essentiel de BPM, puisque dans cette théorie, c est la satisfaction finale du client qui influence l exécution de la totalité du processus. BPM : gérer l organisation par les processus 31

33 On doit la seconde influence conceptuelle au Total Quality Management (TQM). Celui-ci va généraliser le concept du next step is a customer qui signifie que chaque tâche est cliente de la précédente. De la sorte, il va permettre un liage entre les tâches avec un mécanisme rétroactif en cas de plainte de la part du client sur un défaut et un concept qui va permettre au processus d être trans-organisationnel. Etant donné que le lien de clientèle est entre chaque tâche, le passage d une organisation à l autre pour un processus n est pas de nature différente. La troisième influence est celle de la comptabilité analytique qui, dans les années 60, a mis en exergue la limite d une vision hiérarchique de l organisation découpée en sous unités ou en métiers (voir Figure 5) dans leur contribution à créer de la valeur et qui, elle aussi fera naître le concept de chaîne de valeur, soit un ordonnancement de processus créant un produit qui parcoure l organisation de manière transversale. Enfin, le process re-engineering proposé par Hammer et Champy, notamment au travers de leur ouvrage Reengineering the Corporation: Manifesto for Business Revolution (Hammer&Champy, 2003) va faire de la notion de processus l élément clé pour repenser une organisation. C est de cette dernière démarche que naîtra ensuite un certain nombre d outils et de méthodes que l on identifie désormais comme faisant partie du BPM LE BUT DU BPM : L AGILITÉ La pratique du BPM n est en soi pas une finalité. Il s agit d un ensemble de moyens mis en place pour permettre à une entreprise de devenir agile. Par agilité, on entend «une qualité qu une entreprise possède lorsqu elle est capable de s adapter rapidement à un environnement d affaires changeant tant au niveau des défis que des opportunités. Il s agit d une démarche d amélioration continue qui optimise les coûts, la qualité et les délais de livraison. Elle implique le top management de l entreprise afin d implémenter très rapidement les nouvelles stratégies et de contrôler les variables clés du modèle d affaire, ceci dans le but d obtenir un avantage concurrentiel» (Cummins, 2009). Cette définition permet de comprendre que l agilité est un défi. Un défi qui demande à la fois une compréhension de la part du management et son implication jusque dans les plus hautes sphères de la direction. Mais pour pouvoir modifier les processus au besoin, il faut aussi compter sur des outils qui permettent le changement et le déploiement de l agilité, ainsi que sur une infrastructure du SI qui rende possible ces changements organisationnels. Comme cela été vu dans le point 3, SOA possède les caractéristiques pour supporter un changement grâce à ses propriétés fondamentales. Quant à l intégration de l agilité dans l organisation, celle-ci se fera grâce aux outils BPM présentés à la suite de ce travail. BPM : gérer l organisation par les processus 32

34 4.2 BPM Lifecycle Le point 4.2 répondra à la question de recherche se demandant «En quoi le BPM Lifecycle est-il un concept qui permet à l entreprise de gérer ses processus et de les améliorer?» CONCEPT GÉNÉRAL Le BPM Lifecycle est une méthodologie dérivée de l approche PDCA (Plan-Do-Check- Adjust). Elle recourt au concept d itération qui implique que l exécution de la dernière phase donne lieu au retour à la première phase du cycle. Les auteurs qui écrivent sur le BPM ont plusieurs interprétations du BPM Lifecycle. Celle qui sera utilisée dans ce travail est celle exposée par Michael Hammer dans l ouvrage Handbook on Business Process Management I (Brocke & Rosenmann, 2009). Elle est constituée de 5 phases distinctes dont la Figure 14 décrit le séquencement. Chaque phase va faire interagir des acteurs différents et va amener au traitement de tâches spécifiques. L étude distincte de chaque phase sera l objet des points et suivants. Sa qualité de standard est perceptible au fait qu il est devenu un outil commun pour les personnes en charge de la gestion des processus. Le recours au BPM Lifecycle est donc garant d une gestion des processus qui soit à la fois intelligible pour tous les acteurs et standardisée au niveau de la méthode de projet. Goal Specification / Strategy Definition Process Improvement Process Design Process Runtime Process Implementation FIGURE 14: BPM LIFECYCLE BPM : gérer l organisation par les processus 33

35 4.2.2 LA PHASE GOAL SPECIFICATION / STRATEGY DEFINITION La phase Goal Specification / Strategy Definition est la première phase du BPM Lifecycle. Elle implique deux impératifs pour le management. En premier lieu, l instance dirigeante doit être capable de définir un but que l organisation entend atteindre. Pour cela, elle se doit de procéder à une réflexion sur la valeur attendue par le client quant aux prestations ou produits qu elle est à même de lui livrer. En parallèle, elle devra définir comment atteindre ce but : c est l objet du Strategy Definition. Ces deux inputs devront ensuite être mis en forme pour être transformés en réalité. Il faudra donc penser aux moyens à allouer au projet, à la planification aux rôles à donner aux différents acteurs et définir en termes très clair le but poursuivi par le projet et la forme qu il doit prendre. La bonne exécution de cette phase est capitale pour que la suite de projet puisse se dérouler dans les meilleures conditions. En vertu du concept d agilité défini au point 4.1.3, c est en impliquant le plus tôt possible le top management dans des décisions qu il sera possible d atteindre les meilleurs résultats. Il est à noter que la première phase du BPM Lifecycle est dans les faits rarement la première à être utilisée dans un projet concernant un processus. Elle ne l est que lors de la première itération sur un projet de processus. Elle sera, dans les itérations suivantes, consécutive à la phase de Process Improvement LA PHASE DESIGN La phase de design peut être considérée comme une phase intermédiaire entre le Plan-Do du modèle PDCA. Elle va transformer les besoins du management en une représentation abstraite des tâches et des séquencements nécessaires à l exécution du processus. Cette phase, mise sous la responsabilité de spécialistes appelés business process analysts est absolument nécessaire pour définir un modèle qui soit à la fois compréhensible de la part du management, des acteurs et des utilisateurs du processus ainsi que des informaticiens et spécialistes métiers. Le but de la phase design est donc de proposer une modélisation du processus qui soit «un même langage» pour tous les acteurs du projet et qui garantisse à chacun d entre eux que les aspects importants relatifs à leurs fonctions y soient mentionnés. Pour parvenir à ces fins, le recours à un langage de modélisation est une nécessité. Le langage BPMN 2.0 (voir 4.4) est un standard reconnu et partagé et sera utilisé dans ce travail. Il permet de définir et de représenter : Les acteurs du processus ; Les opérations selon leur type ; Les types d interactions entre les acteurs ; BPM : gérer l organisation par les processus 34

36 Les séquences et les éventuelles conditions. Par ce biais, il sera question de déterminer un processus qui soit optimal, tenant compte des limitations en termes de ressources et des conditions d optimalité exprimées dans la phase 1 du BPM Lifecycle LA PHASE IMPLEMENTATION La phase d implémentation est consécutive à celle de design. Elle a pour objectif de faire des spécifications et du concept de processus développé lors du design une réalité qui met en œuvre les ressources de l organisation délivrant de la valeur. Ces ressources peuvent être de différentes natures. On notera deux grands types : les ressources humaines et celles qui sont intégrées dans le SI de l entreprise. L implémentation d un processus consiste à la fois en l exécution de tâches selon la séquence donnée du processus, mais aussi en la mise sur pied des interfaces qui vont permettre aux utilisateurs de lancer le processus et d interagir avec le SI. Une implémentation de processus va se faire par le biais d un logiciel spécialisé dans la gestion de processus qui soit à même d appeler des tâches et les exécuter selon la description donnée par la modélisation. Afin de rendre possible l exécution successive des tâches, le paradigme de l orientation service sera alors requis. Chaque tâche devenant un service qu il est possible d appeler par son interface. Ainsi, les fonctions informatiques et les acteurs du processus seront appelés à agir selon les principes de SOA. La propriété d orientation service des services utilisés sera promue par le Service Layer (voir 3.3.1) et si cela est nécessaire techniquement par la présence d un ESB. Il existe plusieurs bases technologiques pour l exécution de processus. Comme cela a été vu au point 3.3.7, BPMN 2.0 sera la norme utilisée pour ce travail LA PHASE DE PROCESS RUNTIME Une fois le processus implémenté et rendu exécutable, vient le temps pour le processus de devenir une réalité dans l organisation dans laquelle il existe. Cette réalité prend forme avec des ressources informatiques mobilisées sous la forme d interfaces visuelles qui permettent l interaction avec le processus, la formation d utilisateurs et le monitoring du processus pour s assurer de son bon fonctionnement. Ce monitoring est aussi réalisé dans le BPM. En plus du monitoring des ressources, il est nécessaire d appliquer une métrique de performance au processus pour s assurer qu il est optimal et qu il corresponde aux attentes formulées dans la première phase du BPM Lifecycle. Pour se faire, le recours à des KPI (Key Performance BPM : gérer l organisation par les processus 35

37 Indicators) est nécessaire. Ces KPI sont à mettre en lien avec le BPMM et particulièrement le niveau 4 de BPMM qui est défini au point Il est aussi à noter que si l entreprise veut s inscrire dans une démarche processus de long terme, il sera extrêmement important durant cette phase de s assurer que les utilisateurs font une expérience optimale du processus tel qu il est développé et que leurs remarques puissent-être saisies et intégrées par le biais de la dernière phase du BPM Lifecycle qui sera le sujet du point suivant LA PHASE DE PROCESS IMPROVEMENT Une fois le processus exécuté au sein de l entreprise, il faut encore s assurer de son suivi, et notamment de s assurer qu il desserve toujours le modèle d affaire. Si le processus devait devenir désuet et ne plus correspondre aux besoins et s il devait s avérer ne plus être optimal d un point de vue économique, ce serait alors à la phase du process improvement de gérer les améliorations possibles. Si l exécution des 4 phases précédentes est à même de garantir que le projet se déroule le mieux possible et selon des responsabilités et des rôles établis, elle ne peut en aucun cas garantir que le résultat soit parfait, ni même suffisant par rapport à ce qui a été défini par l organisation. La dernière phase est garante qu il soit possible de reprendre un projet peutêtre imparfait, mais elle permet aussi de réaliser des itérations plus courtes qui peuvent permettre de montrer plus rapidement des résultats sur lesquels un retour de la part du maître d ouvrage soit celui qui est à l origine du projet et des besoins est possible. BPM : gérer l organisation par les processus 36

38 4.3 BPMM Le point 4.3 répondra à la question de recherche suivante : «Comment le niveau de sensibilité d une organisation aux processus peut-il être évalué et amélioré?» CONCEPT Le BPMM (Business Process Maturity Model) «est une norme définie par l'object Management Group (OMG) qui propose de fournir une grille d'analyse de la maturité des processus métier d'une entreprise.» (BPMS Maîtriser la complexité, 2012). Cette norme est définie par l OMG, soit la même organisation qui définit BPMN 2.0. Les deux concepts sont ainsi compatibles et complémentaires. Le recours à cette norme permet de disposer d un standard pour juger du niveau de conscience et d importance donnée aux processus dans une organisation. Les différents niveaux de la norme seront exposés ci-dessous. Sa spécification utilisée ici pour décrire les 5 phases constitue le document BPMM Specification disponible sur la page du site OMG (OMG, 2013). Il existe des Maturity Models dans de nombreux domaines de la gestion d entreprise et le point a été l occasion de mentionner celui dévolu à SOA. Dans ce travail, la présentation d un tel modèle pour les processus a été retenue car les processus et leur gestion représentent la cible de ce travail, contrairement à SOA qui a un rôle de participant REPRÉSENTATION DES NIVEAUX Le BPMM est un modèle à 5 niveaux que la Figure 15 présente. Le premier niveau représente le plus faible niveau de prise en compte des processus dans l organisation alors que le niveau 5 représente quant à lui la situation optimale. Chaque niveau porte un nom qui décrit la situation générale des processus. Le passage d un niveau à un autre est possible par le recours à une itération du BPM Lifecycle. BPM : gérer l organisation par les processus 37

39 Level 1 Initial Level 2 Managed Level 3 Standardized Level 4 Predictable Level 5 Optimized FIGURE 15: NIVEAUX DU BPMM NIVEAU 1 : INITIAL Le niveau initial consiste en une situation qui fait des processus une réalité qui n est pas gérée ni contrôlée. Le déroulement des actions dans une entreprise qui a un niveau 1 de BPMM n obéit pas à une définition préalable des processus qui fait l objet d une réflexion, mais à l impératif d exécuter les tâches pour obtenir un résultat qui ne fait pas l objet d une définition préalable. D une manière générale, «la capacité d exécuter un processus est celle des individus et pas de l organisation» (OMG, 2013). Cela implique que si une personne avec une compétence donnée devait quitter l organisation, la compétence au sein même de celle-ci serait perdue et nécessiterait d être à nouveau développée. Comme l exécution du processus est directement liée aux personnes, c est aux qualités intrinsèques de celles-ci que l organisation reconnaît son fonctionnement. On verra alors souvent des situations de crise devoir être gérées par le biais d actions «exercice pompier». A ce niveau, les processus ne sont rarement documentés puisqu un processus repose la plupart du temps sur une seule personne. Et s ils sont documentés, leur exécution ne suit pas ou rarement la description formelle qui en est faite NIVEAU 2 : MANAGED Au niveau 2, il y a une prise en charge des processus, mais celle-ci est locale. Cela signifie que ce sont des cadres intermédiaires, situés entre le top management et le déroulement des opérations qui permettent à leurs subalternes de s organiser et de faire en sorte que les processus suivent une certaine logique. BPM : gérer l organisation par les processus 38

40 Comme la gestion des processus est locale, il n y a pas de guidelines pour toute l organisation. Dans ces circonstances, une prise en charge d une problématique de processus dans un département et une prise en charge dans un autre département de la même problématique pourra donner lieu à deux processus différents pour traiter le même cas. Les considérations pour optimiser les processus portent sur ce qui importe directement au département : des délais, des coûts et des aspects de performance qui sont reliés à l unité organisationnelle qui gère les processus, mais pas pour la totalité de l organisation. Le client final n est pas pris en considération dans l amélioration des processus, en ce sens que les processus choisis ne sont pas end-to-end NIVEAU 3 : STANDARDIZED Il s agit du premier niveau du modèle BPMM où la gestion des processus est pensée pour l organisation en entier. La documentation des processus est réalisée de manière générique afin qu elle puisse-t-être utilisée dans tous les départements de l organisation pour des problèmes donnés et que la solution proposée soit partout de la même forme. A ce niveau, il existe une responsabilité définie dans l organisation qui se charge des processus, de leur application et de leur gestion. Les processus sont organisés selon une typologie qui distingue les processus opérationnels, les processus de soutien et les processus décisionnels. Elle tente de standardiser ceux-ci et de généraliser les processus qu elle identifie comme étant les meilleures pratiques. La gestion des processus fait partie de l organisation et une attention lui est donnée dans l organisation de la vie de l entreprise NIVEAU 4 : PREDICTABLE Au niveau 4, les processus font l objet de métriques. Ces métriques sont garantes du concept de qualité. Il est en effet possible grâce à elles de déterminer un niveau de performance donné d un processus en relation avec un besoin. L existence d une valeur qui soit quantifiable permet d effectuer un controlling des processus et de déterminer les actions correctives qui seront à même d améliorer le processus. (NB : on comprend ici le lien entre la phase Process Monitoring et Process Improvement du BPM Lifecycle). Si ce niveau est appelé «Predictable», c est parce que les processus sont «contrôlés, quantifiés et prévisibles (anglais : predicable) car leur performance est mesurée et opère dans des limites quantitatives» (OMG, 2013). BPM : gérer l organisation par les processus 39

41 4.3.7 NIVEAU 5 : INOVATING LEVEL Le niveau 5 concerne les organisations qui évaluent sur une base constante leur modèle d affaires et les limites inhérentes à celui-ci. De la sorte, elles sont en mesure de proposer des actions sur les processus qui aillent plus loin que la correction des erreurs, mais qui permettent de faire de la maintenance préventive ou qui optimisent la valeur délivrée par le biais de l approche qualité développée dans le niveau précédent. Cet effort a lieu avec le concours de tous les membres de l organisation. Il est un état atteint lorsque l amélioration continue succède à l atteinte des buts de tous les niveaux précédents LIENS ENTRE BPMM ET LE BPM LIFECYCLE Le BPMM décrit des niveaux de prise en charge des processus dans une organisation. Le comportement attendu d une organisation étant ici, si elle veut livrer un maximum de valeur, d évoluer vers le niveau 5. Dans l approche BPM, le BPM Lifecycle est la méthodologie qui va permettre de planifier cette évolution et de maximiser les chances de succès. Mais le BPM Lifecycle concerne habituellement un processus qui peut être à la rigueur composé de sous-processus. Il faudra donc plusieurs itérations de BPM Lifecycle sur un ensemble de processus qui couvrent l entier de l activité de l entreprise pour que l organisation passe d un niveau à un autre. Ce passage ne pourra être assuré par le simple recours au BPM Lifecycle pour chacun des processus. Un intérêt pour la cohésion entre eux et de leur gestion devra être développé. De par ses propriétés, c est ce que propose de faire le BPMM. Il faut toutefois remarquer que le BPMM est un modèle, donc une simplification de la réalité. Cela implique qu il n est pas possible de réduire toutes les situations et toutes les évolutions possibles dans cette grille. On peut voir comme limite le cas où une entreprise produirait un bien qui nécessite une compétence spécialisée dans un processus industriel et que cette compétence soit celle d un corps de métier qui la garde sous la forme de secret. Enfin, le contexte dans une organisation peut ne pas être uniforme. Il sera ainsi possible qu un département intègre très rapidement l approche processus s il se trouve dans une situation critique, alors qu un autre département montre plus de résistance au changement. BPM : gérer l organisation par les processus 40

42 4.4 BPMN 2.0 Sous ce point, la question de recherche suivante sera traitée : «quelles bases conceptuelles et technologiques rendent possible l exécution de Business Process sur une SOA?» AVÈNEMENT DE BPMN 2.0 Un certain nombre de langages ont été développés dans le but de gérer les processus. Historiquement, deux tendances parmi ces langages sont à observer. Il existe premièrement les langages qui servent à la modélisation des processus et ceux qui servent à leur exécution. Le standard WS-BPEL, promu par l OASIS (Organization for the Advancement of Structured Information Standards) a été abordé dans ce travail sous le point des web services (voir 3.3.7) car il respecte les spécifications WS* et il possède notamment un contrat WSDL. Il est utilisé chez les principaux éditeurs de solutions membres de l OASIS. Si ce langage propose des propriétés d exécution qui lui ont valu et lui valent toujours d être massivement utilisé dans l industrie informatique, il n offre en revanche pas de représentation graphique, sa dénomination ayant la forme d un fichier XML. Le langage BPMN (Business Process Model and Notation) est quant à lui une notation qui est née à l initiative de l OMG et qui a pour but d être «une notation qui soit facilement compréhensible pour les business users, les business analysts ainsi que pour les technical developers qui en réaliseront l implémentation technique et, enfin, pour les gens du business qui vont gérer et monitorer les processus» (Krogstie, 2010). Cette notation voulait donc rendre possible la communication entre les différents acteurs de processus, indépendamment de leur rôle, de leur domaine de compétence et de toute notion technique. Cette norme posait toutefois deux problèmes majeurs dans la gestion des processus. Premièrement, une exécution des processus n était pas possible et, ensuite, n étant qu une convention graphique, les formes implémentées dans les différents BPMS pouvaient varier et être incompatibles. Si ce dernier problème a été en partie résolu avec l utilisation d un format standard d échange en XML intitulé XPDL (extensible- Markup Process Definition Langage) qui ne sera pas abordé dans ce travail, une solution de plus large envergure allait être proposée pour éviter de complexes procédures de mapping entre une définition des processus au travers d une modélisation par les acteurs du business et une exécution au sein des systèmes qui allait recourir à WS-BPEL. Ainsi, la version BPMN 2.0 a été rendue exécutable, rendant ainsi possible le passage du process design au process implementation sans qu il faille changer de modèle. La Figure 16 illustre cette propriété fondamentale en montrant l utilisation des normes entre le business et BPM : gérer l organisation par les processus 41

43 le IT avant BPMN 2.0 et tels qu ils sont rendus possibles avec l adoption de la norme. BPMN 2.0 est donc plus qu un langage de modélisation, c est un standard pour représenter les processus et leur exécution. Ces deux fonctions clés seront présentées dans les deux prochains points. FIGURE 16: AVANT ET APRÈS BPMN PRINCIPAUX CONSTITUANTS D UN DIAGRAMME DE BPMN 2.0 Les diagrammes de BPMN 2.0 sont une composition d objets simples qui peuvent être répliqués. Les principaux sont abordés à la suite, il existe un certain nombre de variation des objets. Le layout des éléments présentés est celui proposé par la solution Open Source Bonita qui servira à la partie pratique de ce travail. BPM : gérer l organisation par les processus 42

44 Evènements FIGURE 17: TYPES D'ÉVÈNEMENT BPMN 2.0 Les évènements sont modélisés sous la forme d un point. Ils peuvent prendre plusieurs formes suivant qu ils soient un évènement de départ à la Figure 17 en vert, un évènement intermédiaire en bleu ou un évènement de fin en rouge. BPMN permet aussi de spécifier la nature de l évènement. C est ici les lignes de la Figure 17 qui en recensent les différents types. Un évènement peut être abstrait, il sera alors un point vide, être un message, une minuterie, un signal, une correction d erreur ou un arrêt. Tâches FIGURE 18: TÂCHES BPMN 2.0 Dans BPMN 2.0, les tâches sont les éléments qui nécessitent la mobilisation des fonctions de l organisation. Les actions peuvent être de différents types. Il peut soit s agir de tâches qui sont effectuées par des personnes. On parlera alors de tâches humaines. Si les tâches requièrent l appel d une fonction informatique, on parlera alors de tâche de service. Il se peut aussi qu une tâche soit d un type indéfini. On parlera alors de tâche abstraite. Enfin, il est possible qu un tâche soit elle-même composée de tâches. On parlera alors de sousprocessus. BPM : gérer l organisation par les processus 43

45 Branchements FIGURE 19: BRANCHEMENTS BPMN 2.0 Le chemin que va prendre l exécution d un processus n a pas besoin d être déterminé à son début. Il peut être soumis à des conditions. Pour gérer cela, BPMN 2.0 intègre la notion de branchements. Ceux-ci sont de trois types : les branchements parallèles, les branchements exclusifs et les branchements inclusifs. Les branchements organisent les flux. Ces derniers sont représentés sous la forme d une flèche. Si les flèches sont placées avant un branchement, on parlera du rôle de celui-ci comme d une fusion. Si les flèches sont placées après lui, on parlera de scission. Chaque type de branchement traite différemment ces deux cas de figure. Les branchements parallèles représentés à la Figure 19 sont reconnaissables à la croix perpendiculaire qui se trouve au milieu du losange. Dans une situation de scission, ils permettent à plusieurs flux de se dérouler en parallèle. Dans une situation de fusion, ils attendent que tous les flux rentrant soient terminés pour passer à l étape suivante. Les branchements exclusifs que l on reconnait au X situé au milieu du losange agissent comme un «if» dans un langage de programmation. Ils vérifient une condition et permettent uniquement le choix d un flux en scission. Dans une situation de fusion, ils attendront aussi qu un seul des flux soit terminé pour passer à l étape suivante. Les branchements inclusifs qui sont le dernier type représenté sur la Figure 19 se distinguent par le comportement suivant : à la scission ils permettent soit à un flux soit à plusieurs de se poursuivre, alors qu à la fusion, ils attendent que tous les flux soient terminés pour passer à l étape suivante. BPM : gérer l organisation par les processus 44

46 Pools and lane FIGURE 20: POOLS ET LANES BPMN 2.0 Les lanes représentent un niveau d unité organisationnel dans lequel ont lieu certaines tâches d un processus alors que les pools sont, elles, composées de lanes (voir Figure 20). Alors qu entre deux lanes, la communication se fera par le biais d un flux de séquence, celle entre deux pools se fera par le biais d un flux de message. Ces représentations permettent de faire figurer les impacts organisationnels que peuvent avoir la modélisation de processus EXÉCUTION DE BPMN 2.0 L exécution de BPMN 2.0 répond au défi de proposer une norme qui respecte le concept de model preserving strategy (Swenson, 2009) entre la phase de modélisation et d exécution du BPM Lifecycle. Ce respect a pour conséquence que le modèle défini dans la modélisation n a pas besoin d être retravaillé pour être utilisé dans la phase d implémentation. Deux types d acteurs, soit ceux du business et ceux de la IT, comme illustré à la Figure 16, s évitent non seulement la transition d un langage à un autre qui peut s avérer très lourde en temps et en ressources, mais parlent un langage qui est similaire et de ce fait, peuvent mieux collaborer. Ce n est donc pas que le passage de la phase de design à la phase d implémentation qui est facilité, mais aussi les prochaines itérations du BPM Lifecycle qui pourront compter sur une implémentation de processus qui soit plus facile à comprendre. Afin de rendre BPMN 2.0 compatible avec ce concept, il a été nécessaire d y intégrer des spécifications particulières. Celles-ci qui sont ici reprises du chapitre Make a BPMN 2.0 executable de l ouvrage BPMN Handbook (Shapiro, 2012) sont soit de types conceptuelles, soit inhérentes à l implémentation. Parmi le premier type, l auteur observera qu un respect strict de la syntaxe du langage est nécessaire. Si ce point va amener à une complexification de la modélisation avec BPMN 2.0 puisqu il sera nécessaire de respecter une stricte grammaire, elle permettra à la phase d exécution de disposer des informations nécessaires à l exécution même du processus. BPM : gérer l organisation par les processus 45

47 D un point de vue technique, la norme demande le recours systématique à XML. Par le biais de XML schémas en XSD (voir 3.3.3) qui définissent la forme des modèles, ainsi que par le biais de WSDL (voir 3.3.5), pour l appel de services. Cette dernière norme fait partie des web services. Il est donc intéressant de constater que l exécution de BPMN 2.0 est rendue possible par une approche de standard fort au niveau de sa syntaxe et de sa sémantique, ainsi que par le recours à des normes techniques qui sont constituantes de SOA. BPMN 2.0 n est donc pas un constituant de l approche SOA, mais une norme qui permet une interaction standardisée avec celle-ci. BPM : gérer l organisation par les processus 46

48 4.5 BPMS Le point 4.5 répondra à la question de recherche qui demandait «Quel outil BPMS open source ou en accès libre est-il le plus à même de permettre une modélisation et une exécution de processus?» PRINCIPE Les méthodologies et concepts vus jusqu à présent dans le cadre du BPM offrent une vision qui permet d intellectualiser et de gérer les processus. Mais ce qui rend l approche processus intéressante pour une organisation, c est qu elle est à même de se transformer en réalisation concrète qui s implémente dans une entreprise et qui permette d automatiser certains processus. L industrie informatique a mis sur pied des outils qui permettent de réaliser et d implémenter les différentes tâches que l on retrouve dans le BPM Lifecycle. Ces solutions sont connues sous le nom de Business Process Management System (BPMS). Ces solutions suivent les différentes étapes du BPM Lifecycle et les soutiennent avec des outils relatifs aux différentes phases. Historiquement, ces solutions ont été intégrées dans des plateformes SOA et permettaient ainsi de gérer le business process layer par le biais d une suite logicielle qui respecte les standards SOA. Il s avère qu une entreprise peut aussi avoir besoin de gérer ses processus sans pour autant disposer des ressources et des compétences nécessaires à la création d une SOA au sein de son organisation. Dans la pratique, c est le cas de la plupart des PME. Le BPMS peut alors servir d interface pour connecter plusieurs systèmes ensemble et gérer leurs interactions nécessaires et orchestrer le processus. L intérêt d un tel recours est de rendre la gestion des processus indépendante d une solution de type ERP qui n est pas nécessairement spécialisée dans la gestion des processus, même s il est possible qu en théorie elle offre cette fonctionnalité. Pour se faire, il sera nécessaire d identifier les différentes caractéristiques des outils présents à cette heure sur le marché et de voir lesquels offrent le plus grand potentiel pour la partie pratique de ce travail. Certaines de ces solutions font aussi la promesse du zero code, c est-à-dire de programmer des fonctions informatiques sans avoir recours à une moindre ligne de programmation. Cette notion est intégrée à titre de proposition du vendeur dans le tableau de la Figure COMPARATIF DES OUTILS EXISTANTS Il existe une pléthore de solutions logicielles qui affirment être des solutions BPMS. Si toutes garantissent par le biais de leurs vendeurs une prise en main facile et des résultats BPM : gérer l organisation par les processus 47

49 fulgurants, il peut en être bien autrement dans la réalité. Ce travail a évalué 4 solutions en consultant la documentation disponible sur la solution et en les installant, et pour chacune d entre elles en tentant de modéliser le processus de la Figure 24. Ces solutions ont été choisies en fonction d un critère simple : l absence de coûts de licences pour l utilisation dans ce travail. Si le choix est non exhaustif, il se veut illustratif des différentes tendances présentes sur le marché Nom de la solution Type de licence Qualité de la Orientation BPMN 2.0 Qualité de la Facilité de documentation technique modélisation prise en main Bonita Soft Open Source * Zero code Oui *** *** Xpert.Ivy Propriétaire *** Hybrid Oui ** *** Agiliti 1.4 Open Source *** Orienté Non ** * développeur Processmaker Open Source *** Zero code Non * ** FIGURE 21: TABLEAU COMPARATIF DES OUTILS BPMS EN ACCÈS LIBRE Comme on peut le voir dans le tableau ci-dessus, il n existe pas une solution qui soit supérieure à toutes les autres. En revanche, il existe des critères qui sont quasi éliminatoires chez certaines. Ainsi Agiliti peut s avérer très utile dans le cadre d un développement logiciel basé sur Java, mais il nécessite d importantes bases de connaissances de ce langage pour espérer utiliser des fonctions ne serait-ce triviales. Pour processmaker, c est la qualité médiocre de la modélisation et l impossibilité de pouvoir utiliser certains éléments de BPMN 2.0 comme des lanes qui s est avéré éliminatoire. Parmi les deux solutions restantes, la solution Open Source de Bonita Soft dispose du meilleur outil de modélisation des 4 solutions, elle est en revanche très incomplète en termes de documentation au sujet de l implémentation des processus. Xpert.Ivy possède quant à lui le meilleur rapport entre la qualité de la documentation et la facilité de prise en main, mais offre un outil de modélisation qui est déjà orienté très technique et peut s avérer difficile à utiliser pour modéliser des processus abstraits qui serviraient dans la partie pratique au niveau de la modélisation. Il a été très difficile de procéder à un choix d une de ces solutions compte tenu que chacune comportait un important risque pour la partie pratique. La qualité de modélisation proposée par Bonita a toutefois surpassé les qualités documentaires de Xpert.Ivy, notamment parce qu il était possible de mieux documenter l exécution des processus avec son recours. Mais il s est avéré depuis la sélection des outils en libre accès qu aucun n allait permettre de pouvoir approcher un résultat de prototype qui soit évolué en raison de leur demande d une maîtrise étendue d un langage de programmation ou de leurs lacunes fonctionnelles. BPM : gérer l organisation par les processus 48

50 BPM : gérer l organisation par les processus 49

51 5 PARTIE PRATIQUE : APPLICATION DU BPM LIFECYCLE DANS UNE PME 5.1 BPM Lifecycle Phase 1 : Goal specification / Strategy definition Dans ce chapitre, il sera question de répondre à la question de recherché suivante: «Quels sont les besoins qui vont nécessiter une approche processus au sein de la PME et comment le web service e-dec pourra-t-il participer à celle-ci?» en utilisant la première phase du BPM Lifecycle BUSINESS CASE Partie pratique : Application du BPM Lifecycle dans une PME 50

52 Manufacture (50%) Partie pratique : Application du BPM Lifecycle dans une PME 51

53 FIGURE 23: INCOTERMS Partie pratique : Application du BPM Lifecycle dans une PME 52

54 Partie pratique : Application du BPM Lifecycle dans une PME 53

55 Partie pratique : Application du BPM Lifecycle dans une PME 54

56 5.2 BPM Phase 2 : Process Design La partie 5.2 va répondre à la question de recherche suivante «Quelle forme prendra la modélisation de ce processus avec le standard BPMN 2.0?» DESCRIPTION DU PROCESSUS D EXPORT DU POINT DE VUE DE L ENTREPRISE Le processus d export du point de vue de Hans Werk AG est un sous processus du processus de commande de montre. Celui-ci est décrit à la Figure 24. Il consiste en la collaboration de 4 départements : La vente qui établit les commandes La facturation qui s occupe de traiter les données financières La logistique qui prépare les produits et se charge de l expédition des marchandises et des procédures relatives La production qui crée les produits qui vont ensuite être envoyés et facturés aux clients. FIGURE 24: PROCESSUS DE COMMANDE DANS L'ERP Partie pratique : Application du BPM Lifecycle dans une PME 55

57 La procédure d exportation contrairement aux procédures d établissement de CITES (import + export) et de tâches liées à l import dans le pays de destination possède un grand potentiel de standardisation. Le service d export de Hans Werk AG a toujours affaire au même interlocuteur : la douane Suisse. Actuellement, le processus suit le déroulement décrit à la Figure 25. FIGURE 25: PROCÉDURE D'EXPORT ACTUELLE CHEZ HANS WERK La procédure d export actuelle compte sur le concours de transporteurs pour gérer les interactions avec la douane Suisse. Hans Werk AG n a qu à envoyer les marchandises et il reçoit en retour la DTE (Déclaration Taxation à l Export). Cette pratique est contraire à la volonté de la direction de posséder le savoir-faire lié aux exportations. De plus, elle n assure pas une bonne qualité de traçabilité des cas d export et s avère problématique lors du retour de marchandises qui ont été laissées en vente en consignation, c est-à-dire une vente où le paiement de la marchandise est effectué lors de l achat par le client final. Il est actuellement difficile d assurer la traçabilité de ces envois et d associer l import des montres à leur exportation initiale. Ces situations nécessitent actuellement des heures de travail administratif qui sont assumées au détriment d autres tâches. Le niveau de BPMM de l organisation peut être estimé à 2. Des initiatives locales ont permis la description des processus et leur gestion, mais l entreprise ne dispose pas encore d une stratégie globale des processus ni d une documentation exhaustive DESCRIPTION DU PROCESSUS D EXPORT DU POINT DE VUE DE LA DOUANE SUISSE La solution e-dec est née d un constat. La procédure d export qui prévalait alors, basée sur la RSE (Réglementation Simplifiée sur les Exportations) et soutenue par le système Partie pratique : Application du BPM Lifecycle dans une PME 56

58 informatique MD90 n était plus à même d offrir un fonctionnement efficace au niveau administratif de l AFD (Administration Fédérale des Douanes), ni de s adapter aux évolutions du contexte douanier international qui promeut de plus en plus l échange d information sous format électronique. Afin de pallier à cette situation, la douane suisse a donc décidé de se lancer dans un projet qui permette à la fois d alléger la tâche de l administration en termes de traitement de données en abolissant la saisie manuelle et d échanger facilement des informations avec d autres systèmes informatiques, tout en tenant compte des évolutions futures possibles. Cette solution porte le nom de e-dec. Basée sur une architecture de type SOA, elle met à disposition des déclarants plusieurs canaux pour réaliser les déclarations. L , un web service et un une plateforme web. Alors que le premier médium ne sera pas traité dans ce travail, les deux suivants font l objet d une description ci-dessous WEB SERVICE E-DEC Le web service de e-dec utilisé dans le cas d une déclaration d export fonctionne comme décrit à la Figure 26. Cette modélisation étant une adaptation en BPMN 2.0 de celle du document Manuel e-dec exportation pour la clientèle externe et les entreprises ((AFD), 2012) qui utilisait le langage UML. FIGURE 26: FONCTIONNEMENT DE E-DEC EXPORT DU POINT DE VUE DE LA DOUANE Partie pratique : Application du BPM Lifecycle dans une PME 57

59 Il est à noter qu une prise en charge du web service e-dec par le système du déclarant est un prérequis s il veut éviter une rupture de média. Son SI doit donc être à même de faire appel au service e-dec et aux technologies qui y sont inhérentes et qui ont notamment été décrites dans ce travail au chapitre E-DEC WEB La solution e-dec web consiste en une mise à disposition d un masque sur le portail internet de la douane qui rend possible la saisie des données de déclaration et leur saisie après correction. La mise sur pied de cette solution ne demande aucun prérequis technique de la part du déclarant, si ce n est de disposer d un accès à internet et un navigateur web. FIGURE 27: PORTAIL E-DEC WEB (E-DEC, 2013) Si elle offre une bonne solution d appoint, elle ne peut en aucun cas être considérée comme une solution viable pour une entreprise qui exporte quotidiennement des marchandises. En effet, elle provoque une rupture de média entre le système du déclarant et e-dec. Cette procédure risque donc d être la source d erreurs et de générer de coûts administratifs élevés relatifs à la saisie manuelle des donnés PROCESSUS D EXPORT ENTRE L ERP, LE BPMS ET E-DEC Compte tenu d une croissance importante du volume de cas d exportation attendue dans l entreprise Hans Werk AG, il a été décidé d implémenter le service web. Cela va impliquer de recourir au BPMS pour réaliser l interface entre l ERP et e-dec. Cette implémentation va nécessiter les tâches illustrées à la Figure 28 et décrites ci-dessous. Il est à noter que les Partie pratique : Application du BPM Lifecycle dans une PME 58

60 tâches de couleur rouge sont celles qui feront l objet d une implémentation dans le point suivant de ce travail. FIGURE 28 : PROCESSUS D EXPORT AVEC ERP, BPMS ET E-DEC La première tâche de ce processus est intitulée dans la Figure 28 Décision d envoi de montres. A ce stade, il faut comprendre qu une commande réalisée auprès de Hans Werk AG ne va pas donner lieu à un seul envoi correspondant à toutes les montres commandées. En effet, il se peut que pour des raisons de disponibilité de stock il ne soit possible d envoyer qu une partie de la commande ou alors qu il soit décidé pour des raisons commerciales d en envoyer qu une partie. La décision est prise par l entreprise Hans Werk AG durant la séance de vente hebdomadaire. Elle nécessite la concertation de la direction, du responsable de la logistique et du responsable de la production. La décision d envoi de montres amène à la génération des factures relatives à l envoi. La facturation a en effet lieu sur les quantités livrées. Les informations présentes sur une facture Partie pratique : Application du BPM Lifecycle dans une PME 59

61 de l ERP servent à a fois au paiement de cette dernière par le client, mais elle est aussi la base informationnelle pour toute exportation. FIGURE 29 : FACTURE ERP En plus des montants pour chaque ligne, on notera la présence du champ HS Code. Un HS Code étant un identifiant tarifaire défini par l Organisation Mondiale des Douanes (OMD) qui est une information demandée par les douanes du monde entier pour les processus d export et d import. Dans l exemple de la Figure 29, les deux articles de la facture diffèrent de par leur code car la première position est une montre en acier (9102.) automatique (.2100), alors que la seconde est une montre en or (9101.) manuelle (.2900). Il faut aussi noter que l imputation de la TVA dans l ERP se déroule comme suit : chaque produit possède une taxe par défaut qui est celle prévue par la loi ; chaque client doit être soumis à un régime fiscal. Il en existe 2. Le premier est intitulé «conventionnel» et le second «Import/Export». Lorsque la marchandise est vendue en Suisse, c est le régime conventionnel qui s applique. Si la marchandise est exportée, c est alors le régime «Import/Export» qui va être retenu. Ces deux options sont visibles sur la Figure 28. Afin d assurer la collaboration entre l ERP et le BPMS, il sera à la fois nécessaire que l ERP soit capable de transmettre des données à chaque fois que la décision de livrer des produits qui sont sujets au régime de taxes «Import/Export» est prise par l entreprise Hans Werk AG. Cette problématique pose des questions de responsabilité du traitement de ces tâches. Partie pratique : Application du BPM Lifecycle dans une PME 60

62 En effet, même si l évènement déclencheur a lieu dans l ERP, on peut se demander quel système entre le BPMS et l ERP sera le plus à même de traiter les données pour les rendre conformes à e-dec. De plus, on peut aussi se demander si une infrastructure de type ESB ne serait pas nécessaire pour réaliser les tâches de traitement de données. Ces questions excèdent la problématique de la collaboration d un BPMS avec un web service qui est le sujet de la partie pratique de ce travail. Elles pourraient en revanche être au centre d une prochaine itération de BPM Lifecycle pour le processus d export. La mise en conformité des données qui succèdera à la réception des données consiste à confronter les données reçues de l ERP dans un format indéfini et à les transformer en un fichier XML qui respecte le contrat d interface de e-dec. Une fois cette tâche exécutée, il sera possible d envoyer des données grâce à l appel du web service à e-dec. Cet envoi sera vérifié par un test de plausibilité. Si celui s avère négatif, les données seront renvoyées à l exportateur par le biais du web service et une demande de correction aura lieu. Si le test est passé avec succès, il donnera lieu à l envoi de la DDE au client. S ensuivra la procédure d exportation décrite en détail à la figure Figure 26 et la clôture du cas d exportation par la réception de la DTE. Partie pratique : Application du BPM Lifecycle dans une PME 61

63 5.3 BPM Phase 3 : Implementation La partie de ce travail répond à la question de recherche suivante : «Quelles tâches de configuration seront nécessaires depuis la modélisation pour que le processus puisse s exécuter?». Elle va le faire par le biais d un prototype d implémentation qui va permettre de comprendre les enjeux d implémentation. Ce prototype est en annexe du travail CRÉATION DES INTERFACES DE VÉRIFICATION DES DONNÉES ISSUES DE L ERP Dans cette implémentation, on doit considérer que les données issues de l ERP sont générées par un évènement qui a eu lieu dans l ERP. En effet, comme on peut le voir à la Figure 28, c est suite à une décision d envoyer des montres et la facturation qui va suivre que les données nécessaires à l exportation seront générées. Comme cela a été énoncé au point 5.2.5, la décision de traiter les données soit par l ERP ou par le BPMS ne va pas être traitée dans l implémentation de ce travail. C est pourquoi les données à vérifier ont dû être générées, indépendamment de la source qui serait la leur dans le cas d une implémentation complète du processus. Idéalement, il aurait été possible d utiliser le XML Schema goodsdeclaration.xsd fourni par l AFD par le biais du document Service Contract für Zollanmeldung (AFD, 2012) pour générer un fichier XML qui soit conforme à l interface du service e-dec. Il s est malheureusement avéré lors des tentatives de générer un fichier XML depuis le fichier goodsdeclaration.xsd que celui-ci était reconnu comme corrompu par le BPMS Bonita, alors qu un contrôle de celui-ci avec le logiciel XML copy editor affirmait au contraire qu il était conforme. Afin de pallier à ce problème, une solution d appoint consistant à rentrer les données de déclaration sous forme de variable a été retenue (voir 8.1). Etant donné que le fichier goodsdeclaration.xsd gère aussi les dépendances entre les champs et ceux qui sont nécessairement à remplir pour valider la déclaration, il a été décidé de procéder de la manière suivante : d abord réaliser une déclaration sur l interface test de e-dec web (voir 5.2.4), puis utiliser les données demandées lors de la déclaration comme les champs à entrer pour le cas. Les valeurs saisies dans ce cas de déclaration préalable ont été configurées comme valeur par défaut. Cette manière de procéder donne donc à l utilisateur du BPMS la possibilité de valider au travers d un formulaire tous les champs qui ont été reconnus comme nécessaires à l établissement de la déclaration test MISE EN FONCTION DU MOCK SERVICE E-DEC AVEC SOAP UI SOAP UI est un logiciel qui permet de simuler un service depuis un fichier WSDL. Comme cela a été expliqué au point 3.3.5, WSDL est un format qui gère le contrat de service d un web service. Il suffit donc d indiquer à SOAP UI l adresse à laquelle se trouve le fichier Partie pratique : Application du BPM Lifecycle dans une PME 62

64 WSDL et depuis ce fichier, il sera en mesure de réaliser plusieurs tâches que l on peut apercevoir dans la capture d écran à la Figure 30. Sur la base de ces informations, SOAP UI sera en mesure de réaliser un mock service, c est-à-dire un service qui ne respecte pas nécessairement l implémentation du service cible et qui soit à même de contourner certaines restrictions émanant de celui-ci. Cela a permis dans ce travail de contourner l authentification nécessaire et le recours à HTTPS sur l interface test tout en pouvant analyser l exécution d un service depuis le côté serveur pour ce qui est de l échange d informations, sans pour autant avoir accès aux fonctions de l ESB de e-dec. FIGURE 30: CONFIGURATION DE SOAP UI AVEC FICHIER WSDL Suite à la validation de cette fenêtre, il est possible par le biais de l interface de SOAP UI de visualiser un certain nombre d informations concernant le service, comme on peut le voir à la Figure 31. Partie pratique : Application du BPM Lifecycle dans une PME 63

65 FIGURE 31: INTERFACE SOAP UI La visualisation des services au travers de cette interface permet d analyser au travers du contrat de service WSDL les bindings, soit les services pris en charge. On notera qu ils sont au nombre de deux. Le premier s intitule goodsdeclaration, alors que le second qui ne sera pas traité dans ce travail car il est réservé à des exportateurs qui répondent à des conditions particulières et qui se nomment exportateurs agréées se nomme selectionandtransit. Chacun de ces services est constitué d une enveloppe SOAP (voir 3.3.4) qui va permettre au client d utiliser le service en envoyant celle-ci avec le recours d un protocole de transport. Le mock service utilisera l adresse de la machine comme hôte CONFIGURATION DU WEBSERVICE DANS BONITA Suite à la validation des données dans le BPMS, il va être nécessaire d appeler le service web e-dec. Dans Bonita, cette opération est possible par le biais d un connecteur. C est-àdire une interface qui gère l appel de service par le biais d un paramétrage. Dans sa version payante Bonita Teamwork permet la configuration des web services par le biais d une interface dédiée et prenant en charge les fichiers de type WDSL. Ce travail académique n étant pas basé sur des solutions informatiques payantes, il aura été nécessaire de réaliser le paramétrage sur l interface basique pour les web services. Celle-ci est visible à la Figure 32. Partie pratique : Application du BPM Lifecycle dans une PME 64

66 FIGURE 32: INTERFACE CONNECTEUR SERVICE WEB DE BONITA Cette tentative de configuration se sera avérée vaine pour qu un appel du web service soit possible. En revanche, les champs demandés à compléter pour connecter le service sont cidessous documentés. Les champs suivants seront à renseigner depuis le fichier WSDL. : 1. Cible NS La cible NS désigne le targetnamespace, soit l endroit où est stocké le fichier WSDL. Cette information est elle-même stockée dans le fichier WSDL sous l attribut targetnamespace visible à la Figure Nom de service Le Nom de service désigne le nom associé au contrat de service. Il est disponible dans le fichier WSDL sous l attribut name visible à la Figure 33. Partie pratique : Application du BPM Lifecycle dans une PME 65

67 FIGURE 33: DEFINITIONS DU FICHIER E-DEC WSDL Les deux premières informations demandées font partie de ce qui a été défini au point comme étant l interface abstraite du service. 3. Nom du port Le Nom du port désigne une information qui lie un URL et un binding. Ce dernier étant une association entre plusieurs paramètres présents dans le fichier WSDL et qui ont étés décrits lors de la description de la Figure Requête La requête est constituée de l enveloppe SOAP qui est à transmettre au web service. Ici, les variables sont celles qui ont été confirmées par l utilisateur grâce au formulaire. La forme de l enveloppe SOAP est celle que l on trouve dans SOAP UI sous la forme de l enveloppe associée à Request1 qui est visible à la Figure Adresse endpoint L adresse endpoint est la destination à laquelle l enveloppe SOAP va être utilisée pour le traitement. Ici, c est l adresse qui est fournie par SOAP UI et qui héberge le mock service. C est-à-dire que le contenu de l enveloppe sera envoyé au mock service lancé par SOAP UI et qu une réponse correspondant lui sera envoyée. 6. Binding Le binding a été configuré ici selon les informations présentes dans le mode d emploi pour les connecteurs disponible sur la page web. Il s agit de la meilleure source à disposition pour l utilisation de connecteurs trouvée. 7. SOAP Action SOAP Action désigne quelle action décrite dans le fichier WSDL va-t-être utilisée pour traiter la requête. Partie pratique : Application du BPM Lifecycle dans une PME 66