Como a TI pode parar de administrar filas, reduzir desperdício e começar a gerar valor

Clark Maltempi
Atualizado em 27 de agosto de 2026

Existe um tipo de caos que, depois de algum tempo, deixa de parecer caos.

O telefone toca, chegam mensagens no Teams, alguém aparece na porta porque “é só uma coisinha rápida”, o gestor pergunta por que determinado chamado ainda não foi resolvido e, enquanto tudo isso acontece, a fila do Service Desk continua crescendo. A equipe trabalha o dia inteiro, os técnicos não param, o painel mostra centenas de tickets em andamento e, mesmo assim, no fim do expediente permanece aquela sensação difícil de explicar para a diretoria: a operação correu muito e avançou pouco.

Se você trabalha com suporte, sustentação ou gestão de serviços, provavelmente já viveu exatamente esse dia. E provavelmente já ouviu a conclusão que costuma vir junto: falta gente.

Às vezes falta mesmo. Capacidade insuficiente existe, e negar isso seria tão superficial quanto atribuir todos os problemas à falta de processo. O ponto é outro: antes de aumentar a equipe, é preciso descobrir se o sistema está usando bem a capacidade que já tem. Uma operação pode estar sobrecarregada porque recebe demanda demais, mas também pode estar fabricando espera, retrabalho, transferências, aprovações inúteis e reincidência. No segundo caso, contratar mais pessoas sem corrigir o fluxo apenas aumenta a capacidade de processar desperdício — com folha de pagamento maior.

É aqui que Lean, ITIL e GLPI começam a se encontrar de forma interessante.

Não porque Lean seja um “método para fechar chamados mais rápido”, nem porque ITIL deva ser usada como coleção de procedimentos burocráticos, muito menos porque o GLPI organize uma empresa sozinho. A conexão acontece porque os três ajudam a responder a uma pergunta mais madura do que “quantos tickets fechamos?”:

O que acontece com uma necessidade do usuário desde o momento em que ela entra na TI até o momento em que o valor é efetivamente entregue?

Essa pergunta parece simples. Na prática, ela abre o capô inteiro da operação — e o que aparece lá dentro raramente é o que está no fluxograma da política interna.

---

Parte I — Por que a operação corre o dia inteiro e avança pouco

1. O chamado não é o trabalho: é o registro de uma necessidade

Quando um usuário abre um ticket porque não consegue acessar o ERP, ele não quer um número de protocolo. Ele quer voltar a trabalhar. Quando um novo colaborador precisa de conta, permissões, notebook e acesso aos sistemas, o negócio não está pedindo quatro tarefas administrativas; está pedindo que aquela pessoa esteja operacional no primeiro dia. Quando um servidor deixa de responder, o valor não está em classificar corretamente a categoria do incidente, mas em restaurar a capacidade do serviço com o menor impacto possível.

Essa distinção não é filosófica. Ela é o primeiro princípio do Lean Thinking: valor se define pela perspectiva de quem recebe o serviço, não pela perspectiva de quem o executa. James Womack e Daniel Jones organizaram esse pensamento em cinco movimentos — especificar valor, identificar o fluxo de valor, fazer o trabalho fluir, permitir que a demanda puxe o trabalho e perseguir continuamente a melhoria.[1]

Aplicado à TI, isso troca o objeto da análise. Em vez de começar perguntando quantos tickets a equipe fechou, começamos perguntando quanto tempo a necessidade levou para atravessar o sistema, quantas vezes mudou de responsável, quanto tempo ficou parada esperando alguma coisa e se a solução eliminou a causa ou apenas empurrou o problema para a próxima semana.

O ticket, portanto, é uma representação digital do trabalho. Ele guarda evidências sobre uma necessidade, os atores envolvidos, as decisões tomadas, os tempos consumidos e o desfecho. O valor não está no registro; está na transformação que acontece entre a abertura e o resultado.

Parece conceitual, mas muda completamente a forma de olhar para o GLPI. Se eu trato a ferramenta como repositório de chamados, olho para contagens. Se a trato como instrumento de observação de um sistema de serviços, começo a procurar comportamento.

E comportamento de sistema aparece em padrões: filas que crescem sempre no mesmo grupo, categorias que concentram reincidência, tickets que passam dias em “Pendente”, solicitações que exigem quatro transferências, SLA que vence mesmo com quarenta minutos de execução técnica e problemas que voltam porque a organização aprendeu a restaurar o serviço, mas nunca a remover a causa.

2. A fábrica invisível dentro do Service Desk

Uma forma útil de enxergar uma central de atendimento é imaginar que cada ticket seja uma caixa física.

O usuário abre o chamado e uma caixa entra pela porta da TI. Ela passa pela triagem e vai para uma prateleira. Um técnico a pega, analisa e percebe que o assunto pertence a outro grupo. A caixa muda de prateleira. O segundo grupo identifica que falta uma informação. A caixa vai para a área de espera. O usuário responde no dia seguinte. A caixa volta para a fila. Depois aparece uma aprovação. Mais espera. Finalmente alguém executa vinte minutos de trabalho e conclui uma necessidade que permaneceu quatro dias dentro da organização.

Agora imagine essas caixas empilhadas no corredor. Trezentas delas, ocupando espaço físico, atrapalhando a passagem, com etiquetas amarelando. Nenhum gestor no mundo passaria por esse corredor duas vezes sem perguntar o que está acontecendo.

O problema é que, no sistema digital, o corredor não existe. Trezentos itens parados viram um número discreto no canto do dashboard, e números discretos são fáceis de normalizar.

No Lean, o trabalho que já entrou no processo e ainda não saiu chama-se work in progress (WIP). Em serviços, esse WIP assume a forma de tickets novos, atribuídos, em atendimento, aguardando usuário, aguardando fornecedor, aguardando aprovação ou tecnicamente resolvidos mas ainda não encerrados. O que importa entender é que cada item em andamento ocupa espaço cognitivo, administrativo ou operacional dentro do sistema — mesmo quando ninguém está trabalhando nele.

Isso não significa que todo WIP seja ruim. Um sistema sem trabalho em andamento também não entrega nada. O problema aparece quando o volume liberado para o fluxo supera, de forma persistente, a capacidade de processamento, ou quando o próprio desenho do processo cria espera entre etapas.

A partir daqui a discussão deixa de ser “gestão de chamados” e entra em terreno mais técnico: teoria das filas e gestão de fluxo.

3. WIP, throughput e lead time: a matemática que explica a fila

John D. C. Little demonstrou uma das relações mais importantes da teoria das filas. A Lei de Little pode ser escrita assim:

L = λ × W

Em leitura operacional para um Service Desk:

WIP médio = throughput médio × lead time médio

onde WIP é a quantidade média de itens dentro do sistema, throughput é a taxa média de conclusão e lead time é o tempo médio que uma demanda passa no sistema.[3][4]

