Guida all'implementazione › Esempi di case study › Esempi di modellazione dei dati › Case study 8: prestazioni dell'assistenza tecnica

Case study 8: prestazioni dell'assistenza tecnica

Si tratta di un tipico case study relativo alle prestazioni dell'assistenza tecnica.

In base all'origine dati illustrata di seguito:

L'origine dati illustrata in precedenza elenca le informazioni per i ticket di assistenza tecnica gestiti per ciascun cliente nelle diverse ubicazioni dei servizi cliente. Una singola ubicazione potrebbe anche essere condivisa tra i clienti.

I tre requisiti seguenti sono obbligatori per la creazione di report utilizzando questa origine dati:

• % di ticket con priorità 1 risolti in quattro ore per il cliente CM3.
• % di ticket con priorità 1 risolti in quattro ore per il cliente CM3 in ciascuna ubicazione.
• % di ticket con priorità 1 chiusi in un giorno per il cliente CM3 in ciascuna ubicazione.

Tali requisiti indicano che è necessario filtrare gli eventi per:

• Priorità
• Cliente
• Ubicazione

È necessario specificare quali di questi criteri di filtro vengono convertiti in Tipo evento e quali sono la risorsa pertinente.

Come è possibile selezionare un tipo di evento?

Dei tre criteri di filtro richiesti, la priorità del ticket è quello più appropriato per la conversione in Tipo di evento per i seguenti motivi:

• Descrive il tipo di evento da gestire (ticket con priorità 1).
• Il numero di priorità diverse esistente è alquanto ridotto (priorità 1, 2, 3).
• Il tipo di evento stesso è relativamente costante (solo raramente l'assistenza tecnica modifica le priorità con cui vengono gestiti i ticket).

Come viene selezionata una risorsa?

Gli altri due criteri di filtro richiesti sono il cliente e l'ubicazione e sono le entità più piccole che necessitano della creazione di report. Pertanto, la combinazione di cliente e ubicazione costituisce la risorsa.

Il cliente e l'ubicazione sono entità alquanto fisse con un ciclo di vita definito, in base al quale è possibile aggiungere nuovi clienti o nuovi siti. Inoltre, la relazione tra un sito e un cliente può variare.

Ai fini delle conversioni, è possibile utilizzare più campi dall'origine dati. Se nel precedente case study il campo del server è stato convertito in una risorsa CA Business Service Insight, in questo caso la risorsa viene creata utilizzando la combinazione dei due campi. Ogni permutazione pertanto genera una nuova risorsa.

L'elenco di risorse è indicato di seguito:

La risorsa di output è la combinazione dei campi cliente e sito utilizzando il simbolo + per combinarli. È importante conoscere il nome della risorsa in quanto viene estratta dall'origine dati e viene visualizzata successivamente nei report. È necessario che le funzionalità dei report soddisfano le aspettative.

Nota: uno degli errori più comuni durante la modellazione dell'assistenza tecnica o di un ticket o di un sistema di incidenti consiste nella definizione di un solo incidente come risorsa.

I seguenti presupposti errati spesso sono causa di errori:

1. L'unico incidente è quello che viene segnalato nel report. Non impostare di segnalare l'entità come l'entità per la quale vengono generati i calcoli in modo che il singolo incidente non sia la base dei calcoli per il sito del cliente. In generale, lo SLA si basa sulle prestazioni complessive, non sulle prestazioni di gestione di un singolo ticket.
2. La garanzia è per livello di ticket. Si tratta di un errore perché le garanzie sono periodiche, l'oggetto dei calcoli è un'aggregazione nel corso del tempo.

Impostazione delle allocazioni di risorse

Per il primo requisito di calcolo:

1. % di ticket con priorità 1 risolti in quattro ore per il cliente CM3.
   • È necessario ricevere eventi di ticket attribuibili a uno specifico cliente. Il cliente è parte della risorsa, che inoltre indica il sito del cliente. Pertanto, per acquisire tutti gli eventi relativi alle risorse e attribuibili a tale cliente, sono disponibili due opzioni:
   • Nei casi in cui il cliente nell'origine dati rappresenta un contraente, è possibile associare le risorse al contraente pertinente. Si consente così la registrazione per contraente. Laddove possibile, questa opzione è sempre preferibile.
   • Creare un gruppo di risorse per ciascun cliente nell'origine dati e raggruppare tutte le risorse pertinenti all'interno di esso. Con questo metodo, la registrazione avviene per gruppo di risorse.

   Per i due requisiti di calcolo successivi:

2. % di ticket con priorità 1 risolti in quattro ore per il cliente CM3 in ciascuna ubicazione.
3. % di ticket con priorità 1 chiusi in un giorno per il cliente CM3 in ciascuna ubicazione.

Per questi requisiti, raccogliere le risorse in gruppi di risorse in quanto è necessario che le metriche siano di gruppo, dato che il calcolo è richiesto per ogni sito singolarmente.

Nota: anche se le allocazioni di risorse per il modello corrente e i requisiti non sono necessarie, è importante crearle tenendo conto dei futuri requisiti. In tal modo si impedisce il sovraccarico nello sviluppo del sistema futuro.

Selezione del campo Data/ora

Come indicato in precedenza, il campo Data/ora è molto importante per la modalità di gestione degli eventi da parte del motore di correlazione. Le metriche calcolano sempre il livello di servizio per il periodo di tempo e gli eventi elaborati entro questo periodo sono quelli i cui valori Data/ora rientrano in tale periodo.

Nel primo case study, l'origine dati dispone di un solo campo ora. Tuttavia, in questo caso, sono presenti tre campi che è possibile impostare come data/ora. In base all'esame dei primi due record:

Per calcolare i tempi di risoluzione, sono obbligatorie sia l'ora di emissione del ticket, sia l'ora di risoluzione. Ai fini dell'evento, è possibile associarvi solo un valore Data/ora. Quindi, è possibile utilizzare gli altri come un valore all'interno dei campi valore.

Se il valore Raised at (Data/ora emissione) è utilizzato come Data/ora, il ticket viene incluso nei risultati di dicembre. Se il valore Resolved at (Data/ora risoluzione) è utilizzato come Data/ora, il ticket viene incluso nei risultati di gennaio. Entrambe le opzioni sono utilizzabili. È necessario che la selezione soddisfi le aspettative quando i ticket devono essere visualizzati nei report.

È un aspetto molto importante da considerare durante l'implementazione, in quanto determina quando gli eventi vengono utilizzati per i calcoli. Ad esempio, se un ticket viene emesso a novembre, ma non chiuso fino a dicembre, quando contribuisce rispetto al risultato dello SLA? Rientra nei dati di novembre o in quelli di dicembre?

In tal caso, poiché il ticket viene segnalato all'origine dati solo una volta chiuso, è possibile acquisire i dati solo dopo la chiusura del ticket. In genere, la data di chiusura è successiva alle date di emissione e risoluzione. Nel caso in cui la data di emissione è stata selezionata come Data/ora, è necessario quindi elaborarla come parte dei risultati di dicembre. La data di chiusura è stata a gennaio, il che significa che dicembre è già passato quando il ticket è stato segnalato. Pertanto, i risultati per dicembre sono stati già pubblicati. Il motore di correlazione quindi notifica che l'evento è nel passato, in quanto il valore Data/ora appartiene a dicembre, e attiva il ricalcolo. Di conseguenza, i risultati di dicembre vengono modificati in modo retroattivo.

È necessario comprendere a fondo tali conseguenze in modo da poter definire quale campo ora sia necessario selezionare come Data/ora. In genere, viene selezionata la data di chiusura in modo che non sia necessario modificare i report finali in modo retroattivo.

D'altra parte, l'utilizzo della data di chiusura come valore Data/ora ritarda l'immissione dei calcoli da parte dei ticket. Un ticket risolto potrebbe essere chiuso solo a una determinata ora successivamente.

Tuttavia, tenere presente che l'utilizzo della data di chiusura potrebbe inoltre attivare un processo nell'organizzazione in grado di accelerare i tempi di chiusura dei ticket.

Il suggerimento finale è quindi: