Capítulo 19 — BPM — Gestão de Processos

19.1 Objetivo do Capítulo

Este capítulo detalha o módulo de BPM — Business Process Management — da Plataforma de Relacionamento Digital com o Cidadão, descrevendo como os processos institucionais associados aos serviços públicos são modelados, versionados, publicados, executados, monitorados e evoluídos ao longo do ciclo de vida da parceria.

O BPM não é uma ferramenta de desenho de fluxogramas. É o mecanismo que conecta a submissão de uma solicitação ao conjunto de atividades humanas, automatizadas e integradas necessárias para produzir um resultado formal ao cidadão — rastreável, com prazos controlados e auditável em cada etapa.

19.2 Papel do BPM na Plataforma

O BPM articula os demais módulos da plataforma em torno do resultado do serviço prestado ao cidadão:

Cidadão submete solicitação
    │
Request Service publica request.submitted.v1
    │
Workflow Service inicia instância do processo correspondente
    │
┌─────────────────────────────────────────────────────┐
│  PROCESSO EM EXECUÇÃO                                │
│                                                      │
│  Etapa automática → aciona Integration Service      │
│  Etapa humana     → cria Tarefa para analista       │
│  Decisão          → avalia variáveis do processo    │
│  Timer            → aguarda prazo ou confirmação    │
│  Evento externo   → reage a resultado de integração │
│                                                      │
└─────────────────────────────────────────────────────┘
    │
Instância concluída → atualiza status da solicitação
    │
Communication Service notifica o cidadão
    │
Evento publicado no Data Lake

O BPM responde pela execução do que foi prometido quando o serviço foi modelado e publicado. A qualidade do processo define a qualidade do serviço percebida pelo cidadão.

19.3 Princípios do BPM

1. Processo como contrato — a definição publicada de um processo é um contrato com o cidadão e com os executores internos; mudanças não corrompem instâncias ativas;
2. Separação modelagem / execução — a ferramenta de modelagem não é o motor de execução; o modelo desenhado é compilado para uma definição executável;
3. Versão preservada — cada instância executa na versão em que foi iniciada, independentemente de versões mais novas do mesmo processo;
4. Rastreabilidade total — cada transição de estado, decisão, execução de tarefa e violação de prazo é registrada com data, responsável e resultado;
5. Separação BPM / CRM — o BPM controla a execução do processo de negócio; o CRM controla o atendimento ao cidadão; os dois se articulam por eventos sem acoplamento direto;
6. IA como apoio ao processo — a IA pode classificar, resumir ou sugerir ações dentro do processo, mas decisões de negócio são formalizadas pelos atores humanos ou por regras configuradas explicitamente;
7. Configuração por tenant — cada órgão modela e publica seus próprios processos dentro do contexto do seu tenant, sem afetar outros.

19.4 Atores do BPM

19.5 Estrutura Funcional do BPM

O BPM é organizado em quatro áreas funcionais:

┌───────────────────────────────────────────────────────────┐
│  MODELAGEM E PUBLICAÇÃO                                    │
│  Editor visual, versionamento, validação e publicação     │
├───────────────────────────────────────────────────────────┤
│  EXECUÇÃO DE PROCESSOS                                     │
│  Motor, instâncias, variáveis, decisões e timers          │
├───────────────────────────────────────────────────────────┤
│  GESTÃO DE TAREFAS                                         │
│  Tarefas humanas, filas, distribuição e SLA por tarefa    │
├───────────────────────────────────────────────────────────┤
│  MONITORAMENTO E GOVERNANÇA                                │
│  Instâncias ativas, gargalos, SLA global e dashboards     │
└───────────────────────────────────────────────────────────┘

19.6 Modelagem de Processos

19.6.1 Editor Visual

O editor visual oferece ao analista de negócio uma interface para modelar processos sem necessidade de codificação. O editor permite criar, editar e salvar processos em rascunho antes de submetê-los à revisão e publicação.

Elementos modeláveis:

• etapas (automáticas, humanas, de decisão, de integração, de espera);
• transições entre etapas com condições configuráveis;
• formulários vinculados a etapas humanas;
• variáveis de processo com tipo e valor padrão;
• regras de decisão por variável ou condição;
• timers de espera absolutos (data) e relativos (duração);
• acionamentos de integrações externas;
• publicação de eventos;
• configuração de SLA por processo e por etapa;
• responsáveis e grupos por etapa humana.

19.6.2 Tipos de Etapa

19.6.3 Versionamento

Cada processo possui ciclo de vida:

Rascunho → Em revisão → Aprovado → Publicado → Depreciado → Desativado

Cada transição é registrada com data e responsável. Somente versões publicadas são utilizadas para iniciar novas instâncias. Versões anteriores continuam executando suas instâncias ativas até a conclusão natural ou cancelamento explícito.

19.6.4 Validação e Simulação

Antes da publicação, a definição passa por validação: todas as transições têm destino; não existem etapas órfãs; variáveis referenciadas estão definidas; condições de decisão são completas; integrações referenciam configurações existentes.

A simulação permite executar o processo com dados de teste para verificar o fluxo antes da publicação.

19.7 Execução de Processos

19.7.1 Início de Instância

Uma instância é iniciada quando:

• request.submitted.v1 é publicado pelo Request Service;
• um evento configurado é recebido de sistema externo;
• uma etapa de subprocesso de outro processo inicia a instância;
• uma ação administrativa explícita inicia o processo diretamente.

O motor de execução recebe a definição publicada, cria a instância com variáveis iniciais e avança para a primeira etapa.

19.7.2 Contexto de Execução

Cada instância carrega:

ProcessInstance
  id
  tenantId
  processDefinitionId
  processVersion
  requestId          (quando originada de solicitação)
  citizenId
  status
  currentStep
  variables          (mapa de variáveis do processo)
  startedAt
  expectedDeadline
  completedAt

O tenantId está presente em toda instância. O motor nunca inicia instância sem contexto de tenant validado.

19.7.3 Avanço do Fluxo

O motor avança o fluxo após cada etapa:

Etapa automática: executa a ação configurada (publicar evento, chamar integração, atualizar variável) e avança imediatamente ou aguarda confirmação assíncrona.

Etapa de decisão: avalia a condição definida nas variáveis da instância e seleciona a transição correspondente.

Etapa humana: cria tarefa e aguarda. O motor avança quando a tarefa é concluída com resultado.

Timer: o motor registra o deadline e avança quando o prazo chega ou quando o evento esperado ocorre antes do prazo.

19.7.4 Variáveis de Processo

Variáveis transportam estado entre etapas. São tipadas e imutáveis no sentido de que cada atualização cria uma nova entrada no histórico de variáveis — o valor anterior é preservado para auditoria.

Exemplos de variáveis em um processo de análise de documento:

documentId          → string
citizenId           → string
documentClassified  → boolean
classificationResult → enum(VALID, INVALID, REQUIRES_REVIEW)
reviewerAssigned    → string
decisionNote        → text
finalDecision       → enum(APPROVED, REJECTED)

19.7.5 Idempotência

Ações automáticas executadas pelo motor são idempotentes quando necessário. Se o motor executar a mesma etapa mais de uma vez por falha de infraestrutura, o resultado de negócio é o mesmo. Integrações externas recebem o instanceId e o stepId para garantir deduplicação.

19.7.6 Tratamento de Falhas

Falhas em etapas automáticas seguem política configurada: retry com backoff, desvio para etapa alternativa ou suspensão da instância com alerta. Instâncias suspensas por falha são visíveis no painel de monitoramento e requerem intervenção manual para retomada.

19.8 Gestão de Tarefas

19.8.1 Criação de Tarefa

Quando o processo chega a uma etapa humana, o Workflow Service cria uma tarefa via evento task.created.v1, consumido pelo Task Service:

Workflow Service → task.created.v1 → Task Service

A tarefa carrega: processo e instância de origem, tenant, etapa, tipo, responsável ou grupo candidato, formulário vinculado (quando aplicável), variáveis disponíveis para consulta, prazo e prioridade.

19.8.2 Distribuição de Tarefas

O Task Service distribui tarefas por: atribuição direta a usuário específico configurado no processo; atribuição a grupo (qualquer membro do grupo pode assumir); distribuição automática por capacidade ou round-robin dentro do grupo; assumir manual da fila pelo próprio atendente.

19.8.3 Ciclo de Vida da Tarefa

CREATED → ASSIGNED → IN_PROGRESS → COMPLETED
                │                      │
             RETURNED              COMPLETED_WITH_NOTE
                │
            ASSIGNED (novo responsável)

Cada transição registra data, responsável e resultado quando aplicável.

19.8.4 Formulários em Tarefas

Tarefas humanas podem vincular formulários específicos de coleta de decisão. O formulário não é o mesmo formulário de abertura de solicitação — é um formulário de decisão, coleta de complementação ou validação interna. Os dados do formulário são salvos como variáveis da instância ao concluir a tarefa.

19.8.5 Retorno ao Processo

