Está en la página 1de 22

8

1. Definicin

QC Story: un mtodo de resolucin de problemas

QC Story es aplicable no solamente a problemas de calidad, sino tambin a problemas de
productividad, costos, logstica, energa, seguridad, etc.
Asi pues QC Story, que tiene un proceso estandar y diIerentes utiles, es aplicable a problemas de
diIerente naturaleza.

En este documento hablaremos del proceso y poco de mtodos o utiles ~~ asociados que son objeto
de otros documentos. Sin embargo encontrareis al Iinal un recordatorio sobre los 7 utiles basicos de la
calidad y su aplicacion en las diIerentes etapas.
Cualquiera que sea el nivel de conocimiento de los tiles de la Calidad ~~, los principios de QC
Story son aplicables por todos y en la mayor parte de los casos.
El nivel de conocimiento o competencias en los utiles de la Calidad, en particular en los utiles de
analisis, es una ventaja importante para el que empieza.

La gestion utilizada por QC Story es valida tanto en el caso de resolucion de problemas en grupo como a
nivel individual. En el caso individual la utilizacion de un Iormato no es indispensable, pero es necesario
en periodo de aprendizaje, o para la comunicacion de los resultados.


QC Story: un medio de comunicacin

QC Story es tambin, como veremos, una herramienta de resolucion de problemas y Irecuentemente
tambin una herramienta de comunicacin. En eIecto, no es raro que el problema tratado aIecte a
otros compaeros, o bien sea necesario comunicarlo dentro de la empresa (capitalizacin).
La Alianza con Nissan muestra que la utilizacin de grficos, dibujos, o esquemas permiten una mejor
comunicacion, con independencia del idioma.
Mucho mejor, la representacion esquematica de un problema, permite a menudo dar un paso
suplementario hacia su comprensin.

Captulo 1: Qu es el QC Story?
<<QC STORY>> es un mtodo de resolucin de problemas, basado en la consideracin de los
hechos y los datos, sin especulacin, para un problema que est causado por numerosos elementos.
9
QC Story: una filosofa

Por su aplicacion rigurosa y generalizada, QC Story es considerado hoy dia por el management de
Nissan como parte de la filosofa de la Empresa. En eIecto, como nuestra vida proIesional esta llena de
problemas~~, QC Story, y todos los principios que le rigen , deben ser utilizados constantemente. La
prctica regular, permite dejar atras la simple aplicacion del mtodo e integrar los principios en la
actividad de todos los dias y hacer de ello una IilosoIia. Por otra parte muchos managers de Nissan
reconocen utilizar QC story en su vida privada como una reIlexion innata.


Significacin del trmino <<QC Story>>

El trmino QC~~ viene de un trmino genrico de la Iamilia de otros mtodos de Calidad tales como
TQC, SQC, QC nuevos 7 utiles, etc.
QC signiIica Control de Calidad ~~ pero raramente es deIinida completamente, ni en los libros, ni
en la expresion corriente.
El trmino Story~~ recuerda que la vida~~ de un problema, es contada como una pequea
historia que cada uno puede Iacilmente comprender y transmitir.

2. Puntos claves

Ademas de seguir una sistematica estructurada, la dinamica de QC Story ~~ para que tenga xito
depende de los puntos claves siguientes:


1. Considerar los hechos y los datos, sin especular
2. Tomar en cuenta la dispersion (no solamente la media)
3. Implicar al maximo las personas concernidas.
4. El proceso es tan importante como el resultado.
5. Hacer un planning utilizando el ciclo PDCA y mantenerle.
6. Conservar las 9 etapas, y usar los utiles habituales.
7. Las mejoras solo son utiles, si son duraderas (estandarizar).
8. No tener miedo al cambio ni a los errores.
9. Nadie se mueve sin motivacion.
y sobre todo: practicar, practicar, practicar, ... ...
10

3. Historia de QC Story

El libro Economic control oI quality oI manuIactured product ~~ ( por W.A. Shewart de los
laboratorios Bell en USA ) editado en 1931, es considerado como el primer trabajo sobre el MSP (
Dominio Estadistico del Proceso).
Es el origen de QC Story ~~.

El Dr. Deming introdujo el MSP en Japon en 1950, despus QC Story Iue aplicado a la actividad de
todos y no solo a la Iabricacion o la calidad.

Llego a ser no solamente la base de Kaizen, sino tambin un medio de aumentar la consciencia QCD
de todos.