A fórmula é simples. A interpretação exige cuidado.

A Lei de Little não diz que apagar tickets da fila reduz magicamente o tempo de atendimento. Ela descreve uma relação entre médias de longo prazo, em um sistema observado sob condições adequadas de estabilidade, com entradas e saídas contabilizadas de forma consistente. Se a demanda está explodindo, se o período observado mistura operações completamente diferentes ou se “conclusão” significa três coisas distintas dependendo do técnico, usar a fórmula como slogan produz mais confusão do que análise.

Mas, aplicada com honestidade, ela oferece uma lente poderosa.

Imagine uma central relativamente estável que conclua, em média, 50 tickets por dia útil e mantenha um WIP médio de 300 tickets. A relação aponta um lead time médio próximo de seis dias úteis:

Lead time médio = 300 / 50 = 6 dias úteis

Agora imagine que, depois de redesenhar formulários, reduzir transferências, retirar aprovações sem função clara e atacar uma causa importante de reincidência, a operação mantenha throughput semelhante, mas o WIP médio caia para 200:

Lead time médio = 200 / 50 = 4 dias úteis

Olhe com atenção para o que aconteceu. Ninguém digitou mais rápido. Ninguém trabalhou mais horas. O tempo de entrega caiu um terço porque o sistema deixou de manter tanto trabalho parado dentro dele.

Essa é a diferença entre otimizar pessoas e otimizar fluxo. Uma gestão orientada à ocupação tenta manter todos os recursos permanentemente cheios de tarefas. Uma gestão orientada ao fluxo se preocupa com o tempo que a demanda passa esperando entre as etapas — que, na maioria das operações que já vi, é a maior parte do tempo total.

4. Por que “todo mundo está 100% ocupado” costuma ser um péssimo sinal

Aqui está a contradição que mais incomoda quem vem de uma cultura de produtividade individual: uma equipe pode estar completamente ocupada e, ao mesmo tempo, entregando mal.

Pense em um técnico com quarenta tickets atribuídos. Ele não trabalha em quarenta coisas. Ele trabalha em duas ou três e mantém as outras trinta e sete em uma fila pessoal, invisível para o resto da organização. O sistema não distribuiu trabalho; distribuiu backlog. E cada retomada custa alguns minutos de releitura, reconstrução de contexto e verificação do que já foi feito.

Se essa descrição soou familiar, é porque ela é exatamente o thrashing de um sistema operacional: a máquina passa mais tempo trocando páginas entre memória e disco do que executando programas. Uso alto, trabalho útil baixo. Escrevi sobre esse mecanismo em detalhe no artigo Sob o Capô da Máquina, e a semelhança não é coincidência: filas de trabalho se comportam de maneira parecida, independentemente de quem executa o trabalho ser silício ou gente.

Existe uma segunda razão, menos intuitiva e mais importante, para desconfiar da ocupação máxima: variabilidade.

Chamados não chegam em intervalos regulares e não custam o mesmo esforço. Um reset de senha consome minutos; um incidente de ERP mobiliza várias pessoas por horas. A literatura de teoria das filas mostra que, à medida que a taxa de utilização se aproxima da capacidade, o tempo de espera não cresce de forma proporcional — ele dispara. A aproximação de Kingman para filas gerais deixa isso explícito: a espera é função conjunta da variabilidade, da utilização e do tempo de serviço, e o termo de utilização cresce de forma acelerada perto do limite.[13][14]

Traduzindo para o corredor da TI: uma operação a 70% de utilização absorve um pico e volta ao normal no mesmo dia. A 95%, o mesmo pico vira uma semana de atraso — porque não sobrou folga nenhuma para recuperar o terreno perdido.

É por isso que “todo mundo está 100% ocupado” não deve ser lido automaticamente como excelência operacional. Em sistemas com variabilidade alta — e suporte de TI é um dos mais variáveis que existem —, ocupação máxima costuma significar ausência de capacidade de absorção. A fila já começou; ela só ainda não apareceu no relatório.

---

Parte II — O desperdício que nenhum balanço mostra

5. Lean não procura pessoas mais rápidas; procura um sistema com menos desperdício

Lean costuma ser reduzido a uma frase perigosa: “fazer mais com menos”. A expressão é ótima para planilha de corte de custo e péssima para entender o conceito.

O Lean Thinking, desenvolvido a partir das práticas do Sistema Toyota de Produção, está interessado na criação de valor e na eliminação sistemática do que impede esse valor de fluir: espera, retrabalho, excesso de processamento, estoques desnecessários, movimentação inútil, defeitos. O objetivo não é acelerar qualquer atividade. É questionar por que determinadas atividades, filas e correções existem.[1]

Em uma fábrica, o desperdício é visível: peças paradas entre duas operações, gente andando de um lado para o outro. Em TI, ele aparece como informação parada — e informação parada não ocupa espaço no chão.

A tradução direta das categorias clássicas para uma central de atendimento é reveladora:

Repare que a coluna mais importante é a terceira. Cada tipo de desperdício deixa um rastro diferente, e nem todos estão dentro da ferramenta: a última linha só aparece se você sentar do lado de quem executa o trabalho. Nenhum dashboard percebe um técnico abrindo cinco abas para resolver um chamado.

O que torna esse custo tão difícil de combater é que ele nunca aparece como linha no balanço. Ele é pago em parcelas pequenas: minutos de técnico, horas de usuário, interrupções, cobranças, escalonamentos, reuniões de alinhamento, atrasos de projeto e perda gradual de confiança na TI. Como o custo está diluído no cotidiano, ele passa a parecer “o jeito normal de trabalhar”.

E é justamente por isso que melhorar um processo começa por torná-lo visível.

6. Mapeamento de fluxo de valor: desenhar o que acontece, não o que deveria acontecer

O Value Stream Mapping (VSM) é a prática Lean usada para visualizar as etapas e os fluxos de informação necessários para levar uma demanda da origem até a entrega. A diferença em relação a um fluxograma comum é que o VSM procura representar o estado atual real, incluindo onde o fluxo para, acumula, volta ou depende de informação externa, antes de qualquer proposta de estado futuro.[2]

Essa diferença é especialmente importante em TI, porque processo documentado costuma ser bem mais limpo do que processo executado.

No documento, uma solicitação de acesso aparece assim:

Solicitação -> Aprovação -> Execução -> Validação -> Encerramento

Está correto, e não diz absolutamente nada sobre desempenho. Agora observe o mesmo fluxo com os tempos reais:

Solicitação
   | 14 h de espera
Triagem - 6 min de trabalho
   | 9 h de espera
Aprovação - 3 min de decisão
   | 17 h de espera
Execução - 18 min de trabalho
   | 5 h de espera
Validação - 4 min de trabalho
Encerramento

Some as duas colunas mentalmente. O tempo efetivamente trabalhado não chega a uma hora. O tempo atravessando o sistema passa de dois dias úteis. Mais de 95% da experiência do usuário foi espera.

