Après plusieurs années à naviguer sur BMC Remedy, Remedyforce ou CA Service Desk, un constat s’impose : la réussite d’une solution d’outillage ne se joue pas lors de son déploiement, mais dans sa capacité à ne pas dériver. J’ai trop souvent vu des plateformes performantes s’effondrer sous le poids de demandes métiers mal arbitrées..

Depuis de nombreuses années, le concept de OOTB (pour Out-Of-The-Box), qu’on pourrait appeler aussi Standard First anime les projets ServiceNow. Un concept à développer tout au long de la vie de la solution et non uniquement durant les phases de conception et déploiement.

Un contrôle certain durant les projets

Lors de la mise en place d’une nouvelle solution, la mise en œuvre au travers d’un projet garantit une forme de respect des standards. Pourquoi ? Tout simplement parce que les contraintes projets en elle-même (et notamment coût et délai) limitent la volonté d’aller au-delà des fameux « Must Have ».

Il y a donc une forme de contrôle des déviations qui tient plus du contrôle projet que de la pertinence solution… Même si bien entendu, l’un n’empêche pas l’autre.

Le manque de mise en place d’une gouvernance de la plateforme dès le départ a pour fâcheuse tendance de faire dévier la plateforme dès le projet terminé. Les personnes qui se sont vues refuser leurs besoins durant le projet, reviennent taper à la porte à la clôture de ce dernier. Cela peut avoir comme conséquence une dette technique qu’il faudra un jour ou l’autre payer.

La deuxième raison est que, bien trop souvent, les équipes plateforme, par leur ADN, ont tendance à privilégier la réponse technique immédiate au détriment de la cohérence fonctionnelle globale.

Alors quelle solution ? L’installation, dès la phase projet, d’une gouvernance solution forte.

Sortir du piège de la dette technique

Il était effectivement un temps où la vox populi indiquait que les outils devaient s’adapter aux processus et non l’inverse. Néanmoins, les montées de version fréquentes (au moins une par an avec la possibilité d’en faire deux par an) et la complexité que cela peut avoir sur les temps pour le faire ont rebattu les cartes.

De la même façon qu’une couverture métier de plus en plus large de la plateforme… En effet, plus la solution s’éloigne du standard, plus le risque de ne pas être compatible avec les nouvelles fonctionnalités est important.

Souvent on me dit que ce ne sont que de « petits développements » (d’ailleurs cette notion de développement mérite d’être discutée)… J’aime bien prendre l’idée du bateau : Une déviation d’un degré semble anodine ; une déviation de 180 degrés vous ramène au point de départ : le re-platforming complet.

Alors comment faire pour sécuriser sa plateforme ?

La démarche de gouvernance

Pour sécuriser sa plateforme, rien de mieux que d‘industrialiser la façon de prendre en compte ou non les nouvelles exigences de la part des différents métiers. Parmi les critères qui doivent être pris en compte figurent :

• Des critères permettant d’évaluer de façon pertinente les besoins métier,
• Une analyse détaillée des impacts techniques,
• Une vision complète sur les impacts plateforme / solution.

Cela nécessite aussi une bonne captation du besoin, une bonne validation des critères d’acceptation et surtout une bonne prise de position du propriétaire de la plateforme. Entrons un peu dans le détail.

Des besoins métiers clairement exprimés

Cela ne surprendra pas, il est indispensable d’avoir des demandes de changement qui sont claires pour toutes les parties prenantes. Il est indispensable de récupérer sur chaque exigence :

• La personne qui va consommer le besoin et/ou utiliser la fonctionnalité,
• Le besoin en lui-même,
• L’objectif que permettra d’atteindre la réponse au besoin,
• Les tests qui permettront de valider que l’objectif est atteint mais aussi ceux qui permettront de dire qu’il n’est pas atteint.

