Gestão TI

Lean, GLPI e a Verdade Sobre Processos: Como a TI Pode Parar de Apagar Incêndio e Começar a Gerar Valor

Processo ruim não aparece de forma clara no balanço, mas consome tempo, energia, produtividade e lucro todos os meses.

A maioria das empresas fala sobre tecnologia, inovação, inteligência artificial, automação e transformação digital.

Mas existe uma verdade que muita gente evita encarar:

Não adianta ter ferramenta moderna se o processo continua bagunçado.

E aqui eu quero trazer uma visão prática, principalmente para quem trabalha com suporte, infraestrutura, sustentação de sistemas, service desk, atendimento interno, gestão de TI ou melhoria de processos.

Muitas vezes, quando uma central de atendimento está sobrecarregada, a primeira conclusão é simples:

“Está faltando gente.”

Às vezes realmente falta.

Mas nem sempre.

Em muitos casos, o problema principal não está apenas na quantidade de pessoas. Está no fluxo do processo.

Chamado parado, categoria errada, técnico sem informação, usuário sem retorno, SLA estourado, retrabalho, falta de padrão e ausência de indicadores não são apenas problemas operacionais.

São sinais de desperdício.

É aqui que o Lean começa a fazer sentido.

O Lean tem origem no Sistema Toyota de Produção e foi popularizado no mundo corporativo por autores como James Womack e Daniel Jones, principalmente com os princípios de valor, fluxo de valor, fluxo contínuo, sistema puxado e perfeição/melhoria contínua. A ideia central é simples, mas muito poderosa: entregar mais valor com menos desperdício. Lean Enterprise Institute

No contexto de TI, especialmente usando GLPI, isso significa transformar o atendimento em um fluxo mais inteligente, mensurável e melhorável.


Visão central deste artigo

Este artigo não é sobre “ferramenta pela ferramenta”.

É sobre como usar o GLPI como parte de uma estratégia maior de gestão.

A proposta aqui é conectar:

  • Lean, para eliminar desperdícios;
  • GLPI, para registrar e organizar o processo real;
  • ITIL, para estruturar boas práticas de serviços;
  • Metabase, para transformar dados em indicadores;
  • PDCA e Kaizen, para sustentar a melhoria contínua.

O objetivo não é apenas atender chamados.
O objetivo é aprender com cada chamado para melhorar o sistema inteiro.


1. O problema não é só o chamado. É o caminho que ele percorre

Quando um usuário abre um chamado, ele não está interessado em saber se o fluxo interno da TI tem três níveis, cinco aprovações, duas filas e uma regra de prioridade mal configurada.

O usuário quer resolver o problema.

Se ele não consegue imprimir, acessar um sistema, redefinir uma senha, usar o e-mail ou trabalhar normalmente, o valor para ele é simples:

  • resolver rápido;
  • resolver certo;
  • receber retorno;
  • não precisar repetir a mesma informação;
  • não abrir o mesmo chamado várias vezes;
  • saber o prazo;
  • sentir que foi bem atendido.

Esse ponto é essencial.

No Lean, valor é aquilo que realmente importa para o cliente ou usuário final.

No suporte de TI, o valor não é “ter muitos chamados registrados”. O valor está em resolver problemas, reduzir reincidência, cumprir SLA, comunicar bem e gerar aprendizado para a organização.

O GLPI entra como uma ferramenta forte porque permite registrar incidentes, requisições, SLAs, categorias, ativos, técnicos, grupos, entidades, localizações, satisfação e histórico de atendimento.

A própria documentação do GLPI apresenta a solução como uma plataforma de ITSM e helpdesk para lidar com incidentes, requisições, catálogo de serviços e SLAs. GLPI Project Documentação GLPI

Mas aqui está o detalhe:

Ferramenta nenhuma salva processo ruim sozinha.

O GLPI registra.
O Lean analisa.
A gestão corrige.
Os indicadores provam se melhorou ou não.


2. Menos hype, mais processo

Gosto de olhar tecnologia sem romantizar demais.

Hoje se fala muito sobre inteligência artificial, automação, dashboards, bots, integrações e transformação digital.

Tudo isso tem valor.

Mas a pergunta de base continua sendo:

O processo está organizado o suficiente para ser automatizado?

Porque automatizar bagunça não resolve.

Apenas faz o erro acontecer mais rápido.

Na prática, processo bom não é aquele cheio de etapas. Processo bom é aquele que:

  • reduz confusão;
  • evita retrabalho;
  • melhora a comunicação;
  • deixa claro quem faz o quê;
  • gera dados confiáveis;
  • facilita a tomada de decisão;
  • entrega valor para o usuário final.

