Definir Medir Analizar Mejorar Control DEFINIR Un problema

Definir Medir Analizar Mejorar Control DEFINIR Un problema bien definido. . . 1

Seis Sigma Frontal una opción en DMAIC Definir Medir Análisis Mejora Identificación de problema Definir problema desempeño (Y) si -Desviación de Y claramente definida -Causas asignables conocidas e identificadas ¿Relacione s Y(x)? no si no Accion de mejora dirigida ¿Se cumplen las 4 condiciones siguientes? 1. Ocurrencia de Y conocida 2. Relaciones definidas x, Y 3. Sin interacciones entre xs o con interacciones conocidas entre xs 4. Especialista de proceso si Confirmación experimenrta l ¿La causa raiz fue verificada? no si Estrategia de Mejora no Estrategia de Medición Control 2

Cartografía Definir Medir Analizar Mejorar Control Revisión de proyecto Inicio del proyecto Definir “CTQ” n n Declarar el Problema n Asignar líder del proyecto n Y claramente definida y observable Planear el proyecto n. Recursos – Líder – MBB, BB – Equipo -- Establecimiento de roles Límites de especificación mostrados n n Definir Problema Identidad, Ubicación, Tiempo y Magnitud Mal desempeño, Evento no deseado - ES / NO-ES - Árbol de Definición de Proyecto - Pareto n n Presentar las distribuciones; la requerida y la existente comprometidos Desarrollar plan del proyecto -- Planear Requerimientos -- Definir Actividades y tiempos n Establecer el Contrato n Gráficas de Gantt CAP Unidades de medición de la Y - causa efecto ( 5 por-qués) - Definición operacional CTQ - PEPSC - AMEF n 3

DEFINIR, Índice Objetivo: mostrar los pasos y herramientas utilizadas en la definición del proyecto – 1 a. declarar problema – 2 a. definir proyecto • ES NO ES (diagrama de árbol) • Diagrama de Pareto • Herramientas de Apoyo – – – causa efecto ( 5 porqués) hoja de verificación Diagrama de Nivel Alto (PEPSC) Diagramas Funcionales AMEF CAP 4

Problema proyecto • Los Gerentes señalan los problemas del negocio • Los Green / Black Belts realizan proyectos de cambio que atacan los problemas de negocio • Se debe convertir el problema de negocio en un proyecto de cambio claramente definido 5

Definir Medir Analizar Mejorar Control ES NO ES 6

ES NO ES • Objetivo: declarar la situación problema de una manera clara y concisa, que nos permita convertir la declaración del problema en un proyecto de cambio. • Descripción: responder preguntas lógicas sobre la situación problema – Identidad: qué es y qué no es, quién tiene y quién no lo tiene – Ubicación: dónde es y dónde no es, cómo es y no es – Tiempo: cuándo es y cuándo no es, desde cuándo es y desde cuándo no es – Magnitud: cuánto es y cuánto no es • Usos: la lógica de ES NO ES se usará en varias partes; en la definición del proyecto nos permitirá dar enfoque al proyecto. 7

Ejemplo: ES – NO ES Fuga de aceite en el filtro no. 1 unidad 1 Unidad 3 Unidad 2 Válvula de limpieza No en uso Al cargar aceite, inicio turno Fuga de 5 a 10 galones por turno unidad 4 Unidad 5 Tuberías, mecanismos No en el turno Menos de 5 galones Antes de hace 3 días Más de 10 galones Identidad: Unidad con falla ¿Qué falla? Ubicación: ¿Dónde se observa la falla? , geográficamente Dentro de unidad Tiempo: ¿Cuándo se observó la falla por primera vez? ¿Cuándo ha vuelto ha observarse desde entonces? Magnitud: Extensión de la falla No. de unidades afectadas ¿qué tan afectada está la unidad? 8

ES – NO ES GENERAR POSIBLES CAUSAS ¿QUE DISTINGUE A…? Fuga de aceite en el filtro no. 1 unidad 1 Unidad 2 Válvula de limpieza No en uso Al cargar aceite, inicio turno Fuga de 5 a 10 galones por turno Unidad 3 unidad 4 Unidad 5 Tuberías, mecanismos No en el turno Menos de 5 galones Filtro #1 empaque cuadrado, otros redondo Empaque de esquina cuadrada es nuevo, instalado hace 3 días en la revisión mensual de mantenimiento Válvula de limpieza se abre y se vuelve a apretar todos los días cada turno Antes de hace 3 días Más de 10 galones Mantenimiento mensual hace 3 días, aceite a presión sólo cuando se usa, al inicio de turno es cuando el aceite entra a presión Ubicación y nivel de vibración los mismos durante años Filtro #1 ha sido abierto, limpiado y cerrado durante años 9

Ejemplo de Declaración de Problema Ejemplo malo: Los clientes están enojados con nosotros y pagan tarde su cuenta. Ejemplo mejorado: En los últimos 6 meses (cuándo), 20% de nuestros clientes – clientes repitiendo, no de primera vez – están pagando tarde más allá de 60 días nuestras facturas (qué). La tasa actual de pagos tardíos subió de 10% en 1990 y representa el 30% de nuestras cuentas sobresalientes (magnitud). Esto afecta negativamente nuestro flujo de efectivo operativo (impacto o consecuencia). 10

Ejemplo de Declaración de Problema (Mejor) Los pagos tardíos están impactando el Flujo de Efectivo operativo Calidad Costo Clientes 1 a vez Entrega Confiabilidad Crecimiento Problema Prioridad de negocio afectada 30% de las cuentas sobresalientes Clientes que Repiten Pago de deudas (Clientes que Repiten) Requerida Existente 60 Fecha de pago – fecha acordada (días) DPMO iniciales: ~200, 000 Definición enfocada de Proyecto 11

Definir Medir Analizar Mejorar Control ÁRBOL DE DEFINICIÓN DEL PROYECTO 12

Árbol de Definición de Proyecto • Objetivo: El Proyecto se define a partir de una situación problemática que se presenta a nivel gerencial, generalmente una discrepancia entre un métrico del negocio y una meta establecida. • Descripción: Árbol que describe los cortes que eliminan temas y conceptos que no se tratarán en el proyecto y concentra la atención en los conceptos que son el fundamento del proyecto. El árbol se puede construir usando la lógica de ES NO ES. 13

Árbol de Definición de Proyecto • Se divide la situación problemática de acuerdo a cuatro enfoques posibles: – enfocar al área de más influencia de varias iguales, para después repetir la solución – enfocar eliminando las áreas sin influencia a la situación problemática – enfocar por conectividad entre mediciones, llevando al proyecto en donde se puede tener una medición equivalente – enfocar buscando progresivamente a través de la situación problemática eliminando las posibilidades no lógicas de causa. Utilizando el mecanismo de ES NO ES 14

Árbol de Definición de Problema Enfocado Situación Problemática Gerencial Partición Enfocar área por Mayor Influencia Enfocar separando áreas sin influencia Enfocar por Conectividad de Medida Enfocar por búsqueda progresiva Requerimiento Medible del Requerida. Cliente Existente LIE Capacidad LSE Figura. Árbol de Definición de Problema Enfocado 15

Árbol de Definición de Problema Lavadora vibra Modelos grandes Centrifugar Modelos pequeños Se observa en lavadoras de más de 9 kg Lavar Ciertas partes Todo el ciclo Cambio herramental Cambiar componente de amortiguamiento Vibración inaceptable en etapa de centrifugado Desde inicio hasta final vibra Cambio suspensión Resorte y pistón sobre amortiguan Problema de negocio Varillas y ligas Especificar K de resorte No es viable cambiar herramental Análisis de vibración indica sobre amortiguamiento de resorte Especificando una K de resorte apropiada se eliminará el problema de vibración después de paso en 16 frecuencia natural

Árbol de Definición del Problema Fallas de la turbina Rozamiento tensores Modos de Falla Defecto presente en el punto de embarque Falla de Balero Defecto requiere energía para mostrarse Tensor torcido Turbina Movida Distribución de Resistencia Energía Medir resistencia directa Otras fallas Medir cambio del claro en la punta Esta característica puede ser el parámetro de enfoque Problema no enfocado 80% de la falla es debido a rozamiento Weibull Beta > 2 Tensores torcidos encontrados antes del rozamiento La resistencia es más fácil de arreglar Conforme el tensor se debilita y tuerce, el claro en la punta disminuye Estos “cortes” ayudan a moverse de un estado de falta de enfoque a uno 17 con enfoque

Árbol de Definición del Problema “Reducir/eliminar fallas de turbocargador” no da mucho enfoque Una representación gráfica de una Y importante, hace fácil ver la magnitud del problema, el enfoque del equipo, la meta del equipo, etc. 1 La Variable a medir está claramente definida. Y es directamente enlazada al problema del cliente Tensor de turbocargador Requerido 3 Existente 0. 014 1 2 4 USL Cambio en la brecha de la punta (pulgadas) 2 Límites de especificación mostrados (incluir límites físicos) 3 Distribuciones requerida y existente mostradas 4 Se indican las unidades de medición Una imagen vale más que mil palabras. 18

