Conduite du changement et spécificat​ion: chemins parallèles ou même combat ?

Depuis quelques années, la conduite du changement s’est professionnalisée et l’on est bien loin des plans de formation accompagné de quelques supports originaux. Pourtant, lors de l’élaboration des projets CRM, j’entends parfois que « la conduite du changement, c’est une option, on va se focaliser sur la formation des formateurs et des utilisateurs clés en phase de recette« .

Malgré tout ce que l’on sait sur les risques d’échec des projets CRM, les SSII et les clients rognent parfois sur ce budget. Bien entendu, le discours des cabinets de conseil n’est pas du tout le même : l’alignement des processus, voire l’optimisation, et la conduite du changement sont des axes clés de leurs interventions.

Ma position ne me permet pas de dévoiler ici les approches et méthodologies que j’ai pu croiser. Elles relèvent de l’expérience et de l’effort d’investissement des sociétés chez lesquelles je suis intervenu: ce sont des éléments de différenciation envers la concurrence, confidentiels.

Néanmoins, je crois que les approches conduite du changement (change) en SSII ont du mal à se positionner par rapport aux phases de cadrage, de spécification et de maquettage (build) des projets d’implémentation de solutions CRM et que c’est pour cette raison que le change est encore vu comme une option.

Dans le cadre d’un récent projet de migration d’une solution CRM vers une autre (périmètre fonctionnel constant et pas de refonte des processus en vue) où la contrainte de délai était forte, les 3 points clés étaient la migration des données, l’intégration au système d’information existant et l’adhésion des utilisateurs à leur prochaine application CRM.

J’ai donc détaillé le point de rencontre entre les deux démarches build et change via le schéma ci-dessous.

L’un des points d’analyse du change étant l’analyse préalable du changement et de son impact sur les utilisateurs, j’ai considéré que les ateliers de spécifications (design) fournissaient la matière première à l’équipe change :

• maquette de la future application, permettant une présentation auprès de quelques utilisateurs ;
• spécifications des processus et modes opératoires, permettant de mesurer le changement ;
• liste des points d’achoppement non résolus (backlog) en atelier et en comité de pilotage, où l’enjeu est de positionner le curseur entre développement spécifique, pour ressembler à l’existant où à la cible espérée, et l’accompagnement du changement.

A l’issue des ateliers spécifiques du change, le backlog peut revenir sur la table en comité de pilotage avec une recommandation. L’équipe change devient alors un intervenant tiers dont l’angle d’approche est différent et complémentaire de celui de l’équipe projet.