Aqui aparece a distinção que qualquer gestão de serviços deveria ter tatuada: tempo de processamento não é lead time.

Se eu medir apenas o esforço técnico, concluo que a atividade é eficiente e vou embora satisfeito. Se eu medir o tempo total percebido pelo usuário, descubro que a maior parte da entrega é fila.

E isso reordena completamente as prioridades. Pedir ao técnico que execute em 15 minutos a tarefa de 18 minutos economiza três minutos em dois dias. Entender por que a aprovação demora 17 horas pode economizar um dia inteiro — e ninguém precisou correr.

O VSM também protege contra um erro clássico: otimizar uma etapa e piorar o sistema. Uma equipe pode se tornar excelente em classificar tickets e despejá-los rapidamente no grupo seguinte, melhorando o próprio indicador enquanto congestiona a etapa vizinha. Para a primeira equipe, o gráfico melhorou. Para o usuário, nada mudou. É otimização local com prejuízo global, e ela é surpreendentemente comum em operações organizadas por métricas de time.

Fluxo de valor obriga a olhar de ponta a ponta. Essa é a razão de ele existir.

---

Parte III — A ferramenta como instrumento de medida

7. O GLPI como telemetria da operação

É neste ponto que o GLPI passa a ter um papel mais interessante do que guardar chamados.

A documentação oficial descreve o módulo de Assistance como responsável por criar, acompanhar e processar tickets, além de suportar problemas, mudanças, planejamento e estatísticas.[5] No ticket, o sistema registra atores, entidade, categoria, urgência, impacto, prioridade, itens relacionados, níveis de serviço, datas, tarefas, acompanhamentos, solução e histórico.[6] Dependendo de como a implantação foi desenhada, esse conjunto vira uma trilha rica do comportamento operacional.

O “dependendo de como foi desenhada” não é ressalva educada. É o ponto central: ferramenta nenhuma cria qualidade de dado por decreto.

Se quase todos os chamados caem em “Outros”, a organização perdeu capacidade analítica antes de começar. Se impacto e urgência são preenchidos por conveniência, prioridade passa a representar preferência, não risco. Se “Pendente” virou estacionamento genérico, o tempo de espera deixa de explicar a realidade. Se a solução registrada é “resolvido” ou “ok, feito”, a base histórica guarda encerramentos, mas não guarda conhecimento — e daqui a seis meses ninguém vai lembrar o que foi feito.

Um dashboard transforma dados ruins em gráficos impecáveis. Isso não os torna verdadeiros. É provavelmente a forma mais cara de estar errado com confiança.

Por isso, antes de falar em Metabase, Power BI, IA ou qualquer camada analítica, é preciso definir a semântica operacional dos registros. Uma categoria precisa representar algo que a gestão pretende compreender. Um status precisa significar uma condição real do trabalho. Uma pendência precisa ter motivo rastreável. Uma transferência precisa acontecer porque a responsabilidade mudou, não porque ninguém sabia para onde mandar o ticket.

Quando essa disciplina existe, o GLPI começa a funcionar como telemetria da operação. E telemetria é o termo certo: cada ticket individual conta uma história, e o conjunto revela o comportamento do sistema — que é uma coisa completamente diferente.

Na prática, três trilhas sustentam quase toda a análise de fluxo que vale a pena fazer: as datas do ticket (abertura, primeira atribuição, solução, encerramento), o histórico de alterações, que preserva mudanças de grupo, de status e de responsável, e os registros de pendência, que mostram quando e por que o relógio parou. Antes de montar qualquer indicador em cima disso, confirme na sua versão do GLPI quais campos são efetivamente preenchidos no seu ambiente — versões, plugins e regras de negócio mudam bastante o que sobra registrado.

8. SLA mede compromisso; não mede sozinho a qualidade do fluxo

Service Level Agreement é indispensável em operações que precisam explicitar níveis de serviço. No GLPI, o SLA controla dois relógios — Time To Own (TTO), o tempo máximo até o ticket ter um técnico atribuído, e Time To Resolve (TTR), o tempo máximo até a resolução. A ferramenta também suporta OLA, o acordo equivalente entre grupos internos, além de calendários e níveis de escalonamento.[7]

O problema começa quando o SLA é tratado como sinônimo de eficiência.

Imagine um ticket com TTR de oito horas resolvido em sete horas e cinquenta minutos. O indicador fica verde, o relatório mensal agradece. Agora imagine que, dessas sete horas e cinquenta minutos, apenas quarenta minutos foram trabalho efetivo, e todo o resto foi fila, transferência e espera por uma informação que poderia ter sido capturada no formulário de abertura.

O compromisso foi cumprido. O fluxo continua ruim. As duas afirmações são verdadeiras ao mesmo tempo, e é exatamente essa convivência que faz o SLA ser um indicador tão confortável.

Vale conhecer alguns detalhes de implementação, porque o comportamento do relógio depende da configuração — e configuração mal compreendida vira indicador enganoso:

• Pendência suspende a contagem. Colocar o ticket em status pendente coloca o SLA em modo de espera; se ele ficar três horas pendente, a data limite é adiada em três horas.[7] Isso é legítimo quando a pausa representa dependência real fora do alcance do provedor. Vira maquiagem quando “Pendente” é usado para tirar ticket da zona de risco.
• Calendário muda tudo. Por padrão, o cálculo é feito 24 horas por dia, sete dias por semana, a menos que um calendário seja associado ao SLA ou herdado da entidade.[7] Uma operação que atende em horário comercial e esqueceu o calendário está medindo prazos que ninguém prometeu cumprir de madrugada.
• Dias e horas não se comportam igual. Prazo expresso em dias é calculado em dias úteis; prazo expresso em horas respeita o horário de funcionamento. Um SLA de quatro horas com atendimento das 8h às 18h, acionado às 16h, vence às 10h do dia seguinte.[7]
• Atribuição manual vence a regra. Se o SLA for atribuído manualmente na abertura ou por template, as regras de negócio não conseguem redefini-lo.[7] É uma fonte silenciosa de inconsistência em bases grandes.

Esses detalhes mostram por que governança de dado e desenho de processo não podem ser separados. Se o status não representa fielmente a realidade, o indicador passa a medir a regra do sistema, não a experiência do usuário.

A pergunta madura, portanto, não é “qual foi nosso percentual de SLA?”. É um conjunto maior: qual foi o lead time? Quanto dele foi espera? Onde essa espera aconteceu? Quantos tickets ficaram raspando no limite? Quais categorias concentram violação? Em quais grupos as transferências se acumulam? O mesmo serviço volta a gerar demanda depois de marcado como resolvido?

SLA continua necessário. Ele só precisa ocupar o lugar certo: medir compromisso de serviço, não substituir análise de fluxo.

---