Árbol de Definición de Problema Costos de Inventario demasiado altos Valle del Grano Comprar Todas Otros cinco sitios Hacer Ciertas partes Reducir precio Reducir cantidad La cantidad Cantidad presente “correcta” mayor que la necesaria Reducir demanda Reducir el tiempo de ciclo de reposición Problema de negocio V de G tiene 70% del valor de inventario Material comprado representa el 80% del valor del inventario El código 7 de bienes representa la más grande cantidad de valor de inventario (20%) La reducción de precio no es viable La variación actual en el nivel de inventario ocasionalmente (pero rara vez) se vuelve cero Reducir tiempos de ciclo de reposición permitirá un nivel de inventario más estable, reduciendo incertidumbre 19 por razones de negocio

Árbol de definición del problema “Costos de Inventario demasiado altos” no da mucho enfoque Una representación gráfica de una Y importante, hace fácil ver la magnitud del problema, el enfoque del equipo, la meta del equipo, etc. Código # 7 de Bienes Requerida 0 2 48 3 Existente 1 La Variable a medir está claramente definida. Y es directamente enlazada al problema del cliente 2 Límites de especificación mostrados (incluir límites físicos) 3 Distribuciones requerida y existente mostradas 360 Tiempo de ciclo Reposición (horas) (desde que la necesidad es creada hasta que la parte está en anaquel) 4 Se indican las unidades de medición 1 4 20

Definición de Proyecto Enfocado Varilla elevador 400 NBL Requerida 3. 900 LE inferior 3. 960 LE superior Longitud (pulgs) DPMO inicial: 168, 000 1 La Variable a medir está claramente definida. Y es directamente enlazada al problema del cliente 2 Límites de especificación mostrados (incluir límites Existente físicos) 3 Distribuciones requerida y existente mostradas 4 Se indican las unidades de medición 5 Objetivo centrado (a menos que se anote otra cosa) • DPMO inicial de 168, 000 calculado de reporte de desperdicio (GRR no validado) • ¿ es el GRR adecuado para la solución del problema? • ¿ Es el GRR adecuado para inspeccionar partes dentro de tolerancia 3. 900 - 3. 960? Este tipo de descripción gráfica de un problema se usa para proyectos donde la “Y” es continua. Otras situaciones pueden involucrar una Y “discreta” – cosas como si un programa fue compilado o no, o si una factura se procesó correctamente. Las “Y´s” 21 discretas no tienen un terreno medio - el resultado es bueno o malo.

De un Problema a un Proyecto: ¿Dónde enfocar? La facturación (throughput) está limitando las ventas Calidad Costo Entrega 400 NBL En Recibo En manuf. Longitud Incorrecta en Varilla elevador Confiabilidad Barrenos incorrectos en Varilla Impacto al negocio Área del Problema: Pareto de retraso por Modelo Otras líneas En Prueba Crecimiento En campo Defectos de pintura en producto terminado Punto de descubrimiento de problema Modos de Falla: 73% de todo el desperdicio/retrabajo es debido a longitud 22

Definición de CTQ y Elementos de CTQ Especificar CTQs • Los CTQs son la traducción de las necesidades del Cliente en Requerimientos cuantificados para nuestro producto o servicio • Los CTQs son los requerimientos críticos puestos sobre el producto o servicio Necesidad de Cliente Préstamos Rápidos Meta de Negocio Desempeño Seis Sigma CTQ Característica de Servicio /Producto Tiempo de Proceso de Préstamo Medir Tiempo de Solicitud de desembolso de fondos (Horas) Objetivo/ Valor Nominal 48 Horas Especificación / Límite(s) de Tolerancia 72 Horas Tasa tolerada de Defecto < 3. 4 DPMO 23

Especificar CTQs Definición de CTQ y Elementos de CTQ • Característica de Producto o Servicio: Una palabra o frase que describe algún aspecto del producto o servicio. • Medición: una definición de cómo la característica del producto o servicio va a ser cuantificada. Puede haber varias formas de cuantificar una característica dada. • Valor Objetivo o Nominal: A donde “apuntaremos” nuestro producto o servicio. Si no hubiera variación en el producto o servicio, este es el valor que siempre lograríamos. • Límites de Especificación: ¿Cuánta variación “tolerará” el cliente en la entrega del nuestro producto o servicio? • Tasa Permisible de Defectos: ¿Cuán a menudo estamos (los productores) queriendo producir un producto o servicio fuera de los límites de especificación? 24

Entender la necesidad del Cliente Quiero mi queja atendida rápidamente Identificar Característica(s) de Producto o Servicio Tiempo de procesar la queja ¿ Correlación con la necesidad ? No Si Nota: Algunos esfuerzos de diseño no distinguen entre características y mediciones Tiempo desde recibir la queja hasta comprobación recibida por el quejoso Determinar como medir la característica (Gage Ry. R) ¿Correlaciona a necesidad y Car. ? (Si) No Si Medida Continua (Continuo) Medida discreta Determinar Objetivo 3 Días (Basado en encuestas a clientes) Determinar Límite de Especificación o Tolerancia 5 Días (Especificación Superior) Determinar Tasa permisible de defecto (DPMO, SIGMA) Proceso General Para Determinar CTQs 6 s (<3. 4 DPMO) Determinar Objetivo DPMO/Sigma Resumen CTQ Característica Medida Objetivo LIE LSE DPMO Tiempo de procesar queja De recepción de queja a comprobación recibida (días) 3 días – 5 días 3. 4 25

Definir Medir Analizar Mejorar Control Operaciones estándar Las características pueden ser clasificadas en: calidad, precio y entrega El tiempo estándar nos permite ubicarnos en las características de entrega 26

una operación estándar es. . . · la mejor combinación de personas y recursos, balanceados según la demanda del cliente… • …utilizando el mínimo de personal, espacio, materiales y equipo • crear un método constante de flujo de trabajo para mejorar la calidad, el costo y la rapidez de entrega 27

operaciones estándar • ¿por qué implementar operaciones estándar? – para que sea posible identificar y eliminar las variaciones entre los asociados en el trabajo – establecer y clarificar los lineamientos del proceso – para sostener los logros obtenidos de actividades kaizen anteriores y establecer las bases para futuras actividades kaizen • ¿cómo se usan las operaciones estándar? – documente cada proceso estándar. – exhiba esa documentación. – asegúrese de que todos los asociados estén capacitados. 28

ejemplo de tiempo takt para 1 turno / día: tiempo takt = * los períodos de tiempo son iguales 29

formato de observación de tiempos Proceso: Elemento de la Paso Operación # 1 2 3 4 Observador: Fecha: 1 2 3 4 5 6 7 8 9 10 11 Levantarse de la Silla 08 53 38 23 13 54 42 29 17 7’ 02 51 8 7 9 6 7 7 8 8 9 Caminar al pizarrón Tomar marcador y quitarle el tapón Escribir en el pizarrón 18 1’ 04 48 34 23 4’ 06 53 40 27 13 8’ 01 10 11 10 12 11 11 10 20 06 51 37 25 09 55 43 Tiempos 29 16 2 2 3 30 15 2’ 01 48 34 M 5’ 05 53 10 9 10 11 9 10 51 37 3 3 5 33 18 05 Tapar marcador y Observación acomodarlo 3 Perdida 3 4 6 Volver a la silla 7 Sentarse Tiempo de 1 Ciclo 23 04 del 2 3 3 Elemento 38 27 15 10 9 11 11 09 56 41 31 18 4 3 3 43 27 14 3’ 01 46 32 19 6’ 06 52 40 28 10 9 9 10 10 11 9 10 46 30 16 04 48 35 42 31 3 3 2 3 2 3 46 44 46 48 44 – 22 09 Más baja 54 y 3 repetible 3 2 47 47 45 48 49 12 Tiempo Tarea Comentarios 7 10 3 9 2 44 Tiempo ciclo más bajo y repetible 30

tiempo de entrega vs. tiempo ciclo Tiempo de Entrega Tiempo Ciclo del Asociado Servicio A Clientes El tiempo ciclo es el que requiere una persona para completar un proceso determinado, incluyendo capturar, archivar, hablar por teléfono, clasificar, copiar, caminar, verificar, etc. 31

gráfica de barras de tiempo takt vs. tiempo ciclo # Operadores = S Tiempos Ciclo Tiempo Takt 60 Tiempo Takt = 50 seg. 50 Tiempo 40 30 S Tiempos Ciclo = 150 seg. 20 10 1 2 3 4 5 6 7 8 9 10 11 12 Operador # 32

aproximaciones del nivel de personal vea “nivelar” Tiempo 60 50 Tiempo Takt = 50 seg. 40 30 Demanda Flexible del Cliente 60 Tiempo Demanda Fija del Cliente 50 40 30 20 20 10 10 1 2 3 4 Asociados 5 6 Asociados 33

Definir Medir Analizar Mejorar Control DIAGRAMA DE PARETO 34

Diagrama de Pareto • Objetivo: ordenar por importancia de magnitud conceptos a estudiar • Descripción: Una Herramienta de Despliegue de Datos que separa las observaciones discretas en categorías con el propósito de identificar las “Pocas Vitales”. El reconocimiento de que la mayor aportación a la variabilidad de los problemas proviene de unas pocas causas, permite hacer una mejor asignación de los esfuerzos 35

