Lean Office: Evitando erros em processos administrativos (Poke Yoke)

Lean Office: Evitando erros em processos administrativos (Poke Yoke)

Um escritório enxuto (lean office) é aquele que utiliza a filosofia Lean para identificar e tratar desperdícios. No post anterior, comentei sobre o conceito e os tipos de desperdícios que impactam a eficiência administrativa. Neste, disserto um pouco sobre um tipo específico de desperdício, o defeito, e como evitá-lo usando Poke Yoke.

O que são defeitos?

Defeitos são entregas que não atendem às necessidades, especificações, modelos etc, sejam nos processos de gestão de projetos, controle financeiro, staffing, recrutamento etc.

Exemplos de defeitos administrativos podem ser:

  • Dados não inseridos – Os dados não foram inseridos em sua totalidade, ou nenhum dado foi inserido, num formulário, sistema ou repositório
  • Dados, processamento ou local errados – Os dados foram inseridos equivocadamente, com erros ou registrados no local errado.
  • Dados publicados fora do prazo – Não se cumpriu um prazo para inserir ou processar informações.
  • Diferenças entre previsto e realizado – Houve uma diferença entre os valores esperados e os inseridos.

Estes e outros defeitos podem causar transtornos e muitas vezes as áreas de apoio não compreendem a dificuldade de um simples “copy and paste”, o que eventualmente gera conflitos que podem tomar proporções indesejáveis.

Analisar defeitos em processos administrativos

Necessidade

Entendo que o primeiro item a observar é se, de fato, o processo é necessário. Não raro, vejo empresas com controles excessivos que acabam gerando defeitos. Então, a primeira sugestão é observar se é realmente necessário que um processo exista e, para isso, deve-se mapear o fluxo de valor para checar se há algum outro tipo de desperdício.

A pergunta chave é: gera valor ao cliente? Se não gerar, é sempre um forte candidato à eliminação, automatização ou delegação.

Silva (2011) faz um paralelo entre manufatura e escritório, no aspecto “valor”:

Manufatura Escritório
Valor Visível em cada passo; objetivo definido Difícil de enxergar, objetivos mutantes
Fluxo de Valor Itens, materiais, componentes Informações e conhecimento
Fazer fluir Interações são desperdícios Interações planejadas devem ser eficientes
Deixar o cliente puxar Guiado pelo Takt Time Guiado pela necessidade da empresa
Perfeição Possibilita a repetição de processos sem erros O processo possibilita melhoria organizacional

Às vezes continuamos seguindo processos sem recordar o motivo (superprodução), geramos indicadores que ninguém analisa (processamento) ou tentamos monitorar demais (intelecto), por não confiar na responsabilidade das pessoas (accountability).

Este último é mais um fator social que processual. Se alguém não estiver apto a responsabilizar-se por determinada função, é melhor que treinemos, acompanhemos, troquemos de função ou demitamos a pessoa. Assim, evitamos o equívoco “pelo erro de um, pagam todos”, que causa grandes desperdícios.

Frequência

Estando seguro de que o processo é necessário, vale analisar a frequência de ocorrência de um defeito, o que se faz através de um histograma.

Curva normal / distribuição gaussiana / regra dos 3 sigma

Esta ferramenta nos permite analisar não apenas o percentual, mas a distribuição de ocorrência. Observando os pontos extremos, é possível fazer o isolamento de um aspecto (e.g. cliente, departamento, perfil de pessoa, ferramenta utilizada etc) para seguir a uma análise causal.

Pode-se também utilizar gráficos de controle (também chamados de diagramas de dispersão ou cartas de controle) para identificar se, de fato, os defeitos configuram eventos relevantes ou se são desvios normais do processo.

É importante lembrar que um processo com defeito 0 é algo praticamente impossível. Ainda que seja realizado por máquinas, uma matéria-prima com a mínima variação pode influenciar no resultado. Mesmo processos “6 sigma” tem níveis de qualidade com 99,9997% de acertos e constituir um processo com uma variabilidade tão pequena pode custar uma fortuna, avalie se vale realmente a pena.

Análise Causal