Um processo ruim pode até funcionar por um tempo, principalmente quando a equipe é boa e “carrega nas costas”.

Mas isso tem limite.

Chega uma hora em que a empresa cresce, o volume de chamados aumenta, os usuários cobram mais, o SLA começa a estourar e a gestão percebe que não tem visão clara do que está acontecendo.

Aí o problema aparece.


3. Lean não é cortar custo. É cortar desperdício

Um erro comum é achar que Lean significa simplesmente reduzir custo ou fazer mais com menos gente.

Essa visão é rasa.

Lean é sobre:

  • fluxo;
  • valor;
  • qualidade;
  • melhoria contínua;
  • eliminação de desperdício;
  • aprendizado organizacional.

Taiichi Ohno, um dos principais nomes ligados ao Sistema Toyota de Produção, ficou conhecido pela classificação dos desperdícios, chamados de muda. A literatura Lean geralmente trabalha com desperdícios como espera, transporte, estoque, movimento, processamento excessivo, superprodução e defeitos.

Agora, quando trazemos isso para a TI, a leitura muda completamente.

O desperdício não aparece como uma peça parada na linha de produção.

Ele aparece como:

  • chamado parado;
  • técnico aguardando informação;
  • usuário sem retorno;
  • aprovação perdida;
  • SLA estourado;
  • retrabalho;
  • fila acumulada;
  • chamado reaberto;
  • planilha paralela;
  • decisão baseada em achismo;
  • solução sem registro;
  • conhecimento preso na cabeça de uma pessoa.

Processo_Lean_20260527113043.png

Esse quadro é forte porque mostra algo que normalmente fica invisível.

O desperdício em TI nem sempre aparece como dinheiro saindo diretamente do caixa.

Muitas vezes ele aparece como atraso, fila, irritação do usuário, baixa produtividade e equipe sobrecarregada.

Retrabalho silencioso é perigoso porque, com o tempo, todo mundo se acostuma com ele.


4. Os 5 princípios do Lean aplicados ao GLPI

Womack e Jones consolidaram cinco princípios do Lean Thinking:

  • valor;
  • fluxo de valor;
  • fluxo contínuo;
  • sistema puxado;
  • perfeição.

Esses princípios são usados como base para transformar processos e melhorar eficiência. ASME

Agora vamos colocar isso no mundo real do GLPI.


4.1 Valor: o que realmente importa para o usuário?

Valor é aquilo que resolve a dor do usuário.

No GLPI, isso começa antes mesmo do técnico atender.

Começa na abertura do chamado.

Um bom processo precisa responder:

  • o formulário está claro?
  • a categoria faz sentido?
  • o usuário sabe o que preencher?
  • o chamado já chega com dados mínimos?
  • a prioridade é baseada em impacto e urgência?
  • o SLA está coerente?
  • a comunicação é automática e clara?
  • o usuário recebe retorno durante o atendimento?
  • a solução fica registrada de forma reutilizável?

Exemplo simples:

Se o usuário abre um chamado dizendo “não consigo imprimir”, o valor não é registrar esse chamado em uma fila bonita.
O valor é fazer o usuário voltar a imprimir com o menor esforço possível.

Aplicações práticas no GLPI:

  • criar categorias claras;
  • usar modelos de chamados;
  • criar formulários por tipo de solicitação;
  • definir SLA por criticidade;
  • usar modelos de solução;
  • criar base de conhecimento;
  • medir satisfação após a solução;
  • revisar chamados reabertos;
  • transformar dúvidas recorrentes em artigos internos.

Aqui começa a diferença entre uma TI reativa e uma TI organizada.

TI madura não mede apenas volume. Mede valor entregue.


4.2 Fluxo de valor: onde o chamado está travando?

O fluxo de valor é o caminho completo do chamado.

No GLPI, esse fluxo pode ser visto assim:

Abertura → Triagem → Atribuição → Atendimento → Solução → Aprovação → Fechamento → Pesquisa

A pergunta Lean é direta:

Qual etapa realmente gera valor e qual etapa só cria espera, burocracia ou retrabalho?

Um chamado pode parecer simples quando olhamos apenas para o número dele dentro do GLPI.

Mas, quando analisamos o caminho completo, começamos a enxergar onde o processo perde força.

