Gestor Tecnologia Da Informação - Gestão Da Tecnologia Da Informação | PDF | Tecnologia da Informação ...
Gestão Da Tecnologia Da Informação | PDF | Tecnologia da Informação ...

Por que a maioria dos gestores de TI falha em implementar um sistema de gestão

A implementação de um gestor tecnologia da informação nunca é só uma questão de escolher um software e instalar. A parte técnica leva algumas semanas. A parte humana, que é o que realmente trava tudo, leva meses e geralmente acaba custando o projeto. Eu comecei a brigar com isso há uns oito anos, quando minha empresa comprou uma plataforma genérica de ITSM. A gente achou que bastava importar os dados de ativos e criar os procedimentos. Em três meses, o sistema estava sendo usado por dois funcionários de forma esporádica, e o resto da equipe continuava resolvendo tudo pelo WhatsApp. A plataforma em si não era ruim. O problema era que ninguém tinha dedicado tempo para mapear os fluxos reais de trabalho antes de tentarmos encaixá-los num software.

O erro mais comum é partir diretamente para a escolha da ferramenta sem definir o que exatamente você quer gestionar. Antes de qualquer coisa, você precisa listar os processos que realmente existem na sua operação hoje. Não os processos ideais, os que acontecem de fato. Anotações soltas, conversas com a equipe de suporte, análise dos tickets abertos. Isso leva cerca de uma semana e evita que você compre uma funcionalidade que nunca vai usar.

Escolhendo e configurando o gestor tecnologia da informação certo

Depois de ter o mapeamento dos processos, a próxima decisão é entre contratar uma solução SaaS ou rodar algo on-premise. No Brasil, a maioria das empresas pequenas e médias está opting por plataformas cloud como Kanda, Freshservice ou até ferramentas mais simples como o ZenHub combinado com um formulário estruturado. A vantagem do SaaS é que a manutenção fica com o fornecedor. A desvantagem é que, ao configurar regras personalizadas de SLA e fluxos de aprovação, você rapidamente se depara com limitações que o sistema não permite ultrapassar sem customizações caras. Já tive um caso específico em que precisávamos de um campo obrigatório condicional: se o solicitante fosse do departamento financeiro, um campo adicional com código de custo deveria aparecer automaticamente. O sistema escolhido não suportava essa lógica nativamente. A solução foi criar um script simples em Python que lia os dados do formulário via API e pré-preenchia o campo antes do registro ser salvo. Levei cerca de seis horas para deixar funcionando e hoje roda sem problemas. Se você planeja precisar de integrações do tipo, verifique desde o início se a plataforma oferece API documentada e se permite webhook ou trigger customizado.

Outro ponto que poucas pessoas consideram é a configuração inicial de categorias e subcategorias de chamados. A tendência natural é criar muitas subdivisões para tentar ser preciso. Na prática, isso apenas gera confusão na hora de classificar. Um modelo mais enxuto com quatro a seis categorias principais e subcategorias limitadas a duas camadas costuma funcionar melhor. Você pode refinar depois com base nos dados de uso real, não na intuição.

👉 Clique no botão abaixo para saber mais sobre o assunto!

Documentação e treinamento: a parte chata que define o sucesso

Um gestor de TI bem configurado só funciona se as pessoas souberem usá-lo corretamente. Eu já vi empresas gastarem dezenas de milhares de reais em licenciamento e depois não destinarem nada para capacitação. O resultado é previsível: dados inconsistentes, tickets mal descritos e métricas inúteis. Um guia rápido de quatro páginas com exemplos reais do dia a dia da sua equipe vale mais do que um treinamento genérico de duas horas. Inclua screenshots dos telões reais do sistema, mostre como preencher cada campo obrigatório e, principalmente, explique o que acontece se o chamado for mal preenchido. As pessoas seguem procedimentos quando entendem a consequência direta de não segui-los.

Para a parte de download e instalação, se você estiver optando por uma solução open source como o iTop ou o GLPI, o processo é relativamente direto. O GLPI, por exemplo, está disponível no repositório oficial e roda em um servidor LAMP básico. A instalação leva cerca de trinta minutos em uma máquina com quatro núcleos e oito gigabytes de RAM. A configuração inicial inclui a criação dos perfis de usuário, a importação de ativos e a definição das regras de negócio. Tudo pelo assistente web, sem necessidade de compilação ou configuração manual de banco de dados.

Métricas que realmente importam e as que você deve ignorar

A maioria dos dashboards de gestão de TI inclui métricas que parecem úteis mas na prática não ajudam em nada. Tempo médio de resolução é uma delas. Soa importante, mas sem contexto não significa nada. Um chamado resolvido em quinze minutos pode ter sido um problema trivial que nem precisava ter sido aberto. Outro que levou três dias pode ter envolvido uma mudança crítica de infraestrutura. O que realmente importa é a taxa de primeiro contato resolução, o percentual de chamados que voltam abertos após fechados e o tempo médio até o primeiro atendimento, que mostra se sua equipe está respondendo dentro do prazo. Outra métrica subutilizada é o volume de chamados por categoria ao longo do tempo. Se uma categoria específica aumenta consistentemente em dois meses consecutivos, isso é um sinal de que algo está errado num processo ou equipamento, não necessariamente na equipe de suporte. Anotar e revisar esses volumes semanalmente, mesmo que de forma rápida, faz diferença na tomada de decisão.

Limitações reais que ninguém menciona

Um gestor tecnologia da informação não substitui processos bem definidos. Se a sua operação atual é caótica, colocar um sistema novo em cima vai apenas tornar o caos mais organizado, não melhor. O sistema amplifica o que já existe. Processos ruins ficam visíveis de forma mais clara e, ironicamente, às vezes mais frustrantes. Também há um limite prático de escalabilidade. Sistemas como GLPI e iTop funcionam bem até certo ponto de crescimento. Quando você passa de duzentos ativos gerenciados e mais de cinquenta chamados por dia, a interface começa a apresentar lentidão significativa, especialmente se a base de dados não estiver otimizada com índices adequados. Nessa situação, a alternativa mais comum é migrar para uma solução enterprise ou particionar a base de dados por período. Isso exige conhecimento técnico de administração de banco e não é algo que um gestor de TI júnior consegue fazer sem supervisão.

Outro ponto fraco comum é a integração com ferramentas externas. A maioria dos sistemas brasileiros de gestão de TI oferece conectores limitados. Se você precisa que o sistema de chamados se comunique com um ferramentas de monitoramento como Zabbix, um sistema de inventário automático como o OCS Inventory ou ainda um ERP interno, prepare-se para desenvolver integrações personalizadas. APIs estão disponíveis, mas a documentação nem sempre acompanha a complexidade real dos cenários que você vai encontrar. O que funciona na prática é começar pequeno, com um número reduzido de processos mapeados e um grupo piloto de usuários. Isso permite ajustar configurações, detectar gargalos e treinar pessoas antes de expandir para toda a organização. A maioria dos projetos que falharam que eu vi acompanhados tinha como ponto em comum a ambição de implantar tudo de uma vez. Nenhuma equipe consegue absorver uma mudança desse porte sem algum tipo de amortecimento gradual.