O que acontece quando você tenta implementar gerenciamento de serviços de ti na prática
A maioria das empresas falha nos primeiros seis meses não por falta de ferramenta, mas porque tenta espelhar o ITIL como se fosse um manual de leis físicas. Não é. É um conjunto de práticas que precisa ser adaptado ao tamanho do time, ao volume de chamados e à maturidade dos gestores locais. Já vi empresa com duzentos colaboradores tentarem implementar uma estrutura de nível 4 de ITIL com três pessoas no help desk. O resultado foi um catálogo de serviços com quarenta e sete classificações que ninguém usava. Em dois meses, voltaram a abrir chamado por WhatsApp. O cerne do gerenciamento de serviços de ti não está no catálogo. Está no fluxo entre o que o usuário pede e o que a equipe entrega. Se esse fluxo tem mais de cinco mãos sem registro de passagem, o processo já nasceu morto.
Por onde começar: a arquitetura antes do software
Não compre ferramenta nenhuma nos primeiros trinta dias. Reserve esse tempo para mapear os quatro fluxos que realmente geram impacto operacional. No meu caso, quando fui acionado para estruturar o gerenciamento de serviços de ti de uma fintech com quatrocentos usuários, comecei identificando que oitenta por cento dos chamados giravam em torno de três categorias: acesso a aplicações críticas, reinstalação de postos de trabalho e problemas de conectividade interna. O restante era ruído. A estrutura que defini levou onze dias. Primeiro, listei todos os serviços de TI que tinham dono definido e SLA mensurável. Só nove saíram dessa triagem. Depois, atribuí a cada um um proprietário funcional, mesmo que o responsável tivesse outras funções no dia a dia. Finalmente, desenhei o fluxo de priorização baseado em dois critérios: impacto nos negócios e urgência temporal. Sem esses dois critérios definidos pela equipe de operações e não pelo consultor externo, o sistema de triagem virava uma votação aleatória.
A escolha da ferramenta e o erro que cometi no início
Depois do mapeamento, precisei de um sistema que suportasse os nove serviços com autonomia para escalonamento automático. Testei quatro plataformas em dois meses. A que adotei permitia criar regras de escalonamento baseadas em horário comercial, criticidade do ativo e disponibilidade do responsável. Configurei o sistema para que chamados de categoria acesso crítico disparassem notificação automática para o segundo nível em quinze minutos sem intervencao manual. O erro foi achar que a automação resolveria a falta de procedimento. No terceiro mês, o sistema escalonou um chamado de reinstalação de posto para o nível três porque o técnico do nível dois marcou a resolução como incompleta ao invés de realocar o chamado para uma fila de segunda linha. Perdi três horas debugando a regra de escalar quando o problema era humano, não tecnológico. A correção foi ajustar o campo de status do chamado para exigir uma justificativa obrigatória quando o técnico marcava como incompleto.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Métricas que realmente importam e as que você deve ignorar
FPR (First Pass Resolution) acima de sessenta e cinco por cento é o indicador que sustenta a operação. Tudo abaixo disso indica que o primeiro nível não tem autonomia ou que o catálogo está mal estruturado. Tempo médio de resposta inicial deve ficar entre cinco e quinze minutos para chamados críticos. Se sua média ultrapassa vinte minutos, o problema não é a ferramenta, é a definição de plantão ou a falta de cobertura horária. Evite medir volume de chamados por técnico como indicador de performance individual. Isso gera inflação artificial de abertura de chamados e desincentiva a resolução colaborativa. Em vez disso, acompanhe a taxa de reclamos do usuário sobre a resolução e o tempo de exposição do serviço afetado. Esses dois números refletem a qualidade real do atendimento.
O caso do serviço de migração de estações que quebrou a estratégia
Um dos problemas mais difíceis que encontrei foi o serviço de migração de postos de trabalho para novo SO. O gerenciamento de serviços de ti previu um SLA de cinco dias úteis, mas o fluxo real envolvia backup, teste de compatibilidade, migração propriamente dita e validação pós-instalação. Nenhum desses passos tinha dono definido na matriz de RACI original. O resultado foi que a migração ficava presa por uma semana em uma fila genérica sem responsável. A solução foi criar um workflow independente com quatro gatilhos de entrada e saída, cada um com responsável identificado e prazo máximo. O sistema passou a exibir um painel visual do status da migração em tempo real. O tempo médio caiu de onze dias para três dias e meio em seis semanas. A mudança não exigiu nova contratação, apenas reorganização das responsabilidades existentes.
Quando o gerenciamento de serviços de ti não funciona
Essa abordagem depende de maturidade mínima de documentação e de pelo menos um gestor disposto a manter o catálogo atualizado. Se a equipe de TI tem rotatividade acima de trinta por cento ao ano, o catálogo vira obsolescência programada em quatro meses. Nesse cenário, o mais racional é começar com um modelo simplificado de gerenciamento de incidentes e adicionar os processos de mudança e configuração apenas após estabilizar o fluxo principal. Tentar embutir todos os processos de uma vez em ambiente de alta rotatividade é um dos motivos mais comuns de fracasso que vejo na prática.
O que fazer quando o SLA não é respeitado e a culpa não é da TI
Uma situação recorrente envolve serviços que dependem de terceiros. A infraestrutura de rede externa, por exemplo, era responsabilidade de uma operadora com SLA de quatro horas para resolution. O sistema de gerenciamento registrava o chamado como aberto até o restabelecimento completo, o que distorcia todas as métricas de tempo de resolução. A solução foi criar uma categoria de chamada vinculada que separava o tempo de espera do provedor do tempo efetivo de atuação da equipe interna. Assim, o FPR refletia a performance real do time e não a ineficiência de um contrato mal monitorado. O gerenciamento de serviços de ti funciona quando você trata ele como uma estrutura viva, não como um documento que se implementa e esquece. Revisão trimestral do catálogo, manutenção obrigatória de dono para cada serviço e ajuste anual dos SLAs com base em dados reais são o mínimo para manter o sistema relevante. Sem esses três pilares, a ferramenta vira um arquivo morto com notificações automáticas.
