Um prestador de serviços de TI é composto por camadas de trabalho que têm pouca relação entre si. Há a construção e a manutenção de código, há a resolução de tickets e incidentes, há arquitetura e design, há gestão de projetos voltada para o cliente, e há pré-vendas: propostas, provas de conceito, fundamentação técnica de uma licitação. Entre essas categorias, as horas variam enormemente por encomenda. Um departamento de suporte funciona com base em volume e repetição. Uma equipa de arquitetura funciona com um pequeno número de pessoas com muita experiência. O resultado de um negócio é determinado por qual dessas camadas o cliente considera mais importante, e isso varia por licitação, por cliente e por momento no projeto.
As três categorias que se aplicam em todo o lado — a IA assume a tarefa, a IA trabalha em conjunto com uma pessoa que aprova ou rejeita, ou o trabalho continua a ser trabalho humano — atravessam todo o setor de TI, e não de forma uniforme. O tratamento de tickets para problemas conhecidos é, em parte, automatizável; a triagem inicial, o reconhecimento de um padrão, a proposta de uma solução com base em casos anteriores. A geração de código para partes rotineiras de software está a deslocar-se para a IA com um revisor que aprova o resultado. As decisões de arquitetura, a tradução de um desejo vago do cliente num sistema funcional, e a manutenção da confiança junto de um cliente continuam, por enquanto, a ser trabalho humano, porque exigem um julgamento que não pode ser extraído de um padrão em dados existentes.
A mudança que isto provoca não tem a ver com a IA ser boa a programar. Tem a ver com o que acontece à comparação entre fornecedores assim que parte desse trabalho passa a fazer-se sozinho. O tempo de resposta no suporte era um resultado da capacidade de equipa e do planeamento; se a triagem for maioritariamente automatizada, a rapidez deixa de ser prova de uma boa equipa e passa a ser prova de um sistema bem configurado, e esse sistema pode ser tão bem comprado ou construído pelos concorrentes. O que resta então como distinção não é a rapidez em si, mas o que acontece nos casos em que o sistema não resolve — quem consegue mesmo assim resolver e quem deixa um cliente à espera.
O mesmo padrão está presente nos processos de proposta. Elaborar uma proposta técnica a partir de componentes existentes é trabalho que pode ser parcialmente automatizado. Assim que isso acontece em várias partes numa licitação, muda o local onde um cliente ainda vê diferença: não na rapidez da proposta, mas na questão de saber se a proposta está correta para esta situação específica, e em quem consegue explicá-lo sem recorrer a um modelo padrão.
O facto de uma empresa de TI já ter organizado isto desta forma depende de onde coloca as suas pessoas. Uma empresa que ainda coloca os seus arquitetos experientes maioritariamente a escrever código padrão sobra-lhe pouca capacidade para a conversa com o cliente onde o negócio se decide. Uma empresa que já deslocou esse trabalho — IA para a parte rotineira, pessoas para o julgamento — libertou essas horas precisamente para a componente em que agora se ganha. Não é uma escolha que se faça num trimestre; resulta de decisões anteriores sobre ferramentas, sobre quem faz que tipo de trabalho, e sobre quanta confiança uma organização tem na supervisão de resultados automatizados. O que um empregador faz com o seu quadro de pessoal a este respeito é da responsabilidade do empregador; aplicam-se aí requisitos legais próprios, independentemente da questão de saber que trabalho é tecnicamente transferível.
Esta dinâmica não é exclusiva do setor de TI. A mesma mudança — de volume e rapidez para julgamento e explicação — desenrola-se de forma diferente nos serviços financeiros, onde o aconselhamento e a avaliação de risco são o ponto de partida, e de novo de forma diferente na construção, onde o planeamento e o cálculo mudam mas a execução no estaleiro continua a ser trabalho humano. A questão de saber que trabalho, nesta empresa específica, já foi deslocado e que trabalho não foi, pode ser respondida com [um levantamento de funções que avalia, por tarefa, se a IA a assume, a assume parcialmente com supervisão, ou não a assume](https://ftetoai.nl) — um passo à parte, independente da comparação com os concorrentes.
O risco desta mudança não é que um fornecedor perca, mas que não saiba em que perde. Uma proposta que diz ser mais rápida, um website que promete estabilidade, um discurso de vendas que se apoia em experiência — tudo isso são alegações, e as alegações só são uma vantagem quando podem ser fundamentadas em comparação com o que um cliente vê noutro lugar. Quem já tenha constatado um atraso numa dimensão, pode consultar uma abordagem para recuperar um atraso numa dimensão específica para saber quais são as opções, e quem quiser validar uma alegação antes de um cliente perguntar por ela, encontra em uma verificação da fundamentação das próprias alegações de qualidade como o fazer de forma sistemática.
Identifique aquilo em que a sua empresa acredita que ganha — rapidez, preço, experiência, fiabilidade — e verifique quais dessas alegações consegue hoje fundamentar com provas em comparação com um concorrente. É exatamente isso que a verificação gratuita de dimensão faz: não é um benchmark completo, mas dá uma primeira imagem de quais alegações são sólidas e quais ainda estão sem fundamento. O benchmark competitivo completo, com matriz de provas por dimensão, está em preparação.