Postos, pessoas, tempos, precedências e restrições ficam num estudo persistido. Para simular uma mudança, você escreve o pedido em português; o solver de otimização verifica as restrições e mostra a comparação antes de qualquer aplicação. Testar mais um cenário custa o tempo de escrever o pedido e ler a comparação.
Cada cenário fixa alguns parâmetros e deixa outros livres para o solver decidir. A base é a mesma nos dois modos: tempos, precedências e habilidades.
Os tempos-padrão entram prontos, vindos do estudo de tempos e métodos que a engenharia já faz, no software de cronoanálise ou na planilha. Medir tempo não faz parte do produto.
Você informa o ritmo e o solver procura o menor arranjo que cabe embaixo dele. É o cálculo que responde de quantos postos e posições a linha precisa para atender um determinado takt, e o que sobra pode ir para outra célula ou para o turno novo.
Aqui a equipe e os postos são dados e o solver reduz a maior carga atribuída, que é o que limita o ciclo. Serve para saber até onde a linha vai com o time que já existe, antes de discutir contratação ou hora extra.
No estudo de exemplo a linha roda com 8 posições e ciclo de 34,2 s. A posição P3-B carrega 7,5 s enquanto P3-A e P4-A ficam em 34,2 s, o que dá 34,8% de perda de balanceamento. Fixando os quatro postos, liberando até três pessoas por posto e pedindo o menor ciclo possível, o solver redistribui as operações entre 7 posições respeitando precedências, habilidades e ferramentas: a perda cai para 14,9% e o ciclo para 30,0 s. Em compensação a maior carga individual numa variante sobe de 38,4 s para 43,2 s, e é por isso que o perfil Robustez mantém as oito posições. Os dois cenários ficam disponíveis para comparação antes de qualquer aplicação.
O texto abaixo é digitado como está. O agente identifica quais campos do cenário mudam, monta a alteração e chama o solver; se o pedido for ambíguo, ele pergunta em vez de escolher por você.
“Ana estará em treinamento no próximo turno. Crie um cenário sem ela, com quatro postos, e mostre o impacto.”
“A demanda subiu e o takt caiu para 33 s. Crie um cenário com esse ciclo e mostre o impacto.”
“O mix vai mudar para 45% Basic, 20% Plus e 35% Pro. Crie o cenário e mostre qual posto vira gargalo.”
“Crie um cenário com ciclo alvo de 45 s e mostre o impacto no número de postos e posições.”
Nenhum pedido altera o estudo sozinho: o cenário fica como proposta até você comparar com a linha atual e aplicar.
Balancear linha com otimização matemática já foi tentado em muita engenharia: programação inteira, heurística, suplemento de solver na planilha. Muitos desses projetos pararam de ser usados em poucos meses, pelo mesmo motivo: montar a entrada, traduzir a pergunta da semana para os parâmetros do modelo e interpretar a saída dependiam de um especialista, e o especialista tinha mais o que fazer.
O Line Lab organiza esse mesmo cálculo em outro fluxo: a tela abre no estado atual da linha, o pedido é uma frase em português, o solver verifica a proposta contra as restrições, a comparação mostra atual e proposta lado a lado, e nada muda sem uma aplicação explícita, que gera revisão. Cada passo aparece no vídeo no topo desta página.
Precedência entre operações, ferramenta compartilhada, teto de carga definido pela engenharia, quem sabe operar o quê: no dia a dia essa informação costuma morar na experiência de quem balanceia. No Line Lab ela é cadastrada como restrição do estudo, e o solver respeita cada uma em todos os cenários. Quando essa pessoa sai de férias ou muda de área, o estudo continua legível.
Cada aplicação gera uma revisão imutável (r1, r2) com o cenário, o resultado e o hash da entrada. Dá para saber qual versão está valendo, comparar as alternativas ranqueadas pelos perfis Eficiência, Ferramental e Robustez, e voltar meses depois à revisão que sustentou uma decisão.
operacao_id← MatrizTempos.CodEtapasem transformaçãoaplica← MatrizTempos.Executabooleano → SIM/NÃOtempo_padrao_s← MatrizTempos.Duracao_msms → sDepois da migração o Excel continua servindo para relatório: cada solução exporta um .xlsx identificado com a revisão e o hash que a geraram, o que permite reabrir mais tarde exatamente o estudo que embasou uma decisão.
O cálculo roda no nosso solver determinístico, dentro do serviço: tempos, precedências e restrições não são enviados a nenhum provedor de IA para resolver o cenário.
A parte de linguagem natural usa um modelo externo, contratado com retenção zero de dados, coleta negada e sem troca automática de provedor. O agente não grava nada no estudo: ele propõe a alteração, o solver verifica e a aplicação continua sendo sua.
Antes de dado real entrar num piloto, esse caminho é documentado e aprovado com a TI do cliente.