Aos mas tarde Nissan lo introdujo en toda la empresa, y QC Story se convirtio en uno de los mtodos
indispensables para la calidad y la productividad creciente de Nissan.

En el continente Europeo, QC Story Iue introducido en 1992 en la Iabrica Nissan de Sunderland (G.B.)
despus en la de Barcelona.

La Alianza Renault-Nissan es la ocasion, dentro del marco del SPR, de comprender las razones de esta
generalizacion exitosa de QC Story y de aplicar sus beneIicios.

Desde la puesta en marcha el QC Story, Nissan ha evolucionado de un proceso de 11 etapas a otro mas
sinttico de 9 etapas.
Este es el proceso que se presenta en las paginas siguientes.





















11


1. Diferentes tipos de problemas
Antes de presentar la metodologia de resolucion de problemas, es necesario deIinir que entendemos por
problema ~~.


Esta deIinicion nos lleva a considerar dos situaciones principales:
1.- El problema es el resultado de un disfuncionamiento: alguna cosa no es conIorme a las
especiIicaciones. Es el caso de una pieza o un sistema que se desajusta ~~. En este caso , resolver el
problema es volver a la normalidad ~~.
2.- El problema es el resultado de un deseo de mejorar lo existente: una oportunidad de
progreso o un nuevo objetivo que es asignado a unos parametros que rinden a una "normalidad"
obsoleta. En este caso resolver el problema es hacer progresar el nivel conocido

Destacar que en la vida corriente, no hay a priori un problema ~~, pero algunas situaciones son
vividas o no como problemas, la sensibilidad de cada uno hacia un problema depende de nuestra propia
percepcion.
Comprendemos las diIicultades Irecuentes de entendernos sobre la importancia de los problemas, y la
necesidad de intentar deIinir objetivamente los diIerentes niveles de diIicultad de los problemas. Es el
objeto del parraIo siguiente.

2. Problemas simples, problemas complejos

Un problema simple es un problema para el que podemos reunir inIormaciones, datos ciIrados por
recopilacion y observacion del eIecto.
En este caso las relaciones de causa-eIecto pueden ser establecidas por el analisis, y las acciones sobre
las causas hacen desaparecer el problema.
Reconocemos aqui la mayor parte de los problemas tcnicos: maquinas paradas, desreglaje de utiles...
Estos problemas se rigen bajo el principio de las mismas causas producen siempre los mismos
efectos, y son el lugar privilegiado para la utilizacion de la MSP (especialmente).

Un problema complicado no diIiere mucho de un problema simple, solamente en el numero de
elementos que comportan. En el mundo del automovil Irecuentemente nos enIrentamos a este tipo de
problemas.
Un problema complicado pude ser descompuesto en varios problemas simples y pueden ser tratados
con la ayuda de los mismos mtodos.


Sin embargo, algunos problemas complejos tienen la particularidad de no tener una relacion simple
entre las causas y los eIectos: las mismas causas no producen siempre los mismos efectos.
Captulo 2: QU ES UN PROBLEMA ?
Un problema es la diferencia entre lo que es y lo que debiera ser o pudiera ser.
12
Es el caso de los problemas que comportan una dimensin humana y ligada a sistemas vastos que
interaccionan en todo momento con el entorno: la empresa es un buen ejemplo pero tambin algunos de
sus componentes como un taller o incluso una persona que trabaja en un entorno proIesional.
Los mandos se enIrentan Irecuentemente a problemas complejos, pero es evidente que si el dominio de
los problemas complejos es diIicil, lo es mucho mas sino se sabe abordar correctamente la resolucion de
problemas, simples (o complicados).

3. Problema y estndar

En el marco de un sistema de produccion que se apoya sobre el principio de los estandares ~~, la
nocion de problema ~~ puede precisarse un poco mejor.

Todo producto o servicio creado por un proceso adecuado tiene un cliente que espera unas perIormances
QCD dadas: un problema aparece cuando hay una diferencia entre el QCD esperado y el QCD
obtenido.
El objetivo del estandar es asegurar a todos los niveles esta perIormance esperada, y deIinir el valor de
los parametros que inIluyen en su resultado.

Entonces cuando una diIerencia QCD aparece, debemos en primer lugar veriIicar si el estandar ha sido
respetado. Si el estndar no ha sido respetado, no hay problema: volver al estandar debe permitir
restablecer el QCD.
Si el estndar ha sido respetado, es cuando hay realmente un problema: la utilizacion del QC Story
debe permitir restablecer el QCD.

4. Problema y Progreso

