Ata 08 · Integrações WFM e ADMS, Motor de Cálculo IQS e Escalabilidade do Barramento (15 de julho de 2026)¶

Ata consolidada a partir da compilação detalhada da reunião.


Data	15 de julho de 2026
Horário	09h32 às 10h39, horário de Brasília
Duração aproximada	1 hora e 7 minutos
Formato	Reunião técnica remota
Tema central	Integração de equipes entre WFM e ADMS, integração do ADMS com o motor de cálculo IQS e escalabilidade dos consumidores do barramento
Cliente	Energisa (distribuição de energia)
Fornecedor	Syntropy Labs
Fontes	Compilação detalhada da reunião

Nota de consolidação das fontes

Diferentemente das Atas 05, 06 e 07, esta sessão foi disponibilizada apenas na forma de compilação detalhada, sem transcrição correspondente. Por essa razão, esta ata não possui anexo de registro cronológico, e o conteúdo segue integralmente a estrutura e o recorte da compilação recebida.

A própria compilação registra que a transcrição de origem não continha identificação nominal confiável para todos os falantes e que termos distorcidos pelo reconhecimento automático foram normalizados quando o contexto permitia. A atribuição individual de intervenções deve, portanto, ser validada antes de qualquer emissão formal com responsabilidades nominais.

Índice desta ata¶

Identificação e contexto da reunião
Participantes e áreas envolvidas
Resumo executivo
Visão consolidada do ecossistema de integração
Integração de equipes entre WFM e Sigode e o ADMS
Proposta de integração incremental por API com automação
Segurança, rede OT, DMZ e requisitos de implantação
Integração do ADMS com o motor de cálculo IQS
Tratamento de erros, dependências e trabalho manual
Capacidade, contingência e escalabilidade com HPA e KEDA
Observabilidade, suporte e governança operacional
Decisões, entendimentos e encaminhamentos
Recomendações técnicas consolidadas
Plano de ação priorizado
Questões em aberto para aprofundamento
Matriz de riscos
Conclusão do assessment desta sessão

1.9.1. Identificação e contexto da reunião¶

A reunião fez parte do assessment das integrações de ponta a ponta relacionadas ao ADMS. O trabalho de levantamento já havia envolvido equipes de infraestrutura e outras frentes técnicas e, nesta sessão, avançou sobre integrações sob responsabilidade ou conhecimento das equipes de desenvolvimento, operação de força de trabalho e barramento.

O foco inicial foi a integração entre o ambiente de Workforce Management, apoiado pelo sistema legado Sigode, e o ADMS, especialmente o cadastro e a atualização de equipes de campo. Em seguida, a discussão avançou para a integração entre o ADMS e o motor de cálculo IQS, desenvolvido pela Minsight, além de aspectos de contingência, observabilidade e escalabilidade da infraestrutura de integração.

Objetivo central da sessão

Entender o funcionamento atual das integrações, identificar gargalos e riscos, registrar o trabalho manual existente e levantar alternativas arquiteturais que possam reduzir falhas, melhorar a rastreabilidade e sustentar a entrada das próximas empresas no ambiente multitenant.

1.9.2. Participantes e áreas envolvidas¶

Os nomes abaixo foram identificados ou citados ao longo da reunião. Como a transcrição não contém identificação nominal confiável para todos os falantes, a atribuição exata de cada intervenção deve ser validada antes da emissão de uma ata formal com responsabilidades individuais.


Vladimir Morozowski de Sousa	Consultoria do assessment; condução de perguntas de arquitetura, integração, observabilidade e alternativas de solução.
João Carlos Franco Castellani	Consultoria do assessment; citado como integrante da equipe responsável pelo levantamento.
Norberto da Silva Prado	Representante do cliente e articulador entre áreas; contextualização das integrações, infraestrutura e próximos encontros.
Douglas	Especialista com conhecimento do WFM e do Sigode e das integrações de equipes; principal expositor das dores operacionais.
Daniel	Especialista do barramento e do motor de cálculo; detalhamento da integração com o IQS, validações, dependências e escalabilidade.
Borba	Nome citado em relação ao conhecimento do serviço e da integração com o motor de cálculo; pode coincidir com um dos participantes identificados na transcrição.
Schneider Electric	Fornecedor do ADMS e dos adaptadores associados.
Minsight	Fornecedor responsável pelo motor de cálculo IQS.
Equipes de infraestrutura, redes e segurança OT	Áreas necessárias para validar topologia, acessos, DMZ, Citrix, autenticação e implantação de novos componentes.

1.9.3. Resumo executivo¶

A reunião evidenciou três riscos estruturais que tendem a crescer à medida que novas empresas forem incorporadas ao ambiente ADMS: a ausência de atualização incremental de equipes, a fragilidade operacional da integração com o motor de cálculo e a necessidade de escalar os consumidores e serviços do barramento de forma mais elástica.


