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

Tables sur lesquelles vous travaillez pendant la phase Foundation

Table des processus business [cmdb_ci_business_process]

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.

Table de contrat [ast_contract]

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

Table du modèle de produit [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 des actifs et des CI par modèle de produit, vous unifiez et associez 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. Discovery peut renseigner les modèles de produits matériels 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 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 produits sont idéaux pour associer des CI qui font partie d’un seul produit digital. 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 dans le 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 tôt de la façon dont vous souhaitez signaler les informations des CI et de la façon dont vous souhaitez surveiller les CI. Ces décisions ont une incidence sur la façon dont vous créez les CMDB groupes.

Table d’emplacement [cmn_location]

La table Emplacement identifie de façon 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 exigences en matière de génération de rapports. Par exemple, vous pouvez renseigner la table d’emplacement comme suit

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. Grâce aux fonctionnalités de hiérarchie, aux données sources fiables et à vos besoins, vous pouvez créer des emplacements qui prendront en charge 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 de demandes de changement, la résolution d’incidents, la réception de notifications par e-mail ou l’exécution de tâches de commande de travaux. Les groupes utilisent également les données référentielles de la CMDB pour identifier la façon 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, règles d’affectation, rôles système ou attributs qui font référence à un groupe s’appliquent automatiquement à tous les membres du groupe.

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 commerciales internes et les clients, fabricants et fournisseurs externes.

Table de 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 champ est CMDB 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 champ Vrai ou Faux. Le marqueur Client identifie vos clients externes.

  Le marqueur 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 les produits que vous achetez. Une organisation interne peut être un fournisseur.

Table des unités 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é parente. Une unité business est une partie de votre organisation 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 business qui identifient les opérations régionales indépendantes et les opérations spécifiques dans la région.

Table de département [cmn_department]

La table Département comprend un niveau de détail plus fin sur une unité business. La table Département offre un autre moyen de classer les utilisateurs, les groupes, les actifs et les CI.

Tables de cycles 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 vous aide à suivre 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.

Remarque :

En fonction du type d’élément, la table [life_cycle_control] contrôle les valeurs d’étape de cycle de vie disponibles pour chaque étape du cycle de vie.

Vous pouvez considérer l’état du cycle de vie comme la combinaison de deux valeurs d’un actif ou d’un CI : l’étape du cycle de vie et l’état du cycle de vie au cours du cycle de vie du CI. Par exemple, un CI matériel en phase opérationnelle peut changer d’état au fil du temps, passant de En cours d’utilisation à En maintenance , puis à Fin de support. Un CI matériel différent peut passer de En coursd’utilisation à Fin de support sans jamais avoir été dans l’état En cours de maintenance .

Lorsque vous activez le cadre de CSDM travail, vous pouvez commencer à utiliser les Life Cycle Stage champs et Life Cycle Stage Status pour suivre le cycle de vie d’un actif. Pour utiliser les champs, suivez la procédure décrite dans la section Deuxième étape d’activation : activer le module d’extension CSDM. Les actifs suivants peuvent utiliser des états de cycle de vie :

• Cycle de vie du produit
• Cycle de vie du matériel
• Cycle de vie logique
• Cycle de vie du document
• Cycle de vie de l’emplacement

Regarder la vidéo : Discussion sur le produit et le ServiceNow Communitycycle de vie CSDM V4