Una Buena Descripción del Problema es Clave

Puedes causar problemas si no se empieza bien

por George R. Raub III

s Jueves, 9 de la mañana, y el personal esta en la oficina del gerente para una reunión de
emergencia. El director de la planta acaba de recibir una llamada del área de ventas. Su
cliente más importante divulga un problema muy serio en como caben sus partes--placas
automotoras del ajuste del tablero de instrumentos--y pueda tener que parar la
producción. El director de la planta dice "Tenemos un problema en la producción o la
calidad y necesito que se resuelva ahora mismo. Nuestro cliente más grande puede parar
la producción."

El departamento de la garantía de calidad (QA) divulga que los funcionamientos del

turno de día son mejores y la tarifa de rechazo del turno de media noche es muy alta. El
área de producción esta preocupado de que existen muchas normas diferentes de calidad.
"¿Sabemos cualquier cosa mas sobre el problema?" pide el encargado de QA. "Enviamos
12 versiones del producto." Desgraciadamente, todo lo que se sabe es de que el cliente
reporta un problema muy serio de cabida pobre.

"No deberíamos tener problemas. No hay rechazos para cabida pobre," dice el encargado
de QA. "Voy a instalar hojas con macas para ver como cabe cada puerta. Tendré
resultados de medidas corta de capacidad del funcionamiento para mañana."

"El problema esta con nuestros nuevos empleados" dice alguno de recursos humanos.
"Los contratamos sin el entrenamiento cuando la rampa-para arriba empezó."

El director de la planta concuerda y el departamento de QA decide reinspeccionar todos

los artículos en inventario, poner etiquetas engomadas verdes en las piezas que pasen la
inspección y notifica al cliente. "El QA se cerciorara de que no enviemos mas piezas
malas," dice el director de la planta.

Problema resuelto

Después de la reunión, el equipo acuerda que la causa raíz del problema era
entrenamiento pobre. Así es de que los empleados graban en video las operaciones del
personal de turno de día y entrenan a los empleados del turno de media noche
enseñándoles los videos. A la mañana siguiente, todos construían el producto como el
turno de día.

El QA reinspecciono todo el material en inventario y encontró solamente piezas que se

conformaban a las características aptas. Durante el proceso de reinspección, 50 de 2,000
piezas fueron extraídas y desechadas. Al cliente se le dijo que todo el material fue
reinspeccionado, marcado con puntos verdes y enviado y que todos los empleados fueron
entrenados de nuevo.
El problema fue solucionado. La planta reacciona rápidamente e hizo un gran trabajo.
Varios días después, el cliente ordena un paro a sus envíos porque las piezas
reinspeccionadas eran tan malas como las piezas anteriores.

¿Cual es el problema?

En su preocupación por la satisfacción del cliente, la compañía corrigió cosas antes de

describir el problema. Nadie sabía cual era el problema. Sin primero describir por
completo el problema, la compañía no tenia nada para probar y llegar a las potenciales
causas raíz. Permitió que el proceso de acción correctiva fuera la plataforma para
prejuicios personales. ¿Cómo es posible implementar acciones correctivas sin saber el
problema?

La descripción del problema

Una buena descripción del problema es la clave para el proceso de acción correctiva
descrito por Kepner-Tregoe.1 Equipos de acción preventiva utilizan la descripción inicial
del problema como su punto de partida pero los informes iniciales son a menudo
irregulares e incompletos. El equipo debe investigar la descripción inicial, y la mejor
fuente de clarificación es la persona que divulgo el caso. Haga a esa persona las
preguntas siguientes:

• ¿Quién vio el problema primero?

• ¿Cuál es la definición del problema en términos del cliente?
• ¿Cuál es la definición del problema en nuestros (la compañía) términos?
• ¿Desde que el problema fue divulgado, ha aumentado, disminuido, sigue
constante o se repite?
• ¿Cuándo (hora del día) se ha visto el problema?
• ¿Cuándo en el proceso (en que paso o estación) ocurre el problema?
• ¿Dónde en la pieza se ve al problema?
• ¿Cuantas piezas se divulgan implicadas? ¿Se puede el problema expresar en
porcentajes, dólares o piezas?

