Uma organização pode ter fluxogramas atualizados, procedimentos publicados, responsabilidades formalmente definidas e sistemas implantados.

E, ainda assim, funcionar de uma maneira completamente diferente daquela que está documentada.

Isso acontece porque processos não existem apenas em diagramas.

Eles acontecem nas decisões tomadas todos os dias, nas interfaces entre áreas, nas exceções, nos controles paralelos, nas planilhas criadas para suprir limitações, nas mensagens trocadas fora dos sistemas e, principalmente, no conhecimento acumulado pelas pessoas que executam o trabalho.

É justamente nesse espaço — entre o processo declarado e o processo real — que muitos problemas organizacionais permanecem escondidos.

E também é onde uma transformação precisa começar.

O organograma mostra quem responde pela área. Não necessariamente como o trabalho acontece.

Durante muito tempo, organizações foram analisadas principalmente a partir de suas estruturas funcionais.

Financeiro. Compras. Comercial. Recursos Humanos. Operações. Tecnologia.

Essa divisão é necessária para organizar competências e responsabilidades. O problema começa quando utilizamos essa mesma lógica para compreender processos.

Porque o cliente, a informação, uma solicitação ou uma entrega raramente respeitam as fronteiras do organograma.

Um processo pode começar no Comercial, depender de uma validação Financeira, passar por Compras, exigir uma decisão da liderança e terminar em outra área.

Quando cada departamento enxerga apenas sua própria parte, surgem zonas cinzentas.

Quem é responsável pela passagem entre uma área e outra? Quem acompanha o resultado ponta a ponta? Onde termina uma responsabilidade e começa a próxima?

É justamente nas interfaces que costumam surgir esperas, retrabalhos, duplicidades, controles paralelos e conflitos.

Por isso, mapear departamentos não significa necessariamente compreender processos.

O risco do processo “como deveria ser”

Existe uma pergunta aparentemente simples que pode comprometer um diagnóstico: “Como esse processo funciona?”

Frequentemente, a resposta descreve como ele deveria funcionar.

O procedimento determina uma sequência. O sistema deveria registrar determinada informação. A aprovação deveria acontecer em determinado momento. O gestor acredita que determinada atividade é realizada daquela maneira.

Mas, quando observamos a execução, encontramos outra realidade.

Uma planilha complementar existe porque o sistema não entrega determinada visão. Uma aprovação acontece por e-mail porque o fluxo oficial é lento. Uma pessoa consulta um colega antes de tomar uma decisão porque a regra formal não cobre aquela situação. Um controle manual surgiu anos atrás para resolver uma exceção e acabou incorporado à rotina.

Nenhuma dessas situações necessariamente aparece no fluxograma oficial. Ainda assim, elas fazem parte do processo real.

É por isso que um bom AS IS não é simplesmente um desenho

AS IS significa compreender o estado atual. Mas existe uma diferença enorme entre documentar o que foi relatado e investigar como o trabalho efetivamente acontece.

Um diagnóstico consistente precisa avançar sobre diferentes camadas da operação.

  • Quem executa?
  • Onde recebe a informação?
  • Em qual sistema trabalha?
  • Que decisão precisa tomar?
  • Que regra utiliza?
  • O que acontece quando existe uma exceção?
  • Existe algum controle fora do sistema?
  • Para quem entrega?
  • Quanto precisa esperar?
  • Onde ocorre retrabalho?
  • O que depende do conhecimento de uma única pessoa?
  • O que acontece quando essa pessoa não está disponível?

A execução real costuma deixar rastros

Planilhas paralelas. E-mails utilizados como workflow. Mensagens solicitando aprovação. Arquivos locais. Controles duplicados. Reentrada de informação. Conferências manuais. Cadastros incompletos. Filas invisíveis. Decisões sem critério explícito. Atividades que “sempre foram feitas assim”.

Esses elementos podem parecer pequenos quando observados isoladamente. Mas, juntos, contam uma história sobre a operação.

Uma planilha paralela, por exemplo, não é necessariamente o problema. Ela pode ser um sintoma.

Talvez exista uma necessidade de informação que o sistema atual não atende. Talvez o processo tenha sido alterado sem que a tecnologia acompanhasse. Talvez não exista clareza sobre onde determinada informação deveria ser mantida.

Eliminar a planilha sem compreender sua função pode simplesmente deslocar o problema. É por isso que transformação exige diagnóstico antes de solução.

Ouvir somente a liderança também não é suficiente

Gestores possuem uma visão indispensável do processo. Conhecem objetivos, responsabilidades, indicadores e problemas relevantes.

Mas existe uma dimensão da operação que normalmente aparece apenas quando conversamos com quem executa o trabalho. É o conhecimento tácito.

A exceção que nunca foi documentada. O cliente que precisa de tratamento diferente. O sistema que exige uma sequência específica. A conferência criada depois de um erro ocorrido anos atrás. A decisão que depende da experiência de determinada pessoa.

Isso não significa que a percepção da liderança esteja errada. Significa apenas que gestão e execução observam o mesmo processo a partir de perspectivas diferentes.

Um diagnóstico robusto precisa conectar essas perspectivas.

Tecnologia também não resolve aquilo que ainda não compreendemos

Esse problema se torna ainda mais relevante diante da automação e da inteligência artificial.

Automatizar uma atividade antes de compreender por que ela existe pode apenas tornar um problema mais rápido. Digitalizar uma exceção desnecessária continua mantendo a exceção. Criar uma integração entre sistemas não resolve necessariamente uma responsabilidade mal definida. E colocar um agente de IA dentro de um processo confuso pode aumentar a complexidade em vez de reduzi-la.

Antes da pergunta “O que podemos automatizar?”, existe uma pergunta anterior: “Como esse trabalho deveria funcionar?”. E, antes dela, outra: “Como ele funciona hoje, de verdade?”.

Essa sequência importa.

Do AS IS ao TO BE: redesenhar antes de automatizar

Compreender profundamente o estado atual não significa preservar o passado. É justamente o contrário. O AS IS fornece evidências para questioná-lo.

Depois de compreender atividades, interfaces, decisões, exceções, controles, sistemas e responsabilidades, podemos perguntar:

  • Essa atividade ainda precisa existir?
  • Essa aprovação gera controle ou apenas espera?
  • Essa informação precisa ser digitada novamente?
  • Essa decisão poderia seguir uma regra?
  • Esse controle deveria estar dentro do sistema?
  • Essa interface precisa existir?
  • Essa responsabilidade está no lugar correto?

Processos não são desenhos. São sistemas de trabalho.

Fluxogramas são importantes. Arquiteturas são importantes. Procedimentos são importantes. Mas todos eles são representações.

O processo existe quando pessoas, informações, decisões, regras, sistemas e responsabilidades se conectam para produzir um resultado.

Por isso, transformar processos exige muito mais do que documentá-los. Exige compreender como a organização realmente funciona. Inclusive aquilo que não aparece no desenho.

Antes de redesenhar, descubra o que realmente acontece.

Na LBA’S, partimos de uma premissa simples: “Não é possível transformar aquilo que ainda não compreendemos.”

Por isso, arquitetura, diagnóstico AS IS, visão ponta a ponta, interfaces, responsabilidades e governança não são documentos isolados. São diferentes lentes para compreender uma mesma organização.

E é a partir dessa compreensão que começa o redesenho.

Porque o processo declarado mostra como a organização acredita que trabalha. O processo real mostra onde a transformação precisa acontecer.