Estudo de Caso: Orquestração de Onboarding reduziu o lead time em 72% numa instituição financeira

O processo de onboarding de clientes desta instituição financeira envolvia múltiplos sistemas — CRM, KYC/AML, scoring e core bancário — além de várias tarefas manuais com reentrada de dados. Em seis semanas, a equipa redesenhou o fluxo de ponta a ponta com BPMN 2.0, DMN e integrações API-first, alcançando ganhos expressivos em tempo, qualidade e custo.

Contexto inicial

• Onboarding sujeito a validações legais e operacionais (KYC/AML, verificação documental, scoring e abertura de conta).
• Integrações fragmentadas entre CRM, plataformas de verificação e core bancário.
• Tarefas manuais repetitivas (upload de documentos, conferência, introdução dupla de dados).
• Ausência de telemetry unificada e pouca visibilidade sobre gargalos.

Principais desafios

• Gargalos na verificação documental e validação de identidade.
• Erros de reentrada que geravam retrabalho e atrasos.
• Dependências assíncronas com serviços externos (KYC, credit bureaus).
• Exceções mal governadas, tratadas ad hoc por email e planilhas.

Abordagem de transformação

1. Modelação do fluxo em BPMN 2.0: desenho do processo end-to-end (solicitação → verificação → decisão → abertura → ativação) com Service Tasks, Message Events e Timer Boundary Events para SLAs.
2. Externalização de regras em DMN: decisões de segmentação, risk-based approach, scoring thresholds e exigências documentais por perfil de risco.
3. Integrações API-first: contratos claros, idempotency keys, circuit breakers e retry with backoff.
4. Case management para exceções: abertura automática de cases CMMN quando há inconclusivos, suspeitas de fraude ou documentação incompleta.
5. Telemetria e logs centralizados: correlationId, traceparent, métricas por etapa, event store e dashboards.

Arquitectura de referência (alto nível)

• Orquestrador BPMN (motor de processos) a publicar comandos e a reagir a eventos de serviços internos e externos.
• Motor DMN para decisões (document checklist, scoring policy, STP eligibility).
• API Gateway com rate limiting, authn/authz e observability.
• Event broker para mensagens assíncronas e decoupling entre domínios.
• Case management (CMMN) para exceções, com SLAs e workbaskets por equipa.

Resultados principais

• Lead time -72%, de ~3 dias para < 1 dia.
• STP (Straight Through Processing) subiu de 54% para 91%.
• Reclamações -35% e custos operacionais -18%.
• Telemetria e logs centralizados por passo, com rastreabilidade ponta a ponta.
• Exceções tratadas via case management com SLAs e playbooks definidos.

Como o BPMN acelerou o fluxo

O BPMN tornou explícitos os pontos de decisão, dependências assíncronas e tempos máximos de resposta. Timer Boundary Events disparam escaladas e caminhos alternativos quando serviços externos excedem o SLA. Message Intermediate Events desacoplam chamadas a KYC/AML e scoring, evitando blocking e permitindo parallelization sempre que seguro.

Trechos de processo (pseudo)

• Parallel gateway para correr KYC e scoring em simultâneo.
• Event subprocess para cancelamentos e timeouts globais.
• Escalation events para intervenção humana quando documentos são inconclusivos.

DMN: decisões transparentes e auditáveis

Regras críticas foram extraídas para DMN, garantindo transparência e facilidade de alteração sem mexer no fluxo. Exemplos: matriz de documentos por risco, limiares de scoring por segmento e elegibilidade STP.

Exemplo simplificado de decisão (JSON)

{
  "decision": "STPEligibility",
  "input": {
    "riskTier": "MEDIUM",
    "score": 685,
    "pepMatch": false,
    "docsComplete": true
  },
  "rules": [
    { "when": {"pepMatch": true}, "then": "REVIEW" },
    { "when": {"docsComplete": false}, "then": "REVIEW" },
    { "when": {"riskTier": "LOW", "score": {">=": 640}}, "then": "STP" },
    { "when": {"riskTier": "MEDIUM", "score": {">=": 680}}, "then": "STP" },
    { "when": {"riskTier": "HIGH"}, "then": "REVIEW" }
  ],
  "result": "STP"
}

API-first: integrações previsíveis e seguras

