ISO 9001, para reflexão

O Handelsblatt publicou, no passado dia 7 de Abril, um artigo com um título sugestivo: “Deutschlands Digitalproblem: Viele Projekte, wenig Produkte” - o problema digital da Alemanha: muitos projectos, poucos produtos.

A ideia central é simples e poderosa: o problema não está na falta de ideias, mas nos mecanismos que deveriam transformar invenções em soluções usadas em larga escala.

Um projecto tem início, fim, orçamento e entrega final.
Um produto tem utilizadores, ciclo de vida, manutenção, evolução e impacte real.

Na lógica do projecto, escreve-se a candidatura, desenvolve-se o software, entrega-se o relatório final e encerra-se o trabalho. Se depois ninguém reutilizar a solução, se ela não for transferida para outros contextos, se não gerar impacte, isso raramente é tratado como fracasso. Simplesmente, não fazia parte do plano.

Na lógica do produto, a pergunta é outra: quem usa isto, para quê, com que frequência, que problema resolve, que valor cria e como vai melhorar ao longo do tempo?

Ao ler isto, pensei em muitos sistemas de gestão da qualidade certificados.

Talvez parte das críticas à ISO 9001 nasça precisamente daqui: muitos sistemas são implementados como projectos de certificação, quando deveriam ser desenvolvidos como produtos internos de gestão.

Digo isto também com algum desconforto profissional. Como consultor, não me interessa apenas ajudar uma organização a obter um certificado. Isso pode ser importante, naturalmente. Mas não chega.

O que verdadeiramente me interessa é perceber se o sistema ficou útil depois da auditoria. Se ajuda a empresa a decidir melhor, a reduzir erros, a cumprir melhor os requisitos dos clientes, a aprender com problemas, a controlar alterações, a melhorar processos e a ganhar disciplina de gestão.

Quando o sistema é tratado como projecto, a pergunta dominante é: O que falta fazer para passar na auditoria?

Quando é tratado como produto, a pergunta muda: Quem vai usar isto, para quê, e que problema ajuda a resolver?

Esta diferença muda tudo.

Um SGQ tratado como projecto tende a produzir documentos, procedimentos, registos, mapas, indicadores e evidências.

Um SGQ tratado como produto tem de produzir utilização.

Tem de ser usado pela direcção, pelos responsáveis de processo, pelas equipas operacionais, pelas compras, pelo comercial, pela produção e pela qualidade. Tem de estar ligado à forma como a organização trabalha, decide, aprende e melhora.

O problema não é haver documentação. O problema é a documentação existir para ser mostrada e não para ser usada.

O problema não é haver indicadores. O problema é ninguém tomar decisões com base neles.

O problema não é haver auditorias internas. O problema é elas não gerarem aprendizagem.

O problema não é haver acções correctivas. O problema é fechá-las sem mudar verdadeiramente a forma de trabalhar.

Por isso, cada vez mais, penso que o teste essencial de um sistema de gestão não é apenas perguntar se ele cumpre a norma.

A pergunta mais difícil é outra: Se a auditoria externa desaparecesse amanhã, a empresa continuaria a querer usar este sistema?

Se a resposta for sim, talvez tenhamos criado algo com valor. Se a resposta for não, talvez tenhamos apenas terminado um projecto. E esta é uma responsabilidade séria para quem implementa, mantém ou audita sistemas de gestão.

A certificação pode ser o ponto de chegada de um projecto. Mas a eficácia do sistema só começa verdadeiramente a ser provada depois, quando a organização o usa sem estar a representar para o auditor.

No fundo, um sistema de gestão da qualidade devia ser visto como um produto interno de gestão: com utilizadores reais, necessidades reais, melhoria contínua e impacto mensurável.

Porque um bom sistema não é aquele que sobrevive à auditoria. É aquele que ajuda a empresa a sobreviver melhor à realidade.