5 facteurs clés de succès pour mettre en oeuvre une application ECM-BPM

23 novembre 2009

dans BPM

5 facteurs clés de succès pour vos applications ECM BPM

L’idée de cette note m’est venue récemment après avoir échangé avec plusieurs clients et prospects sur la facilité – ou non – de mettre en œuvre et déployer une application de BPM/ECM. En repensant à tous ces échanges, et aux nombreuses expériences vécues ou qui m’ont été relatées depuis ces dernières années, j’ai tenté de lister ici ce qui, pour moi, est un facteur de succès – ou d’échec – lors de la mise en œuvre d’une application ECM/BPM.

Etude IBM menée auprès de 1 500 responsables de la conduite du changement sur des projets de transformation dans 15 pays intitulée « Making Change Work », 60% des projets n’atteignent par les objectifs fixés au départ. L’étude reprend la réflexion entamée par la CEO Study intitulée « l’Entreprise de Demain » et confirme ses résultats.

1- Avoir le support de la Direction Générale
Dans la mesure où la mise en œuvre d’une application de BPM implique un changement des méthodes de travail et des éléments de mesure de la performance, il est impératif d’avoir l’appui de la Direction Générale et son soutien au quotidien. Sans volonté délibérée de la DG de supporter le déploiement de telles applications, il est très difficile d’arriver à ses fins : résistance au changement, divergences d’opinions, difficulté à arriver à un consensus, intérêts personnels, etc. la liste des éléments perturbants serait longue et il faut absolument avoir de son côté une Direction qui comprend les enjeux et sait prendre des décisions le moment venu.

2- Disposer du bon niveau d’expertise fonctionnelle
BPM comme ECM sont des domaines où il est très important de disposer d’un savoir-faire, d’une expérience réelle, d’un vécu en matière d’analyse fonctionnelle. Les aspects techniques sont également importants mais je reste persuadé qu’une analyse fonctionnelle mal réalisée ne peut pas permettre d’aboutir à une application pertinente et à son adoption par les utilisateurs. L’expression de besoins, à l’initiative d’un groupe restreint d’utilisateurs, doit définir le cadre – « voilà comment nous souhaitons travailler » – et l’analyse fonctionnelle (ou spécifications fonctionnelles détaillées) doit définir le comment – « voilà comment nous allons travailler ». Ce n’est pas nécessairement la même chose.
Si vous pensez ne pas disposer de l’expérience requise en la matière, il est impératif de faire appel à une ressource spécialisée qui saura vous faire profiter de son expertise et qui pourra capitaliser sur ses expériences vécues, bonnes comme moins bonnes.

3- Impliquer les utilisateurs très tôt
Combien de fois ai-je entendu « c’est trop complexe à utiliser » ou « ce n’est pas comme ça que l’on travaille » ou encore « c’est bien mais on a du mal à s’y faire ». Il est impératif d’impliquer les utilisateurs, un groupe de personnes au fait du métier et aptes à penser différemment de façon positive, de telle manière que toute expression fonctionnelle, toute fonctionnalité demandée, toute forme de mise en œuvre soit validée par ces gens là. J’ai encore en mémoire un Directeur de Projet m’expliquant que le succès de l’application métier BPM qu’il venait de mettre en service l’était en grande partie parce que les utilisateurs avaient pu choisir dans les interfaces applicatives l’emplacement des différents boutons et leurs libellés. Autre conséquence de cette implication, le fait d’aboutir à un consensus impératif dès lors que l’on parle de processus métier : autre cas vécu, celui de ce groupe de 30 comptables qui décrivaient chacun à leur tour leur processus de gestion de factures fournisseurs et pour lequel nous sommes arrivés à 30 versions différentes à la fin du tour de table. Inutile de dire que la 31ème version, consensuelle, fût difficile à obtenir mais remporta l’adhésion car elle avait été élaborée par l’ensemble des personnes concernées.

4- Choisir un périmètre fonctionnel simple
Une des erreurs fréquentes est de vouloir démarrer avec l’application la plus complexe car « cela réglera la plupart des problèmes ». Echec assuré. Dès lors qu’il s’agit de mettre en œuvre une application qui touche au métier de l’entreprise, qui provoque un changement dans les habitudes, qui nécessite une conduite de ce changement, il est impératif de choisir l’application la plus simple à mettre en œuvre tout en étant suffisamment pertinente pour présenter un intérêt immédiat : on approche une nouvelle technologie, de nouvelles méthodes de travail, il faut adopter des comportements différents, aller au-delà des appréhensions, inutile de choisir le processus le plus complexe, vous aurez bien assez de choses à gérer avec une application simple pour commencer. De plus le succès de la mise en œuvre d’une application certes simple mais pertinente – ne pas négliger cet aspect non plus – sera un autre facteur de succès pour les applications à venir. Vous aurez fait la preuve que « ça peut marcher » et l’image que vous donnerez sera positive, facilitant d’autant plus l’envie de mettre en œuvre d’autres applications. Mieux vaut un projet simple mené à son but et une application opérationnelle qu’un projet complexe qui traîne en longueur ou part en échec avant la fin.

5- Impliquer l’éditeur
Je suis bien placé pour savoir que l’éditeur, qui n’est pas uniquement que celui qui cherche à vendre ses licences et part vite ailleurs ensuite (!!), a une responsabilité importante dans la mise en œuvre des projets. C’est généralement lui qui détient l’expertise produit ultime pour aider à la bonne réalisation des applications, réalisation qui sera le fait d’une maîtrise d’œuvre spécialisée bien évidemment – intégrateur certifié, équipes internes formées – et sans laquelle la garantie de succès se trouve altérée. L’éditeur a le savoir-faire pour valider les choix fonctionnels comme techniques, mais il a aussi la capacité à supporter les projets et à anticiper les obstacles. Il est toujours plus simple de prévenir que de guérir, et impliquer l’éditeur en amont permet d’avoir son soutien tout au long du projet. De même l’éditeur saura agir avec plus de souplesse dès lors qu’un problème technique quelconque surviendra dans la mesure où il aura été impliqué précédemment et saura dans quel contexte le problème survient.

Cette liste ne se veut pas exhaustive mais elle est représentative des nombreux projets auxquels j’ai pu être confronté, ou qui m’ont été relatés. Je vous invite à la compléter avec vos expériences personnelles, à défendre des positions différentes, à donner une autre vision, c’était aussi un des buts de cette note que de faire réagir sur le sujet.

*Photo (C) Search Engine People Blog

Lire la suite :

Les commentaires sont fermés sur cette entrée.

Article précédent :

Article suivant :