Accompagnement au changement et Valeur d'usage

Le vieux Paris n'est plus (la forme d'une ville
Change plus vite, hélas! que le cœur d'un mortel);

Et mes chers souvenirs sont plus lourds que des rocs.

Charles Baudelaire, Le cygne

L’objectif de la conduite du changement est de développer la valeur d’usage du produit acheté [On ne s’éloigne pas trop de Baudelaire qui est un contemporain de Marx]. Le produit  (ici un logiciel ou un SAAS) est acheté en fonction des qualités qui lui sont attribués : réduction des coûts, amélioration du processus, meilleure qualité du service. L’acquéreur souhaite que le produit ou le service réalise le résultat attendu pour le coût déterminé et dans les délais prévus.

Toutefois ces avantages attendus ne sont pas acquis avec le produit, ils dépendent

• de la bonne intégration du logiciel,
• de sa contextualisation c’est-à-dire de son intégration dans les processus de l’organisation,  
• de l’utilisation de ses fonctionnalités qui correspondent aux besoins des utilisateurs
• de sa compréhension par les utilisateurs.

L’acquéreur souhaite donc développer la valeur d’usage du logiciel afin que celle-ci soit conforme voire performe sa valeur d’échange (c’est-à-dire le prix d’acquisition, d’installation et de maintenance du logiciel) : optimiser le ROI du service.

Un premier point semble allez de soi : L’acquisition du nouveau logiciel correspond au besoin de l’organisation et des utilisateurs. Ce n’est pas toujours le cas notamment le remplacement peut être imposé par des évolutions technologique.

Exemple :

Dans cette organisation le logiciel précédent était développé en interne, toutes les demandes des utilisateurs étaient  acceptées mais au prix d’un coût important de maintenance, d’une dépendance totale vis-à-vis des informaticiens chargés du développement, d’une complexité croissante et de l’impossibilité de suivre les nouveautés technologiques. Pour les utilisateurs l’outil était parfait mais pour l’organisation ce mode de fonctionnement devait cesser.

Même si le service correspond à la fois au besoin de l'organisation et à ceux des utilisateurs il faut s'engager à augmenter sa valeur d’usage :

1. Limiter la durée de perte de productivité due au changement (lien) : identifier et mesurer le risque, mettre en place les actions adéquates.
2. Développer les gains de productivité sur les processus qui sont performés
3. Optimiser les interactions entre le logiciel et les processus en identifiant les points positifs et les points négatifs.

Conseil pratique :

Identifier un processus existant qui est manifestement sous-performant et que l’outil va optimiser radicalement. Cette optimisation évidente et chiffrée permet de légitimer le changement. Ainsi nous gagnons du temps pour mener les actions de réduction de la perte de productivité et conduire les actions d’optimisation.

Identifier les catégories d’utilisateurs qui sont le plus impactés (positivement ou négativement par le changement). Les actions d’accompagnement vont alors se clarifier.

Les principes de la conduite du changement sont les suivants : savoir, comprendre, agir. Et se mobiliser (plaquette greenpeace)

Savoir, comprendre (appelé également diagnostic)

Agir et se mobiliser (appelé également levier): les verbes d’action associés sont les suivants :

• auditer, mesurer, écouter, formaliser les pratiques existantes
• communiquer, informer, participer
• former, apprendre
• documenter
• organiser, intégrer

L’accompagnement au changement se déroule dès la prise de décision et durant toutes les phases du projet.

• L’étude d’opportunité est un document clé de la conduite du changement : le logiciel doit correspondre aux besoins de l’organisation – Engagement de la direction, définition des raisons du changement et des objectifs. Communication partager ces objectifs avec les utilisateurs, définition planning.

• La phase de rédaction du cahier des charges et du choix solution: le logiciel doit correspondre aux besoins des utilisateurs - création d’un premier groupe projet –. Communication à l’ensemble de la société.

Conseil pratique :

Plutôt que de réaliser frontalement le cahier des charges, intégrer le groupe d’utilisateurss référents dans une phase d’analyse des processus et confier la rédaction du cahier des charges à un consultant extérieur ou à un chargé de mission.

Vérifier dans un service ne participant pas à la démarche et peut-être moins performant, l’écart entre les processus décrits par les référents et les pratiques existantes.

• Lors de la phase de spécifications il est parfois difficile d’intégrer les utilisateurs : Problème de disponibilité, langage spécifique de l’éditeur qui peuvent rebuter l’utilisateur. Il est préférable de mettre les utilisateurs référents en position d’arbitre sur les points clés des spécifications (attention aux délais de réponse exigés et à la question de la responsabilité). Par contre c’est la phase où l’on passe du rêve (ce qui a été vendu) à la réalité (ce qui fonctionne dans le logiciel). Il est indispensable à ce niveau de confronter les processus au produit et d’identifier les points de risque.

Conseil pratique :

Parallèlement aux ateliers  faire une cartographie de l’outil et des processus : points d’adhérence et d’écarts, niveau de paramétrage nécessaire, optimisation à prévoir, points de risques. Cette cartographie n’est malheureusement jamais effectuée à ce moment du projet. Cette information est plus importante pour la direction qui ne se passionne pas pour les spécifications fonctionnelles (vous l’aviez certainement remarqué)

Si les utilisateurs ne participent pas aux ateliers de spécification il faut bien noter tous les écarts entre le cahier des charges et les spécifications.

• La phase de recette fonctionnelle devrait suivre une phase de test unitaire (sous la responsabilité de l’éditeur intégrateur). Trop souvent on confond la recette avec les tests unitaires et n’effectue pas réellement de recette des processus (comment fonctionne l’outil par rapport à mes processus) en se mettant à la place de l’utilisateur et dans son contexte de production.

Conseil pratique :

Lorsque l’on effectue une recette par processus il faut clairement distinguer en sortie du test les anomalies (écart avec les spécifications) et les problèmes liés au processus : besoin d’accompagnement supplémentaire de l’éditeur pour affiner la contextualisation de l’outil (souvent modification de paramétrage) ou action de conduite du changement.

• La phase de pré-démarrage où se concentrent les actions de formation. Trop souvent c’est ici que l’on se préoccupe de la conduite du changement. Il est déjà trop tard.

• La phase de démarrage où l’on découvre le gap entre les pratiques et l’outil mis en place (si l’on n’a pas au préalable mené les actions de conduite du changement). Lors du démarrage, on a prévu une série d’action d’accompagnement des utilisateurs et de remontée des informations (toujours le « connaitre ») Si les actions de conduite du changement ont été mené depuis le début, on aura une assistance au démarrage par les utilisateurs eux-mêmes.

Le démarrage est une réussite alors enclenchons immédiatement la phase 2 du projet. Il y a obligatoirement des améliorations à faire et vos utilisateurs sont dans les meilleures conditions pour participer à un projet.

Là, tout n'est qu'ordre et beauté,
Luxe, calme et volupté.

Charles Baudelaire l'invitation au voyage