Pular para conteúdo

Fluxo de Incidentes CRM / OMS / ADMS — Mapeamento e Pendências

Projeto: DSB26201 — Assessment de Arquitetura e Integrações ADMS (Energisa) Versão: v0.1 · rascunho — pauta proposta para a sessão de validação com Érica Data-base: 04/09/2026 Fonte: Consolida achados já registrados na Ata 09 (010-evidencias/090-canais-digitais-atendimento.md), nos diagramas de sequência de fluxos-atendimento-adms.md, na matriz de achados e lacunas e na matriz de riscos consolidada — não é uma sessão nova com a Energisa Elaborado por: Consultoria Syntropy Status: Rascunho para validação — vira ativo quando Érica confirmar a Seção 1 e as perguntas da Seção 3 forem respondidas

Por que este artefato existe

A recomendação D3.3 do diagnóstico preliminar já pedia isto: "Documentar e validar com Érica o fluxo ponta a ponta: geração, agrupamento, fechamento, reabertura e conciliação" (ver recomendacoes-preliminares.md, domínio D3). Até esta versão, essa documentação não existia como artefato único — o conteúdo estava espalhado em pelo menos quatro lugares (Ata 09, fluxos-atendimento-adms.md, a matriz de achados e a matriz de riscos), o que tornava fácil ler a pendência como "nada foi mapeado" quando na verdade boa parte do desenho técnico já está descrita, só não validada com a dona do processo de negócio.

Este documento separa deliberadamente o que já está mapeado (Seção 1) do que está pendente (Seção 2), e termina com a lista de perguntas que a sessão com Érica precisa responder (Seção 3) — a intenção é que este seja literalmente o documento levado para essa sessão.

Aviso metodológico

Como as demais pastas de propostas e sínteses deste repositório: nada aqui foi validado com a Energisa. É consolidação de consultoria sobre achados já registrados, não uma nova coleta de dados. Quando Érica validar o conteúdo da Seção 1 e as perguntas da Seção 3 forem respondidas, atualizar este artefato para status: ativo, e propagar a confirmação para matriz-achados-lacunas.md (linha do achado "Agrupamento de incidentes..."), status-sessoes.md (linha "Érica") e recomendacoes-preliminares.md (D3.3).

1. O que já está mapeado

1.1 Geração do incidente — modelo de 3 mensagens

O adaptador do lado do ADMS/DMS não representa uma ocorrência técnica por um objeto único: ele devolve três mensagens distintas — o serviço/incidente, os pontos de entrega afetados e os trouble tickets associados. Um único incidente pode ter vários pontos afetados e vários trouble tickets (um por reclamação registrada); nem todo ponto afetado tem reclamação associada. Essa separação em três mensagens já foi uma evolução deliberada sobre um modelo anterior de objeto único, que ficava grande demais em incidentes com muitas unidades consumidoras afetadas.

Fonte: Ata 09, seção 1.10.4.4.

1.2 Agrupamento e estados — os 7 tópicos

O sistema WFM/SIGOD processa e republica cada mensagem em sete tópicos por estado: criado, despachado, encerrado, cancelado, arquivado, chamada, afetado. A identidade do estado é dada pelo tópico de origem, não por um atributo da mensagem — a estrutura do payload é semelhante entre eles.

Ambiguidade de atribuição ainda não resolvida. A Ata 09 atribui esse papel de agregação/republicação ao "Sigode". A wiki técnica da Energisa, por outro lado, atribui esse papel a um microsserviço específico, o MsAttFiltroIncidentes, que consome os 7 tópicos wfm_ordem_servico_* — esses sim produzidos pelo WFM/SIGOD — e republica para crm_comunicacao e crm_clientes_afetados_desligamento_emergencial. A lista de 7 tópicos bate exatamente entre as duas fontes; a divergência é só de quem faz o quê. Pode ser apenas o jeito como as áreas se referem a isso informalmente em reunião. Precisa de confirmação com Izabooh ou Lucas antes deste artefato virar ativo.

