Perspetiva
A automação promete algo que todas as organizações desejam: menos trabalho manual, execução mais rápida, menos erros e mais tempo para as pessoas se dedicarem a tarefas de maior valor.
Mas a automação não melhora automaticamente um processo.
Se um fluxo de trabalho contém aprovações desnecessárias, introdução duplicada de dados, procedimentos inconsistentes, responsabilidades pouco claras ou soluções improvisadas ao longo dos anos, a tecnologia pode simplesmente fazer esses problemas acontecerem mais depressa e em maior escala.
Por isso, a primeira pergunta não deve ser «O que podemos automatizar?», mas sim «Como é que este trabalho é realmente feito hoje?»
A maioria das organizações tem uma versão oficial de um processo.
Chega um pedido. Alguém o analisa. É aprovado. O trabalho é concluído. O cliente é informado.
Simples. Mas o processo real pode ser muito diferente.
Um colaborador recebe o pedido por email. A informação é copiada para uma folha de cálculo. Alguém contacta outro departamento para obter dados em falta. Um documento é descarregado, renomeado e guardado noutro local. Uma aprovação fica numa caixa de entrada. Alguém faz o acompanhamento manualmente. Outro colaborador mantém uma folha de cálculo separada porque o sistema principal não oferece a visibilidade necessária à equipa.
Estas variações são importantes.
A Microsoft descreve a mineração de processos como uma forma de usar dados de eventos de sistemas de registo para visualizar como os processos organizacionais realmente funcionam, identificar ineficiências, investigar as suas causas e acompanhar indicadores de desempenho. A sua documentação destaca a descoberta de ações desnecessárias, erros e oportunidades de automação.[1]
Esta distinção entre o processo pretendido e o processo real é essencial. Não é possível redesenhar com inteligência aquilo que não se compreende.
Imagine uma organização que recebe pedidos de clientes por email. Um colaborador analisa cada pedido manualmente, decide para onde deve seguir, copia a informação para outro sistema e encaminha documentos para a equipa adequada.
A oportunidade óbvia de automação pode ser ler automaticamente o email e introduzir a informação no sistema existente. Isso pode poupar tempo.
Mas não responde a perguntas mais importantes. Porque é o email o mecanismo de entrada? Porque é a informação introduzida duas vezes? Porque não fica a responsabilidade definida quando o pedido chega? Que pedidos exigem realmente análise humana? Porque circulam documentos entre sistemas? O que acontece quando falta informação?
Se estas perguntas não forem resolvidas, a organização pode automatizar com sucesso um fluxo de trabalho que não deveria existir na sua forma atual.
Se automatizar um fluxo de trabalho que não deveria existir na sua forma atual, tornou o processo errado mais eficiente.
A automação vem depois da compreensão — não antes.
Antes de desenhar uma automação, mapeie o que acontece do início ao fim. Identifique o evento que inicia o processo, as pessoas envolvidas, os sistemas e dados utilizados, as decisões e aprovações, as passagens entre equipas, as exceções e soluções improvisadas, e o resultado que o processo deve produzir.
As plataformas modernas de mineração de processos seguem esta ideia. Por exemplo, a UiPath descreve a mineração de processos como a reconstrução de processos a partir de dados de eventos dos sistemas, para revelar desvios, exceções, bloqueios e ineficiências antes de priorizar oportunidades de otimização ou automação.[2]
Isto não significa que todas as organizações precisem de software sofisticado de mineração de processos antes de automatizar. Em fluxos menores, entrevistas, observação, dados existentes e um mapa de processos bem construído podem revelar muito.
O importante é compreender o estado atual antes de desenhar o estado futuro.
Quando o processo se torna visível, fica mais fácil evitar outro erro: assumir que cada passo manual é um problema.
Algum trabalho é manual porque exige discernimento.
Um engenheiro de fabrico que decide se um desenho é tecnicamente viável é diferente de alguém que copia manualmente um número de pedido de cotação de um email para uma folha de cálculo. Um profissional de saúde que toma uma decisão clínica é diferente de alguém que transfere repetidamente informação administrativa entre sistemas. Um gestor que aprova uma exceção invulgar é diferente de um sistema que o notifica automaticamente de que essa exceção precisa de atenção.
Uma boa automação distingue estas situações.
A tecnologia é especialmente útil em tarefas repetitivas e baseadas em regras: mover informação, criar registos, encaminhar tarefas, gerar notificações, sincronizar sistemas e apresentar informação para apoiar decisões. As pessoas devem permanecer onde o contexto, o discernimento, a responsabilidade ou os conhecimentos especializados são importantes.
Isto cria um objetivo diferente: não automatizar o máximo de trabalho, mas automatizar o trabalho certo.
Há uma nuance importante. «Corrigir o processo antes de o automatizar» não deve transformar-se em «eliminar todas as variações antes de fazer qualquer coisa».
As organizações reais têm variações legítimas de processos. Diferentes locais, clientes, regulamentos ou tipos de transação podem exigir percursos diferentes.
A UiPath defende que as organizações devem compreender quais os percursos a automatizar e que resultado de negócio pretendem alcançar, em vez de adiar toda a automação até que cada variação esteja consolidada num único processo universal.[3]
O objetivo não é, portanto, a perfeição. É a intencionalidade.
Compreenda porque existem as variações. Elimine as desnecessárias. Preserve as legítimas. Depois desenhe a automação em torno do processo que a organização realmente pretende operar.
Uma automação pode funcionar perfeitamente do ponto de vista técnico e ainda assim ter dificuldades operacionais. Porquê? Porque um fluxo de trabalho é também um sistema humano.
Os colaboradores precisam de saber o que mudou, o que a automação faz, pelo que continuam responsáveis, o que acontece quando algo falha e como são tratadas as exceções.
E quando a automação elimina trabalho repetitivo, as organizações precisam de pensar no que os colaboradores fazem com a capacidade criada.
O objetivo não é apenas: uma pessoa fazia a tarefa → o software faz agora a tarefa.
A oportunidade maior é: o software trata do trabalho repetitivo → as pessoas dedicam mais tempo a tarefas que exigem discernimento, relações, análise e tomada de decisão.
É aí que a automação começa a tornar-se transformação operacional, em vez de mais uma implementação tecnológica.
A implementação não é a meta final. As organizações devem definir o que significa melhorar antes de implementar.
Consoante o processo, isso pode incluir tempo de ciclo, intervenções manuais, taxas de erro ou retrabalho, trabalho pendente, volume de exceções, tempo de resposta ao cliente, esforço dos colaboradores ou custo de processamento.
Depois meça o processo após a implementação.
É também por isso que as plataformas de mineração de processos dão cada vez mais importância à monitorização contínua. A Microsoft descreve-a como uma forma de acompanhar indicadores e identificar problemas de desempenho,[1] ao passo que a UiPath destaca a medição do efeito da automação nos processos completos e a sua otimização contínua.[2]
Sem medição, uma organização sabe que implementou automação. Não sabe necessariamente se melhorou a operação.
As conversas mais úteis sobre automação não começam com uma demonstração de produto. Começam com perguntas.
O que queremos alcançar? Como é feito o trabalho hoje? Onde abranda? Onde se duplica informação? Que decisões exigem discernimento humano? Como deve ser o processo futuro?
Só então a pergunta tecnológica se torna útil: o que devemos automatizar?
Na DaVinci-X, este princípio orienta a nossa abordagem à modernização operacional. Começamos pela operação, compreendemos o estado atual, identificamos dificuldades desnecessárias, redesenhamos quando preciso e determinamos onde a automação e os sistemas ligados podem criar melhorias relevantes.
Porque acelerar um processo que não funciona não é transformação. É apenas disfunção mais rápida.
A tecnologia deve seguir a operação — não defini-la.
