Vous déployez un outil ITSM dans différentes filiales ? L’utilisation d’un Core Model s’impose !
Au-delà du simple outil de gestion de projet permettant d’avoir une vision globale et précise, le Core Model est également un formidable levier d’acceptation du changement.

Scénario catastrophe : L’échec annoncé du déploiement d’un outil ITSM Groupe à différentes filiales sans Core Model

Prenons le cas de Martin. Martin est DSI d’une entreprise qui souhaite faire évoluer son outil d’ITSM pour répondre aux nouvelles exigences de la transformation digitale et de l’évolution des usages de ses utilisateurs.

Ses équipes définissent un périmètre pilote (géographique, métier, etc.), se font accompagner, choisissent un intégrateur, et se lancent... L’adoption sur le périmètre pilote s’annonce bien, les équipes sont prêtes à déployer dans l’ensemble des filiales. Rêve ou illusion ?

Les premiers signes de dysfonctionnement apparaissent lors de la réunion avec les filiales italiennes : chaque filiale ou entité présente ses processus et son catalogue, qui sont des plus hétéroclites. Les processus et services des italiens sont véritablement très éloignés du périmètre pilote conçu par l’équipe de Martin ! Dans le même temps, les utilisateurs du pilote remontent des demandes d’évolutions à prendre en charge, ou, tout du moins, à arbitrer. #Patatra… et là c’est le drame !

L’histoire de Martin vous est familière ?

Béni soit le Core Model !

Le Core Model désigne tout ce qui peut être commun et partagé (processus, règles de gestion, modèle de données, référentiels, etc. ) dans les différentes filiales de l’entreprise. L’un de ses principaux objectifs est de faire bénéficier celles-ci, depuis le siège, d’une vision précise et centralisée. Modèle global, le core model prend néanmoins en compte les spécificités de l’entreprise au niveau local : diversité des métiers, envergure des filiales, couvertures géographiques, différences et contraintes légales ou culturelles, etc.

Dans le cadre d’un projet ITSM, le Core Model est une stratégie qui vise à construire un standard groupe pour le catalogue de services et pour chaque processus cible, au sens ITIL® du terme (Incident, Change, CMDB, etc.). C’est un outil précieux pour les DSI qui ont compris l’intérêt de mettre en place, pour l’ensemble de leurs filiales, un outil ITSM unique permettant de disposer d’une vision globale et centralisée de :

  • L’ensemble des « assets » du groupe avec la possibilité de mettre en place une facturation interne claire et précise dans le cadre de services proposés, entre autres, par un Groupement d’Intérêts Économiques (GIE) vers les filiales,
  • La qualité du support (SLA, backlog, etc.), que le fournisseur de support soit une ESN (Entreprise de services du numérique) ou un GIE, ou que le service soit local ou global.

Dans le cas d’un datacenter Groupe fournissant de l’infrastructure aux filiales, un « Core Model » permet également une gestion globale et efficiente des « Change ».

Implication des filiales : Loin des yeux, loin du « Core » !

Fédérer les différentes filiales au sein d’un même outil nécessite de ménager les susceptibilités de chacun ! D’un côté, les filiales se disent prêtes à exploiter l’outil, à condition d’y intégrer leurs processus dont les spécificités peuvent impacter fonctionnellement le périmètre global. De l’autre, l’outil doit rester « maintenable » et permettre une compréhension commune des processus. C’est là qu’une stratégie « Core Model » se révèle efficace, permettant d’éviter l’effet « usine à gaz » et limitant les personnalisations non structurantes.

L’adhésion à un tel projet ne peut pas se faire en s’imposant mais bien en se « posant » autour d’une table. Il faut donc impliquer les filiales très tôt dans la réflexion et respecter certaines règles de mise en œuvre :

  • Identifier, catégoriser et choisir, par processus, les « pratiques groupes »,
  • Ne pas hésiter à revoir ou supprimer les pratiques « groupe » qui ajouteraient de la complexité pour les cibles,
  • Spécifier fonctionnellement chaque processus cible en restant simple,
  • Anticiper la gouvernance, afin de mettre en place l’amélioration continue en « RUN »,
  • Impliquer les filiales, ou à minima des référents régionaux, dans des ateliers, afin d’assurer l’adoption future,
  • « Marketer » le projet de transformation,
  • Identifier des relais locaux afin de communiquer régulièrement et efficacement,
  • Enfin, ne pas oublier de se faire accompagner par un cabinet ayant de l’expérience sur le sujet !