Na prática, podem aparecer situações como:

  • o chamado ficou dois dias sem técnico responsável;
  • a categoria foi preenchida como “Outros”;
  • o técnico precisou pedir informações básicas que poderiam estar no formulário;
  • o usuário demorou para responder;
  • o chamado foi transferido entre vários grupos;
  • a solução foi registrada sem detalhe;
  • o chamado ficou dias aguardando aprovação;
  • o SLA estourou sem ninguém perceber a tempo.

Nesse caso, talvez o problema não seja falta de conhecimento técnico.

Pode ser falha na triagem, ausência de formulário adequado, categoria mal estruturada ou falta de regra automática.

É aqui que o GLPI deixa de ser apenas uma ferramenta de abertura de chamados e passa a ser uma fonte estratégica de dados.

Quando bem utilizado, ele permite enxergar o fluxo real do atendimento, identificar gargalos e mostrar onde a equipe está perdendo tempo com tarefas repetitivas, manuais ou mal direcionadas.

O chamado conta uma história.
O processo mostra onde essa história está travando.


4.3 Fluxo contínuo: reduzir fila, gargalo e interrupção

Fluxo contínuo significa fazer o trabalho andar com menos interrupção.

Na teoria parece simples.

Na prática, é um dos maiores desafios das áreas de TI.

Isso acontece porque o suporte normalmente trabalha com muitas demandas ao mesmo tempo:

  • incidente crítico;
  • solicitação simples;
  • acesso de usuário;
  • problema de impressora;
  • e-mail;
  • sistema interno;
  • equipamento;
  • rede;
  • dúvida operacional;
  • solicitação recorrente;
  • erro de sistema.

Quando tudo entra na mesma fila, sem critério claro, a equipe perde prioridade.

O técnico fica sobrecarregado, o usuário fica sem retorno e a gestão não consegue enxergar o que realmente está travando o atendimento.

Na TI, os gargalos mais comuns são:

  • chamado sem responsável;
  • fila cheia de pendências;
  • falta de informação na abertura;
  • aprovação parada com usuário;
  • categoria preenchida de forma errada;
  • dependência de outro setor;
  • chamados repetidos;
  • técnico com chamados demais ao mesmo tempo;
  • ausência de padrão para registrar solução;
  • falta de painel para acompanhar SLA e backlog.

Aplicações práticas no GLPI

Para melhorar o fluxo contínuo no GLPI, algumas ações ajudam bastante:

  • criar regras automáticas de atribuição;
  • separar incidente, requisição e problema;
  • organizar filas por grupo técnico;
  • usar modelos de tarefas;
  • padronizar categorias;
  • configurar notificações;
  • acompanhar backlog por dashboard;
  • criar alertas para chamados próximos do vencimento;
  • usar modelos de solução para problemas recorrentes;
  • revisar chamados sem técnico responsável diariamente.

Exemplo prático

Chamados de reset de senha não deveriam competir com um incidente crítico de sistema parado.

Se tudo cai na mesma fila, a gestão perde prioridade e a equipe perde foco.

O correto é criar um fluxo mais inteligente, onde demandas simples sejam direcionadas rapidamente e incidentes críticos recebam atenção imediata.

O objetivo do fluxo contínuo não é fazer a equipe correr mais.
É fazer o processo travar menos.


4.4 Sistema puxado: trabalhar pela demanda real

No Lean, sistema puxado significa executar o trabalho conforme a demanda real, e não simplesmente empurrar tarefas para a equipe sem controle.

Na TI, isso é muito importante.

Muitas centrais de atendimento trabalham no modo:

“Quem grita mais alto é atendido primeiro.”

Isso parece resolver no curto prazo, mas cria desorganização, injustiça na fila, sobrecarga dos técnicos e perda de controle sobre o SLA.

Trabalhar com sistema puxado significa organizar o atendimento com base em critérios claros.

Na TI, isso significa:

  • trabalhar por prioridade real;
  • atender conforme SLA;
  • limitar trabalho em progresso;
  • evitar que um técnico fique com dezenas de chamados abertos ao mesmo tempo;
  • priorizar impacto e urgência;
  • acompanhar chamados próximos do vencimento;
  • distribuir melhor a carga entre os técnicos;
  • evitar que demandas simples travem incidentes importantes.

O GLPI permite organizar esse modelo usando:

  • status;
  • grupos;
  • prioridades;
  • SLAs;
  • regras de negócio;
  • filtros;
  • categorias;
  • painéis de acompanhamento;
  • notificações automáticas.

A pergunta aqui é muito importante:

A equipe está trabalhando no que é mais importante ou apenas no que apareceu primeiro?

Essa pergunta muda o jogo.

Uma central madura não trabalha apenas por ordem de chegada.

Ela trabalha por valor, impacto, urgência e risco.