Parte IV — Restaurar o serviço não é eliminar a causa

9. Incidente, problema e mudança: três responsabilidades diferentes

Outra fonte clássica de desperdício é confundir restauração com solução estrutural.

Um sistema para de responder. A equipe reinicia o serviço, os usuários voltam a trabalhar, o incidente é encerrado. No dia seguinte, o mesmo comportamento. Reinicia de novo. Uma semana depois, repete. No fim do mês, o relatório exibe vinte incidentes resolvidos dentro do SLA e uma equipe elogiada pela agilidade.

Operacionalmente, a restauração foi bem executada. Gerencialmente, existe uma pergunta sem resposta: por que o serviço continua falhando?

É nessa separação que Incident Management e Problem Management deixam de parecer vocabulário de certificação e passam a representar responsabilidades distintas. Incidente está associado a restaurar o serviço afetado o mais rápido possível. Problema procura compreender e administrar causas capazes de produzir um ou vários incidentes. E a mudança é o mecanismo controlado para alterar infraestrutura, software, configuração ou processo.[8]

O GLPI permite relacionar as três coisas. A documentação de Changes inclui análise de impacto, itens relacionados, plano de implantação, plano de recuo e associação com tickets e problemas.[8] Quando esse relacionamento é usado com propósito, a ferramenta deixa de ser um arquivo de ocorrências isoladas e passa a registrar uma cadeia de aprendizado:

Incidentes recorrentes
        ↓
Padrão identificado
        ↓
Problema investigado
        ↓
Causa ou condição contribuinte compreendida
        ↓
Mudança planejada e controlada
        ↓
Redução da recorrência
        ↓
Capacidade devolvida à operação

Olhe a última linha, porque é ela que muda a conversa com a diretoria. Remover uma causa recorrente não melhora só qualidade. Libera capacidade.

Se uma falha gera cem tickets por mês e cada um consome quinze minutos entre triagem, comunicação e execução, a organização gasta aproximadamente 25 horas mensais tratando efeito. É meia pessoa por mês, todo mês, indefinidamente. Eliminar a causa devolve esse tempo à equipe sem contratar ninguém — e, diferente de um pedido de headcount, essa é uma conta que qualquer gestor financeiro entende na primeira apresentação.

10. ITIL em 2026: de gestão de chamados para valor em produtos digitais

Vale atualizar a referência conceitual, porque ela mudou recentemente.

Em fevereiro de 2026, a PeopleCert lançou o ITIL (Version 5), começando pelo nível Foundation, com os módulos avançados sendo liberados de forma escalonada ao longo do ano. A nova versão se apresenta como evolução, não como ruptura: mantém continuidade com o conhecimento anterior e reforça gestão de produtos e serviços digitais, ciclo de vida integrado, criação mensurável de valor e o contexto de operações apoiadas por IA. As certificações ITIL 4 continuam válidas e o esquema anterior segue disponível durante a transição.[9]

Essa direção importa para o argumento deste artigo porque confirma algo que já deveria ser natural em uma operação madura: Service Management não pode ser reduzido à administração de filas de suporte.

Tickets são uma das melhores fontes de informação sobre a experiência real de um serviço. Eles mostram onde o usuário encontra fricção, onde o produto falha, quais capacidades internas não acompanham a demanda, onde fornecedores introduzem espera e quais áreas dependem de conhecimento que ainda mora na cabeça de uma pessoa só.

Quando o objetivo deixa de ser “fechar tickets” e passa a ser gerenciar valor e desempenho de serviços, Lean e ITIL param de parecer abordagens concorrentes. Lean oferece uma lente forte para fluxo, desperdício e melhoria. ITIL oferece uma arquitetura de práticas e princípios para gerenciar produtos e serviços. O GLPI oferece o mecanismo operacional para registrar e coordenar parte desse trabalho. A camada analítica transforma registro em evidência. Nenhuma dessas peças substitui as outras, e quem tenta usar uma no lugar das demais costuma descobrir isso do jeito caro.

11. Failure demand: quando a própria organização fabrica parte da demanda

Existe uma pergunta que deveria aparecer em todo relatório de Service Desk e quase nunca aparece:

Quanto da nossa demanda só existe porque falhamos antes em fazer algo, ou em fazer algo direito?

John Seddon popularizou o conceito de failure demand em organizações de serviço: demanda adicional gerada porque o sistema falhou em atender corretamente uma necessidade anterior.[10]

Em TI, ela tem endereço conhecido. O usuário abre um novo chamado porque a primeira solução não funcionou. O colaborador pede de novo um acesso porque o perfil foi provisionado errado. O gestor liga cobrando porque o ticket não recebeu atualização nenhuma em três dias. Um sistema gera incidentes repetidos porque a causa nunca foi investigada. O processo de onboarding esquece uma permissão, e cada novo funcionário abre uma demanda corretiva no segundo dia de trabalho.

Esses tickets entram no mesmo GLPI, consomem a mesma capacidade e — esta é a parte perversa — melhoram a estatística de “quantidade resolvida”. Mas eles têm natureza diferente. Parte da demanda representa necessidade legítima do negócio; outra parte representa trabalho criado pela ineficácia do próprio sistema.

Essa distinção desmonta um indicador extremamente sedutor: produtividade medida por volume fechado.

Se uma equipe conclui 1.500 chamados por mês e 400 deles são reincidência, retrabalho ou correção de falha de processo, aumentar a capacidade de fechamento sem atacar a origem torna a operação mais rápida em processar trabalho que ela não deveria ter recebido.

Não existe medalha estratégica por resolver com agilidade um problema que poderia simplesmente não existir.

---

Parte V — Medir o sistema, não a competição entre técnicos

12. O dashboard que mede saúde da operação

Painéis de suporte frequentemente começam pela pergunta errada: quem fechou mais chamados?

O dado tem alguma utilidade operacional, mas é fraco como medida de desempenho e péssimo como instrumento de comparação. Dois técnicos podem trabalhar em universos diferentes: um recebe solicitações padronizadas de baixo esforço, outro sustenta aplicações críticas, depende de fornecedor e executa diagnósticos longos. Contar tickets sem considerar natureza, complexidade e fluxo produz um ranking que parece objetivo e não é.

Uma visão mais robusta separa indicadores por função gerencial.

Nenhuma dessas linhas significa muita coisa sozinha. A utilidade aparece na leitura conjunta.

Um backlog de 400 tickets não diz se a operação melhora ou piora. Se entram 60 por dia e saem 65, o estoque cai. Se entram 60 e saem 50, o sistema acumula dez por dia — e vai acumular até alguém intervir. Se o WIP total está estável mas a idade dos itens mais antigos cresce, existe alguma classe de serviço sendo sistematicamente abandonada enquanto os itens fáceis passam na frente. Se o SLA está alto, mas a satisfação caiu e as reaberturas subiram, existe uma dimensão de qualidade que o contrato de prazo não captura.

