Geoconcept
Field service management Tendances | 5 MIN DE LECTURE

3 dimensions clés pour une conduite du changement réussie dans le field service management

 23 déc. 2019

Crédits photo : Fauxels - Pexels

Le déploiement d’une solution de planification et d’optimisation des interventions sur site est par nature un projet d’entreprise : transverse, impliquant nécessairement la DSI, certaines fonctions support et, impérativement, les directions opérationnelles et équipes métiers. Que vous vous équipiez pour la première fois, que vous changiez de solution ou de version d’un outil existant, ce projet va entraîner des refontes de processus plus ou moins profondes, transformer les habitudes de travail et impliquer de nouveaux gestes quotidiens – pour les techniciens de terrain, bien sûr, mais aussi pour les ordonnanceurs et les planificateurs, les responsables d’agence ou de région...

C’est la raison pour laquelle aucun projet de ce type ne peut pleinement réussir sans mettre en place une conduite du changement visant à impliquer les utilisateurs le plus en amont possible et à les accompagner dans l’adoption et la maîtrise de leur nouvel outil de travail. Si de nombreuses entreprises l’ont compris, il est important d’insister sur 3 dimensions pas toujours bien appréhendées, parfois minimisées, mais qui conditionnent largement la réussite du projet.

La conduite du changement, c’est dès le début du projet !

On voit encore trop souvent apparaître la conduite du changement à la toute fin des projets, une fois que toute la partie fonctionnelle est calée et prête à être déployée. Elle se résume alors peu ou prou à un plan de formation, ce qui est certes indispensable mais qui revient à mettre les utilisateurs finaux devant le fait accompli : voilà votre nouvel outil, on ne peut plus rien y changer, à vous de vous y adapter. Si vous vous y prenez de cette manière, vous risquez de susciter plus de résistances que de réactions enthousiastes…

Les méthodologies de gestion de projet « agiles » limitent considérablement ce risque en plaçant les utilisateurs finaux et leurs besoins concrets au cœur du processus dès le début du projet. Comme il est matériellement impossible d’associer la totalité des utilisateurs à toutes les étapes, le dispositif préconisé consiste à mettre en place dès le début :

  • Un product owner (PO) – Mandaté pour la durée du projet, c’est dans l’idéal un opérationnel, déchargé de ses autres responsabilités. Au sein de l’équipe projet, il est le représentant des utilisateurs du produit à construire. Ni chef de projet au sens classique du terme, ni donneur d’ordre, le PO est avant tout le maître des besoins et l’arbitre des priorités.
  • un groupe de « key users » – Qui sont ces key users ? Des utilisateurs représentatifs de la diversité de la population impactée par le projet. Cette représentativité s’entend en termes de métiers, de zones géographiques mais aussi d’ancienneté dans l’organisation.

On considère souvent que les plus « anciens » dans l’entreprise sont aussi les plus réticents au changement. Mais ce sont aussi ceux qui connaissent le mieux leurs collègues, les réalités et les contraintes du terrain, les outils en place avec leurs avantages et leurs inconvénients. Ces connaissances sont indispensables à l’équipe projet lors des phases de cadrage, de définition de la cible à atteindre et de validation des réalisations.

lissage-des-charges-de-travail

Quelle que soit leur ancienneté, tous les membres du groupe utilisateurs jouent, dès le début et tout au long du projet, un rôle décisif dans la conduite du changement – celui d’ambassadeur auprès des autres utilisateurs. Comment ? En les informant au fur et à mesure de l’avancement du projet, en remontant à l’équipe projet les réactions et les craintes éventuelles du terrain, en contribuant à la définition du plan de formation et en étant eux-mêmes des relais de formation et de support une fois la solution en production.

Point souvent oublié : pour jouer pleinement leur rôle, les key users doivent être déchargés d’une partie de leurs tâches opérationnelles, y compris après la mise en production de la solution si l’on veut qu’ils restent des interlocuteurs de référence pour la communauté des utilisateurs.

Mettre en avant la création de valeur pour les utilisateurs

