Mapear processo antes de automatizar sem meses de consultoria

Em resumo
- O dono do processo consegue mapear o que vai automatizar em duas ou três conversas curtas com quem executa, desde que o mapa registre o processo como ele roda de fato, com volume aproximado e exceções anotadas.
- O mapa cabe em uma página, com etapas, responsáveis, volume mensal, tempo de espera e exceções, e se faz em papel, quadro branco ou Visio, sem ferramenta paga.
- A armadilha mais cara é mapear o processo como ele deveria ser e depois automatizar etapas que deviam ter sido eliminadas antes.
- Não vale a pena quando o processo muda toda semana ou quando o volume é tão baixo que o mapa custa mais que o ganho.
- Ao diretor, leve o mapa antes de pedir o orçamento de automação, porque ele decide melhor com o processo desenhado do que com uma proposta sobre algo que ninguém descreveu.
Dá para mapear um processo antes de automatizar sem meses de consultoria?
Dá, e na maior parte dos processos de uma área o que decide a qualidade do mapa é com quem você conversa, não quanto tempo se gasta desenhando. Duas ou três conversas com quem executa o trabalho, o volume real tirado da própria planilha e as exceções anotadas uma a uma produzem um mapa de uma página bom o bastante para decidir o que automatizar e o que simplesmente cortar.
A própria fase de planejamento da documentação do Power Automate trata o entendimento do processo como uma etapa anterior à construção, e não como um projeto à parte: antes de qualquer fluxo vêm o problema de negócio e a compreensão a fundo de como o trabalho acontece. Nada ali exige um levantamento de meses, exige que alguém que conhece a operação responda com honestidade a perguntas simples, e quem faz isso melhor do que o dono do processo é o próprio dono do processo, com a ajuda de quem aperta os botões todos os dias.
O que a fase de planejamento pede, traduzido para o gerente da área
A documentação organiza o planejamento em cinco movimentos: identificar o problema de negócio a resolver, entender a fundo o processo, otimizar o processo com a solução, decidir se vale a pena automatizar e criar um plano de projeto. Para quem não desenvolve, isso se lê como cinco perguntas na ordem certa: o que dói e para quem, como o trabalho roda de verdade, o que dessa rotina deveria deixar de existir, se o ganho paga o esforço e quem faz o quê em que prazo. O mapa de uma página responde bem às duas primeiras e alimenta as outras três, e é por isso que ele vem antes de qualquer pedido de orçamento.
A ordem importa porque a tentação, quando a dor aperta, é pular direto para a ferramenta. O gerente já ouviu que o Power Automate tem recurso nativo de aprovações, e isso é verdade, só que o recurso aprova o que lhe for descrito, então um processo mal entendido vira um fluxo bem executado do jeito errado.
Um caso de aprovação de compras numa indústria de médio porte
Pense numa fábrica de médio porte em que os pedidos de compra de insumos e de peças de manutenção passam por uma planilha compartilhada, com uma linha por pedido. O solicitante preenche, o comprador anexa a cotação, o supervisor da área aprova, o gerente aprova quando o valor passa de uma alçada e a diretoria entra acima de outra. Cada passagem é avisada por e-mail, e quando o pedido trava alguém vai até a mesa do aprovador cobrar, o que na prática é a única forma de acompanhamento que funciona.
O gerente de suprimentos queria automatizar tudo isso e estava pronto para pedir orçamento, mas não conseguia dizer quantos pedidos passavam por mês, quantos fugiam do caminho normal e onde exatamente a espera se acumulava. Em vez de contratar um levantamento, ele fez três conversas curtas, uma com o comprador e dois solicitantes, outra com os aprovadores e outra para devolver o desenho à área. O resultado foi um mapa de uma página com as etapas, o responsável de cada uma, o volume mensal aproximado por faixa de valor, o tempo típico de espera entre etapas e a lista de exceções, cada uma com a frequência com que aparecia.
Duas coisas saíram do mapa que ninguém tinha dito em voz alta. A primeira foi que o supervisor e o comprador conferiam a mesma cotação em momentos diferentes, e que a conferência do comprador existia por hábito, porque no passado o supervisor não olhava. A segunda foi que o e-mail de aviso chegava a aprovadores que já tinham visto a linha na planilha, então ele servia mais para gerar cobrança do que para informar. As exceções também apareceram com nome: a compra emergencial de manutenção com a linha parada, o fornecedor sem cadastro, o pedido dividido em dois para ficar abaixo da alçada e o aprovador de férias sem substituto definido.