Esta lista puede ayudar a cualquier persona que recibe quejas iniciales para hacer las
preguntas correctas durante el contacto inicial. Es también bueno anotar el nombre del
contacto, la posición y número de teléfono.

Una descripción bien indicada del problema apresura un proceso robusto de la acción
correctiva. Ayuda a identificar potenciales causas raíz y elimina prejuicios y ruido.
Descripción correcta del problema ahorra tiempo y esfuerzo haciendo que el equipo se
concentre en identificación de causas raíz. Usando herramientas tales como diagrama de
pez (fishbone), el equipo puede probar causas raíz potenciales contra el problema
declarado. La causa raíz verificada debe constar todos los que y donde en la declaración
del problema.
Una forma que usted puede mejorar el proceso de la descripción del problema es
proporcionando el entrenamiento especializado a sus empleados que lidian con clientes
de prioridad. Mejoramiento continuo ocurre cuando se encuentran y se eliminan
permanentemente las causas raíz. La descripción del problema es el primer paso en este
proceso.

REFERENCIA

1. Charles H. Kepner y Benjamin B. Tregoe, The Rational Manager (New York:

McGraw-Hill, 1965).

BIBLIOGRAFIA

Chesla, Erik, Successful Teamwork (New York: Learning Express, 2000)

Feller, Gary, The Deming Vision (Milwaukee: ASQ Quality Press, 1992)

Nadler, Geral, Breakthrough Thinking (Rocklin, CA: Prima Publishing &

Communications, 1990).

Stryker, Perrin, "Can You Analyze This Problem?" Harvard Business Review, May/June
1965.

GEORGE R. RAUB III es director de mejoramiento continuo para Irvin Automotive

Products en Auburn Hills, MI. Obtuvo un bachillerato en quimica de la universidad
Eastern Michigan y escribió Building Problem Solving Teams Using Case Studies, cual
fue presentado en la conferencia de calidad de la Engineering Society de Detroit. Es
miembro Senior de ASQ y esta certificado como gerente e ingeniero de calidad.
 ¿Existe una Relación Aquí?

Un diagrama de dispersión puede ayudar a determinar

si existe una correlación entre dos variables

por la Quality Management Division de ASQ

Un diagrama de dispersión es una grafica en la cual una variable se traza contra otra para
determinar si existe alguna correlación entre las dos. Estos diagramas se utilizan para
trazar la distribución de la información en dos dimensiones y son útiles para calcular
rápidamente una relación entre dos variables.

Un diagrama de dispersión demuestra el patrón de la relación entre dos variables que se

piensa son relacionadas. Por ejemplo, ¿existe o no una relación entre el clima exterior y
los casos del frío común? A como la temperatura cae, ¿aumentan los casos de frío?
Cuanto más abrazan los puntos una línea diagonal, lo mas seguro es de que existe una
relación de uno a uno.

El propósito del diagrama de dispersión es de exhibir que sucede a una variable cuando
otra variable es cambiada. La cuesta del diagrama indica el tipo de relación que exista.

Figura 1 demuestra el diagrama de dos variables--valores predichos contra valores

observados. A como aumenta el valor predicho, el valor medido también lo hace. Estas
variables se dicen ser correlacionadas positivamente; es decir, si una aumenta, la otra
también. La línea trazada es una línea de regresión que demuestra la relación linear media
entre las variables.

Si la línea en un diagrama de dispersión tiene una cuesta negativa, las variables se

correlacionan negativamente; es decir, cuando una aumenta la otra disminuye, y
viceversa. Cuando ninguna línea de regresión puede ser trazada y el diagrama de
dispersión aparece ser simplemente una bola de puntos difusos entonces se dice que los
variables no tienen correlación.

La utilidad del diagrama de dispersión para evaluación de calidad yace en su medida de

variables en un proceso para ver si cualesquiera dos o más variables son correlacionados
o sin correlación. La utilidad especifica de encontrar correlaciones es de deducir
relaciones casuales entre variables y encontrar en ultima estancia las causas de la raíz de
problemas.