Cadastro de equipes entre WFM e ADMS	Carga full, compactada em GZIP e enviada via SOAP para um agrupamento de três empresas.	Falha de uma empresa ou de um cadastro pode afetar todo o pacote; timeout e ausência de resposta deixam a equipe sem confirmação do processamento.	Avaliar atualização incremental por equipe, mantendo carga full periódica e criando um adaptador com API e automação para alterações pontuais.
Observabilidade da carga de equipes	O request ultrapassa o limite de resposta, o ADMS processa em background e o chamador recebe timeout.	Operação sem visibilidade; o diagnóstico depende de acesso a logs no servidor do adaptador e, em casos complexos, do fornecedor.	Criar correlação, status assíncrono, logs centralizados, métricas, alertas e resposta funcional independente do timeout síncrono.
Integração entre ADMS e IQS	Eventos passam por adaptador, APIs, Kafka e filas e base de entrada do motor de cálculo. Dependências entre incidentes podem impedir a gravação.	Existe varredura manual diária de logs, tratamento de mensagens e reenvio de dados há aproximadamente um ano.	Reavaliar regras de dependência, staging, data quality, reprocessamento seletivo e responsabilidades entre ADMS, barramento e motor de cálculo.
Escala do barramento	Serviços operam próximos do limite, com HPA considerado pouco eficiente para alguns fluxos.	Com a entrada de novas empresas, o aumento de volume pode gerar saturação de pods e backlog.	Implantar KEDA para escalar consumidores conforme pressão nas filas e tópicos e preparar capacidade para todos os tenants.

Síntese do assessment

O problema não é apenas tecnológico. Ele combina limitações funcionais do produto ADMS, desenho de integração orientado a cargas massivas, ausência de feedback operacional suficiente, regras de negócio distribuídas entre fornecedores e um modelo de suporte que ainda depende de análise manual e acesso privilegiado a servidores.

1.9.4. Visão consolidada do ecossistema de integração¶

A sessão permitiu reconstruir, em alto nível, dois fluxos principais e uma camada transversal de infraestrutura.

1.9.4.1. Fluxo de equipes de campo¶

1. O cadastro de equipes é mantido no sistema legado Sigode e no WFM.

2. As equipes são necessárias no ADMS para permitir o despacho de ordens de serviço, a visualização geográfica e o funcionamento dos algoritmos do OMS.

3. O WFM gera um pacote contendo o conjunto completo de equipes do agrupamento de empresas do ambiente.

4. O pacote é compactado em GZIP devido ao tamanho.

5. O conteúdo é enviado por uma requisição SOAP, passando pelo barramento e API Gateway e alcançando o adapter WFM do ADMS na rede OT.

6. O ADMS descompacta e processa o pacote. Como o processamento ultrapassa o limite de resposta, o chamador normalmente recebe timeout, embora o processamento continue em background.

7. Quando há falha, o diagnóstico depende de logs no servidor do adapter e, eventualmente, de análise aprofundada pela Schneider.

1.9.4.2. Fluxo entre ADMS e motor de cálculo IQS¶

1. O ADMS consolida informações dos incidentes, execução, equipe executora e demais dados necessários ao cálculo de indicadores e indenizações.

2. Um adapter desenvolvido no ecossistema Schneider disponibiliza as informações para o barramento.

3. Os registros chegam ao API Gateway e ao Kafka, podendo ser divididos em chunks em razão do tamanho.

4. Serviços producers e consumers aplicam validações e encaminham os dados para uma base de entrada e de ETL do IQS.

5. O motor de cálculo processa os registros disponíveis em janelas periódicas, relatadas como algumas vezes ao dia.

6. Após o cálculo, os resultados alimentam outra rotina responsável pelo envio das informações regulatórias à ANEEL.

1.9.4.3. Camada de infraestrutura e segurança¶

O ADMS está inserido em uma rede OT com controles de segurança superiores aos da rede corporativa.
O acesso às telas do ADMS ocorre principalmente por Citrix e identidade específica.
Adaptadores e componentes de integração estão posicionados em uma zona intermediária e DMZ da OT, com caminhos já autorizados entre o ambiente corporativo e a rede operacional.
Aplicações instaladas na OT não acessam livremente a internet; dependências precisam ser previamente baixadas e instaladas de forma controlada.
Qualquer novo serviço deverá ser avaliado por infraestrutura, redes, segurança OT e gestão de identidades.

1.9.5. Integração de equipes entre WFM e Sigode e o ADMS¶

1.9.5.1. Modelo atual de ambientes e empresas¶

Foram mencionados três ambientes ADMS, cada um contendo um agrupamento de três empresas. Um dos agrupamentos já montados reúne Minas, Sul-Sudeste e Mato Grosso do Sul. O pacote de equipes é enviado para o agrupamento como uma unidade única, e não de forma isolada por empresa ou por equipe.