É esse tipo de leitura que uma camada como Metabase pode oferecer sobre os dados do GLPI. O valor não está no gráfico bonito. Está na capacidade de formular perguntas que o gráfico ajuda a responder.

13. Aging: o problema que ainda não virou atraso no relatório mensal

Lead time só existe quando o item termina. Um ticket ainda aberto não tem lead time; tem idade.

A diferença parece técnica e tem enorme valor de gestão. Se os tickets de determinado serviço normalmente terminam em três dias e existe um item comparável aberto há quinze, esperar o fechamento para descobrir que ele foi um caso extremo é administrar olhando pelo retrovisor.

A análise de aging olha para o trabalho que ainda está vivo dentro do sistema. Em vez de perguntar apenas “quantos tickets estão abertos?”, a gestão passa a observar a distribuição de idade: quantos têm menos de um dia, de um a três, de três a cinco, de cinco a dez, acima disso; quais categorias concentram itens antigos; quais grupos têm cauda longa; quais pendências estão paradas sem nenhum evento recente.

Essa perspectiva importa porque médias escondem extremos. Uma operação pode exibir lead time médio perfeitamente aceitável e manter, no mesmo período, um conjunto pequeno de tickets muito antigos que representam usuários esquecidos, dependências quebradas ou ausência de dono. São poucos itens, mas são exatamente os que produzem a frase “a TI não resolve nada” na reunião de diretoria.

Boa gestão de fluxo não olha só para o centro da distribuição. Olha para a cauda.

14. Transferências: cada handoff é uma fronteira organizacional

Quando um ticket passa por cinco grupos, é tentador enxergar cinco registros no histórico. Eu prefiro enxergar cinco fronteiras.

Toda transferência tem custo. Alguém precisa interpretar o contexto, concluir que não é responsável, descobrir o próximo destino, repassar informação e permitir que outra pessoa reconstrua parte do entendimento do zero. Às vezes isso é inevitável, porque o trabalho realmente depende de especialidades diferentes. Em outros casos, a transferência existe porque a entrada foi mal desenhada, as responsabilidades são ambíguas ou a organização fragmentou um serviço que, do ponto de vista do usuário, é único.

Por isso a métrica “transferências por ticket” é reveladora quando cruzada com categoria e serviço. Se uma categoria específica apresenta sistematicamente mais handoffs, não adianta culpar a triagem. É preciso investigar se a taxonomia está coerente, se o catálogo de serviços é compreensível para quem não é da TI, se os formulários capturam as informações certas e se as fronteiras entre grupos fazem algum sentido para o fluxo.

O histórico do GLPI, quando bem alimentado, mostra essas trajetórias. O objetivo não é eliminar toda transferência a qualquer custo — algumas agregam especialidade genuína. O objetivo é encontrar as transferências que não acrescentam nem conhecimento nem execução, apenas tempo.

---

Parte VI — Da causa à mudança

15. Cinco Porquês: causa raiz não é sinônimo de “erro humano”

Uma das formas mais comuns de interromper uma investigação cedo demais é encerrá-la com uma frase do tipo “o usuário preencheu errado”, “o técnico esqueceu” ou “faltou atenção”. Essas frases descrevem eventos. Elas quase nunca explicam o sistema que tornou o evento provável.

A prática dos 5 Whys é uma forma simples de insistir na cadeia causal até ultrapassar o sintoma. O próprio Lean Enterprise Institute enfatiza que o número cinco não é regra matemática: o objetivo é continuar perguntando até chegar a uma causa ou condição sobre a qual seja possível agir para evitar recorrência.[11]

Considere um caso de onboarding.

O novo colaborador abriu chamado porque não tinha acesso ao sistema financeiro. Por quê? Porque a permissão não foi solicitada no processo de admissão. Por quê? Porque o formulário de onboarding não contempla o sistema financeiro para aquela função. Por quê? Porque o formulário foi criado antes da reorganização da área. Por quê? Porque não existe responsável definido por revisar o catálogo de acessos quando cargos e responsabilidades mudam.

A primeira resposta produz uma correção local: conceder o acesso e fechar o ticket.

A investigação produz uma intervenção sistêmica: revisar o processo de admissão e definir governança para manutenção dos perfis.

Repare que em nenhum dos cinco passos apareceu alguém para culpar. Isso não é gentileza corporativa; é precisão técnica. “Erro humano” costuma ser o ponto onde a investigação para, não o ponto onde ela chega.

O ticket é o sintoma. A melhoria acontece quando a organização aprende a enxergar o mecanismo que o produziu.

16. Padronização não significa congelar o trabalho

Outro equívoco recorrente é associar padronização a burocracia. Se o padrão for regra rígida, desconectada da realidade e imposta para controlar pessoas, a crítica procede. Mas esse não é o papel do standardized work no pensamento Lean.

O Lean Enterprise Institute descreve trabalho padronizado como forma de documentar o método atual, reduzir variabilidade, facilitar treinamento e criar base explícita para melhoria contínua. O padrão é a melhor forma conhecida neste momento, não uma verdade permanente.[12] Sem padrão, aliás, não existe melhoria mensurável: você não consegue provar que mudou nada se não sabe o que fazia antes.

Em TI a aplicação é direta.

Se a organização tem uma forma validada de restaurar determinado serviço, esse conhecimento não deveria morar apenas na memória do técnico que “sabe resolver”. Se uma análise de incidente recorrente identificou verificações confiáveis, elas deveriam virar procedimento. Se uma solução exige sequência consistente de passos e critérios, registrar essa sequência reduz variabilidade e acelera a formação de quem chega. A própria documentação do GLPI permite relacionar artigos da base de conhecimento a contextos de atendimento e mudança.[8]

A maturidade aparece quando o conhecimento deixa de ser propriedade de indivíduos e vira capacidade da organização.

E isso não diminui especialistas — faz o oposto. Libera os especialistas de repetir indefinidamente o que já é conhecido, para que possam trabalhar naquilo que ainda exige julgamento, investigação e criação. Ninguém deveria passar o quinto ano de carreira executando o mesmo procedimento que poderia estar documentado desde o primeiro.

17. Automatizar antes de entender é industrializar o erro

Automação é sedutora porque produz sensação imediata de modernização. Bots, APIs, IA, scripts, n8n, integrações e regras automáticas realmente reduzem esforço e tempo. Mas existe uma ordem lógica que não deveria ser invertida.

Primeiro entenda a demanda e o fluxo. Depois elimine as etapas sem valor. Em seguida simplifique o que restou, padronize o que é repetível e só então automatize aquilo cuja lógica já é suficientemente conhecida.

Considere um formulário que recebe solicitações mal classificadas. É possível construir um modelo de IA para inferir a categoria e encaminhar o ticket automaticamente. Talvez seja uma boa solução. Mas talvez a análise mostre que o problema está no desenho do catálogo: o usuário está sendo obrigado a escolher categorias técnicas que não correspondem à forma como ele percebe o serviço.

