Uma avaliação simplória de métricas e descontextualizada traz prejuízos ao centro de suporte
A origem do artigo não é minha. Captei do Bob Lewis em seu post The four fallacies of IT metrics do Infoworld, que agora não me recordo, em algum ponto foi traduzido pelo CIO nacional.
Num papo “bem reto”, como diria o baiano do filme Tropa de Elite, o Bob pega um centro de suporte aonde tudo corria bem e mostra que, na tentativa de aperfeiçoar os números, a coisa ficou complicada para o gestor.
Recomendo a leitura do artigo ou a busca do seu homônimo nacional (estou com preguiça de localizar e lembro que não havia sido traduzido na sua integralidade) para um maior aprofundamento.
Sei também que uma quantidade reduzida de centros de suporte no Brasil adotam métricas que justificam algum processo de melhoria contínua, sendo mais um jogo de “olha-como-trabalho-muito” do que propriamente uma ferramenta para incremento gradual de desempenho do setor.
Mas é falando sobre nossos problemas que os vamos resolvendo, por que se deixarmos eles escondidinhos, um dia a casa explode. Por isso vamos lá.
Métrica que produziu problemas
Vamos acompanhar a métrica de incidentes resolvidos por semana como um indicador de nossa competência.
Essa foi a métrica sobre a qual o CIO decidiu que poderia apurar o desempenho do centro de suporte.
Em uma das três unidades da empresa (a chamaremos de “unidade C”) o time local de tecnologia se esforçou para que os usuários se virassem sozinhos. Realizaram workshops, ensinaram a usar a tecnologia adequadamente, mostraram como acessar a base de conhecimento online para obterem suas respostas, promoveram EAD (minha pimenta na história), etc.
O que aconteceu? Menos incidentes por semana chegando, menos incidentes resolvidos.
Conclusão óbvia? Time incompetente em relação às duas outras unidades que resolveram mais incidentes no mesmo período, hahaha.
Ser competente – na análise fria da métrica – resultou em um indicador de desempenho inferior!
A analogia que o autor faz é: policiais rodoviários deveriam ficar escondidos para ter alta quantidade aplicada de multas (o que parece confirmar que estariam trabalhando de montão) ou deixarem seus veículos policiais bem à vista de modo a reduzir a velocidade excessiva nas estradas, mas com isso reduzir o número de multas?
Das quatro falácias
1. Medir as coisas CERTAS de forma RUIM
Computar a quantidade de incidentes resolvidos sem classificá-los por tempo consumido, por urgência, por departamento ou qualquer outra maneira, coloca “todos os gatos dentro de um mesmo saco” como se fossem iguais. É como uma loja computar a quantidade de artigos vendidos no mês, independente de qual dá mais lucro, menos lucro. Ou seja, uma caneta BIC (barata) tem o mesmo peso que um smartphone Galaxy (beeem mais caro).
A questão é:
Para que medir quantos incidentes resolvidos na semana? Qual o objetivo de estipular tal métrica e no que agrega valor ao negócio?
2. Medir as coisas ERRADAS
No exemplo, não importava muito o tempo que o usuário conseguia trabalhar numa boa, livre das nhacas, dúvidas, interrupções e falhas por causa da tecnologia, mas sim quantos incidentes eram resolvidos.
Ora, o centro de suporte existe para manter o funcionário trabalhando o máximo possível!
3. Negligenciar a medição do que realmente importa
O que realmente importa é a frase final do item anterior: manter o funcionário trabalhando.
Epa, se vamos medir a quantidade de incidentes resolvidos por semana e nós estamos sendo prejudicados por que ensinamos o usuário a trabalhar melhor, cancela tudo!
Que se dane nosso processo educacional de workshops e iniciativas similares. Queremos mais usuários incompetentes e gerando muitos incidentes para ficarmos novamente bem na foto.
Boa essa, não?
Um gerente de informática (CIO) que define essa como métrica absolutamente imprescindível e vai cuidar de seus outros afazeres, ao final da semana ficará fulo da vida ao ver o resultado da unidade C. Mal imagina ele que visualizando aquele pequeno dashboard em seu vídeo está escondido um baita esforço do time C que será menosprezado pelo gestor caso não dedique um momento de reflexão.
4. Avaliar individualmente o desempenho de cada técnico
Rá!
Se eu sou um técnico esperto e preocupado com a métrica, vou até o usuário e não ensino nada para ele! Por que sou medido pela métrica de solução de incidentes semanais. E se ganho recompensas por um alto índice, meu irmão, quero mais é que mais e mais incidentes surjam (vale até reincidência se bobear!).
Gerência de Problemas
Você poderia afirmar que a Gerência de Problemas colaboraria nesse processo, resolvendo de uma vez as causas que produzem tantos incidentes.
Bom, em muitos centros de suporte, nem existe tal figura da Gestão de Problemas. E noutros, a gestão é um tanto estanque, aguardando cair no seu colo os problemas para resolvê-los, sem tomar medidas proativas para AUMENTAR O TEMPO TRABALHADO DOS USUÁRIOS SEM PROBLEMAS CAUSADOS POR TECNOLOGIA.
Yah, eu grifei com maiúsculas e sei que já tem gente vindo com o caderninho do ITIL falando sobre disponibilidade, etc., etc., etc. A realidade é que ela – a realidade – consome nosso tempo, as demandas súbitas desorganizam nossa vida profissional e quando vemos, a única coisa que realmente sobra é a “métrica de incidentes resolvidos por semana”.
Agora vamos complicar: imaginem que o centro de suporte técnico de uma software-house se esforce ao máximo para que os usuários possam resolver seus problemas de uso do aplicativo sozinhos. O que acontecerá numa renovação de contrato? O cliente vai dizer que não precisa, pois tudo funciona direitinho, hahaha.
Conclusão esplêndida do Bob (o outro, não eu)
Métricas importam.
Sem alguma forma estruturada de saber se a organização está alcançando seus objetivos mais importantes, os gestores estarão voando sem instrumentos.
O desafio é fazer as coisas certas, pois existe algo pior que voar sem instrumentos: é voar com instrumentos que oferecem medidas falsas.
Abraços,
EL Cohen
PS: A turma do curso de Gestão de Serviços para Help Desk e Service Desk no final do mês em São Paulo está com as vagas esgotadas, mas… A de Minas Gerais tem vagas ainda. E abri nova turma para setembro em Sampa. Veja mais em www.4hd.com.br/calendario
Cohen, sou supervisor de Field Supportt e atuo com diversas equipes espalhadas pelo Brasil, tenho feito um estudo para avaliar possÃveis pontos de melhorias o que inclui a redução do número de incidentes através de uma análise de causa raiz por exemplo. Hoje quais são as principais métricas de mercado praticado no Field Support, você possui algum material sobre este tema? Quero conhecer o que se pratica no mercado e assim desenvolver um estudo de benchmarking.
Kendson,
1. Estou concluindo um livro sobre métricas. Espero que ele vá pro mercado esse ano.
2. Antes de pensar nas principais métricas de mercado, pense em qual seu objetivo primordial na gestão dessa turma. Ao definir isso, poderá estabelecer objetivos e as correspondentes métricas.
3. Benchmarking você faz visitando as outras empresas aà no EspÃrito Santo. Eu conheço uma grandona que provavelmente lhe receberia bem para conversarem sobre as operações, até por que não são concorrentes (mas seria bom ir com um kit de perguntas para fazer ou debater).
Abração,
Cohen