1.9.5.2. Característica da carga full¶

Qualquer alteração em uma única equipe ou em um cadastro relacionado pode provocar o envio do pacote completo das três empresas. O ADMS aceita atualmente esse modelo full; não foi identificado endpoint funcional capaz de criar ou alterar integralmente uma única equipe. Existe uma interface para mudança de status, mas ela não cobre o cadastro completo necessário ao processo.

Convergência com a Ata 01

A integração de equipes em carga full foi apontada na Ata 01, de 17 de junho, como um dos maiores riscos operacionais do ambiente, com menção a volume que pode se aproximar de um milhão de linhas, sensibilização mensal pela mudança de escala e travamento da gestão de incidentes quando a carga não é concluída. Esta sessão acrescenta o detalhe técnico que faltava: o pacote é compactado em GZIP, transportado por SOAP e não existe endpoint funcional para cadastro individual de equipe, apenas uma interface de mudança de status. Isso qualifica a hipótese de evolução para carga incremental registrada na Ata 01, mostrando que ela depende de um mecanismo que hoje não existe no produto.

1.9.5.3. Principais pontos de falha¶

Uma inconsistência em uma empresa pode comprometer o processamento do conjunto das três empresas.
Uma região de despacho associada à equipe pode não existir no ADMS ou possuir descrição inválida ou nula.
Uma equipe existente no ADMS pode ter deixado de aparecer no pacote enviado, mas permanecer vinculada a uma ordem de serviço, impedindo sua exclusão e quebrando a integração.
Cadastros manuais realizados diretamente no ADMS podem gerar divergência de fonte e conflito com a carga subsequente.
Dependências cadastrais precisam estar previamente sincronizadas; quando a sequência de cargas não é respeitada, a integração falha.
Na implantação de uma nova empresa, o problema pode aparecer apenas na virada operacional, quando as equipes passam a receber ordens de serviço.

1.9.5.4. Timeout e ausência de confirmação¶

O pacote de equipes é grande e o processamento ultrapassa o limite de aproximadamente dez segundos observado na transação. O ADMS continua o processamento em background, porém a comunicação é interrompida e o WFM não recebe confirmação confiável de sucesso ou erro. Dessa forma, o trace registra o request, mas a resposta é normalmente um timeout.

1.9.5.5. Consequências operacionais¶

A equipe de negócio e desenvolvimento não sabe imediatamente se a carga foi concluída.
O erro costuma ser percebido apenas quando o despacho ou outra função deixa de operar.
É necessário acionar infraestrutura para acessar o servidor onde o adapter está executando.
Os logs disponíveis possuem níveis diferentes de detalhamento e nem sempre permitem identificar a causa sem apoio do fornecedor.
O ciclo de diagnóstico é reativo e pode envolver múltiplas áreas.
O custo computacional e energético é considerado desnecessário, pois um pacote extenso é transmitido repetidamente mesmo quando poucas equipes foram alteradas.

1.9.5.6. Risco de crescimento¶

A percepção dos participantes é que a situação tende a piorar com a entrada de novas empresas, novos cadastros e estruturas cadastrais distintas. Quanto maior o número de tenants e de equipes, maior a probabilidade de inconsistências, maior o tamanho do pacote e maior o esforço de suporte.

1.9.6. Proposta de integração incremental por API com automação¶

1.9.6.1. Conceito discutido¶

Foi proposta a criação de uma API de inclusão e alteração de equipe que, para o consumidor, se comportaria como um endpoint REST convencional. Como o ADMS não disponibiliza nativamente essa operação completa, o endpoint acionaria um microserviço de automação capaz de autenticar-se no ADMS, navegar até a tela de cadastro, preencher os campos, executar a operação e interpretar a mensagem de retorno.

Modelo conceitual

Sigode e WFM, evento de alteração, Sensedia e API Gateway, adaptador de automação, interface web do ADMS e resposta normalizada para o chamador.

1.9.6.2. Funcionamento esperado¶

1. Uma alteração é registrada no cadastro de equipes do Sigode e do WFM.

2. O evento gera uma chamada para a API de atualização incremental.

3. O API Gateway encaminha a requisição ao microserviço de automação.

4. O serviço autentica-se no ADMS com uma identidade técnica autorizada.

5. A automação navega até a tela correspondente e realiza o mapeamento entre o payload recebido e os campos da interface.

6. O serviço executa a submissão e captura a resposta apresentada pelo ADMS.

7. O retorno é traduzido para códigos e mensagens padronizados, como sucesso, equipe já existente, validação de campo, falha de autenticação ou erro interno.

1.9.6.3. Estratégia híbrida sugerida¶

A proposta não eliminaria necessariamente a carga full. O modelo considerado mais plausível seria manter uma carga full periódica para reconciliação e utilizar a integração incremental para alterações pontuais entre as cargas completas. Essa abordagem reduziria a janela de inconsistência e o volume de dados transmitido, sem abandonar o mecanismo homologado pelo fornecedor.