Toda empresa no cesa de preocuparse por mejorar con el Iin de satisIacer siempre a sus clientes en un
compromiso permanente en Calidad Costo y Plazo.
Con el Iin de conservar este Iragil equilibrio cara a las exigencias cada vez mayores de los clientes, la
Empresa trata de eliminar todos los disIuncionamientos existentes en su organizacion.
En esta logica todo problema ~~ es entonces una oportunidad de mejorar en QCD y debe ser
abordado como una suerte en nuestra actividad. Como hariamos nosotros para mejorar si no
encontraramos nunca nuestros problemas ?.
La acumulacion de problemas es una diIicultad muy pesada Irecuentemente que el management debe
ayudar a gestionar dando prioridades.









Es necesario decir siempre: bienvenidos los problemas ! ~~
13



QC Story es un proceso estndar llamado las 9 etapas de QC Story ~~, Iundamentado sobre el ciclo
P(S) - D - C - A.

Conservar este proceso es muy importante, no omitir ninguna etapa. Esto hara nuestro trabajo mas
Iacil, tanto mas si la actividad dura mucho tiempo (algunas semanas), o si es necesario trabajar en grupo.
En la practica, a veces es necesario adjuntar inIormacion de etapas precedentes cuando esta muy
avanzado el QC Story. Por ejemplo, la etapa de analisis (etapa 5) puede permitir completar la etapa de
comprension de la situacion actual (etapa 3) recuperando nuevas inIormaciones.



Las 9 etapas de QC Story




















Captulo 3 : LAS 9 ETAPAS DE QC STORY

1. Elegir el tema
2. Explicar las razones de la eleccin
3. Comprender la situacin actual
4. Elegir las metas
7. Confirmar los efectos
5. Analizar
6. Poner en marcha las medidas
correctivas
9.-Sintetizar y planificar acciones
futuras
8.-Estandarizar
14
FASE <<PLAA >> del PDCA


La primera etapa en la resolucion de problemas es encontrar un problema y darle un nombre que
permita a todos comprender de una Iorma simple su naturaleza.
Como algunas personas se arriesgan a trabajar juntos sobre el problema, es importante seleccionar un
asunto motivador y que represente un reto.
Ademas, si comunicamos el problema en la empresa, la manera de expresar el asunto sera muy util a
otros a Iin de comprender bien la naturaleza del problema y asi obtendremos mas Iavorablemente su
participacion.

1. Cmo elegir el tema?

En nuestra vida proIesional (y no solamente) nos encontramos con problemas de diIerente naturaleza y
en grandes cantidades, necesitamos una tcnica para elegirles.
Esta tcnica se describe a continuacion.

Comprobar el rol de cada servicio, departamento y funcin.
Cada servicio y departamento en la empresa tiene su propio rol a jugar y una Iuncion a cumplir.
Debemos comenzar por comprender como deberiamos eIectuar nuestro trabajo y como deberiamos estar
organizados.

Verificar las responsabilidades y los objetivos asignados a la zona de trabajo.
Es preIerible que el problema elegido se corresponda en un alto grado de prioridades con la politica
general, deberemos releer, por ejemplo los objetivos del PAP o del servicio. Sabremos asi si cumplimos
de manera correcta nuestro rol en la puesta en marcha de politicas anuales de nuestro sector.

Identificar y listar los problemas.
Utilizando las preguntas abajo indicadas, identiIicar los problemas, examinando los roles del servicio y
departamentos, los objetivos de los talleres, de la UET, de las secciones; tambin los problemas diarios,
las demandas de los superiores, y a continuacion organizarles bajo una "lista de temas"..
Puede ser util identiIicar los problemas segun los dos angulos siguientes:
Qu tipos de problemas nos molestan?
Qu cosas nos gustara mejorar?
Estos nos permitiran desarrollar dos tipos de temas:
Los problemas correspondientes a una no calidad~~ identiIicada
La puesta en causa del estandar actual con el objetivo de mejorar (siempre que no comporte
un problema identiIicado para el cliente).

Evaluar los problemas y seleccionar un tema.
Seleccionar un problema importante proveniente de las listas anteriores. A veces se puede elegir
Iacilmente un problema discutiendo, en otros casos con mtodos tales como un graIico de evaluacion
de problemas ~~ es necesario para elegir uno solo. Debemos tambin interesarnos en obtener la
evaluacion de los temas por nuestros superiores y permitirles que expresen su opinion.

Etapa 1: Elegir el tema
15















Sistemtica para la identificacin de problemas