Existem diversas ferramentas para fazer análise causal de defeitos, desde o FMEA, 5 porquês, barreira de controle, GFCE, AAF até o Ishikawa, que é bem simples e atende a maioria dos casos de análise.

O importante aqui é dar-se ao trabalho de sair um pouquinho do posto de trabalho e conversar com as pessoas, entender os motivos que causam determinado defeito, antes de determinar verdades absolutas. Por vezes, o motivo do não cumprimento de um processo é diferente entre uma pessoa, departamento, empresa e outra.

Priorizando as causas

O bom e velho Pareto ajuda a resolver a questão da priorização. Avaliando a porcentagem de vezes em que determinado fator é causador de um defeito, descobre-se, através dessa heurística, que 20% das causas resolvem 80% dos defeitos. E, sendo assim, basta eliminar estas causas para ter um processo relativamente confiável.

Como elaborar processos anti-defeito?

Bem, aqui entra nosso querido Poke Yoke. Essa ferramenta nasceu da percepção de Shigueo Shingo, líder de produção da Toyota em meados dos anos 1960. Ele percebeu que os erros humanos eram frequentes, não importava o quanto instruísse as pessoas, então resolveu construir processos “à prova de tolos”, tradução do termo.

Num exemplo clássico, os trabalhadores sempre esqueciam de colocar algum parafuso em determinada peça, até que Shigueo resolveu que deveriam pôr todos os parafusos sobre um prato antes de apertá-los, resolvendo, de uma vez por todas o problema.

Daí pra frente, e não se tem um rastro exato disso, surgiram ideias como: um carro só liga com a chave certa; o aviso sonoro na ré quando o carro está prestes a bater em outro; o microondas que só funciona com a porta fechada; cabos, plugs e tomadas que só ligam na posição e formato adequados; equipamentos que não funcionam em determinadas condições etc.

(Outros exemplos no aqui, aqui e aqui).

Exemplos de Poke Yoke em projetos

Pensemos então em algumas situações causam defeitos e como evitá-los:

Situação Exemplo Complicação Solução (Poke Yoke)
Manter controles paralelos, registrando informações em dois lugares. Controlar as finanças do projeto numa planilha e postar o status financeiro num sistema Copiar e colar dados aumenta as chances de o usuário errar Integrar os sistemas, importar planilhas ou construir plataformas unificadas
Extrair dados de um sistema, processá-los e registrá-los novamente no sistema Baixar custos realizados de um projeto, registrar numa planilha para calcular a margem total e registrá-la num status Altíssima probabilidade de erro, similar ao item 1 Criar plataformas unificadas
Muitos campos a preencher num formulário Cadastrar um projeto informando dados como cliente, unidade de negócio, valor, pessoas, controle de faturamento etc, Pode fazer com que o usuário erre por distração ou pressa Restringir os formulários por consistência, orientando o preenchimento ou utilizar predições para inferir informações (Ex: Se o usuário pertence a determinada unidade de negócio, esta já aparece como selecionada)
Associar dados que não necessariamente se mantém consistentes ao longo do tempo Associar o valor da proposta comercial com o valor do projeto Ao longo de um projeto podem ocorrer acréscimos ou reduções combinados por mudanças de escopo Evitar associar dados que não se mantém consistentes ou, se não houver alternativa, permitir que o usuário os altere com facilidade, mediante comentário

Como pode notar, os defeitos são gerados pelos outros tipos desperdícios. Uma abordagem interessante poderia ser tratá-los como riscos, avaliando-se a probabilidade de erro e o impacto financeiro/tempo, definindo estratégias padronizadas e montando planos de respostas para buscar que os processos sejam anti-erro.

Generalizando:

  • Nunca copiar e colar
  • Avaliar se as pessoas tem capacidade e capacitação para realizar
  • Sempre mostrar a diferença entre a meta e o valor realizado automaticamente
  • Apontar potenciais problemas antes de acontecerem

SILVA, André Thomé Da. Método de gerenciamento de processos administrativos de
engenharia de produto. 2011. 109p. Tese (Mestrado em Engenharia Mecânica) – UNICAMP,
Campinas, 2011.

Publicado por: Eli Rodrigues