Modèles de coûts prescriptifs pour les services d’entreprise et les options d’entreprise : hérités
Utilisez les modèles de coûts préconfigurés des services d’entreprise et des options d’entreprise avec leurs mesures prescrites pour l’allocation de poids. Comprenez la configuration système requise que chaque modèle prend en charge, les méthodes d’allocation et les ensembles de données requis pour les utiliser efficacement.
Important :
Cette fonctionnalité n’est disponible que si vous possédez une licence d’analyste ITBM .
Évaluation des coûts de niveau 2 : modèle de coûts des services d’entreprise
Le modèle de coût fournit :
- Coût de l’activation de l’entreprise : les dépenses du service informatique pour s’assurer que l’entreprise est alignée sur les initiatives de transformation.
- Coût de support de chaque service d’entreprise en termes commerciaux : coût de fourniture de services d’entreprise.
Le modèle de coût est recommandé :
- À la phase II ou si vous avez déjà investi dans la gestion financière.
- Pour une démonstration en termes de fonctions commerciales principales ou d’alignement sur les capacités de l’entreprise.
- Fournir un aperçu des facteurs de coût opérationnels.
Spécifications du modèle de coûts de l’établissement des coûts de niveau 2 – Services d’entreprise :
- La couche de catégorie de coûts est liée à la table de catégorie ITFM [itfm_bucket]. Les compartiments de coûts sont spécifiques au modèle.
- Les comptes de segment Services informatiques partagés (la deuxième couche de ce modèle) proviennent de la table Services informatiques partagés [itfm_shared_service].
- Les comptes de segment Service d’entreprise (la troisième couche de ce modèle) proviennent de la table de services [cmdb_ci_service].
- La couche Unité business est liée à la table Unité business de la plateforme [business_unit].
Évaluation des coûts de niveau 3 : modèle de coût des options d’entreprise
Le modèle de coût fournit :
- Coût de l’activation de l’entreprise : les dépenses du service informatique pour s’assurer que l’entreprise est alignée sur les initiatives de transformation.
- Coût de support de chaque capacité métier en termes commerciaux : le coût de l’innovation.
Le modèle de coût est recommandé :
- À la phase II ou si vous avez déjà investi dans la gestion financière.
- Pour une démonstration en termes de fonctions commerciales principales ou d’alignement sur les capacités de l’entreprise.
Spécifications du modèle de coût de Level 3 Costing — Business Capabilities :
- Les spécifications sont similaires à celles du modèle de coûts de niveau 2 – Services d’entreprise, aligné sur l’application d’entreprise. Cependant, il existe une couche supplémentaire pour les capacités de l’entreprise. Les comptes de ce segment proviennent de la table Capacité métier [cmdb_ci_business_capability], qui est une liste simple.
- Il existe une mesure scriptée qui aligne l’aptitude réelle associée à une application sur la capacité métier de haut niveau de la table.
Méthodes de reprise
Utilisez les méthodes d’allocation suivantes pour déplacer le coût des compartiments de coûts vers les couches supérieures du modèle (Services informatiques partagés, Allocations ou Unités business).
| Méthodes de reprise | Description |
|---|---|
| Aucune | N’est pas alloué à la couche suivante. |
| Égal | Répartit le coût de manière égale pour chaque élément auquel il est associé. |
| Manuel | Alloué par pourcentages fixes estimés ou précalculés. |
| Pondéré | Alloué en fonction de l’utilisation réelle. Par exemple, allouer à la BU en fonction du volume de demandes de changement, du volume d’incidents ou du nombre de CI ou par une propriété de l’objet auquel l’allocation est effectuée, à savoir l’effectif. |
Les mesures prescrites prennent en charge la méthode de déploiement pondéré et proviennent de données directement à partir des applications au sein de la ServiceNow plateforme. Par exemple :
- Structure organisationnelle informatique : niveau de l’unité business ou du département.
- PPM ou carte de pointage : efforts de main-d’œuvre facturés aux projets.
- CMDB : inventaire des CI avec relations, utilisation et alignement des propriétaires.
- Gestion des actifs : inventaire des actifs (utilisateur final et infrastructure) aligné sur les propriétaires des actifs.
- Gestion des services IT : volume associé à l’incident, au problème et au changement.
- Gestion des opérations IT : relations et alignement sur le matériel et les applications.
- Architecture d'entreprise (anciennement Gestion du portefeuille d’applications) : inventaire de la hiérarchie des applications, du propriétaire d’entreprise associé et de la cartographie des technologies.
Mesures prescrites : services informatiques partagés aux services d’entreprise
Voici la description de chaque mesure, ainsi qu’une explication de la méthodologie de pondération et des tables connexes dans le ServiceNow système.
Remarque :
Si les tables connexes contiennent des données incomplètes ou s’il y a des lacunes dans les données, les pourcentages de pondération calculés sont affectés.
Le modèle de coût préconfiguré commence par une pondération égale au segment suivant. Des mesures prescriptives sont disponibles pour les solutions plus matures.
- Allouer au service d’entreprise en fonction du nombre de CI
La mesure alloue le coût des services partagés aux services d’entreprise en fonction de la table de pondération suivante :
Figure 5. Allouer au service d’entreprise en fonction du nombre de CI - La table CI Relationship (Relation CI) [cmdb_rel_ci] fournit une liste de tous les CI et de leur relation avec leur CI parent, comme la dépendance, l’utilisation, les exécutions sur et le contenu par.
- La table Service [cmdb_ci_service] fournit une liste de tous les services d’entreprise qui sont les CI parents.
- La mesure prescrite effectue un décompte de CI par parent et pondère le coût pour les services d’entreprise en conséquence.
La table de poids applique la durée de vie sur la mesure suivante.
- Filtres : Child.Class n’est pas un service d’entreprise et le type est Depends on ::Used by.
- Début de la durée : début réel.
- Fin de durée : fin réelle.
- Allouer au service d’entreprise en fonction de la puissance de calcul
La mesure alloue le coût des services partagés aux services d’entreprise en fonction de la table de pondération suivante :
Figure 6. Allouer au service d’entreprise en fonction de la puissance de calcul - La table CI Relationship (Relation CI) [cmdb_rel_ci] fournit une liste de tous les CI et de leur relation avec leur CI parent, comme la dépendance, l’utilisation, les exécutions sur et le contenu par.
- La table Service [cmdb_ci_service] fournit une liste de tous les services d’entreprise, qui sont les CI parents.
- La mesure prescrite effectue un décompte de CI par serveur (Child.Class) et pondère le coût pour les services d’entreprise (parents) en conséquence.
La table de poids applique la durée de vie sur la mesure suivante :
- Filtres : Child.Class est Serveur et Type est Depends on ::Used by.
- Début de la durée : début réel.
- Fin de durée : fin réelle.
- Allouer au service d’entreprise en fonction du nombre de bases de données
La mesure alloue le coût des services partagés aux services d’entreprise en fonction de la table de pondération suivante :
Figure 7. Allouer au service d’entreprise en fonction du nombre de bases de données - La table CI Relationship (Relation CI) [cmdb_rel_ci] fournit une liste de tous les CI et de leur relation avec leur CI parent, comme la dépendance, l’utilisation, les exécutions sur et le contenu par.
- La table Service [cmdb_ci_service] fournit une liste de tous les services d’entreprise, qui sont les CI parents.
- La mesure prescrite effectue un décompte de CI par base de données (Child.Class) et pondère le coût pour les services d’entreprise (parents) en conséquence.
La table de poids applique la durée de vie sur la mesure suivante :
- Filtres : Child.Class est Base de données et Type est Depends on ::Used by.
- Début de la durée : début réel.
- Fin de durée : fin réelle.
- Allouer au service d’entreprise en fonction du volume de demandes de changement
La mesure alloue le coût des services partagés à l’unité business en fonction de la table de pondération suivante :
Figure 8. Allouer au service d’entreprise en fonction du volume de demandes de changement - La table Demande de changement [change_request] fournit une liste de toutes les demandes de changement et des demandeurs, y compris le service d’entreprise connexe.
- La table Service [cmdb_ci_service] fournit une liste de tous les services d’entreprise.
- La mesure prescrite effectue un décompte des demandes de changement par service d’entreprise et pondère les coûts en conséquence.
La table de poids applique la durée de vie sur la mesure suivante :
- Début de la durée : début réel.
- Fin de durée : fin réelle.
- Appliquer la durée de vie sélectionnée sur la table de poids.
- Allouer aux services d’entreprise en fonction du volume d’incidents
La mesure alloue le coût des services partagés à l’unité business en fonction de la table de pondération suivante :
Figure 9. Allouer aux services d’entreprise en fonction du volume d’incidents - La table Incident [incident.list] fournit une liste de tous les incidents, de leurs appelants associés et du service d’entreprise associé.
- La table Service [cmdb_ci_service] fournit une liste de tous les services d’entreprise.
- La mesure prescrite effectue un décompte des incidents par service d’entreprise (ouverts et fermés au cours de la période) et pondère les coûts en conséquence.
- Début de la durée : ouvert.
- Fin de durée : résolue.
- Appliquer la durée de vie sélectionnée sur la table de poids.
Mesures prescrites : services informatiques partagés pour les applications d’entreprise
- Allouer aux applications utilisant le nombre d’utilisateurs actifs
La mesure alloue le coût des services partagés aux applications en fonction de la mesure pondérée suivante :
Figure 10. Allouer aux applications utilisant le nombre d’utilisateurs actifs - La table Application d’entreprise [cmdb_ci_business_app] fournit une liste de toutes les applications d’entreprise.
- La mesure prescrite effectue une somme des utilisateurs actifs et pondère les coûts en fonction des applications reçues par ID système.
- Allouer aux applications en utilisant le nombre de bases de données
La mesure alloue le coût des services partagés aux applications en fonction de la mesure pondérée suivante :
Figure 11. Allouer aux applications en utilisant le nombre de bases de données - La table CI Relationship (Relation CI) [cmdb_rel_ci] fournit une liste de tous les CI et de leur relation avec leur CI parent, comme la dépendance, l’utilisation, les exécutions sur et le contenu par.
- La table Application d’entreprise [cmdb_ci_business_app] fournit une liste de toutes les applications d’entreprise, qui sont les CI parents.
- La mesure prescrite effectue un décompte de CI par base de données (Child.Class) et pondère le coût pour l’application d’entreprise (parente) en conséquence.
- Filtres : Child.Class est Base de données et Type est Depends on ::Used by.
- Début de la durée : début réel.
- Fin de durée : fin réelle.
Mesures prescrites : applications d’entreprise vers options d’entreprise
Voici la mesure scriptée à allouer aux options d’entreprise :
// Create a Scripted metric if you have complex logic to derive the weights for an Allocate to Segment.
//
// This Return Object is json:
// 1) key: The sys_id of the Allocate To segment's transaction table
// 2) value: the weight for the
//
// The API is called for each fiscal period and stored in weight Maps table which is in turn used in allocation.
// 'inputObject' is available in the script to have access to fiscal period and from Account id.
// The from account id is applicable only for "Allocate From" is part of metric setup where each entity in Allocate From table have their own weight distribution
// An 'inputObject' is injected during the evaluation of the script.
// It is an object of 2 key value pairs for fiscal period and allocate from accountId.
function getTopCapability(capabilityId){
var now_GR = new GlideRecord('cmdb_ci_business_capability');
gr.get(capabilityId);
if(gr.isValidRecord())
return getParentCapabilityRecur(now_GR);
}
function getParentCapabilityRecur(capabilityGr){
if(JSUtil.nil(capabilityGr.parent))
return capabilityGr;
else
return getParentCapabilityRecur(capabilityGr.parent.getRefRecord());
}
getScriptedWeightedMetric();
function getScriptedWeightedMetric(){
var appId = inputObject.from_id; // where inputObject.from_id is one of the Business Applications Id from Allocate From segment(Business Applications)
var relGr= new GlideRecord('cmdb_rel_ci');
relGr.addEncodedQuery('parent.sys_class_name=cmdb_ci_business_capability^child.sys_class_name=cmdb_ci_business_app');
relGr.addQuery('child',appId);
relGr.query();
var retObj={};
while(relGr.next()){
retObj[getTopCapability(relGr.parent).getUniqueValue()] = 1;
}
return retObj;
}
- La table Capacité métier [cmdb_ci_business_capability] fournit une liste de toutes les capacités métier et fait partie de Architecture d'entreprise (anciennementGestion du portefeuille d'applications).
- En substance, le script aplatit la liste des capacités métier.Remarque :Tout doit être lié à sa capacité métier de niveau 0 pour la modélisation financière, bien que les applications au sein de Architecture d'entreprise (anciennement Gestion du portefeuille d'applications) puissent être affectées à des capacités de niveau inférieur.
Figure 12. Logique métrique scriptée d’APM vers FM