Déployer l'ITSM sans projet de six mois

La décision d'introduire un nouvel outil d'opérations informatiques est généralement prise de manière sensée et bien préparée. Mais la réalité de la mise en œuvre finit par s'imposer. Analyse initiale, ateliers avec chaque équipe, conception de processus, configuration, migration de données, tests, formation. Les trois mois prévus se transforment en six, et les opérations continuent de fonctionner à l'ancienne en attendant, parce que le nouvel outil « n'est pas encore prêt ».

Le personnel opérationnel paie ce retard à deux reprises. Tout d'abord, il participe aux ateliers et remplit des modèles en plus de son travail habituel. Ensuite, à mesure que la date de mise en production est repoussée, il perd confiance dans le fait que quoi que ce soit va vraiment changer. Lorsque l'outil est finalement mis en production, il est souvent accueilli avec un scepticisme qui n'a rien à voir avec ses fonctionnalités.

Pourquoi les grands projets sont bloqués

En pratique, nous voyons souvent les mêmes causes se répéter :

• Essayer de résoudre tout à la fois. Incidents, demandes, changements, la CMDB et les rapports pour l'ensemble de l'organisation en une seule vague. Chaque domaine a ses exceptions, et chaque exception bloque l'ensemble.
• Concevoir des processus à partir de zéro. Au lieu de conserver ce qui fonctionne déjà, les équipes conçoivent un état idéal que plusieurs groupes ont du mal à s'accorder.
• Préparer les données à la dernière minute. Les équipes, les utilisateurs, les services et leurs propriétaires sont laissés jusqu'à la dernière étape, qui est lorsque les lacunes enfin apparaissent.
• Un outil qui impose son processus complet dès le premier jour. Si le processus de changement nécessite des fenêtres de maintenance que personne n'a encore définies, le travail ne peut pas commencer.

Une autre façon de déployer

Un déploiement plus rapide n'est pas un déploiement moins prudent. C'est un ordre de étapes différent.

Commencez par une seule zone. Une équipe, un groupe de services, un type de travail. Un pilote montre ce qui fonctionne et donne aux gens une expérience sur laquelle le reste de l'organisation peut s'appuyer.

Reprenez les données que vous avez déjà. La plupart des organisations conservent les équipes, les utilisateurs, les services et les serveurs dans des feuilles de calcul. Ils ne sont pas parfaits, mais ils constituent un bien meilleur point de départ qu'un système vide.

Vérifiez la préparation avant la mise en production. Pas une acceptation formelle, mais un contrôle pratique : chaque service a-t-il un propriétaire ? Existe-t-il un SLA ? Les équipes et les rôles sont-ils en place ?

Et donnez au processus le temps de mûrir. Certaines règles, telles que les fenêtres de maintenance pour chaque service, prennent forme progressivement. L'outil devrait vous permettre de commencer à travailler avant que toutes ne soient réglées.

Comment Eywo Stratum gère cela

Eywo Stratum propose des profils de déploiement : pour les fournisseurs de services partagés, pour les entreprises dont la CMDB principale vit dans un autre système, pour les opérations réglementées avec OT, et pour les organisations plus petites. Un profil applique des paramètres par défaut judicieux, et des modules individuels peuvent être activés ou désactivés. Un pilote peut commencer avec juste les incidents et la CMDB.

Les données proviennent via l'importation Excel. Vous pouvez importer des équipes, des utilisateurs et leurs rôles, des éléments de la CMDB, des services avec leur propriétaire, SLA et fenêtre de maintenance, des relations entre les éléments, et des fenêtres de maintenance elles-mêmes. Les feuilles de calcul que vous avez déjà deviennent le fondement, et non un obstacle.

Avant la mise en production, Eywo Stratum effectue un contrôle de préparation opérationnelle. Douze contrôles couvrent les propriétaires de services, les SLA, les fenêtres de maintenance, les relations, les équipes, les rôles, les paramètres de messagerie électronique et plus encore. Le résultat montre ce qui doit encore être rempli, avant que le premier incident ne se produise.

Pour la période de déploiement, il existe un modèle de « changement sans fenêtre de maintenance ». Les équipes peuvent enregistrer et approuver des changements avant que chaque service n'ait une fenêtre définie. Les fenêtres sont ajoutées étape par étape, et le modèle est désactivé une fois qu'elles sont en place.

Le workflow est configurable, de sorte que les états, les transitions et les autorisations peuvent correspondre à la façon dont l'équipe travaille réellement.

Conclusion

L'ITSM n'a pas besoin d'être déployé comme un grand projet. Un pilote dans une zone, des données existantes reprises et un contrôle de préparation permettent de commencer à travailler rapidement et d'étendre progressivement. Le personnel opérationnel voit les avantages plus tôt et accepte le nouvel outil comme une aide, et non comme une obligation supplémentaire.

Les profils de déploiement, l'importation Excel et le contrôle de préparation sont inclus dans l'édition Standard.