1.9.6.4. Benefícios potenciais¶

Atualização por equipe ou por pequeno conjunto de equipes.
Resposta funcional estruturada para cada operação.
Menor impacto cruzado entre empresas do mesmo agrupamento.
Redução do volume transmitido e processado em cada alteração.
Maior capacidade de correlação, auditoria e reprocessamento seletivo.
Possibilidade de encapsular a limitação do ADMS atrás de uma API controlada pelo cliente.

1.9.6.5. Limitações e riscos da automação¶

Fragilidade diante de mudanças na estrutura da tela, nos identificadores da interface, no fluxo de navegação ou nas mensagens do ADMS.
Necessidade de manutenção sempre que uma versão do ADMS alterar a interface.
Menor desempenho em comparação com uma API nativa, pois cada operação exige interações com a interface.
Risco de concorrência, bloqueio de sessão ou limitação do número de usuários e sessões simultâneas.
Complexidade adicional caso o acesso precise atravessar o Citrix.
Necessidade de armazenar e proteger credenciais ou tokens de uma identidade técnica.
Possibilidade de a automação violar restrições contratuais ou de suporte do fornecedor, caso não seja formalmente aprovada.
Necessidade de garantir idempotência, evitando cadastro duplicado em reenvios.

1.9.6.6. Critérios para estudo de viabilidade¶


Desempenho	Quantas operações por minuto a tela suporta. O tempo médio por equipe é compatível com os picos de 300 a 400 alterações de escala.
Escala	É possível executar múltiplas sessões em paralelo sem bloquear o ADMS ou exceder licenças.
Confiabilidade	A automação consegue identificar mensagens de sucesso, validação e falha de forma determinística.
Segurança	Onde o serviço ficará hospedado e como será feita a autenticação na rede OT.
Operação	Quem monitorará o adaptador de automação e como ocorrerá o reprocessamento.
Manutenibilidade	Como detectar rapidamente mudanças na tela após atualizações do ADMS.
Governança	A Schneider aprova ou reconhece a solução. Há risco de perda de suporte.
Idempotência	Como impedir duplicidade em caso de timeout, retry ou resposta inconclusiva.
Reconciliação	Como comparar periodicamente o cadastro do Sigode com o ADMS e corrigir divergências.

1.9.7. Segurança, rede OT, DMZ e requisitos de implantação¶

1.9.7.1. Restrição de rede¶

O ADMS está protegido dentro da rede OT. O serviço de automação não deveria ser instalado no servidor do ADMS, mas em um servidor segregado, preferencialmente na zona onde já operam os adaptadores. O caminho existente usado pela Sensedia para alcançar o adapter SOAP indica que pode ser possível disponibilizar um novo endpoint no mesmo segmento controlado.

1.9.7.2. Citrix e acesso à interface¶

O ponto ainda não resolvido é a forma como o microserviço acessaria a interface web. Os usuários atualmente utilizam Citrix, com identidade específica. Executar a automação através de uma sessão Citrix adicionaria uma camada de latência e complexidade. A alternativa preferencial seria permitir que o serviço, já dentro da OT e da DMZ, acessasse diretamente a interface do ADMS sem depender do Citrix, respeitando os controles de segurança.

1.9.7.3. Controles mínimos recomendados¶

Conta técnica exclusiva, com menor privilégio possível e segregação de funções.
Gestão de segredos em cofre corporativo, sem credenciais embutidas no código.
Autenticação mútua por certificado ou outra autenticação forte entre a Sensedia e o adaptador de automação.
Lista restrita de origens e portas liberadas.
Logs imutáveis de autenticação, payload, resposta e usuário técnico.
Monitoramento de sessão, falhas de login e bloqueios.
Processo formal de homologação após cada atualização do ADMS.
Plano de contingência para desligamento rápido da automação em caso de comportamento inesperado.

1.9.8. Integração do ADMS com o motor de cálculo IQS¶

1.9.8.1. Finalidade do motor de cálculo¶

O motor de cálculo substitui rotinas que anteriormente estavam incorporadas aos OMS legados. Ele utiliza dados das ocorrências, duração da interrupção, clientes impactados, execução e outros indicadores para calcular indenizações e métricas regulatórias. O resultado é posteriormente encaminhado por outra rotina aos sistemas responsáveis pela comunicação com a ANEEL.

1.9.8.2. Histórico e fornecedores¶

A Schneider inicialmente avaliou desenvolver o motor, mas não prosseguiu após entender a complexidade e a baixa escala comercial do produto no Brasil naquele momento. A Energisa contratou a Minsight, empresa com conhecimento dos motores de cálculo utilizados em soluções anteriores. A Schneider utilizou o esforço originalmente previsto para construir um adapter de integração com o ADMS.