Los pasos básicos implicados en construir un diagrama de dispersión son los siguientes:

1. Defina la variable de x en la forma de diagrama de dispersión en papel grafico.

Esta variable es considerada a menudo como la causa variable y se traza
típicamente en el eje horizontal.
 2. Defina la variable de y en el diagrama. Esta variable generalmente es considerada
como el componente de efecto y se traza típicamente en el eje vertical.
3. Numere los pares de medidas variables de x y de y consecutivamente. Registre
cada par de las medidas para x e y en las columnas apropiadas. Asegúrese que la
medida x y la medida y correspondiente se mantengan apareadas para que los
datos sean exactos.
4. Trace los pares de los datos x e y en el diagrama. Localice el valor de x en el eje
horizontal; entonces localice el valor de y en el eje vertical. Ponga un punto en la
grafica donde los dos intersecan.
5. Estudie la figura formada por la serie de puntos de referencia trazados. En
general, las conclusiones se pueden hacer sobre la asociación entre las dos
variables (x e y) basados en el diseño del diagrama de dispersión. Diagramas de
dispersión que exhiben asociaciones entre dos variables tienden a ser como
esferas elípticas o hasta como líneas rectas.
6. Diagramas de dispersión donde los puntos trazados aparecen en forma circular
demuestran poca o nada de correlación entre la x e y.
7. Diagramas de dispersión en los cuales los puntos forman un patrón de valores
ascendientes para ambas variables demuestran una correlación positiva; así como
los valores de x aumentan, así igual los valores de y. Cuanto más firmemente se
arraciman los puntos en una manera linear, más fuerte es la correlación positiva, o
la asociación entre los dos variables.
8. Diagramas de dispersión en los cuales una variable aumenta de valor mientras la
segunda variable disminuye de valor demuestran una correlación negativa entre x
e y. De nuevo, cuanto más firmemente se arraciman los puntos en una manera
linear, más fuerte es la asociación entre las dos variables.

Si parece que existe una correlación entre dos variables, se dice que son correlacionados.
Las correlaciones positivas y negativas son útiles para la mejora continua de procesos.

Los diagramas de dispersión demuestran solamente que existe una relación, no que una
variable causa la otra. Análisis adicional usando técnicas estadísticas avanzadas pueden
cuantificar que tan fuerte es la relación entre las dos variables.

Nota: Esta columna es adaptada de The Quality Improvement Handbook por la Quality
Management División y editado por John E. Bauer, Grace L. Duffy y Russell T. Westcott
(Milwaukee: ASQ Quality Press, 2002).
Los Beneficios de PDCA

Utilice este ciclo para mejoramiento continuo de procesos

por Corinne N. Johnson, asistente editorial

El ciclo planear-hacer-revisar-actuar (plan-do-check-act "PDCA") es un modelo muy

bien conocido para mejoramiento continuo de procesos (continuous process improvement
"CPI").1 Enseña a organizaciones a planear una acción, hacerla, revisarla para ver como
se conforma al plan y actuar en lo que se ha aprendido.2

El ciclo PDCA se compone de cuatro pasos para mejoramiento o cambio (ver Figura 1):3

1. Planear: Reconozca una oportunidad y planee el cambio.

2. Hacer: Pruebe el cambio.

3. Revisar: Revise la prueba, analice los resultados e identifique lo aprendido.

4. Actuar: Tome acción basada en lo que aprendió en el paso revisar. Si el cambio fue
exitoso, incorpore lo aprendido en la prueba a áreas de cambio más amplias. Si no, siga
los pasos de nuevo con un plan diferente.

Una historia breve

El ciclo PDCA también se le conoce por otros nombres, el ciclo Shewhart y el ciclo
Deming.

Walter A. Shewhart fue el primero que habló de el concepto de PDCA en su libro de

1939, Statistical Method From the Viewpoint of Quality Control. Shewhart dijo que el
ciclo atrae su estructura de la noción de que una evaluación constante de practicas
empresariales, así como la disponibilidad de los empresarios de adoptar e ignorar ideas
sin apoyo, son clave para la evolución de un proyecto con éxito.4

