NEXUS.
Entrevistas
Com quem executa e com quem gerencia, separadamente. As versões costumam divergir.
Guia · Análise e melhoria de processos
Processo AS IS e TO BE: do como é ao como deve ser
Toda melhoria de processo passa por duas fotografias: a do processo atual (AS IS) e a do processo futuro (TO BE). Veja como produzir cada uma, como medir a distância entre elas e como garantir que o processo novo funcione antes de colocá-lo em operação.
01 · Definição
O que é processo AS IS e TO BE
Resposta rápida
AS IS é o retrato do processo como ele acontece hoje, com exceções, esperas e controles paralelos. TO BE é o desenho do processo como ele deve passar a funcionar, depois da análise. A diferença entre os dois é o plano de melhoria.
- AS IS
- Linha de base: fatos, tempos, volumes, problemas.
- Análise
- Causas, lacunas e oportunidades.
- TO BE
- Processo redesenhado e validado.
- Transição
- Plano, responsáveis e indicadores.
02 · Processo atual
Como levantar o processo AS IS
O AS IS precisa ser fiel, não bonito. As gambiarras e exceções são exatamente o que o projeto precisa enxergar.
Fonte 1
Fonte 2
Observação
Acompanhar a execução real. Revela esperas e controles que ninguém menciona.
Fonte 3
Documentos
Formulários, planilhas paralelas, e-mails de aprovação, POPs existentes.
Fonte 4
Dados de sistema
Datas e volumes do ERP ou CRM para medir tempos, filas e devoluções.
O que registrar no AS IS
- Atividades, decisões e responsáveis, em BPMN com raias por papel.
- Volumes: quantos casos por dia, semana ou mês.
- Tempos: de execução de cada atividade e de espera entre elas.
- Sistemas e documentos usados em cada etapa.
- Exceções e retrabalho: quando e com que frequência o fluxo volta.
- Problemas percebidos pelas equipes, que viram hipóteses para a análise.
03 · Diagnóstico
Análise de lacunas: o que separa o AS IS do TO BE
A análise de lacunas (gap analysis) transforma o diagnóstico numa lista de mudanças concretas.
| Lacuna | Causa (AS IS) | Mudança (TO BE) | Requisito | Responsável |
|---|---|---|---|---|
| Pedidos devolvidos para correção | Cadastro sem campos obrigatórios | Validação na entrada do pedido | Ajuste no sistema | TI + Comercial |
| Fila de aprovação no fim do mês | Aprovador único | Alçadas por valor | Nova política de alçada | Diretoria |
| Retrabalho de conferência | Planilha paralela | Relatório único no sistema | Relatório + treinamento | Controladoria |
Exemplo ilustrativo. Para chegar à causa, e não parar no sintoma, use Ishikawa e 5 Porquês.
04 · Processo futuro
Como desenhar o processo TO BE
Quatro perguntas, nesta ordem, para cada atividade do AS IS.
- 01
Eliminar: esta atividade precisa existir?
Controles duplicados, aprovações sem critério e relatórios que ninguém lê são os primeiros candidatos.
- 02
Simplificar: dá para fazer com menos passos?
Menos campos, menos assinaturas, menos passagens entre áreas.
- 03
Integrar: quem deve fazer, e em que ordem?
Juntar atividades na mesma raia, fazer em paralelo o que não depende uma da outra.
- 04
Automatizar: o que sobrou é repetitivo e baseado em regra?
Só depois das três anteriores. Automatizar desperdício só o torna mais rápido.
O TO BE também é documento: fluxo final, matriz RACI atualizada, POPs e indicadores. Sem isso, a equipe volta ao AS IS em poucas semanas.
Tem um processo que todo mundo sabe que precisa mudar?
Começamos pelo AS IS com a sua equipe e entregamos o TO BE validado em simulação e documentado.
05 · Validação
Validar o TO BE com simulação antes de implantar
Um TO BE bem desenhado ainda pode criar um gargalo novo. A simulação mostra isso antes da mudança.
O que entra
- Fluxo TO BE em BPMN
- Volume de chegada de casos
- Tempos por atividade
- Pessoas e horários por raia
O que sai
- Tempo de ciclo médio e máximo
- Filas e tempo de espera
- Ocupação de cada papel
- Custo por caso
O que você decide
- Qual cenário implantar
- Quantas pessoas em cada etapa
- O que acontece se a demanda crescer
- Onde vale investir em automação
06 · Exemplo
Exemplo comparativo AS IS x TO BE
Exemplo ilustrativo de um processo de aprovação de pedidos, com os indicadores que usamos para comparar os dois cenários.
| Indicador | AS IS | TO BE (simulado) | O que mudou |
|---|---|---|---|
| Atividades | 14 | 9 | Conferências duplicadas eliminadas |
| Passagens entre áreas | 7 | 4 | Atividades agrupadas por raia |
| Aprovações | 3 em sequência | 1 por alçada | Política de alçada por valor |
| Tempo de ciclo | alto, com fila no fim do mês | menor e estável | Fila de aprovação removida |
| Retrabalho | frequente | raro | Validação na entrada |
Nos projetos reais, cada linha traz números medidos no AS IS e simulados no TO BE, que viram as metas da implantação.
07 · Implantação
Plano de transição do AS IS para o TO BE
- 01
Priorize as mudanças
Impacto x esforço. Comece pelo que dá resultado rápido sem depender de sistema.
- 02
Defina responsáveis e prazos
Cada lacuna da análise vira uma ação com dono.
- 03
Atualize a documentação e treine
POPs, RACI e fluxo publicados antes da virada.
- 04
Faça um piloto quando possível
Uma unidade, um turno ou um tipo de pedido.
- 05
Meça contra a linha de base do AS IS
Os mesmos indicadores, antes e depois. Sem isso, não há como provar o ganho.
08 · Armadilhas
Erros comuns em projetos AS IS e TO BE
01AS IS idealizado. Desenhado a partir do POP antigo, não da operação real.
02TO BE sem diagnóstico. Redesenho baseado em opinião, não em causa.
03TO BE inviável. Depende de um sistema ou de pessoas que a empresa não tem.
04Sem linha de base. Ninguém mediu o AS IS e o ganho vira discussão.
05Implantar sem testar. O gargalo muda de lugar e aparece na primeira semana.
06Parar no desenho. Sem plano de transição e documentação, o TO BE fica no papel.
Perguntas frequentes
Dúvidas sobre AS IS e TO BE
01O que significa AS IS e TO BE?
São expressões em inglês. AS IS (“como é”) é o processo atual, do jeito que acontece hoje. TO BE (“como será”) é o processo futuro, redesenhado para resolver os problemas encontrados no AS IS.
02Posso pular o AS IS e desenhar direto o TO BE?
Não é recomendado. Sem o AS IS você não sabe quais problemas está resolvendo, não tem uma linha de base para medir o ganho e corre o risco de repetir no TO BE as mesmas causas dos problemas atuais.
03Quanto detalhe o AS IS precisa ter?
O suficiente para responder à pergunta de negócio do projeto. Se o problema é prazo, registre tempos e esperas. Se é erro, registre controles e retrabalho. Não é preciso documentar cada clique de sistema.
04O que é análise de lacunas (gap analysis)?
É a comparação estruturada entre o AS IS e o TO BE, listando cada diferença: o que muda, por que muda, o que é preciso para mudar (sistema, treinamento, regra, pessoas) e quem é responsável.
05Como saber se o TO BE vai funcionar?
Validando antes de implantar: revisão com quem executa, simulação com volumes e tempos reais e, quando possível, um piloto em escala reduzida. A simulação mostra gargalos que o desenho sozinho não revela.
06Em que notação desenhar o AS IS e o TO BE?
Use a mesma notação nos dois, de preferência BPMN, para que a comparação seja direta e o TO BE possa ser simulado.
Leia também
Outros guias da Nexus
Guia
Mapeamento de processos
Guia completo: etapas, técnicas, exemplo e entregáveis
Guia
BPMN
Guia da notação: elementos, gateways, raias (swimlane) e exemplo
Guia
Ishikawa e 5 Porquês
Análise de causa raiz com diagrama espinha de peixe e exemplo
Guia
SIPOC
A visão de uma página do processo: fornecedores, entradas, etapas, saídas e clientes
Guia
POP – Procedimento Operacional Padrão
Estrutura, modelo e como escrever um POP que a equipe usa
Ferramenta gratuita
Gerador de business case
Monte a justificativa executiva do processo TO BE.
Guia
Análise de processos
Onde o processo perde tempo e dinheiro: etapas, técnicas e exemplo
Nexus Consultoria · Consultoria BPM
Teste o processo futuro antes de mudar a operação
A Nexus mapeia o AS IS com quem executa, diagnostica as causas, desenha o TO BE, valida os cenários em simulação e entrega o plano de transição com a documentação pronta.
Mapeamento e DiagnósticoProcesso AS IS em BPMN 2.0, gargalos e causas apontados.
Análise com SimulaçãoCenários testados antes de mudar a operação.
Documentação de ProcessosSIPOC, RACI, POPs e descrições prontas para a equipe usar.