2. Cmo expresar el tema?
Una buena manera de expresar un tema es:
ACCIN (verbo) OB1ETO (nombre) LUGAR

Dnde? (OIicio, maquina, operacion,
producto, sitio, puesto de trabajo, etc.)
Qu cosa? (caracteristica de control)
Cmo, de qu manera? (sentido de la mejora, importancia)

3. Puntos clave
7 puntos clave a tener en cuenta para la descripcin de los temas
1. Establecer donde se situa la mejora (nombre del proceso, titulo del trabajo, nombre del
producto, etc.)
2. Hacerlo de Iorma que en el titulo del problema haga aparecer qu es necesario hacer y cual es
el objetivo.
3. Expresar el problema en los trminos de atacar lo que esta mal, mejor que mejorar alguna cosa
que ya esta bien (esta ultima expresion tiende a obligar a las personas a eliminar alguna cosa
del ideal).
Ejemplos:
- Mejorar la calidad reducir la no calidad
- Mejorar el plazo reducir el numero de dias de retraso
Etapa 1: Elegir el tema
Observar los temas que tienen problema
Comparar con el ideal
Comparar con la politica
Observar los temas que molestan a los
procesos siguientes
Comparar con las especiIicaciones
Comparar con los estandares
Comparar con la situacion pasada
Comparar con otros talleres
Problemas Organizarles Evaluarles Elegir uno
16



4. Expresar en trminos de resultados antes que de mtodos
Ejemplo:
- Preparar un manual de instrucciones para las llamadas de reserva de hotel reducir el
tiempo de espera en las reservas de habitacion por telIono.

5. No conIundir las soluciones con los problemas:
Ejemplo:
- Mejorar la Iormacion producto para el equipo de ventas mejorar el conocimiento del
producto del equipo de ventas.
- Ordenar la oIicina reducir el tiempo de acceso a los documentos.

6. Expresar claramente: utilizar verbos de accion
Ejemplo:
- Intentar reducir los deIectos reducir los deIectos

Una buena eleccin de un tema satisIace las condiciones siguientes:
1. Fuertemente necesario y necesario para todos
2. DiIicil pero posible
3. Vinculado a la politica y a los objetivos de la division y del departamento.

Ademas si la actividad se desarrolla en grupo el tema debe:
4. Ser comun a todos los miembros del grupo.
5. Permitir acrecentar el nivel de practica del grupo.

















Etapa 1: Elegir el tema
17



1. Principios

Explicar los Iundamentos, la importancia y urgencia del problema. Hacerse estas preguntas permitira
justiIicar mas Iacilmente la eleccion.

Cual es el problema:
Esta vinculado a la politica del departamento/servicio?
Es un problema importante?
Es un problema esporadico o es cronico?
Es visible o es latente?

Estas cosas deben ser clarificadas !

Mostrar las condiciones del problema

Es necesario conocer el problema con precision. Para esto es necesario reunir tantos datos como sea
posible y tratar de presentarlos en Iorma de graIicos de Pareto (por ejemplo utilizando los 7 utiles QC ).

Utilizar los datos recogidos.
Los datos recogidos deben permitir justificar la eleccin del problema, posicionandolo con
respecto a la lista existente del sector o del taller.

2. Puntos claves
1. Reunir tantos datos como sea posible
2. Basarse en los hechos
3. ClasiIicarlos por orden de prioridad
4. Generalmente utilizar los diagramas de Pareto par explicar las razones de la eleccion, pero de
Iorma general es necesario tratar de mostrar el inters del tema a travs de elementos visuales
(graIicos diagramas ....).
Etapa 2 : Explicar las razones de la eleccin
18



Esta etapa es esencial en el conjunto del QC Story y es determinante en el resultado Iinal.
En particular la etapa de analisis (etapa 5) depende de la calidad de la etapa 3.

1. Observacin

Hacer una observacion precisa del problema.
Siempre que sea posible, ver nosotros mismos directamente el problema en el lugar donde aparece ( en
el taller, en la maquina, en el aprovisionamiento de piezas......).
Tomar las notas que puedan resultar utiles para etapas siguientes.

2. Reunir los datos

Antes de reunir los datos, es muy importante discutir y decidir qu tipos de datos son necesarios y
utiles. Muchos Iracasos y retrasos en el QC Story ~~ provienen de esa Ialta de discusion previa.
Por datos ~~ se entiende datos numricos derivados, por ejemplo de sistemas inIormaticos
existentes, pero tambin los datos que puedan ser recogidos por personas implicadas en el problema.
Cuando se trate de personas, es necesario transIormar algunos datos subjetivos o emocionales en datos
Iactuales.

