Business case de mineração de processos: quatro números para o financeiro

Um business case de mineração de processos apresenta à área financeira quatro números para avaliar: o tamanho do problema, o custo da solução, o custo do piloto e o prazo até obter as primeiras evidências. Três deles podem ser calculados a partir de uma única exportação dos dados do seu processo. Se algum número ainda for uma estimativa, sinalize isso e informe quando será medido.

É difícil avaliar um pedido para “implementar Process Mining” porque ele não identifica um problema, uma decisão nem uma data para obter evidências. A maioria dos business cases que não avançam se baseia no que alguém espera que a ferramenta produza, e não no que o processo realmente faz. Por isso, esta página mantém o foco em um único processo: o que você vai medir, quanto custará a mudança e quando terá os resultados.

Quais são os quatro números necessários em um business case de Process Mining?

Apresente os quatro números antes de defender qualquer um deles e indique a base de cada um.

1. Tamanho do problema: quanto o processo custa hoje, em uma unidade que sua empresa já acompanha, como dias de tempo de ciclo, multas por atraso, prazo médio de recebimento de vendas ou horas de FTE. Use seus próprios volumes e tempos.
2. Custo da solução: quanto custa mudar o processo, não analisá-lo. Uma mudança de política e uma rodada de treinamento têm um porte diferente de uma mudança de sistema. A estimativa deve vir de quem será responsável pela mudança.
3. Custo do piloto: a licença, o trabalho com os dados e o tempo da equipe interna necessário para confirmar os dados.
4. Prazo até as primeiras evidências: a data prevista para analisar um resultado e a métrica usada nessa análise.

Em geral, três dos quatro números vêm da mesma fonte. Uma exportação dos dados do processo mostra o tamanho do problema, o esforço necessário para preparar os dados e o tempo da análise. O custo da solução depende de uma decisão ainda não tomada. Por isso, é preciso definir um responsável e uma data, em vez de inventar um número.

Identifique cada número do business case como medido ou estimado. A área financeira vai perguntar qual é qual, e um business case que responde a essa pergunta é mais difícil de descartar do que quatro números apresentados com confiança, mas sem uma base clara.

Por que os business cases de Process Mining perdem apoio?

Raramente um business case fracassa porque um número está errado. Um business case de Process Mining perde apoio quando não há nada que possa ser verificado.

Pedem uma capacidade, em vez de propor uma decisão. “Vamos ter visibilidade de ponta a ponta do pedido ao recebimento” não diz à área financeira o que está sendo financiado nem como o resultado será avaliado. “Vamos descobrir se a segunda etapa de aprovação acrescenta uma semana a um terço dos pedidos e apresentar os resultados até 15 de novembro” diz.

Dependem de percentuais de referência. A afirmação de que o Process Mining costuma reduzir o tempo de ciclo em determinado percentual não diz nada sobre o seu processo. Sua própria linha de base é mais útil, mesmo que pareça menos impressionante.

Não incluem o trabalho com os dados. Extrair dados, identificar casos, ordenar as datas e horas e configurar atualizações exige tempo. Se o business case listar apenas a licença, o custo do piloto estará subestimado. Leia primeiro o detalhamento dos custos para entender melhor cada item.

Usam uma média que esconde o problema. O tempo médio de atendimento distribui uma espera de cinco dias igualmente entre todos os casos, fazendo o número parecer pequeno e qualquer melhoria parecer ainda menor. Em vez disso, indique onde o tempo se acumula: em qual etapa, em quantos casos e por quanto tempo. “Cerca de 12.000 pedidos por trimestre; aproximadamente um terço não chega na data prometida e a causa não está clara” dá a quem avalia algo para verificar. “Ineficiência significativa na gestão de pedidos” não.

Quais resultados os projetos de Process Mining costumam entregar?

Entender que tipo de evidência será obtida facilita a elaboração do business case. Uma primeira análise de um processo com base nos dados de eventos costuma responder a perguntas como estas:

• Onde o tempo é gasto: tempo de espera por atividade, ao lado do tempo de trabalho nessa atividade, para deixar clara a diferença entre os dois.
• Com que frequência o processo se repete: contagem de ciclos e retrabalho, incluindo etapas que não aparecem no modelo documentado.
• Por quantas pessoas um caso passa: contagem de transferências entre equipes e sistemas.
• Quanto o processo varia: quantos caminhos diferentes existem e qual proporção dos casos segue o caminho mais comum.
• Em que pontos o processo foge das regras: lacunas de Conformidade em relação ao processo planejado.
• Quais etapas podem ser automatizadas: etapas de alto volume, baseadas em regras e com pouca variação, sustentadas por uma linha de base medida.
• Quanto esforço cada etapa exige: tempo por etapa e por caso, para calcular o custo de uma mudança proposta.

