Integração WFM/Sigode com ADMS e Motor de Cálculo IQS

Projeto: DSB26201 · Assessment de Arquitetura de Integrações · Energisa Fonte: Transcrição integral da sessão de 15/07/2026 (3840 linhas, ~59min36s, pasta Reuniao-WFM) e Ata 08 já consolidada no Assessment (item 1.9) Status: Rascunho para consolidação — a Ata 08 foi escrita sem transcrição disponível; uma transcrição completa foi localizada nesta auditoria e usada para verificar a ata pela primeira vez Elaborado por: Syntropy Labs

Por que este artefato existe

A sessão de 15/07 cobriu dois fluxos distintos: a integração de cadastro de equipes entre o WFM/Sigode e o ADMS (carga full via SOAP, sem endpoint incremental) e a integração entre o ADMS e o motor de cálculo IQS (dependências entre incidentes, trabalho manual de mais de um ano). A Ata 08 declara explicitamente, ao contrário das Atas 05, 06 e 07, que "foi disponibilizada apenas na forma de compilação detalhada, sem transcrição correspondente". Esta auditoria localizou uma transcrição integral desta sessão na pasta do projeto — a primeira vez que a Ata 08 pode ser verificada contra uma fonte primária. Este artefato traduz os três achados centrais — a topologia do cadastro de equipes com a proposta de automação RPA, o comportamento de timeout e "cegueira operacional" na carga full, e o fluxo de dependência entre incidentes no IQS — em diagramas para o Capítulo 4 (Infraestrutura) e o Capítulo 5 (Riscos), e registra os achados de fidelidade encontrados.

Diagrama 1 — Topologia do cadastro de equipes: carga full atual e proposta de API incremental

O ponto estrutural: o ADMS hoje só aceita duas formas de atualizar equipes — carga full (SOAP, pacote GZIP de todo o agrupamento de 3 empresas) ou uma tela de mudança de status que não cobre o cadastro completo. Não existe endpoint funcional para criar/alterar uma única equipe, o que força o reenvio do pacote inteiro a cada alteração pontual. A proposta discutida na sessão — um "adapter RPA" que automatiza a tela via login/navegação/preenchimento — é tratada corretamente na Ata 08 como hipótese de contorno, não solução aprovada, com risco explícito de violar suporte contratual da Schneider se não homologada.

Diagrama 2 — Carga full: timeout e "cegueira operacional"

Este diagrama traduz o achado mais recorrente da sessão: o WFM nunca recebe confirmação confiável de sucesso ou erro. O ADMS continua processando em background após o timeout de ~10 segundos, e a falha só é percebida quando o despacho operacional falha — não durante a carga. O incidente real relatado na virada de Minas (equipe ausente por descrição de região nula) ilustra exatamente esse padrão: o problema existia desde a carga, mas só apareceu na operação.

Diagrama 3 — ADMS → Motor de cálculo IQS: dependência entre incidentes

O achado central aqui não é indisponibilidade técnica — é uma regra de negócio sem lar arquitetural definido. Quando um incidente depende de dados de outro que ainda não aconteceu, a gravação falha e cai em DLQ; uma pessoa faz a varredura manual diária (rotina desde ~setembro de 2025) e reenvia os dados unificados manualmente. A Ata 08 documenta corretamente que a base ETL do IQS cumpre parcialmente o papel de staging, mas falta a lógica explícita de correlação entre incidentes dependentes — por isso criar "mais uma base" não resolveria sozinho, como a própria ata observa.

Achados de fidelidade

Este é o primeiro caso do projeto em que a auditoria muda de natureza: a própria Ata 08 declara, em sua nota de consolidação, que "esta sessão foi disponibilizada apenas na forma de compilação detalhada, sem transcrição correspondente" — diferente das Atas 05, 06 e 07. Uma transcrição integral (3840 linhas) foi encontrada na pasta Reuniao-WFM do projeto e usada aqui para verificar a ata contra uma fonte primária que, segundo a própria ata, não existia no momento da sua redação.

