Université de Fribourg, Suisse Département d'informatique Bachelor en informatique de gestion
G ESTION DE PROCESSUS AVEC SOA ET BPM
DANS UNE PME
Travail de bachelor
Matthieu Borloz Mettlenweg 3 2504 Biel/Bienne (Dr. Stefan Hüsemann)
Mars 2013
Introduction 1
A BSTRACT
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.
M OTS CLÉS
SOA, BPM, BPM Lifecycle, BPMN 2.0, BPMS, e-dec exportation, Architecture des SI, SOAP, WSDL, processus, web services.
.
Introduction 2
T ABLE DES MATIERES
1. Introduction ... 7
1.1 Problématique ... 7
1.2 Questions de recherche et démarche ... 8
1.3 Méthodologie ...10
1.4 Public cible ...10
2 L’entreprise et le SI ...11
2.1 Définitions ...11
2.1.1 Système d’information ...11
2.2 Classification des SI ...13
2.2.1 Typologie selon le niveau de décision et vision OLAP OLTP ...13
2.2.2 Découpage fonctionnel d’un SI : métiers et besoins ...14
2.3 Architecture des SI ...17
2.3.1 Définition ...17
2.3.2 Un modèle d’architecture des SI : Le modèle de référence de l’urbanisation ...17
3 SOA : Emergence d’un modèle d’architecture SI ...20
3.1 La réponse SOA ...20
3.1.1 Motivation et Définition de SOA ...20
3.2 Les principes conceptuels de SOA ...22
3.2.1 Orientation service ...22
3.2.2 Modularité et composition des services ...22
3.2.3 Réutilisabilité ...23
3.2.4 Couplage faible ...23
3.2.5 Promotion de l’Agilité ...23
3.2.6 Valorisation des systèmes déjà existants ...23
3.3 Les composants et standards de SOA ...24
3.3.1 Niveaux de service de l’architecture SOA ...24
3.3.2 Utilisation des web services ...26
3.3.3 Un format pilier : XML ...26
3.3.4 Echange de messages avec SOAP ...27
3.3.5 WSDL ...28
Introduction 3
3.3.6 UDDI ...29
3.3.7 BPEL ...30
4 BPM : gérer l’organisation par les processus ...31
4.1 Bases conceptuelles ...31
4.1.1 Définition ...31
4.1.2 Historique ...31
4.1.3 Le but du BPM : l’agilité ...32
4.2 BPM Lifecycle ...33
4.2.1 Concept général ...33
4.2.2 La phase Goal Specification / Strategy Definition ...34
4.2.3 La phase Design ...34
4.2.4 La phase Implementation ...35
4.2.5 La phase de Process Runtime ...35
4.2.6 La phase de Process Improvement ...36
4.3 BPMM ...37
4.3.1 Concept ...37
4.3.2 Représentation des niveaux ...37
4.3.3 Niveau 1 : initial ...38
4.3.4 Niveau 2 : Managed ...38
4.3.5 Niveau 3 : Standardized ...39
4.3.6 Niveau 4 : Predictable ...39
4.3.7 Niveau 5 : Inovating Level ...40
4.3.8 Liens entre BPMM et le BPM Lifecycle ...40
4.4 BPMN 2.0 ...41
4.4.1 Avènement de BPMN 2.0 ...41
4.4.2 Principaux constituants d’un diagramme de BPMN 2.0 ...42
4.4.3 Exécution de BPMN 2.0 ...45
4.5 BPMS ...47
4.5.1 Principe ...47
4.5.2 Comparatif des outils existants ...47
Introduction 4
5 Partie pratique : Application du BPM Lifecycle dans une PME ...50
5.1 BPM Lifecycle Phase 1 : Goal specification / Strategy definition...50
5.1.1 Business Case ...50
5.1.2 Specification du but ...53
5.1.3 Alignement stratégique ...54
5.2 BPM Phase 2 : Process Design...55
5.2.1 Description du processus d’export du point de vue de l’entreprise ...55
5.2.2 Description du processus d’export du point de vue de la douane suisse ...56
5.2.3 Web service e-dec ...57
5.2.4 e-dec web ...58
5.2.5 Processus d’export entre l’ERP, le BPMS et e-dec ...58
5.3 BPM Phase 3 : Implementation ...62
5.3.1 Création des interfaces de vérification des données issues de l’ERP ...62
5.3.2 Mise en fonction du mock service e-dec avec SOAP UI ...62
5.3.3 Configuration du webservice dans Bonita ...64
5.3.4 Réponse du web service ...67
5.3.5 Intégration des résultats dans le BPMS ...67
5.4 BPM Phase 4 : Process Runtime ...69
5.4.1 Utilisation de la User XP ...69
5.4.2 Contrôle et saisie des données par l’utilisateur ...69
5.5 Phase 5 : Process Improvement...71
5.5.1 Envoi des données par l’ERP ...71
5.5.2 Utilisation de fichiers XML dans le BPMS ...71
5.5.3 Gestion des réponses de déclaration par le BPMS ...72
5.5.4 Définition des rôles autour du processus dans la perspective d’une implémentation ...73
5.5.5 Gestion des ressources ...73
6 Conclusion ...74
7 Bibliographie ...76
8 Annexes ...79
8.1 Annexe 1 : Prototype d’implémentation dans BonitaSoft ...79
8.2 Annexe 2 : Documents issus du service e-dec ...79
Introduction 5
L ISTE DES FIGURES
Figure 1 : Fonctionnement générique d’un système ... 11
Figure 2 : Décomposition en sous-systèmes ... 12
Figure 3: Niveau décisionnels ... 13
Figure 4 : OLTP vs OLAP (Zaiaine, 2013) ... 14
Figure 5: Découpage fonctionnel (CSB, 2013)... 15
Figure 6: Modele de l'urbanisation (Jozwiak, 2013) ... 18
Figure 7: Avant et après SOA (www.tridens.si, 2011) ... 21
Figure 8: Couches SOA (Erl, 2005) ... 24
Figure 9: XML Schema avec fichier XML (Wikipedia, 2012) ... 27
Figure 10: Requête et reponse SOAP simple (Quaine, 2012) ... 28
Figure 11: Fonction de WSDL (Haas, 2012) ... 28
Figure 12: Forme d'un document WSDL (IBM, 2012) ... 29
Figure 13: Implémentation de UDDI (Krawler, 2009) ... 29
Figure 14: BPM Lifecycle ... 33
Figure 15: Niveaux du BPMM ... 38
Figure 16: Avant et après BPMN 2.0 ... 42
Figure 17: Types d'évènement BPMN 2.0... 43
Figure 18: Tâches BPMN 2.0 ... 43
Figure 19: Branchements BPMN 2.0 ... 44
Figure 20: Pools et Lanes BPMN 2.0 ... 45
Figure 21: Tableau comparatif des outils BPMS en accès libre ... 48
Figure 22: Canaux de distribution et imputation de la marge sur prix de vente final ... 51
Figure 23: Incoterms ... 52
Figure 24: Processus de commande dans l'ERP ... 55
Figure 25: Procédure d'export actuelle chez Hans Werk ... 56
Figure 26: Fonctionnement de e-dec export du point de vue de la douane ... 57
Figure 27: Portail e-dec web (e-dec, 2013) ... 58
Figure 28 : Processus d’export avec ERP, BPMS et e-dec ... 59
Figure 29 : Facture ERP ... 60
Figure 30: Configuration de SOAP ui avec fichier WSDL ... 63
Figure 31: interface SOAP UI ... 64
Figure 32: Interface connecteur service web de bonita ... 65
Figure 33: Definitions du fichier e-dec WSDL ... 66
Figure 34: Déclaration en format XML ... 67
Figure 35: Configuration du retour des données dans Bonita ... 68
Figure 36: User Experience Bonita... 69
Figure 37: Formulaire de saisie et de contrôle des données ... 70
Figure 38: Interface de connexion web service payante de bonita (BonitaSoft, 2011) ... 72
Introduction 6
Introduction 7
1. I NTRODUCTION 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 8 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 9
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 10
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.
L’entreprise et le SI 11
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
2.1.1 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 12
¨
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 13
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.
2.2.1 TYPOLOGIE SELON LE NIVEAU DE DÉCISION ET VISION OLAPOLTP
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.
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.
Niveau stratégique Niveau tactique
Niveau opérationnel
L’entreprise et le SI 14
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 2.3.
2.2.2 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 15
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 16 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 17
2.3 Architecture des SI
2.3.1 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.
2.3.2 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 18
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 19 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.
SOA : Emergence d’un modèle d’architecture SI 20
3 SOA : E MERGENCE 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
3.1.1 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 21
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 22
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.
3.2.1 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.
3.2.2 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 23 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é.
3.2.4 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.
3.2.5 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.
3.2.6 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 24
3.3 Les composants et standards de SOA
3.3.1 NIVEAUX DE SERVICE DE L’ARCHITECTURE SOA
Le concept d’orientation service décrit au point 3.2.1 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 25 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 2.2.2 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 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.
o 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.
o 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 sous- caté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 26 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.
3.3.2 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 1995. 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.
3.3.3 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 27 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)
3.3.4 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 28 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)
3.3.5 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 29 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)
3.3.6 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 30 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.
BPM : gérer l’organisation par les processus 31
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.
4.1.1 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.
4.1.2 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 32 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.
4.1.3 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 33
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 ? ».
4.2.1 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 4.2.2 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.
FIGURE 14: BPM LIFECYCLE Goal
Specification / Strategy Definition
Process Design
Process Implementation Process Runtime
Process Improvement
BPM : gérer l’organisation par les processus 34 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.
4.2.3 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 35
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.
4.2.4 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.
4.2.5 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 36 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 4.3.6.
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.
4.2.6 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.