Os resultados dependem do processo e dos dados disponíveis. Um Event Log com ID do caso, atividade e data e hora responde às quatro primeiras perguntas. As demais exigem mais detalhes e, em alguns casos, um modelo para comparação. Veja como o Process Mining analisa os dados do seu processo. Se os dados ainda não puderem ser usados, o caminho da inteligência explica o que precisa ser preparado primeiro.

Vale deixar uma coisa clara: a ferramenta não dá a resposta. Ela fornece as evidências, que você transforma em um business case. Nenhum dos itens dessa lista diz quanto vale uma mudança, se uma etapa deveria existir ou quanta capacidade sua equipe realmente pode liberar. Essas são decisões de negócio, que ficam mais fáceis quando há medições disponíveis. Os benefícios do Process Mining dependem do alcance das mudanças apoiadas por essas decisões.

Se o Event Log cobrir apenas parte do processo ou do período, informe isso junto com os números. Uma medição parcial ainda é uma evidência, desde que fique claro o que ela inclui e o que deixa de fora.

Como calcular os benefícios com base nas suas próprias métricas?

O tamanho do problema só se transforma em benefício quando você mostra o que vai mudar. O valor da mineração de processos está na decisão que as evidências ajudam a tomar. Por isso, vincule o caso a uma decisão que sua organização precisa tomar. Para justificar o investimento em mineração de processos, dois modelos atendem à maioria dos primeiros casos:

Caixa ou capital de giro:

dias reduzidos × casos afetados × valor por dia de caso × custo de capital

Capacidade:

horas reduzidas por período × custo por hora com encargos

Deixe claras três distinções:

• Use uma unidade que sua empresa já adota. Expresse o benefício em dias de tempo de ciclo, multas por atraso evitadas, redução do DSO ou horas liberadas. “Eficiência”, por si só, não pode ser verificada.
• Separe caixa de capacidade. Liberar capacidade não gera caixa por si só. Explique se o valor vem de processar mais volume com a mesma equipe ou de uma decisão sobre o quadro de funcionários, e identifique quem toma essa decisão.
• Identifique a premissa sobre a qual você tem menos certeza. Indique qual parte da estimativa é menos confiável e como você vai testá-la.

Uma linha de base medida facilita a defesa do restante do cálculo. Se as horas foram calculadas com base nos dados dos seus próprios eventos, a única premissa restante é o tamanho da redução, um número que pode ser questionado por quem avalia o caso. Um benefício baseado em uma linha de base presumida e em uma redução também presumida dificilmente se sustenta numa reunião. Se você não consegue defender um percentual de redução, informe o intervalo que testou e explique qual valor usou.

Você pode inserir esses dados na calculadora de ROI do ProcessMind: volume anual de casos, tempo médio de processamento, custo por hora com encargos, redução esperada, incidentes e custo médio de cada um, além dos dados do plano para a licença. O resultado inclui benefícios anuais totais, benefício líquido, retorno sobre o investimento e prazo de retorno.

É um modelo geral, e esse é justamente o seu valor: mostrar como os dados de entrada se combinam. Ele só se torna o seu caso quando você substitui os valores padrão pelos seus próprios volumes, tempos e custos. A calculadora também não inclui o esforço de implementação nem a preparação dos dados nos custos, então some esses valores separadamente. Um modelo que você não consegue adaptar à sua realidade ainda não é um caso de negócio.

Como é, na prática, um caso de negócio com quatro números?

Os números abaixo são apenas ilustrativos. Use o método, não os valores.

Cenário: Um processo lida com 12.000 pedidos por trimestre. O tempo de ciclo mediano é de 18 dias, e o P90 é de 41 dias. Cerca de um terço dos pedidos espera mais de cinco dias em uma etapa de aprovação, que exige aproximadamente quatro minutos de trabalho efetivo.

1. Tamanho do problema: A espera afeta cerca de 4.000 pedidos por trimestre. Se a espera média nessa etapa é de seis dias, são 24.000 dias de ciclo dos pedidos por trimestre. O trabalho efetivo exigido nessa etapa é de aproximadamente 270 horas no mesmo período. Qual dos dois números deve entrar no caso depende de o atraso afetar seus custos, os níveis de serviço ou ambos. Antes de usá-lo, confira qualquer um deles com seus próprios dados. Observe também a unidade: dias de pedidos não são o mesmo que reais. Se o caso precisa apresentar um valor em dinheiro, essa conversão é outra premissa que você deve declarar e testar.