Nesse caso, automatizar a classificação trata o sintoma com elegância. Redesenhar a entrada remove a ambiguidade — e ainda economiza o modelo, o treinamento e a manutenção de mais uma peça no ambiente.

A sequência que considero mais segura é esta:

Entender a demanda
      ↓
Observar o fluxo real
      ↓
Eliminar desperdício evidente
      ↓
Simplificar decisões e handoffs
      ↓
Padronizar o que é repetível
      ↓
Medir o novo comportamento
      ↓
Automatizar onde houver ganho real
      ↓
Medir novamente

Automação é multiplicador de um processo compreendido. Quando aplicada sobre um processo confuso, ela multiplica a confusão — só que mais rápido e com menos gente disponível para perceber.

---

Parte VII — Método, evidência e limites

18. Um método prático para sair do “achismo” usando GLPI

Se eu tivesse que iniciar uma revisão de processo em uma operação real de Service Desk, não começaria redesenhando fluxos nem criando cem indicadores. Começaria construindo um baseline confiável, porque sem ele qualquer melhoria posterior vira questão de opinião.

O primeiro passo é escolher uma família de demanda com relevância suficiente para ser estudada: acessos, ERP, onboarding, rede, impressão ou uma aplicação específica. O objetivo é evitar misturar trabalhos com comportamentos completamente diferentes e depois interpretar a média resultante como se fosse um processo só. Média de reset de senha com incidente de ERP não descreve nem um nem outro.

O segundo passo é mapear o fluxo atual com as pessoas que executam o trabalho. Não o fluxo da política interna: o caminho que tickets reais percorreram. Para uma amostra, reconstrua abertura, triagem, atribuições, pendências, aprovações, tarefas, transferências, solução e fechamento. O histórico do GLPI serve como evidência, complementado por observação e conversa com a equipe — porque nem todo desperdício deixa rastro em campo de sistema.

O terceiro passo é medir quatro dimensões em conjunto: demanda, fluxo, qualidade e experiência. Demanda mostra o que entra. Fluxo mostra o que acontece entre entrada e saída. Qualidade mostra recorrência, reabertura e eficácia da solução. Experiência mostra a percepção de quem recebeu o serviço. Medir só uma delas produz conclusões confortáveis e erradas.

Somente então procure as restrições relevantes. Se a maior parcela do lead time está antes da primeira atribuição, o problema é de entrada e roteamento. Se o trabalho começa rápido e trava em aprovação, o problema é de governança. Se os tickets percorrem muitos grupos, o problema é de fronteira organizacional. Se a demanda é dominada por reincidência, aumentar throughput pode ser menos valioso do que remover a causa. Cada um desses diagnósticos leva a uma intervenção diferente, e é por isso que receita pronta não funciona.

O estado futuro nasce dessa evidência. Alguns fluxos precisam de menos etapas. Outros precisam de regras de entrada melhores, matriz clara de responsabilidade, OLA entre grupos, templates, base de conhecimento, automação ou revisão de SLA.

Por fim, repita a medição. Se o novo processo realmente melhorou, o comportamento muda de forma coerente: queda de WIP ou de aging, redução de transferências, menor reincidência, maior previsibilidade, menos espera, melhor experiência. Se nada disso se move, a organização não “implementou Lean”. Ela apenas redesenhou um diagrama.

19. Estudo hipotético: quando contratar não é a primeira resposta

O caso a seguir é fictício e serve apenas para tornar o mecanismo visível. Os números foram escolhidos para ilustrar a relação, não para representar uma operação real.

Considere uma central que recebe aproximadamente 1.200 tickets por mês. A percepção geral é de saturação: usuários reclamam de demora, técnicos relatam excesso de demanda e a gestão considera contratar duas pessoas.

Antes da decisão, a equipe analisa três meses de dados de uma família de serviços com comportamento relativamente estável. Encontra throughput médio de 55 tickets por dia útil e WIP médio próximo de 420 itens. Pela Lei de Little, esses valores são coerentes com um lead time médio de aproximadamente 7,6 dias úteis:

420 / 55 ≈ 7,6 dias úteis

A análise de fluxo mostra algo mais importante que o número. A execução técnica não ocupa a maior parte desse tempo. Muitos tickets passam períodos longos sem dono definido; uma categoria genérica provoca transferências; solicitações de acesso chegam sem dados obrigatórios e voltam ao usuário; uma aplicação específica gera incidentes recorrentes que são restaurados, mas nunca investigados.

A organização decide atacar esses mecanismos antes de ampliar o headcount. O formulário passa a capturar os dados necessários na origem. Regras de atribuição reduzem parte dos handoffs. A categoria genérica é desmembrada com base no comportamento real da demanda. Um problema é aberto para a aplicação reincidente, e uma mudança posterior elimina uma das causas. Pendências passam a exigir motivo e acompanhamento explícito.

Depois de um período de estabilização, o throughput permanece próximo de 55 por dia, mas o WIP médio cai para 250. Mantidas as condições de análise, a relação aponta lead time próximo de 4,5 dias úteis:

250 / 55 ≈ 4,5 dias úteis

Esse exemplo não prova que toda central reduzirá lead time em quarenta por cento sem contratar. Seria intelectualmente desonesto sugerir isso. O objetivo é mostrar o mecanismo: capacidade e fluxo são problemas diferentes, e só um deles se resolve com contratação.

Se, depois de remover os desperdícios relevantes, a chegada continuar estruturalmente acima da capacidade sustentável, ampliar a equipe pode ser exatamente a decisão certa. A diferença é que a contratação vai acontecer sobre um processo conhecido, com quantidade justificável, e não como tentativa de compensar um sistema que ninguém mediu.

20. Onde essa leitura falha: os limites honestos da abordagem

Seria fácil terminar o artigo aqui, com a impressão de que basta medir fluxo para tudo melhorar. Não é verdade, e ignorar os contrapontos tornaria este texto propaganda. Existem pelo menos cinco limites que merecem ser ditos em voz alta.

A Lei de Little exige condições que raramente são verificadas. Ela vale para médias de longo prazo em um sistema observado com fronteiras claras, entradas e saídas contabilizadas de forma consistente e ausência de tendência explosiva. Se sua base mistura serviços com comportamentos distintos, se tickets são fechados em massa em uma faxina de backlog ou se o critério de “conclusão” muda no meio do período, o resultado será um número bonito descrevendo coisa nenhuma. A fórmula é uma lente, não um oráculo.

Toda métrica de fluxo pode ser gamificada. A formulação mais conhecida do problema vem de Marilyn Strathern: quando uma medida vira meta, ela deixa de ser uma boa medida.[15] Se a organização passar a cobrar redução de WIP, alguém vai fechar tickets prematuramente. Se cobrar aging baixo, alguém vai fechar e reabrir. Se cobrar SLA, “Pendente” vira o status mais popular da empresa. Indicadores de fluxo servem para investigar comportamento, e não para ranquear pessoas — no momento em que viram avaliação individual, eles começam a medir a criatividade da equipe em contorná-los.

