Remplacer un système CAFM semble assez simple à première vue. Choisir une nouvelle solution, exporter les données de l’ancien système, les importer dans le nouveau et poursuivre ses activités.

Si seulement une migration était aussi simple.

Un système CAFM utilisé depuis dix ou quinze ans contient bien plus qu’un ensemble d’enregistrements dans une base de données. On y trouve des bâtiments et des espaces, des équipements, des contrats et des documents, mais aussi des processus, des responsabilités, des interfaces, des données historiques et, bien souvent, quelques solutions de contournement dont plus personne ne sait vraiment pourquoi elles ont été mises en place.

Transférer tout cela d’un système à un autre ne se résume donc pas à un projet informatique. C’est aussi l’occasion de se poser une question qui passe facilement au second plan dans le quotidien opérationnel : voulons-nous vraiment continuer à travailler de cette manière ?

La réussite d’une migration CAFM ne se mesure pas à la fidélité avec laquelle l’ancien système a été reproduit dans le nouveau. Une migration est réussie lorsque l’organisation peut ensuite travailler plus efficacement, avec des informations de meilleure qualité et des processus réellement adaptés aux besoins des utilisateurs.

Dans la pratique, pourtant, les mêmes erreurs reviennent régulièrement.

Erreur n° 1 : commencer sans avoir clairement défini les raisons du changement de système

Erreur n° 2 : tout migrer simplement parce que les données existent

Erreur n° 3 : supposer qu’un export contient tout ce qui est visible dans l’ancien système

Erreur n° 4 : vouloir tout changer en même temps

Erreur n° 5 : impliquer les utilisateurs trop tard

La bonne nouvelle, c’est qu’aucune de ces erreurs n’est inévitable. La plupart peuvent être évitées avant même que le premier jeu de données ne quitte l’ancien système.

Erreur n° 1 : commencer sans avoir clairement défini les raisons du changement de système

La première question à se poser lors d’une migration CAFM ne devrait pas être : comment allons-nous extraire les données ?

Elle devrait être : pourquoi changeons-nous de système ?

Il existe généralement une bonne raison. Le logiciel actuel n’est peut-être plus développé ou pris en charge. Les coûts ont peut-être augmenté, certaines fonctionnalités importantes font défaut, les rapports ne répondent plus aux besoins, le support est insuffisant ou les processus existants sont devenus inutilement complexes.

Quelle que soit la raison, elle doit guider la suite du projet.

Si le système actuel complique inutilement la maintenance, la migration doit permettre de l’améliorer. Si les informations sont difficiles à trouver, la nouvelle solution doit en faciliter l’accès et l’utilisation. Si la création de rapports récurrents nécessite encore plusieurs exports, des corrections manuelles et le rapprochement d’informations provenant de différentes sources, la migration est l’occasion idéale de se demander pourquoi.

Sans objectifs clairement définis, il est pourtant étonnamment facile de reproduire l’existant.

Les mêmes structures sont conservées. Les mêmes processus perdurent. Et parfois, même les mêmes solutions de contournement trouvent leur place dans le nouveau système.

Le système est nouveau. Les raisons qui avaient conduit à remplacer l’ancien, elles, sont toujours là.

Comment éviter cette erreur

Avant d’aborder les détails de la migration, définissez ce qui doit réellement s’améliorer après le changement.

Identifiez les faiblesses de la situation actuelle, déterminez quels processus doivent être améliorés et convenez des exigences essentielles pour les opérations futures. Définissez ensuite comment vous pourrez vérifier que le changement a effectivement produit les résultats attendus.

Le projet dispose ainsi d’un point de référence clair pour toutes les décisions qui suivront.

Erreur n° 2 : tout migrer simplement parce que les données existent

Une idée étonnamment tenace revient dans les projets de migration : si une donnée existe, c’est forcément qu’elle est importante.

Le raisonnement est compréhensible. Après tout, quelqu’un l’a saisie, mise à jour ou importée un jour. Il devait bien y avoir une raison.

Peut-être. En 2014.

Les bases de données CAFM s’enrichissent au fil des années. Les bâtiments évoluent, les espaces sont réorganisés, les équipements sont remplacés, les contrats arrivent à échéance et les responsabilités changent. Les conventions de nommage évoluent elles aussi, et les informations peuvent être gérées différemment selon les services ou les sites. Certaines données sont soigneusement tenues à jour. D’autres sont toujours là principalement parce que personne n’a jamais eu de raison de les remettre en question.

Et tous les problèmes ne sont pas visibles à l’échelle d’un enregistrement individuel.

Un équipement peut, par exemple, être indiqué comme hors service alors que des opérations de maintenance actives lui sont encore attribuées. Pris séparément, les deux enregistrements peuvent sembler parfaitement valides. Mais lequel reflète la réalité ? Il faut le déterminer avant de décider ce qui sera transféré dans le nouveau système.

Tout migrer simplement parce que les données sont disponibles peut sembler être l’option la plus sûre. Rien ne se perd et aucune décision difficile ne doit être prise avant le transfert. Le problème, c’est que le nouveau système risque alors de commencer sa vie opérationnelle avec les informations obsolètes, contradictoires ou inutiles héritées de l’ancien.

Toutes les informations ne méritent donc pas le même traitement. Selon leur pertinence, leur qualité et leur utilité future, les données peuvent être transférées directement, nettoyées ou consolidées, conservées dans une archive ou délibérément laissées de côté. Dans certains cas, repartir sur une base de données propre peut être plus pertinent que de transférer des informations obsolètes ou incomplètes.

Quelles données doivent réellement être transférées ?

Il ne s’agit pas de règles automatiques. Un « équipement actif » ne doit pas nécessairement être transféré dans le nouveau système simplement parce que son statut indique qu’il est actif. De la même manière, un ancien enregistrement ne doit pas automatiquement être archivé uniquement en raison de son âge. Sa finalité, sa qualité, ses dépendances et son utilisation future doivent également être prises en compte.

Comment éviter cette erreur

Décidez quelles données doivent faire partie de la migration et dans quel état elles doivent arriver.

Vérifiez quelles informations sont encore pertinentes, quels enregistrements sont obsolètes ou incomplets, où se trouvent les doublons et quels jeux de données n’ont pas été tenus à jour de manière fiable.

Demandez-vous si les données historiques sont réellement nécessaires aux futurs processus ou si elles doivent simplement rester accessibles à des fins de documentation ou de conformité.

Transférer correctement des données dont la fiabilité est douteuse ne les rend pas plus fiables. Cela signifie simplement que le transfert a fonctionné.

Erreur n° 3 : supposer qu’un export contient tout ce qui est visible dans l’ancien système

« Nous avons les données. »

Cette phrase est moins rassurante qu’elle n’en a l’air.

Ce que les utilisateurs voient dans un système CAFM établi ne correspond pas nécessairement à ce qui peut en être extrait. Les informations affichées dans l’application peuvent dépendre de tables liées, de valeurs calculées ou de la logique interne du système. Un export peut contenir les différents enregistrements sans inclure les identifiants et les relations qui leur donnent tout leur sens.

Prenons l’exemple d’une porte coupe-feu. Dans l’ancien système, son emplacement, son calendrier d’inspection, le prestataire responsable et le dernier rapport d’inspection peuvent être accessibles depuis un même enregistrement. En arrière-plan, ces informations peuvent toutefois être stockées dans différentes tables ou reliées par des références internes. Si l’export contient les différents enregistrements, mais pas ces références, la porte et le document sont bien présents, sans qu’il soit possible de les relier de manière fiable.

Les données ont été extraites. Le contexte qui leur donnait leur utilité, lui, ne l’a pas été.

Et extraire les informations ne représente que la moitié du travail.

Même un export complet doit encore pouvoir s’intégrer dans le système cible. Les champs, classifications, valeurs de statut, identifiants et hiérarchies peuvent y être structurés différemment. Une valeur source telle que « Statut 3 » ne peut pas simplement être transférée si sa signification dans le système cible n’a pas été définie. Il en va de même pour les relations : savoir que deux enregistrements sont liés ne suffit pas à indiquer au nouveau système comment représenter cette relation.

Comment éviter cette erreur

Travaillez rapidement avec un véritable export de données au lieu de vous fier uniquement à ce qui est visible dans l’application.

Vérifiez quels identifiants, classifications, affectations et relations sont réellement disponibles en dehors de l’ancien système. Clarifiez l’accès à la base de données, les possibilités d’export, les interfaces et la documentation technique avant que la migration n’en dépende.

Définissez ensuite comment les informations extraites doivent être représentées dans le système cible. Le mapping détermine où chaque information doit être placée, tandis que les règles de transformation définissent comment les valeurs doivent être interprétées ou converties. Les relations et les exceptions doivent elles aussi suivre des règles clairement définies.

Et testez ces règles avant le transfert final.

Commencez avec un jeu de données représentatif, effectuez la migration et validez le résultat. Si, par exemple, un ensemble défini d’équipements techniques doit être transféré, vous devez pouvoir vérifier ce qui est effectivement arrivé dans le nouveau système et expliquer les éventuelles différences.

Si quelque chose ne va pas, corrigez les données sources ou la règle de migration à l’origine du problème plutôt que de modifier individuellement les enregistrements dans le système cible. Relancez ensuite la migration.

Une correction qui disparaît au prochain cycle de migration n’a jamais vraiment été une correction.

Identifier ces limites pendant la phase de test vous laisse le temps de les résoudre.

Erreur n° 4 : vouloir tout changer en même temps

Un nouveau système CAFM ouvre de nouvelles possibilités.

Et les possibilités ont une fâcheuse tendance à se transformer en exigences de projet.