> ClariIicar el inters de reunir datos
Por qu recogemos los datos ?
Qu vamos a hacer con esos datos ?

> Recoger datos Iiables
Son Iiables los equipos de medida?
El mtodo de medida es correcto?
La muestra es de un tamao suIiciente?
Los calculos son correctos?
Los datos son validos?
Es necesario hacer ensayos para reproducir el deIecto?
Hasta cuando debemos remontarnos en el tiempo (ciclos)?

> ClariIicar como reunir los datos
Quien recoge, cuando y como, ......

> Reunir los datos
Sobre el terreno.
Observando la operacion actual.
En el marco de la produccion real.

Etapa 3 : Comprender la situacin actual
19



3. Datos clasificados y graficados

Esta Iase debe permitir pasar de los datos a la informacin, para esto es necesario organizar ~~ los
datos, con el Iin de clariIicar lo que estos dicen.

* Separarles en grupos que tienen cosas en comun :
Por turno Por tipo de deIecto
Por operario Por linea, Iabrica, etc.
Por mtodo Por partes del vehiculo
Por instalacion Por modelo
Por material Por dia, hora, etc.

* Hacer un graIico
Hacer un graIico, pero utilizando solamente las inIormaciones necesarias o utiles.

4. Puntos claves

Sobre la recogida de datos:
1. Examinar sin prejuzgar y sin ideas preconcebidas
2. Ir a ver sobre el terreno nosotros mismos siempre que sea posible.
3. Comparar los buenos y los malos resultados para clariIicar las diIerencias.
4. La dispersion es una inIormacion util. La media no lo es todo

Sobre la clasiIicacion:
Una clasiIicacion correcta es importante en QC Story porque va a permitir precisar mejor la naturaleza
del problema y puede ayudar enormemente en la busqueda de causas (etapa de analisis).














Etapa 3 : Comprender la situacin actual
20



1. Qu es un objetivo?

Un objetivo, es un numero que indica el nivel de mejora que debe ser alcanzada. Esta determinada por
un compromiso entre lo ideal y las diIicultades como el tiempo, la mano de obra y los recursos
economicos que es posible invertir en el proyecto.
Para hacer esto, es mas Iacil Iijar los objetivos de mejora una vez que es bien conocida la situacion
existente en la etapa 3.
En el caso de un problema identiIicado, tratar al menos de retornar a una situacion normal ~~.
La deIinicion clara del objetivo permitira movilizar a las personas en torno a la resolucion del
problema.
Evitar deIinir objetivos vagos como deseariamos un descenso de las devoluciones de moneda a caja
~~ o bien deseariamos aumentar el nivel de calidad en el taller ~~.

2. Cmo expresar un objetivo?

Los objetivos deben responder a los 3 puntos siguientes :
1.- QU? (caracteristica de control)
Ejemplo: Numero de errores en la devolucion del cambio de moneda
2. PARA CUNDO? (limite de tiempo)
Ejemplo: para Noviembre
3. CUNTO? (valor del objetivo)
Ejemplo: Pasar de 5000 a 4500 euros / mes

Para responder a la pregunta << Qu? >> primero decidimos qu es lo queremos mejorar (qu
caracteristica entre las disponibles), conIirmaremos esto examinando el problema de cerca, y a
continuacion decidiremos lo que deberemos tomar como meta a la luz de los objetivos de mejora.

<< PARA CUANDO >> deIine la Iecha en que el problema debe estar terminado. Un problema esta
terminado cuando hemos aplicado las medidas correctivas, hemos estandarizado los mtodos y estamos
seguros que los beneIicios son estables.

<< CUNTO >> signiIica un valor preciso para el grado de mejora a alcanzar por el proyecto.

3. Cmo fijar los valores de los objetivos?

Como los objetivos representan el resultado de nuestro trabajo de resolucion de problemas, deben ser
expresadas de manera concreta en trminos fciles de comprender.
Para ayudarnos, podemos utilizar el nivel existente de perIormance que hemos de recuperar de la etapa 3
Comprender la situacion actual ~~.



Etapa 4 : Elegir los objetivos
21



La eleccion de lo valores de los objetivos dependera tambin del grado de diIicultad del tema, de las
capacidades personales (o del grupo), y de las necesidades o metas del departamento o servicio.

