Tesis Respuesta Rápida
Tesis Respuesta Rápida
Tesis Respuesta Rápida
Facultad de Ingeniería
T E S I S:
servicios administrativos “
Presenta:
Asesor:
FACULTAD DE INGENIERÍA
Aclaración
se realizó en el periodo octubre de 2016 a abril de 2018 bajo la dirección del M.A. Mónica
Méndez Ontiveros
Originalidad
Por este medio aseguro que he realizado este documento de tesis para fines académicos
sin ayuda indebida de terceros y sin utilizar otros medios más que los indicados.
Este documento no ha sido sometido como tesis a ninguna otra institución nacional o
internacional en forma parcial o total.
Se autoriza a la UASLP para que divulgue este documento de Tesis para fines
académicos.
Nombre y Firma del autor
2
Resumen de Tesis
3
Índice
Sumario de Tablas………………………………………………………………..…............ 7
Sumario de Figuras……………………………………………………………………......... 7
Introducción………………………………………………………………………………… 9
Capítulo1: Antecedentes y problemática del sistema operativo de la empresa………… 10
1 Antecedentes y problemática del sistema operativo de la empresa………… 11
1.1 Antecedentes de la empresa………………………………………………… 11
1.2 Planteamiento del problema………………………………………………… 14
1.2.1 Problematización……………………………………………………………. 14
1.2.2 Delimitación del problema…………………………………………………. 14
1.3 Justificación…………………………………………………………………. 15
1.4 Objetivo general…………………………………………………………….. 16
1.5 Objetivos específicos……………………………………………………….. 16
1.6 Alcance…………………………………………………………………….... 16
1.7 Limitaciones………………………………………………………………… 17
Conceptos de manufactura esbelta y seis sigma para la solución de
Capítulo 2: problemas…………………………………………………………………… 18
Conceptos de manufactura esbelta y seis sigma para la solución de
2 19
problemas……………………………………………………………………
2.1 Marco teórico……………………………………………………………….. 19
2.2 Contexto…………………………………………………………………….. 19
2.3 Definición de conceptos…………………………………………………….. 20
2.3.1 Lean Manufacturing………………………………………………………… 20
2.3.2 Seis Sigma…………………………………………………………………... 23
2.3.3 Solución rápida de problemas………………………………………………. 26
2.3.4 Las 8 disciplinas…………………………………………………………….. 26
2.3.5 Reporte A3 de solución de problemas……………………………………… 28
2.3.6 Metodología de análisis de causa raíz………………………………………. 29
2.3.7 Sistema de operaciones de la empresa……………………………………… 30
2.3.8 Análisis de 5 por qué……………………………………………………….. 30
2.3.9 Modelo de Solución Rápida de Problemas (RPS)…………………………... 31
2.3.10 Requerimientos globales……………………………………………………. 32
4
2.3.11 Métricas de la empresa…………………………………………………….. 32
2.4 Impacto del modelo de solución de problemas en la empresa……………… 33
6
Sumario de Tablas
Tabla 4 Encuestas de voz del cliente en relación con los países donde fueron aplicadas… 54
Tabla 5 Total de análisis de causa raíz y medición del tiempo de los resultados………… 74
Sumario de Figuras
Registro mensual del volumen total y el total de defectos en cada uno de las
Figura 10 regiones, para su medición en ppm (partes por millón)………………………….. 43
Figura 11 Gráfica P de defectos totales con respecto al volumen…………………………... 44
7
Figura 16 Problema y punto de causa………………………………………………………. 50
8
Introducción
El siguiente proyecto se desarrolló en una empresa de servicios compartidos de recursos humanos,
financieros y de servicios Informáticos. La empresa enfoca su filosofía y metodologías en base a
una visión de mejora continua, es decir un hibrido entre herramientas de manufactura esbelta y
seis sigma.
Una de las herramientas de la manufactura esbelta es la solución básica de problemas o conocido
en otras compañías como 8D, A3, modelo de Solución Rápida de Problemas (RPS), la cual ayuda
al sistema de operaciones hacer análisis precisos en cuestión de algún problema o defecto en los
procesos. El proyecto se enfocó en la alineación y estandarización global del modelo de Solución
Rápida de Problemas (RPS) y el desarrollo de un modelo de análisis de causa raíz efectivo para
evitar y eliminar la recurrencia o defectos en los procesos de la compañía. Este es un elemento
fuerte para el sistema operativo de la empresa ya que impacta directamente a las métricas como
calidad y satisfacción del cliente, si cada uno de los defectos y problemas de los procesos para los
servicios administrativos se analizaran de manera efectiva para poder encontrar las causas raíces
que determinen acciones preventivas que mitiguen las fallas en los procesos, haría un sistema más
robusto para la organización estableciendo medidas y controles efectivos.
El modelo de solución de problemas no solo se enfoca en los análisis de causa raíz si no en mejorar
el sentido de urgencia cuando cualquier tipo de defectos o variaciones se presentan durante los
procesos de cada uno de los servicios de la empresa. Cada vez que se notifica sobre un problema
o reclamo del cliente se toman medidas de corrección que solo tapan la falla por ciertos momentos
y el problema se vuelve a presentar en el mismo servicio de la misma manera. La responsabilidad
e involucramiento de los niveles altos de la organización es crítica en este proceso para poder
analizar la recurrencia de los mismos defectos, así como la toma de decisiones en base a los
indicadores actuales de la empresa para el desarrollo de un sistema operativo robusto que cumpla
con las estrategias de la organización.
Las herramientas de análisis de causa raíz de la metodología de manufactura esbelta ayudan a
implementar este tipo de modelos en todo tipo de ambientes no solamente manufacturera si no
también aplicados a este tipo de empresa de servicios.
9
Capítulo 1:
Antecedentes y problemática
del sistema operativo de la
empresa
10
1. Antecedentes y problemática del sistema operativo de la empresa
1.1. Antecedentes de la empresa
En el siguiente proyecto se hará referencia al corporativo de servicios como “la empresa” donde
se desarrolló la implementación del modelo, este es llamado como corporativo debido a que la
estrategia principal la orfanización es la centralización de los servicios que se proveen a los
131,000 empleados que laboran en cada una de las plantas a nivel global de toda la organización
(ver figura 1).
Estos sitios corporativos se encuentran estratégicamente ubicados en las diferentes regiones como
se muestra en la figura 2.
11
En la empresa se llevan a cabo procesos transaccionales o administrativos conformados de equipos
de personas que proveen servicios específicos de recursos humanos a diferentes países donde se
ubican las plantas de la organización a nivel global. Estos servicios son identificados dentro de la
empresa como procesos, que resultan en las transacciones que se realizan como parte de los
requerimientos o pedidos que llegan en base a la necesidad de los empleados de toda la
organización a nivel global. Algunos de estos procesos son los siguientes:
Registro de altas y bajas de empleados
Control de confidencialidad de datos
Cálculo y pago de nomina
Aclaraciones de pagos
Reporte de asistencia y retardos
Beneficios y compensaciones de empleados
Plan de desarrollo y sucesión para empleados
Trámites de expatriados y re ubicación de empleados
Excelencia operacional
13
Este reporte incluye la información del equipo a donde pertenece el responsable del problema o en
su caso el defecto y de igual manera la información de problema, desde quién, cómo, cuándo se
reportó y por qué pasó. Esto da al equipo un punto de partida para analizar la causa raíz del
problema, una vez establecido este punto se empieza con un análisis de 5 por qué dentro del mismo
formato para llegar a la causa raíz. De acuerdo a las herramientas de solución de problemas de lean
seis sigma utilizan diferentes maneras de categorizar las causas raíz con ayuda de un diagrama de
Ishikawa o 6M’s, cada equipo asigna una de acuerdo al problema y se establecen acciones
correctivas y preventivas para solucionar el problema y prevenir la recurrencia del mismo. Cada
acción tiene que contar con un responsable, fecha compromiso para su respectivo seguimiento. El
área de soporte de excelencia operacional se enfoca en la mejora continua de los procesos y el
seguimiento de proyectos de la empresa basada en esta metodología del sistema de operativo de la
empresa, su participación es de gran importancia para validar cada análisis y dar aprobación de las
acciones una vez cerradas.
1.2.1. Problematización
En el sector de servicios compartidos de recursos humanos de la empresa, el Sistema de Solución
Rápida de Problemas o RPS por sus siglas en inglés el cual se mencionará a lo largo del proyecto,
se encuentra inestable debido a la recurrencia de los mismos defectos a lo largo de los diferentes
procesos en los servicios a ofrecer así como la falta de estandarización de la herramienta entre los
equipos, y la inexistencia de una correcta secuencia de acuerdo a la metodología de solución de
problemas que la filosofía de lean seis sigma fomenta.
Esto afecta a las métricas de calidad, exactitud, y satisfacción del cliente de los equipos,
principalmente en los defectos (ppm) de cada servicio, reportando problemas y defectos
repetitivitos que no cuentan con análisis precisos para prevenir su recurrencia.
El proyecto se desarrolló en el área de servicios compartidos de recursos humanos de la empresa
específicamente al sistema de RPS como se menciona anteriormente ya que los datos al día de hoy
del presente año muestran un tiempo de respuesta corta en la elaboración de los Análisis de Causa
Raíz (ACR), así como la recurrencia de defectos y problemas en los diferentes servicios.
De acuerdo al histórico de datos y análisis de tendencia en las gráficas del sistema de métricas de
la empresa es importante tomar acciones de mejora para alinear y estandarizar las herramientas
14
que se utilizan para el análisis de causa raíz y evitar la recurrencia de defectos, así como el largo
tiempo de respuesta por parte de los equipos de servicio. Es fundamental realizar esta alineación
y definir la secuencia correcta de eventos para que las causas raíces de los problemas se mitiguen
o eliminen por completo de los procesos administrativos de la empresa.
1.3. Justificación
El objetivo de la siguiente investigación es analizar el sistema actual de solución rápida de
problemas para una empresa de servicios administrativos, así como su estructura, flujo de
información, metodología a utilizar y herramientas de análisis de causa raíz en cada uno de los
equipos. De igual manera identificar áreas de oportunidad para reducir la recurrencia de los
mismos problemas o defectos de la empresa para crear una línea de partida para la alineación de
los equipos en su sistema de operaciones de manera efectiva.
Se propone la estandarización y mejora del diseño del modelo de Solución Rápida de Problemas
(RPS) como parte de la mejora de los elementos del sistema de operaciones de la empresa que se
basa en la filosofía de mejora continua por medio de la implementación de las herramientas de
manufactura esbelta y seis sigma. El modelo de solución rápida de problemas es un requerimiento
básico para la certificación bronce de la empresa en el sistema de operaciones de la organización
a nivel global.
Un sistema efectivo puede dar un gran impacto en los indicadores principales de la empresa
reduciendo la cantidad de problemas y defectos a lo largo de la organización y los procesos
administrativos de la empresa. Existen equipos en diferentes regiones donde este modelo no ha
sido implementado y la recurrencia de defectos y problemas en los procesos es muy constante. No
15
hay análisis de los mismos por lo que las acciones a tomar no son efectivas y únicamente corrigen
el problema en el momento.
1.6. Alcance
Mejorar la eficiencia de la metodología de solución de problemas en la empresa de servicios
compartidos de recursos humanos en un 50% a mediados del año 2017, por medio de la
estandarización y alineación global de las herramientas para análisis de causa raíz que dé como
resultado la recurrencia de problemas y defectos en los equipos de la empresa. Este alcance aplica
a los servicios compartidos de la empresa específicamente el área de recursos humanos a nivel
global, considerando las regiones de Latinoamérica (LAR), Estados Unidos (US), Canadá (CAN),
Asia Pacifico (APAC), Europa y Medio Este (EMEA).
16
1.7. Limitaciones
Existen diferentes limitantes en la alineación del nuevo sistema de acuerdo al objetivo establecido,
ya que los servicios que se ofrecen en la empresa son meramente administrativos, los procesos
varían según las leyes del país al que se le ofrezca servicios por lo que las causas raíz de los
problemas que se tienen en la compañía varían uno con respecto a otro.
La resistencia al cambio dentro de los equipos de la misma empresa es muy notable, aunque se
trabaje bajo los mismos lineamientos del sistema de operaciones las primeras limitantes vienen de
los mismos miembros que proveen los servicios y no del cliente directo.
17
Capítulo 2:
Conceptos de manufactura
esbelta y seis sigma para la
solución de problemas
18
2. Conceptos de manufactura esbelta y seis sigma para la solución de
problemas
2.2. Contexto
El desarrollo del proyecto toma en cuenta el contexto teórico la metodología de las herramientas
de la manufactura esbelta como:
7 desperdicios
Circulo de Deming (PDCA)
A3- solución de problemas
De igual manera se basa en la estructura de la filosofía de seis sigma para análisis de defectos y
variación en los procesos como:
DMAIC
Gráficas de control (ppm)
19
El sistema de operaciones de la empresa se basa en estas dos metodologías teniendo como objetivo
de certificación oro el uso de las herramientas lean seis sigma de las cuales se dará detalle de los
antecedentes y beneficios de cada una de ellas a continuación.
20
Reducción de inventarios
Reducción del tiempo de entrega (lead time)
Mejor Calidad
Menos mano de obra
Mayor eficiencia de equipo
Disminución de los desperdicios
Sobreproducción
Tiempo de espera (los retrasos)
Transporte
El proceso
Inventarios
Movimientos
Mala calidad
Cuando se habla de manufactura esbelta inmediatamente se piensa en Toyota y en su continuo
éxito. De ahí que hayan sido muchas las empresas que han intentado seguir su modelo: el TPS
(Sistema de Producción Toyota).
Las claves del éxito del sistema de producción Toyota se resumen en 14 principios organizados en
4 conceptos fundamentales como se puede apreciar en la figura 4 (Toledano, 2009):
Figura 4: Pirámide ‘4P’ del modelo Toyota, Fuente: Liker & Meier, 2005.
21
Concepto 1: Filosofía (pensamiento a largo plazo)
- Principio 1. Base sus decisiones de gestión en una filosofía a largo plazo, a
expensas de lo que suceda con los objetivos financieros a corto plazo
Concepto 2: Proceso (eliminación de los desperdicios)
- Principio 2. Cree procesos en flujo continuo para hacer que los problemas salgan
a la superficie
- Principio 3. Utilice sistemas Jalar para evitar producir en exceso.
- Principio 4. Nivele la carga de trabajo (HEIJUNKA).
- Principio 5. Cree una cultura de parar a fin de resolver los problemas, para lograr
una buena calidad a la primera
- Principio 6. Las tareas estandarizadas son el fundamento de la mejora continua y
de la autonomía del empleado.
- Principio 7. Utilice el control visual de modo que no se oculten los problemas
- Principio 8. Utilice sólo tecnología fiable absolutamente probada que dé servicio a
su personal y a sus procesos.
Concepto 3: Gente y socios (respeto, retos y continua evolución)
- Principio 9. Haga crecer a líderes que comprendan perfectamente el trabajo, vivan
la filosofía y la enseñen a otros.
- Principio 10. Desarrolle personas y equipos excepcionales que sigan la filosofía de
su empresa.
- Principio 11. Respete a su red extendida de socios y proveedores, desafiándoles y
ayudándoles a mejorar.
Concepto 4: Resolución de Problemas (aprendizaje organizativo)
- Principio 12. Vaya a verlo por sí mismo para comprender a fondo la situación
(GENCHI GENBUTSU).
- Principio 13. Tome decisiones por consenso lentamente, considerando
concienzudamente todas las opciones; impleméntelas rápidamente
- Principio 14. Conviértase en una organización que aprende mediante la reflexión
constante (HANSEI) y la mejora continua (KAIZEN)
22
Toyota es uno de los principales precursores de la manufactura esbelta o lean y se ha demostrado
que es una referencia de garantía para implementar en los sistemas operativos de la empresa
dedicándonos a eliminar los desperdicios que no agregan valor a las operaciones por lo que
enfocarnos es en estos principios en efecto pueden guiarnos a la clave del éxito donde la solución
de problemas es la punta de la pirámide para lograrlo.
Figura 5: Nivel de sigma y defectos por millón, Fuente: Carry Ryder, 2017.
Seis sigma trae un manual de instrucciones llamada ciclo DMAIC (Definir, Medir, Analizar,
Mejorar y Controlar). DMAIC es un proceso de mejora, sistemático, científico y basado en hechos.
23
Este proceso elimina desperdicios, con frecuencia se enfoca en mediciones nuevas y aplica
tecnologías de mejoramiento continuo.
DMAIC es un proceso de mejora, sistemático, científico y basado en hechos. Este proceso cerrado
elimina pasos improductivos, con frecuencia se enfoca en mediciones nuevas y aplica tecnologías
de mejoramiento (Mono-lab, 2011-2016 ).
Beneficios DMAIC
El principal enfoque de seis sigma consiste en la ejecución constante de proyectos y acciones para
la mejora de los procesos y reducción de la variación en los mismos, la estructura principal de un
proyecto seis sigma se basa en la metodología DMAIC y en cada uno de los pasos a seguir para
que se tenga como resultado un proyecto efectivo (Calidad.com, n.d.):
Define (Definir): ¿Qué es lo importante?
o Definir los objetivos del proyecto.
o Definir los requerimientos críticos para el cliente
o Documentar el proceso (Crear un mapeo del mismo).
o Crear la definición más fácil de entender de dicho problema.
o Construir el equipo efectivo.
El principal enfoque del proyecto en el modelo de solución rápida de problemas está alineado a la
metodología DMAIC y su estructura juega un papel importante en el desarrollo de la siguiente
investigación.
Por otra parte, esta metodología se utiliza a menudo de manera iterativa. Una vez definido el
proyecto, empezamos a medir y a analizar los datos medidos. A partir de este momento, tendremos
una información relevante para:
a. Medir otros aspectos y plantear otras hipótesis sobre la causa raíz del problema
b. Mejorar el proceso utilizando el principio de las mejoras rápidas y/o preparando
un plan detallado de implantación de las mejoras cuando se requiere.
Al final se genera un bucle entre las fases Medir, Analizar y Mejorar. Cada mejora de proceso
llevada a cabo nos permite entrar en la fase Controlar formando otro bucle. Además, en cada
momento se puede revisar la primera fase para definir objetivos, restricciones del proyecto,
alcance, etc. Se deben de seguir rigurosamente las fases de la metodología DMAIC del seis sigma
generando unos bucles iterativos entre las fases para encontrar la causa raíz de un problema y
alcanzar los objetivos basando siempre nuestras decisiones en hechos y datos (Sandrine, 2010).
25
2.3.3. Solución rápida de problemas
A continuación, se explican diferentes herramientas y metodologías para la solución de problemas
basadas en la estructura de manufactura esbelta y seis sigma, como futura referencia para el diseño
robusto y estandarización del modelo de Solución Rápida de Problemas (RPS).
“Los problemas más significativos que enfrentamos no pueden resolverse en el mismo nivel de
pensamiento que teníamos cuando los creamos.” (Albert Einstein).
Las 8 disciplinas nos ayudan a completar el ciclo de la mejora continua mejor llamado como
PDCA, planear, hacer, controlar y actuar el cual es contante al momento de enfocar nuestra
26
atención en las áreas de oportunidad de cualquier tipo de proceso o servicio. En el siguiente
esquema se puede observar la relación que existe entre cada una de las etapas del ciclo de la
mejora continua o PDCA con cada uno de los pasos en las 8 disciplinas (figura 6). El uso de
las 8D permite la mejora de productos, servicios y procesos, y establece una práctica
estandarizada a seguir. Básicamente, lo que se busca es centrarse en el origen de cada
problema mediante determinación de la causa raíz para así implantar soluciones eficaces.
Esta herramienta es de gran utilidad, pues se crea una estructura de trabajo sistematizada, se
trabaja en equipo y se consigue un enfoque común. Como consecuencia se mejoran los
sistemas de la organización, se optimiza el rendimiento y se previenen no conformidades y
fallos futuros (PDCA, 2015).
Figura 6: Ciclo PDCA relacionado a las 8 disciplinas en la solución de problemas, Fuente: Carry Ryder,
2017.
27
2.3.5. Reporte A3 de solución de problemas
Es un modelo de informe de una sola página, llamado así por el tamaño de papel mundialmente
conocido de 11 por 17 pulgadas. Contiene en una página información crítica sobre un tema, como
la descripción, el costo, el tiempo, los datos críticos de la solución de un problema o el desarrollo
de un proyecto de mejora. Para revisar un ejemplo de formato de reporte A3 para la resolución de
no conformidades se puede revisar en el Anexo 1 (Jimenez, 2013)
Antecedentes
El reporte A3 es una práctica de Toyota para desarrollar un problema, análisis, acción correctiva
y un plan de acción por escrito en una sola hoja con el uso de gráficos simples basados en
información de valor.
Este reporte obliga a captar y difundir una gran cantidad de hechos y datos en una sola página en
vez de 40 páginas en power point. Según Toyota, el reporte A3 crea empleados comprometidos y
analíticos a través del proceso de resolución de problemas propuesto en la estructura simple de un
informe A3, es el elemento clave de todo el sistema de desarrollo de talentos de Toyota.
Existen diferentes beneficios del reporte A3 de solución de problemas para todo tipo de empresas,
ya que en base a este sencillo formato y secuencia de pasos reduce los problemas y defectos en los
procesos de las organizaciones, a continuación, se enlistan cada uno de los beneficios de este tipo
de reportes.
Beneficios de solución de problemas
Elimina el tiempo perdido en las discusiones de la resolución
Identifica puntos débiles dentro del proceso
Descubre causas sistémicas
Desglosa las razones del por qué un incidente sucede
Proporciona una representación objetiva del incidente, hablando con datos
Compara lo que en realidad ocurrió contra lo que debió haber ocurrido (LEAN
SOLUTIONS, 2012)
28
2.3.6. Metodología de análisis de causa raíz
El Análisis Causa Raíz (ACR) es una metodología de confiabilidad que emplea un conjunto de
técnicas o procesos, para identificar factores casuales de falla. Es decir, el origen de un problema
definido, relacionado con el personal, los procesos, las tecnologías, y la organización, con el
objetivo de identificar actividades o acciones rentables que los eliminen .Para ver un ejemplo
aplicado de este tipo de ACR se puede revisar en el Anexo 2 de este documento (Sistema de
Confiabilidad Operacional (SCO), 2014).
El análisis de un problema se inicia con la recopilación de datos de fallas de equipos y sus
respectivos impactos asociados (en seguridad, ambiente, producción y costos de mantenimiento);
con el objeto de jerarquizar las fallas mediante el empleo de histogramas que permitan realizar un
tratamiento a los datos. Los datos a recopilar se deberán plasmar en la herramienta computacional
disponible en la instalación. Los datos mínimos requeridos son:
Nombres de la instalación y equipo(s) asociado(s) a la falla.
Descripción de la falla (modo de falla).
Fecha y hora que ocurrió la falla.
Causas de la falla.
Acciones correctivas ejecutadas.
Costo de la reparación realizada.
Tiempo fuera de servicio.
Producción diferida.
Impactos en la seguridad y en el ambiente.
Esta información se obtendrá de la revisión de:
Diagrama de flujo de procesos y diagrama de tubería e instrumentos.
Datos de frecuencia de fallas, producción diferida, impacto en seguridad /ambiente y costos
de mantenimiento (estimados).
Manuales de equipos y de operación.
Condiciones operacionales / tendencias.
Planes de mantenimiento.
Información específica sobre las fallas: causas inmediatas, estudios previos, fotos, análisis
de falla, análisis de laboratorio, entre otros.
29
2.3.7. Sistema de operaciones de la empresa
Metodología
El sistema de operaciones de la empresa de la compañía donde se realiza la presente investigación
está basado en la metodología lean seis sigma utilizadas a nivel mundial por diferentes empresas
del sector industrial. La filosofía de lean manufacturing o manufactura esbelta es desarrollada en
base al sistema de Producción Toyota (TPS) y es implementada en plantas en su mayoría del sector
automotriz por sus eficientes resultados a corto plazo en todos los procesos. seis sigma es utilizada
por empresas de diferentes ramos y se caracteriza por el uso de herramientas estadísticas que
reducen la variación en los procesos, sin embargo, la inversión en la misma es cara y los resultados
pueden ser espectaculares, pero a largo plazo.
La manufactura esbelta son varias herramientas que ayudan a eliminar todas las operaciones que
no le agregan valor al producto, servicio y a los procesos, aumentando el valor de cada actividad
realizada y eliminando lo que no se requiere. Reducir desperdicios y mejorar las operaciones.
30
2.3.9. Modelo de Solución Rápida de Problemas (RPS)
El modelo de Solución Rápida de Problemas (RPS) tiene diferentes usos en la organización
dependiendo del giro, las herramientas que se utilizan para realizar los análisis de causa raíz pueden
ser variadas siempre y cuando estén alineadas a la metodología del sistema de operaciones de la
organización , para el alcance de este proyecto el cual se desarrolló en la empresa de recursos
humanos, el modelo no cuenta con una metodología consistente, haciendo una investigación en el
material de la empresa podemos observar las siguientes definiciones:
Un problema se presenta cuando la condición actual no es la misma al estándar establecido o
cuando el estado actual no es igual al estado ideal, en otras palabras, una desviación de la operación
al proceso estándar. El sistema de Solución Rápida de Problemas (RPS) se basa en la reacción
rápida al problema para su solución, así como encontrar y eliminar la causa raíz del problema (ver
figura 7).
Figura 7: Estructura del sistema de Solución Rápida de Problemas (RPS), Fuente: tomada de la base de
datos de entrenamiento de la empresa, 2017.
31
2.3.10. Requerimientos globales
La certificación bronce del sistema de operaciones de la empresa especifica ciertos requerimientos
que se tienen que cumplir a nivel global para que se pueda implementar un sistema robusto de
solución de problemas. En la Figura 7 se pueden ver cada una de las fases con las que debe de
contar el modelo de RPS, se enlista en una pirámide invertida cada uno de los pasos a seguir en
este modelo y la relación que tiene con las metodologías explicadas anteriormente.
Cada uno de los requerimientos se enlistan en una especificación estándar que es aplicable para
los ramos de toda la organización, cada uno de estos tiene que adaptar los requerimientos a su
sistema operativo sin importar que sea un ambiente manufacturero o de servicios como el de la
empresa donde se planea implementar el modelo de solución de problemas, esto ayudará a la
certificación del sistema operativo en nivel bronce.
32
2.4. Impacto del modelo de solución rápida de problemas en la empresa
En términos generales es importante enfatizar una de las métricas clave para el cumplimiento de
los objetivos de la empresa: la calidad. En definitiva, esta métrica define no únicamente la calidad
del producto que se vende en este caso el servicio, sino también la calidad de los procesos internos
de la empresa el cual impacta a las demás métricas de satisfacción de clienta y entregas a tiempo.
El objetivo principal del proyecto es reducir los defectos y problemas que son resultado de un
reclamo del cliente, un hallazgo de una auditoria interna en los procesos, o cualquier otro tipo de
problema que se presente en los equipos y encontrar las soluciones más efectivas para prevenir la
recurrencia de estos problemas. La implementación de un sistema robusto de Solución Rápida de
Problemas (RPS) dará frente a la solución efectiva y rápida de los problemas en los servicios
mejorando la métrica de calidad en cada uno de los equipos y como resultado en la empresa a nivel
global.
33
Capítulo 3:
Implementación del modelo
de solución de problemas en
la empresa.
34
3. Implementación del modelo de Solución Rápida de Problemas (RPS) en la
empresa.
3.1. Hipótesis
La falta de estandarización en la herramienta de análisis de causa raíz (ACR) y el inconsistente
modelo de solución de problemas del sistema operativo de la empresa es la principal causa de la
recurrencia de defectos o problemas en los procesos de servicio.
Variables Independientes:
Número de Análisis de Causa Raíz (ACR): Es una herramienta para analizar y determina
la causa raíz de los problemas y o defectos.
Número de herramientas para ACR a nivel global y por función: Metodologías para
entender la razón para la variación e identifica las causas potenciales de los problemas o
defectos. Identificar las oportunidades de mejora en el proceso y desarrollar las hipótesis
para la causa raíz de las soluciones.
Metodologías para análisis de problemas: Metodologías para identificar, corregir y
eliminar problemas que permitan desarrollar ventajas competitivas al solucionarlos de
manera rápida y efectiva, disminuyendo la cantidad de defectos dentro de la organización.
Número de análisis de causa raíz abiertos: Análisis de causa raíz a nivel global en base
a los defectos registrados en las métricas de la empresa
Tiempo de espera del día de reporte del defecto y el análisis de causa raíz
Número de re trabajos en los análisis de causa raíz
Número de defectos/problemas en los procesos globales de servicio: Registro de
defectos a nivel global de cada uno de los servicios de la empresa de recursos humanos
35
Variables dependientes:
Defectos (problemas)
Los defectos hacen referencia a la realización de una actividad productiva o de servicio que por
falta de control genera un producto no conforme, y este debe ser identificado y separado para su
reproceso. De igual manera se pueden representar en los análisis estadísticos como partes por
millón o defectuosas en el volumen de los casos generados en la compañía.
Para el proyecto se utilizó el termino defecto para los servicios no conformes, como se trata de
servicios administrativos, cada uno de los servicios que no cumplen con los requerimientos del
cliente se puede clasificar como un producto no conforme, como cada uno de estos requerimientos
se registran como casos en el sistema de la organización o como número de empleados impactados
a los que se les provee servicio.
3.3. Validez
La validación de las variables se hará por medio de la generación de diferentes gráficos estadísticos
comparando la relación de cada una de ellas, la hipótesis supone que por la falta de un sistema
robusto de análisis la recurrencia de defectos y problemas en los procesos es constante, por medio
de los métricos se podrá validar esta relación entre ambas variables, así como el análisis de todas
las variables para detectar los principales factores.
En base al cuadro de construcción de instrumentos para la recolección de datos de acuerdo a las
variables del proyecto, los instrumentos seleccionados son los siguientes:
Lista de verificación global para inventario de herramientas
Lista de verificación de entrenamientos disponibles
Registro estadístico
Registros de defectos en métricos y reportes del CRM de la empresa
Registros de los análisis de causa raíz en el repositorio global de la empresa
36
3.4. Recolección y análisis de datos
Como parte de la evaluación de las herramientas de solución de problemas en todas las regiones,
se enlistaron cada uno de los requerimientos y propuestas que el modelo debería tener y el impacto
que cado uno de estos tiene sobre la métrica. En la tabla 2 se puede observar cada una de las
secciones y campos que la herramienta de solución de problemas y análisis de causa raíz (ACR)
debe cumplir para el estudio de las variables.
La especificación del sistema operativo solicita ciertos requerimientos a cumplir para la
certificación del sitio en bronce, con ayuda de los requerimientos de certificación se alineo cada
uno de estos mismos en la lista de verificación para poder cumplir con las expectativas del sistema
operativo para el Modelo de Solución de Problemas (RPS). Al tratarse de un ambiente
administrativo por el tipo de servicios de la empresa la lista de verificación se tiene que adaptar a
las necesidades de la operación de cada uno de los servicios.
37
Tabla 2 Lista de verificación de requerimientos para la herramienta del modelo RPS
Estado
Requerimientos Impacto en Métricas
Actual
1 Información del Equipo/Proceso
1.1 Dueño del ACR
1.2 Supervisor
1.3 Tipo de Caso
Análisis de los contribuidores de
1.4 Región más defectos y ACR para toma
de decisiones
1.5 País
1.6 Servicio Impactado
1.7 Focal Auditor de excelencia operacional
2 Información General del Problema
2.1 Tipo de defecto
2.2 Número de defectos
2.3 Ejecutivos impactados Análisis de repetibilidad e
impacto de los defectos o
2.4 Impacto del defecto
problemas en cada uno de los
2.5 Repetibilidad del defecto servicios
2.6 Día del defecto
2.7 Día de detección
3 Punto de Causa
3.1 Descripción del defecto
3.2 Cliente que identifico el defecto
Guía para el análisis de causa
3.3 Etapa del proceso donde ocurrió raíz y análisis de tendencia en
3.4 Desviación al proceso estándar métricas correlacionados a los
defectos
3.5 Otros Puntos de Causa
3.6 En qué sistema/archivo ocurrió el defecto
4 Análisis de Causa Raíz (5 Por qué)
4.1 Día del ACR
4.2 Análisis de 5 por qué Análisis y Medición de las
Causas raíces más comunes en
4.3 Descripción de la Causa Raíz los procesos
4.4 Categorización 6M's (Ishikawa)
5 Plan de Acción
5.1 Acciones correctivas
5.2 Acciones preventivas
Seguimiento de acciones y
5.3 Acciones de contención Medición de la efectividad de las
5.4 Acciones de comunicación mismas para mitigar las fallas en
los procesos
5.5 Asignación de fechas y dueños de acciones
5.6 Liga directa al sistema de Ideas de Mejora
6 Niveles de Aprobación
6.1 Aprobación del ACR del auditor de excelencia operacional
6.2 Revisión del ACR por el focal auditor de excelencia operacional Control por parte de los lideres
para sostener las medidas
6.3 Aprobación del ACR del Supervisor implementadas
6.4 Revisión de la implementación de acciones en el proceso
Fuente: Elaboración propia.
38
3.6. Inventario de herramientas de solución de problemas
Figura 8: Herramientas actuales para solución de problemas, Fuente: Plataforma de capacitación, 2016.
La metodología que se utiliza para dar cualquier tipo de entrenamiento en caso de tener nueva
gente en el equipo, así como para el uso de las herramientas anteriores cuenta con diferentes áreas
39
de oportunidad que no se han identificado y son esenciales para un sistema efectivo de solución
de problemas que evite la recurrencia de los mismos defectos:
El análisis de causa raíz no es consistente con respecto a la secuencia del mismo.
La herramienta es manual y toma bastante tiempo para llenar la información que se
requiere.
No existe un proceso estándar para reportar y escalar los defectos a los diferentes
niveles de la organización o de los equipos de operación
En caso de algún problema las áreas de soporte no documentan estos defectos y no
existe un plan de acción para prevenir los mismos.
Las acciones preventivas no mitigan los defectos o problemas identificados y la
recurrencia en los mismos servicios es muy común por lo que no existe efectividad
en el plan de acción.
40
RCCA
RCA Date :- 5th August RCA #(as per RCCA tracker) :-
RCA Team :- Rama, Rashid, Neha Puri(HRG)
Problem Statement :- Expense Approval notfication sent to the Incorrectly designated HRG
Any Immediate Action (Correction) Correct HRG EID updated for the employee.
Corrective actions
Point of Cause (s) Root Cause (s) Action Type of action Action Owner Target Date Status
1.Add Instructions in the
# Due to dragging of cells Mass HRG Template for
containing EID's , incorrect filling the the input.
The Submitter Dragged the EIDs mapping resulted 2. Run a Macro for Input
while filling the Mass HRG # Knowledge Issue Vs Output before moving
Template the Load In Prod. Corrective Action Rashid Husain 26th August 2016 In Progress
Why Request sent to APeHR HRG was not aware of GDA Contacted HRG and
mailbox? mailbox provided the overview Corrective Action Rama Manne 16-Aug-16 Completed
Why processor missed to verify Checklist not Part of the Create Mass HRG checklist
HRG load checklist? Salaesforce currently in salesforce Corrective Action Rama Manne 12-Aug-16 Completed
Figura 9: Formato estándar de la región para análisis de causa raíz de E.U.A., Fuente: tomada de la base
de datos de entrenamiento de la empresa, 2017.
La metodología que actualmente utiliza la región también cuenta con una tabla que muestra las
métricas relacionadas a este elemento con respecto al estado de cada uno de los análisis de causa
raíz en los equipos. Cuenta con una guía de referencia estándar para poder levantar andon (ayuda
visual) que indica cuando se tiene algún problema o anormalidad en los procesos o servicios. Este
concepto de andon es una de las herramientas de manufactura esbelta que indica a las líneas de
producción cuando existe un problema en el proceso y el dueño del mismo no puede solucionarlo,
esto únicamente es una ayuda visual o auditiva, el sistema actual que los equipos utilizan va más
enfocado al reporte con el siguiente nivel de problemas y no a la solución de los mismos. Existen
diferentes áreas de oportunidad en la herramienta estándar de la región que se muestran en la
siguiente lista:
La metodología de análisis de causa raíz no es robusta y toma mucho tiempo a los equipos
reportar los defectos y problemas para llegar a la verdadera causa raíz del mismo.
Las acciones están enfocadas a corregir únicamente los errores y no a prevenir la
recurrencia de los mismos.
Las operaciones enfocan su atención en tapar el problema y no en atacarlo desde la raíz
categorizando las causas correctamente.
41
3.6.3. HRS EMEA
En la región de EMEA se cuentan con 45 países y diferentes equipos de operación que son parte
de 3 funciones en toda la región, así como 5 equipos de soporte para los mismos equipos de
operación de toda la región.
Actualmente esta región no cuenta con un modelo de solución de problemas, existe una gran
holgura en sus procesos ya que cuanto se reporta un defecto o problema los equipos se juntan a
analizar que ocurrió y enfocan su atención en corregirlo, pero no en prevenir o mitigar la falla para
que vuelva a repetirse en los procesos o servicios.
La región no se cuenta certificada en el sistema de operaciones de la empresa ya que hasta la fecha
está alineando cada uno de los elementos con otras regiones para poder controlar sus procesos y
alinearse a los requerimientos del sistema operativo.
En base a estos datos se realizó un análisis estadístico en Minitab con una gráfica de control P la
cual analiza la proporción de defectos contra el volumen total de los procesos, así como sus límites
de control inferior y superior (LCI y LCS), esta grafica puede ayudar a analizar la estabilidad de
los procesos en las regiones con respecto a su número de defectos (figura 11).
Como interpretación de la gráfica los procesos en las regiones no se encuentran bajo un control
estadístico como lo muestra la proporción, ya que existen muchos puntos fuera de los límites de
control, la cuestión es cómo se relaciona este análisis con el modelo de solución de problemas
(RPS). Si las herramientas que cada una de las regiones utiliza para los análisis de causa raíz de
los defectos o problemas fuera efectivos, la recurrencia de los defectos en los procesos de
operación no sería alta como podemos ver en la gráfica. En la gráfica P se puede ver que existe
una enorme variación en las regiones con respecto a la proporción de defectos, se puede decir que
43
el proceso no es estable ya que existen muchos puntos fuera de los límites de control y la
proporción de defectos es alta con respecto al volumen de los casos recibidos por la operación.
Figura 11: Gráfica P de defectos totales con respecto al volumen, Fuente: Elaboración propia.
44
Aunque estos indicadores existan en los equipos tienen recurrencia de los mismos problemas o
defectos por lo que el sistema no es efectivo, así como la validación por parte de los auditores de
excelencia operacional. A continuación, se presentan análisis inicial de datos del estado actual del
modelo de análisis de causa raíz que tiene cada región en sus servicios, por medio de herramientas
estadísticas ayudara a tomar decisiones para el modelo de solución de problemas a proponer para
la empresa, esto ayudara a definir el punto de los objetivos para enfocarnos en la reducción de los
mismos (tabla 3).
Tabla 3: Análisis inicial de datos de ACR de cada región.
El gráfico incluye el número de ACR en comparación de los análisis abiertos al día de hoy durante
el 2016 por equipo, todos estos servicios perteneces al área de operaciones globales de la empresa.
Como se puede observar en el grafico al menos el 60% en promedio de los ACR totales se
encuentran abiertos y no se le ha dado ningún tipo de seguimiento, esto afecta directamente a las
acciones que se toman para cada uno de los análisis y que da como efecto a la recurrencia de los
mismos problemas en los procesos de los servicios.
Figura 12: Análisis estadístico total ACR contra abiertos, Fuente: Reporte mensual de ACR, 2016.
45
Figura 12: Análisis estadístico total ACR contra abiertos, Fuente: Elaboración propia.
El gráfico de la Figura 13 incluye el número de análisis de causas raíz (ACR) en comparación del
porcentaje de re-trabajos en ACR al día de hoy durante el 2016 por equipo. Se considera un re
trabajo del análisis cuando este rechazado por el focal auditor de excelencia operacional que audita
el análisis y las acciones tomadas. Actualmente existe un alto número de rechazos que puede
indicar una falta de efectividad debido a la recurrencia de defectos en los servicios. El re trabajo
es considerado una vez que ya se realizó el análisis, pero no se hizo una categorización de la causa
raíz precisa, entonces el responsable tiene que volver a realizar el análisis y especificar la causa
raíz correcta.
La participación de este focal es crítica en el proceso ya que juega un rol importante de auditoria
para no enfocar los análisis en el error humano si no en identificar mejoras potenciales y controles
para cada uno de los procesos. Una parte clave del proyecto es alinear el criterio de auditoria de
estos focales de excelencia operacional por medio de una calibración que ayuda a hacer más
eficientes las intervenciones de los mismos en los análisis de causa raíz.
46
Total de ACR vs rechazados
160 40
35
140 35
120 27 30
ACR RECHAZADOS
TOTAL DE ACR
100 25
80 20
60 11 15
10
40 8 10
4
20 2 5
0 0
Praga India E.U.A Mexico Sudamerica Canada China
Figura 13: Total ACR vs total de rechazos globales, Fuente: Elaboración propia.
En la Figura 14 se puede observar los datos graficados del 2016 por equipo en cuestión del número
de ACR por equipo de los proceso así como el tiempo promedio de respuesta desde que se reporta
el defecto o el problema hasta que se desarrolla el análisis de causa raíz. El gráfico incluye los días
promedio por equipo del tiempo de espera total de los ACR, todos estos servicios perteneces al
área de operaciones globales de la empresa.
Otro indicador importante de este sistema es el tiempo de espera del ACR desde el día en que se
desarrolla hasta el día que las acciones correctivas y preventivas son cerradas, en la Figura 15 se
47
puede observar este tiempo promedio por equipo de acuerdo al total de sus ACR. En el gráfico se
puede ver que es muy largo el rango de tiempo promedio que se toman lo equipos para implementar
y completar las acciones preventivas que mitiguen las fallas de los defectos y problemas por lo
que puede ocasionar una mayor ocurrencia e impacto de los mismos en los procesos.
Dependiendo de la complejidad las acciones deberían tomar cierto tiempo de implementación en
los procesos. Los operadores de cada uno de los servicios deberían tomar responsabilidad de las
mejoras y controles en los procesos, así como los líderes de los mismos equipos la validación de
que las acciones implementadas son efectivas y eliminar la causa raíz de los problemas.
Figura 15: Tiempo ciclo total (días promedio), Fuente: Elaboración propia.
48
Plan de Acción
Cada uno de los elementos enlistados tiene diferente metodología a seguir, por lo que el análisis
no es consistente y no ataca la causa raíz del problema. Como enfoque del proyecto se planea la
estandarización de cada uno de estos puntos en base a la correcta metodología del sistema de
operaciones de la empresa y los requisitos para la certificación bronce del mismo sistema como se
mencionó en el Marco teórico. A continuación, se ven cada uno de los elementos a estandarizar
con la propuesta para el Modelo:
Análisis de secuencia de eventos: Utilizar un solo formato con diferentes etapas como proceso
estándar, desviación del proceso, responsable y fecha del evento. Esto con el propósito de
identificar la desviación de algún proceso estándar ya definido cuando se cometa un defecto o
error. Este elemento puede ser el detonante del punto de causa para analizar el problema ya que
encontrando la desviación del proceso se pueden identificar diferentes análisis de causa raíz y a
vez asignar acciones que ayuden a la prevención de esos modos de falla.
Punto de Causa: Estandarización de la herramienta de análisis 5W+1H, la cual responde a las
preguntas: Qué, Cuándo, Cómo, Quién, Por qué, Donde, para encontrar el punto de causa del
problema para su posterior análisis de causa raíz.
Análisis de causa raíz: ligado al punto de causa, el análisis de la causa se realiza por medio de la
metodología de los 5 por qué (5W) para llegar a la causa raíz del problema de mayor impacto.
Muchas de las ocasiones donde los operadores realizan los análisis de 5 por qué confunden el punto
de causa con la causa raíz del problema, ambos son elementos totalmente diferentes, como
podemos observar en la imagen existe una fuerte relación entre ambos y de igual manera una gran
diferencia (ver figura 16).
49
Figura 16: Problema y punto de causa, Fuente: A3 - Root Cause Analysis, 2016.
Como se puede observar en la imagen el problema que se presenta de primera instancia es el dolor
que la persona siente en su pie al pisar el vidrio roto el cual se convierte el punto de causa, si
aplicamos de manera correcta la metodología de análisis de causa raíz podremos analizar por qué
el vidrio está roto por medio del método de los 5 por qué y encontrar la causa raíz del problema
que ayudaran a la persona a aplicar mejoras para que el problema no ocurra de nuevo.
Plan de Acción: Establecer un plan con acciones estándares definidos como preventivos,
correctivos, contención, estandarización y comunicación. El plan de acción o también llamado
plan de control ayuda a ligar cada uno de los puntos de causa y causas raíz del problema con
medidas que mitiguen o eliminen las fallas en los procesos de servicios de la empresa. Existen
diferentes metodologías que establecen como obligatorios los planes de acción. Para fines
prácticos del proyecto y del tipo de servicios donde este modelo se aplicará se solicitarán como
obligatorias las medidas correctivas y preventivas, es opcional agregar las otras. Dentro del plan
de administración de cambios del proyecto y entrenamiento es crítico hacer énfasis en dirigir sus
análisis de causa raíz a dos preguntas clave:
¿Por qué ocurrió el problema o defecto?
¿Por qué no se detectó?
Ya una vez estandarizados los puntos anteriores con cada uno de los puntos críticos que se deben
tomar en consideración para el modelo se planea integrar cada uno de ellos con información
complementaria sobre el problema al modelo de solución rápida de problemas que ayude a realizar
de manera efectiva los análisis de causa raíz de los problemas y defectos de la empresa.
50
3.8. Cuadro metodológico propuesto
En base a los conceptos presentados en el marco teórico, se construyó una propuesta de cuadro
metodológico para la implementación de este modelo alineando cada una de las etapas o pasos a
seguir con las metodologías clave del sistema de operaciones de la empresa: manufactura esbelta
y seis sigma como son los pilares de los costados:
La figura 17 muestra la relación del Sistema de Solución Rápida de Problemas (RPS) con la
estructura de las metodologías de lean seis sigma como se mencionaron anteriormente (PDCA y
DMAIC), es importante seguir la secuencia de estas fases para tener un análisis de causa raíz más
efectivo y evitar la recurrencia de problemas en los equipos de recursos humanos de la empresa.
Figura 17: Modelo de Solución Rápida de Problemas (RPS), Fuente tomada de la base de datos de
entrenamiento de la empresa, 2017.
51
3.9. Desarrollo del modelo
En base a metodologías de diseño e implementación de estrategias de servicio se llevó a cabo un
plan detallado de actividades para poder desarrollar la ejecución del modelo propuesto en la
empresa de servicios administrativos. Como se muestra en la lista existen 3 puntos clave para el
diseño del resultado del servicio (Pérez D.A., 2016):
1. Provisión de evidencia tangible para un servicio esencialmente intangible.
2. Personalización de un servicio típicamente estándar.
3. Estandarización de un servicio típicamente personalizado.
Tomando como referencia estos puntos clave para la visión estrategia de diseño e implementación
de estándares en servicios para poder llevar a cabo el modelo propuesto con anterioridad en base
a la investigación de las variables, a continuación se enlistan en un plan estratégico cada una de
las actividades y entregables que se llevaron a cabo para poder implementar el modelo, así como
los resultados obtenidos de cada una de estas etapas con respecto a lo esperado en los objetivos
iniciales del proyecto:
52
Figura 18: Equipo global multifuncional del modelo de Solución Rápida de Problemas (RPS), Fuente:
Elaboración propia.
53
países y equipos que no hacían uso de este tipo de metodologías para tomar en cuenta las diferentes
perspectivas de cada uno de las funciones y así desarrollar un modelo optimo y flexible para todas
las operaciones.
La tabla muestra cada una de las preguntas aplicables para esos equipos ya que para los que no
contaban con ningún tipo de metodología no todas las preguntas eran aplicables, pero si se tomaba
en consideración los posibles cambios que quisieran aplicar al modelo para poder mejorar sus
procesos. Es crítico tomar en cuenta este tipo de sugerencias ya que esto puede ser un gran riesgo
para el proyecto si se deja afuera del estándar algún requerimiento crítico para la operación.
Tabla 4 – Encuestas de voz del cliente en relación con los países donde fueron aplicadas
Sudamérica
Alemania
Inglaterra
México
Canadá
E.U.A.
China
Brasil
India
Praga
Pregunta de la encuesta
De una muestra de 80 personas a las cuales se les compartió la encuesta se obtuvo una después de
65 personas, esto quiere decir más del 80% participo en la encuesta con retroalimentación valiosa
para tomar en consideración en los requerimientos del modelo, así como diferentes sugerencias
que se podían tomar en cuenta para incluir dentro del proceso estándar y la herramienta de análisis
de causa raíz a utilizar. En base a esto se puede ver de la figura 19 a la 24 el tipo de respuestas
recibidas en base las encuestas aplicadas a los usuarios, así como su interpretación de cada uno de
los resultados:
54
1.- ¿Existe un entrenamiento útil y
entendible para el sistema de
solución de problemas?
Figura 19: Encuesta de voz del cliente- pregunta 1 y resultados, Fuente: Elaboración propia.
Existe una parte considerable de la población de usuarios que actualmente no llevan a cabo ninguna
metodología de solución de problemas o no tienen conocimiento del mismo. Esta es una parte
crítica ya que parte de los requerimientos de certificación del sistema operativo de la empresa es
que al menos el 90% de la población total de la empresa tenga al menos un entrenamiento
relacionado con la metodología de solución de problemas.
Con estos resultados se puede interpretar que no únicamente no existe un entrenamiento formal si
no que puede ser que nuevos empleados que se ha incorporado a la organización no han seguido
un proceso de capacitación de acuerdo al estándar. Es importante no dejar esto de lado ya que los
nuevos empleados o talentos dentro de la empresa son los que pueden contribuir con mejoras a los
procesos e identifiquen áreas de oportunidad dentro de los mismos servicios y no convertirlos en
los principales contribuidores de defectos o problemas como se presentaba con anterioridad en la
empresa.
55
2. ¿Es efectivo el sistema de solución
de problemas para reducir los
defectos en tu equipo?
Figura 20: Encuesta de voz del cliente- pregunta 2 y resultados Fuente: Elaboración propia.
Tomando como referencia los resultados de esta pregunta se puede observar que la satisfacción de
los usuarios con respecto a las herramientas que llevan para solución de problemas es en parte
negativa ya que no manejan un sistema robusto y efectivo que evite la recurrencia de los defectos
en las operaciones.
Los especialistas y analistas en su mayoría son los principales impactados en este tipo de
situaciones ya que viven el día a día de sus actividades en las operaciones de cada uno de los
servicios que proveen y cuando los defectos y problemas están a la orden del día esto puede llegar
a causar muchas de las veces inconformidad por parte de los empleados. La clave de la mejora
continua es la gente que atribuya con sus ideas a los procesos para optimizar los recursos y mejorar
los estándares, realizar de manera más sencilla sus operaciones sin la presencia de problemas en
los mismos procesos.
Es por eso que debemos de enfocar nuestra atención en este tipo de retroalimentación que nos da
como punto de partida el desarrollo del modelo de solución de problemas de manera más robusta
para la empresa dando como beneficio procesos con menor re ocurrencia de defectos.
56
3.- ¿Son efectivas y útiles las herramientas que utilizan para analizar la causa raíz de los
problemas?
Figura 21: Encuesta de voz del cliente- pregunta 3 y resultados, Fuente: Elaboración propia.
Al igual que le pregunta anterior como se puede ver también existe un área de oportunidad no
únicamente en el proceso de solución de problemas si no que también en las herramientas que
actualmente utilizan para analizar la causa raíz de los defectos o problemas.
Este dato se puede encontrar con detalle en el previo inventario de herramientas que ayuda a tener
una vista general del estado actual para cada uno de las funciones que se llevan a cabo en los
diferentes procesos de los equipos de la empresa.
La herramienta de análisis de causa raíz ayudara a los usuarios de una manera más sencilla a definir
un punto de causa correcto que detone el análisis de causa raíz de manera efectiva y rápida. Esto
guiara a un plan de acción que mitigue las falles durante los procesos identificando mejoras y
controles que eviten la recurrencia de los mismos. Por este medio también se planea involucrar a
los líderes de equipo y auditores de calidad que con diferentes puntos de vista y aprobaciones
hagan más robusta esta herramienta.
57
4.- ¿Sabes cuándo desarrollar un análisis de causa raíz?
Figura 22: Encuesta de voz del cliente- pregunta 4 y resultados, Fuente: Elaboración propia.
En esta pregunta se recibió una retroalimentación positiva por parte de los usuarios ya que la
mayoría tiene conocimiento de las situaciones donde tienen que realizar un Análisis de Causa Raíz
(ACR) y cuando no es aplicable.
Si nos sumergiéramos más a detalle en el análisis de esta pregunta podríamos observar situaciones
donde el criterio para poder realizar este tipo de análisis no es estándar y varia de un equipo a otro
dentro de la misma función, así como de la misma región. Este es el punto de partida para los
análisis de causa raíz que se desarrollen por la herramienta ya que si el criterio o reglas que se
siguen para desarrollar este tipo de análisis no son los mismos pero las métricas que se toman como
referencia cuando se impacta a alguna de ellas si son las mismas quiere decir que no estamos
midiendo lo mismo de manera correcta. Citando a H. James Harrington gurú de la calidad y mejora
de procesos:
“La medición es el primer paso para el control y la mejora. Si no se puede medir algo no se lo puede
entender. Si no se le entiende, no se le puede controlar. Si no se le puede controlar, no se le puede
mejorar” (Harrington, February 26,1987)
Es importante enfocar los esfuerzos de este proyecto en el costo y la gestión de calidad el cual es
un componente clave de la organización para la mejora de su productividad y reducción de costos,
así como la satisfacción de sus clientes.
58
5.- ¿Cuándo se analiza un problema
el enfoque es directamente al error
humano o al proceso?
Figura 23: Encuesta de voz del cliente- pregunta 5 y resultados, Fuente: Elaboración propia.
Como se puede observar la mayoría de los análisis de causa raíz de los defectos y problemas se
contribuyen a las personas y no a los procesos. Un sistema operativo de producción robusto ya sea
de servicios o productos tangibles enfoca sus esfuerzos en contribuir la causa de los problemas en
los controles establecidos en un proceso y no en el error humano.
Este siempre estará a la orden del día y más tratándose de procesos transaccionales o servicios, si
los mismos usuarios u operadores identificaran mejoras y controles que ayuden a realizar sus tareas
de manera más sencilla y eficiente tendrían como resultado una alta productividad y cero defectos
como lo promueve la metodología seis sigma, empresas de nivel mundial tienen como objetivo
una exactitud en su producción que no genere defectos (ppm).
Es clave que como parte del modelo de solución de problemas se implementen medidas que ayuden
a enfocar los análisis de causa raíz en mejoras y controles para el proceso y no en la gente. Esto
ayudará a reducir al re ocurrencia de los mismos defectos en los diferentes procesos.
59
6.-¿Cuándo se analizan las causas de
los problemas las acciones eliminan
el impacto?
Figura 24: Encuesta de voz del cliente- pregunta 6 y resultados, Fuente: Elaboración propia.
En la figura de la última pregunta de la encuesta podemos ver que al menos la tercera parte de los
usuarios observaron que las acciones que se asignan de un análisis de causa raíz solo reducen el
impacto del problema o el defecto, es embargo puede ocurrir de nuevo ya que no se elimina por
completo. Esto puede afectar a la productividad de los diferentes servicios que se proveen en la
compañía y de igual manera a la métrica más importante la calidad.
El principal objetivo del modelo es reducir el re-ocurrencia de defectos en los procesos de la
empresa para así incrementar la productividad en los equipos dando como resultado servicios más
robustos de mejor calidad para los clientes.
En base a los resultados de las encuestas a los usuarios en base a los modelos actuales de solución
de problemas, otorgan un excelente punto de partida para lo que será el modelo de solución de
problemas. Es clave escuchar la voz del cliente por este medio de métodos que nos ayudan a tener
mayor visión y claridad de las necesidades de cada una de las funciones de los diferentes equipos
y así hacer más efectiva la comunicación de los cambios en la empresa.
60
3.9.2. Desarrollo de requerimientos de la nueva herramienta de ACR
Una vez recolectados los comentarios de los usuarios se tomaron en cuenta para integrarlos en el
modelo en base a la factibilidad y las especificaciones que el sistema operativo solicitaba. En base
a los requerimientos en listados en el inventario de herramientas se enriquece con la
retroalimentación del cliente con el objetivo de integrar lo que se categorizó como factible.
Esta lista de requerimientos se revisó con los líderes regionales de cada función para obtener
posteriormente su aprobación, esto fue tomado como retroalimentación de igual manera para
alinear las necesidades de cada función con el modelo.
61
Figura 25: Información del problema y punto de causa, Fuente: Torres Paola, 2017.
En ambas secciones se da una visión general del defecto definiendo el tipo de problema, la
descripción del mismo, las fechas en que este se detectó y el día que ocurrió para generar métricas
que analicen el sentido de urgencia por parte de los usuarios, de igual manera el impacto del
problema y si existió algún impacto a la nómina a los ejecutivos para tener como referencia a los
reportes que se presenten para el equipo de liderazgo. El punto de causa como se mencionó con
anterioridad será el punto de partida para un análisis de causa raíz robusto que mitigue las fallas
en los procesos.
62
Figura 26: Análisis de Causa Raíz (ACR), Fuente: Torres Paola, 2017.
Esta es la sección clave de la herramienta ya que es donde los usuarios llevan a cabo el análisis de
causa raíz del problema o defecto, como la metodología lo específica es importante que el análisis
de 5 por qué no se desvié del punto de causa y de realizar las preguntas que eliminen la causa del
problema.
Cuando se llevó a cabo un estudio de los ACR anteriores se pudo identificar que esta era una de
las partes donde los usuarios se desvían más de la causa raíz del problema para realizar este análisis
de manera más sencilla parte del requerimiento es automatizar esta sección de la herramienta
ligando el punto de causa a la primera pregunta o por qué del análisis y así con las siguientes
preguntas o por qué hasta llegar a la causa raíz del problema.
Y una vez encontrada la causa raíz se definió una categorización de estos en base a la metodología
de diagrama de pescado (Ishikawa) para hacer un análisis de tendencia de las causas raíces más
comunes del proceso como pare de las métricas del modelo (ver figura 27). Esto sería un detonante
para la mejora de los procesos.
63
Figura 27: Diagrama de causa y efecto o de pescado (Ishikawa, Fuente: Torres Paola, 2017.
La siguiente sección de la herramienta y no menos importante es el plan de acción (ver figura 25)
el cual tiene el propósito de identificar los siguientes tipos de acciones para mitigar y eliminar los
defectos en los servicios de la empresa:
Acción correctiva: acción que se toma para la corrección inmediata del problema
eliminando la causa del defecto.
Acción de contención: Acción que se define para contener el problema o defecto que
impacte otro tipo de clientes dentro del mismo proceso.
Acción preventiva: Acción que se implementa para eliminar la posibilidad de que el
problema impacte otro tipo de procesos
Acción de comunicación: Acción para notificar a los posibles impactados de cualquier
cambio dentro de los estándares del proceso.
Acción de mejora: Acción o medida que por medio de las acciones correctivas o
preventivas pueden identificar áreas de oportunidad para los procesos por medio de
controles o mejoras que ayuden a optimizar los mismos.
64
Figura 28: Plan de acción de la herramienta de ACR, Fuente: Torres Paola, 2017.
El plan de acción cuenta con campos fáciles de usar para los usuarios, como se comentó con
anterioridad la herramienta guiara al usuario a realizar este tipo de análisis de manera más sencilla.
Se puede observar en la figura que existe una opción para asignar tipo de acción, descripción de la
misma, estado, fecha límite para completarla, así como el responsable de llevarla a cabo e
implementarla en el proceso.
Para asegurar la calidad del análisis es importante agregar filtros de aprobación que como se
mencionó anteriormente la función de calidad de procesos o excelencia operacional cuenta con
focales asignados para cada equipo de la empresa que ayudan a dar soporte en la mejora de sus
procesos. La aprobación del análisis es parte del rol y responsabilidad de estos líderes de excelencia
operacional, así como la asignación de un plan de acción efectivo.
Se propone que la implementación de las acciones pase a ser parte de la responsabilidad del líder
o analista del equipo que segura la efectividad de las mismas midiendo que el problema o defecto
no vuelva a repetirse al menos en el mismo proceso. Ambos niveles de aprobación se configurarán
en la herramienta para asegurar un ACR robusto (ver figura 29).
Figura 29: Niveles de aprobación de la herramienta de ACR, Fuente: Torres Paola, 2017.
65
Parte de los requerimientos de esta sección fue la implementación de las notificaciones automáticas
de aprobaciones que haga de manera más efectiva el seguimiento de estos análisis de causa raíz
que no solo despierte un sentido de urgencia en los usuarios, sino que también en los diferentes
niveles de liderazgo de los equipos para hacerlos responsables de los problemas y defectos del día
a día y como estos pueden dar oportunidades de mejora a los procesos de la empresa.
Una vez compartidos la lista de requerimientos y el bosquejo con el equipo técnico del sistema se
midió la factibilidad de cada uno de ellos y para lo que no era factible se optó por otras opciones
que tuvieran la misma funcionalidad sin arruinar el objetivo principal de la herramienta de análisis
de causa raíz (ACR). Se agendaron juntas semanales con el equipo técnico para la revisión del
mismo y así tener un seguimiento en tiempo y forma en caso de alguna falla.
66
Reducción de tiempo
45
Tiempo (minutos)
40
35
30
25
20
15
10
5
0
Información del Análisis de
Punto de causa Plan de acción
problema causa raíza
Antes de implementar la herramienta 20 30 40 15
Después de implementar la herramienta 2 10 12 5
Con ayuda del prototipo que el equipo técnico del sistema desarrolló se realizaron pruebas que
ayudaron a medir los minutos que un usuario nuevo tardaba en llenar cada uno de los campos que
la herramienta requiere, con anterioridad esta misma toma de tiempos y análisis se llevaron a cabo
con los métodos antiguos que se utilizaban.
En la gráfica se puede observar en conjunto del tiempo total para llenar la información requerida
del análisis del defecto se logra una reducción del 72%. Anteriormente se tomaban 105 minutos
en llenar este tipo de formatos con el prototipo de la herramienta se logra una reducción hasta 30
minutos para completarlo.
En base a este análisis de datos se pudo observar que el impacto en la reducción del tiempo para
analizar la causa raíz de los problemas y defectos con métodos que se utilizaban y no aportaban
eficiencia a encontrar un plan que mitigara las fallas en los procesos daba como resultado el tiempo
productivo de una persona directa a la operación al mes, esto se ve reflejado directamente en la
métrica de productividad de una de las operaciones de los servicios de la empresa (Ver Figura 31).
67
Figura 31: Análisis de productividad en operadores en los ACR, Fuente: Elaboración propia.
En la figura se puede observar que es notable la disminución del tiempo antes y después de la
herramienta, esto se debe a que el tiempo que invertían los usuarios en llenar información en cierta
parte innecesaria para el análisis y que no agregaba ningún valor para facilitar la asignación de
acciones que ayuden la prevención o re ocurrencia del problema. Con ayuda del equipo global se
les solicito que participarán en las sesiones de solución de problemas para la toma de estos tiempos
y pudieron ver que en las juntas el equipo se tomaba hasta dos horas en llenar un solo análisis para
la documentación de las acciones. Normalmente en estos equipos existía mayor re ocurrencia de
los mismos defectos en los servicios por lo tanto la inversión de tiempo en este tipo de juntas era
mayor. Esto es aproximadamente el tiempo productivo de 4 personas de operación enfocado en
corregir y tapar los problemas, pero no atacando la causa raíz de estos defectos.
Uno de los objetivos principales del proyecto es reducir ese tiempo el cual es llamado sentido de
urgencia, así como aumentar le efectividad de los análisis reduciendo el tiempo que invierten
llenando esta información sin valor agregado al proceso o método de solución de problemas.
Se obtuvo muy buena respuesta de los líderes en la socialización de la propuesta y el equipo global
fue de gran ayuda debido a las múltiples funciones involucradas en el proyecto. Ya una vez
presentados este tipo de análisis con los líderes de región se empezó a trabajar con el equipo técnico
para desarrollar los guiones de prueba. En caso de alguna apelación a la propuesta se integró al
estándar dependiendo de la factibilidad del requerimiento con la previa aprobación del líder de
región.
68
3.9.4. Proceso de aprobación
Después de completar la revisión con los líderes en las diferentes regiones se llevó a cabo un
proceso de aprobación para poder integrar el modelo al sistema de producción (CRM) de la
empresa de recursos humanos. El documento de requerimientos del negocio1 para integrar
cualquier tipo de módulos o configuraciones en el sistema es fundamental que incluya las
especificaciones técnicas de la herramienta a integrar así como las aprobaciones de cada uno de
los ejecutivos del equipo de liderazgo en la organización.
Se presentó la propuesta y el documento directamente al equipo de liderazgo y se obtuvo su
aprobación después de socializar la propuesta con sus líderes, con la retroalimentación que
previamente se integró de la voz del cliente de los usuarios de sus funciones a nivel global. En
base a esto el equipo técnico asigno un focal como parte del equipo global que empezó a verificar
el piloto desarrollado con anterioridad en el sistema para desarrollar las pruebas en el sistema de
acuerdo a los requerimientos.
Con ayuda del equipo global se desarrolló el plan de entrenamiento, así como el material para
poder comunicar los cambios a todos los usuarios y procesos impactados en el proyecto.
1
El documento de requerimientos (BRD) es confidencial para la empresa sin embargo integra la
información presentara con anterioridad en la lista de requerimientos y el bosquejo de la herramienta
69
Ellos llevaron a cabo la comunicación y guía con sus equipos del nuevo uso de la herramienta para
que en base a casos reales ellos pudieran distinguir el uso de la misma en sus operaciones.
Como se puede ver en la gráfica se llevó a cabo un monitoreo de las personas para poder completar
al menos en un 95% la comunicación a todos los usuarios. Esto es un requerimiento del sistema
de operaciones como parte de la certificación en el elemento de Solución de Problemas (RPS) del
sistema operativo. El requerimiento mínimo es de 90% el cual se logró superar con ayuda del
equipo global.
71
Capítulo 4:
Presentación de resultados y
beneficios para la empresa
72
4. Presentación de resultados y beneficios para la empresa
El detalle de cada uno de los resultados se puede encontrar en las siguientes figuras, como se puede
ver en la tabla 5 se puede ver el resultado final de cada uno de los análisis de causa raíz una vez
implementada la herramienta en el sistema. Una de las métricas que fue parte de la implementación
del modelo fue el sentido de urgencia donde la diferencia fue notable con los usuarios ya que se
redujo el tiempo en el que estaban reportando los defectos y haciendo sus análisis de la causa, así
como la asignación de acciones de 10 a 3 días en promedio. Otro impacto significante de la
herramienta fue el tiempo ciclo total ya una vez implementadas las acciones el cual se redujo de
68 a 16 días en promedio.
73
Tabla 5- Total de análisis de causa raíz y medición del tiempo de los resultados
Sentido de Tiempo
Total Total % Total de Rechazados urgencia Objetivo
ciclo total
Equipos sentido de
(días
ACR abiertos abiertos rechazos (%) (días urgencia
promedio)
promedio)
México 70 1 1% 4 6% 4 3 22
India 50 5 10% 6 16% 8 3 35
E.U.A 23 0 0% 2 9% 5 3 15
Sudamérica 20 0 0% 3 15% 5 3 6
Otros
Equipos 20 8 40% 0 0% 3 3 8
Praga 15 5 33% 4 27% 4 3 20
China 5 1 20% 0 0% 2 3 5
Canadá 4 0 0% 2 10% 5 3 18
Fuente: Elaboración propia.
Como se mencionó en los resultados específicos parte de los objetivos principales era reducción
los análisis de causa raíz, en la siguiente grafica (ver figura 34) se puede ver el total de estos
análisis una vez implementado el modelo se pudo lograr una reducción de:
51 ACR a 27 por mes
30 ACR a 4 por mes
6
50 5 5
5
40
4
30
3
20
2
1 1
10 1
0 0 0
0 0
Mexico India E.U.A Sudamerica Otros Praga China Canada
Equipos
74
El impacto en el decremento de los análisis de causa o ACR es fundamental ya que con esto se
puede concluir que los análisis han sido efectivos y han ido impactando a reducir al re ocurrencia
de los mismos. Otra parte muy importantes la calidad de los análisis se ha visto beneficiada ya que
el número de rechazos del total de los ACR ha disminuido notablemente debido a que con ayuda
de la calibración de los auditores de calidad los análisis son hechos con la calidad requerida a la
primera vez de acuerdo a las reglas y guías que ayudan a los usuarios a desarrollar su
documentación (ver figura 35).
60
ACR'S RECHAZADOS
5
TOTAL DE ACR'S
50 4 4
4
40 3
3
30 2 2
2
20
10 1
0 0
0 0
Mexico India E.U.A Sudamerica Otros Praga China Canada
Equipos
El resultado de mayor impacto fue en la métrica de calidad con reducción de defectos en cada una
de las regiones como se puede observar en la figura 36 se puede notar una diferencia significativa
de los defectos por región y al mes en comparación del estado anterior donde no existía
metodología y proceso estándar para este tipo de casos. Para las regiones como EMEA se hubo
equipos y áreas donde hubo un incremento debido a que se detectó que no todos los equipos
estaban marcando sus defectos como impacto a la métrica de calidad y por lo tanto anteriormente
no se veía reflejado en los reportes de cumplimiento de esta métrica. En promedio la mejora es
notable en todas las regiones y equipos de la organización.
75
Volumen de los procesos de la empresa
defectos de calidad después de las mejoras
Total
Volumen
Mes de Región ppm
total
defectos
Enero 62486 24 384
Febrero 59564 11 185
Marzo 69094 15 217
Abril 70797 21 Américas 297
Mayo 64333 11 171
Junio 73584 19 258
Julio 60073 15 250
Enero 38675 31 802
Febrero 34579 19 549
Marzo 42488 15 353
Abril 53093 20 APAC 377
Mayo 6356 9 143
Junio 71761 12 167
Julio 67985 13 191
Enero 27827 18 647
Febrero 32697 20 612
Marzo 31993 9 281
Abril 35779 12 EMEA 335
Mayo 39623 15 379
Junio 40975 22 537
Julio 33369 18 539
Figura 36: Total de defectos después de las mejoras, Fuente: Fuente: tomada de la base de datos del
sistema operativo de la empresa, 2017.
76
incremento de la productividad de sus procesos, así como mejorar la satisfacción de sus clientes
por sus entregas a tiempo y con calidad.
Por otra parte, se pudo observar un incremento de los defectos de un 12% para los equipos que se
integraron dentro de este modelo, los cuales no llevaban una medición en forma de sus métricas
de calidad y entregas. Este fue un punto clave de la investigación ya que esto detono la oportunidad
a diferentes elementos del sistema operativo para la medición exacta de la calidad de los procesos
que diera como resultado una mayor satisfacción del cliente.
Logrando este enfoque con los nuevos equipos y haciendo la integración a los requerimientos del
sistema operativo por medio de este elemento se pudo observar un notable cambio en la cultura de
trabajo de estos equipos, ya que no únicamente se estandarizaron las herramientas de análisis de
causa raíz si no que se les otorgo el punto de partida para nuevas oportunidades de mejora y
estandarización de sus procesos actuales.
77
ha incrementado con el tiempo identificando áreas de oportunidad para seguir la misma estrategia
a nivel global en otros elementos del sistema operativo.
Figura 38: Proceso estándar del modelo global de solución de problemas, Fuente: Torres Paola, 2017.
78
4.5. Resistencia al cambio:
Con los equipos que manejaban alguna herramienta o método para el análisis de sus problemas se
enfrentó como obstáculo la resistencia de ciertos líderes a cambiar su método convencional de
análisis de causa raíz. Para lograr convencer a los líderes de las áreas de la estandarización de este
modelo en sus procesos se optó por seguir la estratega de asignar agentes de cambio en cada uno
de los equipos los cuales serían los expertos y focales para el entrenamiento, comunicación y
seguimiento con cada uno de los equipos y países. Esta estrategia ayudo a reducir el número de
quejas o comentarios de inconformidad que se recibían a lo largo del proyecto.
En general el desarrollo e implementación de este proyecto fue un reto desde su planeación, sin
embargo, con apoyo del equipo de liderazgo y el patrocinador del proyecto se pudieron llevar a
cabo la mayoría de las actividades planeadas para poder lograr el éxito de sus resultados en base a
los objetivos especificados.
Siendo este el primer elemento implementado y estandarizado a nivel global ayudo a la empresa
mejorar sus métricas principales como es la calidad y satisfacción del cliente y también a
identificar oportunidades de mejora para diferentes elementos de la organización que optimizarían
los recursos y procesos del día a día.
79
Conclusiones
El modelo de Solución de Rápida de Problemas (RPS) desarrollado en este proyecto de tesis tuvo
un gran impacto para la empresa donde se desarrolló, ya que no únicamente se buscaba la
estandarización y alineación global de la metodología y herramienta a utilizar para el análisis de
causa raíz (ACR) de los problemas y defectos que con frecuencia se presentaban en los procesos
de la empresa, sino que también impacto de manera efectiva las métricas más importantes de la
empresa como lo son:
Calidad
Entregas a tiempo
Satisfacción del cliente
Uno de los retos más grandes fue la administración de los cambios, ya que tratándose de una
empresa de servicios es más complejo implementar un modelo con métodos y bases de ramos
manufacturaros. Al inicio del proyecto cuando se presentaron todas las propuestas y el equipo
global contribuyo con sus propias sugerencias donde se querían replicar modelos anteriores que
no mostraban ningún resultado en los defectos de la compañía. Romper el paradigma de los
usuarios de este tipo de herramientas fue un reto que por medio de un plan estratégico de
comunicación y entrenamiento se pudo llevar a cabo de manera efectiva.
Tener un equipo global multidisciplinario ayudo a ver los diferentes puntos de vista y perspectivas
de cada una de las funciones de operaciones, muchas veces únicamente tomamos en cuenta lo que
el estándar dice sin analizar a quien puede impactar y si existe una mejor manera de llevarlo a
cabo. Este equipo fue de mucha ayuda en el desarrollo del modelo, así como en el despliegue de
las comunicaciones y entrenamientos en todos los equipos y regiones de la organización.
La reducción de defectos por medio de la disminución de la re-ocurrencia de los mismos es uno
de los resultados de mayor impacto de este proyecto, ya que por medio de una herramienta que es
amigable para los usuarios el análisis de causa raíz es efectivo ya que enfoca su atención con ayuda
de puntos de validación a identificar mejoras en los procesos y no tener como principal
contribuidor el error humano.
Con las acciones de mejora que los usuarios identifican no solamente estandarizan sus procesos si
no que realizan de manera más sencilla, efectiva y precisa sus operaciones del día a día.
80
ANEXOS
81
Anexo 1: Ejemplo de formato de reporte A3 de Toyota para la solución de no
conformidades (Jiménez, 2013)
82
Anexo 3: Ejemplo aplicado de análisis de causa raíz por medio de 5 por qué
(PROGRESSA, 2016)
83
Referencias
Carry, E & Ryder, W. (2011). Lean Solution/ Six Sigma. Octubre 1, 2017, de Lean solutions Co.
Sitio web: http://www.leansolutions.co/conceptos/qque-es-six-sigma
Fragoso. V. (2011). Sistema de confiabilidad operacional. julio 22, 2017, de Pemex Sitio web:
http://aprendizajevitual.pemex.com/nuevo/guias_pdf/Guia_SCO_Analisis_Causa_Raiz.pdf
Gutiérrez Garza, G. (2000). Justo a Tiempo y Calidad Total, principios y Aplicaciones. México,
D.F.: Ediciones Castillo.
Harrington, H.J. (1987). El costo de la Pobre Calidad. Milwaukee: Mercel Dekker, Inc. ASQC.
Huge, V. (2014). Honeywell The Power of Connected. Agosto 15, 2017, de Honeywell Inc. Sitio
web: https://www.honeywell.com/wordlwide.
Jones, J. (2012). 8 Disciplines. Octubre 16, 2017, de Lean solutions Sitio web:
http://www.leansolutions.co/conceptos/8d
Liker, J.K. & Meier,D . (2005). The Toyota Way. USA: McGraw-Hill.
Mani, S. (2016). Liderazgo: modelo a seguir para todos. septiembre 17, 2017, Sitio web: pot-lid-
infl.blogspot.com/2012/04/dentro-de-cada-lider-existe-una-serie.html
Marshall, B. (2016). Análisis de la causa raíz de los problemas. Noviembre 15, 2017, de Progresa
Lean Sitio web: http://www.progressalean.com/5-porques-analisis-de-la-causa-raiz-de-los-
problemas
84
Naim, M. (2017). Entrenamiento de RPS. julio 8, 2017, de Honeywell Inc. Sitio web:
https://www.honeywell.com/worldwide.
Sandrine, C.S. (2010). 6 Sigma, lean y Kaizen. Septiembre 24, 2017, de Caletec. Sitio web:
http://www.caletec.com/blog/6sigma/metodología-dmaic-si-sigma
Torres, P. (2017). Análisis de ACR. Julio 13, 2017, de Honeywell Inc. Sitio web:
https://www.honeywell.com/worldwide.
Torres, P. (2017). Lista de Verificación para los requerimientos de la herramienta de RPS. Julio
22, 2017, de Honeywell Inc. Sitio web: https://www.honeywell.com/worldwide.
Tracy, B. (11). A3-Root Cause Analysis. Noviembre 14, 2017, de Scrum Inc. Sitio web:
https://www.scruminc.com/a3-root-cause-analysis
Torres, P. (2017). Herramienta ACR. Octubre 8, 2017, de Honeywell Inc. Sitio web:
https://www.honeywell.com/worldwide.
William, R. & Saxer, S. (2015). Sistema operativo de la empresa. julio 25, 2017, de Honeywell
Inc. Sitio web: https://www.honeywell.com/worldwide.
85