En première ligne : Virages stratégiques pour les transformations ServiceNow
La « transformation numérique » est une expression courante dans le domaine des technologies d’entreprise. Mais dans les programmes ServiceNow complexes, la véritable transformation ne se résume pas à l’étape de la mise en production (go-live) – elle s’acquiert grâce à une exécution disciplinée et à une valeur d’affaires mesurable. Il y a un fossé énorme entre une démonstration logicielle bien rodée et une solution d’entreprise en direct. Pour que le changement s’enracine, il faut savoir naviguer dans l’ambiguïté et la politique de l’entreprise, remettre en question les idées reçues et investir du temps dans les petites décisions et les ajustements qui assurent le succès à long terme.
Lorsqu’on guide une organisation dans son parcours ServiceNow, un changement fondamental consiste à passer d’une approche de livraison transactionnelle à un rôle d’amplificateur de décisions stratégiques. Forts de notre vaste expérience dans l’accompagnement de clients grandes entreprises à travers ces programmes, voici les virages fondamentaux qui permettront à votre investissement ServiceNow de générer une valeur d’affaires durable.
Commencez par les résultats d’affaires, pas par les livrables
Il est courant d’arriver à une réunion de lancement et d’entendre des affirmations telles que : « Nous avons besoin d’un portail », « Nous devons déployer le module X » ou « Nous devons nous intégrer au système Y ». Dans un modèle de livraison transactionnel, le carnet de produit (backlog) se remplit et l’équipe commence à développer. Des semaines plus tard, il devient souvent évident que l’« objectif » n’était en fait qu’un moyen de parvenir à une fin, et que le véritable résultat escompté n’a toujours pas été atteint.
Les résultats doivent être liés à des objectifs d’affaires clairs, tels que : « Réduire les coûts d’exploitation en retirant l’application Y », « Permettre aux clients d’interagir avec nous lors du lancement d’un nouveau produit » ou « Répondre à une nouvelle obligation contractuelle en s’assurant que les billets (tickets) sont enregistrés rapidement ».
Une approche stratégique commence par un encadrement axé sur les résultats. Avant que la configuration et le développement ne commencent, définissez des objectifs mesurables qui comptent pour l’entreprise – par exemple : retirer l’application héritée X, atteindre Y interactions clients via le portail A, ou s’assurer que les billets sont créés de manière automatique et fiable dans l’environnement de production ServiceNow. Chaque fonctionnalité proposée doit justifier sa place en répondant à une seule question : En quoi cela fait-il avancer les choses ? Si ce n’est pas le cas, elle est mise en attente. Des résultats clairs permettent de garder le cap sur la portée du projet et de s’assurer que vous livrez des solutions, et pas seulement des logiciels.
Traitez la personnalisation comme un compromis stratégique
La personnalisation (customisation) et la dette technique ne devraient pas être des sujets tabous – elles doivent être soulevées tôt, discutées ouvertement et quantifiées. La réalité est que la dette technique est inévitable; elle commence à s’accumuler dès le début de la configuration. Le but n’est pas de l’éliminer complètement, mais de comprendre son coût et de le soupeser face à la valeur d’affaires qu’elle génère dans le cadre d’une analyse du coût total de possession (TCO).
Toutes les personnalisations n’ont pas le même impact. Même un petit écart par rapport aux fonctionnalités prêtes à l’emploi (out-of-the-box ou OOTB) peut faire boule de neige et entraîner des cycles de tests complexes, des coûts de licence plus élevés et des risques de sécurité accrus. Ce qui est facile à bâtir peut devenir difficile et coûteux à supporter. Considérez la personnalisation comme une décision délibérée et calculée, en tenant compte non seulement de l’effort de développement, mais aussi des implications à long terme en matière de support, de licences, de sécurité et de performance.
Pensez l’architecture pour l’intégrité de la plateforme et la préparation à l’IA
Bâtir en s’alignant sur les modèles de conception de ServiceNow est essentiel pour l’évolutivité (scalability) à long terme. À la base, la plateforme est conçue pour les flux de travail de services. Des capacités telles que le libre-service, les escalades, les communications, l’engagement, l’auditabilité et la sécurité reflètent des années d’itération – façonnées par des déploiements dans le monde réel, la rétroaction des utilisateurs et l’expertise collective des concepteurs, architectes, développeurs, clients et partenaires.
Lorsque vous bâtissez sur ServiceNow, vous vous appuyez sur ces connaissances accumulées. Les modèles de la plateforme existent parce qu’ils ont fait leurs preuves lors d’innombrables implantations – alors utilisez-les.
La simplicité est stratégique. Ne luttez pas contre la plateforme. Établissez et faites respecter des bibliothèques de modèles qui tirent efficacement parti de ServiceNow : modèles de catalogue, taxonomies de connaissances, portails, espaces de travail et flux de travail communs. L’IA, le libre-service, l’engagement des utilisateurs, l’auditabilité et d’autres capacités « standards » dépendent de ces fondations. La réutilisation est le secret de l’évolutivité.
Gérez l’IA avec une discipline délibérée
L’IA amplifie tout dans une plateforme – le bon comme le mauvais. Bien que Now Assist et d’autres outils d’IA basés sur des agents puissent considérablement accélérer le développement et la résolution, ils exigent une supervision rigoureuse. Encadrez les résultats assistés par l’IA avec des contrôles stricts de la qualité des données, des normes claires d’explicabilité et des révisions impliquant une intervention humaine (human-in-the-loop). Assurez-vous d’avoir un soutien architectural expérimenté pour guider l’adoption, afin que l’IA renforce votre modèle opérationnel plutôt que d’introduire des risques non gérés.
Comblez l’écart entre la preuve de concept (POC) et la production
Une preuve de concept (POC) bien ficelée peut impressionner la haute direction, mais le piège classique est de supposer que ce POC est prêt pour la production. Une démo prouve une idée ; la production fait ses preuves en affaires. Atteindre la mise en production implique de répondre aux exigences architecturales moins visibles mais critiques : la sécurité, la performance, le modèle de données, l’évolutivité et les coûts d’exploitation (run costs).
Toutes les solutions ne nécessitent pas le même niveau de rigueur. Adaptez la livraison au risque et à l’ampleur du cas d’utilisation. Une application départementale légère destinée à dix utilisateurs exige des contrôles bien différents de ceux d’une application orientée client soumise à des ententes de niveau de service (SLA) 24/7. Appliquez l’assurance qualité (AQ) et la surveillance en fonction du contexte. Il n’y a pas de solution universelle.
Ne sous-estimez pas les ressources nécessaires au travail fonctionnel
Les capacités prêtes à l’emploi de ServiceNow offrent une forte valeur de base, mais pour passer à une solution de niveau entreprise, il faut traiter des cas d’exception (edge cases) complexes et spécifiques au contexte. Si les critères d’acceptation sont vagues et que les cas d’exception sont ignorés, le projet échouera dans le monde réel. Investissez dans des ateliers fonctionnels, des guides d’exploitation (runbooks) clairs et de la documentation utilisateur. C’est là que les programmes réussissent ou échouent – traitez cela comme une étape de livraison essentielle, et non comme de la paperasse optionnelle.
Pensez l’architecture pour l’adoption et l’évolution continue
Si une solution est mise en production mais n’a pas d’utilisateurs actifs, vous avez livré du code, pas de la valeur. Les applications qui ont le plus d’impact sont rarement les plus complexes ; ce sont celles que les gens utilisent réellement. Évitez la suringénierie. Livrez petit, livrez vite, mesurez l’adoption et itérez.
L’implantation n’est que la première phase d’un parcours de transformation plus long. La rétroaction la plus précieuse émerge une fois que les utilisateurs interagissent avec la solution en production. Les programmes performants planifient la vie après le lancement : ils considèrent la mise en production comme le début d’une amélioration continue.
En conclusion
L’architecture n’est pas un diagramme que l’on épingle sur un mur. C’est un ensemble d’habitudes : comment les décisions sont prises, ce qui est réutilisé, et comment on protège l’avenir de la facilité du présent. Cela inclut la conception technique, mais il faut aussi tenir compte de l’adoption, des impacts sur l’exploitation (runtime) et le support, ainsi que de la maintenabilité à long terme. Dans une ère de changements rapides, il est essentiel d’avoir une perspective de confiance pour naviguer à travers ces compromis. Ce n’est pas facultatif : c’est ce qui fait la différence entre les organisations qui se contentent d’implanter ServiceNow et celles qui se transforment véritablement grâce à lui.
Pour en savoir plus sur nos capacités en services-conseils ServiceNow et sur la façon dont nous pouvons soutenir votre transformation, communiquez avec nos architectes de solutions : Contactez-nous | Ateko