No hay reglas Iijas para la decision de los valores de los objetivos, no obstante es habitual elegirlos
segun las consideraciones siguientes :
1. La cantidad que queremos reducir, en numero de deIectos o productos no conIormes.
2. Tomar como reIerencia las mejores practicas existentes por comparacion (internas o externas).
3. Eligiendo los valores que deberian imponerse logicamente.
4. Los valores que deberian alcanzarse de manera meticulosa de otras consideraciones (ejemplo:
los vinculados a la seguridad y la prevencion de la polucion).


4. Lgica de decisin de un objetivo


> Mtodo lgico

















Etapa 4 : Elegir las metas
Operacion
70
Parada
30
12
8
6
4
12
0 0 0
Acero Acero Paradas
Juzgar qu se
puede mejorar
Objetivo : ' reduccion de
paradas de 30 a 12
Prensa Modo operatorio
22


> Mtodo procedente de la necesidad.














5. Puntos claves

Las 6 condiciones que deben satisIacer una buena eleccion de las metas son las siguientes:

1. Producir beneficios superiores a los costos y a los esIuerzos necesarios para alcanzarlos.
2. Que sean suIicientemente importantes para crear motivacin.
3. Que sean alcanzables (para no desalentarse).
4. Poder verificar si han sido alcanzadas o no
5. Todos los participantes deben aceptarlas y creer en ellas.
6. Considerar con atencion su vnculo con la poltica general y de los departamentos..



Etapa 4 : Elegir las metas
OB1ETIVO DEL TALLER
100
90
80
70
85
90
85
75
Bloque
motor
Lados de
caja
Base
rulante
Objetivo : 'reduccion de la
perdida de lados de cajas
del 25 al 20
Disponibilidad Objetivo
anual
Bloque motor
Lados de caja
Base rodante
80
80
85
23
FASE << Do >> del PDCA


1. Importancia del anlisis

Una vez que las metas han sido decididas y que el planning de la actividad ha sido preparado (respuesta
a la pregunta para cuando ? ~~ de la etapa 4 ) la etapa siguiente es analizar las causas. Es la etapa
mas importante de esta gestion.

IdentiIicar de Iorma precisa las verdaderas causas del problema, nos va a decir que hacer en la etapa
siguiente: buscar y poner en marcha las medidas correctivas. Si no identiIicamos claramente las causas,
corremos el riesgo de perder el tiempo y dinero ensayando diversas soluciones ineficaces.
Analizar las causas signiIica buscar los factores principales que crean los problemas y que parecen
inIluenciar en los resultados del proceso.

En esta etapa, es necesario tender hacia una sistemtica << cientfica >> de la relacion entre la causa y
el eIecto.

Para esto debemos utilizar las herramientas a nuestra disposicion o aquellas que sepamos manejar ( hay
muchas herramientas de analisis, pero en el 90 de casos, los 7 utiles basicos de la calidad son
suIicientes).
Atencion, no son mas que mtodos para encontrar el maximo de causas posibles, no son analisis en si
mismos.
El objeto del analisis de causas es descubrir cuales son las medidas que deben tomarse contra esos
Iactores. Si las relaciones entre la causa y el eIecto no son correctamente identiIicadas en esta etapa,
acabaremos por decir cosas como hemos tomado medidas y nada se ha mejorado! ~~, o bien
no hemos obtenido ningun beneIicio! ~~.

La busqueda de causas posibles puede llevar tiempo. Buscar todas causas posibles es una utopia. Es
necesario encontrar un compromiso con el Iin de no bloquear el QC Story ~~.
La actividad del Brainstorning ~~ puede ser util en esta etapa para trabajos en grupo.


2. Buscar las causas << posibles >>

Empezar listando las diversas causas posibles.
Reunir y buscar un gran numero de opiniones.
Las causas deben ser escritas en los trminos de lo qu es malo en la situacin presente.
Por ejemplo, la Ialta de piezas ~~ o bien se pierde el tiempo en sacar el documento ~~
Seguidamente examinar las causas posibles, sobre la base del conocimiento y la experiencia tcnica, y
hacer resaltar las que tengan un efecto particularmente fuerte (eIecto revelado en la recogida de
datos ).
Etapa 5 : Analizar
24


3. Relacin entre datos y causas

