Ata 01 · Arquitetura de Integrações ADMS (17 de junho de 2026)¶
| Data | 17 de junho de 2026 (quarta-feira) |
| Horário | 10h01 às 10h43 (duração aproximada de 42 minutos) |
| Plataforma | Microsoft Teams (reunião remota, com gravação e transcrição) |
| Tema | Análise da arquitetura de integrações do ADMS, incidentes recentes em contingência e preparação das próximas implantações |
| Cliente | Energisa (distribuição de energia) |
| Fornecedor | Syntropy Labs |
| Elaborado por | Syntropy Labs |
| Fontes | Gravação e transcrição do Microsoft Teams e compilação produzida na análise do encontro |
1.2.1. Participantes¶
Participaram da reunião os profissionais relacionados a seguir, representando a Energisa e a consultoria.
| Érica de Andrade e Santos | Energisa | Condução técnica da análise do ADMS e das integrações |
| Norberto da Silva Prado | Energisa | Coordenação de arquitetura e integração; articulação de agendas |
| Bruno Miranda Couto | Energisa | Apoio à articulação de agendas (contexto de negócio) |
| João Carlos Franco Castellani | Digital Solutions e Syntropy Labs | Consultoria de Arquitetura |
| Vladimir Morozowski de Sousa | Digital Solutions e Syntropy Labs | Consultoria de Arquitetura |
Mencionados ao longo da reunião, sem participação direta: Douglas, Wagner (Bianco), Ana, Felipe Rosa e Melissa, da Energisa. Citados ainda os fornecedores Schneider Electric (fabricante do ADMS) e o parceiro responsável pela transição da Confluent / Kafka para a IBM na camada do barramento corporativo.
1.2.2. Pauta¶
- Papel do ADMS na operação da Energisa e seu ecossistema integrado.
- Análise de incidentes recentes ocorridos em cenários de contingência.
- Observabilidade, rastreabilidade e resiliência ponta a ponta.
- Integrações com CRM, atendimento, WFM, GIS e equipes.
- Escalabilidade, volumetria, triggers e performance.
- Arquitetura OT, DMZ, Sensedia, Kafka e a topologia de clusters e datacenters.
- Priorização das análises e planejamento dos próximos passos.
1.2.3. Índice dos temas discutidos¶
- Contexto do ADMS e seu papel na operação
- Ecossistema integrado e fluxo crítico ponta a ponta
- Situações recentes em contingência
- Jornada do cliente e percepção de cancelamentos
- Observabilidade e rastreabilidade
- Risco regulatório
- Escalabilidade, volumetria e performance
- Integração de equipes e o modelo de carga full
- APIs SOAP, adapters, DMZ e arquitetura Schneider
- Triggers e impactos de performance
- Evolução da integração GIS
- Arquitetura de clusters, datacenters e latência
- Cenários de DR e testes necessários
- Barramento corporativo, Confluent / Kafka e IBM
- Priorização das análises
- Materiais, acessos e contextualização de negócio
1.2.4. Resumo executivo¶
O ADMS foi apresentado como sistema de missão crítica que sustenta a operação do digital grid da Energisa, no centro de um fluxo que conecta atendimento, operação, força de campo, indicadores regulatórios e experiência do cliente. A reunião concentrou-se nos riscos das integrações entre o ADMS e o ecossistema corporativo, a partir de incidentes reais observados em cenários recentes de contingência.
Os casos analisados evidenciaram que o sistema pode estar tecnicamente correto e ainda assim produzir impacto negativo, por falta de observabilidade, rastreabilidade ponta a ponta, tradução adequada de status para o cliente e resiliência sob carga. Foram discutidos riscos regulatórios, limitações de escalabilidade ligadas ao processamento single thread da Schneider, a criticidade da integração de equipes em carga full e a necessidade de validar, por testes, a arquitetura do próximo cluster antes da entrada de Sergipe. Ao final, definiu-se conduzir a análise pela jornada operacional completa, começando pela integração de reclamações.
1.2.5. Detalhamento dos temas discutidos¶
1.2.5.1. Contexto do ADMS e seu papel na operação¶
O ADMS, fornecido pela Schneider Electric, foi descrito como solução de missão crítica para a operação de distribuição de energia. Ele substitui um conjunto relevante de sistemas legados, consolidando o escopo supervisório (SCADA), os sistemas técnicos e a gestão de indicadores em duas plataformas principais: uma voltada à gestão de falta de energia e à recomposição da rede, e outra voltada à gestão de incidentes e indicadores (OMS). O ADMS não opera isolado: está acoplado ao processo operacional real da distribuidora, influenciando atendimento, despacho, recuperação da rede, indicadores regulatórios e a experiência do cliente.
1.2.5.2. Ecossistema integrado e fluxo crítico ponta a ponta¶
O ADMS conecta-se a um ecossistema amplo: CRM, canais de atendimento (incluindo o aplicativo Energisa On), WFM e despacho de equipes, sistema de indicadores, GIS, barramento de integração corporativo (Sensedia e Kafka) e a camada de adapters da Schneider, exposta na DMZ da rede OT. O fluxo crítico ponta a ponta percorre as etapas:
- O cliente comunica falta de energia por qualquer canal, gerando um protocolo.
- O protocolo gera um incidente no ADMS / OMS.
- O incidente é integrado ao WFM, que despacha uma equipe de campo.
- A equipe atende o incidente e o retorno encerra o processo.
- O resultado precisa voltar aos canais, ao CRM e aos indicadores.
A qualidade da operação depende do fluxo completo, e não apenas do funcionamento isolado do ADMS. Cada etapa envolve múltiplas APIs e integrações, e uma falha em qualquer ponto pode impactar atendimento, despacho, prazo regulatório, percepção pública, indicadores e confiabilidade da operação.
1.2.5.3. Situações recentes em contingência¶
A análise partiu de casos reais recentes, com destaque para a entrada em contingência da distribuidora Sul-Sudeste no fim de semana anterior. Em contingência há aumento expressivo de reclamações, intensificação das ações de recomposição, maior dependência do domínio do operador e elevação do volume de eventos e integrações. Em um dos episódios, a operação percebeu que o sistema teria falhado; após um dia inteiro de rastreamento de todas as integrações, comprovou-se que o ADMS se comportou corretamente. O problema não foi falha técnica, e sim a forma como o comportamento do sistema foi traduzido para o atendimento, o cliente e a operação, revelando ainda inúmeras oportunidades de melhoria.
1.2.5.4. Jornada do cliente e percepção de cancelamentos¶
Em caso ilustrativo, uma cliente registrou falta de energia e, no histórico do CRM, as ordens técnicas apareceram como canceladas diversas vezes, seguidas de nova ordem despachada, gerando a percepção de que o sistema havia cancelado o atendimento. O comportamento real é outro: quando há mais de um cliente afetado no mesmo trecho de rede, o ADMS agrupa os incidentes, cria uma nova ordem e encerra tecnicamente as anteriores, sem deixar de atender, passando o atendimento a outro número. Um dos casos evoluiu para repercussão em redes sociais. Avaliou-se que o status cancelado deveria ser substituído por algo como substituído por ou agrupado em incidente maior, de modo a reduzir o ruído na jornada. A informação técnica está correta, porém mal traduzida para o cliente e para o atendimento.
1.2.5.5. Observabilidade e rastreabilidade¶
O principal diagnóstico transversal foi a falta de observabilidade e rastreabilidade ponta a ponta. O primeiro desafio é identificar o problema, o que hoje exige análises longas para distinguir falha real de percepção equivocada. Há dificuldade de rastrear as integrações entre ADMS, CRM, WFM e atendimento, de saber em que ponto o evento parou e de compreender efeitos colaterais entre integrações. A conclusão é a necessidade de logs, correlação de eventos, painéis de observabilidade e trilhas de auditoria entre sistemas, evitando que a equipe gaste tempo desmistificando problemas em vez de corrigi-los.
1.2.5.6. Risco regulatório¶
Episódio crítico: reclamações registradas no dia 13 só apareceram no sistema técnico no dia 15, em decorrência de uma falha na alocação de equipe a um incidente, declarada pela Schneider. Como o prazo de atendimento de um incidente é de poucas horas (cerca de três a quatro horas), houve reclamações com mais de 30 horas sem atendimento visível no sistema técnico (OMS), gerando efeito colateral regulatório sério. A relação exata entre a falha de alocação e a perda de visibilidade ainda está nebulosa, e o tema foi tratado como ponto crítico.
1.2.5.7. Escalabilidade, volumetria e performance¶
Foi destacada a preocupação com volumetria em contingência: um único cliente chegou a abrir mais de 20 reclamações em cerca de um dia e meio, e cada reclamação aciona integrações. Com múltiplas distribuidoras em contingência simultânea, o volume pode crescer fortemente. A solução de integração da Schneider é single thread, o que, mesmo com escalonamento, mantém o risco de filas e gargalos em razão dos saltos entre camadas. Os riscos associados são formação de filas, atraso na comunicação entre sistemas, perda de fluidez operacional, aumento do tempo de reconhecimento de incidentes e pressão sobre as integrações near real time.
1.2.5.8. Integração de equipes e o modelo de carga full¶
A integração de equipes foi apontada como uma das mais críticas e problemáticas. Ela abrange equipe, colaboradores, região de atuação, escala, veículo e status. O modelo atual exige envio full, ou seja, o cadastro completo de todas as equipes das empresas do agrupamento a cada alteração, em vez de carga incremental. As consequências são volume que pode se aproximar de um milhão de linhas, processamento lento do lado da Schneider, sensibilização mensal (a mudança de escala no início do mês para o agrupamento de três empresas dispara nova carga), efeitos colaterais difíceis de diagnosticar e impacto potencial sobre outras integrações real time. Se a carga não for concluída integralmente, o processo de gestão de incidentes é travado. O problema da madrugada de segunda-feira foi atribuído a falha no cadastro de uma equipe de Mato Grosso do Sul. A primeira hipótese de melhoria é evoluir a solução para aceitar carga incremental, o que depende de desenvolvimento do lado da Schneider; os detalhes técnicos devem ser tratados com Wagner (Bianco), do time da Ana.
1.2.5.9. APIs SOAP, adapters, DMZ e arquitetura Schneider¶
As integrações da Schneider são web services SOAP, expostas como adapters em uma camada de integração na DMZ da rede OT. Trata-se de uma arquitetura padrão do produto global, com customizações limitadas; mudanças profundas exigiriam alteração do próprio produto. Isso reforça a necessidade de separar o que é problema de arquitetura da Energisa, o que é problema de integração, o que é limitação do produto Schneider e o que pode ser mitigado por observabilidade, filas, monitoramento ou ajustes de processo. A Energisa abriu uma falha de produto junto à Schneider para provocar a discussão sobre o processamento single thread.
1.2.5.10. Triggers e impactos de performance¶
Na integração de ordens de serviço, o envio de um serviço dispara vários triggers, mecanismo apontado como oneroso, confuso e um dos maiores ofensores de performance. A conclusão é que a análise não pode olhar a API isoladamente: é preciso avaliar a integração acoplada aos triggers disparados no caminho. O detalhamento técnico deve ser feito com o time da Ana.
1.2.5.11. Evolução da integração GIS¶
A integração GIS, antes no radar como ponto de atenção, evoluiu de forma positiva após refatoração, com trade-off de infraestrutura e ganho expressivo de performance: a extração full das três empresas, que levava quase 12 horas, passou a levar cerca de duas a três horas. O GIS deixou de ser ponto de atenção principal. O foco deve migrar para as integrações near real time, que afetam diretamente a operação em tempo real.
1.2.5.12. Arquitetura de clusters, datacenters e latência¶
Para viabilizar financeiramente o projeto, a infraestrutura acomoda o ADMS em três clusters. O cluster G3 está em produção, fisicamente no data center de Cataguases, onde também estão o barramento e o ecossistema corporativo (CRM, WFM e canais de atendimento); o tráfego interno em Cataguases opera bem. O próximo cluster, G1, terá o ADMS no data center da Paraíba, com a distribuidora de Sergipe como primeira implantação. Nesse cenário, eventos originados na Paraíba precisarão acionar o barramento em Cataguases e retornar à Paraíba, com dois clusters consumindo o barramento de forma concorrente. A preocupação central é a latência entre datacenters e o comportamento sob carga, contingência e DR, ainda não experimentados.
1.2.5.13. Cenários de DR e testes necessários¶
A arquitetura normal conta com links dedicados (um secundário, possivelmente um terceiro) para garantir disponibilidade. O risco está no cenário de disaster recovery, em que a operação inverte de rota e que ainda não foi testado. Recomenda-se validar o comportamento antes de depender da arquitetura em produção, por meio de smoke test, teste de estresse, teste de latência e simulação de contingência e de inversão de ambiente com múltiplos clusters. Houve concordância de que esse teste é necessário.
1.2.5.14. Barramento corporativo, Confluent / Kafka e IBM¶
Na camada do barramento, do lado corporativo e não da rede OT, há outra empresa atuando, em função da aquisição da Confluent (Kafka) pela IBM, conduzindo o transbordo e a migração para a IBM e antecipando questões relevantes para as novas distribuidoras. Esse trabalho será apresentado às equipes da consultoria em agenda específica.
1.2.5.15. Priorização das análises¶
Definiu-se iniciar a análise pela integração das reclamações e comunicações dos clientes, por ser o ponto onde o fluxo começa, por estar diretamente ligado a atendimento, incidente, despacho e retorno e por ser crítico em contingência e para o risco regulatório. A integração GIS já está estabilizada. A ordem sugerida de análise é: reclamações e comunicações, associação com incidentes e retorno dos chamados, fluxo com WFM e despacho, integração de equipes, triggers, barramento corporativo, infraestrutura de comunicação entre clusters, cenário de implantação do G1 e Sergipe e, por fim, as demais integrações. Norberto consolidará a ordem das integrações restantes e compartilhará com Érica para validação de prioridade.
1.2.5.16. Materiais, acessos e contextualização de negócio¶
Foram listados como necessários para a análise: desenho de arquitetura, catálogo completo de APIs, fluxos ponta a ponta documentados, acesso ao repositório de desenvolvimento (fluxos por mesa), visão do barramento e detalhes das integrações com CRM, WFM, atendimento e equipes, informações sobre triggers, dados de volumetria e logs e evidências dos incidentes recentes. Também foi acordado apoio de monitoramento para a integração de equipes, conduzido por Douglas junto à equipe de monitoração. Castellani solicitou uma sessão de contextualização do modelo de negócio da distribuição de energia, para conectar a análise técnica à realidade operacional; Felipe Rosa foi indicado como a pessoa adequada, com Bruno Couto articulando a agenda, idealmente para sexta-feira e com ao menos uma hora, e Melissa como apoio à priorização.
1.2.6. Decisões e encaminhamentos¶
Registro das principais decisões tomadas na reunião (modelo de Decision Log).
| Iniciar a análise das integrações pela jornada de reclamações e comunicações dos clientes | Proposto por Érica; acordado por Energisa e consultoria |
| Conduzir a análise pela jornada operacional ponta a ponta, e não por APIs isoladas | Diretriz acordada na reunião |
| Considerar a integração GIS estabilizada e fora do radar de atenção principal | Reportado por Érica após refatoração |
| Tratar a integração de equipes (carga full) como item crítico e buscar evolução para carga incremental | Energisa, em conjunto com a Schneider |
| Validar a arquitetura do cluster G1 (Paraíba e Cataguases) por testes antes da implantação de Sergipe | Acordado por Érica e Norberto |
| Realizar sessão de contextualização do modelo de negócio de distribuição | Solicitado por Castellani; aceito (Felipe Rosa) |
1.2.7. Riscos e pontos de atenção¶
Riscos identificados na reunião, classificados por categoria e severidade (modelo de RAID Log). A severidade é uma leitura preliminar, a ser refinada na fase de assessment.
| Atraso no reconhecimento de incidentes e estouro de prazo regulatório (reclamações que demoram a aparecer no sistema técnico) | Regulatório | Crítico |
| Processamento single thread da Schneider sob contingência simultânea de múltiplas distribuidoras (filas e gargalos) | Escalabilidade | Alto |
| Integração de equipes em carga full travando a gestão de incidentes e afetando integrações real time | Operacional | Alto |
| Latência e comportamento não testados na comunicação entre clusters (Paraíba e Cataguases) e em DR | Arquitetura | Alto |
| Baixa observabilidade e rastreabilidade ponta a ponta (tempo elevado para distinguir falha real de percepção) | Rastreabilidade | Alto |
| Triggers disparados nas integrações de ordens de serviço como ofensores de performance | Performance | Médio |
| Percepção equivocada de cancelamento pelo cliente, com risco reputacional e repercussão em redes sociais | Reputacional | Médio |
| Limitações da arquitetura padrão global da Schneider (APIs SOAP e modelo de integração) | Fornecedor | Médio |
1.2.8. Questões em aberto¶
- Causa raiz das falhas na integração de equipes (equipe inativa, sem veículo ou sem escala) e como mitigá-las.
- Comportamento do sistema com múltiplas distribuidoras entrando em contingência simultaneamente, dado o design single thread.
- Frequência e método ideais de envio dos dados de equipes para equilibrar performance e atualização (incremental versus full, disparo por mudança versus por tempo).
- Como manter latência e disponibilidade na comunicação entre datacenters distribuídos (Paraíba e Cataguases), inclusive em DR.
- Quais melhorias aplicar aos triggers das integrações para reduzir o overhead de performance.
- Como a falha de alocação de equipe ao incidente, declarada pela Schneider, interferiu na visibilidade das reclamações.
1.2.9. Conclusões¶
- O maior desafio é sistêmico, e não apenas técnico: o ADMS está no centro de um fluxo crítico que conecta atendimento, operação, campo, indicadores e experiência do cliente.
- O sistema pode estar tecnicamente correto e ainda assim gerar impacto negativo, por falta de clareza, rastreabilidade, tradução adequada de status e resiliência.
- Observabilidade e rastreabilidade ponta a ponta são a prioridade transversal do trabalho.
- A jornada do cliente precisa ser revisada, em especial a nomenclatura de cancelamento de ordens.
- A integração de equipes em carga full é, hoje, um dos maiores riscos operacionais.
- As integrações near real time devem receber prioridade máxima por afetarem a operação em tempo real.
- A arquitetura do próximo cluster (Paraíba e Cataguases) precisa ser validada por testes antes da entrada de Sergipe.
- Triggers e integrações SOAP da Schneider devem ser analisados em conjunto, e não isoladamente.
- A análise deve ser conduzida pela jornada operacional completa, começando pela integração de reclamações.
1.2.10. Próximos passos e ações definidas¶
Matriz de ações acordadas, com responsável e prazo indicativo.
| 1 | Marcar agenda com a equipe de desenvolvimento para detalhar fluxos e APIs ponta a ponta | Norberto (Energisa), com aval da consultoria | Curto prazo |
| 2 | Marcar agenda com a equipe do barramento (estado atual e iniciativa Confluent, Kafka e IBM; viabilização das 9 empresas) | Norberto (Energisa) | Curto prazo |
| 3 | Disponibilizar desenho de arquitetura, catálogo de APIs e acesso ao repositório de desenvolvimento | Energisa | Curto prazo |
| 4 | Consolidar a ordem das demais integrações e compartilhar com Érica para validação de prioridade | Norberto (Energisa) | Curto prazo |
| 5 | Iniciar a análise pela integração de reclamações (associação com incidentes e retorno dos chamados) | Consultoria e Energisa | Em sequência |
| 6 | Estruturar monitoramento e observabilidade para a integração de equipes | Douglas (Energisa) e equipe de monitoração | Em andamento |
| 7 | Avaliar com a Schneider a evolução para carga incremental; aprofundar detalhes com Wagner (time da Ana) | Energisa | A definir |
| 8 | Aprofundar a análise dos triggers acoplados às integrações de ordens de serviço | Consultoria e time da Ana | Em sequência |
| 9 | Planejar e executar smoke test, teste de estresse e DR (Paraíba e Cataguases; concorrência G1 e G3) | Consultoria e Energisa | Antes de Sergipe |
| 10 | Acompanhar a falha de produto aberta junto à Schneider (single thread) | Energisa | Em andamento |
| 11 | Agendar sessão de contextualização do modelo de negócio de distribuição com Felipe Rosa | Bruno Couto (Energisa), apoio de Melissa | Meta: sexta (19/06) |
| 12 | Preparar avaliação específica para a implantação de Sergipe no cluster G1 | Consultoria e Energisa | Julho a setembro |
Datas-chave¶
- Homologação da distribuidora de Sergipe: a partir de julho de 2026, cerca de um mês após a reunião.
- Go-live de Sergipe no cluster G1 (data center da Paraíba): 1º de setembro de 2026.
- Sessão de contextualização de negócio (Felipe Rosa): meta para sexta-feira, 19 de junho de 2026.
1.2.11. Observações finais¶
Esta ata foi consolidada a partir da gravação e da transcrição da reunião fornecidas pelo Microsoft Teams, da lousa técnica e da compilação produzida durante a análise do encontro. Eventuais nomes de pessoas e termos técnicos transcritos automaticamente foram normalizados para refletir o contexto do projeto. As classificações de risco e os prazos têm caráter indicativo e serão refinados nas etapas seguintes da consultoria.