Diagrama Pareto La gráfica de Pareto se basa en los principios desarrollados por el economista italiano Vilfredo Pareto – quien notó que la influencia de unos “pocos vitales” puede tener un mayor impacto. La regla 80/20 se ha demostrado cierta en muchas circunstancias. • Ejemplo 1: Frecuencia C A B D E Razón 36

Diagrama Pareto Ejemplo 2: abril 1 – junio 30 20 0 Número de Unidades Defectuosas 18 0 90 16 0 80 70 14 0 60 12 0 50 10 0 40 80 30 60 20 10 40 20 0 D B F A C E Otro 37 Porcentaje Acumulativo 100 Número de Unidades Investigadas: 5, 000

Ejemplo: Diagrama de Pareto En una línea de lavadoras se están revisando los defectos de la transmisión. El tipo de defecto asociado a cada transmisión rechazada se ha anotado y se tiene una tabla de frecuencias. Se usará un gráfica de Pareto para identificar los defectos sobre los que se debe empezar a trabajar. 1 Abra la hoja Trans. MTW. 2 Elija Stat > Quality Tools > Pareto Chart. 3 Elija Chart defects table. Ponga “Defectos” en Labels in y “Frecuencias” en Frequencies in. Marque OK. El defecto más importante 38

DIAGRAMA DE PARETO “Pocas causas generan la mayor parte de la variabilidad. ” Esto implica que identificar y controlar las pocas causas importantes es necesario para reducir la mayor variabilidad de salida de un proyecto. 39

Observaciones en los Diagramas Pareto • El Principio de Pareto (Pocas categorías indican la mayoría del problema) • Asegurar que la categoría “otro” es menor • Seguimiento apropiado a los Problemas – Enfoque en lo Más Importante – Arreglar las situaciones obvias (“Arreglos Fáciles”) • Considere Técnicas alternativas para separar los datos – La elección del eje Y basado en el impacto 40

Definir Medir Analizar Mejorar Control DIAGRAMA DE NIVEL ALTO PEPSC 41

Mapa de Proceso de Nivel Alto (PEPSC) Un proceso es una serie de pasos o actividades que toman entradas provistas por los proveedores, añaden valor, y producen valor para los clientes Proveedo r Entradas Proceso (transformar para agregar valor) Salidas Cliente 42

PEPSC • ¿En qué proceso existe el problema que se identificó? • ¿Quiénes son los clientes del proceso? • ¿Qué salidas requieren? • ¿Cuáles son las transformaciones básicas del proceso? • ¿Qué entradas tiene el proceso y quién las provee? Entradas Salidas P E P S C Proveedor Proceso Cliente Pasos Paso 1 Paso 2 Paso 3 Paso 4 Paso 5 43

Pasos para el Mapeo de Procesos 1. 2. 3. 4. 5. 6. 7. 8. Definan el proceso a ser representado Establezcan los puntos de inicio y fin del proceso (fronteras) Determinen las salidas del proceso Determinen los Clientes del proceso Determinen los requerimientos de los clientes Identifiquen los proveedores del proceso y acuerden sobre las entradas al proceso Acuerden sobre los 5 a 7 pasos de nivel alto que ocurren entre los puntos de inicio y fin del proceso Validen el proceso para asegurar que los 5 a 7 pasos del proceso ocurren realmente 44

Mapa de Proceso de Nivel Alto 1. Defina el Proceso a ser representado. Este paso evita que el equipo se deje “arrastrar” al verse retado por plantear el proceso. El nombre del proceso debería incluir algún verbo activo y un nombre. El equipo debe discutir las consecuencias de su definición. La forma en que se defina tendrá impacto en el alcance del trabajo a ser hecho. 2. Establezcan los puntos de inicio y fin del proceso (fronteras) No existe una respuesta única al establecer las fronteras del proceso, sin embargo esta decisión tiene impacto en el alcance del proyecto Un tramo largo de proceso entre las dos fronteras da más visión, pero también puede implicar un proyecto de mucho más tiempo 45

Mapa de Proceso de Nivel Alto 3. Determinen las salidas del proceso La salida del proceso debiera ser declarada en términos de simples nombres sin calificativos La adición de adjetivos sólo hace más difícil el trabajo por adelantarse a sí mismos en el trabajo de las últimos pasos del Mapa de Procesos Un proceso puede tener múltiples salidas, es recomendable que el equipo se oriente a la del proyecto presente 4. Determinen los Clientes del proceso Los clientes del proceso ya deben de estar determinados, el documento que lo debe de referir es el Árbol de Críticos para el Cliente, ahí debe aparecer quién es el cliente y cuáles son sus requerimientos Los clientes deben tener una jerarquía, debe haber identificado al menos un segmento de clientes primarios, con necesidades y requerimientos a los cuáles se les asignará el máximo peso. 46

Mapa de Proceso de Nivel Alto 5. Determinen los requerimientos de los clientes. Este trabajo ya debe estar realizado, en el Árbol de Críticos para el Cliente, en requerimientos que pueden estar en dos niveles o tres. Es recomendable en este punto comenzar a pensar en la forma en que los requerimientos pueden ser medidos, especialmente como los percibe el cliente. 6. Identifiquen los proveedores del proceso y acuerden sobre las entradas al proceso. Ahora el enfoque es sobre el lado izquierdo del Mapa de Proceso, los proveedores son en principio todos los que están afuera del proceso proporcionando entradas, no sólo el proveedor que inicia la secuencia del proceso. Esto implica proveedores “más atrás” del proveedor inmediato y proveedores de pasos posteriores del proceso. 47

Mapa de Proceso de Nivel Alto 7. Acuerden sobre los 5 a 7 pasos de nivel alto que ocurren entre los puntos de inicio y fin del proceso. Haga una tormenta de ideas para generar los 5 a 7 pasos de nivel alto que ocurren en el proceso. Después ordénelos. Asegúrense que cada paso de nivel alto tiene asociado un verbo activo. 8. Validen el proceso para asegurar que los 5 a 7 pasos del proceso ocurren realmente. Recuerden que hay cuatro niveles de proceso: – El proceso como creemos que es. – El proceso “como es” (un entregable de la etapa de definición), aquí estamos. – El proceso “como debe ser” (un entregable de la etapa de mejora). – El proceso “que podría ser” (un entregable de la etapa futura a diseñar). 48

Definir Medir Analizar Mejorar Control Diagramas Funcionales En AMEF necesitamos Diagramas Funcionales que nos ayuden a ver las relaciones funcionales del proceso (diagrama de flujo) ó del producto (diagrama de bloques funcionales ó árbol de fallas) 49

Definir Medir Analizar Mejorar Control DIAGRAMA DE FLUJO La base para recopilar los datos 50

DIAGRAMA DE FLUJO • Objetivo: facilitar la recopilación de datos al identificar los puntos de observación • Descripción: representa la secuencia de todos los pasos que sigue un proceso, incluye operaciones en paralelo/serie, facilitando la identificación de los puntos de observación para la recopilación de datos • Ejemplo: Maquinado de Varillas, siguiente lámina. 51

Diagrama de Flujo de Proceso: Documentar Entradas Inventario de Barra (AISI 1045) Varillas bastas Sierra Torno CNC 1 Varillas torneadas Varillas endurecidas Varilla revenida Varillas revenidas e inspeccionadas Varillas torneadas acabadas Varillas Pulidas Varillas terminadas Función de Proceso Equipo Cortar barras Torno CNC 2 Torno CNC 3 Tratamiento de Calor por inducción Horno Inspección por partículas magnéticas Torno CNC 4 Torno CNC 5 Pulidora sin Centro Lavadora Rociador de recubrimiento Tornear diámetros 3 máquinas 2 operaciones secuenciales/pieza Endurecer puntas 2 puntas, simultáneamente Revenir dureza Detectar indicación (grietas) inspección 100% Tornear acabado de diámetros 2 máquinas 2 operaciones secuenciales/pieza Pulir diámetros de flecha Limpiar varilla Inhibir oxidación 52

¿Qué puede ir mal en tu Proceso? AMEF Entradas Inventario de Barra (AISI 1045) Varillas bastas Sierra Torno CNC 1 Varillas torneadas Varillas endurecidas Varilla revenida Varillas revenidas e inspeccionadas Varillas torneadas acabadas Varillas Pulidas Varillas terminadas Función de Proceso Equipo Cortar barras Torno CNC 2 Torno CNC 3 Tratamiento de Calor por inducción Horno Inspección por partículas magnéticas Torno CNC 4 Torno CNC 5 Pulidora sin Centro Lavadora Rociador de recubrimiento Tornear diámetros 3 máquinas 2 operaciones secuenciales/pieza Endurecer puntas 2 puntas, simultáneamente Revenir dureza Detectar indicación (grietas) inspección 100% Tornear acabado de diámetros 2 máquinas 2 operaciones secuenciales/pieza Pulir diámetros de flecha Limpiar varilla Inhibir oxidación 53

Mapa de Calidad • • • Identifica todos los pasos del proceso Muestra claramente todas las especificaciones de cada paso Identifica los dispositivos de medición empleados en cada paso. Estos sistemas se probarán analizando el sistema de medición Se percibe el control que se tiene contra su realidad. Enfoque total en el paso de transformación para identificar problemas conocidos 54

