Como formular um Problema? A3, PDSA, Ishikawa, entre outros

Quais os 4 erros comuns na hora de formular um problema?

Nelson P. Repenning, Don Kieffer e Todd Astor, professores do MIT e pesquisadores sobre o tema, elencam 4 erros comuns na hora de formular um problema. Evitar esses erros é fundamental para formular declarações de problemas eficazes e focar sua atenção nas questões que realmente importam para você e sua organização.

Não Formular o Problema

O erro mais comum é ignorar completamente a formulação do problema. As pessoas geralmente assumem que todas já concordam com o problema e devem apenas se ocupar em resolvê-lo. Infelizmente, essa clareza e semelhança raramente existem.

Declaração do Problema como Diagnóstico ou Solução

Outro erro frequente é a formulação de uma declaração de problema que pressupõe o diagnóstico ou a solução. Uma declaração de problema que presume o diagnóstico geralmente soa como “O problema é que não temos os recursos de TI certos”, e um que pressupõe uma solução soará como “O problema é que não gastamos o dinheiro para atualizar nosso sistema de TI.

Nem uma declaração de problema é eficaz, porque nenhuma delas refere-se a metas ou alvos com os quais a organização realmente se preocupa. A meta geral é implícita, e a pessoa que formulou a declaração pulou diretamente para um diagnóstico ou uma solução. Permitir que diagnósticos ou soluções propostas se insinuem nas declarações de problemas significa que você ignorou uma ou mais etapas na cadeia lógica e, portanto, perdeu uma oportunidade de se envolver em processamento cognitivo consciente.

Falta de uma lacuna clara

Um terceiro erro comum é não articular uma lacuna clara. Essas declarações de problemas soam como "Precisamos melhorar nossa marca" ou "As vendas precisam aumentar". A falta de uma lacuna evidente significa que as pessoas não estão envolvidas em um claro contraste mental e cria dois problemas relacionados. Primeiro, as pessoas não sabem quando atingiram o objetivo, dificultando que se sintam bem com seus esforços. Em segundo lugar, quando as pessoas lidam com problemas mal formulados, tendem a fazê-lo com soluções grandes, de tamanho único, que raramente produzem os resultados desejados.

O problema é muito grande

Muitas declarações de problemas são muito grandes. As formulações de problemas de escopo amplo levam a iniciativas grandes, caras e lentas; declarações de problemas focadas em uma manifestação aguda e específica levam a resultados rápidos, aumentando tanto a aprendizagem quanto a confiança.

Use a árvore de alcance do John Carrier e encontre uma manifestação específica do seu problema que crie as maiores dores de cabeça. Se você puder resolver essa instância do problema, estará no caminho certo para mudar sua organização para melhor.

Formular boas declarações de problemas é uma habilidade que qualquer um pode aprender, mas é preciso praticar. Se você aproveitar a contribuição de seus colegas para desenvolver suas habilidades, conseguirá melhores formulações mais rapidamente.

Embora muitas vezes seja difícil formular uma declaração clara dos desafios que você enfrenta, é muito mais fácil criticar os esforços de outras pessoas, porque você não tem as mesmas experiências e está menos envolvido em um determinado resultado. Quando pedimos aos nossos alunos que treinem uns aos outros, suas formulações problemáticas geralmente melhoram drasticamente em apenas 30 minutos.

Como estruturar a Solução de Problemas?

Ao abordar problemas mais complexos, você precisará complementar a formulação de um bom problema com uma abordagem estruturada para a solução de problemas. A resolução estruturada de problemas nada mais é do que os elementos essenciais do método científico - um ciclo iterativo de formular hipóteses e testá-las por meio de experimentação controlada refeita para a complexidade do mundo fora do laboratório.

Edwards Deming e seu mentor Walter Shewhart, os avós da gestão da qualidade total, foram talvez os primeiros a perceber que essa disciplina poderia ser aplicada no chão de fábrica. O ciclo PDSA de Deming, ou Plan-Do-Study-Act, foi uma criação para articular uma hipótese clara (um Plano), executar um experimento (Do the Plan), avaliar os resultados (Study) e então identificar como os resultados mostram os futuros planos (ato). [caption id="attachment_17160" align="aligncenter" width="700"] Ciclos PDCA e PDSA[/caption]

Desde o trabalho de Deming, várias variantes de solução estruturada de problemas foram propostas, todas destacando o valor básico de iterar entre articular uma hipótese, testá-la e depois desenvolver a próxima hipótese. Em nossa experiência, garantir que você use um método estruturado de solução de problemas é muito mais importante do que o método específico que você escolhe.

Nas duas últimas décadas, fizemos projetos usando todos os métodos populares e supervisionamos e treinamos mais de 200 projetos de alunos usando-os. Os autores estruturaram uma abordagem híbrida para orientar e relatar a solução de problemas, que é simples e eficaz. Capturaram nossa abordagem em uma versão do famoso formato A3 da Toyota. Os autores modificaram o A3 para permitir seu uso para o trabalho em configurações diferentes da fabricação.