En esta etapa, examinamos las causas posibles listadas anteriormente y utilizamos los datos para
encontrar cules son las verdaderas causas y qu eIectos generan. Aqui es importante no suponer
sino identiIicar correctamente los hechos.
Para hacer esto, debemos analizar los datos tales como:
Los datos pasados.
Los datos clasiIicados diariamente (regulares)
Los nuevos datos procedentes de investigaciones y ensayos sobre el terreno.
Para ayudarse, analizar los datos bajo los aspectos siguientes:
Examinar las diferencias entre los datos.
ClasiIicar los datos segun las 4M >> ( Maquina, Mano de obra, Materiales y Mtodos ), preparar los
graIicos, los histogramas, las hojas de control, etc. y mirar si hay diIerencias entre los diversos datos.
Examinar las variaciones en el tiempo.
Utilizar los graIicos, las hojas de auditoria, las cartas de control,... para ver si las caracteristicas cambian
o no en el tiempo.
Buscar la correlacin entre pares de datos.
Es decir entre causas y caracteristicas, causas y causas, y entre caracteristicas y caracteristicas.
Buscar en el taller y las instalaciones.
Observar atentamente el terreno, las personas y las piezas. Si las quejas aparecen a proposito de los
productos o las piezas no conIormes, podemos utilizar incluso instrumentos, tales como microscopios
electronicos si Iuera necesario.

4. Decidir las causas profundas

En la identiIicacion de las causas, es importante veriIicar si las causas identiIicadas (probables) son de
hecho las verdaderas causas profundas.
Para esto, es util hacerse varias veces la pregunta por qu ? >> para cada identiIicacion de una
causa posible.
En algun caso, hemos visto causas directamente tratadas como medidas correctivas sin haber
comprobado si eran en eIecto las verdaderas causas del problema estudiado. Esta aproximacion tiene
riesgo, las causas listadas a priori consisten Irecuentemente en suposiciones aleatorias o ideas
preconcebidas y no representan posiblemente los verdaderos hechos.
La identiIicacion de las causas proIundas puede conducir a ensayos practicos sobre el terreno con el Iin
de testar cual es el impacto de las causas del problema estudiado, y esto causa a causa ( en la medida de
lo posible ). Es por esto que la etapa de analisis Iorma parte de la Iase DO ~~ de P(S) - D - C - A en
el QC Story Renault.

5. Puntos claves
1. Buscar las causas posibles no es el verdadero analisis, pero es la primera etapa del analisis.
2. Es necesario reunir el maximo de opiniones durante la busqueda de causas.
3. Si es posible realizar una experiencia o ensayo sobre el terreno es posible para elegir las causas,
tratar de conIirmar el grado de inIluencia.
4. Repetir por qu ? ~~ al menos 5 veces para la busqueda de causas proIundas.
5. Elegir las acciones correctivas y clasiIicarlas por orden de Iactibilidad, impacto en otros procesos,
seguridad, costo, eIecto, plazo, etc.
6. No buscar todas las causas posibles, lo importante queda en la accin.
Etapa 5 : Analizar
25


Esta etapa esta relacionada directamente con la etapa precedente: este vinculo debe ser visible sobre el
QC Story, por ejemplo, utilizando numeros entre las causas identiIicadas y las acciones aplicadas.

1. Principios
Antes de aplicar las acciones correctivas, estas deben ser aprobadas por la jerarqua.
A continuacion, ensayar y comprobar los efectos sobre procesos o los otros Iactores, si son buenos,
entonces ponerlas en marcha.
Es necesario especialmente veriIicar que la medida tomada no crea otro deIecto en otra parte.
A veces puede parecer lento poner en marcha las acciones una a una y comprobar su impacto. Pero no se
puede permitir invertir costes de puesta en marcha en acciones que no se haya demostrado su eIicacia.

2. Puntos claves
1. Antes de poner en marcha, decidir el planning y el rol de cada miembro.
2. No molestar a los operarios y prestar atencin a los riesgos de calidad. El periodo de parada entre
turnos de dia y de noche o tambin las vacaciones son apropiadas para las modiIicaciones.
3. Dar prioridad a cada accion correctiva y mantenerla.
4. Implicar a los operarios.
Si les implicamos el 90 de las acciones correctivas despus de un 1 ao seguiran
implantadas.
Si no, solamente el 20 .
5. Cambiar las cosas ~~ no solamente el modo operatorio (que se pueda ver el cambio)
6. Obtener el acuerdo no solamente de personas del sector, tambin de otros departamentos y servicios.
7. Hacer las cosas por nosotros mismos, la dinamica sera mas concreta.
8. Mas de la mitad de acciones correctivas necesitaran de modiIicaciones: ensayos y verificaciones son
muy importantes para la puesta en marcha las acciones correctivas.
9. ConIirmar los eIectos, utilizando el mismo mtodo y el mismo observador.
10. A veces no podemos poner en marcha acciones correctivas sobre todas las causas y el ciclo PDCA no
es completo. Esto no es mas que parte de una dinamica de progreso continuo.
11. Con el Iin de que el entorno nos tenga en cuenta, es eIicaz utilizar colores, limites, graIicos,
indicaciones, en el entorno donde se ha aplicado la medida correctiva.
12. Mostrar los resultados a todos los interesados