Duração: a ata registra "1 hora e 7 minutos" (09h32 às 10h39). A transcrição encontrada vai de 00:00:02 a 00:59:35 — cerca de 8 minutos a menos que o declarado. Como a ata foi escrita sem transcrição, esse número provavelmente veio da agenda da reunião, não da gravação real.

"Vladimir Morozowski de Sousa" não aparece na transcrição. A tabela de participantes (1.9.2) o lista com papel ativo: "condução de perguntas de arquitetura, integração, observabilidade e alternativas de solução." Busca no arquivo integral não encontra nenhuma ocorrência de "Vladimir" ou variações. Diferente das fabricações de nome vistas em atas anteriores (Ata 04, Ata 06), aqui há uma explicação plausível: sem transcrição, quem compilou a ata pode ter presumido a presença de Vladimir por ele participar da maioria das outras sessões do projeto. Ainda assim, é uma atribuição de papel substantivo sem lastro no material-fonte agora disponível, e merece a mesma correção.

Possível recorrência do problema de nome de fornecedor já visto na Ata 06. A Ata 08 chama o fornecedor do motor de cálculo IQS de "Minsight" (seções 1.9.2, 1.9.8.2, 1.9.11.3, 1.9.14). A transcrição registra foneticamente "missight" (33:44) e "missade" (36:31). Isso é muito parecido com o caso já documentado no artefato de Integração GIS-ADMS, onde a Ata 06 registrou "Insight" para o que a transcrição sugeria ser "Minsait" — empresa real do grupo Indra, já estabelecida no projeto como responsável pela customização do GIS Adapter. Se for a mesma empresa fazendo os dois trabalhos (GIS Adapter e motor de cálculo IQS), o nome real mais provável nos dois casos é "Minsait", não "Insight" nem "Minsight". Vale confirmar isso como item único de correção nas duas atas, em vez de tratar como dois erros isolados.

Achado positivo: a Ata 08 interpretou corretamente o termo foneticamente distorcido "queda" como "KEDA" (Kubernetes Event-Driven Autoscaling) — uma leitura correta e não óbvia, bem casada com o contexto de HPA/escalonamento discutido na sessão. É um bom contraste com os erros de nome acima: mostra que a compilação, mesmo sem transcrição, acertou onde o contexto técnico era forte o suficiente para desambiguar.

Achado menor: "Cassiano" aparece uma vez na transcrição (pedido para agendar reunião com a Schneider) mas não consta na lista de participantes da Ata 08 — provavelmente apenas um detalhe perdido na compilação feita sem transcrição, não uma omissão deliberada.

Fora esses pontos, o conteúdo técnico da Ata 08 corresponde bem à transcrição: a proposta de automação RPA, o timeout de ~10 segundos, o transporte GZIP/SOAP, a escala de 300 a 400 equipes, o histórico da Schneider avaliar e desistir do motor de cálculo, e a discussão de HPA/KEDA são todos fiéis ao que foi dito na sessão — um resultado notável para uma ata escrita sem acesso à gravação.

Próximo passo

Consolidar os três diagramas na Ata 08 (itens 1.9.5, 1.9.5.4 e 1.9.8) e usá-los no Capítulo 4 (Infraestrutura) e no Capítulo 5 (Riscos e Matriz RAID) — a matriz de riscos da própria ata já classifica "timeout sem confirmação" e "dependências entre incidentes" como severidade Crítica. Ao consolidar: (1) anexar a transcrição agora localizada à Ata 08 e revisar a duração para ~59min36s; (2) verificar com a equipe se Vladimir de fato participou desta sessão específica antes de manter sua atribuição de papel ativo; (3) tratar "Minsight"/"Insight" como uma única questão de nome de fornecedor a confirmar (provavelmente "Minsait") nas Atas 06 e 08 conjuntamente, em vez de correções isoladas.