Como formular um problema com o A3?

O formulário A3 original foi desenvolvido pela Toyota Motor Corporation para apoiar o compartilhamento do conhecimento em suas fábricas, resumindo um esforço estruturado de solução de problemas em uma única página. Embora o formulário possa frequentemente ter documentação de apoio, restringir o resumo do projeto a uma única página força o usuário a ser muito claro em seu pensamento.

O A3 divide o processo estruturado de solução de problemas em quatro etapas principais, representadas pelos grandes quadrantes, e cada grande passo tem subfases menores, capturadas pelas porções abaixo das linhas pontilhadas. O primeiro passo (representado pela caixa no canto superior esquerdo) é formular uma declaração clara do problema. Na seção Background (na parte inferior da caixa da Declaração de Problemas), você deve fornecer informações suficientes para vincular claramente a declaração do problema à missão e aos objetivos maiores da organização.

Observando o design atual

O próximo passo no processo A3 é documentar o projeto atual do processo, observando o trabalho diretamente. Devido ao processamento automático, a maioria das pessoas, especialmente aquelas que realizam tarefas repetitivas, não podem descrever com precisão como elas realmente executam seu trabalho. Por meio da correspondência de padrões, eles desenvolveram um conjunto de ações habituais e respostas rotineiras, das quais podem não estar inteiramente conscientes.

Como as pessoas que fazem o trabalho muitas vezes não conseguem descrever totalmente o que fazem, você, como gerente, deve se aproximar o máximo possível do local do problema e observar o trabalho que está sendo feito. Taiichi Ohno, um dos fundadores do sistema de produção da Toyota, desenvolveu o Gemba Walking (Gemba é uma palavra japonesa que se traduz aproximadamente como “o lugar real”) como um meio para os executivos descobrirem o que realmente acontece em um dia.

O objetivo é entender como o trabalho é realmente feito. Isso pode significar observar uma enfermeira e um médico realizando um procedimento médico, engenheiros em uma reunião de design ou vendedores interagindo com um cliente.

Os executivos seniores muitas vezes estão completamente afastados do trabalho diário das organizações que lideram. Consequentemente, observar e entender completamente o estado atual do trabalho geralmente sugere oportunidades fáceis de melhoria. Damos aos nossos alunos a seguinte regra prática para guiar seus esforços: quando você vai ver o trabalho, se você não ficar constrangido com o que encontra, provavelmente não está olhando bem de perto.

Recentemente, ajudamos uma equipe a resolver o problema de reduzir o tempo de processamento das faturas. Ao percorrer o processo, a equipe observou que cada fatura passava vários dias esperando que o código de razão geral adequado fosse adicionado. A investigação, no entanto, revelou que, para esse tipo de fatura, o código era sempre o mesmo;

Raiz dos problemas

Observar de perto o trabalho frequentemente solta uma série de preconceitos. O próximo passo no preenchimento do A3 é analisar as causas-raiz e engajar seu processamento consciente ligando explicitamente suas observações à declaração do problema.

Há uma variedade de técnicas e estruturas para guiar uma análise de causa raiz. Talvez a mais famosa, seja a do Sakichi Toyoda, fundador da Toyota Industries, que sugeriu perguntar “5 porquês”, significando que para cada problema observado, o investigador deveria perguntar “por que” cinco vezes na esperança de que cinco níveis de investigação revelem a verdadeira causa de um problema.

Mais tarde, Kaoru Ishikawa desenvolveu o diagrama “espinha de peixe” para fornecer uma representação visual das múltiplas cadeias de investigação que podem ser necessárias para se aprofundar na causa fundamental de um problema. Desde então, praticamente todos os métodos estruturados de solução de problemas ofereceram uma ou mais variantes do mesmo método básico para escavar na fonte de um problema.

O objetivo de todas as abordagens de causa básica é ajudar o usuário a entender como o problema observado está enraizado no projeto existente do sistema de trabalho. Infelizmente, esse tipo de pensamento sistêmico não é natural. Quando vemos um problema (mais uma vez, graças à correspondência de padrões), temos uma forte tendência de atribuí-lo a uma causa imediata e facilmente identificável.

Essa pode ser a pessoa mais próxima do problema ou a causa técnica mais óbvia, como um suporte quebrado. Nossos cérebros são muito menos propensos a ver que existe um sistema subjacente que gerou aquele indivíduo mal treinado ou o suporte quebrado. Resolver o problema imediato não fará nada para evitar manifestações futuras a menos que abordemos a causa no nível do sistema.

Uma boa análise de causa básica deve ser baseada em sua investigação para mostrar como o sistema de trabalho que você está analisando gera o problema que você está estudando como parte das operações normais. Se a análise da causa-raiz identificar uma série de eventos especiais que provavelmente não acontecerão novamente, você não aprofundou o suficiente.