3. El retorno de informacin
Esto es necesario principalmente cuando es util incluir otros sectores en la dinamica de resolucion de
problemas.

Los puntos claves del retorno de inIormacion:
1. Encontrarse con los interlocutores cara a cara, no por telIono.
2. Proponer nosotros mismos las acciones correctivas.
3. Explicar con datos, graIicos, dibujos o imagenes.
4. Encontrarse con los responsables de equipos y personas concernidas.
5. Decir qu ~~, para cuando ~~ y redactar un acta si Iuera necesario.
Etapa 6 : Poner en marcha las medidas correctivas
26
FASE << CHECK >> del PDCA



Comparar con las condiciones iniciales (etapa 3) con la ayuda de datos (graIicos).
Si los eIectos pueden ser convertidos en ganancia (euros) es preIerible.
Los eIectos deben ser explicados sobre el aspecto efecto directo, pero tambin bajo el aspecto
efectos indirectos (repercusiones) o eIectos no materiales.
Es necesario mostrar la situacin antes y despus de la accion correctiva y utilizar los mismos
graIicos que en la etapa 4.
En la medida de lo posible, es necesario mostrar el efecto de cada accin sobre el resultado Iinal
(marcar con numeros ).





























Etapa 7 : Confirmar los efectos
ANTES DESPUES
Medidas correctivas
A B C D E F A B C D E F
EIecto
EIecto
27
FASE << AC1IOA >> del PDCA




1. Principios

La accion correctiva debe ser estandarizada para evitar que los errores aparezcan de nuevo, es necesario
entonces:

1. Revisar o establecer el << estndar >> de trabajo.
2. Si el problema proviene del modo operatorio, formar a los operarios en el nuevo estandar.
3. Revisar el tiempo ciclo, los stocks estandar, las condiciones estandar de la maquina etc.
4. Si es posible, extender las acciones correctivas a otras piezas, procesos u operaciones
similares.

2. Puntos claves

1. Los tiles visuales son muy eIicaces para la estandarizacion.
2. VeriIicar el nivel de calidad y que los operarios Iuncionan con el nuevo mtodo durante al
menos de 2 semanas.

En eIecto, sucede Irecuentemente volver de manera natural al mtodo anterior en las dos semanas
siguientes al cambio.

















Etapa 8 : Estandarizar
28



Despus que el objetivo ha sido la alcanzado, el progreso y los resultados son comunicados a la
jerarqua.

Pero puede haber aspectos bajo el QC Story ~~ que no han podido ser aplicados, o bien causas que
no se han podido resolver actualmente. Esta etapa permite anotarlo para el Iuturo.

Como hemos indicado en la introduccion, el mtodo es tan importante como el resultado, y puede
tambin ser mejorado. Es necesario entonces anotar las observaciones para la proxima vez.

Para cerrar el ciclo P(S)DCA, cada usuario debe terminar su gestion de QC Story ~~ haciendo un
balance de la manera en que lo ha practicado.
Este balance debe llevar a una reIlexion sobre las competencias necesarias para la realizacion de un
QC Story ~~ cada vez mejor, en particular en lo que concierne a los utiles de analisis. Es el rol del
manager ayudar a los practicantes del QC Story a poner en evidencia los puntos a mejorar.




















Etapa 9 : Sintetizar y planificar las acciones futuras
29

Entre todos los aspectos de << QC Story >> los principios siguientes son los fundamentales :

QC Story ~~ es una manera de pensar los problemas, no un mtodo, ni una herramienta.
QC Story ~~ es utilizable para todas las actividades, donde se necesite resolver un
problema o mejorar alguna cosa existente.
Es necesario practicar ms y ms a Iin de probar su eIicacia.
Esta actividad no tiene un Iin, es progreso continuo.

El dominio y utilizacin regular de QC Story por el management es una garantia de estabilidad, y
tambin un medio muy eIicaz de gestionar los ciclo P(S)DCA en las actividades cotidianas.
Es tambin un paso previo a la utilizacion de utiles de management mas complicados y orientados a
sistemas complejos (diagrama matricial, diagrama de aIinidades, ... ).
































Captulo 4: CONCLUSIONES