Por Francisco Aristiguieta em 13 de abril de 2022

Sistemas “push” podem funcionar bem para produtos, mas o mesmo nem sempre é válido para informações que os gerentes de risco e outros podem precisar acessar rapidamente.

Não estávamos nos afastando do “push” e indo em direção ao “pull”? Nos últimos anos, nossos amigos de gestão de operações fizeram grandes esforços para mudar de sistemas “push” (nos quais as coisas são preparadas com antecedência e armazenadas com base em certas previsões de consumo) para sistemas “pull” (nos quais as coisas estão disponíveis apenas quando são necessárias, com o mínimo de tempo de inatividade).

Isso possibilitou melhorias significativas na adaptabilidade de processos e na customização de produtos e, talvez, tenha possibilitado reduções no desperdício de matérias-primas ou níveis de estoque de processamento intermediário.

As transformações “push para pull” funcionam muito bem para produtos físicos, quando o custo de matérias-primas, estoque e itens semiproduzidos é significativo. Mas, quando se trata de informação, o custo de “não se perceber algo importante” supera muito o custo de manter essas informações em estoque até estarmos prontos para examiná-las. Devido a essa diferença de valor, nós – lenta, mas seguramente – saímos da posição de tomadores de decisão solicitando informações e esperando até que sejam geradas, para a posição de ter as informações prontas para os tomadores de decisão quando desejarem. Com o tempo, alguns de nós podem, um dia, permitir que algumas decisões pré-aprovadas sejam executadas sem nenhuma pessoa envolvida (resposta instantânea), porém não é todo processo que precisa atingir esse nível de resposta automática. 

Se processos diferentes precisam de níveis de automação diferentes, desenvolvedores e usuários precisam de uma linguagem em comum para descrever: (1) o objetivo de cada projeto de automação e (2) como mensurar o progresso em direção a esse objetivo. Sem uma linguagem em comum, nossos projetos podem ter desempenho inferior ou excessivo, ou simplesmente precisar de muitas interações para finalmente funcionar corretamente. Para atingir essa linguagem em comum, pode ser útil definir níveis de automação.

Nível 1: Pré-Solicitação (Máximo pull humano)

• Solicitações personalizadas, nas quais um humano precisa de algo que não está pronto. Normalmente, são solicitações “únicas” que precisam de um tempo significativo para serem desenvolvidas. Os exemplos podem incluir a criação de um novo relatório ou o desenvolvimento de um novo teste de auditoria.
• Gatilho: O humano solicita que o processo seja executado.
• Mecânica: A automação não existe, precisa ser desenvolvida, ou até mesmo “resolvida manualmente”.
• Capacidade de resposta: Utilizada quando pronta, o que depende do backlog e da disponibilidade da equipe.
• Conteúdo: Altamente customizado, desenvolvido especialmente para fornecer sua resposta.

Nível 2: Just in time, JTI (Mínimo pull humano)

• Solicitações comuns, prontas ou fáceis de serem criadas no momento. A máquina está sempre pronta para responder (perguntas padrão), mas o humano precisa estar interessado na resposta para verificar a ferramenta. Isso facilita a perda de eventos importantes. Exemplos de JIT incluem a busca de um humano por um relatório de business intelligence “em tempo real”, on-line; a repetição de testes de auditoria padrão; ou a reprodução de um filme ou música em um serviço de streaming de sua escolha.
• Gatilho: O humano se lembra de verificar se há atualizações.
• Mecânica: A automação é pré-fabricada; pode ser uma “receita” que utiliza dados “em tempo real”.
• Capacidade de resposta: Pode ser consumida na hora que o humano quiser, pronta uma vez que solicitada.
• Conteúdo: Altamente padronizado, provavelmente parte de um conjunto de resultados que o indivíduo considera útil.

Nível 3 – Assinatura (Mínimo push computacional)

• Periodicamente, o ser humano é lembrado da disponibilidade das informações padronizadas. Isso aborda a probabilidade do JIT de que eventos importantes passem despercebidos, mas poderia gerar o acúmulo de e-mails não lidos, que podem ser percebidos como spam ou bagunça. Por exemplo, a máquina envia um e-mail com destaques e links de vários relatórios de business intelligence, que podem ou não causar uma ação humana, ou produz um relatório de e-mail resumindo os resultados de testes de auditoria recorrentes.
• Gatilho: A máquina lembra o indivíduo de verificar a ferramenta de JIT.
• Mecânica: A rotina pré-programada é executada e é entregue dentro de um cronograma. Normalmente, parte de múltiplos testes agrupados.
• Capacidade de resposta: Pronta e disponibilizada antes que seja necessária, o ser humano pode consumir a informação quando quiser. Dependendo da resposta do indivíduo, as informações podem estar desatualizadas no momento da revisão.
• Conteúdo: Altamente padronizado, provavelmente parte de um conjunto de resultados que o indivíduo considera útil.

4- Alertas (Máximo pull computacional)

• A máquina revisa várias informações para identificar algo que necessite da atenção humana. Os exemplos incluem um alerta de furacão, um e-mail que inclui apenas exceções encontradas em testes padronizados periódicos, um e-mail ou uma mensagem de texto com informações suficientes para transmitir a urgência e desencadear ações.
• Gatilho: A máquina lembra o humano de verificar a ferramenta de JIT.
• Mecânica: Pré-fabricada e executada de acordo com um cronograma, porém só disponibiliza a informação quando certas condições são cumpridas. As condições podem ser definidas por humanos ou baseadas em previsões do computador sobre respostas ou feedbacks anteriores de um ser humano.
• Capacidade de resposta: A máquina vasculha as informações antes que qualquer solicitação seja feita. Em seguida, aciona o interesse do humano, levando-o a verificar a informação o mais rápido possível.
• Conteúdo: Altamente focado. Informações específicas sobre coisas que você solicitou especificamente ou que você tenha achado interessante anteriormente.

Soberania dos Computadores ou Humanos no Comando?

Algum dia, se todos os processos atingirem o nível de “alerta”, simplesmente largaremos tudo e faremos o que a máquina nos disser, quando disser? Teríamos, de fato, computadores como chefes? Na verdade, não. A automação deve funcionar para nós e, como usuários finais, ainda podemos decidir até onde ir no espectro da automação para cada processo e podemos definir limites. Dito isto, a maioria das pessoas aceita as orientações de semáforos e despertadores.

Isso é consistente com sua experiência? Por favor, me avise.

Copyright © 2022 de The Institute of Internal Auditors, Inc. (“The IIA”).  
Todos os direitos reservados.  
   
Foi obtida permissão do detentor dos direitos autorais, The IIA, 1035 Greenwood Blvd., Suíte 401, Lake Mary, FL 32746, EUA, para publicar esta reprodução, que é igual ao original em todos os aspectos materiais, a menos que aprovada como alterada. 
   
Este documento foi traduzido por INSTITUTO DOS AUDITORES INTERNOS DO BRASIL em 10 DE MAIO  DE 2022.