Arquitetura de Automação de Procurement

O que a automação de compras realmente significa?

"A automação de compras" abrange desde a automação de fluxo de trabalho baseada em regras, que direciona uma requisição por meio de uma cadeia de aprovação fixa, até a automação robótica de processos (RPA), que opera telas existentes da mesma forma que uma pessoa faria, passando pela automação inteligente, que adiciona compreensão de documentos ou lógica de correspondência. Pesquisas revisadas por pares descrevem a RPA como o uso de programas de software de código baixo para automatizar processos de negócios repetitivos e rotineiros, e o classifica como a tecnologia de crescimento mais rápido na categoria de software corporativo. Nenhuma dessas abordagens substitui o processo de ponta a ponta de compras ao pagamento (procure-to-pay); elas operam dentro dele, cada uma assumindo uma etapa específica e bem definida, e é por isso que a pergunta útil é quais etapas neste arquitetura procure-to-pay são rotineiras o suficiente para serem repassadas a um software e quais ainda exigem o julgamento humano.

Quais etapas do fluxo de trabalho são automatizadas primeiro e por quê?

Quatro etapas aparecem repetidamente como candidatas iniciais à automação, porque cada uma possui alto volume, é regida por regras e tem um resultado claro de aprovação/reprova: roteamento e aprovação de requisição, o cruzamento de três vias (three-way match) entre pedido de compra, recebimento e fatura, emissão do pedido de compra assim que a requisição é aprovada e tratamento de exceções de faturas para as divergências sinalizadas pelo cruzamento de três vias. O benchmarking atual de compras revela que a automação melhora a capacidade de aproveitar descontos por volume, consolidar compras e reduzir custos e erros decorrentes de esforços manuais, o que ocorre ao tratar essas etapas como ponto de partida em vez de toda a ambição. O mesmo trabalho de benchmarking acrescenta uma condição que vale a pena levar a sério: a padronização de processos ajuda a garantir que a busca por velocidade não resulte em um aumento de erros, portanto, automatizar um fluxo de trabalho de ordem de compra o que ainda não está padronizado apenas acelera a inconsistência, porque a padronização deve acontecer primeiro ou em conjunto com a construção.

Quais controles o caminho automatizado precisa preservar?

Dois princípios de controle permanecem inalterados em relação às compras manuais, e um fluxo de trabalho automatizado precisa expressá-los em software, em vez de assumir que eles sobrevivem à migração. O primeiro é a segregação de funções: as diretrizes federais de controle autorizadas definem isso como dividir funções e responsabilidades-chave entre diferentes pessoas para reduzir o risco de erro, uso indevido ou fraude, separando as responsabilidades de autorizar transações, processá-las e registrá-las, revisar as transações e manusear quaisquer ativos relacionados, de modo que nenhum indivíduo controle todos os aspectos principais de uma transação ou evento. O segundo é a autorização: as transações são autorizadas e executadas apenas por pessoas que atuam dentro do escopo de sua autoridade. Em um processo manual, isso se manifesta como pessoas diferentes manipulando um pedido de compra em mesas separadas. Em um processo automatizado, isso deve se manifestar como um modelo de função, uma configuração de limite de alçada de aprovação e um mapa de permissões que um bot ou um mecanismo de fluxo de trabalho não pode contornar silenciosamente apenas porque tecnicamente consegue gravar em qualquer campo que consiga acessar.

Como você sequencia uma implantação voltada primeiro para a governança?

Onde as integrações de ERP legadas realmente falham e de onde vêm os silos de dados?

O ponto em que uma plataforma de automação de compras se conecta ao ERP é onde o risco de governança se concentra na prática, e também onde um silo de dados é construído caso a automação mantenha sua própria cópia separada de dados de fornecedores, orçamento ou aprovação, em vez de tratar o ERP como o único sistema de registro. O guia de integração de um fornecedor de automação aponta o risco de acesso com clareza: um conector com acesso mais amplo do que sua função exige pode ler dados que nunca deveria ver e gravar em campos que nunca deveria tocar. O acesso amplo geralmente é concedido por conveniência durante a configuração, e não porque o fluxo de trabalho o exija, e vale a pena tratá-lo como um item de checklist fornecido pelo fornecedor a ser testado, em vez de uma afirmação sobre o produto específico de qualquer fornecedor. O mesmo guia aponta um segundo modo de falha, mais silencioso: uma trilha de auditoria que abrange ações humanas, mas deixa decisões automatizadas sem registro, é incompleta e gerará apontamentos em qualquer auditoria rigorosa. Se um bot aprova uma fatura, essa decisão precisa do mesmo registro que a aprovação de uma pessoa exigiria: qual lógica foi aplicada, quais dados foram utilizados e qual foi o resultado.

Por que a automação não verificada custa mais do que economiza?

A tentação é tratar a automação como um problema de implantação: configurar a ferramenta, direcioná-la ao processo e implementá-la. Pesquisas fundamentais de verificação de fluxo de trabalho alertam contra a omissão da etapa intermediária. Ao estudar sistemas de gerenciamento de fluxo de trabalho em geral, os pesquisadores descobriram que as consequências, no entanto, são que poucos fluxos de trabalho são verificados minuciosamente antes de serem implementados na prática, o que muitas vezes resulta na necessidade de corrigir erros de forma improvisada, frequentemente com custos proibitivos. Essa constatação antecede as plataformas de automação low-code de hoje em duas décadas, e o problema subjacente não desapareceu: uma especificação de fluxo de trabalho é uma peça de lógica, e uma lógica que não foi verificada quanto às escolhas, sequências e exceções que realmente precisa gerenciar falha da mesma maneira, quer uma pessoa ou um bot a esteja executando, exceto pelo fato de que o bot falha mais rápido e em maior volume. As linguagens de especificação de fluxo de trabalho precisam dar suporte à especificação de momentos de escolha, execução sequencial, paralelismo, sincronização e iteração precisamente porque os processos reais precisam de todos eles, e um piloto que exercita apenas o caminho ideal não verificou o fluxo de trabalho de forma alguma.