| |
 |
Jean-François Pirus
P-DG
BPMS |
|
Jean-François Pirus
"Il y a autant de problématiques processus à gérer dans les services que dans l'industrie"
Répondant aux questions de nos lecteurs, le spécialiste du BPM a abordé le management des processus métier, de leur cartographie à leur implémentation.
12/05/2006 |
| |
|
 |
Comment définissez-vous un processus, et plus largement le BPM
?
Jean-François Pirus Dans un domaine où les définitions multiples et parfois contradictoires cohabitent, il y a un certain consensus sur la définition du processus : je le définis comme un ensemble structuré d'activités partageant une même finalité et employant pour cela des ressources humaines et techniques. Cette définition est proche de celle que l'on peut trouver dans la norme ISO, par exemple.
Concernant le BPM, que l'on traduit généralement par management des processus métier, nous avons à BPMS une définition très large, qui inclut les outils et méthodes relatifs à la formalisation, l'analyse, l'optimisation et l'automatisation des processus de l'entreprise. Les Anglo-Saxons distinguent le Business Process Analysis et le BPM qui dans cette acception est cantonnée à la dernière partie, l'automatisation
Le BPM, c'est réservé au grandes entreprises ?
Non, pas du tout. Certains outils de BPM, très onéreux, sont réservés aux grands comptes. Mais toute PME a des processus clés qu'il s'agit de maîtriser et d'optimiser. Il nous arrive d'intervenir dans des structures de moins de 100 personnes.
J'effectue une étude d'avant projet sur l'intégration d'un système workflow. J'aurais voulu savoir par quoi commencer lorsque l'on s'attaque aux processus ?
Pour commencer, il faut oublier l'outil (le logiciel de workflow à intégrer) et se concentrer exclusivement sur le(s) processus concerné(s) : a-t-on formalisé ces processus de manière adéquate ? Est-ce bien une vision cible ou cherche-t-on à reproduire l'existant ? Il peut arriver que l'existant donne satisfaction mais généralement on n'a pas pris le temps de se pencher sur les dysfonctionnements des processus.
| |
|
 |
|
|
 Pour commencer, il faut oublier l'outil et se concentrer exclusivement sur le processus concerné" |
|
La mise en place d'un outil de workflow n'est qu'un moyen. Ce n'est pas l'outil tout seul qui va optimiser le processus. Une fois un consensus établi sur les processus cibles - et cela peut prendre un peu de temps... -, le périmètre de mise en oeuvre de l'outil de workflow voire d'outils complémentaires - je pense à la GED - va ressortir naturellement. La phase organisationnelle du projet ayant produit ses livrables, le chantier purement informatique peut commencer.
Le BPM, qui a pour but de gérer l'ensemble des processus métier, est-il plus adapté à l'industrie qu'aux services ?
Il y a autant de problématiques processus à gérer dans les services que dans l'industrie ! Et elles recèlent souvent des gisements d'amélioration considérables, car la culture processus dans les services est parfois récente.
Quand on regarde les démarches d'optimisation des services dans les banques, dans l'assurance, dans la grande distribution, l'approche est similaire à ce que l'on peut faire dans l'industrie. Avec une différence notable, on aura moins d'automates et par conséquent de mesures objectives de la performance dans les services. Le BPM concerne tout autant un hôpital, qu'une organisation caritative ou une collectivité locale. C'est sa mise en oeuvre qui devra tenir compte du contexte.
Aujourd'hui, où en est-on de l'automatisation des processus ?
Si l'on parle de la France, on est moins avancé que certains pays anglo-saxons, comme l'Allemagne, le Royaume Uni ou les Pays-Bas. A cela, déjà un problème culturel : nous sommes des latins et la simple formalisation des processus nous donne l'impression de "graver dans le marbre" notre intelligence.
Convaincre un acheteur que la formalisation des critères de comparaison des offres est nécessaire et n'a rien à voir avec son savoir-faire, est un exercice parfois périlleux ! Une fois ce constat fait, la photographie va varier considérablement d'un secteur à l'autre.
On a commencé par les processus les plus informatiques. Quant on s'intéresse à la performance globale - le délai de traitement de bout en bout par exemple - d'un processus, on va mettre en évidence les "trappes à temps". Le dossier est en traitement chez untel. L'outil de BPM seul ne pourra qu'alerter. En résumé, il ne faut pas se contenter d'automatiser, il faut - surtout - piloter le processus. Dans tous les secteurs d'activité, il reste beaucoup à faire...
| |
|
 |
