|
Guide pour
Implémenter un outil BPM
Une opportunité pour reconfigurer ses processus
métiers
Mémoire de Master 2 professionnel - MIAGE Agilité
des systèmes d'information et E-Business
Auteur
Mohamed Lamine GHEMATI Tuteur
Mr. Bernard QUINIO
2009 - 2010
Deployment of a Business Process Management Suite
An opportunity for Business Process Reengineering
Companies are often required to modify their processes, at
different frequencies (higher or lower), to improve them and make them more
efficient. Business process management has become essential in these times when
we must have flexible and agile processes to avoid losing any competitive.
Implement a BPM application can be an opportunity to directly
influence its process and make a radical change if necessary, reposition the
actors to places that suit them and to monitor the processes based on reliable
indicators integrated into various parts of the existing information system.
The aim of this paper is to propose a practical method for
professionals who want to deploy a BPM tool to act effectively, or even
completely reconfigure their processes and improve their current management.
The methodology is based on a case study during our course completion and that
has allowed a major airline to choose objectively the BPM software most
appropriate to its activities.
Keywords:
Business process, BPM tools, reengineering.
Les entreprises sont très souvent appelées
à modifier leurs processus, à des fréquences plus ou moins
élevées, en vue de les améliorer et de les rendre plus
performants. Le management des processus est devenu incontournable en ces temps
oi l'on ne peut se permettre de disposer de processus lourds et peu agiles sans
risquer de perdre toute compétitivité. Le risque s'accroît
d'autant plus lorsque lesdits processus sont horizontaux et communs à
plusieurs services, et que cette transversalité empêche d'agir
efficacement et rapidement sur les problèmes qui s'y attèlent.
Mettre en place une application de gestion des processus
métiers peut être là une occasion d'agir directement sur
ses processus et d'y apporter un changement radical si nécessaire, de
repositionner les acteurs concernés aux places qui leur conviennent et
d'assurer un suivi et un pilotage efficients qui reposent sur des indicateurs
fiables intégrés aux différentes parties du système
d'information existant.
L'objectif de ce mémoire est de proposer une
méthode pratique destinée aux professionnels qui désirent
déployer un outil BPM afin d'agir efficacement, voire de reconfigurer
complètement leurs processus et d'améliorer leur management
actuel. La méthodologie suivie repose sur une étude de cas
effectuée lors de notre stage de fin d'études et qui a permis a
une grande compagnie aérienne de choisir objectivement le logiciel de
BPM le plus adéquat à ses activités.
Mots clés:
Outils BPM, processus métiers,
réingénierie.
Table des matières
Introduction
1. Problématique 5
1.1 Problème soulevé & étudié
5
1.2 Contexte 5
1.3 Choix du sujet 6
1.4 Situation actuelle 6
2. La réingénierie des processus
métiers 7
2.1 Qu'est-ce que le Reengineering ? 7
2.2 Le Reengineering & les technologies de l'information
8
2.3 Rôles des solutions BPM 8
3. Quelques notions inhérentes au BPM
10
3.1 Des précisions pour une meilleure
compréhension 10
3.1.1 BPM ou outils BPM ? 10
3.1.2 BPM Vs. WORKFLOW 10
3.1.3 Qu'est-ce qui différencie les outils BPM ? 10
3.2 Définitions autour du BPM 10
4. Comment choisir la suite BPM qui nous convient ?
12
4.1 Configuration actuelle du marché des BPM 12
4.2 Par où commencer ? 13
4.2.1 La communication et la diffusion d'informations 13
4.2.2 Processus pilote 13
4.3 Les phases du projet 14
4.3.1 Présélection technique, fonctionnelle
et....commerciale ! 14
4.3.2 La modélisation des processus 15
4.3.3 Le modèle de données -
Référentiel 15
4.3.4 La création des interfaces utilisateurs 16
4.3.5 Le moteur de règles métiers 16
4.3.6 Le déploiement et l'intégration au
système existant 17
4.3.7 L'exécution des processus 17
4.3.8 La supervision des activités 18
4.3.9 Autres facteurs importants 18
Conclusion
Références bibliographiques
Introduction
Selon le cabinet GARTNER, le marché des suites BPM
demeurera en constante évolution avec un chiffre d'affaires
évalué a environ 3 milliards de dollars d'ici a 2011 sur les 16
milliards de dollars que représentent toutes les applications
d'infrastructures et de middleware, tel le SOA. Ce chiffre est significatif de
la tendance actuelle a adopter de plus en plus un management d'entreprise et
une stratégie basée sur l'optimisation et la bonne gestion des
processus métiers et leur monitoring.
Mais l'achat d'un logiciel de BPM a l'instar d'autres types
d'applications nécessite une certaine réflexion afin de
répondre à ces questions primordiales : ai-je vraiment besoin de
ça maintenant ? Cela m'apportera-t-il réellement quelque chose ?
En tirer le maximum de gains et de profits et ne pas se laisser tenter par
l'effet de mode reste en effet l'objectif premier des DSI.
De là, nous avons essayé d'orienter en quelque
sorte cette réflexion vers des points concrets non exhaustifs certes,
mais qui aideront beaucoup d'entreprises dans leur démarche prospective.
Et si celle-ci débouche sur l'adoption d'une suite BPM, nous proposons
une étude analytique qui recense des besoins en fonctionnalités
pouvant déterminer le choix final de l'outil a acquérir et a
mettre en place, étant donné qu'il existe actuellement une
multitude d'applications sur le marché du BPM et qui sont à
priori toutes équivalentes.
Cependant, avant d'arriver a cela, nous allons consacrer un
chapitre a des notions inhérentes a la gestion des processus avec une
préférence à la pensée véhiculée par
HAMMER & CHAMPY qui est la reconfiguration (ou
réingénierie) des processus métiers que nous aborderons
aussi.
L'approche que nous proposons reste toutefois théorique
et entièrement indépendante des éditeurs du marché,
l'outil choisi pour notre étude de cas ne saurait être
nécessairement la meilleure solution pour toutes les entreprises, il y a
en effet beaucoup de paramètres qui se rapportent à la culture de
l'entreprise qui entrent en considération dans le choix final.
1. Problématique
1.1 Problème soulevé &
étudié
Les outils BPM (ou suites BPM) sont de plus en plus nombreux
sur le marché en raison de l'augmentation de la demande. Ces
applications ont pour rôle principal de permettre de modéliser des
processus, de les exécuter ou de simuler leur comportement,
d'automatiser certaines tâches selon des règles métiers
prédéfinies et elles permettent parfois d'orchestrer toute une
activité en reposant le plus souvent sur des indicateurs statistiques ou
sur un module BI (BAM).
De ce fait, lorsqu'on veut implémenter un logiciel de
ce type, on est contraint de choisir parmi la multitude de logiciels
disponibles selon, d'une part, les fonctionnalités dont dispose l'outil
BPM a déployer et d'autre part l'orientation que l'on souhaite donner a
son projet : gestion d'une chaîne d'approvisionnement, gestion
commerciale, BI...etc. Car cela devra limiter le champ d'application en
intégrant plus ou moins d'acteurs au projet (clients, fournisseurs,
banque...).
En parallèle a cela, une question devra s'imposer
tôt ou tard a l'initiateur du projet : est-ce qu'on doit reproduire le
processus en le modélisant tel qu'il est réalisé
actuellement sur le nouvel outil choisi ou devra-t-on le repenser pour
l'optimiser et en tirer ainsi (éventuellement) plus de
bénéfices ? Jusqu'oü doit-on intervenir pour
l'améliorer ?
Dès lors, on comprend mieux la nécessité
de bien préparer la mise en place d'une suite BPM qui aura sans doute un
impact sur l'environnement du service concerné ou de toute l'entreprise
- selon l'ampleur du projet - et qui sera confronté à des
difficultés diverses.
Nous avons essayé d'aborder ce problème en le
résumant en une seule question :
Quels sont les principaux paramètres à
prendre en compte pour choisir un outil BPM ?
Et en orientant l'objectif du projet de déploiement vers
un remodelage et une reconfiguration totale des processus en suivant
les recommandations du Reengineering.
1.2 Contexte
La méthodologie proposée ici est destinée
aux professionnels, de différents domaines, qui veulent opter pour une
solution de gestion de processus métiers pour leur service ou leur
département (ou carrément toute une société). La
démarche a été appliquée lors d'un stage de fin de
Master professionnel dans le cadre d'un projet visant à améliorer
les résultats d'un processus d'approvisionnement en environnements
informatiques en déployant une application BPM issue du marché et
choisie entre d'autres applications disponibles.
C'est donc une description d'un cas pratique qui s'est
soldé par l'adoption de l'outil le plus approprié aux
problèmes du service de l'entreprise concernée mais qui pourra
être plus ou moins adaptable à toute autre entreprise qui
désire stimuler son fonctionnement par la mise en place d'une gestion
par les processus.
1.3 Choix du sujet
Il y a deux principales raisons qui nous ont amenés
à traiter ce sujet en particulier :
|
Tout d'abord parce que nous croyons que toutes les entreprises
doivent être organisées autour de processus transversaux solides
et efficaces pour qu'elles soient performantes et qu'elles puissent soutenir la
concurrence en ces temps de mondialisation et de libre-échanges. Nous
pensons à juste titre que pour basculer du modèle dit «
fonctionnel » à celui de gestion par les processus, il faudra sans
doute beaucoup d'efforts. Le Reengineering tel qu'il a été
présenté par HAMMER & CHAMPY nous paraît être une
excellente alternative à ce passage, mais il ne pourra être a
notre sens une solution miracle sans qu'il soit accompagné et soutenu
pendant toutes ses phases de réalisation. La reconfiguration des
processus métiers est de plus en plus possible à effectuer
grâce a des outils permettant de se projeter dans l'avenir après
avoir réinventé ses processus et connaître ainsi a l'avance
leurs résultats sur le terrain. Cela apportera sans doute un gain
significatif dans l'application du Reengineering.
|
En second lieu, suite a l'intérêt croissant des
sociétés (de différents secteurs d'activités et de
tailles variées) a la gestion des processus métiers, plusieurs
éditeurs de solutions BPM sont apparus et des standards ont
été mis en place. Ce que proposent ces éditeurs ne
convient pas souvent aux besoins exprimés en la matière et n'est
pas forcément adaptable a toutes les structures. Il est donc
indispensable d'être en possession de tous les paramètres et de
toutes les informations qui sont utiles pour déterminer efficacement
l'outil qui sied le mieux aux exigences d'un tel ou tel métier avec les
particularités de chacun. Nous voulions donc présenter et
résumer en quelque sorte les fondements liés à ce type
d'applications pour permettre aux entreprises de choisir en toute connaissance
de cause avant de s'engager sur cette voie.
1.4 Situation actuelle
Si l'on fait un tour dans la bibliographie
spécialisée ou sur Internet, on se rend compte très
rapidement qu'il y a beaucoup d'informations concernant les suites logicielles
de BPM, mais qui sont hélas éparpillées et n'apportent pas
une analyse concrète et détaillée sur la démarche a
suivre pour distinguer un outil d'un autre. Nous sommes donc en face d'une
situation qui n'est sans doute pas inédite mais qui n'a pas
été clairement traitée et identifiée comme telle.
Nous n'avons donc pas de point de repère ou de véritable «
état de l'art », mais nous nous sommes établis sur des faits
pratiques pour en sortir avec des résultats du vécu
présentés dans ce mémoire.
2. La réingénierie des processus
métiers
2.1 Qu'est-ce que le Reengineering ?
Le Reengineering est une doctrine apparue dans les
années 1980 qui prône une rupture totale avec l'ancien
système de gestion des entreprises basé sur le taylorisme et la
théorie de division de travail. Selon les promoteurs de cette
pensée que sont James CHAMPY & Michael
HAMMER, il faut repenser totalement les organisations pour les rendre
plus flexibles et plus performantes et ne pas se contenter de rafistoler un
existant en le mettant « sous perfusion ». Ces auteurs nous proposent
une définition assez claire du Reengineering en insistant sur les mots
soulignés : `...c'est une remise en cause
fondamentale et une redéfinition
radicale des processus
opérationnels pour obtenir des gains
spectaculaires dans les performances critiques que
constituent aujourd'hui les coûts, la qualité, le service et la
rapidité. ' (HAMMER & CHAMPY ; 1993). A travers plusieurs cas
concret cités dans leur livre référence, ces auteurs
démontrent donc que des résultats impressionnants sont
réalisés lorsqu'on agit sur des processus métiers en les
façonnant comme ils devraient être sans se soucier de ce qu'ils
étaient auparavant, en les modifiant radicalement et ne pas juste
essayer d'en améliorer quelques points déficients. L'organisation
du travail en est bien sûr affecté et devra muter en une
organisation qui repose sur les processus avec des équipes
dédiées et transversales et un (ou plusieurs) responsable(s) de
processus, et ne pas s'appuyer sur des fonctions qui risquent d'alourdir le
fonctionnement de l'activité nouvellement pensée.
Néanmoins, on peut toujours commencer par appliquer un Reengineering
dans un service ou un département pour ne pas risquer de chambouler
complètement la structure fonctionnelle de l'entreprise et limiter ainsi
les risques encourus.
Un autre avantage, et non des moindres, est mis en avant par
J. Akoka et I. Comyn-Wattiau. Il s'agit d'avoir la
possibilité (en reconfigurant ses processus opérationnels) de
« contribuer à l'alignement des processus sur la stratégie
de l'entreprise », ce qui consent aux managers le potentiel pouvoir de
concrétiser plus vite et plus efficacement leurs décisions sur le
terrain.
|
Ces mêmes auteurs (mais aussi Céline
AVERSENG) évoquent des techniques et méthodes qui
peuvent aider a bien mener un Reengineering et qui s'appliquent sur les
facteurs de réussite que sont : les acteurs, les
représentations (des processus), les infrastructures et
systèmes d'information, et enfin la culture de
l'organisation. Celui qui nous intéresse ici est le système
d'information, ou comment les technologies nouvelles peuvent aider les acteurs
à refonder leur façon de travailler pour plus de performances.
|
2.2 Le Reengineering & les technologies de
l'information
Les concepteurs du Reengineering considèrent que les
technologies de l'information et de la communication jouent un rôle
crucial dans la reconfiguration des processus (HAMMER & CHAMPY, 1993). Ils
le montrent d'ailleurs a travers l'utilisation de ces outils technologiques
tels que les bases de données distribuées, la
visioconférence ou les systèmes d'aide a la décision par
des entreprises soucieuses d'améliorer la gestion de leur processus. Ces
technologies agissent en effet sur le coeur du métier de chacun de ces
processus, et ils contribuent certes a l'efficacité de ceux-ci, mais ils
n'apportent pas d'indicateurs directs sur la performance du processus et son
pilotage.
L'apparition des applications de BPM a apporté,
au-delà de leurs fonctionnalités liées à la
modélisation et a l'exécution des processus, une nouvelle
manière de considérer l'approche processus. Les modules de
monitoring des activités permettent en effet d'avoir en temps
réel, et au cas par cas, une vue globale ou détaillée sur
toutes les tâches d'un processus opérationnel et les
paramètres de coûts, délais, ressources consommées
et valeur produite. Ils proposent une analyse des différents
résultats obtenus qui rend maintenant possible d'agir sur le bon endroit
et au bon moment pour modifier une éventuelle tâche mal
réalisée.
Mais surtout, ces modules donnent le moyen de visualiser le
comportement d'un processus suite à une intervention ou à un
changement effectué dessus en temps réel. Ce qui autorise a
présent les managers d'émettre une multitude d'hypothèses
sur les dysfonctionnements actuels des processus ou les améliorations
possibles en ayant tout le loisir de modéliser le processus tel qu'ils
le conçoivent personnellement et d'en simuler le fonctionnement en
l'exécutant (avec plusieurs instances) et en injectant les
données souhaitées. Une sorte d'environnement de test est
proposé pour une meilleure reconfiguration de ses processus.
Les logiciels de BPM jouent donc un rôle plus direct et
plus important dans la réingénierie des processus
opérationnels.
2.3 Rôles des solutions BPM
Avant de citer quelques rôles des suites BPM, nous
rappelons qu'il faut toujours garder en tête une définition des
processus. Nous citons celle proposée par l'association française
de normalisation (AFNOR) : « Un processus est une succession
d'activités réalisées a l'aide de moyens (personnel,
équipement, matériels, informations) et dont le résultat
final attendu est un produit ». Un processus présuppose :
des éléments entrants mesurables,
une valeur ajoutée,
des éléments de sortie mesurables, conformes
à des critères d'acceptation, un caractère
reproductible.
Les suites BPM qui sont donc un levier et un support pour les
processus. Ils offrent la possibilité de :
- Modéliser et concevoir les processus
à travers un environnement de modélisation.
- Exécuter les processus via un
Framework qui repose sur un moteur de règle métiers qui
régissent le comportement des processus et qui sont établis par
les utilisateurs. Des interactions avec d'autres systèmes tels des web
services ou des bases de données de l'entreprise sont aussi possibles.
Des activités manuelles peuvent aussi être intégrées
au cas où on est incapables de les automatiser.
- Piloter et suivre simultanément les
performances des processus grâce à des
statistiques et des mesures restituées sous forme de
tableaux de bords. Ce sont généralement des chiffres qui
renseignent sur le temps d'un cycle de processus, le taux de
défaut de production et la productivité.
- Analyser & Optimiser les processus, par
exemple en détectant et en agissant sur les goulots
d'étranglement ou en réduisant les délais
d'accomplissement de certaines tâches.
Ces fonctionnalités des outils BPM ont été
mises au point dans le but de :
- Contrôler et améliorer les processus et les
sous-processus, en les rendant plus agiles. - Réduire les coûts
liés aux ressources consommées par les processus en
entrée.
- Réduire les délais tout en produisant mieux afin
d'améliorer la productivité.
- Améliorer la
qualité des produits et services offerts par les organisations.
- Isoler les informations utiles des masses de données
disponibles aux utilisateurs.
- Réduire ou supprimer la dépendance de
l'activité par rapport aux employés qui y
sont affectés et améliorer la gestion et la
capitalisation des connaissances.
- Améliorer la collaboration entre les structures
fonctionnelles d'une même
organisation et entre plusieurs organisations.
- Réorienter l'importance vers les clients des
processus.
- Automatiser autant que possible l'activité et supprimer
les tâches sans réelle valeur à l'entreprise.
- Permettre d'aligner l'opérationnel a la stratégie
pour une meilleure gouvernance. - Mettre la technique au service des
métiers pour de meilleurs résultats.
3. Quelques notions inhérentes au BPM
Avant de rentrer dans le vif du sujet et présenter la
méthodologie suggérée pour le choix d'un outil BPM, il
nous faut clarifier certaines choses et définir des notions qui tournent
autour du BPM.
3.1 Des précisions pour une meilleure
compréhension
3.1.1 BPM ou outils BPM ?
Tout d'abord, par abus de langage, nous avons tantôt
cité le BPM comme étant une façon de manager dans
l'entreprise et voulions parler d'autres fois des suites logicielles
consacrées a la gestion des processus métiers. C'est ce dernier
sens qui sera cependant le plus souvent prépondérant étant
donné la nature de notre étude.
3.1.2 BPM Vs. WORKFLOW
Il ne faut pas confondre les outils BPM présent
actuellement sur le marché avec les logiciels de WORKFLOW très
répandus pendant les années 90 et qui ont été
à la base destinés à jouer les mêmes rôles,
certes, mais qui ne permettaient pas de concevoir et de réaliser
rapidement des solutions complètes intégrant des interfaces
utilisateurs et systèmes. Si les suites BPM réutilisent parfois
des technologies présentes dans les moteurs de WORKFLOW, elles vont bien
au-delà afin de permettre une gestion complète et un pilotage
temps réel du processus et de ses performances.
3.1.3 Qu'est-ce qui différencie une application
BPM alors ?
Le BPM est donc l'ensemble des techniques, méthodes et
outils permettant d'effectuer les actions citées plus haut : la
construction, la diffusion, le contrôle, l'analyse et l'optimisation des
processus opérationnels ; En passant par des interfaces utilisateurs, en
utilisant un modèle de données unique et partagé, en
suivant des règles métiers préétablies et en
collaborant avec d'autres systèmes de l'organisation.
3.2 Définitions
Voici quelques définitions qui nous seront utiles pour la
suite du document :
I BPMI - Business Process Management Initiative
: Consortium international composé d'organismes
spécialisés dans le BPM et qui proposent des standards dans ce
domaine.
I BPMN - Business Process Modeling Notation :
Norme de modélisation graphique, BPMN est un système qui comporte
un ensemble d'éléments qui représentent les tâches,
les évènements, les acteurs...etc. Il a été mis au
point par la BPMI pour unifier les concepts liés aux processus et pour
permettre aux analystes métiers comme aux développeurs et
même aux utilisateurs de les comprendre, de les créer et de les
manipuler.
I BPMS - Business Process Management System (ou Suite)
: Ensemble logiciel destiné à formaliser les
procédures qui font l'activité d'une entreprise dans le but de
les automatiser et d'accroître leur performance.
I BPEL - Business Process Execution Language
: Langage de programmation à balises dérivé du
XML qui permet d'exécuter et d'orchestrer des processus et
éventuellement de les faire dialoguer avec différentes
applications dans une architecture orientée services.
I XPDL - XML Process Definition Language :
Langage de programmation dérivé aussi du XML qui permet de
représenter sous forme de balises et d'attributs différents
processus. Ces représentations pourront être de la sorte
importées dans différents modeleurs BPM.
I BAM - Business Activity Monitoring : «
Le concept de BAM comprend l'acquisition, l'agrégation, l'analyse et
la présentation en temps réel de données (typiquement des
séquences de valeurs temporelles et leur évolution)
associées à des processus d'entreprise...Le BAM peut être
employé indépendamment de l'existence d'un outil BPM. Il consiste
en une solution d'entreprise destinée a fournir en temps réel un
résumé de la situation des activités métiers aux
responsables des opérations et la direction. Le but d'une solution BAM
est, entre autres, de permettre une réaction au plus tôt
grâce à un système d'alarmes en cas de dérive et,
dans le meilleur des cas, pouvoir agir de manière proactive. »
(Source : WIKIPEDIA)
I BPR/CPI - Business Process Reengineering :
Approche qui renvoie à l'application d'un Reengineering en permanence
sur les processus opérationnel afin d'assurer une amélioration
permanente des résultats produits.
4. Comment choisir la suite BPM qui nous convient
4.1 Configuration actuelle du marché des
BPM
Comme nous l'avons mentionné en introduction, il y a de
plus en plus d'éditeurs de suites BPM avec divers degrés de prise
en compte des fonctionnalités liées au BPM. Voici quelques-uns
des acteurs les plus connus du monde des applications BPM :
BIZAGI, BONITA, B-PACK, PROCESS MAKER, TIBCO, W4,
INTALIO, IDS SHEER (ARIS), MEGA, ORACLE, JBOSS JBPM, Teamwork
(Lombardi)...etc.
Il est intéressant de voir aussi une représentation
de la distribution des parts de marché de ce secteur fournie par le
cabinet GARTNER, malgré qu'elle date de 2005 :
Il serait donc risqué d'opter pour un éditeur sans
en connaître les tenants et les aboutissants, surtout lorsqu'on sait que
la première des priorités des DSI actuellement est la performance
des processus métiers.
4.2 Par où commencer ?
4.2.1 La communication et la diffusion
d'informations
Lors d'un projet d'implémentation d'une application
métier, un fort besoin de rapidité et de déploiement se
fait ressentir et pousse les chefs de projets à agir parfois dans la
précipitation. Cela tout en cherchant à maintenir facilement et
à un coût raisonnable la nouvelle application qui devra respecter
les normes techniques adoptés par l'organisation.
Dans le cas d'un projet lié a un logiciel de BPM, nous
conseillons d'abord d'avantager l'aspect communication sur le concept et les
bienfaits du BPM qui risque de changer bien des habitudes et chambouler une
organisation, chose qui, comme on le sait, n'est pas vu du même oeil et
n'est souvent pas bien accepté par tout le monde dans la
société.
Un des éditeurs de suites BPM (IDS SHEER) classe les
entreprises en cinq catégories selon leur degré de
maturité dans la gestion des processus métiers tel que c'est
représenté par le schéma ci-dessous qui est semblable
à celui proposé par Yves CASEAU et qui reprend
la nomenclature proposée par CMMI (Yves CASEAU, 2008).
Il est donc plus que nécessaire de lancer une
véritable campagne d'information et de vulgarisation du BPM
(Obligatoirement pour les 2 premières catégories citées
plus haut) auprès des différents acteurs concerné par le
futur changement et gérer ainsi les éventuels
mécontentements (voir les volte-face) pouvant apparaître au
lancement du projet. Evidemment, cela n'est pas toujours facile a faire et il
faudra persuader, par des exemples concrets basés sur des projets ayant
abouti dans d'autres organisations, de l'intérêt de mettre en
oeuvre ce genre de programme. Différents moyens peuvent être
employés à cet effet : réunions d'information,
présentations en ligne, dépliants...etc.
4.2.2 Processus pilote
Dans son livre `Processus métiers et
SI' (Chantal MORLEY et al., 2007), Chantal MORLEY évoque un
type de processus dit de pilotage qui « ne participe pas directement
à la réalisation d'une mission se traduisant par la production
d'un produit ou d'un service. Il a pour but de veiller à la bonne marche
de tout ou partie d'une organisation. Pour cela, il utilise des informations
produites par les autres processus. Il peut conduire à orienter ou
reconfigurer certains processus ~. Il serait plus judicieux
d'élaborer une première étude sur un processus de ce type
afin de ne pas en affecter d'autres, et restreindre au maximum le
périmètre d'implantation sans pour autant le limiter qu'à
deux ou trois utilisateurs, cela pour permettre de vérifier
l'utilité du BPM dans la coordination des acteurs concernés. Dans
tous les cas de figures, il faudra choisir un processus « cobaye »
pour y construire une analyse à travers les différentes phases de
tests et d'implémentation des outils étudiés.
4.3 Les phases du projet
Les bénéfices
associés au
pilotage réactif des processus métiers ne
sont pas exagérés, mais l'ampleur de la
démarche est souvent sousestimée. Comme pour
l'urbanisation, il s'agit d'un changement de culture d'entreprise, qui touche
l'ensemble de l'organisation et s'exerce sur de nombreuses dimensions.
Yves CASEAU, 2008.
Une fois notre « processus test » choisi, nous
allons présenter les différentes étapes à franchir
une à une en prenant compte des fonctionnalités propres à
chaque phase. Il y aura certainement d'autres paramètres
spécifiques (relatifs au métier) à considérer dans
la plupart des cas et qui ne seront pas cités du fait de
l'impossibilité de traiter tous les secteurs d'activités bien
entendu. Un travail de réflexion propre à chacun sera requis pour
la réalisation d'une étude plus complète et
personnalisée.
4.3.1 Présélection technique, fonctionnelle
et... commerciale !
La première phase consiste à réduire le
nombre de logiciels susceptibles de faire partie de notre étude
comparative afin d'en sélectionner qu'un nombre restreint, et en vue de
limiter d'une part les efforts consentis aux différents essais, et
d'autre part de respecter les contraintes liées a l'environnement de
l'organisation concernée. Ces contraintes peuvent être d'un ordre
technique ou fonctionnel tel que :
· Les systèmes d'exploitation pris en compte
· L'architecture réseau
· Serveurs web
· Serveurs d'applications
· Systèmes de gestion de bases de données
· Disponibilité de connecteurs vers des
systèmes spécifiques
· Langage de programmation utilisé
Des contraintes qui sont plus liées aux habitudes et a la
culture de l'entreprise peuvent aussi peser sur le choix des suites BPM
à tester, voire des préférences commerciales telles que
:
· Les relations et l'entente avec les éditeurs
(fournisseurs)
· Les licences proposées (et l'accès au code
source): Propriétaires ou Open Source ; Gratuites ou payantes ;
Annuelles ou perpétuelles...
· Documentation et/ou tutoriels disponibles, formations en
ligne, accompagnement...
· Communauté autour du logiciel (en nombre de
personnes et en volume d'activité)
· Les références clients des éditeurs
(ex : rechercher des sociétés du même secteur
d'activité et se renseigner sur la solution BPM adoptée, faire un
Benchmark)
En outre, on peut déjà écumer les
applications selon les fonctionnalités présentes (ou pas) tel que
les modules de BAM, les relances automatiques, la possibilité de
modéliser et d'exécuter le processus dans le même
Framework...etc. Ce dernier point est important car il existe des
éditeurs qui ne proposent que l'un ou l'autre, ou bien les deux
séparément (modélisation et exécution).
4.3.2 La modélisation des processus
L'environnement permettant de représenter
graphiquement les activités et les processus est un critère
primordial dans notre choix. Il est en effet constamment utilisé et
reflète le mode de fonctionnement de l'application. C'est dans ce module
qu'on aura a modéliser et à réaliser une abstraction des
tâches accomplies selon notre vision de la chose. Il sera autant
accessible aux gens du métier qui devront le documenter le processus le
plus possible et en décrire les moindres détails, qu'aux
responsable des phases futures du développement et paramétrage de
l'application dans le BPM.
Le langage qui y est utilisé doit être de
préférence standardisé, l'on préconise l'usage de
la norme BPMN qui est de plus en plus utilisée et qui
semble répondre à la plupart des besoins exprimés dans la
modélisation des processus. L'objectif demeure la possibilité de
migrer ou d'évoluer dans d'autres environnements de modélisation
ou d'outils BPM dotés de moteurs d'exécutions compatibles
BPMN/BPEL.
Si le but de la démarche est d'étendre le BPM a
toutes les parties de l'organisation, il est vivement conseillé d'avoir
un modeleur capable de gérer les collaborations entre
différents processus et de matérialiser ces échanges
graphiquement.
Une fois qu'on a modélisé un processus, on aura
sans doute à le présenter à des dirigeants ou a des
collègues qui s'intéressent a notre projet. Certains logiciels
proposent la possibilité de projeter des diapositives construites
à partir de fragments de processus, cela peut s'avérer utile
quelquefois. Mais pour parer à toute éventualité, il
vaudra mieux choisir un outil qui dispose de la fonction de
documentation des processus qui permet renseigner chaque
détail concernant les activités - acteurs - Jalons... et de faire
des imports/exports de ces données en différents
format (Word, PDF, XPDL...etc.). Certain éditeur
propose même de publier ces modèles sur des portails internes
(comme SHAREPOINT) ou via des sites web ou autre WIKI.
Enfin, la modélisation peut s'avérer fort
ennuyeuse et nous prendre beaucoup de temps lorsque le logiciel ne sauvegarde
pas automatiquement, surtout lorsqu'on fait une fausse manoeuvre par
inadvertance et qu'on perd ainsi toute une journée de travail
(croyez-moi c'est du vécu !!). Ces détails auront beaucoup
d'importance a plus grande échelle.
4.3.3 Le modèle de données -
Référentiel
Nous avons déjà mentionné que l'un des
intérêts du BPM est la mise a disposition des employés des
informations utiles et agrégées pour éviter de perdre du
temps en se perdant dans des masses de données encombrantes. Ceci passe
inévitablement par le maintien d'un référentiel unique et
partagé par les processus et acteurs concernés qui se limitera
aux informations nécessaires a l'activité.
Certains outils nous donnent la possibilité de
construire nous même un modèle de données selon notre
perception sous forme de tables relationnelles (type MCD), alors que d'autres
proposent un remplissage au fur et à mesure, suivant la création
des tâches/activités. Les liens sont par la suite
générés automatiquement par l'outil qui les fournira aux
développeurs lors de la création des interfaces de la future
application.
4.3.4 La création des interfaces
utilisateurs
Le critère essentiel lors de cette étape est
d'avoir un accès facile et intuitif aux données que nous avons
établies a l'étape précédente. Les outils peuvent
cependant différer les uns par rapport aux autres dans la manière
de procéder pour construire les interfaces. On peut utiliser du code
pur, du glisser/déplacer, piocher les données directement
à partir du modèle construit ou bien les définir et les
lier ultérieurement au modèle. Ces deux dernières
façon de faire peuvent être très utiles dans quelques cas,
en particulier lorsqu'on imagine des données a rajouter aux formulaires
a construire au moment oü on les développe alors qu'on y avait pas
pensé lors de la construction du modèle.
Il peut y arriver de rencontrer des outils qui offrent la
possibilité de personnaliser ses formulaires selon la charte graphique
de son entreprise, cela améliore le rendu final et on obtient alors une
application « maison » qui aura le mérite de ne pas trop
dépayser les futurs utilisateurs. La navigabilité y joue aussi un
rôle important. Veuillez vérifier la présence de mise en
page avec des onglets ou des groupements de données qui facilitent la
lecture des formulaires.
4.3.5 Le moteur de règles métiers
L'utilisation d'un moteur de règles métiers
apporte les bénéfices suivants :
- Assurer la conformité avec la
réglementation ;
- Adapter rapidement le processus suite aux modifications
(temporaires ou définitives) de la politique (globales ou par services)
;
- Gagner en autonomie, donc en efficacité, en
offrant la possibilité aux chefs de service d'apporter des modifications
au processus vertical en fonction de leurs besoins.
Jérôme BESSON, 2009. (Product Manager
VDoc Software)
Le moteur de règles est le cerveau des applications
BPM. Il représente l'ensemble des algorithmes d'automatisation des
prises de décisions qui permettent de tracer les différents
chemins empruntés par un processus. C'est aussi le déclencheur
des activités/actions et des alertes automatiques (e-mails, warnings)
lorsque le processus se trouve dans un état particulier
prédéfini par l'utilisateur. Tous les calculs, les traitements de
données, les contrôles et les assignements se font via le moteur
de règles. L'agilité de l'application finale dépendra de
la flexibilité et de la puissance de ce moteur.
Il faut donc veiller scrupuleusement a vérifier
l'adéquation du moteur disponible dans une suite BPM avec les besoins
métiers des processus a implémenter. S'il y a des traitements
spécifiques à programmer, il se peut que cela nécessite
une intervention sur les couches inférieures du logiciel et donc une
expertise technique sera requise. (BDD, Batchs...)
Ce module doit être parfaitement maîtrisé
si on veut devenir capable de s'adapter très rapidement au moindre
changement qui survient, sans avoir à retoucher à la
modélisation des processus. Car les règles peuvent changer
à tout moment et évoluent dans le temps causant
généralement une redéfinition totale ou partielle des
processus. Une enquête d'IDC de début 2005
reflète que « plus de la moitié des entreprises qui
n'utilisent pas de solution de gestion des règles métier
modifieraient leurs processus métier plus fréquemment si elles
pouvaient réaliser ces changements plus simplement et de manière
plus économique. »
La modélisation des règles doit se faire donc de
préférence en syntaxe naturelle, afin que les responsables
métiers puissent aisément les faire évoluer.
4.3.6 Le déploiement et l'intégration au
système existant
Une fois qu'on aura alimenté l'application avec nos
règles métiers, il faut penser a la phase de déploiement
avec tout ce que cela implique comme prérequis techniques. Mieux vaut
prévoir plusieurs environnements de déploiement afin de dissocier
les étapes de développement, tests et production.
Concernant la greffe de l'outil BPM au SI existant, il nous
semble capital de choisir un environnement pouvant communiquer via des web
services. Même si cette technologie n'est pas encore
implémentée dans l'organisation concernée, cela se fera
inévitablement en raison de l'évolution actuelle que
connaît ce procédé ainsi que les standards XML.
Différents connecteurs à des applications
tierces sont proposés par des éditeurs en natif pourront
être utiles dans l'optique d'incorporer le BPM parmi l'existant d'une
organisation, nous pouvons citer parmi eux les connecteurs aux :
- Bases de données (pour la récupération
des informations) - Annuaires LDAP
- Serveurs de messageries
- Systèmes de gestion des fichiers
- Applications en lignes (Réseaux sociaux, Google
Apps...) - Systèmes BI/ETL
- D'autres outils BPM ou de modélisation de processus
Enfin, il est possible dans certains cas de coder
soi-même ses propres connecteurs à ses applications
métiers. C'est vrai que c'est plus efficace et plus rapide de disposer
de connecteurs prêts a être utilisés, mais cela peut servir
parfois lorsqu'on dispose d'applications internes incontournables.
4.3.7 L'exécution des processus
Nous rappelons encore une fois qu'il vaut mieux disposer d'un
moteur d'exécution compatible avec la norme BPEL pour
la réutilisabilité. À l'exécution des processus, on
s'intéressera premièrement a la présentation de la page
d'accueil de l'application et la manière avec laquelle les instances
créées sont affichées aux utilisateurs. Les cas sont
souvent présentés en liste ou comme une boite mail. On peut
parfois paramétrer les données concernant les processus a
afficher a l'accueil. Un indicateur permettant de connaître
l'état d'une instance donnée (traitée, en attente
ou en retard) est vivement recommandée, ainsi que la fonction de
visualisation du WORKFLOW et des enchainements suivis par l'instance.
La gestion des profils utilisateurs est
aussi à prendre en considération. Nous pouvons soit se connecter
et puiser directement les données de l'annuaire de l'entreprise, ou bien
construire au fur et a mesure une liste d'acteurs/hiérarchie/services
dans le cas de l'inexistence d'un pareil annuaire afin de pouvoir gérer
l'attribution des tâches aux acteurs attachés aux processus
déployés. L'affectation ainsi gérée répond a
un besoin de flexibilité requis par le moteur de règles
métiers qui doit savoir à chaque moment qui doit faire quoi, et
d'autre part a un souci de sécurité (qui a fait quoi) pour
l'application avec la sauvegarde des fichiers de logs et la possibilité
d'y effectuer des contrôles et audits.
4.3.8 La supervision des activités
Lors de cette étape, il faudra mettre l'accent sur la
nécessité de disposer d'indicateurs d'activité pertinents
pour le pilotage de ses processus. Au-delà des outils statistiques
disponibles dans la plupart des logiciels qui intègrent un module de
BAM, un besoin se fera vite ressentir en termes d'informations taillées
sur mesure a son activité. Il faudra donc penser à
vérifier la présence de fonctionnalités de
paramétrage et de personnalisation des requêtes spécifiques
pour disposer d'un tableau de bord efficace. Beaucoup d'éditeurs se
tournent désormais vers le monde du décisionnel en
intégrant des analyseurs multidimensionnels appliqués aux
données recueillies quotidiennement.
Les indicateurs de performance peuvent concerner le processus
au niveau macro, comme ils peuvent renseigner de l'état des tâches
les plus élémentaires en exposant leur nombre, durée, taux
de retard...etc.
Les différents graphes et courbes doivent être
clairs, lisibles et dans un format qu'on pourra exporter car ils sont à
la fois le reflet de l' « état de santé » du
système et la vitrine du BPM auprès des décideurs. On peut
trouver certaines applications munies de générateurs dynamiques
de graphes qui s'adaptent à chaque changement d'état d'un
processus.
Enfin, il existe des modules de BAM indépendants des
outils de BPM mais qui s'y intègrent sans grand effort (HP,
BIZTALK...etc.), qui sont plus robuste et destinés à traiter un
plus grand volume de données.
4.3.9 Autres facteurs importants
D'autres critères de choix indépendant des phases
de mise en place du BPM sont à prendre en considération, nous en
citons quelques-uns à titre d'information :
· La sécurité de l'application
· Ergonomie / Convivialité / Facilité
d'utilisation
· Support / Durée de vie / Gestion des upgrades et
versions
· Code Vs. Glisser/déplacer, sachant qu'un temps
énorme est économisé en utilisant la deuxième
option mais qui n'est hélas pas toujours la solution adoptée.
· Gestion du changement organisationnel
· La dualité technique/métier
· Visualisation de la charge globale de travail /
Ressources disponibles
· Intégrité des données
Cette liste n'est bien évidemment pas exhaustive, mais
elle résume avec toutes les phases qu'on a repassées en vue les
principales préoccupations, besoins et attentes des organisations
intéressées par le concept du BPM.
Conclusion
Au cours de cette étude réalisée tout au
long de l'année, nous avons rencontré de nouveaux concepts qui
sont d'actualité dans les entreprises et le milieu professionnel, et qui
attirent de plus en plus d'adeptes en raison de l'efficacité qu'ils
permettent d'acquérir et des résultats qui en découlent en
des temps records.
C'est pour cela que nous avons orienté notre travail
de façon à le présenter en forme de guide
réservé aux chefs de projets ou aux chefs de service conscients
de la nécessité de disposer de processus robustes et agiles
à la fois, et qui croient en la nécessité d'outiller ces
processus afin de mieux les comprendre et d'être réactifs aux
changements qui s'opèrent dans leur environnement.
Le pilotage et l'optimisation des processus
opérationnels étant une nécessité absolue, et
remarquant une explosion de l'offre des environnements de développement
des applications de BPM, il fallait donc proposer une démarche
pratique qui se base sur une expérience acquise lors d'un
projet de déploiement d'un BPM.
D'autres pratiques peuvent compléter cette
méthode, car le monde du BPM n'en est qu'à ses débuts et
n'atteindra sa maturité que lorsque les suites logicielles BPM seront
bien intégrées dans les SI aux cotés des ERP,
CRM...etc.
Il n'en reste que ces pratiques tourneront principalement
toujours autour des phases critique de la gestion des processus métiers
que sont la conception des processus avec le design graphique,
l'exécution, la supervision et l'optimisation, avec un
intérêt plus ou moins prononcé pour telle ou telle
étape du cycle selon le profil de l'utilisateur du BPM.
Ceci dit, la réussite du concept demeure
irrévocablement liée à celle d'autres pratiques et
technologies tel que le SOA, l'urbanisation et la bonne gouvernance.
Références
Bibliographie
· Les bases du BPM pour les nuls : Découvrez la
gestion des processus métiers - Edition spéciale SOFTWARE AG ;
Kiran GARIMELLA, Michael LEES, Bruce WILLIAMS | Editions WILEY
Publishing. ISBN : 978-0-470-37358-3
· Ingénierie des processus métiers : De
l'élaboration a l'exploitation ; Patrice BRIOL
Disponible gratuitement au téléchargement sur
http://www.ingenieriedesprocessus.net
· Urbanisation, SOA et BPM - Le point de vue d'un DSI
(3ème édition) ; Yves CASEAU |
Editions DUNOND - Juin 2008. ISBN : 978-2-10-051908-8
· Processus métiers et S.I. (2ème
édition) ; Chantal MORLEY, Jean HUGUES, Bernard LEBLANC &
Olivier HUGUES | Editions DUNOD - Novembre 2007. ISBN :
978-2-10-051568-4
· Designing the customer-centric organization: a guide to
strategy, structure, and process (1ère édition);
Jay R. GALBRAITH | Editions JOSSEY BASS/WILEY - 2005.
· Le Reengineering ; Michael HAMMER & James
CHAMPY | Editions DUNOD (4ème édition 1993).
ISBN : 2 10 007991 3
· Optimisation du processus d'approvisionnement en
environnements informatiques & mise en place d'un outil BPM ; Rapport de
stage de Master 2 MIAGE - Lamine GHEMATI | Université
Paris Ouest Nanterre La Défense - 2010.
Publications académiques
· Collaboration des Processus Métiers dans les
Echanges inter-entreprises (B2B) basée sur le Web Service Resource
Framework (WSRF) du Grid, thèse de magistère
réalisée par Melle Lydia Nadia KHELIFA |
Institut National d'Informatique (ALGER) - Février 2008.
· Mise en oeuvre d'un management des processus : Cadre
théorique et pratique managériale ; AVERSENG CELINE
- Professeur Agrégée doctorant CREGOR IAE de Montpellier
| Université de Montpellier II -
celine.averseng@univ-montp2.fr
· Gérer et reconfigurer les processus de
l'entreprise ; J. Akoka, I. Comyn-Wattiau
Articles de la revue trimestrielle
Système d'Information et
Management N°3, Vol. 10 - 2005 :
· Aligning Business and System Functionality through Model
Matching; Colette ROLLAND - Centre de recherche en
informatique | Université Paris 1 Panthéon
Sorbonne.
· Enrichissement de la modélisation des processus
métiers par le paradigme des systèmes multi agents ;
Denis BERTHIER, Chantal MORLEY & Michel MAURICE-DEMOURIOUX
- INT/GET | Groupe des Écoles des
Télécommunications.
· What are the secrets of successful Process Modelling?
Insights from an Australian Case Study; Wasana BANDARA & Michael
ROSEMANN | School of Information Systems, Queensland University of
Technology, Brisbane, AUSTRALIA.
· Performance des processus de coordination à
distance: une approche exploratoire; Valérie MICHAUX -
Docteur en Sciences de Gestion, Professeur REIMS Management School, Chercheur
au CRGNA LAGON | Université de NANTES.
· Caractérisation des dispositifs
d'interdépendance organisationnelle et mutualisation : le cas
des
centres d'appels virtuels ; Cécile CLERGEAU & Frantz ROWE |
Université de NANTES.
Université de Paris Ouest Nanterre La Défense
Mémoire de fin d'études Master 2 Professionnel -
MIAGE
Agilité des systèmes d'information et
E-Business
Réalisé par :
Lamine GHEMATI
2009 -
2010
(
lamine187@gmail.com)
| 
