Guia de Implementação › Exemplos de estudo de caso › Exemplos de modelagem de dados › Estudo de caso 8: Desempenho da Central de atendimento

Estudo de caso 8: Desempenho da Central de atendimento

Este é um caso de estudo típico sobre o desempenho da Central de atendimento.

Dada a origem de dados mostrada a seguir:

A origem de dados exibida acima lista os detalhes dos tickets da central de atendimento que são gerenciados para cada cliente em vários locais que o cliente presta serviço. Um único local também pode ser compartilhado entre os clientes.

Os três requisitos a seguir são necessárias para a geração de relatórios ao usar essa fonte de dados:

• Percentual de tickets com prioridade 1 resolvidos em até quatro horas para o cliente CM3.
• Percentual de tickets com prioridade 1 resolvidos em até quatro horas para o cliente CM3 em cada local.
• Percentual de tickets com prioridade 1 fechados em até um dia para o cliente CM3 em cada local.

Os requisitos acima indicam que os eventos devem ser filtrados por:

• prioridade
• cliente
• local

É necessário especificar quais desses critérios de filtragem serão convertidos como um evento e qual será o recurso relevante.

Como selecionar um evento?

Dentre os três critérios de filtragem necessários, a prioridade de ticket é o mais adequado para ser convertido em evento por uma das seguintes razões:

• Ele descreve o tipo de evento que está sendo manipulado (os tickets com prioridade 1).
• O intervalo de prioridades diferentes que existe é relativamente pequeno (prioridade 1,2,3).
• O tipo de evento é relativamente constante (a central de atendimento raramente altera as prioridades dos tickets que ela manipula).

Como um recurso é selecionado?

Os dois outros critérios de filtragem necessários são o cliente e o local, e eles são as menores entidades que exigem a geração de relatórios. Portanto, o recurso consiste na combinação de cliente e a local.

O cliente e o local são entidades relativamente fixas e precisam ter um ciclo de vida definido no qual novos clientes ou novos sites podem ser adicionados. Além disso, o relacionamento entre um site e um cliente pode alterar.

É possível usar mais de um campo na fonte de dados para fins de conversão. Enquanto que no estudo de caso anterior o campo do servidor foi convertido em um recurso do CA Business Service Insight, neste caso o recurso foi criado usando a combinação dos dois campos. Cada permutação gera um novo recurso.

A lista de recursos é mostrada a seguir:

O recurso de saída é uma combinação de campos do cliente e do site usando o símbolo '+' para combiná-los. É importante estar ciente do nome do recurso, pois é extraído da origem de dados e ele aparece posteriormente nos relatórios. A capacidade de geração de relatórios necessária para atender às expectativas.

Observação: um dos erros mais comuns ao modelar uma central de atendimento ou qualquer sistema de ticket ou incidente é definir um único incidente como um recurso.

As suposições a seguir frequentemente levam a erros:

1. O único incidente é o que foi relatado. Não defina a entidade a ser relatada como a entidade para a qual os cálculos são gerados, de modo que um único incidente não seja a base de cálculos para o site do cliente. Em geral, o SLA tem como base o desempenho geral, não o desempenho individual do ticket manipulado.
2. A garantia é por nível de ticket. Isto é um erro, pois as garantias são periódicas, e o que é calculado é a agregação no decorrer do tempo.

Definindo alocações para os recursos

Para o primeiro requisito de cálculo:

1. Percentual de tickets com prioridade 1 resolvidos em até quatro horas para o cliente CM3.
   • Os eventos de tickets atribuíveis a um cliente específico precisam ser recebidos. O cliente é parte desse recurso que também indica o site do cliente. Portanto, para capturar todos os eventos relacionados a recursos e atribuí-los ao cliente, há duas opções:
   • Nos casos em que o cliente representa uma parte contratual na origem de dados, os recursos podem ser anexados à parte contratual relevante. Isso permite o registro pela parte contratual. Esta é uma ação preferível quando for possível.
   • Criar um grupo de recursos para os clientes na origem de dados e agrupar todos os recursos relevantes. Com esse método, o registro é feito por grupo de recursos.

   Para os próximos dois requisitos de cálculo:

2. Percentual de tickets com prioridade 1 resolvidos em até quatro horas para o cliente CM3 em cada local.
3. Percentual de tickets com prioridade 1 fechados em até um dia para o cliente CM3 em cada local.

Para esses requisitos, colete os recursos nos grupos de recursos, pois as métricas precisam ser agrupadas, uma vez que o cálculo é necessário para cada site individualmente.

Observação: mesmo que as alocações de recursos atuais para o modelo e os requisitos não sejam necessários, é importante criá-los para requisitos futuros. Isso evita a sobrecarga no desenvolvimento futuro do sistema.

Selecionando o campo Data/hora

Conforme mencionado anteriormente, a data/hora é muito importante para o modo como o mecanismo de correlação manipula os eventos. As métricas sempre calculam o nível de serviço por período de tempo, e os eventos que são processados nesse período são aqueles em que a data/hora está dentro do período.

No primeiro estudo de caso, a origem de dados tem somente um campo de horas. No entanto, neste caso, há três campos possíveis que podem ser definidos como data/hora. Analisando os dois primeiros registros:

Para calcular o tempo de resolução é necessário a hora de geração e de resolução. Para os fins do evento, é possível anexar somente um carimbo de data e hora a ele. O outro pode ser usado como um valor nos campos de valor.

Se o valor Criado em for usado como o carimbo de data e hora, o ticket será incluído nos resultados de dezembro. Se o valor Resolvido em for usado como o carimbo de data e hora, o ticket será incluído nos resultados de janeiro. As duas opções são viáveis. A seleção precisa apenas atender às expectativas com relação ao local em que os tickets devem ser exibidos nos relatórios.

É um ponto muito importante a ser considerado durante a implementação, pois ele determina quando os eventos serão usados nos cálculos. Por exemplo, se um ticket foi gerado em novembro, mas não foi fechado até dezembro, quando ele deverá contribuir para o resultado de SLA? Ele será contabilizado nos dados de novembro ou dezembro?

Nesse caso, uma vez que o ticket é relatado à origem de dados somente depois de seu fechamento, os dados poderão ser capturados somente após o fechamento do ticket. Em geral, a data de fechamento é posterior às datas de geração e resolução do ticket. No caso em que a data de geração do ticket foi escolhida para ser a data e hora, ela deve ser processada como parte dos resultados de dezembro. A data de fechamento foi em janeiro, o que significa que dezembro já tinha passado quando este ticket foi relatado. Assim, os resultados de dezembro já foram publicados. O mecanismo de correlação avisa que o evento estava no passado, pois o carimbo de data e hora pertence a dezembro e aciona o recálculo. Portanto, os resultados de dezembro se alteram de forma retroativa.

Essas consequências precisam ser entendidas completamente para que seja possível definir qual campo deve ser escolhido como data/hora. Em geral, a data de fechamento é selecionada para obter relatórios finais que não se alteram de forma retroativa.

Por outro lado, usar a data de fechamento como data/hora atrasa a inserção dos tickets nos cálculos. Um ticket que foi resolvido só pode ser fechado algum tempo mais tarde.

Lembre-se, no entanto, de que o uso de data de fechamento também pode disparar um processo na organização que acelera a hora de fechamento do ticket.

A última sugestão é: