Tesis Respuesta Rápida

Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 86

Universidad Autónoma de San Luis Potosí

Facultad de Ingeniería

Centro de Investigación y Estudios de Posgrado

T E S I S:

“Diseño e Implementación del modelo de Solución

Rápida de Problemas (RPS) para una empresa de

servicios administrativos “

Que para obtener el grado de:

Maestría en Planeación Estratégica e Innovación

Presenta:

Ing. Paola Isabel Torres Uribe

Asesor:

M.A. Mónica Méndez Ontiveros

San Luis Potosí, S. L. P. Octubre de 2018


1
UNIVERSIDAD AUTÓNOMA DE SAN LUIS POTOSÍ

FACULTAD DE INGENIERÍA

Área de Investigación y Estudios de Posgrado

Aclaración

El presente trabajo que lleva por título:

“Diseño e Implementación del modelo de Solución Rápida de Problemas


(RPS) para una empresa de servicios administrativos”.

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.

Las referencias e información tomadas directa o indirectamente de otras fuentes se han


definido en el texto como tales y se ha dado el debido crédito a las mismas.

El autor exime a la UASLP de las opiniones vertidas en este documento y asume la


responsabilidad total del mismo.

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

Ing. Paola Isabel Torres Uribe

2
Resumen de Tesis

La presente Tesis plantea el desarrollo de la implementación de un modelo de solución de


problemas en los servicios centralizados de una compañía con presencia global, donde el principal
objetivo es la reducción de las fallas recurrentes en los diferentes procesos de la empresa, parte de
esta justificación la podrán encontrar de manera detallada en el Capítulo 1.
En el capítulo dos se explicarán los conceptos y metodologías de la Manufactura Esbelta y Seis
sigma, así como las herramientas a utilizar por diferentes ramos en la industria automotriz y
aeroespacial con el propósito de integrar este tipo de métodos a los procesos administrativos para
la reducción de los defectos en la empresa
Por medio del uso de diferentes herramientas y conceptos de análisis de problemas para la
asignación de medidas correctivas y preventivas se integrará un modelo que abarque las
necesidades de la empresa en base a las fallas presentadas en sus procesos actuales. El principal
indicador a enfocarse es la calidad de los servicios, que por ende se espera una mejora en los
indicadores de satisfacción de los clientes.
En el capítulo 3 se explica cómo se llevó a cabo la alineación de estas herramientas y el desarrollo
del modelo que utilizó diferentes recursos para integrar esta metodología en los sistemas actuales
de la empresa, así como equipos multifuncionales con presencia global para comunicar a las
diferentes áreas y procesos impactados el uso correcto de este modelo en sus servicios. Se espera
que la comunicación y el despliegue de la información para introducir el modelo en la empresa
globalmente sea procesada para los diferentes rangos y niveles jerárquicos en la empresa, por lo
que fue importante desarrollar habilidades de entrenamiento en miembros del equipo
multifuncional para aclarar cualquier duda o problema que pueda surgir.
Para finalizar se podrán observar de manera cuantitativa y grafica los resultados positivos del
modelo ya una vez implementado en la empresa en los diferentes equipos donde no únicamente se
impactó a la calidad del proceso, sino que también sirvió como modelo para la alineación global
de las herramientas de calidad total en los servicios de la compañía.

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

Capítulo 3: Implementación del modelo de solución de problemas en la empresa…… 34


Implementación del modelo de Solución Rápida de Problemas(RPS) en la
3 empresa……………………………………………………………………. 35
3.1 Hipótesis…………………………………………………………………… 35
3.2 Tipo de hipótesis……………………………………………………………. 35
3.3 Validez…………………………………………………………………….. 36
3.4 Recolección y análisis de datos…………………………………………… 37
3.5 Lista de verificación de requerimientos de solución de problemas………… 37
3.6 Inventario de herramientas de solución de problemas……………………… 39
3.6.1 HRS América………………………………………………………………. 39
3.6.2 HRS APAC……………………………………………………………….. 40
3.6.3 HRS EMEA……………………………………………………………….. 42
3.7 Análisis de datos…………………………………………………………… 42
3.7.1 Histórico análisis de causas raíz……………………………………………. 44
3.7.2 Evaluación del inventario de herramientas……………………………….… 48
3.8 Cuadro metodológico propuesto…………………………………………… 51
3.9 Desarrollo del modelo……………………………………………………… 52
3.9.1 Definición del modelo de solución de problemas…………………………. 52
3.9.1.1 Asignación de equipo global………………………………………………. 52
3.9.1.2 Encuestas de voz del cliente (VOC)………………………………………. 53
Desarrollo de requerimientos de la nueva herramienta de análisis de causa.
3.9.2 61
raíz…………………………………………………………………………...
3.9.2.1 Herramienta de análisis de causa raíz en el sistema………………………… 61
3.9.3 Alineación global…………………………………………………………… 66
3.9.3.1 Revisión del modelo con el equipo de liderazgo…………………………… 66
3.9.4 Proceso de aprobación……………………………………………………… 69
3.9.5 Entrenamiento y administración del cambio………………………………... 69
3.9.6 Comunicación global……………………………………………………….. 70
3.9.7 Implementación del modelo………………………………………………… 70
3.9.7.1 Lanzamiento de la herramienta en el sistema………………………………. 70
5
3.9.7.2 Comunicación global de estandarización…………………………………… 71
3.9.7.3 Esquema de implementación……………………………………………….. 71
Capítulo 4: Presentación de resultados y beneficios para la empresa…………………… 72
4 Presentación de resultados y beneficios para la empresa…………………… 73
4.1 Resultado final……………………………………………………………… 73
4.2 Resultados específicos……………………………………………………… 73
4.3 Obstáculos y lecciones aprendidas………………………………………….. 78
4.4 Reto cultural………………………………………………………………… 78
4.5 Resistencia al cambio……………………………………………………….. 79
4.6 Niveles de aprobación………………………………………………………. 79
Conclusiones……………………………………………………………………..…………. 80
Anexos……………………………………………………………………………………… 81
Referencias…………………………………………………………………………………. 84

6
Sumario de Tablas

Tabla 1 Métricas del sistema operativo de administración……………………………….. 13

Tabla 2 Lista de verificación de requerimientos para la herramienta del modelo RPS…... 38

Tabla 3 Análisis inicial de datos de ACR de cada región………………………………… 45

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

Figura 1 Presencia global de la empresa…………………………………………………... 11

Figura 2 Ubicación global de los sitios del corporativo…………………………………… 11

Figura 3 Proceso administrativo de la empresa …………………………………………… 12

Figura 4 Pirámide ‘4P’ del modelo Toyota………………………………………………... 21

Figura 5 Nivel de sigma y defectos por millón……………………………………………. 23

Figura 6 Ciclo PDCA relacionado a las 8 disciplinas en la solución de problemas……….. 27

Figura 7 Estructura del sistema de Solución Rápida de Problemas(RPS)………………… 31

Figura 8 Herramientas actuales para solución de problemas……………………………… 39

Figura 9 Formato estándar de la región para análisis de causa raíz de E.U.A…………….. 41

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

Figura 12 Análisis estadístico total ACR contra abiertos…………………………………… 46

Figura 13 Total ACR vs total de rechazos globales………………………………………… 47

Figura 14 Tiempo promedio de "sentido de urgencia”……………………………………… 47

Figura 15 Tiempo ciclo total (días promedio)………………………………………………. 48

7
Figura 16 Problema y punto de causa………………………………………………………. 50

Figura 17 Modelo de Solución Rápida de Problemas (RPS)………………………………. 51

Equipo global multifuncional del modelo de Solución Rápida de Problemas


Figura 18 (RPS)…………………………………………………………………………….. 53
Figura 19 Encuesta de voz del cliente-pregunta 1 y resultados……………………………. 55

Figura 20 Encuesta de voz del cliente-pregunta 2 y resultados…………………………….. 56

Figura 21 Encuesta de voz del cliente-pregunta 3 y resultados……………………………. 57

Figura 22 Encuesta de voz del cliente-pregunta 4 y resultados…………………………..... 58

Figura 23 Encuesta de voz del cliente-pregunta 5 y resultados…………………………..... 59

Figura 24 Encuesta de voz del cliente-pregunta 6 y resultados……………………………. 60

Figura 25 Información del problema y punto de causa……………………………………... 62

Figura 26 Análisis de Causa Raíz (ACR)…………………………………………………… 63

Figura 27 Diagrama de causa y efecto o de pescado (Ishikawa)……………………………. 64

Figura 28 Plan de acción de la herramienta de ACR………………………………………. 65

Figura 29 Niveles de aprobación de la herramienta de ACR……………………………….. 65

Figura 30 Análisis de reducción de tiempo de la herramienta de ACR…………………….. 67

Figura 31 Análisis de productividad en operadores en los ACR…………………………… 68

Figura 32 Lista de registro de entrenamiento global………………………………………... 70

Esquema de implementación del modelo de Solución Rápida de Problemas


Figura 33 (RPS)……………………………………………………………………………... 71
Figura 34 Total ACR vs ACR abiertos……………………………………………………. 74

Figura 35 Total de ACR vs rechazados…………………………………………………....... 75

Figura 36 Total de defectos después de las mejoras……………………………………....... 76

Figura 37 Grafica P de proporción total de defectos……………………………………...... 77

Figura 38 Proceso estándar del modelo global de solución de problemas………………….. 78

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).

Figura 1: Presencia global de la empresa, Fuente:Honeywell, 2018.

Estos sitios corporativos se encuentran estratégicamente ubicados en las diferentes regiones como
se muestra en la figura 2.

Figura 2: Ubicación global de los sitios de corporativo, Fuente:Honeywell, 2018.

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

Figura 3: Proceso administrativo de la empresa, Fuente: Elaboración propia.


Como se muestra en la figura 3 cada proceso funciona en base a la solicitud recibida de los
empleados que necesitan soporte con la transacción de alguno de estos servicios, los equipos y
procesos se dividen en base a las categorías enlistadas anteriormente. Este proyecto se enfoca en
los servicios compartidos de recursos humanos los cuales cuentan con una estrategia diferente a la
solución de problemas, así como su planteamiento y análisis de causas. Actualmente los servicios
cuentan con métricas alineadas a su sistema operativo de administración los cuales son:
12
:
 Entregas a tiempo
 Exactitud de entrega
 Calidad
 Productividad
 Satisfacción del cliente
Cada equipo de procesos o servicios que se proveen cuenta con diferentes procesos los cuales están
obligados a cumplir con el objetivo de las métricas del equipo, cada día se realizan juntas a primera
hora para revisar las métricas del día anterior y si se recibió un reclamo del cliente, defecto o
problema que haya impactado a algún otro proceso o al cliente.
Los equipos miden sus transacciones de acuerdo a las métricas del sistema operativo de
administración descritos en la tabla 1 dónde se puede observar cuál es el objetivo que debe
alcanzarse, la empresa cuenta con un sistema de revisión de métricas para medir su eficiencia y
analizar la tendencia entre los equipos, sin embargo, esta práctica no es compartida a nivel global
y en todos los equipos de la misma empresa. Cada uno de los servicios y proceso deben estar
alineados a las métricas de la organización para basar sus planes estratégicos de acuerdo a las
prioridades del sistema operativo para poder tomar decisiones efectivas para cada uno de los
servicios que se proveen en la empresa de todas las regiones.
Tabla 1: Métricas del sistema operativo de administración:

METRICA UNIDAD DE MEDIDA OBJETIVO

Entregas a tiempo %- Porcentaje 99.97%


Exactitud de entrega %- Porcentaje 99.98%
Calidad ppm (partes por millón) 1630 ppm

Productividad %- Porcentaje 99%


Satisfacción del cliente Puntuación > 8.5
Fuente: tomada de la base de datos del sistema operativo de la empresa, 2017.
Cuando existe un problema o en su caso un reclamo por parte del cliente e impacta a alguna de las
métricas por debajo del objetivo cada uno de los equipos están obligados a desarrollar un análisis
de causa raíz del problema y reportarlo en un formato vía online para el equipo de liderazgo.

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. Planteamiento del problema

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.2.2. Delimitación del problema


El proyecto se desarrolló en una empresa internacional del ramo aeroespacial y tecnologías
avanzadas de seguridad industrial, así como soluciones eléctricas, se enfocó en la empresa de
servicios compartidos de recursos humanos para los equipos a nivel global de las regiones de
América, Asia Pacifico (APAC) y Europa y Medio Este (EMEA). Esto se llevó a cabo en los
niveles de operación o de procesos que proveen servicios en cada una de las regiones del de la
empresa de recursos humanos.
El proyecto se enfocó en la herramienta del modelo de RPS alineada al sistema operativo de la
empresa, la cual está certificada en nivel bronce a nivel global.

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.4. Objetivo general


Estandarizar y alinear la herramienta de Solución Rápida de Problemas (RPS) a nivel global para
todos los servicios compartidos de la empresa de recursos humanos, para el análisis efectivo que
dé como resultado la reducción de defectos y problemas en las métricas de cada uno de los
procesos.

1.5. Objetivos específicos


 Implementar una herramienta estándar de Análisis de Causa Raíz (ACR) en todos los
equipos de servicio a nivel global.
 Alinear la metodología del sistema de solución rápida de problemas con las bases de lean
seis sigma para sectores de manufactura a los servicios administrativos de la empresa.
 Reducir volumen total de 40 ACR por mes a 25 ACR por mes de todos los servicios a nivel
global.
 Reducción de defectos (ppm) en un 15% en los servicios de la empresa.

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.

Una de las limitaciones más comunes en los equipos de la empresa se desarrolla en la


implementación de los proyectos debido al atraso de las actividades de acuerdo a la planeación
inicial del proyecto, existe inestabilidad en la administración de los proyectos y los líderes de
operaciones aceleran el proceso de implementación sin validar los controles o resultados antes de
su lanzamiento. En específico esta es una herramienta que necesita de validación de su madurez
después de haber sido implementada sin embargo los resultados se pueden notar a corto y largo
plazo por lo que el reto de adaptación es posible validando cada resultado.
Las diferentes zonas horarias de cada una de las regiones es una de las grandes limitaciones para
el principal equipo asignado ya que las revisiones semanales pueden atrasar en cierta manera los
entregables en fechas críticas para el proyecto.
Con ayuda de equipos de soporte se pueden manejar este tipo de planes estratégicos de
comunicación y cambios en la organización que requerirán más recursos para el proyecto, así como
niveles de autorización por parte de los líderes de estas áreas.

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.1. Marco teórico


Antecedentes del proyecto
Como parte del sistema de solución rápida de problemas de la empresa, se tiene como antecedente
la implementación previa del mismo en el 2013 la cual desarrolló la herramienta en el sitio de
archivos compartidos de la empresa. Se implementó a nivel global sin embargo se excluyeron
ciertos equipos en el alcance del proyecto que no estaban involucrados con la operación, pero si
eran parte de la empresa de recursos humanos.

Se desarrolló el sistema como requerimiento global de la empresa para la certificación bronce en


el sistema de operaciones de la empresa, sin embargo la implementación de la herramienta para
análisis de causa raíz de los problemas o ACR no se estandarizó para todos los equipos, cada uno
de los equipos desarrolló su propia herramienta con diferentes metodologías y la recurrencia de
problemas y defectos en los equipos era constante, por lo que el uso de las herramientas para este
sistema de solución de problemas no era efectivo y el tiempo que se invertía no agregaba ningún
valor para la operación.

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.

2.3. Definición de conceptos

2.3.1. Lean Manufacturing


Antecedentes
El sistema de manufactura esbelta se ha definido como una filosofía de excelencia de manufactura,
basada en:
 La eliminación planeada de todo tipo de desperdicio
 Mejora continua: Kaizen
 La mejora consistente de productividad y calidad
Los principales objetivos de la manufactura esbelta es implantar una filosofía de mejora continua
que le permita a las compañías reducir sus costos, mejorar los procesos y eliminar los desperdicios
para aumentar la satisfacción de los clientes y mantener el margen de utilidad.
A continuación, se mencionan diferentes metodologías basadas en la filosofía de manufactura
esbelta enfocadas a la solución de problemas como el reporte A3 o las 8 disciplinas.
Beneficios
La manufactura esbelta proporciona a las compañías herramientas para sobrevivir en un mercado
global que exige calidad más alta, entrega más rápida a más bajo precio y en la cantidad requerida.
Específicamente, manufactura esbelta (Gutiérrez Garza, 2000):
 Reduce la cadena de desperdicios dramáticamente
 Reduce el inventario y el espacio en el piso de producción
 Crea sistemas de producción más robustos
 Crea sistemas de entrega de materiales apropiados
 Mejora las distribuciones de planta para aumentar la flexibilidad
La implementación de manufactura esbelta es importante en diferentes áreas, ya que se emplean
diferentes herramientas, por lo que beneficia a la empresa y sus empleados. Algunos de los
beneficios que genera son:
 Reducción de 50% en costos de producció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.

2.3.2. Seis Sigma


Antecedentes
Seis sigma es una metodología de mejora de procesos creada en Motorola por el ingeniero Bill
Smith en la década de los 80, esta metodología está centrada en la reducción de la variabilidad,
consiguiendo reducir o eliminar los defectos o fallos en la entrega de un producto o servicio al
cliente. La meta de seis sigma es llegar a un máximo de 3,4 defectos por millón de eventos u
oportunidades (DPMO), entendiéndose como defecto cualquier evento en que un producto o
servicio no logra cumplir los requisitos del cliente. La variación o sigma (σ) es usada para definir
la desviación estándar de una población, esta mide la variabilidad o dispersión de un conjunto de
datos y se calcula con la desviación estándar.
El nivel sigma corresponde a cuantas desviaciones estándar caben entre los límites de
especificación del proceso. El nivel sigma es una medida de que tan buenos son los procesos y se
relacionan con los defectos por millón de oportunidades como se observa en la figura 5 con
respecto a los niveles de sigma en una gráfica de campana.

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.

 Measure (Medir): ¿Cómo lo estamos haciendo ahora?


o Medir el desempeño actual del proceso.
o Determinar que se va medir.
o Desarrollar y validar el sistema de medición.
o Determinar el desempeño actual del proceso.
 Analyze (Analizar): ¿Qué está mal?
o Analizar y determina la causa raíz de los problemas y o defectos.
o Entender la razón para la variación e identifica las causas potenciales.
o Identificar las oportunidades de mejora en el proceso.
o Desarrollar y probar las hipótesis para la causa raíz de las soluciones.
 Improve (Mejorar): ¿Qué necesito hacer?
o Desarrollar y cuantificar las soluciones potenciales.
o Mejorar y optimizar el proceso.
o Evaluar y seleccionar la solución final.
24
o Verificar la solución final.
o Ganar la aprobación de la solución final.
 Control (Controlar): ¿Cómo garantizo el desempeño?
o Implementar la solución.
o Garantizar que la mejora es mantenida.
o Asegurar que los nuevos problemas son identificados rápidamente.
o Digitalizar siempre que sea posible.
o Estandarizar nuevos requerimientos del proceso o producto.

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).

2.3.4. Las 8 disciplinas (8D)


8D es una metodología sistemática para identificar, corregir y eliminar problemas. 8D significa 8
disciplinas (8 pasos + Disciplina =8D), que permite desarrollar ventajas competitivas al solucionar
rápida y efectivamente los problemas, mantener a los clientes por el buen servicio y la calidad en
los productos que se proveen, disminuir la cantidad de problemas dentro de la organización.
Las ocho disciplinas para la resolución de problemas es un método usado para hacer frente y
resolver problemas. También se conoce de forma más abreviada como 8D, resolución de
problemas 8-D, G8D o global 8D.
El gobierno de los EEUU primero utilizó un proceso parecido al 8D durante la segunda guerra
mundial, refiriéndole como el estándar militar # 1520 (sistema de acción correctiva y disposición
del material no conforme). Ford Motor Company primero documento el método 8D en 1987 en
una resolución de problemas orientada “equipo titulado manual” del curso. Este curso fue escrito
a petición de la alta gerencia de la organización de autogestión Power Train, que estaba frustrada
por tener problemas recurrentes año tras año.
Un problema es la diferencia existente entre una situación deseada (estándar) y una situación actual
(real). Un problema suele ser un asunto del que se espera una rápida y efectiva solución,
generalmente lo que vemos de los problemas son los síntomas, la metodológica permite encontrar
la causa raíz para darle el debido tratamiento. (LEAN SOLUTIONS, 2012)
Un problema es con frecuencia el resultado de múltiples casusas a diferentes niveles, esto significa
que una causa afecta a otra. La causa raíz es la principal visión de esta metodología ya que es el
mal interior, el que causa la cadena de eventos que se generar por el problema.

“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.

2.3.8. Análisis de 5 por qué


La técnica de los 5 por qué es un método basado en realizar preguntas para explorar las relaciones
de causa-efecto que generan un problema en particular Esta técnica se utilizó por primera vez en
Toyota durante la evolución de sus metodologías de fabricación. La estrategia de los 5 por qué
consiste en examinar cualquier problema y realizar la pregunta: “¿Por qué?”, la respuesta al primer
“por qué” va a generar otro “por qué”, la respuesta al segundo “por qué” te pedirá otro y así
sucesivamente, de ahí el nombre de la estrategia 5 por qué. Ya que es simple, se puede adaptar de
forma rápida para que puedas resolver casi cualquier problema, por lo que debemos hacerla nuestra
y aplicarla siempre que sea necesario
Cuando se busca resolver un problema, comienza con el resultado final de la situación que quieres
analizar y trabaja hacia atrás (hacia la raíz), pregunta de manera continua: “¿Por qué?”. Repite una
y otra vez la pregunta hasta que la causa raíz del problema se hace evidente. El objetivo final de
los 5 por qué es determinar la causa raíz de un defecto o problema. Para ver un ejemplo aplicado
revisar el Anexo 3.

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.

2.3.11. Métricas de la empresa


El sistema operativo de la empresa cuenta con métricas establecidas en cada uno de los equipos
sin importar la región. Existe una revisión mensual con el equipo de liderazgo por región y nivel
global de las métricas y el estado de cada una de ellas de acuerdo a los objetivos. Actualmente
los equipos de la empresa para los servicios de recursos humanos cuentan con las siguientes
métricas en base a su Sistema Operativo de Administración (MOR):
 Entregas a tiempo
 Exactitud de entrega
 Calidad
 Productividad
 Satisfacción del cliente.
Cada una de estas métricas son críticas para la organización y la empresa, ya que, tratándose de la
prestación de servicios para los mismos empleados de la empresa internacional, la satisfacción del
cliente es clave para la ventaja competitiva en la que se ha posicionado la empresa hasta la fecha.

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.

3.2. Tipo de Hipótesis

Correlacional: existe la relación de la variación entre las variables de investigación.

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

En base al cuadro de construcción de instrumentos se recolectaron los datos para la construcción


del cuadro metodológico y para la definición del nuevo modelo de solución rápida de problemas
es fundamental realizar un inventario de las herramientas que utilizan por región:
 HRS América: Servicios RH de América
 HRS APAC: Servicios RH de Asia Pacifico
 HRS EMEA: Servicios RH de Europa, Medio Este y África
En la recolección de datos se le identifica a cada región por las siglas mostradas en la lista anterior.
Se descargó un reporte global de los casos para analizar el volumen de los mismos y sus análisis
hechos hasta el momento para tener un punto de partida y poder tomar una decisión para cumplir
los objetivos. Como primera instancia se analizaron las herramientas y metodologías de la primera
región a continuación.

3.5. Lista de verificación de requerimientos de solución de problemas

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

3.6.1. HRS América


En la región de América se cuentan con 14 equipos de operación que son parte de 3 funciones o
ramos diferentes de acuerdo a su especialidad y 5 equipos de soporte de los cuales únicamente 11
equipos en total documentan sus análisis de causa raíz (ACR) en un repositorio web local de la
compañía.
Actualmente en este repositorio web que almacena la documentación, registros, material de
entrenamiento y ayudas visuales del sistema operativo de la empresa (HOS) se encuentran 3
diferentes herramientas de solución de problemas para los ACR y diferente metodología entre las
mismas. Algunos de los métodos que se utilizan para las herramientas de Análisis de Causa Raíz
(ACR) en el repositorio web (figura 8) son los siguientes:
 Análisis de secuencia de eventos
 Punto de causa (3W)
 Múltiples análisis de 5 por qué (5 Why)
 Ishikawa (6M)
 Plan de acción (3 tipos de acciones)

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.

3.6.2. HRS APAC


En la región de APAC se cuentan con 8 equipos de operación que son parte de 2 funciones
diferentes de acuerdo a su especialidad y 4 equipos de soporte de los cuales todos los equipos
documentan sus análisis de causa raíz (ACR) en un repositorio web local de la compañía. Este es
compartido con la región anterior de América, pero la metodología es diferente.
Actualmente en este repositorio web que almacena la información del sistema operativo de la
empresa (HOS) se encuentran 1a herramienta estándar de solución de problemas para la
documentación de los Análisis de Causa Raíz (ACR) (ver figura 9). El método estándar que utiliza
esta región se basa en las siguientes herramientas:
 Punto de causa (5W+1H)
 Análisis de Causa Raíz (ACR)
 Asignación de acciones correctivas
 Secuencia de eventos e impacto de problemas

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

Where did the Who identified


HRS / Non HRS error? Impact Country Entity error occur ? the error Error Date

Expense Approval Employee( whose


notfication sent to the EID incorrectly
Incorrectly designated updated as HRG
HRS HRG IND ACS PeopleSoft for an employee) 7/19/16 9:10 PM

Any Immediate Action (Correction) Correct HRG EID updated for the employee.

Verified all the employees in load file. No Issues


Prevent other potential defects that could have occurred (Containment) found with other records.

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.

3.7. Análisis de datos


Como parte de la recolección de datos y análisis de los mismos se sugirieron las siguientes
herramientas para tener mayor visibilidad para la construcción del cuadro metodológico:
 Registro estadístico
 Registros de defectos en métricas y reportes del CRM de la empresa
En el sistema de CRM (Customer Relationship Management) de la empresa que registra cada uno
de los casos que se procesan por los equipos de operaciones, así como el análisis las interacciones
con el cliente en los cuales basan sus métricas del día a día como es:
 Calidad
 Entregas a tiempo
 Inventario
 Satisfacción del Cliente
Uno de los objetivos de este proyecto es la reducción de defectos en las operaciones de los procesos
y para fines de investigación se hizo el siguiente análisis en la métrica de calidad, por lo cual se
descargó un reporte de este sistema para analizar los defectos totales a nivel global en todos los
equipos de operación (ver figura 10). Este es el registro de defectos que actualmente se registra en
el sistema y de los cuales se tienen visibilidad, existe un modo potencial de falla donde puede
haber procesos que no registren los defectos o re trabajos en el sistema, y esto es fundamental para
la medición de la calidad de los mismos.
42
Volumen de los procesos de la empresa
defectos de calidad antes de las mejoras
Volumen Total de
Mes Región ppm
total defectos
Enero 57857 84 1469
Febrero 55152 40 725
Marzo 63976 52 813
Abril 65553 76 Américas 1159
Mayo 59568 38 638
Junio 68133 69 1013
Julio 55623 52 935
Enero 35810 110 3072
Febrero 32018 68 2124
Marzo 39341 54 1373
Abril 49160 72 APAC 1465
Mayo 58479 32 547
Junio 66445 43 647
Julio 62949 45 715
Enero 25766 15 582
Febrero 30275 28 925
Marzo 29623 23 776
Abril 33129 30 EMEA 906
Mayo 36688 25 681
Junio 37940 17 448
Julio 30897 32 1036
Figura 10: Registro mensual del volumen total y el total de defectos en cada uno de las regiones, para su
medición en ppm (partes por millón), Fuente: tomada de la base de datos del sistema operativo de la
empresa, 2016.

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.

3.7.1. Histórico análisis de causas raíz


Los datos históricos que justifican la investigación actual se pueden observar de acuerdo a la
métrica de operaciones de este sistema de Solución rápida de problemas, parte de los indicadores
actuales son los siguientes, cada una de las métricas enlistadas se encuentran graficadas en las
Ilustraciones a continuación:
 Total ACR vs ACR abiertos (figura 12).
 Total de ACR vs rechazados (figura 13).
 Tiempo promedio de sentido de urgencia (figura 14).
 Tiempo ciclo total de los ACR (figura 15).

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.

Sentido de Objetivo Tiempo


Total Total Total de urgencia sentido ciclo total
Equipos
ACR/mes abiertos/mes rechazos/mes (días de (días
promedio) urgencia promedio)
México 142 82 11 20 3 76
India 99 45 35 18 3 160
E.U.A 44 32 8 15 3 25
Sudamérica 35 18 2 8 3 15
Canadá 20 18 27 3 3 120
Praga 12 8 10 2 3 34
China 3 1 4 2 3 48
Fuente: tomada de la base de datos del sistema operativo de la empresa, 2017.

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.

Figura 14: Tiempo promedio de "sentido de urgencia”, Fuente: Elaboración propia.

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.

Tiempo ciclo total de los ACR


180
160
160
140
120
120
100
76 Tiempo Ciclo Total
80 (dias promedio)
60 48
40 34
25
15
20
0
Praga India E.U.A Mexico Sudamerica Canada China

Figura 15: Tiempo ciclo total (días promedio), Fuente: Elaboración propia.

3.7.2. Evaluación del inventario de herramientas


De acuerdo a la información recolectada en las diferentes regiones de América, APAC y EMEA
se puso observar que existen diferentes herramientas de análisis de causa raíz que se enfocan en el
análisis del problema, pero no en mitigar o eliminar la falla de los mismos para prevenir la
recurrencia. Todas las herramientas cuentan con diferentes usos de los siguientes puntos a evaluar
dentro de la herramienta de ACR (Análisis de Causa Raíz):
 Análisis de secuencia de eventos
 Punto de causa
 Análisis de Causa Raíz (ACR)

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:

3.9.1. Definición del modelo de solución de problemas:

3.9.1.1. Asignación de equipo global:


Con el apoyo del patrocinador del proyecto se llevó a cabo la asignación de puntos de contacto
para tener un equipo global multidisciplinario. En las operaciones de la empresa existen diferentes
funciones de servicios que se enfocan a áreas, regiones o procesos especiales dependiendo de la
función. Para la alineación global y estandarización del modelo se optó por seguir esta estrategia
que ayudara a hacer de manera más sencilla la implementación del modelo, no únicamente a las
áreas y regiones que ya contaban con un método de solución de problemas si no también se integró
a las áreas de soporte y regiones que nunca habían utilizado ninguna de las herramientas de análisis
de causa raíz (ver figura 18).

52
Figura 18: Equipo global multifuncional del modelo de Solución Rápida de Problemas (RPS), Fuente:
Elaboración propia.

En el organigrama se puede ver el equipo global multifuncional para el modelo de solución de


problemas y cada una de las funciones donde ellos proveen servicio de acuerdo a los procesos de
la organización. Este es un punto clave del proyecto que fortalece la eficiencia del despliegue
global del modelo dando como resultado una administración de los cambios más efectiva y menor
riesgo en la resistencia al cambio por parte de los equipos y usuarios actuales.

3.9.1.2. Encuestas de voz del cliente (VOC):


Para poder tomar en consideración cada uno de los requerimientos de las operaciones que
actualmente utilizan este tipo de métodos para los análisis de causa raíz se optó por la estrategia
de desarrollar encuestas que fueron distribuidas a diferentes roles en la empresa como:
 Líderes regionales
 Supervisores
 Líderes de equipo
 Analistas
 Especialistas de operación
 Áreas de soporte
 Equipo técnico
 Auditores de calidad
Las encuestas electrónicas incluían las preguntas enlistas en la tabla, así como los países donde
sea aplicaron y se obtuvo respuesta por parte de los usuarios (ver tabla 4). Es importante resaltar
que no se tomaron en cuenta únicamente los países de la investigación inicial del proyecto los
cuales utilizaban los métodos actuales de análisis de causa raíz, sino que también se incluyeron

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

País del equipo

Sudamérica

Alemania
Inglaterra
México

Canadá
E.U.A.

China

Brasil
India

Praga
Pregunta de la encuesta

1.- ¿Existe un entrenamiento útil y entendible


x x x x x x
para el sistema de solución de problemas?
2. ¿Es efectivo el sistema de solución de
x x x x x x x
problemas para reducir los defectos en tu equipo?
3.- ¿Son efectivas y útiles las herramientas que
utilizan para analizar la causa raíz de los x x x x x x
problemas?
4.- ¿Sabes cuando desarrollar un análisis de
x x x x x x x x x
causa raíz?
5.- ¿Cuándo se analiza un problema el enfoque es
x x x x x x x x x x
directamente al error humano o al proceso?
6.-¿Cuándo se analizan las causas de los
x x x x x x x x x x
problemas las acciones eliminan el impacto?

Fuente: Elaboración propia.

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.

3.9.2.1. Herramienta de análisis de causa raíz en el sistema.


Como primer alcance del proyecto se planeaba la estandarización de la herramienta de análisis de
causa raíz en un repositorio web de la empresa donde tuvieran acceso todos los usuarios. Sin
embargo, el mantenimiento del mismo era alto, así como extremadamente manual. No solo se
quería facilitar el uso de esta herramienta a los usuarios cuando la utilizaran, sino que también para
el equipo o los focales que le darían seguimiento en caso de cualquier problema técnico o
actualización. Desarrollarla por este medio no solo tomaría esfuerzo y tiempo antes de su
implementación si no que después de la misma se seguiría trabajando en ello, por lo que se optó
por presentar esta misma propuesta a los líderes para integrarla al sistema de gestión sobre la
relación con los consumidores (CRM) de la empresa, este sistema ayuda a administrar los casos
que se reciben de los clientes para su procesamiento, como un sistema de Planeamiento de recursos
Empresariales (ERP) de una planta de manufactura.
Integrar la herramienta al sistema de planeación ayudaría a realizar de manera más sencilla el
análisis de los defectos que se ligarían directamente a ellos y así optimizar el tiempo y analizar la
relación entre los mismos. Para poder llevar a cabo esta integración se requirió construir un
documento enlistado de los requerimientos para el equipo técnico que administra el sistema de la
empresa ya alineados con las sugerencias factibles de los usuarios, donde se realizó un bosquejo
del modelo que muestra la funcionalidad de cada una de las secciones de la herramienta de análisis
de causa raíz (ACR) estándar que se utilizaría para el modelo (ver figuras 25-29).

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.

3.9.3. Alineación global


Con ayuda del equipo global multifuncional para llevar a cabo la alineación del modelo ya una
vez definido el estándar en base a los requerimientos re realizo un plan de comunicación el cual
incluía una comunicación previa dirigida a los líderes de cada una de las funciones y regiones para
el futuro cambio. Esto ayudaría a que la administración de los cambios en los equipos que ya
utilizaban algún tipo de método disminuyera el riesgo de posible resistencia al nuevo modelo.

3.9.3.1. Revisión del modelo con el equipo de liderazgo:


Se presentó al equipo de liderazgo el proceso estándar a seguir para el modelo de solución de
problemas, así como la herramienta de análisis de causa raíz. De igual manera se hizo una revisión
del impacto y beneficio que tendría para la compañía integrar esta herramienta al sistema de
administración de casos (CRM) de la empresa (ver figura 27). El principal objetivo de esta
integración es hacer más sencilla la manera de llevar a cabo los análisis de causa raíz (ACR) para
los usuarios y más efectivo sin dedicar tiempo innecesario a llenar información que no agrega valor
al análisis y enfocándose en la definición del punto de causa correcto. Es fundamental mencionar
el enfoque hacia el estudio de la causa raíz del problema que mitiguen las fallas del mismo por
medio de diferentes facilidades que el sistema otorgaría automatizando campos de la herramienta.

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

Figura 30: Análisis de reducción de tiempo de ACR, Fuente: Elaboración propia.

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.

3.9.5. Entrenamiento y administración del cambio


Se realizó un plan de entrenamiento donde se categorizó el tipo de material dependiendo del rol y
responsabilidad de la persona en el proceso.
Se hizo una calibración de los auditores que se necesitan en el proceso de solución de problemas
para poder mantener la efectividad de las acciones al momento de realizar los análisis de causa
raíz de los defectos. Esta es una parte critica de la calidad del análisis para que las causas raíces de
los problemas se enfoquen al proceso y no al error humano y que las acciones de los problemas
mitiguen o eliminen las fallas de los procesos.
La estrategia que se siguió fue diferente para asegurar la efectividad del entrenamiento, así como
el aseguramiento de que las lecciones aprendidas fueran útiles para los usuarios. En vez de dar un
entrenamiento global y directo a los usuarios se solicitó ayuda del equipo global multifuncional
y se asignaron personas por equipo o ‘champions’ para poder entrenarlos como instructores y
expertos del nuevo proceso de solución de problemas.

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.

Lista de registro de entrenamiento


100%
100%
95% 90%
90% 85%
85%
80%
75%
Americas APAC EMEA

Figura 32: Lista de registro de entrenamiento global, Fuente: Elaboración propia.

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.

3.9.6. Comunicación global


Una vez terminado el entrenamiento de ‘entrena al instructor’ se comenzó por desplegar la
información en todos los equipos y líderes para tener una transición efectiva del proceso en todas
las regiones. En base un plan estratégico se llevó a cabo una comunicación previa antes de los
entrenamientos a los líderes de cada región para que los cambios no impactarán de manera
significativa a las operaciones de cada una de las funciones. El despliegue de la herramienta fue
más sencillo debido a estas comunicaciones previas.

3.9.7. Implementación del modelo

3.9.7.1. Lanzamiento de la herramienta en el sistema


Como se comentó con anterioridad con ayuda del equipo técnico en paralelo al plan de
entrenamiento se comenzó a desarrollar el nuevo modelo en el sistema de la empresa para poder
integrar de manera más robusta los defectos a los análisis de causa raíz y a su vez a las acciones.
Ya una vez que todas las pruebas fueron pasadas en el sistema como aceptables se integró la
70
herramienta a producción en el sistema para que de acuerdo a la fecha de lanzamiento establecida
todos los usuarios con acceso al mismo pudieran ver en sus ventanas de operación el nuevo módulo
del modelo de solución rápida de problemas.

3.9.7.2. Comunicación global de estandarización:


Una vez disponible la herramienta en el sistema de la empresa con ayuda del patrocinador del
proyecto se mandó un comunicado oficial de lanzamiento del nuevo modelo de solución de
problemas a todas las funciones de la organización incluyendo cada uno de los usuarios, así como
las áreas de soporte que no habían sido parte de esta metodología con anterioridad.

3.9.7.3. Esquema de implementación


En el siguiente esquema se puede ver cada una de las actividades y su estado de ejecución o
planeación dependiendo de las fechas de desarrollo del plan inicial (ver figura 33).
Cada una de ellas se explicó a detalle en la sección anterior, la presentación de los resultados y
entregables se dará en el siguiente avance del proyecto para poder tener más detalle y visibilidad
de las mismas actividades para el modelo de solución de problemas.