O destaque está nas etapas redundantes: marcar o que eliminar no mapa evita automatizar a conferência feita duas vezes.
Qual é o critério para decidir se vale mapear e levar adiante
A resposta é sim quando quatro condições são verdadeiras ao mesmo tempo. O processo roda mais ou menos do mesmo jeito na maioria dos casos, de modo que um mapa feito hoje ainda vale daqui a alguns meses. O volume é suficiente para que a espera e o retrabalho pesem no mês, o que costuma significar dezenas ou centenas de ocorrências e não uma ou duas. Existem pessoas que executam o processo e aceitam conversar sobre ele sem medo de que o mapa vire auditoria. E o dono do processo tem autonomia para mudar etapas, porque mapear algo que ele não pode alterar produz um desenho bonito e nenhuma decisão.
Quando uma dessas condições falha, a resposta muda de forma. Se o processo é estável mas o dono não manda nele, o primeiro passo é conseguir a alçada, não o mapa. Se o volume é pequeno, a conversa é sobre se vale mexer, e isso fica para a seção sobre quando não usar.
O roteiro das três conversas
O roteiro abaixo é o que o gerente do caso seguiu, e funciona na ordem em que está porque cada conversa corrige a anterior.
- Siga um pedido real, com quem executa. Sente ao lado do comprador e peça para ele mostrar, não explicar: abrir a planilha, o e-mail, a cotação, tudo como faz hoje. Anote cada etapa, quem a executa e onde o pedido espera, e pergunte sempre "e o que acontece se isso der errado".
- Traga o volume e as exceções, com os aprovadores. Antes da conversa, conte na própria planilha quantos pedidos entraram por mês e em que faixas de valor, e separe uma amostra dos que não seguiram o caminho normal. Com os aprovadores, percorra essa amostra e anote cada exceção com a causa e a frequência aproximada, sem tentar resolvê-las ainda.
- Devolva o desenho para quem executa corrigir. Mostre o mapa de uma página ao comprador e aos solicitantes e peça que apontem o que está errado ou faltando. Feche perguntando de qual etapa eles abririam mão se pudessem, porque é nessa resposta que aparecem as etapas a eliminar.
Para desenhar, o que existir à mão serve: uma folha A3 ou um quadro branco com uma raia por responsável e as etapas em sequência, ou o Visio, se a empresa já o tem no pacote. Os dados que importam são sempre os mesmos, etapas, responsável, volume mensal aproximado, tempo de espera e exceções anotadas. Se o processo já deixa rastro em sistema, a análise automática desse rastro pode complementar as conversas, e esse caminho tem o seu próprio post, o que escrevemos sobre o Process Intelligence Studio, então aqui ficamos com o que se faz de graça.
A armadilha: mapear como deveria ser, não como roda
O erro que mais vemos é o mapa feito numa sala de reunião com o gerente e o supervisor, que descrevem com boa fé o processo como foi desenhado. Esse mapa não tem a compra emergencial, não tem o pedido dividido para caber na alçada e não tem a segunda conferência que o comprador faz por desconfiança, porque nada disso está no procedimento. O resultado é uma automação construída sobre o processo ideal, que na primeira semana esbarra nas exceções reais e volta para o e-mail e o corredor.
O custo maior vem depois, porque o mapa idealizado preserva as etapas que existem por hábito. No caso da fábrica, automatizar as duas conferências da cotação teria dado um fluxo de aprovação com dois passos onde bastava um, e a espera continuaria lá, só que agora com histórico e notificação. A pergunta que protege contra isso é a da terceira conversa, sobre o que a pessoa cortaria, e a regra é eliminar primeiro e automatizar o que sobrou.
Isso vale também quando a TI for usar ferramentas que partem de uma descrição. O recurso de planos do Power Apps aceita a descrição do caso de uso em linguagem natural e imagens, como fluxos de processo, para gerar uma solução, e exige um ambiente com Dataverse. Um mapa corrigido pela área é o insumo certo para isso, e um mapa idealizado só gera a solução errada mais rápido.
Quando não usar este caminho
Se o processo muda toda semana, seja por regra comercial, por troca de fornecedor ou porque a área ainda está decidindo como quer trabalhar, o mapa envelhece antes de ser usado. Nesse caso o esforço rende mais em estabilizar o processo primeiro, e só depois desenhar o que ficou. Automatizar algo que ainda está sendo inventado é pagar para refazer.
O segundo caso é o de volume tão baixo que o mapa custa mais que o ganho. Uma aprovação que aparece poucas vezes por mês e que uma pessoa resolve em minutos dispensa o roteiro, e o que cabe é um acordo simples sobre quem decide e em quanto tempo. A conta é grosseira, mas costuma bastar: se a soma da espera e do retrabalho do mês é menor do que o tempo de fazer três conversas e desenhar uma página, deixe como está e volte ao assunto quando o volume crescer.
O que levar para quem aprova
Com três conversas e uma página, a área passa a saber quantos pedidos de compra passam por mês, onde esperam e quais etapas podem ser cortadas antes de qualquer fluxo, e é com esse mapa que o pedido de orçamento de automação chega à diretoria já dimensionado. Sem ele, o risco é pagar por uma automação sobre um processo que ninguém descreveu, que reproduz as etapas redundantes e esbarra nas exceções na primeira semana, o que custa mais do que o levantamento que se quis evitar. O próximo passo é autorizar a área a fazer as conversas e trazer o mapa na próxima reunião, para só então decidir o que vale automatizar.
O próximo passo da trilha é decidir o que do mapa vale automatizar, e é nele que o desenho de uma página vira critério. Se quiser, a Trinapse envia o roteiro das três conversas em uma página, no formato que já usamos com áreas de compras, para você levar ao diretor.
Erick Alves de Moura é Head of Delivery e Arquiteto Principal da Trinapse, consultoria brasileira especializada em Microsoft 365. Acumula 14 anos de experiência em arquitetura e entrega de soluções sobre SharePoint, Power Platform, Microsoft Graph e Copilot, sempre em ambientes corporativos de grande porte.
Ver maisVer menos
Ao longo da carreira, conduziu migrações de SharePoint on-premises para o SharePoint Online, desenhou intranets corporativas, automatizou processos de negócio com Power Apps e Power Automate e, mais recentemente, projetou agentes de IA integrados ao Microsoft 365.
São projetos com milhares de usuários, regras de governança rígidas e integração com sistemas legados, o tipo de cenário em que a decisão de arquitetura importa mais do que a ferramenta.
Fluente em inglês, atende clientes globais e é o arquiteto responsável pela conta da Bayer nos Estados Unidos, no Brasil, atua junto a cooperativas de crédito, agronegócio e indústria, setores com forte exigência de conformidade e continuidade operacional.
Escreve no blog da Trinapse desde 2019. São mais de 240 artigos publicados sobre SharePoint, Modern Workplace, Copilot e agentes de IA, Power Platform e automação de processos, em dois formatos: tutoriais técnicos passo a passo e análises de decisão sobre arquitetura e adoção do Microsoft 365. Todo conteúdo nasce de projeto real entregue, não de documentação traduzida.