Isso não significa ignorar chamados simples.

Significa organizar o atendimento para que cada demanda receba o tratamento correto.


4.5 Perfeição: melhorar sempre, mesmo que aos poucos

No Lean, perfeição não significa nunca errar.

Significa melhorar continuamente.

Esse ponto se conecta ao conceito de Kaizen, muito associado ao trabalho de Masaaki Imai, que defende pequenas melhorias constantes feitas por quem vive o processo no dia a dia.

Na TI, melhoria contínua não precisa começar com um grande projeto.

Pode começar com perguntas simples:

  • por que esse tipo de chamado sempre volta?
  • por que esse SLA sempre estoura?
  • por que essa categoria recebe tantos chamados?
  • por que esse setor tem tanta reclamação?
  • por que esse técnico está sempre sobrecarregado?
  • por que tantos chamados ficam aguardando aprovação?
  • por que a equipe ainda usa planilha paralela?
  • por que a solução não vira base de conhecimento?

Na prática, a melhoria contínua no GLPI pode ser feita com uma rotina mensal.

Rotina recomendada

  • revisar chamados fora do SLA;
  • analisar chamados reabertos;
  • avaliar pesquisas de satisfação ruins;
  • revisar categorias com maior volume;
  • identificar chamados sem técnico;
  • verificar chamados aguardando aprovação;
  • atualizar base de conhecimento;
  • ajustar SLAs e regras;
  • treinar usuários e técnicos;
  • revisar formulários de abertura;
  • criar modelos de solução;
  • automatizar demandas repetitivas.

Esse ponto também conversa diretamente com a ITIL 4, que trabalha com o conceito de Service Value System, conectando práticas, governança, cadeia de valor e melhoria contínua para gerar valor por meio dos serviços. ITSM.tools

Ou seja:

Lean e ITIL não brigam. Eles se completam.

O Lean ajuda a eliminar desperdício.
A ITIL ajuda a organizar boas práticas.
O GLPI ajuda a operacionalizar.
O Metabase ajuda a transformar dados em visão gerencial.
O PDCA e o Kaizen ajudam a manter a melhoria contínua.


5. GLPI + ITIL + Lean + Metabase: a combinação que faz sentido

Minha visão é que o GLPI não deve ser tratado apenas como “sistema de chamados”.

Ele pode ser uma plataforma de gestão de serviços.

Quando bem configurado, o GLPI ajuda a organizar:

  • incidentes;
  • requisições;
  • problemas;
  • mudanças;
  • ativos;
  • SLAs;
  • categorias;
  • grupos técnicos;
  • base de conhecimento;
  • satisfação;
  • relatórios;
  • histórico de atendimento;
  • regras de atribuição;
  • controle de filas;
  • gestão de aprovações.

Mas o GLPI sozinho não faz milagre.

A ferramenta precisa estar conectada a um modelo de gestão.

É aqui que entra a combinação:

  • ITIL organiza boas práticas de gestão de serviços.
  • Lean elimina desperdícios e melhora o fluxo.
  • GLPI operacionaliza o processo.
  • Metabase transforma dados em gestão visual.
  • PDCA e Kaizen mantêm a melhoria contínua.

Essa combinação permite uma mudança importante:

A TI deixa de ser apenas uma área que responde chamados e passa a ser uma área que mede, aprende, melhora e entrega valor.

Quando isso acontece, a gestão passa a enxergar muito mais do que quantidade de chamados.

Ela começa a enxergar:

  • causa;
  • impacto;
  • reincidência;
  • atraso;
  • qualidade;
  • gargalos;
  • produtividade;
  • oportunidade de melhoria.

Esse é o ponto em que atendimento deixa de ser apenas operação e começa a virar estratégia.


6. Estudo de caso: central de TI com GLPI e processo travado

Imagine uma empresa com alto volume de chamados mensais no GLPI.

A equipe reclama que está sobrecarregada.
Os usuários reclamam que os chamados demoram.
A gestão reclama que não tem visibilidade.
O SLA começa a estourar.
A satisfação começa a cair.

O diagnóstico inicial parece simples:

“Precisamos contratar mais gente.”

Mas, quando aplicamos a visão Lean, a análise muda.

O problema pode não estar apenas na quantidade de pessoas.

Pode estar no fluxo do processo.

Cenário encontrado

