Na automação de armazéns há uma cena recorrente: a inauguração do novo equipamento. As gruas do AS/RS já estão de pé, os transportadores têm energia, um AMR faz sua primeira corrida autônoma — e o dono respira aliviado, dando por certo que a parte mais difícil já passou. Os balanços pós-projeto sugerem que o certo costuma ser o contrário. Quando a instalação mecânica termina, a instalação costuma estar ainda a meses da entrada em operação real, e nesse trecho o maior consumidor de horas de trabalho já não é o fornecedor do equipamento, mas as equipes de software e comissionamento. O cronograma de implementação do WCS continua sendo o segmento mais cronicamente subestimado de qualquer projeto de automação.

Vejamos as referências publicadas pela própria indústria. Segundo o FAQ público sobre implementação de WCS da integradora de automação DNC Automation, os prazos caem em três faixas: um WCS básico para um sistema de transportadores simples se implanta em 6 a 12 semanas; uma instalação de complexidade moderada com vários tipos de equipamento precisa de 3 a 5 meses; e uma implementação em grande escala com automação extensa leva de 6 a 12 meses, incluindo projeto, configuração, integração, testes e comissionamento. Note bem o que essas faixas medem: o trabalho de software e integração em si, sob a premissa de que o equipamento já está instalado e a instalação mecânica está concluída. Mesmo com essa premissa, a faixa mais alta consome um ano inteiro. A elasticidade é enorme — e o que determina em que faixa um projeto cai raramente é o volume de código.

As cinco fases: uma prestação de contas de para onde vai o tempo

Sintetizando os balanços pós-projeto de várias integradoras, o esforço de implementação do WCS se distribui mais ou menos assim. Fase um, requisitos e congelamento de interfaces, toma cerca de 15 a 20 por cento do esforço total: documentar cada mensagem WMS-para-WCS, cada formato de telegrama PLC e cada tabela de códigos de exceção entre o WCS e cada equipamento, e depois conseguir a assinatura de ambos os lados. Fase dois, configuração e desenvolvimento, toma de 20 a 25 por cento: configurar a lógica de processo na plataforma WCS, escrever os drivers dos dispositivos, rodar emulação offline. Fase três, integração e comissionamento no local, costuma ser o maior bloco, de 30 a 40 por cento: os equipamentos são energizados unidade por unidade, e o WCS é conectado e exercitado seção por seção. Fase quatro, operação experimental e rampa, toma de 15 a 20 por cento: operar com volume real, ajustar o takt time, corrigir casos-limite. Por fim, o aceite e a entrega tomam cerca de 5 por cento: documentação, treinamento, transferência de garantia.

O ponto estrutural de interesse é a fase três. Por que o comissionamento no local é sempre o buraco negro? Uma razão é que os PLCs e o WCS habitam duas concepções de tempo fundamentalmente distintas. Um PLC pensa em ciclos de varredura de milissegundos — um sinal de foto-célula chegando 50 milissegundos atrasado é um incidente. Um WCS pensa em transações — a jornada completa de um palete do ponto A ao ponto B. Quando essas duas concepções de tempo se encontram no local pela primeira vez, surgem problemas que nenhuma emulação de escritório poderia ter revelado: jitter de sensores, desvios de postura dos paletes, picos de latência de rede. Cada um parece pequeno isoladamente, mas cada um exige que ambas as partes se sentem juntas, o reproduzam, o localizem e estabeleçam de quem é a culpa. É assim que o tempo se consome: não num colapso só, mas em centenas de pequenos saques.

Duas cenas de campo: como o tempo se perde discutindo

Em 2024, um operador logístico terceirizado do Meio-Oeste americano comissionou uma linha de sorter cross-belt, com o WCS cuidando da programação da separação entre o sorter e o WMS. Na terceira semana do comissionamento surgiu um problema: erros de separação oscilando em torno de 0.3 por cento. O fornecedor do equipamento insistia que o WCS emitia planos de separação defeituosos; a integradora apresentou logs provando que os planos estavam corretos e que os telegramas estavam sendo perdidos do lado da execução do PLC. O impasse durou duas semanas completas antes que a causa raiz emergisse: uma incompatibilidade de versões do programa do PLC. O fornecedor havia gravado a versão 3.2 no local, enquanto a integradora havia desenvolvido contra a documentação de interfaces da versão 3.1 — e entre as duas versões, o byte offset do telegrama de confirmação de separação diferia em uma posição. O projeto entrou no ar com cinco semanas de atraso. A correção de código real tomou dois dias. Todo o resto foi para provar que o problema não era do próprio lado.