1.9.8.3. Fluxo técnico consolidado¶

1. O ADMS produz e disponibiliza os dados de incidentes por meio de um adapter específico.

2. As mensagens chegam ao barramento e ao API Gateway e, em seguida, ao Kafka.

3. Registros grandes são divididos em chunks para processamento.

4. Uma API producer aplica regras de negócio e rejeita mensagens com dados obrigatórios ausentes.

5. Uma API consumer realiza validações adicionais e grava os dados na base de entrada e de ETL do IQS.

6. Erros conhecidos podem ser encaminhados para uma DLQ, que é monitorada pela equipe.

7. O motor de cálculo roda sobre os dados disponíveis na base em determinados horários do dia.

1.9.8.4. Natureza das falhas¶

O principal problema relatado não é apenas a indisponibilidade técnica de APIs. Existem dependências entre incidentes e regras de consolidação que fazem com que um registro não possa ser gravado isoladamente. Um incidente pode depender de dados de outro incidente que será concluído ou enviado horas depois. Quando a mensagem chega sem todos os elementos esperados, a integração falha ou exige tratamento manual.

1.9.8.5. Exemplo de dependência¶

Foi utilizado como exemplo um primeiro incidente que depende de informações de um segundo incidente. Caso o primeiro seja arquivado e enviado antes de o segundo estar disponível, a gravação pode falhar. Quando o segundo incidente chega, a equipe precisa reorganizar ou enriquecer as mensagens, juntando parte dos dados dos dois incidentes e reenviando a sequência de forma que o motor aceite a carga.

1.9.9. Tratamento de erros, dependências e trabalho manual¶

1.9.9.1. Rotina operacional atual¶

Desde a entrada da solução, aproximadamente em setembro do ano anterior, existe uma atividade recorrente de varredura de logs. Uma pessoa precisa verificar falhas, identificar mensagens não processadas, acionar os responsáveis e executar ou solicitar o reenvio. A atividade permanece diária e mensal, apesar de correções já terem reduzido alguns tipos de incidente.

1.9.9.2. Limitações de acesso¶

Nem todas as equipes envolvidas possuem acesso direto às bases ou aos componentes do barramento. Em fechamentos mensais, o acompanhamento do processamento depende de pessoas com acesso privilegiado, o que aumenta o tempo de diagnóstico e cria dependência operacional.

1.9.9.3. Validações existentes¶

A API producer contém regras de negócio e bloqueia mensagens com ausência de campos conhecidos.
A API consumer executa validações adicionais antes da gravação na base de ETL.
Erros mapeados podem ser encaminhados para uma fila de DLQ.
As validações atuais detectam dados ausentes, mas não contêm toda a lógica de relacionamento entre incidentes necessária ao motor de cálculo.
O conhecimento completo das dependências parece estar concentrado no ADMS ou em regras específicas do domínio implementadas pelo fornecedor.

1.9.9.4. Discussão sobre staging e data quality¶

Foi sugerida uma arquitetura com base de staging intermediária. Nessa abordagem, os eventos seriam persistidos antes da base final do motor, submetidos a validações de qualidade, correlação e completude e liberados somente quando atingissem os critérios definidos. Registros incompletos seriam isolados para tratamento e reprocessamento, sem impedir o avanço do conjunto válido.

Os participantes observaram, porém, que a base de ETL já cumpre parcialmente o papel de staging. O ponto de divergência está na ausência da regra de unificação e de dependência entre incidentes. Portanto, a simples criação de outra base não resolveria o problema sem que a lógica de correlação fosse explicitada e implementada em algum componente.

1.9.9.5. Alternativas arquiteturais para avaliação¶


Correção no ADMS	Ajustar o adapter para aguardar, correlacionar ou reenviar incidentes relacionados.	Regra fica próxima da fonte e do conhecimento do domínio.	Lead time relatado de até seis meses; dependência do fornecedor.
Enriquecimento no barramento	Persistir eventos, correlacionar por chaves e montar a mensagem completa antes do ETL.	Maior controle do cliente; observabilidade e reprocessamento seletivo.	Exige formalização das regras de negócio hoje implícitas no ADMS.
Flexibilização do IQS	Permitir gravação parcial e consolidação posterior no motor.	Reduz rejeições na entrada.	Pode exigir mudança estrutural do produto e revalidação do cálculo.
Staging com SLA de qualidade	Separar registros válidos de incompletos e liberar lotes conforme limiar de qualidade.	Evita que poucos erros bloqueiem o conjunto; facilita métricas.	Não resolve dependências sem correlação semântica e definição de SLA regulatório.
Modelo híbrido	Correções essenciais no ADMS, correlação no barramento e tolerância controlada no IQS.	Distribui responsabilidades e reduz ponto único de falha.	Maior esforço de coordenação e testes ponta a ponta.

