Da série: mastigando métricas e KPI’s – art. 1

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

2 comentários em “Da série: mastigando métricas e KPI’s – art. 1”

  1. 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!

  2. 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

Deixe um comentário

O seu endereço de e-mail não será publicado.