Por exemplo, os problemas no atendimento ao cliente frequentemente diferem de instância para instância e são facilmente atribuídos a coisas que “acontecem uma vez na vida e nunca poderiam acontecer novamente”. No entanto, cavar mais fundo pode revelar um processo de treinamento defeituoso para aqueles que lidam com clientes ou um processo inconsistente de integração de clientes. Uma boa análise de causa raiz vincula os dados obtidos em sua investigação à declaração de problema para explicar como o sistema atual gera os desafios observados não como uma causa especial, mas como parte da conduta de rotina.

Design Alvo

Depois de vincular os recursos do sistema de trabalho ao problema que você está tentando resolver, use a seção Design de destino do formulário A3 para propor um sistema atualizado para resolver o problema. Muitas vezes as mudanças necessárias serão simples. Na seção Target Design, você deve mapear a estrutura de um sistema de trabalho atualizado que funcionará mais efetivamente.

Isso pode ser tão simples quanto dizer que, a partir de agora, imprimiremos o código contábil geral no formulário da fatura ou algo mais complicado, como mudanças nos programas de treinamento e de embarque. As mudanças necessárias raramente serão um programa ou iniciativa totalmente nova. Em vez disso, elas devem ser modificações específicas e direcionadas que surgem da análise da causa-raiz. Não tente resolver tudo de uma vez; propor o conjunto mínimo de mudanças que o ajudarão a progredir rapidamente em direção ao seu objetivo.

Objetivos e Diretrizes de Liderança

Completar a seção Target Design requer dois componentes adicionais. Primeiro, crie um objetivo de melhoria - uma previsão sobre quanto de melhoria suas alterações propostas irão gerar. Uma boa declaração objetivo é construída diretamente a partir da declaração do problema, prevendo quanto da lacuna você vai fechar e quanto tempo levará para fazê-lo.

Se o seu problema for “24% das nossas interações de serviço não geram uma resposta positiva de nossos clientes, excedendo em muito nossa meta de 5% ou menos”, uma meta de melhoria pode ser “reduzir o número de interações de serviço negativas em 50% em 60 dias. ” Objetivos claros são altamente motivadores e a articulação de uma previsão facilita o aprendizado efetivo.

Por fim, defina as diretrizes de liderança. Diretrizes são os “guard-rails” para a execução do projeto; eles representam limites ou restrições que não podem ser violados. Por exemplo, as diretrizes de liderança para um projeto focado na redução de custos podem especificar que o projeto deve identificar uma inovação que reduza custos sem compensar a qualidade.

Plano de execução

O próximo passo é executar o experimento. Na parte superior da caixa Plano de execução do formulário A3, estabeleça um plano para implementar o design proposto. Certifique-se de que o plano seja dividido em um conjunto de atividades claras e distintas (por exemplo, ter o formulário da fatura reimpresso com o código da razão geral ou realizar uma reunião diária para revisar problemas de qualidade) e que cada atividade tenha um proprietário e uma entrega encontro.

Agora execute seu plano e alcance seu alvo. Mas, mesmo quando você começa a executar, você não está envolvido em um aprendizado consciente. Em vez disso, você quer ter certeza de que não está apenas resolvendo o problema, mas também absorvendo todas as lições associadas. Acompanhe cada atividade em relação a sua data de vencimento e observe as atividades que ficam para trás.

Essas lacunas também podem ser objeto de solução estruturada de problemas. Durante essa fase, os relatórios intermediários do projeto devem ser simples: o proprietário da ação deve informar se esse elemento está adiantado ou atrasado, o que foi aprendido no último conjunto de atividades e que ajuda ele pode precisar.

Na seção Resultados da trilha do formulário, avalie o progresso em direção à sua meta. Por exemplo, se a meta geral é reduzir o número de interações de serviços ruins em 50% em 60 dias, defina metas intermediárias, talvez semanalmente, com base no seu plano de intervenção.

Coloque esses alvos intermediários na primeira coluna da seção Resultados da Trilha e, em seguida, meça seu progresso em relação a eles. Além disso, certifique-se de que você continue a acompanhar os resultados por um longo período depois de ter atingido o seu alvo. Você quer resultados que se mantenham.

Quando o projeto estiver concluído, documente o que você aprendeu na seção O que aprendemos e o que vem a seguir. Aqui você deve descrever as principais lições do projeto e articular as novas oportunidades que seu projeto revelou. Se você excedeu suas previsões, o que isso lhe diz sobre possibilidades futuras?

Em contraste, ficar aquém do seu alvo pode revelar partes do sistema de trabalho que você não entende tão bem quanto você pensou. Finalmente, e talvez mais importante, que problema você vai enfrentar em seguida? Um processo que funcione bem, seja na manufatura, no atendimento ao cliente ou no desenvolvimento de novos produtos, é o produto de inúmeras pequenas mudanças, e a correção de um problema real muitas vezes revela muitos problemas prementes adicionais. Feche seu A3 descrevendo o próximo problema que você e sua organização precisam resolver.