1.9.9.6. Percepção dos participantes¶

Houve frustração explícita com a expectativa de que correções sucessivas do fornecedor eliminariam o problema. Embora o número de falhas por empresa tenha diminuído, o aumento da quantidade de empresas mantém o volume total elevado, criando o risco de acumulação progressiva de trabalho operacional.

1.9.10. Capacidade, contingência e escalabilidade com HPA e KEDA¶

1.9.10.1. Situação atual¶

A reunião registrou que a solução atual consegue suportar a quarta empresa, porém alguns componentes estão operando próximos do limite. O HPA foi descrito como pouco eficiente para o padrão de consumo observado, com serviços trabalhando em regime de força bruta e pods próximos da saturação.

1.9.10.2. KEDA como direção técnica¶

Foi mencionada a adoção do KEDA para escalar os consumidores com base na pressão real das filas ou tópicos. A expectativa é permitir o aumento dinâmico para dezenas de pods, com valores citados de 60 a 100 pods conforme a necessidade, e aplicar o mecanismo aos sistemas ligados ao barramento.

Evolução do registro entre sessões

Na Ata 04, de 09 de julho, o KEDA constava como mecanismo estudado, mas ainda não implantado, e a escalabilidade orientada por lag figurava entre as recomendações de curto prazo. Nesta sessão, seis dias depois, o KEDA é tratado como direção técnica em adoção, com dimensionamento estimado. Convém confirmar o estágio efetivo da iniciativa, já que a diferença entre estudo e implantação altera o perfil do risco de saturação diante da entrada das próximas empresas.

1.9.10.3. Risco multitenant¶

O ambiente corporativo foi descrito como multitenant, organizado em três agrupamentos de três empresas. O compartilhamento de infraestrutura significa que o crescimento de volume de um tenant pode impactar os demais se os consumidores, limites e filas não estiverem adequadamente isolados e escalados.

1.9.10.4. Recomendações de capacidade¶

Definir baseline por empresa: mensagens por segundo, tamanho médio, picos, backlog e tempo de processamento.
Modelar capacidade para o cenário completo de todas as empresas, não apenas para a próxima implantação.
Configurar o KEDA por métrica de fila e de tópico, e não somente por CPU ou memória.
Estabelecer limites de concorrência para evitar sobrecarga dos sistemas a jusante.
Criar quotas ou isolamento lógico por tenant quando possível.
Executar testes de carga com cenários de crise e de fechamento mensal.
Monitorar lag de consumidor, idade da mensagem mais antiga, taxa de erro, DLQ e tempo de recuperação.

1.9.11. Observabilidade, suporte e governança operacional¶

1.9.11.1. Lacunas identificadas¶

Timeout técnico é confundido com resultado funcional desconhecido.
Logs importantes permanecem restritos ao servidor do adapter ou a usuários privilegiados.
Não há visão ponta a ponta do evento desde a origem até o destino.
O diagnóstico depende de conhecimento tácito e acionamento manual de várias equipes.
O reprocessamento não está completamente automatizado nem disponível de forma autônoma para as equipes.
A documentação existente está desatualizada; fluxos elaborados no início do projeto já não representam a arquitetura atual.

1.9.11.2. Modelo mínimo de observabilidade recomendado¶


Origem WFM e Sigode	Identificador de correlação, data e hora, empresa, equipe, tipo de operação, versão do payload e hash do conteúdo.
API Gateway e Sensedia	Latência, status técnico, autenticação, políticas aplicadas, retries e identificação do endpoint de destino.
Adapter do ADMS	Status recebido, início e fim do processamento, quantidade processada, quantidade rejeitada e motivo funcional.
Kafka e filas	Throughput, lag, backlog, idade da mensagem, reentregas, partições e DLQ.
Consumer e ETL do IQS	Validações, gravações, registros incompletos, correlações pendentes e reprocessamentos.
Motor de cálculo	Lotes executados, registros calculados, rejeitados, pendentes e tempo de fechamento.
Gestão operacional	Dashboard por empresa, SLA, alertas, runbooks, histórico de incidentes e causa raiz.

1.9.11.3. Governança de responsabilidades¶

A arquitetura atual distribui a responsabilidade por diferentes fornecedores e equipes. A Schneider controla partes do ADMS e dos adapters; a Minsight controla o motor; o time interno controla o barramento e parte das APIs; a infraestrutura controla acessos e servidores; e as equipes de negócio percebem as falhas na operação. É necessário formalizar um modelo RACI por integração, tipo de erro e etapa do fluxo.

1.9.12. Decisões, entendimentos e encaminhamentos¶


