Automatizar um processo mal conhecido tende a esconder problemas, não a resolvê-los. Antes de escolher uma ferramenta, o gabinete precisa de perceber como o trabalho acontece na prática: onde começa, que informação recebe, quem intervém, que decisões são tomadas, onde surgem exceções e qual é o resultado esperado.
Este artigo não é uma lista genérica de tarefas que “podem ser automatizadas”. É um método de levantamento para construir um mapa utilizável pela equipa e por quem vier a configurar a automatização. O objetivo é terminar com processos delimitados, fluxos validados, responsabilidades explícitas e uma lista de prioridades justificável.
Como mapear processos antes de automatizar?
Para mapear processos num gabinete de contabilidade antes de automatizar:
- escolha um processo concreto e defina o início e o fim;
- faça um SIPOC para identificar fornecedores, entradas, etapas, saídas e destinatários;
- observe uma execução real e desenhe o fluxo atual, sem o embelezar;
- registe decisões, exceções, retrabalho, sistemas e evidências;
- atribua responsável, validador e substituto;
- valide o mapa com quem executa o trabalho;
- priorize com base em frequência, tempo, estabilidade, risco e esforço de implementação;
- só depois descreva o fluxo futuro e avalie a automatização.
O resultado mínimo deve ser uma ficha por processo, um fluxograma simples, um catálogo de exceções e uma matriz de priorização.
1. Começar por um processo, não por um departamento
“Fiscalidade”, “contabilidade” ou “recursos humanos” são áreas demasiado amplas para mapear numa sessão. Um processo tem um evento inicial, um resultado final e um destinatário desse resultado.
Em vez de “mapear o trabalho fiscal”, escolha algo como “recolher e validar documentos necessários para uma obrigação periódica”. O início pode ser a abertura do período de recolha; o fim, a documentação validada e disponível para revisão. Esta delimitação impede que o mapa se transforme numa lista interminável de tarefas relacionadas.
Registe logo quatro elementos:
- nome do processo, escrito com verbo e resultado;
- evento inicial, que desencadeia o trabalho;
- evento final, que prova que terminou;
- unidade de análise, por cliente, obrigação, colaborador ou período.
O mapeamento de processos é uma representação visual das etapas e ajuda a tornar visíveis atividades, decisões e intervenientes.[2] O valor do exercício está em retratar o processo real, não o procedimento que a equipa gostaria de ter.
2. Fazer primeiro um SIPOC de uma página
O SIPOC oferece uma visão de alto nível antes do fluxograma detalhado. A sigla organiza Suppliers, Inputs, Process, Outputs e Customers: fornecedores, entradas, processo, saídas e clientes ou destinatários.
Num gabinete, “cliente” no SIPOC não significa apenas o cliente externo. Pode ser o contabilista certificado que valida, outro departamento que recebe a informação ou a pessoa que prepara a etapa seguinte.
| Campo SIPOC | Pergunta a fazer | Exemplo genérico no gabinete |
|---|---|---|
| Fornecedores | Quem disponibiliza informação ou acesso? | Cliente, colega, portal público, software de origem |
| Entradas | O que tem de existir para começar? | Documento, autorização, credencial, ficheiro, prazo |
| Processo | Quais são as 5 a 7 macroetapas? | Receber, conferir, completar, processar, validar, arquivar |
| Saídas | Que resultado e evidência são produzidos? | Documento validado, estado atualizado, comprovativo |
| Destinatários | Quem usa ou aprova a saída? | Cliente, responsável técnico, equipa seguinte |
Não detalhe todas as variantes nesta fase. Se a equipa discute durante vinte minutos se o processo começa “quando o cliente envia” ou “quando o gabinete pede”, essa divergência já é um achado: faltava uma definição comum.
3. Levantar o trabalho como ele acontece
Um procedimento escrito raramente mostra atalhos, folhas auxiliares e verificações informais. Combine três métodos:
- entrevista curta com quem executa e com quem valida;
- observação de um caso real, com dados sensíveis protegidos;
- análise das evidências, como listas de controlo, modelos de email, pastas, estados e registos do sistema.
Peça à pessoa que execute o processo e explique o que decide. Prefira perguntas abertas: “o que acontece a seguir?”, “como sabe que está correto?” e “o que faz quando falta este elemento?”.
Registe, para cada passo:
- entrada utilizada e saída criada;
- sistema, portal, ficheiro ou canal usado;
- pessoa que executa e pessoa que valida;
- regra de decisão;
- evidência de conclusão;
- espera, devolução ou repetição;
- exceções conhecidas.
Confirme também o que muda em fechos, picos de trabalho, férias e indisponibilidades externas.
4. Desenhar um fluxo que a equipa consiga ler
Não é necessário começar com uma notação complexa. Use poucos símbolos: oval para início e fim, retângulo para atividade, losango para decisão, seta para sequência e raias para separar responsáveis ou sistemas.
A BPMN é uma especificação formal para modelar processos de negócio, publicada pelo Object Management Group.[3] Pode ser útil em integrações complexas, mas, no primeiro levantamento, a legibilidade é prioritária.
Um fluxo simples pode seguir esta lógica:
Pedido ou evento recebido → verificar entradas → estão completas? → não: pedir elementos e aguardar → sim: executar tratamento → validar resultado → corrigir se necessário → registar conclusão e arquivar evidência.
Inclua as esperas. “Aguardar resposta do cliente” ou “aguardar disponibilidade do portal” não é espaço em branco: é parte do processo e influencia prazo, acompanhamento e desenho da futura automatização. O mapeamento do fluxo de valor, por exemplo, torna visível o fluxo de informação necessário para entregar um resultado, e não apenas as tarefas executadas.[4]
Antes de fechar, percorra o diagrama com um caso normal e dois casos problemáticos. Se não for possível localizar no mapa o que acontece a cada caso, o fluxo ainda não está pronto.
5. Criar um catálogo de exceções
A exceção não deve ficar numa nota lateral com “tratar manualmente”. Para cada ocorrência, documente:
| Campo | O que registar |
|---|---|
| Gatilho | Condição que desvia o caso do fluxo normal |
| Deteção | Como e em que etapa é identificada |
| Impacto | Prazo, qualidade, risco, cliente ou trabalho adicional |
| Tratamento | Passos para resolver, devolver ou escalar |
| Responsável | Quem decide e quem executa |
| Evidência | Onde fica registado o desfecho |
| Recorrência | Pontual, ocasional ou frequente, com medição futura |
Separe quatro tipos: entrada incompleta, regra de negócio não cumprida, falha técnica e caso que exige julgamento profissional. Esta separação ajuda a decidir o que pode ser validado automaticamente, o que deve gerar uma tarefa e o que tem de continuar sob decisão humana.
Este catálogo evita desenhar apenas o “caminho feliz”. Consulte também o guia sobre gestão de exceções na automatização fiscal.
6. Definir responsáveis antes de discutir tecnologia
Cada processo precisa, no mínimo, de:
- uma pessoa responsável pela execução;
- uma pessoa com autoridade para validar ou decidir;
- um substituto para ausências;
- um ponto de escalamento para exceções.
Atribua papéis às etapas, não apenas ao processo inteiro, para reduzir zonas cinzentas nas passagens de trabalho.
A matriz de responsabilidades para gabinetes de contabilidade pode complementar o fluxograma. O mapa mostra a sequência; a matriz esclarece quem executa, valida, é consultado e deve ser informado.
7. Priorizar processos com critérios observáveis
Nem tudo o que é repetitivo deve ser automatizado primeiro. Um processo frequente, mas instável e cheio de decisões não documentadas, pode ser uma pior escolha do que um processo mais pequeno, estável e bem delimitado.
Atribua uma pontuação de 1 a 5 a cada critério, mantendo a mesma definição para todos os processos:
| Critério | Pontuação alta significa |
|---|---|
| Frequência | O processo ocorre muitas vezes no período analisado |
| Tempo manual | Consome bastante trabalho por ocorrência ou no total |
| Padronização | Segue regras claras e entradas previsíveis |
| Estabilidade | Regras e passos não mudam constantemente |
| Retrabalho | Há devoluções, repetições ou correções relevantes |
| Criticidade | Uma falha tem impacto operacional ou no serviço ao cliente |
| Qualidade dos dados | As entradas são estruturadas e suficientemente completas |
| Esforço de implementação | Use escala invertida: maior pontuação para menor esforço |
Registe a evidência e a incerteza de cada avaliação. Sem medições, marque a pontuação como hipótese e recolha dados. Consulte os KPIs para gabinetes de contabilidade e o guia de ROI da automatização.
Uma boa primeira prioridade combina volume relevante, regras explícitas, entradas controláveis e resultado verificável. Processos críticos exigem controlos, validação e contingência proporcionais.
8. Validar o mapa e desenhar o estado futuro
Valide o mapa com execução, validação e gestão, usando casos reais. Confirme que:
- os limites estão claros;
- nenhuma etapa ou sistema ficou omitido;
- as decisões têm regras compreensíveis;
- as exceções têm tratamento e responsável;
- o resultado final e a evidência estão definidos;
- as dependências externas são visíveis.
Só então desenhe o fluxo futuro. Marque cada passo como eliminar, simplificar, normalizar, automatizar ou manter com intervenção humana. Esta ordem é importante: automatizar uma aprovação duplicada ou uma transcrição desnecessária apenas torna o desperdício mais rápido.
Ao avaliar o Decimus, use estes mapas para partir de processos, entradas, controlos e exceções reais.
Checklist final antes de automatizar
- [ ] O processo tem início, fim e resultado mensurável.
- [ ] O SIPOC cabe numa página e foi validado.
- [ ] O fluxo atual foi observado num caso real.
- [ ] Sistemas, ficheiros, canais e esperas estão identificados.
- [ ] Decisões e respetivas regras aparecem no diagrama.
- [ ] Exceções têm gatilho, tratamento, responsável e evidência.
- [ ] Execução, validação, substituição e escalamento estão atribuídos.
- [ ] Existem dados ou hipóteses explícitas para a priorização.
- [ ] O fluxo futuro elimina e simplifica antes de automatizar.
- [ ] A equipa sabe como confirmar se o resultado automatizado está correto.
Perguntas frequentes
Quanto detalhe deve ter o mapa de processo?
Detalhe suficiente para outra pessoa compreender a sequência, as decisões, as exceções e as responsabilidades. Se o diagrama se tornar ilegível, mantenha um fluxo principal e crie subprocessos separados para os blocos mais complexos.
É obrigatório usar SIPOC e BPMN?
Não. O SIPOC é útil para delimitar o processo e a BPMN pode dar rigor ao fluxo, mas o objetivo é criar um mapa partilhado e verificável. Um fluxograma simples e consistente é preferível a uma notação sofisticada que ninguém na equipa consegue manter.
Quem deve participar no levantamento?
Quem executa, quem valida e alguém com visão sobre prioridades e risco. Se o processo depende de atendimento, informática ou de outro departamento, inclua essas perspetivas nas etapas relevantes.
Como tratar processos diferentes para cada cliente?
Mapeie primeiro o percurso comum. Depois agrupe variantes por causas concretas, como tipo de entrada, regra aplicável, canal ou necessidade de validação. Evite criar um fluxo por cliente quando várias diferenças podem ser descritas como regras ou exceções.
Qual é o melhor processo para automatizar primeiro?
Não existe uma resposta universal. Prefira um processo delimitado, frequente, baseado em regras, com entradas suficientemente controladas e resultado verificável. Confirme também o impacto, o esforço, as exceções e a capacidade da equipa para acompanhar o novo fluxo.
Transformar o levantamento num plano de automatização
Um bom mapa não é documentação para arquivar. É a base para escolher prioridades, definir controlos, preparar testes e comparar o processo anterior com o futuro. Se o seu gabinete já identificou um processo e quer perceber como pode ser centralizado ou automatizado, contacte a Robosoft e leve consigo o SIPOC, o fluxo, o catálogo de exceções e a matriz de responsabilidades.
Sources
[2] https://www.ibm.com/think/topics/process-mapping — What is process mapping? — IBM [3] https://www.omg.org/spec/BPMN/2.0.2 — Business Process Model and Notation 2.0.2 — OMG [4] https://www.lean.org/lexicon-terms/value-stream-mapping — Value-stream mapping — Lean Enterprise Institute
