Criando uma definição de bônus para um I.T. Manager - Alguma idéia? [fechadas]

Question

Não tenho certeza se essa é uma pergunta META ou não, mas ...

Alguém sabe de uma boa maneira de definir uma estrutura de bônus objetiva para um I.T. Gerente? Eu criei os seguintes critérios, mas não tenho certeza de como melhor avaliar as métricas:

• Operacional (tempo de atividade da rede, tempo de atividade do site, etc.)
• Suporte (tempos de resposta do ticket de helpdesk, etc.)
• Projeto (no prazo / orçamento, execução, efetividade de gerenciamento, etc.)

É claro que eles funcionam muito bem na teoria, mas como avaliar essas métricas de maneira objetiva / justa?

Usamos uma empresa de consultoria terceirizada para monitorar nosso tempo de atividade / recursos, o que poderia funcionar para 'Operacional', temos um Suporte Técnico no qual eu poderia executar uma consulta SQL para gerar estatísticas sobre tickets para 'Suporte' e concede que pelo menos metade da avaliação do 'Projeto' terá que ser subjetiva ...

De qualquer forma, pensei em chegar e ver se alguém tentou algo semelhante.

Obrigado ...

    

Answer 1

Honestamente, eu não acho que os gerentes de TI devam receber bônus por tempo de atividade - o tempo de atividade faz parte do nosso trabalho básico, e se não fizermos isso, não deveríamos ter o emprego. Mesmo assim, às vezes, as coisas acontecem fora do nosso controle, mas isso só piora em termos de bônus: somos recompensados ou não por coisas que não podemos controlar.

Sou um pouco mais compreensivo para o suporte, mas o suporte aos usuários é realmente a mesma coisa e é tão fácil de jogar. Um gerente que sabe que é de onde vem o bônus terá a tendência de criar muitos tickets simples para que ele encontre sua métrica.

Realmente, quando você está pensando em bônus, você tem que olhar para os projetos. Essas são as áreas em que um gerente de TI consegue ser criativo e mostrar que ele vale não apenas o que você paga a ele, mas também o bônus.

Para avaliar projetos objetivamente, você precisa analisar os resultados e os planos. Por exemplo, para o próximo ano, você pode planejar um lançamento de thin client em uma área. As metas para este projeto são reduzir o uso de energia e simplificar o gerenciamento desses desktops, com uma economia líquida de $ X por ano e custo inicial de $ Y.

Para determinar o nível de bônus, você pode usar uma fórmula como X * 5 - Y como economia total ao longo de cinco anos de vida da instalação e colocar até 1/3 desse valor na tabela como parte do bônus daquele gerente para o ano. Outros projetos contribuiriam com outras partes, e você está percebendo a economia potencial desse projeto que durará mais do que apenas a vida útil de cinco anos da instalação inicial, pois esse nível de serviço também é a nova linha de base dessa área para a próxima implantação.

Você então mede os custos reais da implementação, os custos reais de gerenciamento após a conclusão e o uso real de energia antes e depois para ver como o gerente fez em relação às expectativas do projeto.

Por outro lado, um projeto similar em outra área que acabou de atualizar os PCs com este modelo equivalente no ciclo de substituição normal não teria nenhum impacto de bônus, porque isso é apenas parte da função normal para essa posição. Você quer usar o dinheiro do bônus para recompensar o trabalho criativo que ajuda na lucratividade dos negócios.

    

Answer 2

Há um grande número de estudos que parecem sugerir que tentar construir um bônus apenas por critérios objetivos fará com que as pessoas descubram como "jogo o sistema" de maneira a atingir o objetivo.

Por exemplo, quando as pessoas medem por bilhete, giram em torno do tempo, as pessoas uma tecnologia só vai fechar o bilhete o mais rápido possível, mesmo se o problema não for resolvido.

Tentar medir o uptime puro pode incentivar as pessoas a não aplicar patches de segurança ou evitar a manutenção necessária.

Você pode querer ler "O lado positivo da irracionalidade" e "Previsivelmente irracional" para mais exemplos e discussões de estudos que sugiram que os bônus não são tão eficazes quanto a gerência gosta de acreditar.

Se você precisar fazer isso, não estou dizendo que critérios objetivos não devam ser considerados. Mas critérios subjetivos também serão necessários. Talvez meça a satisfação com a resolução de tickets.

    

Answer 3

Na minha última empresa, pediram-me para ajudar a determinar essas métricas e isso é o que decidimos. Infelizmente, muito disso será subjetivo. O problema também é que, quando as coisas estão funcionando bem, ninguém percebe a TI. Outros fatores que nós trabalhamos na estrutura de bônus foi a revisão por outros chefes de departamento (que eu não tenho 100% de certeza sobre como eu me sinto, pode ir de qualquer forma se você não tiver bons chefes de departamento que não entendem o que você fazer) e o desempenho geral de lucro da empresa, uma vez que a TI realmente facilita a todos os outros departamentos a capacidade de cumprir seus objetivos.

    

Answer 4

Você pode dividir o pagamento de bônus com base em seus vários critérios:

33% de bônus se as metas operacionais forem cumpridas 33% de bônus se as metas de suporte forem cumpridas 20% de bônus se as metas do Projeto Objetivo forem cumpridas 13% de bônus se as metas do Projeto Subjetivo forem atendidas

Você poderia dividi-los ainda mais se quisesse. Isso permitiria minimizar as partes subjetivas. Idealmente, o (s) gerente (s) deve (m) prever com bastante precisão qual será o seu bônus, com base em medidas objetivas. Na realidade, o material subjetivo o complica. Se você revisa os objetivos subjetivos regularmente (trimestralmente?) Durante o período de bônus que minimizaria surpresas.