A atualização incremental de equipes foi reconhecida como um problema crítico e crescente.	Entendimento consolidado
A proposta de API com automação foi aceita como hipótese para estudo, não como solução aprovada.	Hipótese em avaliação
A carga full pode ser mantida para reconciliação, enquanto as alterações incrementais seriam tratadas por outro mecanismo.	Direção arquitetural
A viabilidade depende de desempenho, segurança OT, forma de acesso à interface, aprovação do fornecedor e impacto das mudanças de versão.	Condicionante
A integração com o IQS exige uma reunião específica com a Schneider e a Minsight para explicitar regras, dependências e responsabilidades.	Encaminhamento
O tema de escalabilidade com KEDA deve ser antecipado antes da entrada de todas as empresas.	Encaminhamento
A documentação atual precisa ser revisada e disponibilizada no repositório do assessment.	Encaminhamento
Fluxos e diagramas antigos não devem ser tratados como documentação de referência sem validação.	Ressalva

1.9.13. Recomendações técnicas consolidadas¶

1.9.13.1. Curto prazo: estabilização e visibilidade¶

1. Implementar um identificador de correlação ponta a ponta para as cargas de equipes e os eventos do IQS.

2. Centralizar logs dos adapters, APIs, consumers e DLQs em uma plataforma acessível às equipes autorizadas.

3. Criar dashboard operacional com status por empresa e por integração.

4. Documentar os pré-requisitos cadastrais da carga de equipes e validá-los automaticamente antes do envio.

5. Criar runbook de diagnóstico e reprocessamento para os erros recorrentes.

6. Atualizar os diagramas de arquitetura e os fluxos no repositório do assessment.

1.9.13.2. Médio prazo: evolução da integração de equipes¶

1. Realizar prova de conceito controlada do adaptador de automação em ambiente de homologação.

2. Medir tempo por operação, paralelismo, estabilidade da tela, tratamento de sessão e impacto no ADMS.

3. Validar com a Schneider a existência de APIs internas, serviços não documentados ou extensões suportadas antes de adotar automação sobre a interface.

4. Definir modelo híbrido: eventos incrementais somados a carga full de reconciliação.

5. Criar reconciliação diária entre o Sigode e o WFM e o ADMS, com relatório de divergências.

6. Padronizar códigos de retorno e idempotência da API incremental.

1.9.13.3. Médio prazo: evolução do fluxo do IQS¶

1. Mapear formalmente todas as dependências entre incidentes e os casos que exigem consolidação.

2. Classificar as falhas por origem: dados ausentes, ordem temporal, regra de negócio, problema técnico, indisponibilidade ou duplicidade.

3. Avaliar correlação e enriquecimento no barramento com persistência de estado.

4. Automatizar o reprocessamento de mensagens após a chegada do incidente dependente.

5. Definir um SLA de completude e de fechamento compatível com os requisitos regulatórios.

6. Reduzir a necessidade de varredura manual de logs e de intervenções mensais.

1.9.13.4. Capacidade e resiliência¶

1. Concluir o desenho e a implantação do KEDA para os consumidores Kafka e as filas aplicáveis.

2. Executar testes de carga representando todas as empresas e cenários de crise.

3. Definir limites de backlog, alarmes e mecanismos de circuit breaker.

4. Garantir reprocessamento idempotente e isolamento entre tenants.

5. Formalizar plano de contingência para indisponibilidade do ADMS, do adapter, do gateway, do Kafka, do ETL e do motor de cálculo.

1.9.14. Plano de ação priorizado¶


P0	Atualizar o diagrama real das integrações entre WFM e ADMS e entre ADMS e IQS.	Arquitetura, barramento, WFM, ADMS e Minsight	Visão única e validada para as próximas decisões.
P0	Mapear os erros recorrentes, os pré-requisitos cadastrais e as dependências entre incidentes.	WFM, ADMS, IQS e operação	Catálogo de falhas e regras de negócio.
P0	Dar acesso controlado a logs e dashboards para reduzir a dependência de acesso manual ao servidor.	Infraestrutura, segurança OT e observabilidade	Diagnóstico mais rápido e rastreável.
P1	Reunião técnica conjunta com a Schneider e a Minsight.	Norberto, arquitetura e fornecedores	Definição de responsabilidades e alternativas suportadas.
P1	Prova de conceito do adaptador de automação em homologação.	Arquitetura, desenvolvimento e segurança OT	Evidência de viabilidade, desempenho e manutenção.
P1	Desenho de reprocessamento automático e correlação de incidentes no fluxo do IQS.	Barramento, ADMS e Minsight	Redução do trabalho manual.
P1	Implantar o KEDA nos consumidores críticos.	Plataforma e Kubernetes, barramento	Escala baseada em backlog e volume real.
P2	Reconciliação automática entre os cadastros do WFM e do ADMS.	WFM, integração e dados	Detecção preventiva de divergências.
P2	Revisão de SLAs, OLAs e RACI da cadeia.	Gestão, operação e fornecedores	Governança clara para incidentes e mudanças.

1.9.15. Questões em aberto para aprofundamento¶