Ao analisar os dados do GLPI, aparecem alguns sinais:

  • muitos chamados fora do SLA;
  • muitos chamados pendentes;
  • chamados solucionados aguardando aprovação por vários dias;
  • categorias genéricas demais;
  • chamados sem informação básica;
  • técnicos sobrecarregados;
  • problemas recorrentes de impressora, acesso, e-mail e sistemas;
  • baixa satisfação em alguns tipos de atendimento;
  • excesso de chamados transferidos entre grupos;
  • ausência de base de conhecimento para problemas comuns.

Esses pontos mostram que a central não precisa apenas “atender mais”.

Ela precisa entender onde o fluxo está perdendo eficiência.

A pergunta deixa de ser:

“Quantos chamados temos?”

E passa a ser:

“Por que esses chamados estão se acumulando, atrasando ou voltando?”

Essa mudança de pergunta é o começo da melhoria.


7. Diagnóstico Lean: o que está gerando desperdício?

Vamos traduzir os sintomas para uma visão Lean.

ChatGPT_Image_27_de_mai._de_2026_08_34_50_20260527113512.png

Aqui a conclusão fica mais clara:

O problema não é apenas volume.
O problema é fluxo.

E quando o fluxo é ruim, contratar mais pessoas pode apenas aumentar o custo sem resolver a causa.

Antes de aumentar a equipe, a empresa precisa responder:

  • o processo está bem desenhado?
  • as categorias fazem sentido?
  • o SLA está configurado corretamente?
  • os chamados estão chegando com informação suficiente?
  • existe regra automática de atribuição?
  • os técnicos estão trabalhando com prioridade clara?
  • existe acompanhamento visual dos indicadores?
  • existe base de conhecimento para chamados recorrentes?

Sem essa análise, a empresa corre o risco de colocar mais pessoas dentro de um processo quebrado.

Mais gente em processo ruim pode virar apenas mais custo dentro da mesma desorganização.


8. Indicadores que toda gestão de TI deveria medir no GLPI

Sem indicador, a gestão vira opinião.

W. Edwards Deming é uma das grandes referências em qualidade e melhoria contínua, muito associado ao ciclo PDCA e à gestão baseada em dados.

A ideia é simples:

Melhorar exige medir, analisar, agir e padronizar.

No GLPI, alguns indicadores são essenciais.

ChatGPT_Image_27_de_mai._de_2026_08_49_32_20260527114943.png

O ponto não é criar dashboard bonito só para apresentação.

O ponto é usar o dado para tomar decisão.

Um painel no Metabase, por exemplo, pode mostrar rapidamente:

  • quais categorias mais geram chamados;
  • quais técnicos estão sobrecarregados;
  • quais setores mais demandam suporte;
  • quais chamados mais estouram SLA;
  • onde a satisfação está caindo;
  • quais chamados estão parados há mais tempo;
  • quais problemas estão se repetindo;
  • quais chamados estão aguardando aprovação;
  • quais locais concentram maior volume;
  • quais soluções geram reabertura.

Quando a gestão visual entra no processo, a TI deixa de trabalhar no escuro.

Indicador bom não serve para enfeitar reunião.
Serve para revelar onde a gestão precisa agir.


9. Pareto: comece onde dói mais

O Princípio de Pareto conversa muito bem com Lean.

Na prática, muitas centrais descobrem que:

  • poucas categorias geram a maior parte dos chamados;
  • poucos setores concentram muitas solicitações;
  • poucos problemas causam grande impacto;
  • poucos tipos de erro geram muita insatisfação;
  • poucos gargalos explicam grande parte dos atrasos.

Exemplo:

Se 20% das categorias geram 70% dos chamados, a melhoria deve começar nessas categorias.

Se “impressora”, “senha” e “e-mail” são os maiores volumes, a empresa pode criar:

  • base de conhecimento;
  • formulário específico;
  • automação de roteamento;
  • scripts de diagnóstico;
  • treinamento para usuários;
  • modelos de solução;
  • ações preventivas;
  • análise de causa raiz;
  • acompanhamento mensal desses temas.

Isso é gestão inteligente.

Não é tentar resolver tudo ao mesmo tempo.

É atacar primeiro o que gera maior impacto.

A TI madura aprende a priorizar melhoria, não apenas chamado.


10. Modelo de implementação prática no GLPI

Aqui está um modelo direto para aplicar Lean no GLPI.


Etapa 1 — Mapear o fluxo atual

Desenhe o caminho real do chamado:

Abertura → Triagem → Atribuição → Atendimento → Solução → Aprovação → Fechamento → Pesquisa

Pergunte:

  • quem recebe?
  • quem classifica?
  • quem prioriza?
  • quem acompanha SLA?
  • quem cobra usuário?
  • quem revisa chamados reabertos?
  • quem analisa satisfação?
  • onde o chamado fica parado?
  • onde existe retrabalho?
  • onde falta informação?