Ao concluir a tarefa, o Task Service publica task.completed.v1, consumido pelo Workflow Service. O motor retoma a execução a partir da etapa seguinte, usando o resultado da tarefa como variável da instância.

19.8.6 SLA de Tarefa

Cada tarefa tem prazo derivado do SLA configurado na etapa do processo. O Task Service monitora o tempo decorrido e:

• emite task.sla-warning.v1 quando o prazo se aproxima;
• emite task.sla-breached.v1 quando o prazo é ultrapassado;
• aciona escalação automática quando configurada.

19.9 SLA de Processo

19.9.1 Configuração

O SLA é configurado em dois níveis:

Processo: prazo total da instância, contado da criação à conclusão. Pode ser um prazo absoluto (ex.: 30 dias corridos) ou relativo ao serviço (ex.: SLA do serviço N).

Etapa: prazo máximo para permanência em uma etapa específica, especialmente etapas humanas e de integração.

19.9.2 Controle e Suspensão

O prazo pode ser suspenso: quando a instância aguarda complementação do cidadão, com data de início e fim de suspensão registradas. O prazo retoma automaticamente quando a complementação é recebida ou quando o prazo de espera pela complementação expira.

19.9.3 Violação e Escalação

Violação de SLA de processo:

Alerta para responsável da instância
    │
Alerta para supervisor da equipe
    │
Registro em dashboard de SLA
    │
Evento sla.breached publicado
    │
Escalação automática (quando configurada)

Métricas de SLA são disponíveis no painel de analytics do tenant por processo, por serviço e por período.

19.10 Integração com Sistemas Externos

Etapas de integração acionam o Integration Service:

Motor Workflow
    │
Publicação de comando de integração (ex.: integration.sei.register.v1)
    │
Integration Service / SEI Adapter
    │
Sistema externo (ex.: SEI!MG)
    │
Resultado publicado como evento (ex.: integration.sei.registered.v1)
    │
Motor Workflow consome e avança instância

Esta comunicação é assíncrona: o processo não bloqueia thread aguardando resposta do sistema externo. O motor aguarda o evento de resultado dentro do tempo configurado (timer de integração). Se o resultado não chega no prazo, o processo trata como falha de integração conforme a política configurada.

19.10.1 Exemplos de Integração em Processos

• registro de processo no SEI!MG;
• consulta de situação cadastral em sistema de registro;
• validação de certidão em serviço externo;
• envio de notificação formal por PRO SMTP;
• registro na ouvidoria estadual (MG-Ouv);
• consulta de débitos em sistemas de trânsito.

19.11 Automação Inteligente com IA

O BPM integra capacidades de IA em etapas específicas do processo, conforme autorização do tenant:

19.11.1 Classificação de Intenção

Ao iniciar um processo, a IA pode classificar automaticamente o tipo de solicitação e pré-preencher variáveis de roteamento, acelerando a chegada à etapa correta.

19.11.2 Sumarização para o Analista

Antes de uma etapa humana, a IA pode gerar um resumo da solicitação, dos documentos e do histórico, apresentado ao analista como contexto inicial. O analista decide — o resumo é informativo.

19.11.3 Análise de Documento

Uma etapa automática pode acionar a IA para extrair campos estruturados de um documento e carregar as variáveis correspondentes. O analista valida o resultado em etapa humana subsequente quando a classificação de risco exige.

19.11.4 Regras e Decisões Automáticas

Etapas de decisão podem ser baseadas em resultados de capacidades de IA quando o tenant define e aprova explicitamente a regra com threshold de confiança. Decisões com confiança abaixo do threshold vão para etapa humana de revisão.

19.12 Monitoramento de Processos

19.12.1 Visão Geral de Instâncias

O gestor operacional visualiza, no contexto do seu tenant:

• instâncias ativas por processo e por estado;
• instâncias em risco de violação de SLA;
• instâncias com SLA violado;
• instâncias suspensas aguardando complementação;
• instâncias com falha de integração;
• volume de instâncias iniciadas e concluídas por período.

19.12.2 Mapa de Processo

Para uma definição de processo, o mapa visualiza: etapas com quantidade de instâncias ativas em cada uma; etapas com maior tempo médio de permanência; transições mais percorridas; decisões com distribuição de saídas.

Este mapa identifica gargalos operacionais com base em dados reais de execução.

19.12.3 Drilldown de Instância

Para uma instância específica, o analista ou gestor visualiza: histórico completo de etapas percorridas com data de entrada e saída; tarefas criadas e seus responsáveis e resultados; variáveis atuais e histórico de alterações; integrações acionadas com resultado; eventos publicados e consumidos; status de SLA.