W. Edwards Deming fue el primero que dio a conocer el termino "ciclo Shewhart" para
PDCA, llamándolo por el nombre de su mentor y maestro en Bell Laboratories en Nueva
York. Deming promovió PDCA como el principal método de conseguir CPI.5 También se
refirió al ciclo PDCA como el ciclo PDSA (donde la 'S' significa Estudio/Study).

Deming es acreditado como quien incitó a los Japoneses en los años de 1950s que
adoptaran PDCA. Los Japoneses con entusiasmo abrazaron PDCA y otros conceptos de
calidad, y para darle honor a Deming por su instrucción, se refieren al ciclo PDCA como
el ciclo Deming.

Ejemplo de una multa por

estacionarse indebidamente
Aquí esta un ejemplo del PDCA en acción:

Planear

• Identifique el problema. Una multa por estacionarme indebidamente se me envió

por error. Mi nombre esta en la multa, pero la licencia y registro le pertenecen a
alguien mas que tiene mi apellido. La oficina de correos me envía su correo
asumiendo que somos parientes porque tenemos el mismo apellido.

• Analice el problema. ¿Cómo ocurrió el error? La oficina de correos me envió el

correo de alguien mas. ¿Que efecto puede tener? Si la multa no se paga, puede
prevenir el que yo pueda comprar y registrar un carro en el futuro.

Hacer

• Desarrolle soluciones. ¿Debo de ignorar la multa y romperla? ¿Debo de llamar al

teléfono que aparece en la multa de la oficina encargada de violaciones de
estacionamiento y explicar mi situación? ¿Debo de llamar a un amigo o un
familiar quien es oficial de policía o abogado y dejar que esta persona resuelva
todo?

• Implemente la solución. Decidí llamar por teléfono a la oficina de violaciones y

hacer cualquier otra llamada necesaria basadas en información que se me dio para
resolver el error.

Revisar

• Evalúe los resultados. El llamar a la oficina de violaciones no ayudo. Tampoco

ayudo el ir a agencias de gobierno locales y explicar el error.

• ¿Fue alcanzada la meta deseada? (Si así fue, continúe al paso siguiente. Si no fue
así, regrese al principio y empiece de nuevo.) No, la meta deseada no se alcanzó;
el error con la multa no se a corregido. Entonces regresé al principio y repasé la
información. Encontré el teléfono de la oficina de violaciones y lo llamé. La
persona con quien hablé me dio instrucciones de cómo proseguir paso a paso para
borrar mi nombre de la multa.

Actuar

• Estandarice la solución. Si el problema vuelve a ocurrir, me pondré en contacto

directamente con la oficina estatal. Para prevenir ocurrencias futuras, le diré a la
oficina de correos que el correo de la persona equivocada se esta enviando a mi
dirección y pediré que le pongan alto.

REFERENCIAS
1. Nancy Tague, The Quality Toolbox (Milwaukee: ASQ Quality Press, 1995).

2. ASQ y la Holmes Corp., ASQ's Foundations in Quality Self-Directed Learning

Program (Milwaukee: ASQ Quality Press, 1999).

3. Nancy Tague, The Quality Toolbox, see reference 1.

4. "Walter Shewhart: The Godfather of Total Quality Management,"

www.pathmaker.com/resources/leaders/shewart.asp.

5. ASQ y la Holmes Corp., ASQ's Foundations in Quality Self-Directed Learning

Program, ver referencia 2.
¿Que es un Análisis Árbol de Falla?

Use una conclusión general para determinar causas especificas de una falla del sistema

por Simha Pilot

El análisis Árbol de Falla (FTA Fault Tree Analysis) fue introducido por primera vez por
Bell Laboratories y es uno de los métodos mas ampliamente usados en sistemas de
relatividad, mantenimiento y análisis de seguridad. Es un proceso deducible utilizado
para determinar las varias combinaciones de fallas de equipo electrónico (hardware),
programas de computación (software) y errores humanos que pueden causar eventos
indeseables (referidos como eventos altos) al nivel del sistema.

El análisis deducible empieza con una conclusión general, luego intenta determinar las
causas especificas de la conclusión construyendo un diagrama lógico llamado un árbol de
falla. Esto también es llamado tomar una propuesta de arriba-a-abajo.

