|
|
|
A seguir, estão vários exemplos de casos, alguns mais comuns e outros mais exclusivos, que descrevem conceitos que devem ser considerados no processo de modelagem. Esses conceitos podem resultar em uma definição mais precisa das métricas e em uma estrutura estável.
Como o campo de destino na definição da métrica não é obrigatório, em casos em que não estiver definido, os relatórios de nível de serviço ficarão disponíveis para a métrica. No entanto, nenhum relatório de Nível de serviço versus objetivo e Desvio é possível (porque não há nenhum destino com o qual comparar o resultado calculado real de nível de serviço). Esses tipos de métrica são definidos em casos onde os relatórios são necessários para as informações que não fazem parte das obrigações contratuais reais.
Definir esse tipo de métrica fornece ao usuário todos os possíveis recursos de detalhamento de geração de relatórios, além de fornecer ao Gerenciador de nível de serviço a opção de aplicar as medições em um destino em qualquer etapa no futuro.
Por exemplo:
A garantia contratual é fornecer 99% da disponibilidade de rede e relatar o número de downtime por mês.
Duas métricas são definidas: uma com um destino de 99% para disponibilidade, e outra para contar o número de downtime por mês sem um destino. As duas métricas podem ser relatadas, mas apenas a primeira tem cálculos de desvio devido à obrigação contratual.
Observação: outro método possível para esse tipo de situação é usar saídas de lógica de negócios e geração de relatórios de formato livre desses dados. No entanto, isso faz com que a capacidade de detalhamento do relatório nos dados seja perdida, bem como a opção de usar o assistente de relatório simples. A vantagem de usar saídas de lógica de negócios, por outro lado, é a questão de economia de energia do mecanismo ao ter um número menor de métricas.
Para obter mais informações sobre esse método, consulte o estudo de caso Saídas - Tabelas de usuário.
Nos casos em que houver um destino definido para uma métrica, há duas maneiras possíveis de especificá-lo. Pode ser especificado como um destino estático ou dinâmico. Um destino estático é o tipo mais comum de cenário, em que o destino pode ser um valor acordado válido por toda a duração do contrato.
Por exemplo:
A disponibilidade de rede não deve ficar abaixo de 98% por mês.
O destino, neste caso, é 98%.
Como alternativa, o destino poderá depender do desempenho dos meses anteriores, ou simplesmente alterar seu valor ao longo do ano. Há muitas situações alternativas que podem ser encontradas aqui, mas, em geral, elas são implementadas por meio de uma fórmula. O CA Business Service Insight oferece suporte a esse recurso por uma chamada de função do modelo padrão de lógica de negócios. A função de destino pode acessar outros parâmetros do contexto da lógica de negócios e pode oferecer suporte a qualquer possível cenário que seja necessário.
Por exemplo, o tempo de resolução de tickets na central de ajuda que depende da carga da central de ajuda: o tempo de resolução médio para tickets de alta prioridade é 1 dia, se não houver mais de 1000 tickets durante o mês. Se houver mais de 1000 tickets emitidos na central de ajuda no mês, o tempo de resolução médio para tickets de alta prioridade será de 2 dias.
Nesse caso, a métrica é definida como tendo um destino dinâmico que é avaliado no script da lógica de negócios de acordo com o número de tickets emitidos no mês.
Observação: para obter detalhes sobre o método de implementação do destino dinâmico, consulte o estudo de caso Implementando destinos dinâmicos.
Um Parâmetro da métrica é um valor que pode ser obtido na lógica de negócios da métrica e que pode ser facilmente alterado na definição da métrica sem que seja necessário alterar o código real. É usado no lugar do valor codificado e pode ser facilmente alterado.
É importante identificar os parâmetros de métrica para identificar facilmente os módulos de lógica de negócios e criar um conteúdo reutilizável. Além disso, os parâmetros de métrica são acessíveis por meio do Assistente de contrato, que permite que um usuário final execute as alterações facilmente.
Por exemplo:
Na obrigação acima, o destino é uma taxa de resolução de 24 horas, e o nível de gravidade (Severity1) pode ser definido como um parâmetro.
Na obrigação acima, o tempo que é considerado como downtime pode ser definido como um parâmetro.
Um Parâmetro do contrato é um valor que pode ser obtido por todas as métricas em um contrato. Um Parâmetro do contrato pode ser usado na métrica com o mesmo método de um Parâmetro da métrica, mas, em vez disso, é definido como um parâmetro dinâmico.
É recomendável usar um Parâmetro do contrato quando mais de uma métrica exigir o uso do mesmo valor. Outro incentivo importante para usar um Parâmetro do contrato é para facilitar a manutenção do contrato. Como os parâmetros tendem a mudar com frequência e exigir atualização no sistema, é mais fácil acessar um único local no contrato e alterar todos os valores dos parâmetros ao mesmo tempo do que acessar cada métrica no contrato e alterar os valores dos parâmetros no nível da métrica.
Portanto, a modelagem mais recomendada é definir os parâmetros no nível do contrato como parâmetros do contrato e acessar os valores por meio dos parâmetros dinâmicos no nível da métrica.
Para obter um exemplo, consulte o estudo de caso Desempenho da central de ajuda.
| Copyright © 2012 CA. Todos os direitos reservados. | Enviar email à CA Technologies sobre este tópico |