Stephen Mann, da Forrester, dá a dica para evitar métricas “nada a ver”
OK, boys and girls. Essa é a segunda parte do artigo que se iniciou aqui:
13 tópicos para evitar métricas furadas
Indiquei o link acima para não recapitular tudo de novo. Então, continuarei enumerando os problemas, recordando que o autor chama de I&O o time de Infraestrutura & Operações.
Adiante, os problemas na definição de métricas:
- Não existe estrutura ou contexto entre as métricas. Elas podem se tornar silos, independente uma das outras. Por isso devem ser analisadas em conjunto. Um exemplo é o time ficar animado por que o “custo por incidente” baixou. Porém, se aconteceu um crescimento exagerado no número de incidentes recentes, se perceberá que não houve melhorias (a métrica indicada calcula a quantidade de incidentes dividida pelo custo do centro de suporte técnico).
- Adotar uma visão unidimensional das métricas. Se os departamentos de I&O examinam seu desempenho em meses estanques, sem analisar o que acontece mês a mês, semana a semana ou trimestre a trimestre, até podem atingir seus objetivos, mas não perceber – a tempo – tendências importantes.
- A hierarquia das métricas não fica clara. Nem todas as métricas são iguais – existem diferenças entre métricas, indicadores-chaves de performance, fatores críticos de sucesso e objetivos estratégicos. Diferentes pessoas terão usos diferentes para diferentes métricas, por isso um determinado relatório provavelmente não atenderá a todo mundo.
- Colocar muita importância nos benchmarks de I&O. Comparar-se com outras organizações pode mostrar quão fantástica sua organização está indo ou ajudar a justificar gastos em melhorias. Contudo, os dados de benchmarks podem ser confusos, tal como comparar laranjas com maçãs. Dois grandes exemplos são “o custo por incidente” e “incidentes tratados pelos agentes de service desk por hora“. Em “custo por incidente“, como você sabe quais custos foram incluídos pelos outros e quais não? Aliás, o volume, tipos e características dos incidentes também afetam as estatísticas. O tipo de incidente também afeta a quantidade de incidentes que os técnicos conseguem lidar durante uma hora.
- Relatório de métricas é pobremente projetado e entregue. í€s vezes, é provável gastar mais tempo coletando os dados do que entendendo a melhor maneira de entregá-los – é como num processo de comunicação, onde não se garante que a mensagem entregue seja compreendida pelo receptor.
- Desprezo pelo aspecto comportamental das métricas. Em nível de time ou individualmente, as métricas podem conduzir a comportamentos indesejados, fazendo com que algumas pessoas batalhem mais pelo sucesso individual do que da corporação. Elas também podem colocar a equipe de I&O em conflito e fazendo o staff ir a direções diferentes. Um bom exemplo é a tensão originada entre “tempo médio de atendimento” e “solução no primeiro contato“. Atingindo altos números em uma métrica afeta contrariamente a outra (se eu consigo reduzir o tempo médio de atendimento, talvez não consiga resolver tudo no primeiro contato como poderia se dispensasse mais tempo no atendimento). Por isso, se o departamento de I&O usa uma delas para o time e outra para medição individual será potencialmente perigoso para as operações e entrega de serviços.
- A equipe de I&O pode ficar cega pelas métricas existentes. Quando a organização atinge consistentemente seus objetivos, a consequência padrão é incrementar o número ou escopo desses objetivos. Mas isso não é necessariamente a abordagem mais correta. Em vez disso, é importante considerar se as métricas ainda valem – se ainda adicionam valor. Algumas vezes, o melhor é abolir uma determinada métrica e substituí-la por outra que seja mais adequada para as necessidades do negócio.
- Métricas e desempenho podem ser facilmente confundidos. Um bom exemplo é o “volume de incidentes” – uma redução nele pode ser uma boa coisa, certo? Não necessariamente. Considere isso: um Service Desk oferecendo um serviço de baixa qualidade pode ter uma redução nos incidentes quando os usuários decidem que acessar ou enviar emails é inútil e começam a procurar ajuda noutros lugares ou adotar suas soluções próprias de contorno. Por outro lado, um Service Desk realizando um serviço excelente pode ser a quantidade de incidentes crescer na medida em que mais usuários decidem prestigiá-lo.
Finalmente, nas palavras sábias de Ivor McFarlane da IBM:
“Se nós usamos as métricas erradas, será que não fazemos melhor ainda as coisas erradas?”
Brothers and sisters, os dois últimos cursos de gestão de 2012: 27-28-29 de setembro em Caxias do Sul/RS e 03-04-05 de outubro em São Paulo.
See you.
EL Cohen