Di seguito sono riportati alcuni esempi di casi comuni e più particolari che descrivono i concetti da tenere presente durante il processo di modellazione. Tali concetti possono comportare una definizione più precisa delle metriche e un framework stabile.
Poiché il campo destinazione all'interno della definizione di metrica è facoltativo, nei casi in cui non è definito, sono disponibili report sul livello di servizio per la metrica. Tuttavia, non è possibile alcun report su livello di servizio rispetto a destinazione e deviazione, poiché non esiste alcuna destinazione con cui confrontare il livello di servizio effettivo calcolato. Questi tipi di metriche vengono definiti nei casi in cui sono necessari report per le informazioni non incluse negli obblighi contrattuali effettivi.
La definizione di questo tipo di metrica offre all'utente tutte le caratteristiche funzionali possibili di drill-down per i report, e offre al manager del livello di servizio la possibilità di applicare le misurazioni a una destinazione in qualsiasi fase in futuro.
Ad esempio:
La garanzia contrattuale prevede di fornire il 99% di disponibilità della rete e report sul numero dei tempi di inattività per ogni mese.
Vengono definite due metriche: una con una destinazione del 99% per la disponibilità, l'altra per il conteggio dei tempi di inattività ogni mese senza una destinazione. È possibile creare un report per entrambe le metriche, ma solo la prima presenta i calcoli della deviazione in virtù del relativo obbligo contrattuale.
Nota: un altro metodo possibile per risolvere questo tipo di situazione è utilizzare gli output di business logic e i report in formato libero su tali dati. Tuttavia, si perdono la caratteristica funzionale drill-down del report sui dati e anche la possibilità di utilizzare la procedura guidata di creazione report semplice. Il vantaggio dell'utilizzo degli output di business logic è, dall'altro lato, è il risparmio dell'energia del motore con un numero minore di metriche.
Per ulteriori informazioni su questo metodo, consultare il case study Output - Tabelle utente.
Nel caso in cui viene definita una destinazione per una metrica, ci sono due modi possibili di specificare la destinazione. Può essere specificata come destinazione statica o dinamica. Una destinazione statica è lo scenario più frequente, in cui la destinazione può essere un valore valido concordato per la durata del contratto.
Ad esempio:
La disponibilità della rete non deve essere inferiore al 98% ogni mese.
La destinazione in questo caso è 98%.
In alternativa, la destinazione può dipendere dalle prestazioni dei mesi precedenti, oppure cambiare solo il valore in tutto l'anno. Esistono molte altre situazioni che possono essere rilevate, ma in generale vengono tutte implementate mediante una formula. CA Business Service Insight supporta questa funzionalità richiamando una funzione aggiuntiva dal modello di business logic standard. La funzione di destinazione può accedere ad altri parametri dal contesto della business logic e può supportare qualsiasi possibile scenario richiesto.
Ad esempio, il tempo di risoluzione dei ticket nell'assistenza tecnica che dipende dal carico dell'assistenza tecnica: il tempo medio di risoluzione per i ticket di priorità alta è 1 giorno se non sono presenti più di 1000 ticket durante lo stesso mese. Se sono presenti più di 1000 ticket inviati all'assistenza tecnica in un mese, il tempo medio di risoluzione per i ticket di priorità alta è 2 giorni.
In questo caso, la metrica viene definita con una destinazione dinamica che viene valutata all'interno dello script di business logic in base al numero di ticket emessi in tale mese.
Nota: per informazioni sul metodo di implementazione della destinazione dinamica, consultare il case study Implementazione di destinazioni dinamiche.
Un parametro della metrica è un valore che può essere trattato dalla business logic della metrica e un valore che può essere facilmente modificato dalla definizione di metrica senza dover modificare il codice effettivo. Viene utilizzato al posto del valore hardcoded e può essere facilmente modificato.
È importante identificare i parametri della metrica per individuare facilmente i moduli di business logic e creare contenuti riutilizzabili. Inoltre, i parametri della metrica sono accessibili tramite la Procedura guidata contratto che consente a un utente finale di eseguire modifiche facilmente.
Ad esempio:
Nel precedente obbligo, la destinazione è un tasso di risoluzione di 24 ore e il livello di gravità (Severity1) può essere definito come un parametro.
Nell'obbligo precedente, il tempo che viene considerato come tempo di inattività può essere definito come un parametro.
Un parametro contrattuale è un valore che può essere trattato da tutte le metriche all'interno di un contratto. Un parametro contrattuale può essere utilizzato all'interno della metrica utilizzando lo stesso metodo del parametro della metrica, ma definito invece come parametro dinamico.
È consigliabile utilizzare un parametro contrattuale quando è necessario l'utilizzo dello stesso valore per più di una metrica. Un altro vantaggio importante per utilizzare un parametro contrattuale è la semplificazione della manutenzione dei contratti. Poiché i parametri tendono a modificarsi spesso e richiedere l'aggiornamento nel sistema, è più facile accedere a una singola posizione nel contratto e modificare i valori dei parametri simultaneamente invece che accedere a ciascuna metrica nel contratto e modificare i valori dei parametri a livello di metrica.
Di conseguenza, la modellazione più consigliata è definire i parametri a livello di contratto come parametri contrattuali e accedere ai relativi valori tramite parametri dinamici a livello di metrica.
Ad esempio, consultare il case study Prestazioni dell'assistenza tecnica.
|
Copyright © 2013 CA.
Tutti i diritti riservati.
|
|