Fonte: Ata 09, seção 1.10.4.5; fluxos-atendimento-adms.md, seção "Achado de nomenclatura: 'Sigode' vs. MsAttFiltroIncidentes".

1.3 Encaminhamento ao WFM e retorno ao CRM

Após a formação dos eventos técnicos, as informações seguem para o WFM, que consolida os dados e cria ordens de serviço para execução em campo. Um componente de integração filtra o que é relevante para os canais digitais e o atendimento convencional, publicando em dois tópicos consumidos por ambos: ordem de serviço e clientes afetados.

O microsserviço de comunicação é responsável por manter ADMS e CRM no mesmo estado lógico: consome os 7 tópicos de estado e, por um alt, decide entre gerar uma comunicação nova (6 inserções no ATD, incluindo consulta ao trouble ticket no ADMS) ou atualizar uma existente (3 operações). Todo esse encadeamento já está descrito e é a base do Diagrama 5 (Geração de Comunicação) referenciado abaixo.

Fonte: Ata 09, seções 1.10.4.6 e 1.10.4.7; fluxos-atendimento-adms.md, linha 235.

1.4 Fluxos já diagramados em sequência

fluxos-atendimento-adms.md traz 8 fluxos completos, com diagrama de sequência, nome real de tópico Kafka, tabela e microsserviço — extraídos diretamente da wiki técnica da Energisa (não são reconstrução da consultoria). Os que compõem o ciclo de vida do incidente:

Diagrama Fluxo Cobre
2 Abertura de Ocorrência Técnica Geração do incidente (Seção 1.1)
4 Encerramento de Comunicação Fechamento — com uma hipótese de nome de tópico ainda não confirmada explicitamente (ver nota na linha 196 do artefato)
5 Geração de Comunicação Agrupamento e retorno ao CRM (Seção 1.3)
7 Desligamento Emergencial Variante do fluxo de incidente para desligamento não programado

O Diagrama 3 (Desligamento Programado, addendum de 24/07 com Izabooh) é um fluxo diferente e mais estreito — ver ressalva na Seção 2.5.

1.5 Problemas já confirmados pelo ambiente — não são hipótese da consultoria

Estes quatro pontos já são fatos reportados por quem opera o ambiente, com evidência concreta — a pendência não é "descobrir se existem", é desenhar como o fluxo deveria tratá-los:

  • Cancelamento como estado terminal (bug confirmado). Ocorrências aparecem como canceladas no CRM legado e não conseguem mais mudar de status depois disso. Izabooh confirmou ao vivo que "o problema persiste e não é possível mapear todos os casos em que ele ocorreu". O time já identificou que a correção deve ocorrer no microsserviço de comunicação, não no filtro de incidentes. Fonte: Ata 09, seção 1.10.5.3.
  • Risco de ordenação e regressão de estado. Como os estados de uma mesma ocorrência são distribuídos em tópicos diferentes, não há garantia de ordem global entre eles — um evento de cancelamento pode chegar antes do de criação. Fonte: Ata 09, seção 1.10.5.2.
  • Incidente real de dual write já ocorrido. Uma ocorrência cancelada no DMS não teve o cancelamento propagado ao Sigode, exigindo carga manual de dados para restabelecer a consistência. É a evidência concreta por trás do risco R08. Fonte: Ata 09, seção 1.10.6.6.
  • Janela de sincronização GIS→ADMS sem SLA (R09). Confirmado por escrito pela própria equipe do GIS que a etapa manual de sincronização de ChangeSets não tem SLA definido — é a causa mais direta dos eventos tardios que este fluxo precisa reconciliar. Fonte: integracao-gis-adms.md, seção "Confirmações e achados novos (31/08/2026)"; matriz de riscos, R09.

2. O que está pendente

2.1 Mecanismo de reabertura — sem artefato