2. Custo da solução: Uma possível mudança é elevar o limite para que a etapa de aprovação se aplique a 8% dos pedidos, em vez de 33%, e designar um substituto quando a pessoa responsável pela aprovação estiver ausente. Antes de considerar essa uma solução de baixo custo, confirme as políticas, os controles e os custos de implementação com as pessoas responsáveis.

3. Custo do piloto: Limite o piloto a um processo e a um período definido. Inclua a licença, o tempo do analista dedicado à preparação dos dados e o tempo da pessoa responsável pelo processo. Se o esforço de preparação dos dados ainda não foi confirmado, identifique-o como estimativa. Um caso de negócio de mineração de processos que considera apenas o custo da licença subestima o trabalho envolvido.

4. Tempo até as primeiras evidências: Defina uma data para analisar o tempo de ciclo do segmento afetado. Se a espera não mudar, você ainda terá uma linha de base para orientar a próxima decisão.

O que poderia mudar a conclusão? Se a etapa de aprovação existe para detectar uma falha de controle, mudar o limite pode enfraquecer esse controle. Inclua esse risco no caso e envolva a pessoa responsável pelo controle antes de recomendar qualquer mudança.

Reúna os quatro números e as perguntas da área financeira em uma página:

Cada linha dessa tabela deve apontar para algo que você mediu ou para uma estimativa feita por uma pessoa responsável identificada. O cálculo de ROI da mineração de processos não é diferente: não apresente uma estimativa como economia até que seus próprios dados e a mudança proposta deem suporte a ela.

Para identificar quais etapas podem valer a pena mudar, leia como encontrar oportunidades de automação com mineração de processos.

Por que seu primeiro caso de negócio deve ser um piloto?

O primeiro caso de negócio deve ser para um piloto, não para uma plataforma. É para isso que os quatro números servem: um processo, uma decisão e um período curto o bastante para avaliar o resultado antes de assumir um compromisso maior. Trate-o como uma prova de valor da mineração de processos: um exercício de medição, não uma implantação em pequena escala.

Comece com pouco e mantenha os critérios realistas: o caso de negócio deve ser fácil de justificar. Se não for, você está pensando grande demais. Deixe os dados falarem primeiro e amplie o escopo onde fizer sentido. Um piloto que custa algumas licenças e algumas semanas do tempo de um analista precisa atender a critérios bem menos exigentes que um programa de plataforma. Além disso, produz algo que esse programa não consegue oferecer: sua própria linha de base.

Começar pequeno também é uma decisão sobre software. Se uma ferramenta só faz sentido como implantação Enterprise, o caso precisa ser grande antes mesmo de ser elaborado. O ProcessMind cobra por licença e oferece um plano gratuito após o período de teste, além de um teste grátis de 14 dias sem necessidade de cartão de crédito. Assim, a primeira análise não exige um contrato Enterprise. Veja o preço de cada plano.

Defina quatro pontos antes de iniciar um piloto de mineração de processos:

• Um processo: restrito o bastante para que uma única pergunta defina o escopo.
• Uma decisão: a decisão que os resultados devem ajudar a tomar.
• Critérios de saída: definidos com antecedência, indicando quais resultados justificariam continuar e quais justificariam parar.
• Uma data de análise: o dia em que você vai avaliar as evidências e decidir os próximos passos.

Se o piloto justificar a continuidade do trabalho, use os resultados para embasar o próximo processo. Caso contrário, você ainda terá uma linha de base e motivos mais claros para mudar de direção. De qualquer forma, registre no caso, antes de começar, os três resultados possíveis: as evidências apoiam essa mudança, apoiam outra mudança ou indicam que é melhor parar. Um caso que só pode terminar de uma maneira não é um exercício de medição.

E se os números ainda não estiverem prontos?

Nesse caso, talvez ainda não seja possível justificar o investimento. Reconhecer isso é um resultado, não um fracasso. Em geral, há três motivos: o volume do processo é baixo demais para que o trabalho faça diferença, os dados não estão disponíveis em um formato utilizável ou ninguém está aguardando essa decisão.

Se os dados existem e o processo é pequeno, meça uma linha de base manualmente. Se os dados não forem utilizáveis, defina o escopo do trabalho necessário com eles em vez de solicitar uma licença. Explique também o que precisa mudar para que você reavalie o caso.