Domaine de base du cadre de CSDM travail
Le domaine de base implique des tables qui contiennent des données de base qui sont référencées à partir d’objets dans les autres CSDM domaines. Des données de base sont requises avant de pouvoir utiliser ServiceNow des produits ou ajouter des données à la .CMDB
Les tables du domaine Foundation ne sont pas utilisées dans Base de données de gestion des configurations (CMDB) les 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 gestionnaires de données, les propriétaires de produits et les gestionnaires de contrats.
Processus de gestion
Un processus business a un début et une fin bien définis. Des exemples de processus commerciaux dans le secteur bancaire sont le processus d’intégration des clients et le processus de vérification de la solvabilité. 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 à l’aide de l’attribut parent comme référence à un processus business parent.
Le processus business est un CI géré manuellement qui peut identifier la criticité déclarée et déterminée, ainsi que l’impact sur la confidentialité, l’intégrité et la disponibilité. Les processus business peuvent être examinés mensuellement, trimestriellement, semestriellement ou annuellement. De plus, la date d’examen suivante peut être enregistrée. Pour plus d’informations, reportez-vous aux rubriques Gestion des processus métier et Création d’un processus métier.
Contrats
Un contrat est un accord contraignant entre deux parties. Dans le , les Now Platformcontrats 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èles de contrat du module Modèles de produits . Les contrats sont stockés dans la table [ast_contract].
- Utilisez l’application pour gérer et suivre les Gestion des contrats contrats. Reportez-vous à la section de l’application Contract Management.
- 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 Vendor Management Workspace peuvent prendre en charge les CI matériels dans le cadre d’un SLA.
- Dans le Gestion du service clientèle produit, les contrats de service définissent le type d’assistance 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 autorisations de service et SLA. Consultez Définir un contrat de service dans Customer Service Management.
Produits et modèles de produits
Un modèle de produit est une version ou une configuration spécifique d’un produit utilisée pour gérer et suivre les applications sur le Now Platform. Les modèles de produits identifient le propriétaire de 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. Pour plus d’informations, consultez Product Catalog.
En outre, vous pouvez identifier les produits arrivant 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 de produits que votre organisation développe, vend ou utilise.
Les modèles de produits sont étendus en sept types de base : modèle d’application (indépendant de la version), modèle logiciel (spécifique à la version), modèle de contrat, modèle d’installation, modèle matériel, modèle de consommable, modèle de service. 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 24 h/24 et 7 j/7 (modèle de service).
Les modèles de produits sont stockés dans la table [cmdb_model] ou dans les tables étendues alignées sur les sept types de base. Les tables de modèle de produit ne sont pas des CI. Les éléments de configuration peuvent utiliser l’attribut ID de modèle pour référencer les modèles de produits. Par exemple, un CI d’offre de service peut faire référence à un modèle de service particulier auquel d’autres offres de service du même type font également référence.
Les CI d’application, de service et d’instance de classe logicielle ne sont pas créés via Détection, de sorte que leurs valeurs 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 produitfichier . Reportez-vous à Générer automatiquement des modèles de produits pour les CI logiques.
CMDB groupe
Un CMDB groupe est un ensemble de CI (mais n’est pas lui-même un CI). Un groupe est basé sur les résultats de requêtes enregistrées dans le générateur de requêtes, de requêtes codées ou d’entrées manuelles. Vous pouvez appliquer une action à tous les membres d’un groupe à la fois.
Vous pouvez travailler avec un CMDB groupe sur l’ensemble du Now Platform.
- Pour le CSDM, le groupe de CI dynamiques référence un CMDB groupe pour fournir une liste de CI basée sur un critère commun.
- CMDB Les groupes sont stockés dans la table [cmdb_group].
- Le CMDB groupe peut potentiellement remplacer les feuilles de calcul que vous utilisez peut-être pour regrouper vos CI.
Pour plus d’informations, consultez Groupes CMDB.
États du cycle de vie
Les états de cycle de vie suivent 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 au cours de leurs transitions au fil du temps. Les rapports peuvent donc refléter avec précision les états réels des CI : utilisation, disponibilité, fin de support, etc.
Voir la vidéo : Discussion sur le produit et le ServiceNow Communitycycle de vie CSDM V4
Les états de cycle de vie hérités sont mis à jour automatiquement
- État du modèle de produit
- État de l'actif
- Sous-état de la ressource
- Statut du contrat
- État de l’installation du CI
- Statut opérationnel du CI
- État du matériel du CI
- Sous-statut matériel de CI
Mapper vos valeurs de cycle de vie existantes aux états du cycle de vie CSDM
Utilisez le module Cartographie du cycle de vie () pour spécifier comment vos valeurs de cycle de vie existantes doivent être converties en CSDM états de cycle de vie. Le mappage garantit que Now Platform les produits « voient » les CI hérités dans votre environnement. Dans cet exemple, la valeur Installation en attente existante de l’attribut État d’installation pour les CI matériels sera toujours mappée à l’état du cycle de vie Déploiement/Test dans le CMDB. Consultez Spécifier comment mapper les états du cycle de vie hérités aux CMDB états et Activer la migration du cycle de vie.
Données communes
Les éléments de données courants ne sont pas des éléments de configuration. Les données communes sont partagées et utilisées tout au long du Now Platform. Les données courantes comprennent la structure organisationnelle (société, unité business, département), les emplacements, les groupes et les utilisateurs. De nombreux Now Platform produits s’appuient sur des données communes pour apporter une valeur commerciale.
- Disposez-vous d’une source fiable pour les données ?
- Disposez-vous de 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 ?
- Entreprise : [core_company]
- Unité business : [business_unit]
- Département : [cmn_department]
- Lieu : [cmn_location]
- Groupes : [sys_user_group]
- Utilisateurs : [sys_user]
Gestion de l’emplacement
Les données provenant de plusieurs sources et 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 d’emplacement.
- Type d’emplacement : position de l’enregistrement d’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 salle.
- Géré par groupe : groupe qui régit ou gère cet enregistrement d’emplacement.
- Validation (doublon et primaire) : marquez les enregistrements en double et filtrez manuellement les emplacements qui ne doivent pas être affichés.
- Étape du cycle de vie et État de l’étape du cycle de vie : reportez-vous aux sections États du cycle de vie.