.
Quem programa software sabe, em princípio, programar. Duvido é que saiba, ou que dê atenção aos conceitos usados na área da qualidade.
.
Uma não-conformidade, um defeito, uma falha é detectada!
.
Nesse instante, o operário sabe o que está mal, sabe que há uma não conformidade e, pode ir ao quiosque electrónico da sua bancada de trabalho registar a ocorrência da não-conformidade e o motivo (furação em falta? dimensões erradas? ...) da não-conformidade. Por que é que o software lhe há-de pedir para registar a origem da não-conformidade naquele momento? Será que ele pode perder tempo a identificar se a falha foi de um subcontratado, ou se foi da engenharia, ou se foi do armazém?
.
Depois, no seguimento do tratamento da não-conformidade, o passo seguinte, segundo o software, é desenvolver uma acção correctiva...
.
Wrong again!!!
.
Perante uma não-conformidade a prioridade é corrigir, ou seja, eliminar a não-conformidade. Não se fazem acções correctivas para eliminar não-conformidades, fazem-se correcções para eliminar não-conformidades e fazem-se acções correctivas para reduzir a probabilidade de uma não-conformidade voltar a acontecer. Como? Atacando as causas da não-conformidade!
.
Só depois da correcção é que se coloca a questão de saber se se deve desenvolver uma acção correctiva. Uma acção correctiva é desencadeada por uma situação concreta.
.
Depois, no seguimento do software no que diz respeito ao follow-up das não-conformidades outra falha, desenvolver acções preventivas por causa dessa não-conformidade. OMG!!!
.
Acções preventivas atacam as causas das potenciais não-conformidades, das que ainda não aconteceram. Acções preventivas ocorrem quando na sequência da análise de dados resolvemos melhorar tendências.
.
Origem, motivo, causa, correcção, acção correctiva, acção preventiva
Sem comentários:
Enviar um comentário