Como vem pela frente uma conferência sobre Métricas e KPI’s, achei interessante registrar aqui no blog algum conteúdo didático sobre o assunto. Os mais experientes ficarão enfarados com os primeiros artigos, mas os “finalmente” trarão conteúdos mais densos sobre o tema.
OK, vamos lá.
A primeira pergunta é: PRA QUÊ?
Olhando com a visão de gerentes de T.I. a resposta seria:
“Para permitir que as pessoas envolvidas no gerenciamento de serviços de T.I. possam tomar decisões racionais e bem-informadas sobre os serviços e a infra-estrutura oferecida aos usuários“.
Ou seja: se precisa comprar mais storage, quanto? E de onde vem essa idéia? São precisos mais técnicos no primeiro nível? Porquê? O volume de incidentes vem aumentando? O negócio está operando 24 horas por dia e existem muitos incidentes noturnos? Vamos mudar o mecanismo de reinicialização de senhas para algo mais automatizado via URA porquê, com a aquisição da nova empresa, incrementou demais esse tipo de serviço? As prefeituras, nossas clientes, mudaram de partido e agora ninguém sabe operar os sistemas que oferecemos?
Bom, tenho certeza que você consegue colocar uma lista enorme adicional de motivos nesse parágrafo acima.
E sob a ótica de relatórios oferecidos aos clientes?
“Para mostrar ao negócio que paga pelos serviços de T.I. (ou outros grupos interessados) o nível de serviço oferecido e sua performance. E permitir examinar se este nível de performance está adequado e dentro dos padrões necessários do próprio negócio.”
Você encontra tais definições (de métricas e KPI’s) em vários lugares. Inclusive em livros-texto, material de ITIL, COBIT, ISO, etc. Por isso, minha idéia não é que você copie-e-cole tais comentários do tio aqui, mas compreenda os objetivos, quando então passaremos aos próximos tópicos.
Compreenda que mostrar sua performance caso ela esteja ruim não é motivo de vergonha. Talvez seja uma oportunidade de melhorar. Pode ser motivada por falta de recursos, organização, infra-estrutura e uma série de fatores que, apresentados a quem paga pelos serviços, pode ser providenciada uma melhoria. Ou não. Ou até uma terceirização, hehe.
Mas se o cliente toma consciência que o tempo de resposta está em cinco segundos e o serviço em questão é crítico, talvez aceite pagar (ou investir, que é uma expressão mais chique) por mais banda de internet, ou cabeamento mais rápido da rede, etc para que a performance melhore.
Ou treinamento para seus técnicos de primeiro nível, com o objetivo deles resolverem mais rápido os incidentes que chegam (que claro, será contratado junto ao 4HD).
Ou um novo software de gerenciamento de incidentes (que claro, você vai escolher o Fireman).
Hehehe, perdão, mas como meu peixe é bom, fica difícil deixar de vendê-lo!
Well, isso é uma primeira abordagem ao tema.
É claro, nada substitui sua presença na conferência. Até estou colocando esse tópico aqui também para sensibilizá-lo que CONVERSAR E DEBATER COM OUTROS SUPERVISORES é ainda muito melhor do que ler um texto num blog (ainda que de um sujeito super-famoso 🙂 🙂
Abrazon
El Cohen
Bom dia, estou em busca de uma informação um tanto complicada de se encontrar. Preciso analisar se existe uma métrica utilizada que mensure a quantidade de incidentes ou horas de incidentes que um novo sistema/software pode gerar.
Obrigado e um forte abraço!
Luis,
Não entendi muito bem sua necessidade.
Qual o objetivo de medir a quantidade de incidentes que um sistema pode gerar? É que não estou no seu ambiente, então preciso de uma contextualização maior. É algo relacionado a um NOC? O que está meio esquisito para mim é o “PODE GERAR”.
Abs
EL CO