O objetivo dessa etapa é enxergar o processo como ele realmente acontece, e não como ele está desenhado no papel.

Processo real é o que acontece na operação, não o que está bonito no fluxograma.


Etapa 2 — Identificar desperdícios

Procure sinais claros de desperdício:

  • chamados parados;
  • chamados reabertos;
  • excesso de transferência;
  • categorias erradas;
  • falta de informação;
  • demora de aprovação;
  • técnicos sobrecarregados;
  • chamados repetidos;
  • filas sem responsável;
  • soluções sem padrão.

Aqui a empresa começa a entender onde está perdendo tempo, energia e produtividade.


Etapa 3 — Medir com dados reais

Use GLPI e, se possível, Metabase para acompanhar:

  • SLA;
  • backlog;
  • volume por categoria;
  • tempo de atendimento;
  • satisfação;
  • chamados por setor;
  • produtividade por grupo;
  • chamados reincidentes;
  • chamados por localização;
  • chamados aguardando aprovação;
  • chamados reabertos.

Sem dados, a melhoria fica baseada em percepção.

Com dados, a gestão consegue priorizar melhor.

Percepção aponta o problema.
Dados confirmam onde agir primeiro.


Etapa 4 — Corrigir as maiores causas

Comece pelo que gera mais impacto:

  • categorias mais usadas;
  • SLAs mais estourados;
  • chamados mais recorrentes;
  • setores com mais demanda;
  • técnicos mais sobrecarregados;
  • piores avaliações;
  • chamados com maior tempo parado;
  • problemas com maior reincidência.

Essa etapa precisa ser prática.

Não basta descobrir o problema.

É preciso definir ação, responsável e prazo.


Etapa 5 — Padronizar

Crie padrões para evitar que o erro volte.

Algumas ações úteis:

  • modelos de chamados;
  • modelos de solução;
  • regras automáticas;
  • formulários específicos;
  • base de conhecimento;
  • categorias bem definidas;
  • grupos técnicos organizados;
  • notificações automáticas;
  • critérios claros de prioridade;
  • política para chamados aguardando aprovação.

Padronizar não é engessar.

É criar uma base para que o processo funcione com mais previsibilidade.

Padrão bom reduz dependência de herói.


Etapa 6 — Melhorar continuamente

Crie uma rotina mensal de melhoria.

Revise:

  • indicadores;
  • categorias;
  • base de conhecimento;
  • treinamentos;
  • SLAs;
  • satisfação;
  • chamados reabertos;
  • chamados fora do prazo;
  • chamados repetidos;
  • etapas inúteis.

Aqui entra o ciclo de melhoria contínua.

Não é um projeto que termina.

É uma cultura que amadurece.


11. O papel da base de conhecimento

Uma base de conhecimento bem construída é uma das formas mais práticas de reduzir desperdício.

Ela ajuda a:

  • evitar chamados repetidos;
  • padronizar soluções;
  • acelerar atendimento;
  • treinar novos técnicos;
  • orientar usuários;
  • reduzir dependência de pessoas específicas;
  • melhorar a qualidade das respostas;
  • diminuir o tempo médio de atendimento.

Exemplo:

Se todo mês existem muitos chamados sobre configuração de e-mail, impressora, VPN ou acesso a sistemas, isso precisa virar artigo, procedimento ou automação.

O conhecimento não pode ficar preso na cabeça de um técnico.

Quando isso acontece, a empresa cria dependência.

E dependência é risco operacional.

Uma boa base de conhecimento transforma experiência individual em patrimônio da organização.


12. Chamados aguardando aprovação: o estoque invisível da TI

Um ponto que muitas empresas ignoram é o volume de chamados solucionados aguardando aprovação.

Na visão Lean, isso parece muito com estoque parado.

O trabalho aparentemente foi feito, mas o ciclo ainda não terminou.

Problemas comuns:

  • usuário não aprova;
  • chamado fica aberto por dias;
  • indicadores ficam distorcidos;
  • fila parece maior;
  • técnico perde rastreabilidade;
  • gestão não sabe se aquilo foi realmente resolvido;
  • chamados antigos continuam poluindo os relatórios.

A solução pode envolver:

  • notificação automática;
  • prazo de aprovação;
  • regra de fechamento automático conforme política interna;
  • comunicação clara para o usuário;
  • análise mensal desses chamados;
  • painel específico de chamados aguardando aprovação.

Esse detalhe parece pequeno, mas em ambientes com alto volume pode fazer muita diferença.