Figura 33: Esquema de implementación del modelo de Solución Rápida de Problemas(RPS),


Fuente: Elaboración propia.

71
Capítulo 4:
Presentación de resultados y
beneficios para la empresa

72
4. Presentación de resultados y beneficios para la empresa

4.1. Resultado final


De acuerdo a las actividades presentadas en la sección anterior como parte del esquema de
implementación se logró la estandarización global del modelo de Solución Rápida de Problemas
(RPS) a lo largo de todos los equipos y funciones de la organización donde por medio de una
herramienta de análisis de causa raíz que se integró al sistema se obtuvo como resultado la
reducción de defectos que se ven reflejados en la métrica de calidad y satisfacción del cliente.

4.2. Resultados específicos


I. Implementación de la herramienta estándar de análisis de causa raíz (ACR) en el
sistema de la empresa para todos los equipos y funciones de la organización a nivel
global.
II. Estandarización de la metodología y proceso del modelo de solución rápida de
problemas en cada uno de los procesos de los servicios administrativos de la
empresa.
III. Se redujo el volumen total de los Análisis de Causa Raíz (ACR) de 51 a 27 por mes
de todos los servicios a nivel global.
IV. Se redujeron los defectos (ppm) en un 65% en los servicios de 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

Total ACR vs ACR abiertos


80 9
8
70 8

TOTAL DE ACR ABIERTOS


7
60
TOTAL DE ACR

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

Figura 34: Total ACR vs ACR abiertos, Fuente: Elaboración propia.

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).

Total de ACR’s vs rechazados


80 7
6
70 6

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

Figura 35: Total de ACR vs rechazados, Fuente: Elaboración propia

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.

En la figura 37 la gráfica P muestra la proporción de estos defectos en comparación del volumen


para cada región donde la estabilidad del proceso es cada vez más estable estadísticamente por los
controles identificados en los análisis de casusa raíz que se llevaron a cabo una vez implementado
el modelo de Solución Rápida de Problemas. Los análisis muestran acciones de mejora y controles
efectivos que mitigan y eliminan la re-ocurrencia de los mismos defectos y problemas en los
diferentes procesos de servicios de la empresa. Esto es una ventaja competitiva para la empresa ya
que refuerza y mantiene su calidad atreves de este tipo de herramientas.
La reducción total de los defectos como se muestra en los resultaos específicos fue de un 65% de
los procesos relacionados a los equipos donde se tomaron los datos iniciales que se integraron en
el análisis de la investigación. Esto es un impacto alto para cada uno de los equipos y general para
la empresa ya que a partir de la implementación de este modelo concentrará sus esfuerzos en el

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.

Figura 37: Grafica P de proporción total de defectos, Fuente: Elaboración propia.

El principal resultado y entregable del modelo de solución de problemas es la estandarización del


proceso a seguir para todos los equipos y funciones de la organización (ver figura 38). El
seguimiento y apego al estándar por parte de los usuarios ha tenido un excelente cumplimiento que
ha llegado a crear un compromiso no únicamente en el equipo multifuncional, sino que también
en los dueños del proceso que siguen el mismo cuando se les solicita. La cultura de mejora continua

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.

4.3. Obstáculos y lecciones aprendidas


Para poder llevar a cabo la implementación del modelo se enfrentaron diferentes obstáculos que
hicieron del proyecto un reto para lograr los objetivos establecidos, a continuación, se pueden
observar algunos de los obstáculos, así como las lecciones aprendidas para futuros proyectos:

4.4. Reto cultural


Dentro del equipo global multifuncional que ayudo a la implementación del modelo se
enfrentaron con diferentes retos, como la diferencia de horarios entre zonas, así como la diferencia
de idiomas entre cada uno de los países. Por medio de la comunicación en ingles lo cual facilitaba
el desarrollo del modelo se pudo llegar a acuerdos en común, aunque las diferentes maneras de
interpretar los mensajes podían ser obstáculos en algunos momentos. Para poder mitigar el impacto
de este obstáculo se optó por agendar juntas con cada uno de los focales para hacer revisiones de
acciones, así como validar con el equipo su experiencia durante el proyecto para de alguna manera
lograr el compromiso de cada uno de los integrantes.

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.

4.6. Niveles de aprobación


Parte del objetivo inicial del proyecto era implementar y estandarizar este modelo en todas las
áreas de la empresa globalmente, por lo que uno de los mayores retos fue seguir y apegarse a los
niveles de aprobación de cada una de las diferentes unidades de negocio de la empresa. Cada una
de estas áreas cuenta con equipos de liderazgo que deben de dar su aprobación cada vez que existe
un cambio o integración en sus procesos, por lo que la espera de estas aprobaciones postergaban
las actividades consideradas en el plan inicial y los tiempos de implementación se extendían debido
a esto. La lección para este punto fue realizar un plan estratégico para este tipo de cambios de
último momento teniendo diferentes opciones o planes en caso de enfrentarnos a estas situaciones.

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)

Anexo 2: Ejemplo aplicado de Análisis de Causa Raíz (ACR) (Sistema de


Confiabilidad Operacional (SCO), 2014)

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.

Jiménez, D. (2013). Reporte A3 de Toyota-Una práctica para Resolver No conformidades.


Septiembre 8, 2017, de Pymes y Calidad Sitio web: https://www.pymesycalidad20.com/elreporte-
a3-de-toyota.html

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.

Pery, H. (2015). 8 disciplines. Agosto16, 2017, de CRM Sitio web: http//www.pdcahome.com/las-


8d

Pérez, D.A. (. (2016). Desarrollo de la visión estratégica y el liderazgo. En Gestión de Operaciones


(pp. 13-15). SLP: UASLP.

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

Toledano, A. (2009). Las claves del éxito de Toyota. México: Pearson.

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

También podría gustarte