L’utilisation des User Stories sous la forme « En tant que [Rôle de la personne], je souhaite [Description de la fonctionnalité] afin de [Objectif recherché] facilite la compréhension. De la même façon, attention à bien tracer un besoin et non une réponse : « souhaiter un bouton pour… » n’est pas un besoin mais une réponse technique.

En plus de cette description, il est intéressant de pouvoir détailler la valeur ajoutée mais aussi les risques potentiels si la fonctionnalité n’était pas implémentée. Par exemple, la non mise en œuvre d’un besoin peut avoir pour conséquence de faire courir un risque réglementaire ou conformité à l’organisation.

Il est intéressant aussi de proposer une réponse directement dans la philosophie de l’outil, y compris si cela peut changer les modes opératoires actuels.

A noter : dans le plupart des organisations, tout besoin est traité en User Story alors que certains ne sont que des Technical Stories permettant, par exemple, un interfaçage avec le reste du SI.

Organisation

Au-delà du Platform Owner, l’introduction d’un Product Owner ou d’un Business Analyst est le meilleur rempart contre la dérive. Ces rôles agissent comme un filtre critique pour transformer une envie en un besoin réel et standardisé.

Une vision précise des impacts techniques

Au-delà de l’importance métier, il est aussi important de donner une bonne visibilité sur les conséquences techniques de l’implémentation du besoin. Parmi les questions à se poser viennent naturellement :

• La charge associée au développement ou la configuration,
• La méthode de réponse au besoin (Business Rules, Scripts clients, …),
• La réponse au besoin se fait-elle au-dessus du code ServiceNow ou modifie-t-elle le code ServiceNow,
• Le besoin n’est-il pas couvert par une fonctionnalité native de ServiceNow
• L’impact sur les futures montées de version.

Cette analyse doit permettre de donner les bons leviers de décision au propriétaire de la plateforme.

Dans l’idéal, il serait intéressant de pouvoir mettre en place un outil de contrôle de l’utilisation de la fonctionnalité. Il est fréquent qu’un champ soit demandé pour stocker une information et ne sera utilisé que dans 1% des cas. Avoir cette information permettrait de prendre la décision de retirer l’adaptation.

La vision plateforme

Au-delà des visions très liées au besoin en lui-même, la sécurisation de la plateforme passe aussi par une analyse des impacts à plus long terme ou de façon plus transverse.

Si l’impact sur la maintenance est le principal élément à contrôler lors de l’analyse de la réponse au besoins, d’autres questions doivent être posées pour bien comprendre la pertinence d’aller plus loin ou non dans la réalisation.

• La fonctionnalité demandée est-elle extensible au sein de la plateforme. Notamment, si on prend le cas de la brique ITSM : le besoin exprimé pour la gestion des incidents ne pourrait-il pas être pertinent pour la Gestion des demandes de Service par exemple,
• La fonctionnalité demandée est-elle sans impact si l’organisation devait demain intégrer des nouveaux modules ?
• Comment s’assure-t-on de la bonne utilisation de la fonctionnalité ?

En conclusion

Les besoins métier sont souvent étudiés par le prisme de l’organisation et/ou technique sans se poser la question de remettre en cause les pratiques en elle-même.

Dans beaucoup de situation, il est possible de trouver des alternatives… Notamment parce que les outils ne remplaceront jamais la relation humaine. Souvent, la reproduction de fonctionnalités est plus une facilité qu’une réelle réponse : la mise en place d’une bonne gouvernance permet de valoriser la plate-forme et de la pérenniser dans le temps.

La gouvernance devrait aussi prendre en compte l’impact carbone : l’ajout de code et/ou de notifications fait aussi partie des éléments qu’il serait pertinent de mesurer. Souvenez-vous que moins de code, c’est moins de maintenance, moins de stockage et une exécution plus rapide.

Si vous voulez en savoir plus, n’hésitez pas à me contacter : j’ai pu contribuer à la mise en place de plusieurs gouvernance plateforme et animer des comités de gouvernance !