Le BPM - Nordnet

Transcription

Le BPM - Nordnet

CNAM cours NFE107 : Urbanisation et architecture des SI
Xavier Godefroy, Rapport sur le BPM, mai 2009
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 processus1 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 service2 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
2
Valtech livre orange sur l’urbanisation & l’intégration de systèmes
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 :
-
3
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)
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 Valtech4. 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 abstractions5 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
5
Livre orange de Valtech Annexe : aperçu de BPMN p 65
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 BPMN6
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 Valtech7 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
8
Livre orange de Valtech, 6 Annexe : Métmodèle pour l’approche Think Service
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 SOA9)
Tâche2
Processusmétier
TâcheN
Tâche1
Tâche3
Servicesmétier
Servicesfonctionnels
Servicestechniques
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 pattern11 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 pattern12 (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
12
design pattern : Elements of reusable Object-oriented software
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
14
Architecture Orientée Services [SOA] livre blanc p 37
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 workflow15 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 subscribe16 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
16
Wikipédia
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

Le BPM - Nordnet

Transcription

Documents pareils

Consultants EAI/SOA/Urbanisation (H/F)

BUCK IT

Un partenariat mondial de recherche pour augmenter les

Taboulé libanais. - Ville de Coudekerque

cake saveur fruit

Composition florale

Rapport sur le marché

MUHKA (Museum van Hedendaagse Kunst Antwerpen)

Position Summary

Consultant en management des SI