Creación de un Mapa de Calidad • Use los pasos de proceso identificados en el mapa de flujo de proceso administrativo • Determine los estándares de trabajo para cada paso del proceso (lineamientos críticos para concluir exitosamente el paso del proceso) • Determine los métodos/controles de medición para cada paso (método de medición utilizado para rastrear el desempeño del proceso) • Lluvia de ideas sobre los problemas conocidos asociados con cada paso y hacer una lista en papel • Colocar arriba de cada paso de proceso del mapa de flujo de proceso administrativo, el Mapa de Calidad correspondiente 55

Definir Medir Analizar Mejorar Control Diagrama de Bloques Funcionales Una clase especial de diagrama funcional es el digrama de bloques funcionales, nos sirve en el caso de producto. Puede ser el primer paso para hacer un árbol de fallas 56

¿Qué es un Diagrama de Bloques Funcionales? • es una representación gráfica de los elementos funcionales de un sistema y sus interconexiones. 57

¿Para que utilizar el Diagrama de Bloques Funcionales? u. Es el primer paso para desarrollar el modelo del sistema y se utiliza como punto de partida en la realización de un análisis de modo y efecto de falla (AMEF). u. Entender la relación que guardan los subsistemas entre sí y el impacto de un cambio o más en el sistema. u. Construir gráficamente los elementos funcionales de un sistema y sus interrelaciones, complementar con la misión crítica que corresponde a cada elemento en el sistema. 58

Pasos en la construcción de un Diagrama de Bloques Funcionales: 1. Defina la función del sistema. 2. Defina los modos de operación del sistema. 3. Liste los subsistemas (muestre los límites de referencia). 4. Liste las funciones de los subsistemas (activas y pasivas) para cada modo de operación. 5. Defina las entradas y salidas de los subsistemas. 6. Defina la falla crítica de los subsistemas/partes y la interdependencia El formato preferido para el FBD está contenido en el “System Modeling Guidelines Standing Instruction”. 59

Perspectiva de Supersistema Diagrama de Supersistema (ejemplo de diseño de estufa) Cocina CTQs Tamaño Fácil de usar Costo Apariencia Aquí esta Ud. Estufa Eléctrica Costo Rasgos Calidad Diagrama de Contexto para la estufa Espacio y Servicios Tamaño gas electricidad agua Espacio de instalación Utensilios Recipientes especiales Accesorios Formada por Otros Recetas Costumbres Personal de instalación y reparación Manufactura Estufa Ambiente cocinar embarcar limpiar Ventilador de salida Energía Usuario El diagrama de supersistema se usa para entender donde nuestro producto o proceso ajusta en la imagen mayor.

Ejemplo de Diagramas de Comportamiento Diagrama de contexto para un sistema de control electrónico de estufa Usuario Suministro de energía energiza Parrilla controlada por afectado por Sistema de Control Electrónico de Estufa controlado por Calentamiento de Horno Ambiente opera lee calor humedad EMI Sensores montado sobre/dentro servido por Copete Reparador 61

sistema motriz lavadora MOTOR Controles OPRESOR Y LOCKTITE -Convierte la energía eléctrica en mecánica ( par- velocidad ) POLEA VENTILADOR MOTOR 2 TORNILLOS 2 TUERCAS 2 ARANDELAS DE PRESIÓN 2 ARANDELAS PLANAS 2 GROMET MOTOR SEGÚN SE REQUIERA -Figura de arrastre banda V. -Transforma par velocidad motor. -Reduce incremento de temperatura motor. BANDA V POLEA -Figura de arrastre banda V. TRANSMISIÓN-Transforma par velocidad motor. PERNO DE ARRASTRE Y CANDADO 3 TORNILLOS -Reduce giro polea transisión y lo transmite a flecha agitador. TRANSMISIÓN-Posee estructura para soportar tensión banda. ENSAMBLE CUBIERTA Tina lavado COPLE FLECHA AGITADOR GRASA Base Soporte tx Base cubierta 1 EMPAQUE NEOPRENO -Aplica movimiento de polea motor a polea transmisión. -Transmite movimiento de agitación de flecha agitador transmisión a flecha agitador cubierta. FLECHA AGITADOR GRASA -Transmite movimiento de agitación de transmisión a agitador mediante el block impulsor. -Sujeta agitador mediante husillo y tapón agitador -Posiciona flecha agitador. -Protege a flecha agitador de agua y agentes de limpieza. HUSILLO -Soporta fuerza de tensión para sellado entre tapón agitador y agitador. 1 EMPAQUE NEOPORENO 2 EMPAQUE PAPEL OPRESOR BLOCK IMPULSOR -Transmite movimiento de agitación de flecha agitador al ensamble agitador. ARANDELA Tapón agitador Ensamble agitador 62

Definir Medir Analizar Mejorar Control Análisis del Árbol de fallas (FTA) Cuando se esta analizando un producto una herramienta que puede ser de mucha utilidad para entender los mecanismos de falla es el Árbol de fallas 63

Análisis del Árbol de fallas Propósito: En este sector, explicaremos el concepto del análisis del árbol de fallas como una herramienta de análisis cualitativo de confiabilidad. Objetivos: § Aprender la simbología y el proceso de construcción de un árbol de fallas. §Entender la relación de un FTA con un Diagrama de Bloques de Confiabilidad y el AMEF. 64

Análisis del Árbol de fallas El Análisis del Arbol de Fallas(FTA) es un término que ha sido aplicado a un diagrama lógico que es usado para desarrollar todas las fallas de un sistema, subsistema, ensamble, módulo y parte/componente y las combinaciones de fallas que pueden resultar en síntomas específicos del sistema o fallas de nivel Superior. FTA es una representación gráfica asociada a una anomalía particular de un producto; un tipo de análisis de “arriba hacia abajo” en el cual cada uno de los eventos que contribuyen a una anomalía particular puede evaluarse en términos cuantitativos como cualitativos. Dicho de otra forma, el FTA muestra la relación causa-efecto entre un evento indeseable de nivel Superior y varios eventos contribuyentes. Esto se hace al proporcionar una declaración lógica del efecto acumulado de causas dentro de un producto o de un proceso. Debido a que este método de análisis inicia con un evento indeseable de nivel Superior y entonces prosigue a través de todas las causas posibles o conocidas que pueden conducir a este evento indeseable de nivel Superior, el proceso de análisis considera una estructura de ramificación que es similar a la de un árbol. Por esta razón, la técnica de análisis es referida como Análisis del Arbol de 65 Fallas.

Análisis del Árbol de fallas FTA es un medio para identificar o investigar modos de falla potenciales y causas asociadas. Puede ser § Aplicado en la fase inicial de diseño y progresivamente refinado y actualizado conforme evoluciona el diseño. § Util en la identificación de todas las causas posibles (en todos los niveles) y la relaciones entre las causas. § Usado como una herramienta para ayudar en la mejora del diseño de cualquier producto o proceso. La construcción y el análisis de un árbol de fallas es mejor realizado como una actividad de equipo. Aunque un FTA pueda ser realizado por un individuo, los árboles que son desarrollados por un equipo son generalmente más completos y mejor definidos. La razón es que una esfera mucho más amplia de información es presentada y considerada por un equipo. El conocimiento colectivo de un equipo es más benéfico que el de un individuo. 66