Reduzir WIP não cria capacidade. Melhorar fluxo aumenta a velocidade com que o trabalho atravessa o sistema, mas se a chegada média excede estruturalmente a capacidade média, nenhuma reorganização de fila resolve. Nesse cenário, as opções reais são aumentar capacidade, reduzir demanda na origem ou negociar escopo. Lean usado como argumento para não contratar é distorção do conceito, não aplicação dele.

Classificar failure demand envolve julgamento. A fronteira entre “o usuário não entendeu” e “o serviço foi mal desenhado” nem sempre é óbvia, e a classificação costuma refletir quem está classificando. Trate esses números como indicação de direção, não como medida exata, e revise os critérios periodicamente com pessoas de fora da equipe que os criou.

Serviço não é linha de montagem. Boa parte da variabilidade em TI é legítima: problemas realmente são diferentes entre si, e diagnóstico exige julgamento. Padronizar o que é repetível é saudável; tentar padronizar o que exige investigação produz procedimento inútil e profissional frustrado. O critério é simples de enunciar e difícil de aplicar: padronize o caminho conhecido, proteja o tempo de quem precisa pensar.

Nada disso invalida a abordagem. Apenas define onde ela funciona — que é exatamente o que se espera de qualquer decisão de engenharia.

21. De “quantos chamados fechamos?” para “o que essa demanda está nos ensinando?”

Existe uma progressão bem reconhecível na maturidade dos relatórios de TI.

No primeiro estágio, a organização conta volume: quantos tickets abriram, quantos fecharam. No segundo, mede compromisso: percentual de SLA, tempo médio, tickets vencidos. No terceiro, segmenta comportamento: categorias, serviços, áreas, grupos, reincidência, reabertura, aging. No quarto, conecta padrão a causa e a intervenção — uma mudança eliminou determinada recorrência, uma revisão de onboarding reduziu tickets corretivos, uma alteração de formulário removeu transferências, uma automação devolveu horas de capacidade.

É no quarto estágio que o dado deixa de ser relatório e vira aprendizado operacional.

A pergunta deixa de ser “quem fechou mais?” e passa a ser “por que esse trabalho existe?”.

Talvez seja a mudança mais importante deste artigo inteiro. Porque uma TI que mede apenas produção tende a se orgulhar de processar cada vez mais demanda. Uma TI que mede o sistema tenta entender quais demandas representam valor, quais são inevitáveis, quais poderiam ser prevenidas e quais denunciam falhas de produto, serviço ou processo.

O melhor ticket nem sempre é o resolvido em cinco minutos.

Em muitos casos, o melhor ticket é aquele que não vai precisar ser aberto de novo.

22. O papel real do GLPI em uma operação madura

Depois de tudo isso, vale voltar à ferramenta e ser justo com ela.

GLPI não é Lean. GLPI não é ITIL. GLPI não melhora fluxo sozinho e não transforma dado em decisão por conta própria. Qualquer fornecedor que prometa o contrário está vendendo outra coisa.

Mas, quando implementado com taxonomia coerente, estados que significam alguma coisa, responsabilidades claras, níveis de serviço bem definidos, disciplina de registro e integração com uma camada de análise, ele se torna uma fonte valiosa de evidência operacional.

Cada abertura mostra uma necessidade. Cada categoria mostra uma forma de demanda. Cada mudança de grupo mostra uma fronteira atravessada. Cada pendência mostra uma interrupção do fluxo. Cada reabertura questiona a qualidade da solução. Cada recorrência levanta uma hipótese sobre causa. Cada SLA vencido mostra um compromisso não cumprido. Cada solução bem documentada pode virar conhecimento reutilizável.

O ticket conta o que aconteceu com uma demanda.

O conjunto dos tickets conta como a organização se comporta diante das demandas.

Essa diferença é o que separa uma TI que administra registros de uma TI que aprende com o próprio trabalho.

---

Conclusão: apagar incêndio não pode ser o modelo operacional

Toda empresa conhece o profissional que salva o dia. O servidor cai e ele resolve. A integração quebra e ele sabe onde olhar. O ERP trava e ele encontra um caminho. Esse conhecimento é valioso e merece reconhecimento.

O problema começa quando o funcionamento da organização depende permanentemente desse tipo de heroísmo. Heroísmo não escala, não tira férias e, mais cedo ou mais tarde, aceita uma proposta melhor.

Uma operação madura não elimina especialistas; elimina a necessidade de gastar especialistas repetindo emergências evitáveis. Ela transforma conhecimento em padrão, recorrência em problema, problema em aprendizado, aprendizado em mudança e mudança em redução de demanda futura.

Lean ajuda a enxergar valor, desperdício e fluxo. A teoria das filas explica o comportamento do trabalho em andamento. ITIL oferece um sistema de práticas para gerenciar produtos e serviços. GLPI registra parte importante da realidade operacional. Metabase, Power BI ou outra camada analítica tornam padrões visíveis. Nenhuma dessas ferramentas substitui julgamento técnico, liderança ou entendimento do negócio — e todas elas juntas ainda dependem de alguém disposto a olhar para um número desconfortável sem procurar culpado.

A maturidade aparece quando elas se conectam em um ciclo coerente:

Observar a demanda
      ↓
Entender o fluxo
      ↓
Medir o comportamento
      ↓
Investigar causas
      ↓
Redesenhar o sistema
      ↓
Padronizar o aprendizado
      ↓
Automatizar o que faz sentido
      ↓
Medir novamente

No fim, a pergunta que mais me interessa não é quantos chamados uma TI consegue fechar.

É outra:

O que o volume, o tempo, as transferências, as reincidências e as falhas registradas no Service Desk estão ensinando sobre a forma como a empresa trabalha?

Quando a organização consegue responder isso com dados e agir sobre a resposta, o Service Desk deixa de ser apenas o lugar onde os problemas chegam.

Ele passa a ser um dos lugares onde a empresa aprende por que os problemas existem e como evitar que voltem.

E essa é a diferença entre uma TI ocupada e uma TI que gera valor.

Se você quiser começar por algum lugar nesta semana, comece pequeno: escolha uma única categoria de chamado, meça quanto do lead time dela é espera e descubra onde essa espera acontece. Você provavelmente vai encontrar um dia inteiro escondido entre duas etapas que ninguém nunca cronometrou.

---

FAQ

Por onde começar se a base do GLPI está bagunçada?
Não tente corrigir tudo. Escolha uma família de demanda relevante e razoavelmente homogênea, garanta que categoria, status e pendência signifiquem algo consistente nela, e construa o baseline só desse recorte. Base histórica ruim não se conserta retroativamente; ela se conserta a partir de hoje, com regra clara de preenchimento e revisão periódica. Em geral é mais rápido chegar a um dado confiável em uma categoria do que a um dado medíocre em todas.