Fechar o ciclo do chamado é tão importante quanto atender o chamado.


13. Satisfação não é só nota. É diagnóstico

A pesquisa de satisfação no GLPI não deve ser vista apenas como uma nota bonita para relatório.

Ela é diagnóstico.

Uma nota baixa pode revelar:

  • comunicação ruim;
  • demora;
  • solução incompleta;
  • falta de empatia;
  • categoria errada;
  • reincidência;
  • falha de expectativa;
  • SLA mal definido;
  • falta de retorno ao usuário.

O erro é olhar apenas a média geral.

O ideal é cruzar satisfação com:

  • técnico;
  • categoria;
  • setor;
  • localização;
  • tempo de atendimento;
  • SLA;
  • reincidência;
  • tipo de chamado;
  • grupo responsável.

É assim que a gestão começa a enxergar padrão.

E onde existe padrão, existe oportunidade de melhoria.

Uma avaliação ruim não deve ser tratada apenas como reclamação.
Deve ser vista como dado para corrigir processo.


14. O que empresas ganham com processos bem definidos?

Processo correto não é burocracia.

Processo correto é produtividade.

Quando a TI organiza seu fluxo, a empresa ganha:

  • menos retrabalho;
  • menos atraso;
  • melhor SLA;
  • mais satisfação;
  • mais previsibilidade;
  • melhor uso da equipe;
  • redução de chamados recorrentes;
  • decisão baseada em dados;
  • aumento de confiança na TI;
  • melhor alinhamento com o negócio;
  • mais clareza para a gestão;
  • melhor comunicação com os usuários.

E aqui entra uma visão importante de gestão:

TI não pode ser vista apenas como custo.

Uma TI organizada evita parada, reduz perda de produtividade, melhora a experiência interna e ajuda a empresa a funcionar melhor.

Peter Drucker é frequentemente associado à ideia de que gestão precisa transformar objetivos em desempenho mensurável.

Trazendo isso para a TI:

Não basta dizer que o suporte está “correndo bastante”.
É preciso mostrar resultado, qualidade, prazo, volume, causa e melhoria.


15. A diferença entre TI reativa e TI estratégica

Uma TI reativa vive apagando incêndio.

Ela trabalha assim:

  • atende quando estoura;
  • corre atrás do problema;
  • depende de heróis;
  • não mede direito;
  • não documenta;
  • não aprende com reincidência;
  • resolve o sintoma, mas não a causa.

Uma TI estratégica trabalha diferente:

  • mede indicadores;
  • entende padrões;
  • melhora processos;
  • documenta soluções;
  • automatiza tarefas;
  • reduz reincidência;
  • usa dados para decisão;
  • comunica melhor;
  • entrega valor para o negócio;
  • cria previsibilidade;
  • transforma chamados em aprendizado.

O GLPI pode existir nos dois cenários.

A diferença não está apenas na ferramenta.

Está na maturidade do processo.

Uma empresa pode ter GLPI e continuar desorganizada.
Ou pode usar o GLPI como base para uma gestão de serviços mais inteligente.


16. Referências renomadas aplicadas na prática

Taiichi Ohno

Referência central do Sistema Toyota de Produção.

Sua contribuição ajuda a enxergar desperdícios que muitas vezes ficam invisíveis no dia a dia operacional.

Na TI, isso significa identificar espera, retrabalho, excesso de transferência, chamados parados e processos que não agregam valor.


James Womack e Daniel Jones

Autores ligados à popularização do Lean Thinking, estruturando os cinco princípios:

  • valor;
  • fluxo de valor;
  • fluxo;
  • puxar;
  • perfeição.

Na TI, esses princípios ajudam a transformar atendimento em fluxo de valor.


Masaaki Imai

Associado ao Kaizen, reforça a ideia de melhoria contínua com participação das pessoas.

Na TI, isso significa envolver técnicos, analistas, gestores e usuários na evolução do processo.


W. Edwards Deming

Referência em qualidade e melhoria contínua, muito ligado ao pensamento estatístico, ao PDCA e à importância de gerir com dados.

Na TI, isso reforça a necessidade de medir antes de decidir.

O ciclo PDCA é amplamente usado como método de melhoria contínua em quatro etapas: planejar, executar, verificar e agir. Investopedia


ITIL / Axelos

A ITIL 4 trabalha com o conceito de sistema de valor de serviço, conectando práticas, governança, cadeia de valor e melhoria contínua para gerar valor por meio dos serviços.