Ces tâches sont bien souvent itératives et doivent idéalement être lancées avant la phase « d’outillage » du projet de transformation.

Sans une gouvernance forte mais flexible, point de salut pour votre Core Model !

Une stratégie « Core Model » requiert une gouvernance forte mais flexible pour réussir la transformation. Cette gouvernance couvre l’ensemble des processus mis en œuvre en s’appuyant sur un responsable global pour chacun d’entre eux, et un service manager pour le service « ITSM » global fourni par le biais de l’outil.

Chaque responsable de processus devient le garant de la cohérence de son processus et en mode « RUN » :

  • Du suivi des tickets incidents ouverts sur son processus et de leurs traitements en L2 ou L3,
  • De l’analyse et de la consolidation des demandes d’amélioration (relais locaux et/ou utilisateurs finaux), et de leur intégration dans des releases incluant les améliorations validées,
  • De la construction et de la mise à jour de documents (formation, ateliers, etc.),
  • Éventuellement de l’animation d’une communauté pour collecter les besoins d’amélioration, présenter les fonctionnalités à venir et faciliter l’adhésion de l’outil et de son processus.

En mode PROJET, il convient également de :

  • Animer les ateliers de design des besoins des filiales entrantes (règles de routages, règles d’escalades, requests, templates de change, etc.),
  • Valider les différents design avant chargement/création dans les environnements (DEV, TEST, etc.),
  • Et animer les formations informatiques sur son processus.

Le Service Manager, de son côté, est responsable de la cohérence globale de l’outil et de :

  • La revue et validation des demandes d’amélioration entrantes,
  • Le suivi de l’implémentation des releases,
  • Le pilotage de toutes les migrations (mineures/majeures) de l’outil ITSM,
  • Le reporting sur l’ensemble des processus de l’outil,
  • Le pilotage des potentielles sociétés externes en charge du support.

« Rome ne s’est pas faite en un jour… », votre Core Model non plus

Dès le départ, il faut accepter l’idée que le « Core Model » ne sera pas livré dans une version définitive mais qu’il devra évoluer au gré des demandes de filiales et surtout de son utilisation. Un processus de « Release Management » devra être mis en œuvre pour assurer et contrôler son évolution par le biais de la gouvernance. Un processus agile, pour assurer des livraisons régulières mais sous contrôle, et structuré autour :

  • D’un product owner qui est impérativement le service manager,
  • Du « backlog product » (liste des fonctionnalités attendues d'un produit) alimenté régulièrement par les demandes d’évolutions
  • De « backlog sprints » (plans d’itération) créés grâce au « backlog product »
  • Et d’une communication autour de ce processus de « release management » intégrant les filiales utilisatrices, ainsi que les services managers qui utilisent le « Core Model » (sécurité, réseaux, etc.)

Le cercle vertueux du Core Model : implication des filiales, gouvernance, amélioration continue

La mise en œuvre d’un « Core Model » est un élément indispensable à la réussite d’un projet d’ITSM dans un contexte Groupe, mais elle ne saurait être la panacée universelle ! Si le Core Model est développé « dans son coin », et imposé, que les filiales ne sont pas impliquées et que la gouvernance et l’amélioration continue passent à la trappe, le Core Model se réduira à un simple outil de gestion de projet, avec plus ou moins de succès.

Si, au contraire, il est abordé comme un levier de changement et d’adhésion, avec une prise en compte éclairée et attentive des spécificités de chaque filiale, une réelle gouvernance et une évolution permanente et constructive, alors le « Core Model » sera le nouveau meilleur ami du chef de projet ITSM Groupe ! Pour en faire l’outil du changement, il faut accepter de revoir ses pratiques et surtout accepter de ne pas se précipiter, de prendre le temps, de simplifier, de s’organiser. Et de se faire accompagner si besoin.

A découvrir également, « 6 bonnes pratiques pour Service Management Agile ».