Transformação dos processos de implantação
Como identifiquei e liderei o redesenho de um fluxo de implantação fragmentado pela automação.
Resumo
Resumo executivo
A Alper Seguros automatizou três tipos de implantação numa ferramenta de BPMN contratada antes do discovery. O fluxo de Nomeação, o mais complexo, saiu fragmentado em números de processo que a BU não conseguia acompanhar; assumi o diagnóstico e liderei o redesenho, aprovado pela BU mas ainda pendente de implementação quando encerrei minha atuação no projeto.
Cliente
BU de Benefícios
Ano
2025–2026
Papel
Product Designer
Ferramentas
Figma, AlperFlow, Google Sheets, Azure DevOps
- Plataforma
- AlperFlow (ferramenta de BPMN)
- Usuários
- Analistas de implantação e áreas envolvidas (comercial, relacionamento, backoffice)
- Escopo
- Automação de três tipos de implantação, com foco no redesenho do fluxo de Nomeação
- Contribuição
- UX, discovery e redesenho de fluxo em uma squad com PO, Tech Lead e consultor de BPMN
Contexto
Contexto do projeto
Este projeto aconteceu na carteira corporate da Alper Seguros, a partir de 200 vidas. Implantação é o processo de vincular um cliente a uma operadora de saúde, odontológica ou de seguro de vida. Existem três tipos: Abertura de Subestipulante (um CNPJ novo entra sob um estipulante já existente), Nomeação (a corretora passa a administrar contratos que o cliente já tinha, sem trocar de operadora) e Tombamento (as mesmas vidas migram para uma nova operadora). O foco é Nomeação, o mais complexo.
AS IS, macro, dos três tipos de implantação: da venda do contrato até o encerramento, passando por conferência de documentação, cadastros internos e passagem de bastão pra operação.
Desafio
Como digitalizar e padronizar os três tipos de implantação sem perder a visibilidade do andamento de cada uma?
Restrições
Restrições do projeto
A automação dos três tipos rodou numa ferramenta de BPMN contratada antes do discovery.
Ferramenta de BPMN obrigatória
Todos os fluxos precisavam rodar na AlperFlow, então o desenho seguiu o que a ferramenta consegue executar. O efeito pesou mais em Nomeação, o fluxo mais complexo (ver Decisões).
Dependência do consultor
A squad não dominava a ferramenta no início e dependia do consultor para traduzir cada fluxo para as regras do BPMN, inclusive na separação por produto (ver Decisões).
Sem baseline de SLA
As respostas sobre o tempo de cada etapa variavam demais entre analistas, então não há comparação com o processo antigo. A evidência vem só do acompanhamento da produção assistida (ver Em números).
Meu papel
Meu papel
Entrei na squad desde o início como UX, do mapeamento do AS IS ao redesenho do fluxo de Nomeação. Com a V1 em produção assistida, identifiquei que a fragmentação em subprocessos tirava a visibilidade que a BU também sentia faltar, e assumi a liderança do diagnóstico e do redesenho.
Decisões
Decisões de produto
O raciocínio por trás de cada escolha, incluindo o problema, as alternativas consideradas e por que a decisão final fazia mais sentido.
Reverter a modelagem de subprocesso por tarefa, mantendo a apólice como exceção
Problema
Nomeação chegava a 17 números de processo por implantação, porque cada tarefa tinha sido modelada como subprocesso. Ninguém via o fluxo macro de dentro de um subprocesso, nem o que acontecia dentro dele a partir da visão macro, e a gestão mantinha uma planilha paralela para rastreá-los.
Decidi
Voltar a modelar as tarefas como tarefas, mantendo subprocesso só no nível da apólice, e confirmar a viabilidade técnica com um novo consultor antes de apresentar à BU.
Em vez de
Reabrir a discussão de como o processo de Nomeação deveria funcionar do zero.
Porque
A modelagem por subprocesso causava a fragmentação, então corrigi-la era mais direto do que rediscutir o processo.
Trade-off aceito
Abri mão de consolidar tudo num único número de processo, o que simplificaria a leitura, para manter um subprocesso por apólice e preservar o ritmo independente entre elas.
Antes × Depois
V1, em produção
Cada tarefa modelada como subprocesso
Apólice 1
Apólice 2
1 pai + 8 subprocessos por apólice, numa implantação com duas apólices
V2, proposta
Subprocesso só no nível da apólice
Apólice 1
Apólice 2
1 pai + 1 subprocesso por apólice, na mesma implantação
Impacto esperado
- A proposta reduz de 9 para 2 os números de processo por apólice (de 17 para 3 numa implantação com duas apólices).
- Foi aprovada pela BU, mas a implementação dependia de uma nova rodada de aprovação que não aconteceu antes de eu sair, e não há dado de produção para confirmar o resultado.
Outras decisões
- Separei a proposta de Nomeação em dois fluxos por produto, Vida e Saúde/Odonto, seguindo a orientação do consultor, porque os formulários pedem etapas diferentes. Isso duplicou parte da lógica, em troca de manutenção isolada.
- Deixei as melhorias de UX dos formulários para uma fase posterior, para apresentar a proposta do fluxo ao comitê primeiro. O problema relatado pela BU, de campos confusos e preenchimento errado ou em branco em etapas com mais de 30 campos (algumas passam de 200), ficou pendente.
Solução proposta
A proposta de redesenho
Um processo pai com um subprocesso por apólice, separado em duas versões por produto, Vida e Saúde/Odonto.
Clique em qualquer fluxograma abaixo para abrir em tela cheia, com zoom e arraste.
TOBE Nomeação — Vida
Proposta de redesenho para o produto Vida, com um subprocesso por apólice.
TOBE Nomeação — Saúde e Odonto
Mesma lógica de redesenho aplicada ao fluxo de Saúde e Odonto, com etapas e formulários próprios do produto.
Evidência
O que os dados mostraram
Acompanhamento da produção assistida dos três fluxos entre abril e julho de 2026, com o prazo médio de 45 dias como referência de atraso.
Implantações de Nomeação monitoradas
30 em andamento, 22 atrasadas e 1 finalizada, entre abril e julho de 2026.
Taxa de atraso em Nomeação
A maior taxa de atraso entre os três fluxos monitorados.
Taxa de atraso em Abertura de Subestipulante
O fluxo mais simples dos três, com 50 implantações finalizadas no mesmo período.
Números de processo por apólice em Nomeação
Um processo pai mais 8 subprocessos, chegando a 17 números numa implantação com duas apólices.
A diferença de atraso (42% em Nomeação contra 17% em Abertura de Subestipulante) aparece ligada à complexidade do fluxo e à fragmentação em vários números, sem isolar o peso de cada fator. Só 1 das 53 implantações tinha sido finalizada, o que fez do redesenho de Nomeação a prioridade.
Aprendizados
Aprendizados
Automatizar um processo manual não garante controle sobre o resultado sem revisão técnica constante ao longo do caminho.
- Contratar a ferramenta antes de entender o problema tem custo silencioso. O discovery vira adaptação à ferramenta, e quem aprova o investimento precisa saber disso cedo.
- Risco de fornecedor externo precisa ser mapeado. Quando o fluxo depende de tradução técnica externa, a complexidade do fluxo e a capacidade de quem traduz são riscos a mapear antes da entrega.
- Débito de homologação aparece tarde. Lembrar a importância da homologação nas reviews não substitui reservar agenda para ela com a mesma prioridade das outras entregas.
- Nem toda fragmentação é o problema. A solução foi separar a que dava autonomia da que só confundia.
Próximos passos
O que vem a seguir
Quando encerrei minha atuação, a V2 estava aprovada pela BU, mas a implementação dependia de uma nova rodada de aprovação. Uma pesquisa de percepção com a BU estava planejada, e não tenho confirmação de que foi aplicada. Os passos seguintes são:
- Aprovar a implementação da V2. Fechar a rodada de aprovação pendente.
- Medir o impacto depois da implementação. Comparar o número de processos por apólice e a taxa de atraso antes e depois.
- Revisar o fluxo de Tombamento. Avaliar se também precisa de ajuste.
- Aplicar as melhorias de UX nos formulários. Retomar a frente que ficou fora da V2.