|
|
La modélisation des processus métier ne va pas de soi pour les opérationnels" |
|
Quand vous parlez de processus "cible", vous entendez les principaux processus de l'entreprise ?
Non, j'entends la version optimisée du processus (les anglophones vont parler de "TO BE") par rapport aux processus actuels ("AS IS"). La mise en oeuvre d'outils de BPM n'a d'intérêt que si l'on a procédé à une analyse organisationnelle préalable qui va permettre de travailler sur des processus - en théorie - améliorés.
Le BPM ne va t-il pas engendrer l'apparition de nouveaux métiers ?
Probablement. Typiquement, la modélisation des processus métier ne va pas de soi : si les informaticiens s'y mettent facilement, ce n'est pas forcément le cas des opérationnels. Je crois donc beaucoup à l'émergence d'un profil d'analyste processus - Business Analyst - qui serait positionné côté métier avec une double compétence modélisation / connaissance métier approfondie. En regard, il travaillera avec des "System Analyst" qui seront chargés de faire le lien avec le système d'information.
Côté pilotage, on voit également apparaître des responsables de processus, qui à l'instar de nouveaux métiers comme celui d'urbaniste SI, doivent parfois jouer des coudes pour exister !
Pour un fonctionnel, pensez-vous que le BPM soit vraiment abordable ? Comment vulgariser toutes les approches que vous manipulez au quotidien ?
Si, je peux vous rassurer, je suis un fonctionnel. Mon premier métier a été auditeur financier puis responsable informatique. Je n'ai aucune formation en informatique. Vulgariser tous ces concepts et expliquer que le management des processus métier est avant tout une problématique organisationnel, c'est un des objectifs que l'on s'est fixés avec le lancement du portail bpms.info il y a 3 ans. Mais la route est longue, je vous l'accorde.
Dans un chantier de BPM, quels sont les pièges à éviter ?
Déjà les pièges de tout projet : mal définir ses objectifs, son périmètre. Un de mes leitmotivs est "on modélise par rapport à un objectif". Le processus peut être très différent, suivant qu'on le regarde avec l'oeil du financier, de l'organisateur, du responsable qualité, de la DRH, ou de l'informaticien. Mal définir les objectifs du projet aboutit à de pas collecter les informations nécessaires à l'analyse du processus.
| |
|
 |
|
|
Le processus se décompose en sous processus, en tâches, on peut y mettre les applications informatiques en regard" |
|
La question du périmètre et du niveau de détail requis est toute aussi cruciale,sinon l'effet "poupée russe" peut frappe : le processus se décompose en sous processus, en tâches, on peut y mettre les applications informatiques en regard, les fichiers, les informations manipulées, les compétences requises... Cela ne s'arrête pas et l'on tourne en rond. Enfin, comme souvent, il vaut mieux enchaîner de petits projets plutôt que d'opter pour le big bang.
Chez nous, la mise en uvre d'un processus informatique métier transverse à l'entreprise parait compliqué politiquement et techniquement. Votre conseil ?
C'est sûrement plus compliqué politiquement que techniquement. La formalisation d'un processus transverse passe immanquablement par un consensus sur le qui fait quoi entre départements : on entre là dans les jeux de pouvoir et le projet peut s'enliser à ce stade.
Le seul remède est de s'assurer la présence d'un sponsor projet de niveau suffisant, apte à arbitrer les "questions qui fâchent". C'est réellement une condition déterminante de réussite car au delà du "qui fait quoi" se posera rapidement la question des indicateurs de mesure de la performance...
Pourriez-vous m'éclairer sur un point ; quelle différence entre procédures et processus ?
J'ai parlé des différentes façons de voir un même processus. La procédure doit être considérée comme la vision très opérationnelle du processus. Si vous formaliser votre processus au travers d'un outil de modélisation, vous allez certainement abandonner Word et demander à l'outil de générer automatiquement la procédure à partir des informations intégrées dans le référentiel. La procédure est en quelque sorte un document descriptif du processus, parmi d'autres.
La pierre d'achoppement du BPM n'est-elle pas la standardisation ?
Standardisation de quoi ? Des normes d'échanges entre outils ? Certainement. Les standards sont jeunes, très perfectibles et pour l'instant... pas standards ! (Je pense à BPEL par exemple). Mais dans d'autres domaines, les best practices, l'émergence de référentiels dits standards - ITIL, SCOR... - peut au contraire faire gagner du temps.
Quelle différence entre Business Intelligence et Business Activity Monitoring ?
Bonne question, d'autant que les éditeurs de BI ont tendance à affirmer qu'ils peuvent faire du BAM - c'est vendeur. En première approche, on peut dire que la BI dépend des données qu'elles manipulent, données qui sont rarement orientées processus (sauf si vous êtes déjà au sein d'un outil de BPM).
| |
|
 |
|
|
Les outils de Business Activity Monitoring ont cette capacité à reconstituer une traçabilité du processus" |
|
Les outils de Business Activity Monitoring ont cette capacité à reconstituer une traçabilité du processus à partir de systèmes d'information hétérogènes qui n'ont pas été conçus pour cela.
Le SI va souvent se contenter de conserver des photographies du processus à un stade donné alors que l'on a besoin de "reconstituer le film". Les outils de BAM ont cette capacité et sont souvent plus orientés temps réel (alertes,...).
BPMS n'est pas un éditeur. Quel est son rôle concrètement ?
BPMS est un cabinet de Veille et Conseil en management des processus, indépendant des acteurs du marché. Côté veille, nous éditons le site BPMS.info (que nous ouvrons régulièrement à des contributeurs externes), côté conseil, nous intervenons plutôt en assistance maîtrise d'ouvrage sur des problématiques d'analyse et d'optimisation de processus.
Cela peut déboucher sur des enjeux de mise en oeuvre d'outils et dans ce cas notre double compétence est appréciée mais c'est loin d'être systématique. On peut optimiser un processus simplement en formalisant ses règles de gestion !
Jean-François Pirus : C'était une première pour moi mais l'expérience est à renouveler. Ceux qui n'ont pas pu poser leur question et qui en sont très frustrés peuvent toujours nous la poser via le site. Merci à tous et bonne soirée.
|
| |
Propos recueillis par Antoine CROCHET-DAMAIS, JDN Solutions |
|
