Pour plusieurs organisations, maintenir une CMDB ServiceNow en bonne santé est un combat de tous les instants. Une CMDB traditionnelle peut vous donner un inventaire solide de vos serveurs et bases de données, mais elle ne répond pas à la question la plus importante : comment cette infrastructure soutient-elle les affaires?
Lors de notre récent atelier de maître (masterclass), Maxime Carrier, directeur de pratique ITOM chez Ateko, et Denise Morrison, gestionnaire ITOM chez CAE – un chef de file mondial en aviation et en défense – nous ont montré comment combler ce fossé.
Regarder la vidéo :
Succès concret : le parcours ITOM de CAE
CAE a amorcé sa démarche en se concentrant sur ses applications les plus critiques. Denise a expliqué qu’avant d’adopter le modèle de données de service commun (CSDM) de ServiceNow, les équipes utilisaient souvent le même nom pour désigner à la fois un service et une offre, ce qui créait de la confusion et des rapports incohérents.
Notre équipe chez Ateko a joué un rôle crucial pour guider CAE. En animant des sessions de modélisation collaborative avec les architectes d’entreprise et les propriétaires d’applications, notre équipe a méthodiquement cartographié leurs applications d’affaires critiques par rapport à l’infrastructure sous-jacente, aux services techniques dont elles dépendent et aux résultats d’affaires précis qu’elles soutiennent. Pour s’assurer que le modèle réponde à des besoins opérationnels réels plutôt qu’à de la simple théorie, nous avons analysé l’historique des billets d’incidents et de changements afin de comprendre exactement comment les services étaient consommés et où se situaient les points de friction. Cette approche pratique, axée sur les cas d’utilisation, a permis à CAE de concevoir un nouveau modèle qui distingue clairement les services d’affaires, les offres de services et les environnements applicatifs (tels que Production, QA et Développement).
Choisissez votre point de départ : orientation application vs orientation service
Vous ne pouvez pas vous attaquer à l’ensemble de votre infrastructure et de vos applications d’entreprise d’un seul coup. Lorsque vous commencez votre parcours, nous vous recommandons de choisir une approche qui correspond à votre culture et à votre modèle opérationnel.
| Approche | Idéale pour | Premières étapes |
|---|---|---|
| Axée sur les applications | Les organisations guidées par l’architecture d’entreprise interne (ex. : TI corporatives standards). | S’aligner avec l’architecture d’entreprise. Identifier de 20 à 50 applications d’affaires « bijoux de famille » ou de priorité 1 (P1) à cartographier en priorité. |
| Axée sur les services | Les organisations qui offrent des produits ou services numériques à des utilisateurs finaux (ex. : télécommunications, services publics et institutions financières). | Identifier les services d’affaires et techniques. Définir les offres actuellement proposées aux consommateurs internes ou externes. |
Peu importe où vous commencez, votre objectif final est de cartographier votre infrastructure à vos applications et à vos services d’affaires. Cela vous permet de comprendre l’impact des incidents, d’évaluer les risques liés aux changements et de gérer les problèmes en toute confiance.
Trouvez le juste milieu
Le facteur le plus déterminant pour obtenir une vue des dépendances exploitable est le niveau de détail.
Si vous modélisez à un niveau trop global (par exemple, un seul service applicatif générique pour le système SAP mondial), vos cartes deviendront illisibles et vos relations entre éléments de configuration (CI) se transformeront en bruit. Si vous modélisez de manière trop granulaire, vous risquez de créer un fardeau de maintenance impossible à gérer, ce qui freinera l’adoption.
Votre but est de trouver le « juste milieu », c’est-à-dire le niveau de détail minimal requis pour répondre à vos questions opérationnelles les plus importantes. Vous pouvez utiliser ces critères pour guider la granularité de vos services applicatifs :
- Consommation ITSM : Utiliseriez-vous ce service applicatif de manière autonome dans un billet de changement? Si oui, séparez-le dans son propre service applicatif. Si non, regroupez-le.
- Environnement : Gérez-vous ces processus pour des environnements hors production? Si oui, séparez la Production, l’Assurance qualité (QA/Staging) et le Développement au besoin.
- Géographie : Déployez-vous des changements de manière indépendante sur des sites ou dans des régions spécifiques? Si oui, divisez les services applicatifs par région ou par site.
- Architecture : Ces services applicatifs fonctionnent-ils sur des piles technologiques différentes avec des impacts distincts sur la performance ou la disponibilité? Si oui, créez des instances distinctes (par exemple, une instance Administrateur et une instance Utilisateur final).
Meilleures pratiques pour la modélisation CSDM
- Commencez par les personnes et les processus : Animez des séances de modélisation avec les architectes d’entreprise, les propriétaires d’applications et les experts techniques à l’aide d’un tableau blanc ou d’un outil de diagramme avant de lancer la découverte automatisée.
- Gardez votre CMDB propre : Utilisez une approche de classification cohérente. Les équipes confondent souvent les logiciels ou les plateformes TI fondamentales avec de véritables applications d’affaires.
Si vous travaillez à bâtir une CMDB axée sur les services, ou si vous avez besoin d’aide pour définir des modèles applicatifs qui soutiendront vos objectifs ITSM et ITOM, communiquez avec Ateko pour vous accompagner dans votre démarche.