Un changement d’outil métier est d’autant plus facile à promouvoir et devient d’autant plus désirable que chaque personne impactée y trouve de la valeur ajoutée pour elle. Bien sûr, tout le monde sera sensible à l’idée de gagner en efficacité, en productivité et d’améliorer ainsi la performance globale de l’entreprise. Mais avant d’adhérer, chacun se pose inévitablement la question : concrètement, qu’est-ce que cela va changer pour moi au quotidien, au niveau de ma charge de travail, de mes horaires, des types d’interventions, du nombre de kilomètres parcourus…

Un des objectifs de la phase de cadrage est précisément d’identifier les changements majeurs attendus de la nouvelle solution et de les décliner en bénéfices concrets pour les différentes catégories d’utilisateurs. Par exemple, si vous passez de plusieurs outils à une solution intégrée comme Opti-Time, les techniciens de terrain n’auront plus besoin de jongler entre plusieurs applications sur leur terminal mobile pour consulter leur planning et notifier un client. Les planificateurs apprécieront pour leur part que les contraintes RH individuelles soient pré-intégrées dans la solution et automatiquement prises en compte dans le remplissage des plannings.

Si vous appliquez vraiment les principes « agiles », ce sera plus facile parce que la règle est de partir des besoins formulés par les utilisateurs en termes positifs : « pouvoir notifier un client de mon retard en un clic », « je veux que ma première intervention de la journée soit la plus proche de mon domicile », « avoir des plannings basés sur des temps d’intervention réalistes »… Tous les souhaits/besoins ne pourront sans doute pas être satisfaits, mais ils seront discutés, arbitrés et priorisés de manière transparente et argumentée, à l’aune de l’économie générale du projet et des éventuelles contraintes liées au système d’information existant.

Un chantier « données » à part entière

Votre moteur d’optimisation se nourrit de données et sa valeur ajoutée est directement dépendante de la disponibilité et de la qualité de ces données. C’est pourquoi un projet de déploiement bien mené comporte en réalité deux chantiers qui doivent être conduits en parallèle : un chantier fonctionnel et un chantier dédié aux données. Ne pas travailler sur les données, faire l’impasse sur le nettoyage et l’assainissement des différents référentiels qui alimentent la solution, c’est se mettre dans l’incapacité de tenir les promesses d’amélioration faites aux utilisateurs et donc les décevoir.

a-chaque-grand-metier-son-mode-de-planification

Par exemple, si vos techniciens interviennent dans la grande distribution et chez les commerçants, les horaires d’ouverture de chaque magasin, petit ou grand, sont des données indispensables pour l’organisation des plannings et des tournées. Si ces données sont inexactes ou incomplètes, les premières tournées calculées par votre nouvel outil risquent d’être chaotiques… Si vous voulez envoyer automatiquement des avis de passage à vos clients, encore faut-il savoir à qui les envoyer : où sont les adresses e-mail, sont-elles valides, est-ce que ce sont celles des bons interlocuteurs pour le technicien ? Si vous voulez renforcer l’adéquation entre compétences des techniciens et types d’intervention, vous avez besoin des données RH, etc.

Le point de départ du chantier « données » de votre projet est de lister et localiser toutes les sources de données dont le moteur va devoir tenir compte :

  • les installations de vos clients (adresse exacte pour le géocodage, mais aussi interlocuteurs, type de matériel/équipement, horaires…) ;
  • la typologie des interventions ;
  • les compétences et conditions d’intervention des techniciens ;
  • la disponibilité des ressources (véhicules, agence/dépôt de rattachement, pièces de rechange…) ;

Il faut ensuite mettre en place un plan d’action et un calendrier d’assainissement de ces différentes catégories de données. Ce calendrier doit évidemment être compatible avec celui de la partie fonctionnelle. Le plan d’action « données » doit en outre préciser les normes de qualité à respecter, qui est responsable de l’assainissement des différents référentiels et les procédures visant à maintenir la qualité de données dans la durée.

Tout cela vous paraît peut-être très éloigné de l’idée que vous vous faites de la conduite du changement. Mais croyez-nous : l’expérience que nous avons de la mise en œuvre de nos solutions de field service management dans les grandes organisations nous permet d’affirmer que ces trois dimensions sont absolument clés pour atteindre l’objectif de tous les projets : livrer aux utilisateurs une solution à laquelle ils adhérent et qu’ils adoptent parce qu’elle leur apporte une valeur ajoutée tangible au quotidien.

Vous aimerez aussi :

[Interview] La planification des interventions de ...

Field Service Management : plongée dans le quotidi...