19.12.4 Reprocessamento

Instâncias com falha podem ser reprocessadas manualmente por usuário com perfil autorizado. O reprocessamento é uma ação auditada: quem, quando, motivo e resultado.

19.13 Modelo de Dados do BPM

ProcessDefinition
  id
  tenantId
  name
  description
  currentVersion

ProcessVersion
  id
  processDefinitionId
  tenantId
  version
  status         (DRAFT, REVIEW, APPROVED, PUBLISHED, DEPRECATED)
  definition     (estrutura executável serializada)
  publishedAt
  publishedBy

ProcessInstance
  id
  tenantId
  processDefinitionId
  processVersionId
  requestId        (referência à solicitação, quando aplicável)
  citizenId
  status           (RUNNING, SUSPENDED, COMPLETED, FAILED, CANCELLED)
  currentStepId
  startedAt
  completedAt
  slaDeadline
  slaSuspendedAt
  slaResumedAt

ProcessVariable
  id
  instanceId
  name
  type
  value
  changedAt
  changedBy

ProcessExecutionHistory
  id
  instanceId
  stepId
  stepType
  enteredAt
  exitedAt
  outcome
  actorId        (usuário ou sistema)
  notes

Timer
  id
  instanceId
  stepId
  triggerAt
  status

19.14 Eventos do BPM

Esses eventos são consumidos por: Request Service (atualização de status da solicitação), Communication Service (notificação ao cidadão), Analytics Service (métricas operacionais), Audit Service (ações sensíveis), Data Lake Ingestion (dados analíticos).

19.15 Integrações do BPM com Outros Módulos

19.16 Configuração do BPM por Tenant

Cada tenant configura seu BPM de forma independente:

• processos próprios com definições específicas do órgão;
• grupos de responsáveis por etapa vinculados aos perfis do IAM do tenant;
• integrações externas específicas do órgão;
• SLA por processo e por etapa conforme política do órgão;
• formulários de decisão específicos;
• regras de automação configuradas pelo tenant.

Processos de um tenant não são visíveis ou executáveis por outro tenant.

19.17 Métricas e Indicadores do BPM

19.18 Rastreabilidade com o Anexo III

O módulo de BPM atende ao Bloco 2 do Anexo III:

19.19 Benefícios do Módulo

• processo como contrato executável com rastreabilidade de cada decisão;
• versionamento que preserva instâncias ativas ao evoluir o processo;
• automação de etapas reduz tempo de ciclo e libera analistas para o que exige julgamento;
• SLA controlado em dois níveis (processo e etapa) com alertas proativos;
• integração assíncrona com sistemas externos sem bloqueio do fluxo;
• IA integrada como apoio à execução, com decisão formal mantida no domínio humano ou em regras configuradas;
• monitoramento com identificação de gargalos baseada em dados reais de execução;
• configuração por tenant sem fragmentar a implementação do motor.

19.20 Riscos e Mitigações

19.21 Decisões Arquiteturais

19.22 Considerações Finais

O BPM transforma a plataforma de um canal de entrada de solicitações em um sistema de gestão completo do ciclo de vida dos serviços públicos. O processo modela o que precisa acontecer; o motor garante que aconteça; o monitoramento evidencia como está acontecendo; e o SLA responsabiliza os atores pelo cumprimento dos prazos acordados com o cidadão.

A separação entre modelagem e execução, o versionamento que preserva instâncias ativas e a integração desacoplada com sistemas externos garantem que o BPM possa evoluir continuamente sem comprometer os processos em curso.

O Capítulo 20 detalha a Arquitetura de Observabilidade, Operação, SRE e Resiliência.

19.23 Controle de Versão

19.24 Rastreabilidade PRODEMGE

• [ANX-III] Bloco 2 — Orquestração de Processos e Workflow: cobertura completa dos itens 2.1 a 2.8 conforme seção 19.18.
• [ANX-IV] — Capacidades técnicas de BPM, execução de workflows, gestão de tarefas, SLA, automação por eventos e integração com sistemas externos.
• [ANX-V] — Sustentabilidade: versionamento de processos, separação modelagem/execução, motor desacoplado do editor, configuração por tenant.
• [PNR] — Plano de Negócio Referencial: plataforma com capacidade de orquestração de processos, automação de fluxos e controle de SLA para serviços públicos digitais.
• [EDITAL] — Edital CP001/2026: módulo de BPM com modelagem, execução, automação, integração e monitoramento de processos de negócio.