O segundo caso é da Europa, em 2022. Um centro de fulfillment de e-commerce instalou um AS/RS, e o dono — perseguindo um prazo de temporada alta — insistiu que o WCS entrasse em operação experimental no cronograma original, embora a instalação mecânica das gruas estivesse seis semanas atrasada. A lógica de controle foi, portanto, ajustada durante dois meses contra equipamento instalado pela metade; ramos inteiros de lógica não puderam ser testados de jeito nenhum porque o hardware não estava lá. Quando a instalação mecânica finalmente terminou, quase todos os parâmetros previamente ajustados tiveram de ser refeitos, porque os perfis de aceleração das gruas reais diferiam dos simulados. A lição foi mais tarde escrita no modelo de contrato daquele dono para todos os projetos greenfield: a equipe do WCS não se mobiliza no local até que a instalação mecânica e os testes independentes dos equipamentos estejam completos. Essa regra, aparentemente atrasadora de cronograma, cortou a duração do comissionamento em quase um terço nos projetos seguintes.

As três armadilhas que atrasam

A primeira armadilha é começar a trabalhar antes que a documentação das interfaces esteja congelada. Uma vez que as interfaces WMS-WCS e WCS-PLC começam a mudar no meio do projeto, cada mudança cria retrabalho em ambos os lados. Pior ainda, as interfaces são uma zona cinzenta — não pertencem à lista de entregáveis de nenhuma das partes — de modo que o custo das mudanças nunca é negociado de forma limpa. A prática madura é fazer do congelamento de interfaces um marco contratual: após a data de congelamento, qualquer mudança de interface passa por um processo formal de mudança, com cronograma e custo tratados separadamente.

A segunda armadilha é deixar a definição de "rodar bem" fora do contrato. O que constitui passar a operação experimental — 72 horas de operação contínua sem falhas, ou 90 por cento do takt de projeto? Pedidos reais ou dados de teste? Se esses critérios não estiverem definidos na assinatura, o aceite vira uma negociação sem fim. Vi uma discussão de seis semanas sobre a definição literal do aceite da operação experimental — enquanto ambos os lados concordavam em particular que o sistema já era utilizável. A solução é quantificar os critérios de aceite no anexo do contrato: duração de operação contínua, taxa de cumprimento do takt, teto de erros de separação.

A terceira armadilha é amarrar o aceite do WCS ao aceite mecânico na mesma data. Cada dia que o maquinário atrasa, a equipe de software queima outro dia de custo no local — e o dano moral da espera ociosa supera o custo financeiro. A abordagem desacoplada é o aceite por etapas: o WCS primeiro passa o "aceite por emulação" contra equipamento virtual, e depois o "aceite no local". Uma vez passado o aceite por emulação, a equipe de software pode desmobilizar, deixando no local apenas uma equipe mínima de suporte.

Uma descoberta contraintuitiva: escrever código é a parte mais barata

Ao estudar os estouros de projetos WCS, uma conclusão contraintuitiva se repete: no custo total, escrever a lógica do WCS em si representa a menor fatia. O grosso vai para três itens — espera, retrabalho e disputa. Espera: equipes de software ociosas no local esperando equipamento, interfaces ou o cronograma da outra parte. Retrabalho: desfazer coisas porque os requisitos nunca foram congelados. Disputa: estabelecer responsabilidades nas zonas cinzentas. Nenhum dos três produz uma única linha de código, mas juntos consomem a maior parte do orçamento e do cronograma.

Uma segunda descoberta contraintuitiva corta na direção oposta: congelar os requisitos cedo demais causa mais retrabalho, não menos. Congelar a lógica de controle antes que o hardware esteja pronto apenas congela suposições sobre uma máquina hipotética. A abordagem que realmente economiza tempo é a inversa — adiantar o banco de testes de interfaces (a emulação): antes mesmo de o equipamento chegar ao local, rodar cada ramo da lógica do WCS milhares de vezes contra PLCs virtuais. Quando o equipamento real chega, o comissionamento vira verificação em vez de depuração. Quanto mais a fundo for feito o comissionamento virtual, menor fica o buraco negro no local.

A tendência: o comissionamento virtual está reescrevendo o cronograma

A fronteira entre WCS e WES (sistemas de execução de armazém) está se esmaecendo, com mais plataformas WCS absorvendo capacidades de orquestração; enquanto isso, as ferramentas de comissionamento virtual estão devolvendo ao escritório o trabalho que antes tinha de ser feito no local. Se 60 por cento ou mais do trabalho de integração puder ser concluído antes da chegada do equipamento, as três faixas publicadas — 6 a 12 semanas, 3 a 5 meses, 6 a 12 meses — podem cada uma descer um degrau nos próximos anos.

Mas isso levanta uma pergunta que vale a pena ponderar: quando o comissionamento não exigir mais grandes equipes de engenharia estacionadas no local por meses, o que acontecerá com o modelo de negócio da integradora? O modelo de faturamento por diária colapsará primeiro, ou os donos exigirão primeiro que o cronograma economizado seja convertido em cortes de preço? Um cronograma de implementação do WCS nunca foi puramente uma questão de engenharia — por baixo dele está a distribuição de lucros de toda a cadeia de valor da automação. Da próxima vez que ouvir "a parte de software é rápida, só umas semanas", considere fazer três perguntas: as interfaces estão congeladas, os critérios de aceite estão no contrato, e o ambiente de emulação está construído? As respostas preveem a data real de entrada no ar melhor do que qualquer cronograma de Gantt.

Por Dr. Chen, pesquisador de cadeia de suprimentos

Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.