Nenhuma das duas fontes técnicas (Ata 09 ou os 8 diagramas de fluxos-atendimento-adms.md) descreve o que acontece quando um incidente já fechado precisa reabrir. Não há diagrama, tópico ou regra de negócio documentada para esse caso.

2.2 Conciliação de eventos tardios e duplicidade — sem desenho

R09 confirma que a janela GIS→ADMS gera eventos tardios e duplicidade como consequência (ver Seção 1.5). O que falta não é confirmar que o problema existe — é desenhar o mecanismo de conciliação: o que o fluxo deve fazer quando um evento chega depois do incidente já ter sido fechado ou quando duas entradas terminam representando a mesma ocorrência.

2.3 Ambiguidade Sigode vs. MsAttFiltroIncidentes

Ver Seção 1.2. Confirmação simples (quem publica o quê), mas precisa acontecer antes de qualquer decisão de redesenho que dependa de saber onde intervir.

2.4 Consistência transacional (dual write) — R08, sem decisão

Duas propostas concorrentes já rascunhadas, nenhuma validada com a Energisa: Outbox + captura XStream customizada e Oracle AQ ponto-a-ponto. São mutuamente exclusivas para o mesmo hop (MsAttOcorrenciaTecnica → MsCrmMiddleware) — a escolha depende de confirmar se esse tópico é hoje estritamente ponto-a-ponto.

2.5 O que o addendum de 24/07 não cobre

O addendum de 24/07 (com Izabooh) fechou o fluxo de Desligamento Programado — um fluxo diferente e mais estreito, acionado por CronJob, não pelo ciclo de vida de um incidente técnico. status-sessoes.md já registra isso explicitamente: não tratar como o retorno concluído com Érica. Mantido aqui para não deixar a ressalva implícita.

2.6 Notificação proativa do ADMS ao CRM (D3.4) — depende deste artefato

A recomendação D3.4 (publicar o incidente no barramento assim que detectado, para o CRM consultar antes de abrir chamado novo) foi registrada como dependente de D3.3 — só faz sentido redesenhar a regra de geração de incidente depois deste fluxo estar documentado e validado. Fonte: recomendacoes-preliminares.md, domínio D3.

3. Perguntas para a sessão com Érica

  1. Atribuição: o papel de agregar e republicar os 7 tópicos de estado é do Sigode ou do MsAttFiltroIncidentes? (idealmente confirmar antes com Izabooh ou Lucas, e trazer a resposta como ponto fechado)
  2. Reabertura: hoje, o que acontece operacionalmente quando um incidente fechado precisa reabrir? Existe um processo manual, ou isso simplesmente não acontece na prática?
  3. Conciliação de eventos tardios: quando o GIS entrega um evento depois do incidente já fechado, o que deveria acontecer? Reabrir automaticamente, gerar um novo incidente vinculado, ou outro tratamento?
  4. Duplicidade: como o negócio hoje identifica e resolve dois incidentes que na prática são a mesma ocorrência?
  5. Consulta prévia do CRM ao ADMS (D3.4): o CRM tem hoje algum mecanismo de consulta ao ADMS antes de abrir um chamado novo, ou o fluxo é estritamente unidirecional (ADMS → CRM)?
  6. Dual write (R08): entre Outbox+XStream (Proposta 1) e Oracle AQ ponto-a-ponto (Proposta 2), qual direção faz mais sentido para a Energisa — e o tópico crm_registra_ocorrencia_sistema_tecnico é de fato estritamente ponto-a-ponto hoje?

Rastreabilidade

Onde O quê
matriz-achados-lacunas.md Achado "Agrupamento de incidentes pelo ADMS e retorno ao CRM podem produzir inconsistência processual..."
matriz-riscos-consolidada.md R08 (dual write/correlation ID), R09 (janela GIS), R14 (DLQ, WFM/eForce), R42 (dado pessoal sem schema)
recomendacoes-preliminares.md Domínio D3, recomendações D3.3 e D3.4
status-sessoes.md Linha "Érica (CRM, OMS, ADMS e integrações)"

Ver também