El motivo principal del análisis árbol de falla es el ayudar a identificar causas potenciales
de falla de sistemas antes de que las fallas ocurran. También puede ser utilizado para
evaluar la probabilidad del evento mas alto utilizando métodos analíticos o estadísticos.
Estos cálculos envuelven sistemas de relatividad cuantitativos e información de
mantenimiento tal como probabilidad de falla, tarifa de falla, y tarifa de reparación.
Después de terminar un FTA, puede enfocar sus esfuerzos en mejorar el sistema de
seguridad y relatividad.

Diagrama lógico de FTA

Los símbolos básicos usados en un diagrama lógico de FTA

son llamados puertas lógicas y son similares a los símbolos
usados por diseñadores de circuitos electrónicos. Dos tipos de
puerta, el 'y' y el 'o' son descritos en la Tabla 1.

El diagrama lógico parcial de FTA en la Figura 1 utiliza las

puertas 'y' y la 'o' para analizar riesgos al cliente. Entradas a
la puerta 'o' en lo alto identifican las cuatro razones por la cual esta falla
puede ocurrir. Una de estas razones, choque eléctrico, entonces se analiza
porque resulta simultáneamente de corriente contacto de tierra al paciente y
de crear un camino a la fuerte de corriente eléctrica (una puerta 'y'). El
análisis continua, utilizando las mismas técnicas, hasta que el nivel mas bajo como error
del operador o contacto de tierra abierto es identificado.

Cuando haga un FTA, sistemáticamente determine que le pasa al sistema cuando el status
de una parte u otro factor cambia. En algunas aplicaciones, el criterio mínimo para éxito
es de que no falla individual puede causar daño o una perdida de control no detectada en
el proceso. En otros, donde riesgos extremos existen o cuando productos de alto valor son
procesados, el criterio puede ser incrementado para requerir tolerancia de fallas múltiples.
Construcción del Árbol de Falla

1. Defina la condición de falla y escriba la falla mas alta.

2. Utilizando información técnica y juicios profesionales, determine las posibles razones

por la que la falla ocurrió. Recuerde, estos son elementos de nivel segundo porque se
encuentran debajo del nivel mas alto en el árbol.

3. Continué detallando cada elemento con puertas adicionales a niveles mas bajos.
Considere la relación entre los elementos para ayudarle a decidir si utiliza una puerta 'y' o
una 'o' lógica.

4. Finalice y repase el diagrama completo. La cadena solo puede terminar en un fallo

básico: humano, equipo electrónico (hardware) o programa de computación (software).

5. Si es posible, evalué la probabilidad de cada ocurrencia o cada elemento de nivel bajo

y calcule la probabilidad estadística desde abajo para arriba.

BIBLIOGRAFIA

Anderson, R.T., Reliability Design Handbook (Chicago: IIT Research Institute, 1976).

Evans, James R., y William M. Lindsay, The Management and Control of Quality
(Mason, OH: South-Western Thomson Learning, 2001).

Juran, Joseph M., y Frank M. Gryna, Quality Planning and Analysis (New York:
McGraw-Hill, 1991).

Michalsky, Walter J., Top Tools for Manufacturers (Portland, OR: Productivity Press,
1998).

SIMHA PILOT es un director general en SPC Consultants en Israel. Recibió un titulo

de maestría en administración de empresas de la Universidad Tel-Avi. Pilot es miembro
de ASQ y esta certificado como gerente en calidad y auditor de sistemas de calidad.
Es Divertido Trabajar Con un A-F-E (FMEA)

Prevenga defectos, realce seguridad y aumente satisfacción del cliente

por Kristen Johnson, editor asistente

Un Análisis de Falla y Efecto (FMEA--Failure Mode and Effect Analysis) es un grupo

sistémico de actividades con la intención de reconocer y evaluar la falla potencial de un
producto o proceso, identifica acciones que pueden eliminar o reducir la potencial falla y
documentar el proceso entero.1 FMEA ayudan a fabricantes a prevenir defectos, realza
seguridad e incrementa satisfacción del cliente. Muchos son conducidos durante la etapa
de diseñó o desarrollo, pero conducir un FMEA en un producto y proceso existente es
también beneficiario.2