No GLPI, isso pode ser aplicado em:

  • incidentes;
  • requisições;
  • problemas;
  • mudanças;
  • SLAs;
  • catálogo de serviços;
  • base de conhecimento;
  • melhoria contínua.

17. Integração entre atendimento, serviços e estratégia

Uma central de serviços bem estruturada não deve operar isolada da estratégia da empresa.

Quando GLPI, Metabase, Lean e ITIL trabalham juntos, a organização começa a conectar operação com gestão.

Isso permite:

  • enxergar gargalos;
  • medir produtividade;
  • acompanhar SLA;
  • melhorar satisfação;
  • reduzir reincidência;
  • justificar investimentos;
  • priorizar melhorias;
  • transformar dados operacionais em decisão executiva.

Esse é o caminho para uma integração nativa entre gestão de atendimento, serviços e estratégia.

Uma solução adaptável, personalizável e de baixíssimo custo pode gerar muito valor quando o processo é bem desenhado.

Saiba mais sobre essa visão prática em:


18. Conclusão: o futuro da TI não é só ferramenta. É processo

A tecnologia evolui rápido.

Novas ferramentas aparecem o tempo todo:

  • IA;
  • automação;
  • dashboards;
  • integrações;
  • bots;
  • scripts;
  • APIs;
  • plataformas de atendimento.

Tudo isso é importante.

Mas a base continua sendo processo.

Uma empresa que não entende seu fluxo de atendimento vai apenas automatizar bagunça.

E automatizar bagunça não resolve.

Só faz o erro acontecer mais rápido.

O Lean aplicado ao GLPI ajuda a responder perguntas fundamentais:

  • onde o processo está travando?
  • quais chamados geram mais esforço?
  • quais categorias causam mais atraso?
  • quais setores demandam mais suporte?
  • quais técnicos estão sobrecarregados?
  • quais soluções geram reabertura?
  • onde existe retrabalho?
  • o que pode ser automatizado?
  • o que precisa virar base de conhecimento?
  • onde a TI está perdendo valor?

No fim, Lean em TI é enxergar o atendimento como fluxo de valor.

O GLPI registra esse fluxo.
Os indicadores mostram os gargalos.
A gestão melhora o processo.
A melhoria contínua transforma suporte em estratégia.

E talvez essa seja a maior virada de chave:

TI boa não é aquela que apenas atende chamado.
TI boa é aquela que aprende com cada chamado e melhora o sistema inteiro.


Mensagem final

Processo bem desenhado não cria burocracia.

Cria clareza.
Cria escala.
Cria produtividade.
Cria previsibilidade.
Cria confiança.
Cria lucro.

A pergunta não é quanto custa organizar processos.
A pergunta é: quanto custa continuar trabalhando no improviso?


Referências e apoio

  • Lean Enterprise Institute — Lean Thinking and Practice: apresenta os princípios do Lean Thinking propostos por Womack e Jones para orientar uma transformação Lean.
    https://www.lean.org/lexicon-terms/lean-thinking-and-practice/

  • ASME — 5 Lean Principles Every Engineer Should Know: resume os princípios de valor, fluxo de valor, fluxo, puxar e perfeição associados a Womack e Jones.
    https://www.asme.org/topics-resources/content/5-lean-principles-every-should-know

  • GLPI Project — Smart IT Service Management, Helpdesk & Asset Tracking: documentação institucional sobre GLPI como solução de ITSM, helpdesk, incidentes, requisições, catálogo de serviços e SLAs.
    https://www.glpi-project.org/en/

  • GLPI Help Center — Manage tickets: documentação sobre gestão de tickets, incidentes, requisições e associação de SLA ao chamado.
    https://help.glpi-project.org/documentation/modules/assistance/tickets/ticketmanagement

  • ITSM.tools — ITIL 4 Service Value System Explained: explicação sobre o sistema de valor de serviço da ITIL 4, cadeia de valor, práticas e melhoria contínua.
    https://itsm.tools/the-itil-4-service-value-system-explained/

  • Investopedia — PDCA Cycle: explicação sobre o ciclo Plan-Do-Check-Act, popularizado por W. Edwards Deming, como método de melhoria contínua.
    https://www.investopedia.com/terms/p/pdca-cycle.asp

  • Projeto Plataforma — Integração GLPI + Metabase e gestão estratégica de atendimento.
    https://projetoplataforma.com.br/landing_glpi/

  • Projeto Plataforma — Lean, GLPI e a verdade sobre processos.
    https://projetoplataforma.com.br/artigo/lean-glpi-e-a-verdade-sobre-processos-como-a-ti-pode-parar-de-apagar-incendio-e-comecar-a-gerar-valor