«Shift-left» é provavelmente um dos termos mais usados — e abusados — no ITSM. Refere-se à tendência para resolver problemas o mais cedo possível na cadeia de suporte, com o objetivo de conter custos. A ideia é apelativa e, no papel, difícil de contestar. O problema é que muitas organizações tratam o shift-left como um fim em si mesmo — um projeto a lançar ou uma ferramenta a implementar — em vez de o encararem como o resultado de pré-requisitos operacionais já bem consolidados.
Deslocar os tickets para os níveis menos dispendiosos da cadeia de suporte — o movimento «para a esquerda» que dá nome à prática — não produz qualquer redução de custos se não existirem, em simultâneo, três elementos: uma base de conhecimento de elevada qualidade, um self-service bem concebido e uma automatização madura do service desk.
A análise que se segue pretende colocar o shift-left no lugar que realmente lhe pertence. Para as organizações ITSM, deve representar um ponto de chegada, sustentado por bases operacionais sólidas, e não uma solução tecnológica a implementar logo no início do percurso.
A matemática que torna o shift-left indispensável
O interesse pelo shift-left assenta numa realidade muito concreta em termos de custos: o custo por ticket aumenta significativamente à medida que avançamos para níveis de suporte mais especializados, desde o service desk de primeiro nível até ao suporte prestado por fornecedores externos.
Segundo os benchmarks da MetricNet, na América do Norte, um ticket tratado por um service desk de Nível 1 custa cerca de 22 dólares, enquanto o mesmo problema, resolvido através de self-service no Nível 0, custa cerca de 2 dólares. À medida que subimos na cadeia de suporte, o suporte de desktop (Nível 2) custa cerca de 70 dólares, o suporte de IT de Nível 3 aproximadamente 100 dólares, o suporte no terreno cerca de 220 dólares e o suporte de fornecedores pode chegar aos 600 dólares por ticket. A MetricNet identifica também um «Nível -1» — o ponto mais à esquerda de todos: a prevenção de incidentes através da gestão de problemas, eliminando à partida tickets que, de outra forma, chegariam a ser criados.
Na prática, quanto mais tickets conseguirmos deslocar para a esquerda — por exemplo, de uma reposição de palavra-passe tratada por um agente, com um custo de 22 dólares, para uma resolução automatizada que custa 2 dólares — maior será a redução do custo total. É nesta diferença de custos que assenta a promessa de redução associada ao shift-left: cada pedido resolvido num nível inferior custa menos. No entanto, esta lógica só funciona com uma condição: o pedido tem de ser efetivamente resolvido nesse nível, e não apenas reencaminhado.
Quando o shift-left aumenta os custos em vez de os reduzir
A poupança por ticket pressupõe uma resolução efetiva, e não um simples reencaminhamento. Um pedido encaminhado para self-service que depois regressa ao Nível 1 — porque o artigo da base de conhecimento estava incorreto, o portal era difícil de utilizar ou a automatização estava mal concebida — não custa 2 dólares, mas 2 dólares mais os 22 dólares do Nível 1, aos quais poderá ainda somar-se o custo de uma eventual escalada. Um shift-left prematuro pode, por isso, aumentar o custo global do problema: reduz a percentagem de pedidos resolvidos no primeiro contacto e aumenta os contactos repetidos sobre a mesma questão.
É precisamente por isso que uma iniciativa de shift-left orientada exclusivamente para a redução de custos produz frequentemente o efeito contrário. Um canal de self-service concebido apenas com o objetivo de conter custos tende a ter uma baixa adoção e a não gerar os benefícios esperados. Quando os utilizadores não encontram uma resposta, acabam muitas vezes por procurar alternativas fora dos canais oficiais.
O estudo da TeamViewer sobre fricção digital confirma este problema: 54% dos colaboradores afirmam não se sentir capazes de resolver problemas técnicos sozinhos — um sinal de que um self-service mal mantido acaba por não ser utilizado e leva os utilizadores a recorrer ao suporte na mesma. O resultado é o paradoxo que qualquer responsável por ITSM deve querer evitar: as métricas de volume melhoram, enquanto a experiência real dos utilizadores e o custo efetivo por problema resolvido pioram.
A checklist dos pré-requisitos
Para que a redistribuição dos tickets pelos diferentes níveis de suporte seja realmente viável, têm de estar previamente reunidas três condições — os verdadeiros fatores que tornam o shift-left possível.
1. Conhecimento preciso e acessível
A base de conhecimento é um dos ativos mais importantes da cadeia de valor do ITSM. No entanto, não basta «capturar» conhecimento: o seu valor está na utilização, não no simples armazenamento. Metodologias consolidadas, como o Knowledge-Centered Service (KCS), existem precisamente para manter os artigos atualizados, relevantes e verdadeiramente úteis na resolução de problemas — uma condição essencial para que um problema possa ser considerado «Level Zero Solvable», ou seja, resolvido de forma autónoma no Nível 0.
2. Gestão eficaz no Tier 0 e Tier 1
O Nível 0 (self-service) e o Nível 1 devem ser concebidos a partir das necessidades reais dos utilizadores, e não das funcionalidades do software. Um portal fácil de utilizar, com uma pesquisa eficaz e FAQs bem estruturadas, e um primeiro nível com as ferramentas e a autonomia necessárias para resolver e fechar tickets sem necessidade de escalada: é aqui que se decide, em grande medida, o sucesso ou o fracasso do shift-left.
3. Ciclos de feedback fechados entre os níveis
Sempre que um nível superior resolve um problema novo, a solução encontrada deve ser documentada e disponibilizada aos níveis inferiores, para que possa voltar a ser utilizada de forma autónoma no futuro. O processo desenrola-se em quatro etapas: documentar, pesquisar, corrigir e resolver. Sem este fluxo contínuo de partilha de conhecimento, a base de conhecimento vai ficando progressivamente desatualizada, comprometendo a eficácia do shift-left.
A gestão da mudança organizacional
A estes três pré-requisitos junta-se um quarto, muitas vezes negligenciado: a gestão da mudança organizacional. O shift-left implica uma alteração nas formas de trabalhar e exige uma revisão correspondente dos critérios de avaliação e dos incentivos das equipas. Sem essa mudança, a gestão do conhecimento, o self-service e a automatização continuam a ser apenas ferramentas, sem uma verdadeira adoção por parte das equipas.
É precisamente nestes pré-requisitos que os responsáveis de IT devem começar por medir o seu desempenho, antes mesmo de olharem para o volume de tickets. A taxa de resolução no primeiro contacto (first contact resolution), a percentagem de problemas «Level Zero Solvable» e a taxa de reabertura de tickets revelam, melhor do que qualquer contagem de tickets reencaminhados, se o shift-left está efetivamente a funcionar.
IA e shift-left: benefícios reais e custos ocultos
A inteligência artificial e, em particular, os grandes modelos de linguagem (LLM) estão a alterar a lógica económica do shift-left — mas não necessariamente da forma que muitos esperam. Quando utilizada corretamente, a IA pode aumentar significativamente a capacidade de resolução do Nível 1. A Gartner identifica o apoio aos agentes (agent enablement) como um dos casos de utilização mais eficazes: resumos automáticos de tickets, respostas rápidas e sugestões de próxima melhor ação (next-best action) que poupam tempo aos agentes sem comprometer a precisão.
Da mesma forma, um LLM pode gerar rascunhos de artigos para a base de conhecimento a partir de tickets resolvidos, aumentando rapidamente o conhecimento disponível para o Tier 0 e o Tier 1 — e acelerando a automatização do service desk.
Os custos invisíveis de uma automatização sem bases sólidas
O outro lado da moeda é uma automatização mal concebida, capaz de gerar custos adicionais a jusante. Um assistente conversacional baseado numa base de conhecimento de fraca qualidade não resolve o problema: limita-se a reencaminhar o pedido — muitas vezes de forma incorreta — e pode apresentar respostas imprecisas com uma confiança enganadora, prejudicando a confiança dos utilizadores e aumentando os contactos repetidos. Não é por acaso que, no relatório da TeamViewer referido anteriormente, 32% dos inquiridos afirmam que as soluções de IA que testaram falharam.
Ainda assim, o potencial é enorme: a Gartner estima que, até 2029, a IA agêntica poderá resolver autonomamente 80% dos problemas de serviço mais comuns, permitindo uma redução de cerca de 30% nos custos operacionais. Estes resultados, no entanto, só são alcançáveis quando o Nível 0 e o Nível 1 já assentam em bases sólidas. Caso contrário, a automatização do service desk limita-se a reproduzir, em escala, os erros que já existem.
O shift-left como indicador de maturidade
Para os responsáveis de IT que têm de demonstrar o impacto do IT nos resultados do negócio — e não apenas o cumprimento dos SLA —, o shift-left deve ser encarado como o resultado de pré-requisitos bem estabelecidos e não como um ponto de partida. É preciso abandonar a ideia de que basta redistribuir a carga de suporte e esperar que a qualidade apareça por si só.
A sequência deve ser outra: primeiro, criar os pré-requisitos — conhecimento, self-service, automatização e processos de transmissão e feedback do conhecimento; depois, como consequência natural, transferir progressivamente os tickets para níveis inferiores; e, por fim, alcançar uma redução sustentável dos custos, baseada em resoluções efetivas e não em simples transferências.
Visto desta forma, o shift-left torna-se verdadeiramente um indicador relevante da maturidade operacional de uma organização ITSM.
FAQs
- O que é o shift-left no ITSM?
É a prática de resolver problemas e pedidos o mais próximo possível do utilizador e do momento em que surgem, transferindo tickets de níveis de suporte mais dispendiosos para níveis de menor custo, até ao self-service de Nível 0. - Por que razão o shift-left pode aumentar os custos em vez de os reduzir?
A poupança pressupõe que o problema seja efetivamente resolvido e não apenas reencaminhado. Um ticket que regressa a níveis superiores acumula os custos das diferentes etapas, reduz a taxa de resolução no primeiro contacto e aumenta o número de contactos repetidos. - Que pré-requisitos são necessários antes de redistribuir os tickets para níveis inferiores?
São necessários três: uma base de conhecimento rigorosa e acessível; uma gestão eficaz do Tier 0 e do Tier 1, concebida em função das necessidades reais dos utilizadores; e processos estruturados que permitam disponibilizar aos níveis inferiores as soluções encontradas nos níveis superiores. - A IA permite dispensar os pré-requisitos do shift-left?
Não. A IA amplifica as condições existentes: com uma base de conhecimento sólida, pode acelerar a automatização do service desk; com uma base de fraca qualidade, pode gerar respostas incorretas, aumentar os contactos repetidos e comprometer a confiança dos utilizadores.