Cadastro de equipes	Existe alguma API interna, SDK, comando ou serviço suportado pela Schneider para cadastrar equipes individualmente. Quais campos e entidades são pré-requisitos para a criação ou alteração de uma equipe. O status de escala utiliza o mesmo endpoint de status citado ou possui tratamento diferente. Qual o volume real de equipes por empresa, a frequência de mudança e o pico simultâneo.
Comportamento síncrono e assíncrono	Qual o timeout configurado em cada camada e por que a operação não foi modelada como assíncrona. O adapter do ADMS possui identificador de job ou consulta de status após o envio da carga.
Automação e segurança OT	O novo serviço poderia ser instalado na mesma DMZ dos adapters e acessar diretamente a interface sem o Citrix. Quais são as restrições de licenciamento e de sessões simultâneas do ADMS.
Motor de cálculo IQS	Quais regras determinam a dependência entre incidentes no IQS. Qual componente deve possuir a lógica de correlação: ADMS, barramento ou motor de cálculo. Qual é a janela regulatória real para fechamento dos cálculos e qual a tolerância de atraso existente. Por que o motor não aceita dados parciais com consolidação posterior. Qual o volume mensal de mensagens em DLQ e o tempo médio de tratamento.
Capacidade e isolamento	Quais são os limites atuais de pods, partições Kafka, consumidores e conexões a jusante. Existe isolamento de recursos por tenant ou todas as empresas competem pelos mesmos limites.

1.9.16. Matriz de riscos¶


Falha de uma empresa interromper a carga full do agrupamento.	Alta	Alto	Crítico	Validação prévia, incremento por equipe e reconciliação.
Timeout sem confirmação gerar duplicidade ou inconsistência.	Alta	Alto	Crítico	Processo assíncrono, idempotência e consulta de status.
Mudança de tela quebrar o adaptador de automação.	Média	Alto	Alto	Contrato de interface, testes automáticos e homologação por versão.
Acesso automatizado violar controles da rede OT.	Média	Alto	Alto	Arquitetura aprovada por segurança, identidade técnica e menor privilégio.
Dependências entre incidentes manterem o trabalho manual no IQS.	Alta	Alto	Crítico	Correlação explícita, staging com estado e reprocessamento automático.
Escala insuficiente com a entrada de novas empresas.	Alta	Alto	Crítico	KEDA, teste de carga e planejamento de capacidade multitenant.
Documentação desatualizada induzir decisões incorretas.	Alta	Médio	Alto	Atualização de diagramas, versionamento e owner definido.
Dependência excessiva de fornecedores e de acessos privilegiados.	Alta	Médio	Alto	RACI, observabilidade interna e transferência de conhecimento.
Reprocessamento não idempotente gerar duplicidades.	Média	Alto	Alto	Chaves de negócio, deduplicação e controle de estado.
Falha não percebida até o despacho operacional.	Média	Alto	Alto	Monitoramento sintético e alertas proativos.

1.9.17. Conclusão do assessment desta sessão¶

A reunião foi tecnicamente rica e revelou que as dores atuais não são incidentes isolados, mas sintomas de escolhas arquiteturais que precisam ser revistas antes da expansão completa do ADMS. A carga full de equipes, a resposta síncrona incompatível com o tempo de processamento, as dependências de incidentes no IQS e a escala limitada dos consumidores formam um conjunto de riscos interdependentes.

A hipótese do adaptador de automação pode mitigar a ausência de uma API incremental, porém deve ser tratada como solução de contorno sujeita a prova de conceito, aprovação de segurança e avaliação contratual com a Schneider. Paralelamente, a integração do motor de cálculo requer uma discussão conjunta com a Schneider e a Minsight para decidir onde as regras de correlação e consolidação devem residir.

O passo mais urgente é criar visibilidade ponta a ponta e documentação atualizada. Sem correlação, logs acessíveis, métricas e ownership claro, qualquer evolução funcional continuará dependente de diagnóstico manual. A adoção do KEDA e o planejamento de capacidade devem ocorrer antes que o crescimento do número de empresas transforme problemas administráveis em indisponibilidade sistêmica.

Conclusão executiva

A recomendação é conduzir três trilhas em paralelo: estabilização e observabilidade imediata; prova de conceito de atualização incremental de equipes; e redesenho das regras de dependência e reprocessamento do IQS, com participação formal dos dois fornecedores.

1.9.18. Observações finais¶

Esta ata foi consolidada a partir da compilação detalhada da reunião, único documento disponibilizado para esta sessão. A compilação registra que termos aparentemente distorcidos pela transcrição automática foram normalizados quando o contexto permitia, e que trechos cuja identificação nominal ou interpretação permaneceu incerta foram redigidos de forma neutra, sem atribuição individual de responsabilidade. As classificações de risco e as prioridades do plano de ação têm caráter indicativo e serão refinadas nas etapas seguintes da consultoria.