Da série: mastigando métricas e KPI's – art. 1 – 4HD Blog
Da série: mastigando métricas e…
"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 🙂 🙂
Category: processosBy Roberto Cohen 14 - março - 2008 2 Comments
PreviousPrevious post:Gauchadas em Saint PaulNextNext post:Conferência de métricas em abril
7 - outubro - 2015 at 10:33 am
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.
14 - outubro - 2015 at 3:53 pm
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".