• Contratos versionados e validados (schema-first).
• Idempotency keys para evitar efeitos duplicados.
• Retry com exponential backoff e jitter para falhas transitórias.
• Circuit breakers e timeout por integração.

Exemplo de pedido a KYC (JSON)

{
  "requestId": "REQ-2025-000981",
  "correlationId": "ONB-7f3c9c12",
  "customer": {
    "name": "João Almeida",
    "nationalId": "XXXXXXXXX",
    "dob": "1988-04-19"
  },
  "documents": [
    { "type": "ID_CARD_FRONT", "uri": "s3://bucket/id-front.png" },
    { "type": "ID_CARD_BACK",  "uri": "s3://bucket/id-back.png" }
  ],
  "idempotencyKey": "idem-4f23b9b1"
}

Telemetria e observabilidade

Foi estabelecido um event store com correlationId e traceparent propagados do canal digital ao core. Métricas de negócio e técnicas foram agregadas em dashboards (lead time por etapa, percentil p95, taxa de STP, taxa de exceções por motivo, reentregas).

Evento de processo (JSON)

{
  "event": "KYCCompleted",
  "timestamp": "2025-03-12T10:21:44Z",
  "correlationId": "ONB-7f3c9c12",
  "traceparent": "00-4b7c3e2da2b1d...-01",
  "payload": {
    "customerId": "C-102344",
    "result": "PASS",
    "providerLatencyMs": 842
  },
  "metrics": {
    "stageLeadTimeMs": 12980,
    "retries": 1
  }
}

Gestão de exceções com case management

Quando a decisão DMN retorna REVIEW ou ocorre um timeout crítico, o orquestrador abre um case CMMN com tarefas humanas, sentries e SLAs específicos. Isto evita paralisação do fluxo principal e melhora a previsibilidade.

Abertura automática de case (JSON)

{
  "command": "OpenCase",
  "correlationId": "ONB-7f3c9c12",
  "caseType": "KYC_REVIEW",
  "priority": "HIGH",
  "slaHours": 8,
  "attachments": [
    { "name": "id-front.png", "source": "kycProvider" },
    { "name": "id-back.png",  "source": "kycProvider" }
  ],
  "reason": "DOCS_INCONCLUSIVE"
}

Medição antes & depois

Controlo de risco & conformidade

• Risk-based approach refletido em DMN com audit trail.
• Privacy-by-design: minimização de dados e mascaramento em logs.
• Segregation of duties em casos de review manual.
• Retention policies por tipo de evento e documento.

Patamares operacionais (SLA/OLAs)

• KYC assíncrono com Timeout de 15 minutos e retry controlado.
• Scoring com p95 de 2s; alerta a partir de 5s.
• Abertura de conta em < 30s no core; fallback para fila se indisponível.

Boas práticas implementadas

• Decoupling com eventos e comandos assíncronos.
• Idempotência por idempotencyKey e operationId.
• Outbox pattern para entrega confiável de mensagens.
• DLQ com playbook de reprocessamento e reconciliação.
• Observabilidade com trace distribuído e métricas de negócio.

Anti-padrões evitados

1. Fluxo monolítico com dependências síncronas longas.
2. Regras enterradas no código do orquestrador (em vez de DMN).
3. Gestão de exceções por email sem SLAs.
4. Ausência de correlationId, dificultando auditoria.

Lições aprendidas

• Design first: alinhar negócio, risco e TI em torno de BPMN/DMN acelera a entrega.
• Small batches: entregar em incrementos semanais reduz risco e encurta feedback.
• Telemetria desde o dia 1: o que não se mede não se melhora.
• Case management para o 9% não-STP: foco da operação onde mais importa.

Conclusão

Com orquestração, a instituição passou a medir, melhorar e escalar o onboarding sem depender de robots ou retrabalho manual. BPMN 2.0 tornou o fluxo claro; DMN deu agilidade às decisões; integrações API-first reduziram erro e latência; e o case management disciplinou as exceções. O resultado: -72% de lead time, STP de 91%, -35% de reclamações e -18% de custos operacionais — com telemetria e governança à altura de um ambiente financeiro.

You may also like

Sagas e Compensações: orquestração por eventos sem drama

October 28, 2025

Orquestração vs RPA: o que usar e quando largar o robot

October 28, 2025

Pega em detalhe: plataforma low-code com decisão e orquestração para operações em grande escala

October 28, 2025