CSDM Phase de mise en œuvre : base

  • Rversion finale: Australia
  • Mis à jour 12 mars 2026
  • 7 minutes de lecture
  • Lors de la phase Fondation de la mise en œuvre du cadre de travail, les administrateurs préparent les données référentielles qui permettent d’obtenir des rapports précis pour soutenir les CSDM bonnes décisions business. Utilisez les système-de-base tables lorsque vous commencez à implémenter le CSDM pour tirer le meilleur parti de vos ServiceNow produits et du ServiceNow AI Platform.

    Avantages de la préparation des données à l’étape Fondation

    Tout bon modèle de données repose sur les données de base référencées dans l’ensemble du modèle.
    • Les système-de-base tables de la CMDB table servent de base à de nombreux ServiceNow AI Platform produits.
    • Les tables aident votre organisation à s’aligner rapidement sur les exigences de génération de rapports afin d’accélérer la valeur que vous tirez des ServiceNow AI Platform produits. Vous pouvez réduire ou éliminer les tâches de reprise coûteuses nécessaires pour vous aligner sur les exigences de reporting.

    Tables sur lesquelles vous travaillez pendant l’étape Fondation

    Tables sur lesquelles vous travaillez pour préparer les données de base.

    Table Processus business [cmdb_ci_business_process]

    Un processus de gestion a un début et une fin bien définis. Le processus d’intégration des clients et le processus de vérification de crédit sont des exemples de processus commerciaux dans le secteur bancaire. Chaque processus business peut avoir des niveaux de criticité et d’impact. Les processus business sont stockés dans la table cmdb_ci_business_process.

    Table des contrats [ast_contract]
    La table Contrat identifie les accords contraignants entre deux parties. Lorsque vous renseignez les services fournis par les fournisseurs dans le , tenez compte du rôle que jouent les contrats lors de l’évaluation des accords sur les niveaux de CMDB service (SLA).
    Table des modèles de produits [model_id]

    La table Modèle de produit [model_id] identifie les types uniques de produits que votre organisation développe ou consomme. Lorsque vous regroupez les actifs et les CI par modèle de produit, vous unifiez et reliez les CI qui font partie du même produit digital et des mêmes portefeuilles de produits. Le regroupement des actifs et des CI par modèle de produit peut vous aider à planifier des projets, à surveiller les coûts et à rationaliser vos données. Découverte Peut renseigner les modèles de produits tangibles/physiques une fois qu’ils sont opérationnels, mais d’autres types de modèles de produits nécessitent une planification de la part des propriétaires de produits.

    Utilisez la tâche d’affectation de modèle de produit CSDM pour générer automatiquement un Modèle de produit enregistrement (modèle d’application, modèle de service ou modèle logiciel) pour chaque CI logique qui n’est pas encore associé à un Modèle de produit. Les modèles de produit sont idéaux pour associer des CI qui font partie d’un seul produit numérique. Reportez-vous à Générer automatiquement des modèles de produits pour les CI logiques.

    CMDB Table de groupe [cmdb_ci_query_based_service]

    La CMDB table Groupe identifie une collection de CI en fonction des résultats des requêtes enregistrées du générateur de requêtes, des requêtes codées ou des entrées manuelles.

    CMDB Les groupes sont des éléments essentiels des groupes de CI dynamiques et de la gestion stratégique des CI. Décidez rapidement de la manière dont vous souhaitez signaler les informations de CI et de la manière dont vous souhaitez surveiller les CI. Ces décisions affectent la façon dont vous créez les CMDB groupes. Pour Gestion des changements et Gestion des incidents les processus, il existe deux comportements d’analyse d’impact distincts pour les groupes de CI dynamiques. Consultez Correspondance de l’utilisation des groupes de CI dynamiques avec le type de service.

    Nomenclatures logicielles (SBOM)

    An SBOM est l’ensemble des composants d’un logiciel. Cyclone DX est pris en charge.

    Table d’emplacement [cmn_location]
    La table Emplacement identifie de manière unique les emplacements géographiques. Vous pouvez créer une hiérarchie des données d’emplacement à l’aide de l’attribut Parent . La hiérarchie peut inclure des entrées qui correspondent à vos besoins en matière de génération de rapports. Par exemple, vous pouvez remplir la table Location (Emplacement) comme suit
    Figure 1. Attributs d’emplacement de votre organisation
    Rapports sur l’emplacement.

    Pour inclure plus de détails dans les rapports, vous pouvez étendre la table Emplacement pour inclure les étages, les salles et même les centres de données. Avec des capacités de hiérarchie, des données sources fiables et vos exigences en main, vous pouvez créer des emplacements qui répondent à vos besoins futurs en matière de reporting.

    Table de groupe [sys_user_group]
    La table Groupe identifie les ensembles d’utilisateurs qui partagent un objectif commun. Les groupes peuvent effectuer des tâches telles que l’approbation des demandes de changement, la résolution d’incidents, la réception de notifications par e-mail ou l’exécution de tâches de demande de commande de travaux. Les groupes utilisent également les données référentielles dans le CMDB pour identifier la manière dont les CI sont gérés (par exemple, le groupe géré par) et pris en charge (par exemple, le groupe de support). Toutes les règles métier, les règles d’affectation, les rôles système ou les attributs qui font référence à un groupe s’appliquent automatiquement à tous les membres de ce groupe.
    Remarque :
    Le Managed by Group paramètre identifie le groupe qui gère une classe CI (en s’assurant qu’elle est complète et correcte). Il peut s’agir ou non du même groupe que celui qui répare un CI individuel.
    Table des utilisateurs [sys_user]
    La table Utilisateur identifie les personnes et les applications qui ont accès à votre ServiceNow instance. Vous pouvez organiser les utilisateurs en groupes associés aux tables Société, Unité business et Département.
    Structure organisationnelle
    Les tables de structure organisationnelle identifient les structures business internes ainsi que les clients, fabricants et fournisseurs externes.
    Table de la société [core_company]
    La table Société est renseignée avec les entités juridiques des sociétés. Les entités peuvent être internes (votre organisation) ou externes. Vous pouvez utiliser l’attribut Parent pour créer une hiérarchie. Tenez compte des entités juridiques dont vous avez besoin pour la génération de rapports lorsque le CMDB est renseigné.
    • Les entrées internes doivent se concentrer sur une hiérarchie d’entités juridiques plutôt que sur une hiérarchie d’unités business au sein d’une entité juridique.
    • Les entrées externes sont identifiées par un marqueur Vrai ou Faux. Le marqueur Client identifie vos clients externes.

      L’indicateur Fabricant identifie les entreprises qui créent les produits que vous consommez. Une organisation interne peut être un fabricant.

    • Le marqueur Fournisseur identifie les organisations qui fournissent des produits que vous achetez. Une organisation interne peut être un fournisseur.
    Table de l’unité business [business_unit]
    La hiérarchie de votre entreprise est renseignée dans la table Unité business avec une référence à la société mère. Une unité business est une partie de votre organisation qui est responsable d’opérations spécifiques, telles que les finances, les ressources humaines (RH) ou l’informatique. Une hiérarchie au sein d’une unité business est courante. Pour les grandes organisations multinationales, vous pouvez avoir des unités commerciales qui identifient les opérations régionales indépendantes et les opérations spécifiques dans la région.
    Table du département [cmn_department]
    La table Département comprend un niveau de détail plus précis sur une unité business. La table Département vous offre un autre moyen de classer les utilisateurs, les groupes, les ressources et les CI.
    Tables du cycle de vie

    CSDM Paires de valeurs de cycle de vie Suivez les cycles de vie des produits, des actifs, des contrats, des CI, des emplacements et d’autres objets. L’utilisation cohérente des valeurs standard vous aide à suivre les objets tout au long de leurs transitions dans le temps. Le reporting peut donc refléter fidèlement l’état réel des CI : utilisation, disponibilité, fin de support, etc.

    La norme CSDM Paire de valeurs de cycle de vie couvre toutes les phases du cycle de vie d’une instance de produit.
    • A life cycle stage est l’une des grandes phases par lesquelles passe un CI, par exemple, de sa création ou de son approvisionnement à l’exploitation, puis peut-être à la fin de vie.
    • life cycle stage status est l’état particulier d’un CI dans l’étape actuelle de son cycle de vie.
    Par exemple, un CI matériel/physique à l’étape Opérationnel peut changer d’état d’étape au fil du temps, passant de En cours d’utilisation à En cours de maintenance et à Fin de support. Un CI matériel/physique différent peut passer de En cours d’utilisation à Fin de support sans jamais avoir été à l’étatEn cours de maintenance .
    Valeurs de cycle de vie autorisées pendant la phase opérationnelle d’un cycle de vie de CI tangible/physique
    Remarque :
    La table [life_cycle_control] utilise le type de CI (tangible/physique, document et contrat, emplacement, etc.) pour déterminer les valeurs d’état de l’étape du cycle de vie disponibles pour chaque étape du cycle de vie.

    Pour tirer pleinement parti des normes de cycle de vie, vous pouvez mapper les CSDM données d’état héritées au .Paires de valeurs de cycle de vie Consultez Activation de la synchronisation du cycle de vie de l’actif legacy cible.

    Regardez la ServiceNow Community vidéo : CSDM Discussion sur le produit et le cycle de vie V4