Construcción de árboles de fallas Una vez que el evento falla de nivel Superior ha sido definido, existen una serie de pasos que el equipo debe seguir con el objeto de analizar y construir apropiadamente el árbol de fallas. 1. Defina el sistema y cualquier otra suposición a ser usada en el análisis. También, defina que constituye una falla (es decir, límite, cambio paramétrico, funcionalidad, vibración, etc. 2. Si es necesario para simplificar el alcance del análisis, desarrolle un diagrama de bloques simple del sistema, mostrando entrada, salida e interfases. Nota: en la fase inicial de diseño, un diagrama de bloques funcionales puede ser la base de un FTA. 3. Identifique y liste los eventos falla de nivel Superior a ser analizados. Si es necesario, desarrolle un árbol de falla individual para cada evento de nivel Superior. (Esto dependerá de cómo es definido el evento de nivel Superior y la especificidad del evento o alcance del estudio). 4. Use la simbología de las puertas de la TABLA 1 y la de eventos de la TABLA 2, identifique todas las causas contribuyentes para el evento de nivel Superior. En otras palabras, use el razonamiento deductivo, identifique eventos podrían causar la ocurrencia del evento de nivel Superior. 69

Construcción de árboles de fallas 5. Piense en las causas del Paso 4 como efectos intermedios, continue el árbol lógico identificando las causas para estos efectos intermedios. 6. Desarrolle el árbol de falla al nivel más bajo de detalle necesario para el análisis, típicamente con eventos básicos o eventos no desarrollados. 7. Una vez que el árbol ha sido terminado, analícelo con el objeto de entender la lógica y las interacciones de los diversos caminos de falla, y obtenga discernimiento sobre los modos únicos de falla del producto. Adicionalmente, este proceso de análisis debería enfocarse sobre fallas que, potencialmente, parecen más probables de ocurrir. 8. Determine donde es necesaria acción correctiva o un cambio de diseño para eliminar los caminos de falla siempre que sea posible o identifique algún control que posiblemente protegiera la ocurrencia de la falla. 9. Documente el proceso de análisis y entonces de seguimiento para asegurarse que todas las acciones apropiadas han sido ejecutadas. NOTA: En este enfoque básico, el desarrollo, análisis y recomendaciones eventuales de acciones correctivas se presentan como pasos separados. En la práctica, hay una gran parte de interacción entre los pasos listados. Como resultado, el árbol de fallas que se desarrolla incluye adiciones y/o cambios 70 que reflejan una comprensión mejorada de las diversas fallas.

Construcción de árboles de fallas TABLA 1 Puertas del Arbol de Fallas Símbolo r Nombre Descripción Puerta O El evento precedente a esta puerta ocurre si cualquiera de los eventos bajo esta puerta ocurre. Una puerta O significa unión de eventos. Puerta Y El evento precedente a esta puerta ocurre si todos los eventos bajo esta puerta ocurren. Una puerta Y significa una intersección de eventos. Puerta O Exclusiva El evento precedente a esta puerta ocurre si uno de los eventos bajo esta puerta ocurre y los otros no. El evento disparador es especificado dentro de la puerta. Puerta Y Prioridad El evento precedente a esta puerta ocurre si todos los eventos bajo esta puerta ocurren en el orden especificado. El orden puede estar listado en la puerta o en un óvalo contiguo. Si no hay un orden especificado, el orden previsto es de izquierda a derecha. El evento precedente a esta puerta ocurre si r de los n eventos bajo esta puerta tienen lugar. Puert a r de n Puerta NO Y Puerta prohibida El evento precedente a esta puerta ocurre si todos los eventos en una pata sin un círculo ocurren y todos los eventos en una pata con un círculo no ocurren. Un tipo especial de puerta Y. El evento precedente a esta puerta sucede si el evento listado dentro de la puerta prohibida 71 es satisfecho y el evento bajo la puerta tiene lugar.

Construcción de árboles de fallas TABLA 2 Eventos del Arbol de Fallas Símbolo Nombre Descripción Evento Principal. También conocido como Evento Básico. Evento condicion al Evento casa El nivel más bajo de falla posible. Los eventos principales son fallas de componentes individuales, errores humanos y errores de software. Evento sin desarrollo Este evento no ha sido definido. Algunas razones para no definir un evento son : falta de interés, falta de información o desarrollo adicional no proporcionará comprensión adicional. Triángul o En Triángul o Fuera Los eventos condicionales son dependientes de los eventos principales. Están localizados sobre las puertas en el árbol de fallas. Un evento que puede estar prendido o apagado. Si está prendido, la probabilidad de ocurrencia es uno; si está apagado, la probabilidad de ocurrencia es cero. Con frecuencia se usa como guión de análisis. Usado para repetir una parte del árbol o para continuar el árbol en otra página. Usado en unión con el bloque Triángulo En. 72

Construcción de árboles de fallas Ejemplo 1 El árbol de fallas de la Figura 1 muestra la puerta Y, la puerta NO Y y la puerta prohibida. El evento Superior es seguido por una puerta Y y tiene lugar sólo si el evento A y el evento B tienen lugar. El evento A es seguido por una puerta NO Y y sucede si ocurre el evento 1 y no ocurre el evento 2. El evento B es seguido por una puerta prohibida y ocurre si los eventos 3 y 4 tienen lugar. Evento Superior Evento A Evento B Evento 4 Evento 1 Evento 2 Evento 3 FIGURA 1 Ejemplo de árbol de Fallas 73

Construcción de árboles de fallas Ejemplo 2 El árbol de fallas presentado en la Figura 2 ilustra la puerta O Exclusiva y la puerta Y Prioridad. Seguida por una puerta O Exclusiva, el evento Superior sucede si ocurre el evento A o el evento 3, pero no sucede si ambos ocurren. El evento A tiene lugar si el evento 1 y el 2 tienen lugar, pero sólo si el evento 1 ocurre antes del evento 2. Evento Superior Evento A Evento 3 1 entonces 2 Evento 1 Evento 2 FIGURA 2 Ejemplo de árbol de Fallas 74

Construcción de árboles de fallas Ejemplo 3: Daño Potencial a un Motor La FIGURA 3 muestra el evento indeseable de nivel Superior, daño potencial a un motor relativo a insuficiente presión de aceite. Como se ilustra en la FIGURA 3, el daño puede resultar de una combinación de los tres eventos básicos. Estos son 1. Baja presión de aceite 2. Bajo nivel de aceite 3. Indicador de presión de aceite defectuoso Si hay baja presión de aceite o bajo nivel de aceite y el operador falla en detectar estas fallas porque hay un indicador de presión defectuoso, entonces potencialmente el motor puede dañarse. Daño potencial a un motor relativo a insuficiencia de presión de aceite Baja presión de aceite 1 Bajo nivel de aceite 2 Indicador de presión de aceite defectuoso 3 FIGURA 3 FTA del daño potencial a un motor resultante de insuficiente presión de aceite Observe que el diagrama usa las puertas Y y O. Una vez que este paso ha sido terminado, un modelo matemático puede ser desarrollado para describir la 75 probabilidad de ocurrencia del evento de nivel Superior.

Construcción de árboles de fallas El evento de nivel Superior descrito en el árbol de la FIGURA 4 es descrito como “motor no opera”. Este ejemplo de árbol de fallas ilustra el uso de una puerta prohibida. Observe que la condición mostrada con la puerta PROHIBIDA es que un fusible se abre debido a una sobrecarga de corriente en el circuito, pero está “prohibida” su abertura hasta que la corriente a través del fusible excede la tasa de abertura. Evento esperado Switch abierto Motor no opera Falla el motor Falla el switch Corto a tierra Ejemplo 4 Motor no opera Falla alambre (abierto) Falla contacto (abierto) Motor sin corriente Fusible (abierto) Fusible abre Falla suministro de potencia Falla fusible (abierto) Corriente excede el límite del fusible Puerta prohibida Sobrecarga en el circuito FIGURA 4 FTA Motor no opera Falla alambre (cortado) Suministro de potencia (ondulado) 76

Construcción de árboles de fallas La FIGURA 5 muestra la parte superior del FTA e ilustra el uso de una puerta O con varios eventos de entrada. El propósito de la puerta O es ilustrar los eventos que necesitan ocurrir, individualmente o en combinación, para que ocurra el evento falla de nivel Superior. Este ejemplo ilustra el uso del símbolo “casa”. El evento “switch abierto” no es actualmente un evento falla. Este es un evento que normalmente se espera que ocurra. La razón de incluir este evento es tomar en cuenta que para todos los eventos normalmente produce el evento de nivel Superior. Evento esperado Switch abierto Motor no opera Falla el motor Motor sin corriente FIGURA 5 Detalle del árbol de falla Motor no opera El evento listado como “falla el motor” e ilustrado por el círculo en la figura es considerado un evento básico o principal para este análisis y no requiere desarrollo adicional. El evento listado como “motor sin corriente” e ilustrado por el rectángulo es un evento falla que es el resultado de una causa o una 77 combinación de causas, como se muestra en la FIGURA 4.

Otros aspectos del FTA AMEF y FTA son formas de análisis complementarios en diversos aspectos. El AMEF clásico, en su forma y enfoque común: 1. Es un tipo de análisis de “abajo hacia arriba”. Esto significa que el análisis considera los modos de falla al nivel más bajo y trabaja su forma para determinar los efectos al nivel más alto. 2. Implica un enfoque de análisis inductivo (FIGURA 6) para considerar como un nivel inferior, una falla simple puede producir uno o varios efectos al nivel superior. ENFOQUE DEDUCTIVO ENFOQUE INDUCTIVO Efecto de nivel Superior Causa FIGURA 6 Enfoques deductivo e inductivo FTA difiere significativamente del AMEF en el enfoque y en la construcción. El clásico FTA: 1. Usa un enfoque de “arriba hacia abajo” (en lugar de abajo hacia arriba) para determinar las causas del efecto de nivel Superior. 2. Utiliza 78 el análisis deductivo (mostrado en la FIGURA 6) en lugar del análisis inductivo del AMEF.

Otros aspectos del FTA El análisis deductivo deriva todas las causas posibles o combinaciones de causas que pueden producir el evento de nivel Superior. FTA implica el análisis de un solo evento de nivel Superior. Este análisis se usa para identificar todas las posibles causas del evento. La probabilidad de que ocurra el evento de nivel Superior puede ser predicha al usar la probabilidad de las causas y las relaciones que producen el evento de nivel Superior. Al realizar un AMEF o un FTA, un equipo debe poseer conocimiento considerable del sistema. Sin embargo, FTA tiene una ventaja en que §El árbol de fallas puede ser usado como una herramienta de desarrollo del diseño. Esta herramienta no requiere que todos los detalles del diseño sean terminados antes de que pueda empezar el proceso de análisis. Estos detalles de diseño se refieren a aspectos como planos, especificaciones, métodos, etc. §El esfuerzo de análisis puede iniciar más pronto en el proceso de desarrollo del diseño; sin embrago, debe existir antes de iniciar un FTA una comprensión de cómo se espera o cual es la intención de operación del sistema. 79

Relación Árbol de Falla - AMEF La TABLA 4 ilustra varias ventajas del AMEF y el FTA, así como el desempeño esperado de la herramienta y las situaciones en las cuales es mejor el enfoque. En realidad, piense que estas técnicas deben verse como complementarias. Ambas técnicas se enfocan sobre la generación y toma de acciones sobre la misma información. Es decir, ambas se enfocan a los modos de falla, causas y efectos, pero cada herramienta se enfoca desde una perspectiva diferente. Estas técnicas se usan mejor cuando 80 se apoyan mutuamente en lugar de verlas como en competencia o en conflicto.

Definir Medir Analizar Mejorar Control AMEF Análisis del Modo y Efecto de la Falla 81

Proceso AMEF Paso 1 Revisar el Proceso • Asegurese que el equipo entiende el proceso. • El equipo deberá revisar un plano del producto o un diagrama de proceso detallado de la operación • El producto debe ser conocido físicamente y presente y el proceso debe ser caminado en el orden en que fluye • Incluya “un experto” en el producto o proceso para responder las preguntas del equipo Paso 2 Generar y organizar modos potenciales de falla • Cada miembro del equipo debe llegar con una lista escrita de los modos potenciales de falla • Al final de una sesión conducida se deberá tener los modos de falla agrupados por afinidad. Paso 3 Listar los Efectos potenciales de cada Modo de falla • El equipo pone la lista agrupada de modos de falla en una hoja de trabajo. • Para algunos modos de falla, podría haber sólo un efecto, mientras que puede haber varios efectos para otros modos de falla • Piense: SI la falla ocurre, LUEGO cuáles son las consecuencias 4. Asignar una calificación de severidad a cada efecto 5. Asignar una calificación de ocurrencia a cada modo de falla 6. Asignar una calificación de detección a cada modo de falla y efecto 7. Calcular el número prioritario de riesgo para cada efecto. 82

Proceso AMEF Paso 8 Ordenar Los Modos de Falla • Decida sobre que Modos de Falla trabajar, ordenelos y estblezacan un NPR de corte • Un diagrama de Pareto pudiera ser útil. Paso 9 Actue para eliminar o reducir Riesgos • Usando un proceso organizado de solución de problemas (M, A, I, C), identifique las acciones para eliminar o reducir los modos de falla de alto riesgo. • Haga las recomendaciones en el nivel gerencial apropiado 83

Generar el AMEF de Proceso · Identificar el Proceso a examinar (Renovar órdenes de partes, por ejemplo) y obtener una copia del Diagrama de Proceso de Flujo Tomar Orden Llenar orden (NOTA: Un Diagrama de Entregar orden proceso no debe ser así de simple) · Identifique quién es el responsable del proceso. · Identifique al equipo participante en el AMEF. · Obtenga una copia del formato del AMEF de Proceso. · Llene las categorías AMEF. · NOTA: Un AMEF de Proceso debe suponer que el trabajo de diseño fue hecho apropiadamente. En otras palabras se supone que las tolerancias son correctas, las elecciones de material son apropiadas y así por el estilo. 84

Proceso Renovar Ordenes de Partes Análisis de Modos y Efectos de Falla AMEF de Proceso PROCESO __ _______________ Responsabilidad del Proceso ____ _ Número de AMEF _______ Preparado por: _______ Pag. _ ___de _______ Tomar orden Efecto(s) Potencial(es) de Falla Mecanismos de Falla Causa(s) Potencial(es) Controles de Proceso Actuales Detección Modos Potenciales de Falla Ocurrencia Tema Función FECHA AMEF (orig. )__ ___ Severidad Equipo BASE ____ N. P. R. Acción Recomendada Responsabilidad y Fecha Objetivo (rev)____ Resultados de Acción S O D N. e c e P. v c t R. Acción Tomada 1. Liste los pasos del proceso Llenar orden Entregar orden 85

Proceso Renovar Ordenes de Partes Análisis de Modos y Efectos de Falla AMEF de Proceso PROCESO __ _______________ Responsabilidad del Proceso ____ _ Número de AMEF _______ Preparado por: _______ Pag. _ ___de _______ Tomar orden Efecto(s) Potencial(es) de Falla Mecanismos de Falla Causa(s) Potencial(es) Controles de Proceso Actuales Detección Modos Potenciales de Falla Ocurrencia Tema Función FECHA AMEF (orig. )__ ___ Severidad Equipo BASE ____ N. P. R. Acción Recomendada Responsabilidad y Fecha Objetivo (rev)____ Resultados de Acción S O D N. e c e P. v c t R. Acción Tomada #parte mal cantidad mal dirección mal código mal 2. Identificar Modos de Falla: ¿Cómo puede fallar el Proceso para lograr su función? Llenar orden Nota: Es posible que modos de falla múltiples pueda existir para una sola función de proceso. Entregar orden 86

Proceso Renovar Ordenes de Partes Análisis de Modos y Efectos de Falla AMEF de Proceso PROCESO __ _______________ Responsabilidad del Proceso ____ _ Número de AMEF _______ Preparado por: _______ Pag. _ ___de _______ Tomar orden #parte mal cantidad mal Efecto(s) Potencial(es) de Falla Demora al llenar la necesidad del cliente Mecanismos de Falla Causa(s) Potencial(es) Controles de Proceso Actuales Detección Modos Potenciales de Falla Ocurrencia Tema Función FECHA AMEF (orig. )__ ___ Severidad Equipo BASE ____ N. P. R. Acción Recomendada Responsabilidad y Fecha Objetivo (rev)____ Resultados de Acción S O D N. e c e P. v c t R. Acción Tomada 3. Describe los efectos potenciales de los modos de falla dirección mal código mal 87

Efectos Potenciales de la Falla Los efectos pueden describirse en 3 niveles: • Efectos Locales – Efectos en el área local – Impactos inmediatos • Efectos superiores siguientes – Intermedio entre Efectos Locales y Usuario Final • Efectos finales – Efectos sobre el Usuario final Esto es lo que se califica No todos los Modos de Falla tendrán este “Efecto Domino” 88

Proceso Renovar Ordenes de Partes Análisis de Modos y Efectos de Falla AMEF de Proceso PROCESO __ _______________ Responsabilidad del Proceso ____ _ Número de AMEF _______ Preparado por: _______ Pag. _ ___de _______ Tomar orden #parte mal Efecto(s) Potencial(es) de Falla Demora al llenar 7 la necesidad del cliente Mecanismos de Falla Causa(s) Potencial(es) Controles de Proceso Actuales Detección Modos Potenciales de Falla Ocurrencia Tema Función FECHA AMEF (orig. )__ ___ Severidad Equipo BASE ____ N. P. R. Acción Recomendada Responsabilidad y Fecha Objetivo (rev)____ Resultados de Acción S O D N. e c e P. v c t R. Acción Tomada 4. Use la tabla en la siguiente diapositiva para identificar severidad. cantidad mal dirección mal código mal 89

Calificaciones de Severidad (AMEF-Proceso) Efecto Valor Criterios Menor notable 1 Es irrazonable esperar que la naturaleza menor de esta falla causará un efecto sobre el desempeño del punto del sistema o proceso siguiente o la operación de ensamble. El cliente probablemente no está habilitado para detectar la falla. Bajo 2 -3 Debido a la naturaleza de esta falla, el cliente solo experimenta ligera molestia. El Cliente probablemente notará deterioro ligero en el desempeño de este punto del sistema o un ligero inconveniente con un proceso siguiente u operación de ensamble. i. e. Retrabajo menor. Moderado 4 -5 -6 La Falla causa alguna insatisfacción en el cliente que puede incluir inconformidad o molestia. El cliente notará deterioro en el desempeño de este punto del sistema. Esto podría resultar en retrabajo/reparación no programada o daño al equipo. Alto 7 -8 Alto grado de insatisfacción del cliente debido a la naturaleza de la falla, tal cómo partes inoperables o sistemas. Las Fallas no involucran seguridad o gubernamentales. Podría resultar en una interrupción seria del proceso operación de ensamble o requerir un retrabajo mayor. 9 -10 La Falla afecta la seguridad o involucra el incumplimiento de regulaciones del gobierno. Puede poner en peligro al operador o la maquinaria de ensamble (9 con aviso, 10 sin aviso). regulaciones siguiente u Muy Alto 90

Proceso Renovar Ordenes de Partes Análisis de Modos y Efectos de Falla AMEF de Proceso PROCESO __ _______________ Responsabilidad del Proceso ____ _ Número de AMEF _______ Preparado por: _______ Pag. _ ___de _______ Tomar orden #parte mal Efecto(s) Potencial(es) de Falla Mecanismos de Falla Causa(s) Potencial(es) Controles de Proceso Actuales Detección Modos Potenciales de Falla Ocurrencia Tema Función FECHA AMEF (orig. )__ ___ Severidad Equipo BASE ____ N. P. R. Acción Recomendada Responsabilidad y Fecha Objetivo (rev)____ Resultados de Acción S O D N. e c e P. v c t R. Acción Tomada Demora al llenar 7 # parte mal la necesidad del requerida cliente Requerimiento mal entendido Error de captura cantidad mal dirección mal código mal 5. Identifique las Causas Potenciales de falla…. ¿“Cómo puede ocurrir la falla”? Nota: Debe describirse en términos de algo que se pueda corregir o controlar. 91

Proceso Renovar Ordenes de Partes Análisis de Modos y Efectos de Falla AMEF de Proceso PROCESO __ _______________ Responsabilidad del Proceso ____ _ Número de AMEF _______ Preparado por: _______ Pag. _ ___de _______ Tomar orden #parte mal Efecto(s) Potencial(es) de Falla Mecanismos de Falla Causa(s) Potencial(es) Demora al llenar 7 # parte mal la necesidad del requerida cliente Requerimiento mal entendido 6 6 Error de captura 8 cantidad mal Controles de Proceso Actuales Detección Modos Potenciales de Falla Ocurrencia Tema Función FECHA AMEF (orig. )__ ___ Severidad Equipo BASE ____ N. P. R. Acción Recomendada Responsabilidad y Fecha Objetivo (rev)____ Resultados de Acción S O D N. e c e P. v c t R. Acción Tomada 6. Califique la posibilidad de que la causa identificada ocurra. (use la tabla en la diapositiva siguiente) dirección mal código mal 92

Tasa de Ocurrencia (AMEF de Procesos ) Ocurrencia Criterios Remota La Falla es poco probable. Baja Moderada Alta Muy Alta Rango Tasas de Falla 1 <1 in 1, 500, 000 2 1 in 150, 000 3 1 in 15, 000 4 1 in 2, 000 5 1 in 400 6 1 in 80 7 1 in 20 8 1 in 8 9 1 in 3 10 >1 in 2 Relativamente pocas fallas Fallas Ocasionales Fallas Repetidas La Falla es casi inevitable 93

Proceso Renovar Ordenes de Partes Análisis de Modos y Efectos de Falla AMEF de Proceso PROCESO __ _______________ Responsabilidad del Proceso ____ _ Número de AMEF _______ Preparado por: _______ Pag. _ ___de _______ Tomar orden #parte mal cantidad mal dirección mal código mal Efecto(s) Potencial(es) de Falla Mecanismos de Falla Causa(s) Potencial(es) Demora al llenar 7 # parte mal la necesidad del requerida cliente Requerimiento mal entendido Controles de Proceso Actuales Detección Modos Potenciales de Falla Ocurrencia Tema Función FECHA AMEF (orig. )__ ___ Severidad Equipo BASE ____ N. P. R. Acción Recomendada Responsabilidad y Fecha Objetivo (rev)____ Resultados de Acción S O D N. e c e P. v c t R. Acción Tomada 6 Ninguno 6 Repetirle la orden al cliente Error de captura 8 # de parte recapturada para confirmación 7. ¿Qué controles reales de proceso se tienen para prevenir el modo de falla? 94

Controles Proceso Actual “Controles” se refiere a cosas que previenen la ocurrencia de los modos de falla o detectar el modo de la falla si ésta ocurre. · Primera línea de Defensa - Evitar o Eliminar la (s) Causa (s) de la Falla · Segunda línea de Defensa - Identificar o Detectar Tempranamente la Falla · Tercera Línea de Defensa - Reducir Impactos/Consecuencias de la Falla 95

Proceso Renovar Ordenes de Partes Análisis de Modos y Efectos de Falla AMEF de Proceso PROCESO __ _______________ Responsabilidad del Proceso ____ _ Número de AMEF _______ Preparado por: _______ Pag. _ ___de _______ Tomar orden #parte mal cantidad mal dirección mal código mal Efecto(s) Potencial(es) de Falla Mecanismos de Falla Causa(s) Potencial(es) Demora al llenar 7 # parte mal la necesidad del requerida cliente Requerimiento mal entendido Controles de Proceso Actuales Detección Modos Potenciales de Falla Ocurrencia Tema Función FECHA AMEF (orig. )__ ___ Severidad Equipo BASE ____ 6 Ninguno 10 6 Repetirle la orden al cliente 5 Error de captura 8 # de parte recapturada para confirmación N. P. R. Acción Recomendada Responsabilidad y Fecha Objetivo (rev)____ Resultados de Acción S O D N. e c e P. v c t R. Acción Tomada 2 8. ¿cuánta posibilidad hay de que la causa de la falla sea detectada? (use la tabla en la diapositiva siguiente) 96

Rangos de Detección ( AMEF proceso) “Controles” se refiere a cosas que ya sea previenen la ocurrencia de los modos de falla o detectan el modo de la falla si ésta ocurre. · Primera línea de Defensa - Evitar o Eliminar la (s) Causa (s) de la Falla · Segunda línea de Defensa - Identificar o Detectar Tempranamente la Falla · Tercera Línea de Defensa - Reducir Impactos/Consecuencias de la Falla Detección Rango Criterio Alto 3 -4 Controles tienen una buena probabilidad de detectar el modo de falla. Procesos Automáticamente detectan la falla. Moderado 5 -6 Controles podrán detectar la existencia de un modo de falla. Bajo 7 -8 Muy Bajo 9 Controles tienen una oportunidad baja de detectar la existencia de un modo de falla Controles probablemente no detectarán la existencia de un modo de falla. Ninguno 10 Muy Alto 1 -2 Control (es) Actual (es) casi certeza para detectar el modo de falla. Controles de detección confiables son conocidos en Procesos Similares. El proceso automáticamente previene procesamiento adicional. Controles no pueden detectar la existencia de un modo de falla. No se conocen controles disponibles para detectar el modo 97 de falla.

Proceso Renovar Ordenes de Partes Análisis de Modos y Efectos de Falla AMEF de Proceso PROCESO __ _______________ Responsabilidad del Proceso ____ _ Número de AMEF _______ Preparado por: _______ Pag. _ ___de _______ Tomar orden #parte mal cantidad mal dirección mal código mal Efecto(s) Potencial(es) de Falla Mecanismos de Falla Causa(s) Potencial(es) Demora al llenar 7 # parte mal la necesidad del requerida cliente Requerimiento mal entendido Controles de Proceso Actuales Detección Modos Potenciales de Falla Ocurrencia Tema Función FECHA AMEF (orig. )__ ___ Severidad Equipo BASE ____ N. P. R. 6 Ninguno 10 420 6 Repetirle la orden al cliente 5 210 Error de captura 8 # de parte recapturada para confirmación Acción Recomendada Responsabilidad y Fecha Objetivo (rev)____ Resultados de Acción S O D N. e c e P. v c t R. Acción Tomada 2 112 9. Multiplique las tres calificaciones para calcular el Número Prioritario de Riesgo. (NPR) 98

Calcular el Número Prioritario de Riesgo (NPR) NPR = Severidad x Ocurrencia x Detección guías NPR / Severidad usadas para identificar CTQs Severidad mayor o igual a 9 o NPR más grande que 360 Nota: Clasificar un NPR más grande que 360 como un CTQ es sólo una guía. Un equipo puede seleccionar el valor más bajo y tratar un NPR menor que 360 como un CTQ, pero no deberá 99 elevarlo más de 360.

Elementos Requeridos para todos los CTQs l Listar todas las Acciones Recomendadas, Quiénes son los Responsables y Completar fechas l Describir Acciones tomadas y Resultados l Re-valorar Severidad, Ocurrencia, y Detección l Recalcular el Número Prioritario de Riesgo Nota: Una severidad más grande qué/igual a 9 puede no necesitar acciones basado en la baja Ocurrencia y tasa de Detección (aunque ello permanece siendo un CTQ). 100

Proceso Renovar Órdenes de Partes Análisis de Modos y Efectos de Falla AMEF de Proceso PROCESO __ _______________ Responsabilidad del Proceso ____ _ Número de AMEF _______ Preparado por: _______ Pag. _ ___de _______ Tomar orden #parte mal cantidad mal dirección mal código mal Efecto(s) Potencial(es) de Falla Mecanismos de Falla Causa(s) Potencial(es) Demora al llenar 7 # parte mal la necesidad del requerida cliente Requerimiento mal entendido Controles de Proceso Actuales Detección Modos Potenciales de Falla Ocurrencia Tema Función FECHA AMEF (orig. )__ ___ Severidad Equipo BASE ____ N. P. R. 6 Ninguno 10 420 6 Repetirle la orden al cliente 5 210 Error de captura 8 # de parte recapturada para confirmación Acción Recomendada ? ? Responsabilidad y Fecha Objetivo ? ? (rev)____ Resultados de Acción S O D N. e c e P. v c t R. Acción Tomada ? ? ? ? 2 112 10. Use el NPR para identificar los modos de falla que necesitan más atención. Una vez que la acción se toma, re-valore Severidad, Ocurrencia, y Detección; luego recalcule el NPR. Reduzca el riesgo general en el proceso 101

¿ Cómo Generar una AMEF de Diseño? · Identificar el Sistema, Subsistema, o Componente apropiado. · Identificar quién tiene la Responsabilidad del Diseño. · Identificar el equipo participante en el desarrollo del AMEF. · Obtener una copia del formato del AMEF de Diseño (disponible en el página Web) · Llenar en el AMEF las categorías. · NOTA: Un AMEF de Diseño deberá asumir que cualquier proceso de manufactura o proceso de ejecución del trabajo será hecho apropiadamente. En otras palabras, se asume que los sistemas de medición son válidos y los métodos de control son correctos. 102

Formato de AMEF de Diseño Análisis de Modos y Efectos de Falla AMEF de Diseño DISEÑO __ _______________ Responsabilidad del Diseño ____ _ Número de AMEF _______ Preparado por: _______ Pag. _ ___de _______ Efecto(s) Potencial(es) de Falla Causa(s) Potencial(es) (Diseño) de Mecanismos de Falla Controles de Dueño Actuales Detección Modos Potenciales de Falla Ocurrencia Tema Función FECHA AMEF (orig. )__ ___ Severidad Equipo BASE ____ N. P. R. Acción Recomendada Responsabilidad y Fecha Objetivo (rev)____ Resultados de Acción S O D N. e c e P. v c t R. Acción Tomada 103

Cartografía AMEF Caso de Negocio Declaración de Problema Declaración de Meta Diagrama Funcional Identificar Modo Potencial de Falla Identificar Efecto(s) Potenciales de Modo de Falla Determinar Severidad Identificar Causas Potenciales de Modo de Falla Determinar Ocurrencia Evaluar los controles presentes o los procesos de verificación de diseño Determinar Detectabilida d Calcular NPR Identificar Acciones para conducir Mejora 104

Definir Medir Analizar Mejorar Control EQUIPO CONSTITUÍDO CAP 105

EQUIPO CONSTITUÍDO • CAP – PROCESO DE CAMBIO – ARMI – DENTRO DE MARCO – RETOS Y OPORTUNIDADES 106

PROCESO DE CAMBIO • Objetivo: Asegurar que las soluciones del proyecto estén fundamentadas durante la implementación, así como después de terminar el proyecto • Descripción: reconocer que la efectividad en los resultados de los proyectos definidos, depende de un Proceso de Cambio expresado de la siguiente manera Efectividad = Calidad de esfuerzo x Aceptación de la solución 107

PROCESO DE CAMBIO E=Q*A (Efectividad = Calidad de esfuerzo * Aceptación de la solución) Debe usted cumplir con lo siguiente: • Estar comprometido personalmente • Desempeñar el papel o papeles que se le asignen • Participar activamente • Retar el status quo • Manejar las dificultades de manera proactiva • Demostrar un sentido de urgencia, pasión y enfoque para el proyecto Su equipo, deberá cumplir con todos los requerimientos anteriores, ADEMÁS DE LO SIGUIENTE: • Evitar actitudes que pudiesen impedir el cambio • Evitar la “no intervención” prematura • Evitar “trabajar por sí solo” • Evitar que el esfuerzo de cambio sea inútil 108

PROCESO DE CAMBIO Cambio de Sistemas y Estructuras Hacer el Cambio Perdurable Monitorear el Progreso Lograr el Compromiso Estado Actual Estado de Transición Estado Mejorado Creación de una Visión Creación de una Necesidad Compartida Conducir el Cambio 109

Proyectos y Equipos Preparación para el Éxito • Enfocarse hacia un CTQ que sea terriblemente claro • Definir un alcance que sea terriblemente claro 3 herramientas principales para lograr una definición clara sobre el alcance y CTQ • Incluir / Excluir en el marco • PEPSC 110

Proyectos y Equipos Hoja de Trabajo ARMI Fase del Proyecto Fase 1 Medición/ Identificar Fase 2 Analizar/ Diseñar Fase 3 Mejorar/ Optimizar Fase 4 Controlar/ Validar Participante A Se requiere la Aprobación de esta persona, para cualesquiera decisiones fuera del alcance del equipo R Proporcionar Recursos al equipo, con la experiencia o asesoría necesaria para trabajar de manera apropiada M I Miembro del equipo Parte Interesada que será informada sobre el avance del proyecto 111

Proyectos y Equipos Preparación del Equipo • Haga que los miembros del equipo de trabajo se conozcan entre sí • Definir las formas preferidas del trabajo en equipo • Enfocarse hacia el cliente • Revisar el contrato del proyecto • Discutir cualquier aspecto del contrato • Asignar responsabilidades • Preparar una copia de contratos operativos 112

Hacer el Cambio Perdurable ¿Cómo podemos lograr lo que buscamos? Celebrar los éxitos anticipadamente Interpretar las lecciones Integrar esfuerzos Hacer el Cambio Perdurable Dedicar recursos Demostrar compromiso Alentar a la gente 113

Definir Medir Analizar Mejorar Control RETOS Y OPORTUNIDADES CAP Prepararnos para el cambio 114

Necesidad Compartida Creación de una Necesidad Compartida Matriz de Amenaza y Oportunidad Amenaza Oportunidad A Corto Plazo A Largo Plazo 115

Crear una necesidad compartida Matriz Retos vs. Oportunidades Retos Entregas tardías penalizadas Corto Plazo Más agilidad en mercado Menor costo de calidad Costos altos de retrabajo Exceso de producción Pérdida de participación de mercado Largo Plazo Oportunidades Dificultad de vender otros productos por reputación dañada Menores ajustes de último minuto Crecimiento Continuo Capacidad para introducir nuevos productos Más activos disponibles para reinversión 116

Definir Medir Analizar Mejorar Control DENTRO DE MARCO 117

DENTRO DE MARCO • Objetivo: facilitar en el trabajo en equipo la comprensión del alcance del proyecto • Descripción: dentro de un marco físico se colocan tarjetas con descripciones a temas relacionados al proyecto. Al final se distinguirán temas dentro del marco, fuera del marco y marginales. 118

Dentro del Marco “Mejorar Recepción” proveedor de material Embarque en Planta Intercambio unitario de material Capacidad de Muelle Llevar Registro Tiempo de Ciclo Sistema MRP 119

Dentro del Marco 1. El líder del equipo debe crear tres columnas sobre una pared del cuarto de reunión. – – – En la parte superior de la primera columna habrá una tarjeta grande que diga “dentro. ” En la segunda columna habrá una tarjeta que diga “fuera. ” En la tercera y última columna aparecerá una tarjeta con “¿? ” signos de interrogación. 2. El líder de equipo (BB ó GB) describirá el caso de negocio y presentará una Declaración del Problema Preliminar, usando las guías dadas anteriormente en el material. 3. Se les repartirán tarjetas a los participantes, en cada tarjeta separadamente se escribirá lo que cada miembro considera dentro del marco del proyecto, lo que esta fuera del marco y de lo que se tiene duda. 120

Dentro del Marco 4. Los miembros del equipo podrán poner sus tarjetas dentro de la columna apropiada. 5. El líder del equipo revisará cada tarjeta aclarando lo que esta escrito y buscando al mismo tiempo duplicación de ideas en lo generado por el equipo. Más importante aún, el líder buscará las tarjetas que aparecen en más de una columna, estas tarjetas deben de ponerse el columna de interrogantes, junto a las ideas en que los miembros del equipo tienen duda. 6. Es responsabilidad del GB ó BB tomar el trabajo creado por el equipo e inmediatamente reportarlo al Champion. Sobre esta base el Champion dejará sólo dos columnas: lo que esta dentro del marco del proyecto para el equipo y lo queda afuera. 121

Hacer el Cambio Perdurable Puntos Clave 1. La aceptación es importante para que el proyecto tenga éxito 2. Las CAP deben aplicarse en los proyectos en puntos apropiados, con el fin de asegurar la aceptación de soluciones y el éxito del proyecto 3. Revisión del uso de herramientas CAP, lo que animará a la gente a considerar y atender el “lado flaco” del proyecto, y no a ignorarlo 4. Los beneficios de las herramientas no pueden identificarse si no se usan 122

Definir Medir Analizar Mejorar Control GRÁFICA DE GANTT 123

GRÁFICA DE GANTT • Objetivo: programar las actividades que tendrán que realizarse en la ejecución del proyecto definido • Descripción: mostrar las actividades y fechas de ejecución que permitan observar los avances y brechas que en el desarrollo del proyecto definido se siguen 124

Ejemplo Gráfica de Gantt ID 1 Nombre de la Tarea Identificar Clientes 2 Identificar Necesid. 3 Desarrollo de CTQs 4 Revisión 5 Desarrollo de Concep. 6 Diseño de Nivel Alto 7 Capacidad 8 Revisión del Diseño 9 Desarrollo de detalles 10 Simulación 11 Análisis de costos 12 Revisión del Diseño 13 Obtención 14 Implementación Qtr 4, 1996 Qtr 1, 1997 Qtr 2, 1997 Oct. Nov. Dic. Ene. Feb. Mar. Abr. May Jun. Qtr 3, 1997 Jul. Ago. Sep. 125

Entregables · Proyecto Identificado a través de estrategia de negocios y dificultades encontradas personalmente · Revisión de Carpetas para proyectos similares · CTQs internos/externos identificados · Mapa de proceso de nivel alto · Definición de defecto y de oportunidad · Crear árbol a profundidad · Identificar fuentes potenciales de datos · Identificar miembros del equipo y funciones de negocio requeridas · Identificar requerimientos de administración de la información · Identificar el impacto financiero · Abrir proyecto en Carpeta 126