Puisque l’organisation migre déjà vers un nouveau système, pourquoi ne pas en profiter pour repenser la maintenance ? Et introduire des processus mobiles. Et reconstruire les interfaces. Et restructurer la gestion des contrats. Et nettoyer vingt ans de données historiques. Et peut-être modifier quelques workflows puisque tout le monde est déjà mobilisé.

Toutes ces mesures peuvent être pertinentes.

Les mettre toutes en œuvre simultanément ne l’est pas forcément.

Chaque sujet supplémentaire semble gérable lorsqu’il est considéré séparément. Mais lorsque suffisamment de sujets sont regroupés dans une même phase du projet, le fameux « tant qu’on y est » finit par peser lourd.

À mesure que le périmètre s’élargit, les dépendances se multiplient. Une modification dans un domaine peut remettre en question des décisions déjà prises ailleurs. Si les exigences continuent elles aussi d’évoluer, certaines décisions doivent être réexaminées, des travaux déjà réalisés doivent être adaptés et l’ensemble de la mise en œuvre devient de plus en plus difficile à maîtriser.

Comment éviter cette erreur

Déterminez ce qui est indispensable pour démarrer sur des bases fiables et ce qui peut être mis en œuvre ultérieurement.

Les structures fondamentales et les données essentielles peuvent être traitées en premier. Les processus, interfaces et fonctionnalités supplémentaires peuvent ensuite être introduits progressivement, selon des étapes cohérentes. Cela ne réduit pas nécessairement l’ampleur globale du projet. Cela permet de rendre un projet complexe maîtrisable.

Surtout, cette approche permet d’obtenir rapidement des résultats utilisables. Un processus peut être mis en place, testé, évalué et ajusté avant de passer au prochain grand ensemble de fonctionnalités.

Il existe une différence considérable entre entendre dire qu’un projet avance et pouvoir déjà utiliser ses premiers résultats.

Mais une mise en œuvre par étapes ne fonctionne que si les responsabilités décisionnelles sont clairement définies. Quelqu’un doit pouvoir trancher sur les exigences métier. Quelqu’un doit les hiérarchiser. Quelqu’un doit résoudre les questions liées aux données et valider les modifications.

Les intitulés de poste varieront d’une organisation à l’autre. L’essentiel est que, lorsqu’une décision doit être prise, chacun sache qui est habilité à la prendre.

Erreur n° 5 : impliquer les utilisateurs trop tard

Il existe un moyen très simple de repérer les problèmes dans un processus parfaitement conçu sur le papier : le confier à quelqu’un qui devra réellement l’utiliser.

Les personnes qui travaillent quotidiennement avec un système CAFM remarquent des détails qui passent facilement inaperçus lors des ateliers ou sur les schémas de processus. Un champ est mal placé. Une information importante est trop longue à trouver. Un workflow qui semblait parfaitement logique pendant la conception se révèle inutilement complexe au quotidien.

Si les utilisateurs découvrent le nouveau système peu avant la mise en production, ces constats arrivent bien tard.

À ce stade, les processus sont déjà configurés, les décisions ont été prises et des modifications qui auraient été relativement simples trois mois auparavant ont soudain des répercussions sur la formation, la documentation, les tests et le calendrier du projet.

Comment éviter cette erreur

Impliquez les futurs utilisateurs suffisamment tôt pour que leurs retours puissent réellement être pris en compte.

Leur présenter des résultats intermédiaires leur permet de vérifier comment les nouvelles structures et les nouveaux processus fonctionnent en pratique et de signaler des problèmes qui ne sont pas nécessairement visibles d’un point de vue technique.

Ils n’ont pas besoin d’assister à toutes les réunions. En revanche, des moments précis doivent être prévus tout au long de la migration pour recueillir leurs retours. Ils peuvent ainsi se familiariser progressivement avec le nouvel environnement au lieu de le découvrir pour la première fois juste avant la mise en production.

Une meilleure migration commence par de meilleures décisions

La réussite d’une migration CAFM ne devrait pas être évaluée en fonction du volume de données transférées. Ce qui compte, c’est que le nouveau système démarre avec des informations fiables, des relations pertinentes entre les données et moins de problèmes hérités de l’ancien environnement.

 

Chez speedikon FM AG, nous accompagnons nos clients à chaque étape de leur migration en mettant notre expérience au service des exigences, des dépendances et des conditions techniques propres à chaque projet. Avec speedikon® C, les données, les processus et les informations pertinentes peuvent être regroupés dans un environnement logiciel intégré, offrant ainsi une base flexible pour les opérations futures.

Vous envisagez de remplacer votre système CAFM actuel ? Contactez nos experts pour échanger sur votre projet de migration.

Pour aller plus loin avec notre livre blanc

Vous souhaitez approfondir le sujet ? Notre livre blanc vous accompagne à travers les principales étapes d’un changement de système, de la définition des objectifs et de l’évaluation des données existantes jusqu’au mapping, aux tests, à la validation et au cutover.

Demandez gratuitement votre exemplaire et découvrez les points à prendre en compte avant, pendant et après la transition.