Software técnico, programas de cálculo e análise avançada de dados.

A situação. Uma empresa projeta sob encomenda componentes cujo dimensionamento exige verificações normativas. Há mais de vinte anos o trabalho passa por um software de cálculo escrito internamente, em uma plataforma de desenvolvimento que já não tem suporte, com formatos de arquivo proprietários nunca documentados. O programa funciona, mas ninguém consegue mais alterá-lo com segurança razoável. E as especificações não existem: as regras vivem dentro do código e na experiência de um único projetista.

O que foi feito. Os requisitos não foram coletados, foram reconstruídos. O trabalho lê em paralelo três fontes — o código-fonte, o arquivo dos projetos realmente executados e as indicações do escritório técnico — e as faz colidir entre si: cada regra extraída do código é confrontada com os dados e levada ao especialista, cada indicação do especialista é verificada no código. Nenhuma afirmação é aceita por confiança, nem a do especialista nem a do código; o que não é verificável é declarado como tal, em vez de permanecer implícito.

O que mudou. A empresa deixou de depender de um saber que existia em um só lugar. O que era tácito virou um documento discutível e, junto com o mapa do sistema, saiu a lista das incongruências que ninguém tinha mais como ver, inclusive divergências entre o que o manual prescreve e o que o programa executa.

A situação. Uma organização recebe os pedidos por e-mail, em forma livre, escritos por pessoas diferentes. Cada processo exige dados precisos, alguns verificáveis só cruzando várias informações, e produz documentos oficiais em modelos fixos. O tempo qualificado se vai no transporte dos dados: reler, pedir o dado faltante, esperar, recopiar os mesmos campos em vários documentos, cobrar quem precisa completar a sua parte. O gargalo não é a decisão: é o transporte.

O que foi feito. Um assistente vigia a caixa. Lê a mensagem, extrai os dados, confere-os com as condições da organização e responde explicando em linguagem corrente qual dado falta e em que forma é preciso, em vez de reenviar um formulário vazio. Acima dele trabalha um gestor que conhece o ciclo de vida do processo: quantas vezes o mesmo dado já foi pedido, se quem precisa completar a própria parte respondeu nos dias previstos, se o solicitante já tem um processo aberto. Depois de um número declarado de trocas infrutíferas o processo congela, em vez de alimentar uma troca infinita.

O que mudou. Quando o processo está completo, os documentos oficiais saem já preenchidos nos modelos da organização, com os campos populados pelos dados validados. O tempo qualificado volta à avaliação de mérito, que é a única parte que realmente pedia uma pessoa experiente.

A situação. Quando uma empresa envia equipes aos clientes, o programa semanal nasce de dezenas de restrições que se atrapalham: endereços espalhados em um território amplo, faixas de horário impostas pelos clientes, prioridades comerciais e prazos de lei, durações que mudam com o tipo de prestação, equipes não intercambiáveis. Feito à mão, o plano sempre sai percorrível, mas nunca eficiente, e falta o termo de comparação para perceber isso.

O que foi feito. O problema é formulado como problema de rota com janelas de tempo e resolvido com um otimizador. Um primeiro nível distribui as intervenções pelos dias, equilibrando a capacidade das equipes e colocando primeiro as mais onerosas. Um segundo resolve cada dia como rota em vários veículos, com os tempos de percurso reais tirados de um serviço viário e as janelas de horário tratadas como restrições que não se podem violar.

O que mudou. O responsável recebe um plano pronto para usar: rotas no mapa, calendário diário por unidade, quilômetros, horas de direção e saturação das equipes. E o mesmo plano se regenera em poucos segundos quando uma restrição muda, que é a parte que serve na hora, quando alguém falta.

A situação. Reconhecer a partir de uma foto os artigos de um catálogo que muda todo dia custa caro se cada sede precisa antes reunir e classificar à mão as fotografias. É o que torna proibitivos os prazos de ativação das soluções tradicionais neste tipo de serviço.

O que foi feito. A abordagem alternativa é descrever o catálogo em vez de mostrá-lo. Os itens do dia são carregados de forma declarativa — nome, categoria, descrição estendida, ingredientes, quantidade — e um modelo multimodal generalista reconhece a partir dessas descrições, não de um arquivo de imagens rotuladas. O sistema também trata os itens compostos, com coeficientes de porção, para que os valores permaneçam corretos quando na mesma escolha convivem meias porções de produtos diferentes.

O que mudou. Ativar uma nova sede significa carregar o catálogo dela. Não é preciso hardware dedicado: usa-se o smartphone da pessoa, sem totens nem leitores. E o custo escala com o tráfego, em vez de ser o custo fixo de um posto a manter mesmo quando passam dez pessoas.

A situação. Quem responde pelo treinamento obrigatório de dezenas ou centenas de pessoas mantém o estado em planilhas que envelhecem a cada contratação e a cada mudança de função. O risco não é teórico: é perceber um vencimento ultrapassado durante uma inspeção, com o que isso implica em matéria de segurança do trabalho.

O que foi feito. O problema não é calcular uma data. É manter juntos cadastros, histórico dos cursos e regras de periodicidade diferentes por função e por atividade, e calcular para cada pessoa e para cada obrigação um estado entre quatro: válido, a vencer dentro do limiar, vencido, nunca realizado. Dali saem a matriz formativa legível de relance, as cobranças em registro formal e o relatório periódico.

O que mudou. Quando a matriz existe, o trabalho vira programar os cursos em vez de reconstruir o estado. Os dados pessoais permanecem no servidor da organização: nenhum envio a serviços externos, obtido como restrição de arquitetura e não como declaração de intenção.