Um mapa desenhado a partir de entrevistas descreve o processo como foi desenhado. O dinheiro está na diferença entre isso e como o trabalho é feito.
Conteúdo6 seções
O mapa que a empresa já tem
Quase toda operação tem um diagrama de processo em algum lugar. Caixas, setas, uma raia por departamento, desenhado em algum momento por alguém que entrevistou todo mundo.
Ele costuma estar correto e quase sempre é inútil, por um motivo: descreve o processo como foi desenhado. O trabalho é feito de outro jeito, e a diferença é o assunto inteiro.
Duas coisas fazem um mapa valer a pena
A primeira é um número em cada passagem. Vazão, taxa de erro, tempo de ciclo.
Sem eles um diagrama diz que os passos existem e nada sobre qual deles custa algo, então toda decisão sobre o que consertar sai por impressão. Com eles, os passos se separam sozinhos entre irritantes e caros, e esses dois grupos se sobrepõem muito menos do que qualquer um espera.
A segunda é a rota real, com os contornos. Se três pessoas dependem de uma planilha compartilhada que não aparece no processo oficial, essa planilha pertence ao mapa. Ela é estrutural, e normalmente é ali que se escondem as contradições que quebram a automação.
De onde vêm os números
Entrevistas mais dados de sistema, e os dois respondem perguntas diferentes.
As pessoas são precisas sobre os próprios passos e pouco confiáveis sobre espera, frequência e exceções. Quem descreve a própria parte dá um bom relato do que faz e um ruim de quanto o trabalho fica parado antes de chegar até ela, porque ninguém vivencia uma fila em que não está.
Por isso acompanhamos o trabalho real por quatro a oito horas em cada processo alvo e ingerimos noventa dias de dados operacionais dos sistemas que já os guardam. Os dados corrigem as distorções: mostram a distribuição em vez da impressão, cobrem as noites e fins de semana de que ninguém se lembra, e incluem os casos abandonados, que por definição ninguém recorda.
As entrevistas então passam a servir a outro trabalho: explicar por que os dados têm aquela cara.
O que sai disso
| Artefato | O que contém | Para que serve |
|---|---|---|
| Mapa de processo | Cada passo, com vazão, taxa de erro e tempo de ciclo por passagem | Localizar os passos caros em vez dos irritantes |
| Relatório de custo do caos | Dinheiro perdido por semana em retrabalho, perdas e espera | A base contra a qual toda alegação de ROI é conferida |
| Matriz de prioridades | Cada candidato pontuado por viabilidade e retorno | Decidir o que é construído e o que fica adiado de forma explícita |
Em um projeto, mapear três processos candidatos precificou as horas que eles perdiam em 3.140 dólares por semana. A maior linha isolada foram as atualizações de status de projeto: 26 engajamentos ativos, uma nota por semana cada, 40 minutos de tempo de consultor por nota, a 95 dólares a hora carregada. Outro, a conciliação de faturas e horas, levava 8 horas por semana com 22% de taxa de erro.
O ponto está nesses números. Não por serem grandes - não são, e uma firma de sessenta pessoas pode carregar uma perda desse tamanho por anos sem ninguém piscar -, mas porque a alegação futura de melhoria passa a ter algo específico contra o que ser medida, e ninguém consegue comparar em silêncio um depois com um antes imaginado.
O que o total deixou de fora de propósito importa igual. O mesmo projeto tinha primeira resposta mediana de 38 horas nos leads de entrada, e 24% desses leads não recebia resposta em cinco dias úteis. As duas coisas quase certamente valem mais que todas as horas do total. Nenhuma está dentro dele, porque precificá-las exige supor uma taxa de conversão e um valor de negócio, e uma suposição enterrada numa linha de base torna infalsificável tudo o que for construído sobre ela.
O achado é a discordância
O mais útil que um mapa produz raramente está no mapa.
Três pessoas descrevem o mesmo processo e as descrições divergem. Isso não é desleixo, é informação. Os pontos onde os relatos divergem quase sempre são onde moram as exceções, onde um contorno substituiu a rota oficial, ou onde dois sistemas discordam sobre um fato e pessoas diferentes escolheram vencedores diferentes.
Esse último decide o tamanho do projeto futuro mais que qualquer escolha de tecnologia, argumento desenvolvido em a decisão que deu forma a uma obra de três semanas.
O que acontece se os números disserem não
O estágio encerra o trabalho e o depósito do diagnóstico é devolvido.
Esse desfecho precisa ser real ou nenhuma das medições significa nada, e é pela mesma razão que as condições de prontidão valem ser aplicadas antes de uma proposta e não depois.
O cliente ainda sai com o mapa, a base e a matriz. Os três servem independentemente de algo ser construído, e barateiam qualquer projeto futuro, porque a parte cara da automação é descobrir como o trabalho se move de verdade e não escrever o código que o move.
Um diagnóstico que não produz nada reaproveitável produziu um documento de vendas em vez de uma auditoria. Essa distinção vale para nós tanto quanto para qualquer um, e a semana de medição numa locadora é como isso fica quando é feito direito numa operação real.
Perguntas frequentes
O que torna um mapa de processo digno do tempo que custa?
Números nas passagens e honestidade sobre os caminhos que as pessoas realmente percorrem. Um diagrama de caixas e setas sem quantidades é uma figura de organograma fingindo ser análise: diz que os passos existem sem dizer qual deles custa alguma coisa, então toda decisão posterior sobre o que consertar é tomada por impressão. Um mapa que vale marca vazão, taxa de erro e tempo de ciclo em cada passagem, o que separa imediatamente os passos entre os irritantes e os caros, e esses dois grupos se sobrepõem bem menos do que se imagina. O segundo requisito é mostrar a rota real, com os contornos incluídos. Se três pessoas usam uma planilha compartilhada que não aparece em lugar nenhum do processo oficial, essa planilha pertence ao mapa, porque é estrutural e porque normalmente é ali que se escondem as contradições que quebram a automação.
Por que não simplesmente entrevistar quem faz o trabalho?
Entreviste, mas não pare aí, porque as pessoas são precisas sobre os próprios passos e pouco confiáveis sobre espera, frequência e exceções. Alguém descrevendo sua parte de um processo dá um bom relato do que faz e um relato ruim de quanto tempo o trabalho fica parado entre a parte dela e a seguinte, porque ninguém vivencia a fila em que não está. Ela também descreve o processo como ele deveria rodar, o que não é desonestidade e sim a forma natural de responder a uma pergunta sobre o próprio trabalho. Noventa dias de dados de sistema corrigem as duas distorções: mostram a distribuição em vez da impressão, cobrem as noites e fins de semana de que ninguém se lembra, e incluem os casos abandonados, que por definição ninguém recorda. As entrevistas então passam a servir a outro propósito, que é descobrir por que os dados têm aquela cara.
O que é o custo do caos e como ele é calculado?
É o dinheiro perdido por semana em retrabalho manual, passagens perdidas e espera, calculado sobre os processos candidatos e não sobre a empresa inteira. Em um projeto essa cifra foi de 3.140 dólares por semana em três processos, e seu propósito é estreito mas importante: é a linha de base contra a qual toda alegação posterior de retorno é medida, para que ninguém compare em silêncio um número de depois com um antes imaginado. Ele é deliberadamente construído a partir do custo total da hora e não do salário de anúncio, do mês fraco e não do bom, e de volumes tirados dos sistemas e não de uma conversa. Ele também é deliberadamente incompleto: uma perda que não dá para precificar sem supor uma taxa de conversão fica na página como achado e fora do total, porque uma suposição enterrada numa linha de base torna em silêncio infalsificável tudo o que for construído em cima. Um custo do caos calculado de qualquer outra forma bajula o projeto, e um projeto bajulado reprova na mesma aritmética depois, só que já com alguém pago.
O que o cliente leva quando o trabalho acaba?
O mapa, a linha de base e a matriz de prioridades, e os três servem independentemente de algo ser construído. Isso importa mais do que parece, porque é o que permite ao estágio Break concluir que não há projeto que valha a pena. Se a aritmética não sobrevive, o trabalho termina ali e o depósito do diagnóstico é devolvido, e o cliente ainda sai com um retrato quantificado da própria operação que antes não tinha. Isso também barateia o segundo projeto, já que a parte cara de qualquer automação é descobrir como o trabalho realmente se move e não escrever o código que o move. Um fornecedor cujo diagnóstico não produz nada reaproveitável produziu um documento de vendas, não uma auditoria.
