Domaine de base dans le CSDM modèle

  • Rversion finale: Australia
  • Mis à jour 12 mars 2026
  • 9 minutes de lecture
  • Les tables du domaine Foundation contiennent des données de base qui sont référencées depuis ou vers des objets dans les autres CSDM domaines. Avant de pouvoir utiliser des ServiceNow produits, vous devez renseigner les données de base.

    Les tables du domaine Foundation ne sont pas utilisées dans CMDB des relations. Au lieu de cela, les tables contiennent des données référentielles critiques. Les utilisateurs typiques du domaine sont les propriétaires de processus, les administrateurs de données, les propriétaires de produits et les gestionnaires de contrats.

    Domaine fondamental du CSDM cadre de travail.

    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. Pour plus d’informations sur cette étape de la création de votre CMDB, reportez-vous à la section CSDM Phase de mise en œuvre : base.

    Remarque :
    Pour obtenir une présentation des tables et des attributs que vous devez renseigner pour n’importe quel domaine, reportez-vous aux vidéos répertoriées dans CSDM ressources.

    Tables de domaine de base utilisées pendant le cycle de vie de service

    Données gérées par le stratège en chef : Flux de valeur

    Flux de valeur : un flux de valeur est l’ensemble des actions qui ont lieu pour ajouter de la valeur à un client depuis la demande initiale jusqu’à la réalisation de la valeur par le client. La chaîne de valeur commence par le concept initial, passe par différentes étapes de développement et passe par la livraison et le support. Un flux de valeur commence et se termine avec un client. Le flux de valeur est aligné sur les processus business de votre organisation.

    Données gérées par le propriétaire du processus : processus business

    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.

    Dans une relation parent-enfant, les processus business peuvent être identifiés en utilisant l’attribut parent comme référence à un processus business parent.

    Le processus de gestion est un CI maintenu manuellement qui peut identifier, déclaré et déterminé, la criticité, ainsi que l’impact sur la confidentialité, l’intégrité et la disponibilité. Les processus business peuvent être révisés mensuellement, trimestriellement, semestriellement ou annuellement. En outre, la date d’examen suivante peut être enregistrée. Pour plus d’informations, voir Gestion des processus business et Créer un processus de gestion.

    Données gérées par le gestionnaire des contrats : Contracts (Contrats)

    Un contrat est un accord contraignant entre deux parties. Dans le ServiceNow AI Platform, les contrats contiennent des informations détaillées telles que le numéro de contrat, les dates de début et de fin, l’état actif, les termes et conditions, les documents, les informations de renouvellement et les conditions financières.

    • Un contrat n’est pas un CI. Les contrats utilisent les types de modèle de contrat du module Modèles de produit . Les contrats sont stockés dans la table [ast_contract].
    • Utilisez l’application pour gérer et suivre les Gestion des contrats contrats. Voir l’application Gestion des contrats.
    • Dans l’application, les Gestion des niveaux de service contrats regroupent les SLA qui se rapportent à un seul fournisseur ou client, ainsi que les CI, les emplacements, les groupes, les utilisateurs et les contrats enfants associés au contrat. Pour plus d'informations, consultez Define a service contract.
    • Les contrats de service utilisés par Espace de travail de gestion des fournisseurs peuvent prendre en charge des CI tangibles/physiques dans le cadre d’un SLA.
    • Dans le produit, les Gestion du service client contrats de service définissent le type de support que les clients reçoivent. Un contrat peut inclure un compte et un contact ou un consommateur et les actifs spécifiques qui sont couverts. Un contrat peut également inclure plusieurs droits de service et SLA. Reportez-vous à Définir un contrat de service dans Gestion du service client.

    Pour plus d'informations, consultez Définitions des valeurs de cycle de vie pour les entités de document et de contrat.

    Données gérées par le propriétaire du produit

    Produits et modèles de produits

    Les produits peuvent être regroupés pour créer une collection ou un groupe de produits, par exemple un serveur FlashBlade (modèle matériel) ou un service d’assistance 24h/24 et 7j/7 (modèle de service). En outre, vous pouvez identifier les produits qui arrivent en fin de vie tels que définis par des fournisseurs tiers ou des propriétaires de produits internes. Vous pouvez également regrouper d’autres produits en tant que composants pour représenter l’ensemble des produits que votre organisation développe, vend ou utilise.

    Un modèle de produit est une version ou une configuration spécifique d’un produit utilisé pour gérer et suivre les applications sur le ServiceNow AI Platform. Les tables Modèle de produit ne sont pas des CI. Les CI référencent les modèles de produits à l’aide de l’attribut d’ID de modèle (disponible sur toutes les CMDB tables). Par exemple, un CI d’offre de service peut faire référence à un modèle d’offre de service, tandis qu’un serveur Windows peut faire référence à un modèle matériel.

    Les modèles de produit identifient le propriétaire du produit, l’équipe, l’état du produit, la compatibilité avec d’autres produits, la référence au catalogue de produits et les objets de référence dans les différentes étapes du cycle de vie d’un produit.

    Les modèles de produits sont enregistrés dans la table [cmdb_model] via les tables étendues suivantes, appelées classes de modèles de produits.

    • Modèle d’application [cmdb_application_product_model] (indépendant de la version)
    • Modèle logiciel [cmdb_software_product_model] (spécifique à la version)
    • Modèle de contrat [cmdb_contract_product_model]
    • Modèle d’installation [cmdb_facility_product_model]
    • Modèle matériel [cmdb_hardware_product_model] (périphériques matériels/matériels)
    • Modèle de consommable [cmdb_consumable_product_model]
    • Modèle de service [cmdb_service_product_model]

    Les CI d’instance d’application, de service et de classe logicielle ne sont pas créés via , de sorte que Découverte leurs valeurs d’ID de modèle [model_id] peuvent ne pas faire référence à des Modèle de produit enregistrements. Pour vous aider à migrer vers un paradigme de gestion centré sur le produit, chaque instance d’un CI logique doit être associée à un Modèle de produit. Pour obtenir des recommandations, reportez-vous à la section Générer automatiquement des modèles de produits pour les CI logiques.

    Fonctionnalités du produit

    Dans la mise en production d’un produit numérique, une fonctionnalité (ce vers quoi vous développez) existe dans une version particulière du logiciel ou du service.

    Nomenclatures logicielles (SBOM)

    Une nomenclature logicielle logicielle est l’ensemble des composants d’un logiciel.

    Cyclone DX est pris en charge.

    Données gérées par l’administrateur des données

    CMDB groupes

    Un CMDB groupe est une collection de CI (mais n’est pas lui-même un CI). Un groupe est basé sur les résultats des requêtes enregistrées du générateur de requêtes, des requêtes codées ou des entrées manuelles. Vous pouvez appliquer une action à tous les membres d’un groupe à la fois.

    • Vous pouvez travailler avec un CMDB groupe sur le .ServiceNow AI Platform
    • Pour le CSDM, le groupe de CI dynamique fait référence à un CMDB groupe pour fournir une liste de CI basée sur un critère commun.
    • CMDB groupes sont stockés dans la table Groupe [cmdb_group].
    • Le CMDB groupe peut potentiellement remplacer les feuilles de calcul que vous utilisez pour regrouper vos CI.

    Pour plus d’informations, consultez Groupes CMDB.

    Emplacements

    Les données provenant de sources multiples et d’intégrations fédérées sont difficiles à gérer. Les attributs suivants ont été ajoutés à la table d’emplacement [cmn_location] pour simplifier la gestion :

    • Source : origine de l’enregistrement de l’emplacement.
    • Type d’emplacement : position de l’enregistrement de l’emplacement dans la hiérarchie des emplacements. Vous pouvez utiliser les options suivantes pour créer une hiérarchie des données d’emplacement en fonction de vos besoins : Région, Comté, État/Province, Ville, Site, Bâtiment/Structure, Étage et Pièce.
    • Groupe Géré par : groupe qui gouverne ou gère cet enregistrement d’emplacement.
    • Validation (doublon et primaire) : marquez les enregistrements en double et filtrez manuellement les emplacements qui ne sont pas affichés.
    • Étape du cycle de vie et État de l’étape du cycle de vie.
    Valeurs de cycle de vie

    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 de cycle de vie standard CSDM vous aide à suivre efficacement 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.

    Lorsque vous activez le CSDM cadre de travail, vous pouvez commencer à utiliser les valeurs et Life Cycle Stage Status pour suivre le Life Cycle Stage cycle de vie d’un actif. Pour utiliser les champs, suivez la procédure décrite dans .Activer le module d’extension CSDM Les processus suivants peuvent utiliser le Paires de valeurs de cycle de vie:

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

    Données communes gérées par l’administrateur des données

    Les données communes sont stockées dans les tables suivantes :
    • Société : [core_company]
    • Unité business : [business_unit]
    • Département : [cmn_department]
    • Emplacement : [cmn_location]
    • Groupes [sys_user_group] et utilisateurs [sys_user]. Lorsque la définition complète d’un CI nécessite que vous identifiiez les groupes de contacts associés au CI, vous pouvez ajouter ces données dans la liste connexe Équipes pour le CI.

    Les éléments de données communs ne sont pas des éléments de configuration. Les données communes sont partagées et utilisées dans l’ensemble du ServiceNow AI Platform. Les données communes comprennent la structure organisationnelle (société, business unit, département), les emplacements, les groupes et les utilisateurs. De nombreux ServiceNow AI Platform produits dépendent de données communes pour fournir une valeur commerciale.

    La planification de vos données communes est essentielle à la mise en œuvre efficace des produits et des ServiceNow AI Platform fonctionnalités. Tenez compte des questions suivantes :
    • Avez-vous une source fiable pour les données ?
    • Avez-vous plusieurs sources de données ?
    • À quelle fréquence les données changent-elles ?
    • Disposez-vous de la profondeur de données requise par les CI ?
    • Qui gère les données ?

    CSDM vidéos dans le ServiceNow Community

    Liste de lecture de tous CSDM vidéos