Dá para medir lead time e espera sem ferramenta de BI?
Dá, e vale começar assim. As datas de abertura, atribuição, solução e encerramento, somadas ao histórico de mudanças, já permitem reconstruir manualmente uma amostra de trinta a cinquenta tickets em planilha. A amostra manual costuma ensinar mais que o primeiro dashboard, porque obriga você a olhar caso a caso e a perceber os detalhes que nenhuma agregação mostraria. A camada de BI vem depois, para escalar o que você já entendeu.

Qual é a diferença prática entre SLA e OLA no dia a dia?
SLA é o compromisso com o cliente do serviço; OLA é o compromisso interno entre grupos que participam da mesma entrega.[7] A utilidade do OLA aparece justamente nas operações com muitas transferências: sem ele, o tempo perdido entre times fica invisível e o SLA externo estoura sem que ninguém consiga apontar onde a demora aconteceu.

Reduzir WIP não significa apenas deixar chamados fora da fila?
Não, e essa confusão é comum. Reduzir WIP de verdade significa liberar menos trabalho simultâneo para o sistema e concluir o que já entrou antes de puxar mais. Manter tickets escondidos em uma fila paralela, em planilha ou em status criativo apenas transfere o estoque de lugar — e piora, porque agora ele não aparece nem no relatório.

Como saber se a demanda é reincidência ou apenas demanda alta?
Compare o mesmo serviço ao longo do tempo procurando repetição de sintoma, de item afetado ou de usuário. Um mesmo comportamento retornando com regularidade é candidato a problema, não a incidente novo. Se a análise apontar recorrência relevante, abra um problema formal: isso muda a natureza da investigação e, principalmente, cria um registro para acompanhar se a mudança realmente eliminou a causa.

Vale a pena implantar Lean se a equipe é pequena?
Vale, e talvez mais. Equipe pequena tem menos folga para absorver variabilidade e sente cada retrabalho de forma desproporcional. A diferença é a escala da intervenção: em vez de um programa de transformação, comece com três coisas concretas — melhorar um formulário de entrada, eliminar uma aprovação sem função e investigar a causa recorrente que mais consome tempo. Dá para começar no mês que vem.

---

Referências técnicas

1. Lean Enterprise Institute. Lean Thinking and Practice. Síntese dos cinco princípios associados a Womack e Jones: valor, fluxo de valor, fluxo, pull e melhoria contínua. https://www.lean.org/lexicon-terms/lean-thinking-and-practice/

2. Lean Enterprise Institute. Value Stream Mapping. Referência sobre VSM, estado atual, estado futuro e análise do fluxo de informação e trabalho. https://www.lean.org/lexicon-terms/value-stream-mapping/

3. LITTLE, John D. C. Little’s Law as Viewed on Its 50th Anniversary. Operations Research, v. 59, n. 3, 2011, p. 536-549. DOI: 10.1287/opre.1110.0940. https://pubsonline.informs.org/doi/10.1287/opre.1110.0940

4. MIT Sloan School of Management. John D. C. Little. Registro acadêmico do pesquisador e referência à demonstração da relação L = λW. https://mitsloan.mit.edu/faculty/directory/john-d-c-little

5. GLPI Project. Assistance. Documentação oficial do módulo de assistência: tickets, problemas, mudanças, planejamento e estatísticas. https://help.glpi-project.org/documentation/modules/assistance

6. GLPI Project. Manage tickets. Documentação oficial sobre atores, itens, níveis de serviço e datas TTO/TTR em tickets. https://help.glpi-project.org/documentation/modules/assistance/tickets/ticketmanagement

7. GLPI Project. Service Levels. Documentação oficial sobre SLA, OLA, TTO, TTR, calendários, cálculo em dias e horas, atribuição automática por regras, escalonamentos e suspensão da contagem em tickets pendentes. https://help.glpi-project.org/documentation/modules/configuration/service_levels

8. GLPI Project. Changes. Documentação oficial sobre mudanças, relacionamento com tickets e problemas, análise de impacto, itens afetados, planos de implantação e de recuo. https://help.glpi-project.org/documentation/modules/assistance/changes

9. PeopleCert. Understanding the evolution of ITIL e ITIL Foundation (Version 5). Referências oficiais sobre ITIL (Version 5), lançamento escalonado em 2026, continuidade com ITIL 4 e ênfase em produtos e serviços digitais, valor e ambientes habilitados por IA. https://www.peoplecert.org/news-and-announcements/itil-version-5-explained

10. SEDDON, John; O’DONOVAN, Brendan. The Vanguard Method: Beyond Command and Control. Journal of Systems Thinking, 2023. Complementado pela referência da Vanguard Consulting sobre failure demand. https://beyondcommandandcontrol.com/failure-demand/

11. Lean Enterprise Institute. 5 Whys. Referência sobre investigação causal por perguntas sucessivas e prevenção de recorrência. https://www.lean.org/lexicon-terms/5-whys/

12. Lean Enterprise Institute. Standardized Work. Referência sobre trabalho padronizado, redução de variabilidade, treinamento e base para Kaizen. https://www.lean.org/lexicon-terms/standardized-work/

13. KINGMAN, J. F. C. The single server queue in heavy traffic. Mathematical Proceedings of the Cambridge Philosophical Society, v. 57, n. 4, 1961, p. 902-904. Aproximação clássica para o tempo de espera em filas gerais sob alta utilização.

14. HOPP, Wallace J.; SPEARMAN, Mark L. Factory Physics. Waveland Press. Tratamento didático da relação entre variabilidade, utilização e tempo de espera, incluindo a formulação VUT, e da aplicação da Lei de Little em operações.

15. STRATHERN, Marilyn. “Improving ratings”: audit in the British University system. European Review, v. 5, n. 3, 1997, p. 305-321. Origem da formulação mais conhecida sobre métricas que deixam de ser boas medidas ao se tornarem metas.

---

Leitura relacionada no Projeto Plataforma

• Sob o Capô da Máquina: Uma Aula Sobre Arquitetura de Computadores e Sistemas Operacionais — O mesmo raciocínio de fila, espera e utilização, uma camada abaixo: cache, escalonamento, troca de contexto e thrashing.
• Acelere sua carreira em TI: o método definitivo para dominar tecnologias — Como transformar fundamentos de processo e engenharia em diferencial profissional real.

Se a sua operação convive com fila crescente, reincidência e a sensação de que ninguém consegue explicar para onde o tempo está indo, uma análise de fluxo sobre os dados que você já tem no GLPI costuma responder isso antes de qualquer decisão de contratação. É esse tipo de trabalho que faço em projetoplataforma.com.br/servicos.