Le BPM 1 Introduction... 2 1.1 Dissiper l ambiguïté... 2 1.2 Quelques définitions... 2 1.3 Définition du BPM... 3 1.4 Modélisation BPMN... 4 1.4.1 Les briques de la modélisation... 4 1.4.2 Des patterns dans le contrôle du flot... 5 1.4.3 Voici les patterns proposés par le BPMN... 5 Le couple BPM - SOA... 7 1.5 Définition de SOA... 7 1.6 convergence des démarches BPM et SOA... 7 1.7 BPM en appui sur les architectures SOA... 8 2 La gestion de processus d Octo technology... 10 2.1 Les patterns SOA... 10 2.2 Les différentes solutions de mise en ouvre de processus métier... 11 3 Le workflow... 14 3.1 Définition:... 14 3.2 Exemple de workflow... 15 3.3 Conclusion :... 16 4 Références :... 17 1
1 Introduction Ce rapport tente de décrite de manière synthétique les concepts qui intervienent dans le BPM. En vue d obtenir un regard critique, ou un certain recul, sur les outils de BPM proposés par les éditeurs du marché, ce document présentera aussi une démarche de gestion de processus du cabinet d architecture Octo technology. 1.1 Dissiper l ambiguïté L acronyme BPM peut sembler ambigu car celui réfère deux disciplines dans l étude des processus d entreprise. Le BPM (Business Process Modeling ou Modélisation des processus métier) est l activité qui consiste à représenter et modéliser les processus d entreprise. Il a pour vocation de fournir une modélisation actuelle ou en l état du processus pour ensuite pouvoir l analyser. Comme on le verra par la suite, il fait parti de l étape initiale d une discipline plus globale le BPM (Business Process Management ou Gestion des processus métier) Il est aussi utilisé pour cartographier la vue métier d une entreprise qui est employée dans les démarches d urbanisation du système d information. Pour décrire de manière unifier les processus d entreprise, un standard de langage de modélisation des processus est apparu le BPMN (Business Process Model Notation). Il a été développé par le BPMI (Business Process Management Initiative) et est maintenu par l OMG. Ce langage est supporté par les principaux éditeurs de solution SOA. 1.2 Quelques définitions Avant d entamer la suite de ce rapport, voici quelques définitions pour fixer un sens précis aux mots clé du document : Un processus 1 métier est un enchaînement de tâches métier réalisées par un ensemble d acteurs de l entreprise et produisant une valeur ajoutée pour celle-ci. Un service 2 est un traitement normalisé, mutualisé et référencé au sien de l entreprise, dont l interface d appel est décrite dans un langage neutre (indépendant des technologies), et qui est déployé physiquement sur un serveur. 1 Valtech livre orange sur l urbanisation & l intégration de systèmes 2 idem 2
1.3 Définition du BPM Le BPM (Business Process Management) traite du cycle d ingénierie des processus d entreprise en répondant aux problématiques métiers telles que : l efficacité ( étape redondante voire inutile, délais incertains, goulot d étranglement) le contrôle (qui contrôle et qui est le responsable du processus) transparence (pouvoir suivre les étapes de processus ) Ainsi une définition au sens large serait «Le BMP est la discipline qui fournit l ensemble des méthodes, technologies et outils destinés à améliorer l efficacité, la traçabilité et l agilité des processus métiers au sein desquels collaborent des systèmes, des logiciels, des personnes et aussi des clients, des fournisseurs et des partenaires... le BPM traite du cycle d ingénierie des processus» 3 Le logo suivant pris du wiki résume cette définition. Les principaux objectifs du BPM sont : - d avoir un langage commun entre la MOA et la MOE - de permettre la convergence entre besoin métier et SI - d obtenir un référentiel des processus métier - d améliorer l agilité des entreprises (métier et SI) 3 Forum de CXP 21 Octobre 2008 BPM : le défi de l agilité 3
1.4 Modélisation BPMN Le BPMN fourni un ensemble d objets graphiques qui permet de modéliser tout processus d entreprise. 1.4.1 Les briques de la modélisation La hiérarchie des objets du langage graphique BPMN entrant dans la modélisation d un processus métier sont les suivants : Les "couloirs" (Swimlanes) qui? Les "objets de flux" (Flow Objects) Les "activités" (Activities) Fait quoi? simples (Task) complexes (Process / Sub-Process) Les "événements" (Events) Quand? Evénement initiateur du Processus (Start Event) Evénement Intermédiaire de Processus (Intermediate Event) Evénement terminal du Processus (End Event) Les "portes" (Gateways) Synchronisations ou décisions XOR XOR OR AND Complexe Event-based Les "objets de relation" (Connectivity Objects) Dans quel ordre et avec quoi? des flux séquence (Sequence flow) des flux message (Message flow) des Associations (Association) Les "artéfacts" (Artifacts). On retrouvera la description de chaque objet dans le livre orange de Valtech 4. On peut remarquer une certaine similitude avec la modélisation Merisienne. En effet, les conceptes qui décrivent la dynamique du SI dans Merise sont aussi les trois abstractions 5 suivantes : l événement, la synchronisation, l opération. Mais la modélisation Merisienne est plutôt orienté dans le contexte de conception de système d information. 4 Livre orange de Valtech Annexe : aperçu de BPMN p 65 5 La méthode Merise principes et outils p 103 4
1.4.2 Des patterns dans le contrôle du flot Comme on le verra par la suite lorsque l on parlera de la gestion des processus, l activité de modélisation a aussi ses patterns. C est-à-dire, des mini-structures récurrentes que l on retrouve dans les «bonnes» modélisation de processus d entreprise. Ceci afin d éviter une modélisation type «usine à gaz» : faire une modélisation compliquée pour finalement quelque chose de simple. Cette approche permet aussi de mieux maîtriser la complexité d un processus car composé d un certain nombre de mini-structures récurrentes plus facile à comprendre. 1.4.3 Voici les patterns proposés par le BPMN 6 6 Valecth livre orange p 65 5
6
Le couple BPM - SOA 1.5 Définition de SOA SOA (Service Oriented Architecture) est un style Architecture logicielle pour lequel les processus métier de l entreprise sont des composants logiciels paramétrables, orchestrant des tâches avec les acteurs de l entreprise et des appels à des composants de services pour s exécuter. On pourra se référer au métamodèle proposé par Valtech 7 pour voir un exemple d architecture logicielle SOA. 1.6 convergence des démarches BPM et SOA Le BPM est souvent associé à la démarche SOA car «la vision SOA permet de replacer les processus métier au coeur de l architecture SI» 8. Voir même la convergence des deux démarches BPM et SOA est source d optimisation SI et source d agilité pour l entreprise. d après le séminaire Norsys 2008 7 Livre orange de Valtech, 6 Annexe : Métmodèle pour l approche Think Service 8 Livre orange de Valtech p 65 7
1.7 BPM en appui sur les architectures SOA Pour atteindre les objectifs d une architecture SOA, il est nécessaire de décomposer le SI en couche de services : - métiers - fonctionnelles - techniques Le déploiement d un processus métier sur ce type d architecture SI est plus facile car chaque tâche de l enchaînement métier utilise un service réutilisable de l architecture SOA. C est grâce au principe d architecture SOA : les services n appartiennent à aucune application particulière qui fait que l utilisation de services est au maximum découplée. On peut changer par exemple une tâche et de redéployer le processus sans modifier les couches services du SI (pour peu que ces dernières satisfont toujours au besoin), on dit qu il y a découplage entre ces deux aspects d où la flexibilité métier et SI attendue. Le schéma suivant extrait du forum du CXP résume ce principe. Les différentes interactions dans les couches métier, fonctionnelles et techniques sont sujets à des contraintes de couplage faibles (non décrites ici, mais on peut néanmoins consulter les principes d architecture applicative SOA 9 ) Tâche2 Processusmétier Tâche1 TâcheN Tâche3 Services métier Services fonctionnels Services techniques Un processus métier est sa déclinaison en terme de services sur l architecture SI. Schéma repris du forum du CXP 9 Livre orange Valtech p 38 8
Les architectes du cabinet de conseil en architecture Octo Technology accordent aussi au BPM une place nécessaire dans leur démarche d architecture SOA. Mais ils sont plus réservés que les autres sociétés sur les outils d orchestration de services proposés par les éditeurs. Pour Octo «l orchestration de services vu comme un moyen facile d implémenter un processus métier prêche encore pour la gestion de processus complexe». En effet, pour eux ces outils BPM censés «en quelques clic de souris d implémenter un processus et de le faire vivre facilement» n est possible que pour certain type de processus. Leur pattern d architecture fonctionnel «processus implicite et explicite» 10 de leur livre blanc propose d identifier la nature des différents processus d entreprise et de leur associer une implémentation en adéquation (en autre) avec leur complexité, leur nature transverse. On verra plus loin une classification ou grille qui permet de choisir l incarnation d un processus métier suivant divers solutions techniques (développement spécifique, externalisation vers des outils spécifiques BPM/workflow ou des outils d infrastructure EAI/ETL). Les avantages/inconvénients en terme de maintenance, suivi, seront décrit pour chaque type de solution. Pour rappel, l objectif de l EAI (Entreprise Application Intégration) est d échanger de manière performante des informations entre applications ou progiciels, sur plates-formes hétérogènes. Dans des Systèmes d Information en constante évolution l EAI répond à la problématique d intégration de systèmes hétérogènes (Solution à l effet spaghetti ) 10 Octo technology livre blanc sur l architecture orienté service (SOA) p36-39 9
2 La gestion de processus d Octo technology Comme annoncé précédemment, le sujet de la gestion de processus dans la démarche SOA d Octo technology est décrit par le pattern «processus explicite et implicite» 2.1 Les patterns SOA A la fin des années 90, en réponse à une volonté de maîtrise de la complexité croissante des système d information, les DSI ont engagé des démarches de cartographie. Malheureusement ces dernières ont été entreprises de manière trop exhaustives et finalement peu exploitables et maintenables. Aux démarches de cartographies centrées sur l exhaustivité de l information les architectes d Octo technology privilégient une approche orientée «pattern». Ils généralisent, au niveau du système d information, le concept de design pattern 11 repris du domaine de l architecture logiciel. Ils basent leur démarche d architecture SOA sur la présence au sein du SI de patterns caractéristiques de cette architecture. Ces patterns constituent pour eux la valeur intrinsèque du SI. Un pattern 12 (ou modèle d architecture) est la formalisation d une idée correspondante à une solution pour un problème identifié, et qui se répète dans le temps. Octo propose une structure pour cataloguer les patterns SI caractéristiques de l architecture SOA Les patterns d architecture SOA 11 design pattern : Elements of reusable Object-oriented software 12 livre d Octo technology «Une politique pour le système d information» 10
2.2 Les différentes solutions de mise en ouvre de processus métier Soulignons d abord, que la société Octo se positionne en rupture avec les autres éditeurs de solution SOA. Et même avec ce qui a été présenté précédemment concernant les objectifs de flexibilité avec le couple BPM/SOA. Car ils pensent que «la flexibilité que les entreprises attendent n est pas liée à la mise en ouvre d un outil de gestion de processus mais plutôt à la maîtrise de son architecture fonctionnelle.» 13 Ils sont aussi en porte à faux sur un autre point fondamental de l urbanisation : la vision en quatre couches du système d information communément admise par la démarche d urbanisation des SI. Ainsi, ne retiennent-ils dans leur démarche SOA que trois couches sur les quatre. Ils fusionnent la vision fonctionnelle et la vision applicative car «les démarches de pilotage et de conception SI adressent de manière insécables ces deux aspects». 14 Comment choisir l implémentation d un processus métier? Pour répondre à cette question il faut aussi savoir répondre à celle ci : De quelque type de processus suis-je en présence? Les processus d entreprises sont souvent complexes, avec états, interaction humaine, règles de gestion complexes. Ce type de processus sera difficilement modélisable et implémentable, selon eux, avec des outils de BPM. Ces processus seront donc modélisés via des «uses cases» et des différents diagrammes associés. Ces processus sont nommés processus explicites. Les processus transverses, très rares, sont candidats à une externalisation au sein d un outil de gestion de processus. Ainsi, une solution technique adaptée à cet aspect est l implémentation à l aide outil de EAI/BPM Les processus non transverses, se retrouvent localisés au sein même des applications. Leur implémentation peut alors varier du développement spécifique à l utilisation d un outil spécifique (BPM ou Workflow), toujours local à l application concernée. On présentera un exemple de workflow dans la suite du document. Par opposition, l entreprise ou plus particulièrement la DSI possède des processus de support au bon fonctionnement du système d information. Ces processus ont rarement de sens pour le métier de l entreprise et sont, la plupart du temps, orientés synchronisation ou alimentation de données. Par exemple, l alimentation de l entrepôt de données du système décisionnel. On 13 Architecture Orientée Services [SOA] livre blanc p 37 14 livre d Octo technology «Une politique pour le système d information» p 81 11
qualifie ces processus d implicites. De part leur nature aussi transverse, ils sont de bons candidats à une externalisation au sein d un outil d infrastructure (outil EAI, ETL). On a deux caractéristiques principales de la gestion d un processus entre applicatifs : l orchestration du processus : c est-à-dire le moteur d exécution permettant le passage d un état à l état suivant du processus, le suivi du processus : c est-à-dire la capacité à savoir dans quel état se trouve un processus à un instant donné ainsi que ceux par lesquels il est passé. En conclusion on peut synthétiser le pattern processus explicites implicites de la manière suivantes : La quasi-totalité des processus explicites sont implémentés au sein même des applications, leur complexité n est pas propice au développement à l aide d un BPM. Les outillages de BPM servent l orchestration de tâches séquentielles, par exemple un traitement Back-office nocturne. Les outillages de BPM peuvent orchestrer des échanges inter-domaines, le plus souvent de nature implicite : irrigation des référentiels, extraction vers les systèmes de synthèse. 12
Grille du pattern processus explicite/implicites d Octo 13
3 Le workflow 3.1 Définition: Un workflow 15 est la modélisation et la gestion informatique de l ensemble des tâches à accomplir et des différents acteurs impliqués dans la réalisation d un processus métier ( aussi appelé processus opérationnel ou bien procédure d entreprise ) Comme vu précédemment le workflow est un cas d implémentation non transverse (au sens technologique) d un processus métier. Dans l offre SAP, le moteur de workflow est fourni de par défaut ( inclus dans l offre de base) Il permet d éviter du développement spécifique dans le progiciel. L avantage de la mise en oeuvre d un processus métiers par workflow par rapport à un développement spécifique est qu il est plus facile, rapide et moins coûteux. D autant plus que le processus métier comporte beaucoup d activités, plusieurs personnes impliquées, et un fort besoin de coordination. La notion d objet logiciel est fortement utilisée dans un workflow. Les concepts objets (abstraction, encapsulation) ont permis une plus grande réutilisation des développements que les langages procéduraux. Un langage orienté objet spécifique à SAP (ABAP object) a ainsi été crée pour constituer une architecture logicielle adaptée à la mise en oeuvre de workflow. Le passage de la modélisation vers le déploiement passera par une traduction ( générateur de code) d un schéma métier en un ensemble de composant logiciels. Le workflow s appuie sur un ensemble de composant métier du repository du progiciel ( BOR : Business Objet repository) qui permet de traduire en terme logiciel l ensemble des notions métier tels que les tâches, les événements, les acteurs, les objets métiers manipulés dans le progiciel. On retrouve le principe du publish and subscribe 16 du gang of four dans la modélisation des événements, c est-à-dire la manière dont les objets du repository vont communiquer entre eux. Le progiciel offre des outils de modélisation graphique de workflow qui permet d exprimer une modélisation métier. Cette dernière sera traduite dans le langage propriétaire du progiciel (par exemple en ABAP objet sur SAP) et exécuter par le moteur de workflow. Chaque concept métier du modèle sera associé à une instance d objet lors de l exécution du workflow 15 Wikipédia 16 design patterns : Elements of reusable oriented object software 14
3.2 Exemple de workflow Cet exemple défini un workflow de validation de commande dans SAP. Il utilise aussi un développement spécifique fournissant une IHM permettant d afficher et donner la possibilité de valider/invalider ces commandes. Ce développement sera déclencher via une transaction spécifique Z_AFF_CMD 15
3.2.1 Conclusion : On pourrait aujourd hui remettre en question les réserves d Octo concernant la difficulté voir l impossibilité d implémenter des processus complexes avec les outils de BPM (ce livre blanc date de Mars 2005) Le BPM est connexe avec beaucoup d autres gros sujets tel que l EAI, la SOA. L EAI qui intervient dans son rôle d intégrateur de systèmes hétérogènes lors de la mise en oeuvre de processus transverses de l entreprise. Le socle SOA qui propose ses briques sous forme de services qui permettent de déployer et d exécuter un processus indépendamment du SI. La notion de pattern SI en tant que principe d architecture est très intéressante. Car on structure le SI sur des «bonnes pratiques» éprouvées et reconnues comme le sont les designs patterns en génie logiciel. La plupart des problématiques récurrentes dans les SI dans un contexte donné se trouvent répertoriées et une solution générique (manière de faire avec des hommes et des outils ) est proposée. Et UML dans tout ça! L approche par les cas d utilisation représente une méthode éprouvée de spécifications qui s attache à décrire la valeur dans un système informatique : les besoins métiers. De la même manière, la modélisation métier avec UML défini des cas d utilisation métier servant à décrire une séquence d interaction entre acteurs et le système. La modélisation métier avec UML offre la continuité des concepts et de notations depuis les phases de capture des besoins jusqu aux phases les plus détaillées de développement informatique. Mais UML n a pas réussi à s imposer comme langage de modélisation métier car il est une pratique propre à l ingénierie logiciels et des systèmes. Il est même «inopportun de chercher à en élargir le périmètre dans la mesure où son intérêt réside précisément dans le prolongement possible de cette modélisation sur le développement informatique» 17 En résumé, UML pour la MOE car pratique pour la continuité des concepts et des notations dans le cycle de vie du processus de développement et le BPMN pour la MOA et la MOE. 17 Franck Vallée : UML pour les décideurs p 106-112 16
4 Références : (1) Forum du CXP du 21 octoble 2008 «BPM : le défi de l agilité» de Muriel Guénon analyst CXP. (2) Octo technology livre blanc sur l architecture orienté service (SOA) une politique de l interopérabilité de Mars 2005. (3) Valtech livre orange «Urbanisation & Intégration de systèmes» Think Service janvier 2007. (4) Si3Si - De la cartographie au BPM et au BPEL.ppt (5) Design pattern : Elements of reusable oriented object software. (6) Livre d Octo technology «Une politique pour le système d information». (7) Octo technology livre blanc sur architecture de système d information Novembre 2002. (8) La méthode Merise principes et outils Hubert Tardieu, Arnold Rochfeld, René Colletti. (9) UML pour les décideurs Franck Vallée 17