Votre modèle de données pour la gestion du changement
Votre modèle de données pour la gestion du changement
- Attributs recommandés à collecter
- Activités clés à suivre pour une découverte précise des processus
- Guide pour l'extraction des données de ServiceNow
Attributs de Change Management
| Nom | Description | ||
|---|---|---|---|
|
Heure de l'événement
EventTime
|
L'horodatage précis du moment où une activité ou un événement spécifique s'est produit. | ||
|
Description
L'heure de l'événement enregistre la date et l'heure exactes auxquelles une activité a été effectuée ou un changement de statut a été enregistré. Cet horodatage est essentiel pour ordonner les événements chronologiquement et pour toutes les analyses basées sur la durée. En Process Mining, cet attribut permet le calcul des temps de cycle, des temps de traitement et des temps d'attente entre les activités. Il est essentiel pour les tableaux de bord qui analysent les performances, tels que le temps de cycle d'approbation des changements et le flux de processus de changement de bout en bout. Des horodatages précis sont la base pour identifier les retards et mesurer l'efficacité des processus par rapport aux SLA.
Pourquoi c'est important
Cet horodatage est crucial pour séquencer correctement les événements et calculer toutes les métriques basées sur le temps, y compris les temps de cycle, les durées et le respect des SLA.
Où obtenir
Table ServiceNow : sys_audit, Champ : sys_created_on. Ceci fournit l'horodatage pour chaque changement enregistré.
Exemples
2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:05:00Z
|
|||
|
ID de demande de changement
ChangeRequestNumber
|
L'identifiant unique pour une demande de changement, servant d'ID de cas principal pour regrouper tous les événements liés. | ||
|
Description
L'ID de demande de changement est la pierre angulaire de l'analyse du processus de gestion du changement. C'est un numéro unique attribué à chaque demande de changement, tel que 'CHG0030001', qui lie toutes les activités, approbations et tâches entre elles. En Process Mining, cet attribut est utilisé pour reconstruire le parcours de bout en bout de chaque changement individuel. Il permet aux analystes de retracer le cycle de vie complet de la création à la clôture, offrant une vue cohérente de la manière dont chaque changement progresse dans le système. L'analyse des processus regroupés par cet ID est essentielle pour calculer les temps de cycle, identifier les boucles de retravail et comprendre les variantes de processus.
Pourquoi c'est important
Cet ID est essentiel pour suivre l'ensemble du cycle de vie d'un changement, permettant une analyse complète du flux de processus, de la durée et de la conformité pour chaque demande.
Où obtenir
Table ServiceNow : change_request, Champ : number
Exemples
CHG0030001CHG0030045CHG0030112
|
|||
|
Nom de l'activité
ActivityName
|
Le nom d'un événement ou d'une tâche spécifique qui s'est produit au sein du processus de gestion du changement. | ||
|
Description
Le Nom de l'Activité décrit une étape discrète ou un changement de statut dans le cycle de vie d'une demande de changement. Les exemples incluent 'Changement en attente d'évaluation', 'Approbation demandée' et 'Changement implémenté'. Ces activités constituent les nœuds de la carte des processus découverte. L'analyse de ces activités permet un examen détaillé du flux de processus. En suivant la séquence et la fréquence des activités, les organisations peuvent identifier les chemins courants, les déviations du processus standard et les goulots d'étranglement où les changements bloquent fréquemment. Ceci est fondamental pour la visualisation du processus et le calcul de métriques telles que les temps de transition entre les étapes.
Pourquoi c'est important
Il constitue la colonne vertébrale de la carte des processus, permettant la visualisation du flux de processus, l'identification des goulots d'étranglement et l'analyse des déviations.
Où obtenir
Dérivé des modifications dans le champ 'state' ou d'autres champs d'état clés de la table
Exemples
Changement approuvéImplémentation démarréeChangement closChangement annulé
|
|||
|
Élément de configuration
ConfigurationItem
|
Le composant informatique, service ou système spécifique qui est le sujet du changement. | ||
|
Description
L'Élément de Configuration (CI) est l'actif de la Base de Données de Gestion de Configuration (CMDB) qui sera affecté par le changement. Il peut s'agir d'un serveur, d'une application logicielle, d'un périphérique réseau ou d'un service métier. Cet attribut fournit un contexte critique pour le changement. En Process Mining, il permet de segmenter l'analyse par type d'actif modifié. Par exemple, le tableau de bord 'Change Testing Duration Analysis' utilise cet attribut pour comparer les temps de test pour différentes applications ou systèmes, aidant à identifier quels CIs sont associés à des cycles de test plus longs.
Pourquoi c'est important
Fournit un contexte métier essentiel, permettant à l'analyse d'être filtrée par l'application, le service ou le système affecté pour identifier les problèmes spécifiques aux composants.
Où obtenir
Table ServiceNow : change_request, Champ : cmdb_ci
Exemples
SAP ERPOracle Database 19cService de messagerieWebServer-01
|
|||
|
État du changement
ChangeState
|
L'état actuel ou historique de la demande de changement, tel que 'Assess', 'Authorize', 'Implement' ou 'Closed'. | ||
|
Description
L'attribut État du Changement représente le statut d'une demande de changement à un moment donné. Il fournit un résumé de haut niveau de l'emplacement du changement dans son cycle de vie. Contrairement à l'Activité, qui représente un événement spécifique, l'État est la condition résultant de cet événement. Dans l'analyse, l'État du Changement est utilisé pour catégoriser les cas et comprendre leurs résultats. Il est fondamental pour filtrer les changements, par exemple, pour analyser uniquement les changements 'Closed' ou pour chercher pourquoi de nombreux changements sont bloqués à l'état 'Authorize'. Il soutient directement les KPI tels que le Taux d'Échec des Changements lorsqu'un état 'Failed' existe.
Pourquoi c'est important
Fournit un instantané du statut de la demande de changement, permettant l'analyse des résultats, le filtrage des cas et l'identification des changements bloqués.
Où obtenir
Table ServiceNow : change_request, Champ : state
Exemples
ÉvaluerAutoriserPlanifiéImplementExamenClôturéAnnulé
|
|||
|
Groupe d'assignation
AssignmentGroup
|
L'équipe ou le groupe responsable de la demande de changement. | ||
|
Description
Le Groupe d'Affectation indique quelle équipe est actuellement responsable de la demande de changement, telle que 'Approbation CAB', 'Ingénierie Réseau' ou 'Administrateurs de Bases de Données'. C'est une dimension critique pour l'analyse de la performance des processus à travers différentes zones fonctionnelles. Cet attribut est utilisé pour mesurer l'efficacité au niveau des équipes, identifier les goulots d'étranglement au sein de groupes spécifiques et analyser l'efficacité des transferts entre les équipes. Des tableaux de bord comme 'Efficacité des transferts inter-fonctionnels' et 'Débit d'implémentation des changements' s'appuient fortement sur ces données pour identifier les retards causés par les dépendances inter-équipes.
Pourquoi c'est important
Permet l'analyse des performances par équipe, en mettant en évidence les goulots d'étranglement spécifiques aux groupes et en mesurant l'efficacité des transferts entre les différentes zones fonctionnelles.
Où obtenir
Table ServiceNow : change_request, Champ : assignment_group
Exemples
Approbation du CABÉquipe réseauSupport serveurAdministrateurs de bases de `données`
|
|||
|
Heure de fin
EndTime
|
L'horodatage de fin d'une activité. Il est souvent dérivé de l'heure de début de l'activité suivante. | ||
|
Description
L'Heure de fin marque l'achèvement d'une activité. Bien que les systèmes source enregistrent souvent le début d'un événement, l'heure de fin est fréquemment déduite. Elle est généralement calculée comme l'horodatage de l'activité suivante dans la séquence pour le même cas. Cet attribut est essentiel pour calculer la durée de chaque activité, appelée temps de traitement. Comprendre combien de temps chaque étape prend est fondamental pour identifier les goulots d'étranglement et les inefficacités du processus. Pour la dernière activité d'un cas, l'Heure de fin est la même que l'Heure de début.
Pourquoi c'est important
Permet le calcul du temps de traitement des activités, ce qui est crucial pour identifier les goulots d'étranglement et mesurer la durée des étapes spécifiques du processus.
Où obtenir
Cet attribut est généralement calculé lors de la transformation des données en prenant le StartTime de l'événement suivant pour le même CaseId.
Exemples
2023-10-26T10:05:12Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
|
|||
|
Niveau de risque
RiskLevel
|
Le niveau de risque évalué du changement, tel que 'Élevé', 'Modéré' ou 'Faible'. | ||
|
Description
Le Niveau de Risque est le résultat du processus d'évaluation des risques pour une demande de changement. Il quantifie le potentiel de conséquences négatives si le changement est implémenté, aidant à déterminer le niveau d'examen et d'approbation requis. Cet attribut est clé pour le tableau de bord 'Standardisation de l'évaluation des risques', où il est utilisé pour vérifier si des changements similaires reçoivent des évaluations de risque cohérentes. L'analyse des flux de processus par niveau de risque peut également révéler si les changements à haut risque suivent correctement un chemin d'approbation et de test plus rigoureux par rapport aux changements à faible risque, ce qui est un contrôle de conformité clé.
Pourquoi c'est important
Essentiel pour l'analyse de conformité et pour garantir que les changements à haut risque reçoivent le niveau d'examen approprié et suivent un processus plus rigoureux.
Où obtenir
Table ServiceNow : change_request, Champ : risk
Exemples
ÉlevéModéréFaible
|
|||
|
Priorité
Priority
|
Le niveau de priorité de la demande de changement, déterminé par son impact et son urgence. | ||
|
Description
La Priorité indique l'importance d'une demande de changement et détermine l'ordre dans lequel elle doit être traitée. Elle est souvent dérivée de l'impact et de l'urgence du changement, avec des valeurs telles que 'Critique', 'Élevée', 'Modérée' et 'Faible'. L'analyse par priorité est essentielle pour garantir que les changements à haute priorité sont traités plus rapidement que ceux à faible priorité. Elle soutient le tableau de bord 'Critical Change Performance' en permettant aux analystes de suivre les temps de cycle et les taux d'échec spécifiquement pour les changements les plus importants. Toute déviation où les changements à faible priorité sont finalisés plus rapidement que ceux à haute priorité indique un problème d'allocation des ressources ou d'exécution des processus.
Pourquoi c'est important
Crucial pour évaluer si les ressources sont correctement allouées aux changements les plus critiques et pour surveiller leurs performances séparément.
Où obtenir
Table ServiceNow : change_request, Champ : priority
Exemples
1 - Critique2 - Élevée3 - Modérée4 - Faible
|
|||
|
Type de modification
ChangeType
|
La classification du changement, telle que 'Standard', 'Normal' ou 'Urgent'. | ||
|
Description
Le type de changement catégorise la demande de changement en fonction de sa nature, de son risque et de ses exigences d'approbation. Les changements standard sont pré-approuvés, les changements normaux suivent le processus complet, et les changements d'urgence utilisent un chemin accéléré. Ceci est une dimension fondamentale pour l'analyse des processus, car différents types de changements ont des modèles de processus distincts et légitimes. Comparer la performance des changements normaux par rapport aux changements d'urgence peut révéler des informations importantes sur l'adhérence aux processus et l'efficacité. Il est également utilisé dans des tableaux de bord comme 'Standardisation de l'évaluation des risques' pour garantir que des changements similaires sont traités de manière cohérente.
Pourquoi c'est important
Permet la segmentation de l'analyse, car les différents types de changements suivent des flux de processus autorisés différents et ont des attentes de performance uniques.
Où obtenir
Table ServiceNow : change_request, Champ : type
Exemples
StandardNormalUrgence
|
|||
|
Attribué à l'utilisateur
AssignedToUser
|
L'utilisateur individuel responsable de la demande de changement à un moment précis. | ||
|
Description
Cet attribut identifie la personne spécifique assignée à travailler sur la demande de changement. Cela peut changer plusieurs fois tout au long du cycle de vie à mesure que la demande se déplace entre différentes étapes et équipes. L'analyse par utilisateur aide à comprendre la distribution de la charge de travail, les performances individuelles et à identifier les besoins en formation. Elle est également clé pour analyser les transferts, en particulier lorsqu'elle est combinée avec le Groupe d'Affectation, pour voir l'efficacité avec laquelle le travail est transmis entre les individus.
Pourquoi c'est important
Aide à suivre la charge de travail et les performances des utilisateurs individuels, et est crucial pour analyser les retards de transfert entre différentes ressources.
Où obtenir
Table ServiceNow : change_request, Champ : assigned_to
Exemples
Beth AnglinDavid LooAbel Tuter
|
|||
|
Code de fermeture
CloseCode
|
Un code indiquant le résultat lorsque la demande de changement a été clôturée, tel que 'Réussie' ou 'Échouée'. | ||
|
Description
Le Code de clôture fournit une disposition finale pour une demande de changement complétée. Il enregistre formellement si le changement a été implémenté avec succès, avec des problèmes, ou a été annulé. Cet attribut est une entrée directe pour le KPI 'Taux d'échec des changements'. En analysant la distribution des codes de clôture, les organisations peuvent quantifier le succès de leurs initiatives de changement. Filtrer la carte des processus pour les changements avec un code de clôture 'Unsuccessful' est une technique puissante pour l'analyse des causes profondes, révélant les schémas de processus courants qui mènent à l'échec.
Pourquoi c'est important
Mesure directement le résultat d'un changement, fournissant les données primaires nécessaires pour calculer le taux d'échec des changements et analyser les causes profondes des changements échoués.
Où obtenir
Table ServiceNow : change_request, Champ : close_code
Exemples
RéussiRéussi avec des problèmesÉchec / Annulé
|
|||
|
Dernière mise à jour des données
LastDataUpdate
|
Le timestamp indiquant la dernière actualisation des données de cet enregistrement depuis le système source. | ||
|
Description
Cet attribut fournit l'horodatage de la dernière extraction de données. C'est un champ de métadonnées critique pour comprendre l'actualisation des données analysées. Les analystes utilisent cet horodatage pour confirmer qu'ils travaillent avec des informations à jour et pour comprendre la récence des données. Il est particulièrement important pour les tableaux de bord opérationnels qui surveillent la performance continue des processus, garantissant que les décisions ne sont pas basées sur des données obsolètes.
Pourquoi c'est important
Indique l'actualisation des données, garantissant que les analyses et les tableaux de bord sont basés sur des informations actuelles et pertinentes.
Où obtenir
C'est un champ de métadonnées généré pendant le processus d'extraction et de transformation des données (ETL), indiquant l'heure de l'extraction des données.
Exemples
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
Est un retravail
IsRework
|
Un indicateur booléen qui est vrai si une activité représente une répétition d'une étape précédente dans le même cas. | ||
|
Description
Cet attribut calculé identifie les activités qui constituent un retravail. Le retravail se produit lorsque le processus doit revenir à une étape déjà terminée, comme un changement rejeté après approbation et renvoyé pour réévaluation. Ce drapeau est crucial pour quantifier l'inefficacité du processus. Il soutient directement le KPI 'Taux de retravail des changements' et le tableau de bord 'Analyse des échecs et retravaux des changements'. En filtrant les activités où 'Is Rework' est vrai, les analystes peuvent isoler et étudier les causes du retravail, telles que des évaluations initiales incomplètes ou des exigences changeantes, et prendre des mesures pour réduire le gaspillage.
Pourquoi c'est important
Quantifie directement l'inefficacité des processus en signalant les tâches répétées, aidant à identifier et à traiter les causes profondes des boucles de processus et des efforts gaspillés.
Où obtenir
Calculé lors de la transformation des données en détectant si la même activité (ou une activité antérieure dans le flux standard) s'est déjà produite pour le CaseId donné.
Exemples
truefaux
|
|||
|
État du SLA
SlaState
|
Le statut de la demande de changement par rapport à son Accord de Niveau de Service (SLA), tel que 'En bonne voie', 'À risque' ou 'Violé'. | ||
|
Description
L'État SLA indique si la demande de changement progresse dans les délais définis par son SLA. Ce statut peut être suivi à chaque étape du processus. Cet attribut est essentiel pour le suivi de la conformité aux engagements de niveau de service. C'est la source de données principale pour le tableau de bord 'Vue d'ensemble des performances SLA des changements' et le KPI 'Taux de respect des SLA des changements'. L'analyse des lieux et des raisons des violations de SLA permet à l'organisation de résoudre les retards systémiques et d'améliorer la prévisibilité de la prestation de services.
Pourquoi c'est important
Fournit une mesure directe de la performance par rapport aux délais, permettant un suivi proactif et une analyse des violations de SLA pour améliorer la prestation de services.
Où obtenir
Ceci peut provenir de la table 'task_sla' dans ServiceNow, qui suit les SLA liés à des tâches comme les demandes de changement, ou être calculé sur la base des champs de date d'échéance.
Exemples
En bonne voieÀ risqueDépassé
|
|||
|
Impact
Impact
|
L'effet potentiel du changement sur les opérations métier, évalué sur une échelle telle que Élevé, Moyen ou Faible. | ||
|
Description
L'Impact mesure l'effet potentiel sur l'activité si la demande de changement n'est pas gérée correctement. C'est un élément d'entrée clé, avec l'Urgence, pour déterminer la Priorité globale du changement. L'analyse par Impact permet de s'assurer que les changements affectant les services critiques sont gérés avec le soin approprié. Elle est utilisée dans le tableau de bord 'Critical Change Performance' pour isoler et surveiller les changements ayant un impact commercial élevé. Elle sert également à vérifier la cohérence de l'évaluation des risques, garantissant que les changements à fort impact ne reçoivent pas un faible niveau de risque sans justification.
Pourquoi c'est important
Aide à prioriser les changements en fonction de leur effet commercial potentiel et est utilisé pour valider que les changements à fort impact sont gérés avec la diligence appropriée.
Où obtenir
Table ServiceNow : change_request, Champ : impact
Exemples
1 - Élevée2 - Moyenne3 - Faible
|
|||
|
Système source
SourceSystem
|
Le système d'où les données ont été extraites, généralement 'ServiceNow'. | ||
|
Description
Cet attribut identifie l'origine des données du processus. Bien que dans ce cas, il devrait être ServiceNow, c'est un champ crucial pour la gouvernance des données et pour les scénarios où les données de plusieurs systèmes pourraient être fusionnées. En analyse, il assure une traçabilité claire des données et aide à valider la source des données. Pour les organisations disposant de plusieurs outils ITSM ou de systèmes intégrés, cet attribut permet de filtrer et de comparer les processus sur différentes plateformes.
Pourquoi c'est important
Fournit une traçabilité claire des données, garantissant que l'origine des données du processus est documentée, ce qui est vital pour la gouvernance des données et l'analyse multi-système.
Où obtenir
Il s'agit généralement d'une valeur statique ajoutée lors du processus d'extraction et de transformation des données (ETL).
Exemples
ServiceNowServiceNow_PRODSNOW_ITSM
|
|||
|
Temps de cycle
CycleTime
|
Le temps total écoulé entre la création et la clôture d'une demande de changement. | ||
|
Description
Le temps de cycle est une métrique au niveau du cas qui mesure la durée totale du cycle de vie d'une demande de changement. Il est calculé comme la différence entre l'horodatage du tout premier événement et l'horodatage du tout dernier événement pour une demande de changement donnée. Ceci est un KPI critique pour mesurer la vitesse globale du processus. Il est utilisé dans le tableau de bord 'Flux de processus de changement de bout en bout' pour offrir une vue d'ensemble des performances du processus. L'analyse des tendances du temps de cycle et leur comparaison selon différentes dimensions comme le type de changement ou la priorité aide les organisations à identifier les opportunités d'amélioration stratégique des processus.
Pourquoi c'est important
Mesure la durée de bout en bout du processus de changement, fournissant un indicateur clé de la vélocité et de l'efficacité globales du processus.
Où obtenir
Calculé au niveau du cas lors de l'analyse des données en soustrayant le StartTime minimum du StartTime maximum pour chaque CaseId.
Exemples
60480012096002592000
|
|||
|
Temps de traitement
ProcessingTime
|
La durée d'une seule activité, calculée comme la différence entre son Heure de fin et son Heure de début. | ||
|
Description
Le Temps de traitement, également connu sous le nom de durée d'activité, mesure le temps passé à travailler activement sur une tâche spécifique. Il est calculé en soustrayant l'Heure de début de l'activité de son Heure de fin. Cette métrique calculée est fondamentale pour l'analyse des performances. Elle permet d'identifier les étapes les plus chronophages du processus, qui sont souvent les principales cibles des efforts d'optimisation. Les tableaux de bord analysant la durée des tests ou le temps de cycle d'évaluation des risques sont directement basés sur cette métrique pour les activités pertinentes.
Pourquoi c'est important
Mesure la durée des activités individuelles, permettant d'identifier les étapes les plus chronophages qui sont les principaux candidats à l'optimisation.
Où obtenir
Calculé lors de la transformation des données : EndTime - StartTime.
Exemples
259200360086400
|
|||
|
Urgence
Urgency
|
La vitesse à laquelle un changement doit être résolu, évaluée sur une échelle telle que Élevée, Moyenne ou Faible. | ||
|
Description
L'Urgence définit la rapidité avec laquelle un changement doit être implémenté. Elle reflète la sensibilité au temps de la demande du point de vue métier. Avec l'Impact, elle est utilisée pour calculer la Priorité globale. Bien que la Priorité soit le champ principal pour l'analyse, l'Urgence fournit un contexte additionnel. Elle peut être utilisée pour enquêter sur les raisons pour lesquelles certains changements sont marqués comme urgents et si le processus les gère efficacement sans compromettre la stabilité. Elle aide à répondre à des questions sur la fréquence à laquelle l'organisation est en mode réactif, à haute urgence.
Pourquoi c'est important
Fournit un contexte sur la sensibilité au temps d'un changement, aidant à analyser si le processus gère efficacement les requêtes critiques en termes de temps.
Où obtenir
Table ServiceNow : change_request, Champ : urgency
Exemples
1 - Élevée2 - Moyenne3 - Faible
|
|||
Activités de Change Management
| Activité | Description | ||
|---|---|---|---|
|
Changement annulé
|
La demande de changement a été retirée ou annulée à un certain point avant l'achèvement de l'implémentation. Il s'agit d'un état final alternatif capturé lorsque l'état est défini sur 'Canceled'. | ||
|
Pourquoi c'est important
L'analyse des changements annulés peut révéler des inefficacités de processus, telles que des demandes créées inutilement ou bloquées en approbation trop longtemps, devenant obsolètes.
Où obtenir
Déduit du champ 'state' dans la table change_request étant défini sur 'Canceled'. L'horodatage est capturé à partir du journal d'audit pour ce changement d'état.
Capture
Capturez l'horodatage lorsque le champ 'state' est mis à jour vers 'Canceled'.
Type d'événement
inferred
|
|||
|
Changement approuvé
|
La demande de changement a reçu toutes les autorisations nécessaires pour passer aux phases de planification et d'implémentation. C'est un jalon critique, capturé lorsque l'approbation finale est accordée et que le champ 'approval' est défini sur 'approved'. | ||
|
Pourquoi c'est important
Ce jalon conclut la phase d'approbation. Il est essentiel pour mesurer les temps de cycle d'approbation et identifier les goulots d'étranglement dans le processus de prise de décision.
Où obtenir
Déduit du changement du champ 'approval' de la table change_request vers 'approved'. L'horodatage provient de l'historique d'audit pour ce changement.
Capture
Capturez l'horodatage lorsque le champ 'approval' devient 'approved'.
Type d'événement
inferred
|
|||
|
Changement clos
|
La demande de changement a été menée à bien, examinée et est maintenant considérée comme terminée. C'est le point d'arrivée de succès principal pour le processus et est capturée lorsque l'état du changement passe à 'Closed'. | ||
|
Pourquoi c'est important
Cette activité marque l'achèvement réussi du cycle de vie du changement. C'est l'événement de fin pour mesurer la durée du processus de bout en bout et le respect des SLA.
Où obtenir
Déduit du champ 'state' dans la table change_request étant défini sur 'Closed'. L'horodatage est extrait de l'historique d'audit pour ce changement d'état final.
Capture
Capturez l'horodatage lorsque le champ 'state' est mis à jour vers 'Closed'.
Type d'événement
inferred
|
|||
|
Changement implémenté
|
Le travail d'implémentation a été achevé, et le changement est prêt pour examen, vérification ou test. Cette activité est déduite lorsque l'état de la demande de changement passe de 'Implement' à 'Review'. | ||
|
Pourquoi c'est important
C'est un jalon critique qui clôture la phase d'implémentation. C'est un événement clé pour le calcul des KPI 'Taux d'échec des changements' et 'Taux de retravail des changements'.
Où obtenir
Déduit d'une transition d'état de 'Implement' vers un état subséquent comme 'Review'. L'horodatage est capturé à partir de l'historique d'audit du champ 'state' dans la table change_request.
Capture
Identifier quand le champ 'state' passe de 'Implement' à 'Review'.
Type d'événement
inferred
|
|||
|
Changement planifié
|
Le changement approuvé s'est vu attribuer une date de début et de fin planifiée et est maintenant officiellement au calendrier d'implémentation. Ceci est déduit lorsque l'état de la demande de changement passe à 'Scheduled'. | ||
|
Pourquoi c'est important
Cette activité sépare les étapes de planification et d'approbation de la phase d'implémentation active. Le temps passé dans cet état peut indiquer des retards entre l'approbation et le début du travail.
Où obtenir
Déduit d'un changement du champ 'state' dans la table change_request vers 'Scheduled'. L'horodatage est capturé à partir de l'entrée du journal d'audit correspondante.
Capture
Suivre les changements du champ 'state' vers 'Scheduled' dans l'historique d'audit de la table change_request.
Type d'événement
inferred
|
|||
|
Demande de changement créée
|
Cette activité marque la création d'un nouvel enregistrement de demande de changement dans le système. C'est le début officiel du processus de gestion du changement et elle est capturée lorsqu'une nouvelle entrée est insérée dans la table change_request. | ||
|
Pourquoi c'est important
C'est l'événement de début principal pour le processus. L'analyse du temps écoulé entre cette activité et les autres révèle le délai total et aide à identifier les retards au tout début du processus.
Où obtenir
Cet événement correspond à l'horodatage de création de l'enregistrement (sys_created_on) dans la table change_request de ServiceNow.
Capture
Utilisez l'horodatage sys_created_on de la table change_request.
Type d'événement
explicit
|
|||
|
Risque et impact évalués
|
Représente l'achèvement de l'analyse des risques et des impacts pour la demande de changement. C'est un jalon crucial avant de solliciter l'approbation et est souvent déduit lorsque le changement passe d'un état 'Assess' à un état 'Authorize' ou 'Awaiting Approval'. | ||
|
Pourquoi c'est important
Le suivi de la durée de la phase d'évaluation est clé pour le KPI 'Temps de cycle moyen d'évaluation des risques'. Il aide à standardiser le processus d'évaluation et à identifier où les analyses prennent trop de temps.
Où obtenir
Déduit de la transition du champ 'state' dans la table change_request de 'Assess' à 'Authorize'. L'horodatage de l'événement est capturé à partir du journal d'audit de ce changement d'état.
Capture
Identifier quand le champ 'state' passe de 'Assess' à un état subséquent comme 'Authorize'.
Type d'événement
inferred
|
|||
|
Approbation demandée
|
Cette activité signifie que la demande de changement a été formellement soumise pour approbation, généralement à un gestionnaire ou à un Comité Consultatif des Changements (CAB). Cet événement est capturé lorsque le statut d'approbation de la demande de changement est défini sur 'requested'. | ||
|
Pourquoi c'est important
Ceci marque le début du cycle d'approbation. Mesurer le temps entre cet événement et 'Change Approved' calcule directement le KPI 'Temps moyen d'approbation des changements'.
Où obtenir
Déduit du changement du champ 'approval' dans la table change_request vers 'requested'. L'horodatage est enregistré à partir de la table sys_audit pour ce champ.
Capture
Horodatage du moment où le champ 'approval' dans la table change_request est défini sur 'requested'.
Type d'événement
inferred
|
|||
|
Changement en attente d'évaluation
|
La demande de changement a été soumise et est maintenant en attente d'évaluation technique et métier. Ceci est généralement déduit lorsque l'état de la demande de changement passe à 'Assess' ou un statut similaire, indiquant qu'elle a quitté la phase de brouillon. | ||
|
Pourquoi c'est important
Cette activité aide à mesurer le temps de transfert initial du demandeur à l'équipe d'évaluation. Des retards ici peuvent indiquer des problèmes de qualité des données initiales ou de disponibilité des ressources pour l'évaluation.
Où obtenir
Déduit d'un changement du champ 'state' dans la table change_request, généralement vers une valeur telle que 'Assess'. L'horodatage est extrait de l'historique d'audit (sys_audit) pour ce changement de champ.
Capture
Suivre les changements du champ 'state' vers 'Assess' dans l'historique d'audit de la table change_request.
Type d'événement
inferred
|
|||
|
Changement rejeté
|
La demande de changement a été refusée par un approbateur ou le CAB. Cette activité représente un état terminal pour la demande, à moins qu'elle ne soit retravaillée et soumise à nouveau. Elle est capturée lorsque le champ 'approval' est défini sur 'rejected'. | ||
|
Pourquoi c'est important
Le suivi des rejets aide à identifier les raisons courantes de refus, telles que des informations incomplètes ou un risque élevé. Cette analyse peut améliorer la qualité des futures soumissions de changements.
Où obtenir
Déduit du changement du champ 'approval' dans la table change_request vers 'rejected'. L'horodatage est capturé à partir de l'historique d'audit.
Capture
Capturez l'horodatage lorsque le champ 'approval' devient 'rejected'.
Type d'événement
inferred
|
|||
|
Changement rouvert
|
La demande de changement a été renvoyée à un état précédent, tel que 'Implement' ou 'Assess', après avoir atteint une étape ultérieure. Cet événement est déduit d'une transition d'état non linéaire et signifie un retravail. | ||
|
Pourquoi c'est important
Cette activité est cruciale pour identifier les boucles de retravail et calculer le 'Taux de retravail des changements'. Les réouvertures fréquentes indiquent des problèmes de qualité d'implémentation, de test ou de planification.
Où obtenir
Déduit en analysant la séquence des changements d'état dans l'historique d'audit de la table change_request. Une transition d'un état ultérieur (par exemple, 'Review') à un état antérieur (par exemple, 'Implement') indique un événement de réouverture.
Capture
Détecter une transition non séquentielle et arrière dans l'historique du champ 'state'.
Type d'événement
inferred
|
|||
|
Examen en cours
|
Un examen post-implémentation (PIR) est en cours pour déterminer si le changement a été réussi et a atteint ses objectifs. Ceci est enregistré lorsque l'état de la demande de changement est défini sur 'Review'. | ||
|
Pourquoi c'est important
L'analyse de la durée de la phase de révision aide à identifier les retards dans la validation du succès du changement. Elle met également en évidence les changements non conformes où cette étape est ignorée.
Où obtenir
Déduit du changement du champ 'state' dans la table change_request vers 'Review'. L'horodatage provient du journal d'audit pour ce changement d'état.
Capture
Capturez l'horodatage du changement d'état vers 'Review' à partir de l'historique d'audit de
Type d'événement
inferred
|
|||
|
Implémentation démarrée
|
Le travail d'implémentation du changement a activement commencé. Ceci est capturé lorsque l'état de la demande de changement est mis à jour vers 'Implement', signifiant la transition de la planification à l'exécution. | ||
|
Pourquoi c'est important
Ceci marque le début du travail d'implémentation pratique. C'est le point de départ pour mesurer le KPI 'Durée moyenne d'implémentation' et analyser l'efficacité de l'équipe.
Où obtenir
Déduit du changement du champ 'state' dans la table change_request vers 'Implement'. L'horodatage est extrait du journal d'audit pour cette transition d'état.
Capture
Capturez l'horodatage du changement d'état vers 'Implement' à partir de l'historique d'audit de
Type d'événement
inferred
|
|||