Les projets d’harmonisation des systèmes d’information sont de plus en plus courants. Ils peuvent notamment s’expliquer par la volonté pour les entreprises de simplifier leurs paysages applicatifs, d’homogénéiser leurs processus de travail ou encore de centraliser leurs données dans un unique outil. Mais qu’en est-il en réalité ? Les impacts métier annoncés sont-ils respectés ? Les gains prévus sont-ils atteints ?
#1 : Quels sont les principaux objectifs que les entreprises souhaitent atteindre en lançant de tels projets ?
Les objectifs de ces projets diffèrent selon les strates de l’entreprise. Au niveau managérial, les principaux objectifs de ces projets sont :
- De gagner en productivité en redéfinissant et en harmonisant les processus de travail.
- De gagner en cohérence dans l’architecture IT – avec souvent des promesses de réduction de coût de maintenance et des simplifications pour les montées de version.
- De gagner en productivité globale pour l’entreprise.
- D’avoir un outil unique pour le pilotage de l’entreprise.
Au niveau opérationnel, les gains annoncés de ces projets sont :
- La résolution d’incohérences, de dysfonctionnements et la simplification du traitement de certaines tâches chronophages (anomalies, double saisie, information dans deux systèmes, etc.) via la redéfinition des processus de travail.
- Plus de fiabilité dans les données traitées via l’intégration de tâches souvent faites dans Excel.
- La possibilité de libérer du temps pour se concentrer sur des tâches à plus forte valeur ajoutée.
Ces objectifs semblent tout à fait cohérents pour de tels projets mais certains prérequis doivent tout de même être respectés pour maximiser les chances de réussite.
#2 : Quels sont les facteurs clés de succès de ces projets ?
Tout d’abord, il est essentiel de constituer une équipe projet, de construire sa gouvernance, d’avoir un sponsorship actif et de s’assurer que les personnes concernées auront du temps qui leur sera dégagé pour s’y consacrer ! Cela semble évident mais il n’est pas rare que ce premier prérequis soit négligé.
Ensuite, des utilisateurs finaux doivent être intégrés dès le début du projet. Il est recommandé de leur présenter le type d’outil et la refonte des processus de travail envisagés pour les aider à se projeter dans leur futur travail. Ces utilisateurs finaux doivent être intégrés à la phase de définition du besoin : ce sont eux qui, la plupart du temps, connaissent les spécificités techniques auxquelles l’outil sélectionner devra répondre. Ces détails, souvent négligés, sont pourtant ceux qui deviennent bloquants lors des phases de déploiement.
De plus, il est nécessaire de mettre en place des indicateurs de suivi de projet : ils permettent notamment de suivre les avancées du projet mais aussi de refléter les difficultés rencontrées (retards, surcoût, etc.).
Ensuite, il est indispensable qu’une roadmap de projet soit clairement définie : quel est le périmètre du projet ? Le déploiement doit-il démarrer avec un pilote ? Si oui, quel doit-en être le périmètre ? Qui est impliqué dans chaque déploiement ? Qui intervient à quel(s) moment(s) ? Quels sont les rôles et responsabilités de chacun ? Etc.
La définition de cette roadmap doit donc prendre en compte divers éléments comme l’implication des ressources dédiées au projet, l’enchaînement des étapes du projet, les jalons temporels s’ils existent (ex : décommissionnement de l’ancien outil à une date précise), etc.
Enfin, comme pour tout projet de transformation, l’accompagnement au changement (Change Management) doit être budgété : ce volet représente généralement 25% du budget total du projet. A ce budget, il est également important d’ajouter une réserve pour gérer les impondérables qui ne manqueront pas d’arriver.
#3 : La préparation du projet
Après ce cadrage, la première étape d’un tel projet consiste à définir quels sont les besoins métier auxquels l’outil sélectionné devra répondre. Pour cela, une phase de diagnostic est nécessaire pour :
- Décrire les processus de travail actuels
- Evaluer leur pertinence/leur efficacité
- Identifier ce que les outils actuels couvrent et leurs limites
- Identifier les outils satellites développés pour combler des manques
- Rédiger le cahier des charges décrivant précisément les besoins métier à couvrir
Nous l’avons déjà dit, mais l’implication dès cette étape des opérationnels est primordiale. Lors de cette phase de diagnostic, il faut prendre du recul sur les opérations et remettre en cause, challenger des processus de travail : c’est là le rôle du management de l’entreprise.
Le cahier des charges qui sera construit, permettra de sélectionner l’outil capable de couvrir la totalité, ou une partie, les besoins exprimés. Si l’outil sélectionné ne couvre pas totalement le besoin fonctionnel, alors un plan d’action doit être clairement défini pour identifier comment ces besoins non couverts seront gérés : via d’autres outils complémentaires ? Excel ? Etc.
#4 : La phase de déploiement
Une fois l’outil sélectionné, la phase de déploiement peut commencer. Cette phase est plus ou moins complexe selon l’envergure du projet. Cependant, quelle que soit la taille du projet, la première chose à faire est d’affiner la roadmap de déploiement initialement prévue.
Plus l’envergure du projet (périmètre couvert, nombre de filiales, etc.) est importante, moins cette roadmap initiale a de chances d’être respectée. Ci-dessous, plusieurs exemples :
- Lorsqu’une roadmap contient des déploiements successifs, alors tout retard sur l’un d’eux peut décaler le démarrage du déploiement qui lui est adossé. Cela est d’autant plus vrai lorsque des équipes de déploiement centrales sont en place, qui doivent avancer de manière séquentielle avec une capacité finie.
- Les enjeux financiers liés aux décalages de la roadmap peuvent être tels que la Direction du projet peut pousser à tenir des échéances quoi qu’il arrive. Dans ce cas-là, les impacts sur le déploiement concerné seront par exemple : le non-développement d’une spécificité initialement prévue ou l’accélération des phases de tests utilisateurs.
Quel que soit la raison, de la frustration se fera ressentir chez les utilisateurs car des spécificités ne seront pas prises en compte ou alors, certaines étapes du projet seront réalisées plus vite que prévu et les chances de passer à côté de certaines erreurs seront plus élevées. Le pire serait de réduire la durée et l’intensité de l’accompagnement des utilisateurs post go-live !
Conclusion
Nous constatons très régulièrement que les objectifs initiaux ne sont que partiellement atteints ou dans des délais plus longs que prévu : les difficultés rencontrées pour respecter les prérequis ou les différentes étapes se traduisent par un très grand nombre d’échecs ou d’abandons des projets IT. D’après une étude du Standish Group, le manque d’implication des utilisateurs finaux est la première cause d’échec de ces projets, juste devant le manque de clarté de la définition des besoins et leurs modifications en-cours de projet : ces causes représentent, à elles 3, presque 50% des causes d’échecs de projets… Quant au respect des budgets, moins de 20% des projets ne dépassent pas le budget initial mais plus de 50% d’entre eux le dépassent…d’au moins, 50% !
Le déroulement de ce type de projets et les chiffres présentés nous amènent finalement à nous demander s’il est vraiment pertinent de se lancer dans de tels projets ? Les besoins d’harmonisation des processus souhaités par les entreprises sont-ils réellement nécessaires ? La réponse n’est pas binaire et dépend de l’activité, du périmètre du projet, du nombre de personnes impliquées, etc. Par exemple, si l’objectif principal est de centraliser les données, une harmonisation IT peut être évitée au profit de la mise en place de cubes de données qui sont rapides et faciles…à mettre en place et à maintenir !
Baptiste Vignes, Consultant confirmé et Jérôme Pacaud, Manager, Groupe Citwell