El objetivo principal

Un FMEA busca todas las maneras en que un proceso o producto puede fallar. Por
ejemplo, un tostador de pan puede fallar en diferentes maneras.

• Un corto en el cordón eléctrico.

• Los alambres queman el pan sin importar a que temperatura se le programe.
• El mecanismo de extracción es muy sensitivo y lanza el pan tostado fuera y sobre
el mostrador.

Fallas también pueden ocurrir cuando el usuario comete un error, y es sensato incluir los
dos tipos de falla en un FMEA. Todo lo que se pueda hacer para asegurarse que el
producto funciona correctamente, sin importar como el usuario lo utilice, moverá al
producto mas cerca del 100% de satisfacción.3

Un producto/diseño de FMEA puede descubrir problemas que resultan en peligro para la

seguridad, mal función del producto o disminución de la vida del producto. La pregunta
clave a hacer aquí es, ¿cómo puede fallar el producto? El proceso FMEA descubre
problemas en el proceso relativos a la construcción del producto. La pregunta clave a
hacer aquí es, ¿cómo puede la falla del proceso afectar el producto, la eficiencia del
proceso o la seguridad?4

10 pasos para un FMEA efectivo

Todos los productos/diseños y procesos FMEA deben de seguir estos 10

pasos (ver tabla 1):5

1. Revise el proceso: Reúna a un equipo desde 4 hasta 6 (esté seguro de incluir personas
con varios tipos de responsabilidad y nivel de experiencia) y dé a cada miembro una
copia del plan del producto. También haga que el equipo opere el producto para que
todos los miembros se familiaricen con él y vean como funciona.
2. Realice una sesión de tormenta de ideas potenciales de falla: Observe cada
componente del producto e identifique maneras de como puede fallar.

3. Liste efectos potenciales de cada modelo de falla: Liste los efectos potenciales de
cada falla enseguida de la falla. Si una falla tiene mas de un efecto, escriba cada uno
aparte en cada línea.

4. Asigne un valor de severidad a cada efecto: De a cada efecto su valor de severidad

(de 1 a 10, siendo 10 el mas severo). Si el equipo no puede acordar en un valor, pónganlo
a votación.

5. Asigne un valor de ocurrencia por cada falla: colecte datos en las fallas del producto
de sus competidores. Utilizando esta información, determine la posibilidad de que una
falla ocurra y asigne un valor apropiado (desde 1 a 10, siendo 10 el mas posible).

6. Asigne un valor de detección a cada falla y efecto: Liste todos los controles
actualmente en su lugar para prevenir cada efecto de que ocurra una falla y asigne un
valor de detección a cada articulo (desde 1 a 10, siendo 10 el menos posible de
detección).

7. Calcule el numero riesgo de prioridad (NRP) para cada efecto: Multiplique el valor
severo por el valor de ocurrencia por el valor de detección.

8. Ponga las fallas en orden de prioridad para la acción: Decida en que artículos
trabajar de inmediato. Por ejemplo, si termina con números de 50 hasta 500, quizá
prefiera comenzar a trabajar con aquellos con un total de 200 o más.

9. Tome acción para eliminar o reducir las falla con riesgo alto: Determine que acción
tomar con cada falla con riesgo alto y asigne una persona para implementar la acción.

10. Calcule el NRP que resulte cuando las fallas se reduzcan o se eliminen: Reúna al
equipo después de haber terminado la acción correctiva inicial y calcule un nuevo NRP
para cada falla. Entonces puede decidir si ya tomaron acción suficiente o si quieren
trabajar en otro grupo de fallas.

REFERENCIAS

1. Chrysler, Ford y General Motors, Quality System Requirements, QS-9000, terser

edition (Southfield, MI: AIAG, 1998).

2. Robin E. McDermott, Raymond J. Mikulak y Michael R. Beauregard, The Basics of

FMEA (New York: Quality Resources, 1996).

3. Ibid

4. Ibid.
5. Ibid.