Revista Industrial Data 25(1): 205-228 (2022)

DOI: https://doi.org/10.15381/idata.v25i1.22194

ISSN: 1560-9146 (Impreso) / ISSN: 1810-9993 (Electrónico)

 

 

Aplicación de Lean Six Sigma para mejorar el subproceso de reparación de averías en enlaces de comunicaciones

Hugo Iván Ticona Gregorio[1]

Recibido: 05/02/2022 Aceptado: 13/04/2022 Publicado: 31/07/2022

RESUMEN

En telecomunicaciones, el proceso de resolución de averías en enlaces de comunicaciones es un proceso complejo que contiene subprocesos, uno de los cuales es el de Reparación. En el siguiente estudio de investigación se aplicó Lean Six Sigma para mejorar dicho subproceso. Como resultado se obtuvo una mejora de 36.7% en el promedio mensual del Tiempo de Reparación (TR) y de 300.08% del Yield del Tiempo de Reparación (YTR).

Palabras clave: telecomunicaciones, Lean Six Sigma, tiempo de reparación, yield, averías.

INTRODUCCIÓN

La necesidad de competir en el mercado demanda a las empresas a practicar la mejora continua de la calidad en sus procesos, más aún en aquellas industrias donde los servicios ofrecidos van perdiendo diferenciación como está sucediendo en el sector de telecomunicaciones. La calidad es un concepto relativo, por lo que en su estudio se debe tener claro la perspectiva desde la cual se está valorando. Según Evans y Lindsay (2015), existen hasta 6 perspectivas de la calidad: producto, estética, del usuario, de valor, manufactura y cliente.

Uno de los procesos clave para un proveedor de servicios de telecomunicaciones es el de Resolución de Averías, el cual está conformado por varios subprocesos, siendo uno de ellos el de Reparación. El presente estudio busca contribuir al conocimiento a través de un ejemplo de aplicación práctica de Lean Six Sigma en el sector servicios de telecomunicaciones que, en comparación con otros sectores, tiene una menor cantidad de aplicaciones registradas. La relevancia y el aporte novedoso radican en que la metodología Lean Six Sigma se aplicó en un proceso que ocurre dentro de las organizaciones nacionales e internacionales que proveen servicios de telecomunicaciones, los cuales sirven de soporte a otras actividades económicas en un país. La propuesta de solución planteada en esta investigación puede ser aplicada en aquellas compañías en las que el desempeño de su proceso de reparación de averías se ve afectado por las complicaciones que se originan como resultado de organizar sus recursos humanos en horarios rotativos y con relevo de tareas entre ellos a fin de brindar una operación continua 24/7. La solución propuesta es de fácil aplicación debido a que esta no se centra en las actividades técnicas de reparación, ni tampoco si el tipo de tecnología usada es MPLS (Multiprotocol Label Switching), 5G (5th Generation) o SDN (Software Defined Networks); por el contrario, la solución se enfoca principalmente en estandarizar la forma en que las actividades se documentan y registran en un entorno de trabajo por relevos. Su aporte es relevante ya que busca resolver un problema existente identificando sus causas y proponiendo mejoras.

Problemática

¿En qué medida la aplicación de Lean Six Sigma mejora el subproceso de reparación de averías?

La presente investigación busca determinar en qué medida mejora, mediante la aplicación de LSS, el subproceso de reparación de averías en una compañía que provee servicios de comunicaciones al sector corporativo, para lo cual se plantearon como objetivos:

1.  Mejorar el TR a un valor menor igual que 3.25 Hrs.

2.  Mejorar el YTR a un valor mayor igual a 75%.

Donde:

·      TR: Tiempo de Reparación, es el tiempo que transcurre desde que se recibe el reporte de avería hasta que se resuelve; en su cálculo se descuentan los tiempos de espera atribuibles al cliente.

·      YTR: Yield Tiempo Reparación, es el % de averías que se resuelven con un valor menor o igual a un tiempo de reparación meta; para el control del yield, el TR vale 3.5 horas.

 

Hipótesis

·      H0: La aplicación de LSS no mejora el subproceso de reparación de averías.

·      H1: La aplicación de LSS mejora el subproceso de reparación de averías.

Antecedentes

En México, Pérez (2016) investigó el impacto de LSS en las organizaciones latinoamericanas y concluyó que los dos factores de éxito más influyentes fueron un concurso organizado por la alta dirección y el establecimiento de metas de mejora que cuantificasen los avances conseguidos. Asimismo, afirma que la falta de empoderamiento y confianza en el personal son los principales obstáculos. En Ecuador, Serrano y Ruiz (2018) aplicaron LSS para mejorar la calidad y productividad del proceso de elaboración de quesos, para lo cual usaron la herramienta 5S. En Cuba, García (2014) aplicó LSS en un taller de reparación de autos utilizando DMAIC como metodología de resolución de problemas, con lo que se redujo el defecto en las reparaciones de 52.9% a 20.45%.

En Perú, Barahona y Navarro (2013) aplicaron LSS para reducir el consumo de zinc y la tasa de fallas en el proceso de galvanizado de alambres de acero; para cumplir con su cometido, identificaron y eliminaron las actividades que no agregan valor. Cárdenas (2019) también aplicó LSS y usó la metodología DMAIC para mejorar la eficiencia de formación de una línea específica de envases, con lo que obtuvo un aumento de la eficiencia de 78.6% a 82%. En el sector bancario, Felipa (2014) desarrolló un modelo de aplicación de LSS con el que resaltó la importancia de la participación de la gerencia y la ventaja del uso gráficos para facilitar la comprensión de los procesos por parte de los usuarios. Perales (2018) logró mejorar los procesos de atención en una universidad pública aplicando LSS mediante el uso de 5S como herramienta principal. Finalmente, Yuiján (2014) mejoró el proceso logístico en una empresa que vende productos de consumo masivo al reducir la tasa de fallas en las entregas de productos en un 20% y conseguir una mejora a nivel de sigma de 0.66.

Marco Teórico

Los procesos juegan un rol muy importante en las compañías, independientemente del rubro en que se encuentren, ya que a través de ellos las entradas se transforman en resultados deseados. Según Pérez (2010), un proceso se conforma por una colección ordenada de actividades que se ejecutan para obtener un producto valorado por el usuario. Boutros y Cardella (2016) señalan que los procesos tienen cinco elementos: recursos, inputs, secuencia de actividades, outputs y control; asimismo, plantean una clasificación de los procesos: de negocio, de soporte, y administración.

La mejora de procesos es una práctica importante para las empresas tanto de manufactura como de servicios, por lo cual se han desarrollado herramientas y técnicas diversas para impulsarla. Una de dichas técnicas es Lean Six Sigma, que es una combinación de las bondades de las técnicas de mejora de proceso Six Sigma y Lean, lo que resulta en un enfoque de mejora en dos frentes: la variabilidad del proceso y la reducción de desperdicios para ganar agilidad. Furterer (2015) señala que LSS reduce la variabilidad que ocurre en un proceso y elimina el desperdicio que se produce dentro, con lo cual mejora la calidad de este. Antony, Vinodh y Gijo (2016) definen el desperdicio en un proceso como cualquier actividad que se ejecuta en un proceso e implica inversión de recursos sobre la cual el cliente no está dispuesto a pagar, ya que no le aporta valor, y provee como ejemplo los tiempos de inactividad.

Voehl et al. (2014) afirman que el enfoque transversal que posee LSS provee ventajas para concretar oportunidades de mejoras; también señalan que es necesaria la intervención de proveedores, propietarios y clientes del proceso para una implementación exitosa. Antony et al. (2016) señalan que cuando se implementa la metodología LSS se debe buscar el entendimiento y la confianza en esta mediante la consulta con expertos en la materia, a los que se debe apoyar, de modo que haya un enfoque en los procesos principales a fin de asegurar el alto impacto; estos autores también resaltan la importancia de alinear el proyecto de mejora con los objetivos estratégicos de la compañía y así asegurar la sostenibilidad de los cambios a lo largo del tiempo. Según George et al. (2005), SIPOC permite obtener información sobre el proceso de estudio de forma rápida, identificando sus principales entradas y salidas, así como sus intervinientes.

LSS usa DMAIC para resolver problemas, el cual, al estar conformado por cinco etapas, aporta una secuencia estructurada para gestionar el proyecto de mejora, así como herramientas especializadas en cada una de las etapas. Según Antony et al. (2016), DMAIC es muy útil para afrontar escenarios de problemas donde las causas y soluciones no son obvias, así como aquellos escenarios donde los riesgos son muy altos. También indica que la etapa Define (D) se encarga de definir el alcance del problema, Measure (M) define la situación actual, Analyze (A) se orienta a identificar las causas del problema, Improve (I) identifica las oportunidades de mejora y, finalmente, la etapa Control (C) se enfoca en mantener la sostenibilidad de las mejoras.

Algunas de las herramientas usadas por LSS son Críticos para la calidad (CTQ), Project charter, diagrama SIPOC, análisis de causa-efecto o Ishikawa, diagrama de Pareto, histogramas y gráficas de control. Antony et al. (2016) indican que CTQ permite identificar las salidas críticas que debe proveer un proceso, mientras que Franchetti (2015) define a la carta del proyecto como el mapa de ruta que consolida información relevante sobre el mismo.

Encontrar las causas de un problema es una tarea clave dentro de un proyecto de mejora, para lo cual LSS posee el análisis de causa-efecto. Kume (2002) define a este análisis, que también se conoce como espina de pescado, como una herramienta gráfica que facilita el entendimiento de un problema complejo. Debido a que los recursos dentro de una compañía son limitados, es importante enfocarse en resolver los componentes del problema que generan mayor impacto, para ello LSS dispone del diagrama de Pareto que, de acuerdo con George (2003), usa barras para representar gráficamente el peso que tiene un factor dentro de la problemática que se busca resolver. Por otro lado, los histogramas y gráficas de control, de acuerdo con Kume (2002), son herramientas gráficas: la primera está enfocada en facilitar la comprensión del comportamiento de los datos sobre un problema, y la segunda permite controlar el impacto de las mejoras introducidas.

METODOLOGÍA

§     Las averías estudiadas cumplen con las siguientes características:

-          Se presentaron en red propia y en zonas urbanas.

-          Fueron reportadas por los clientes, es decir, son reactivas.

-          Implicaron indisponibilidad total de los servicios.

-          Fueron de tipo individual.

-          Impactaron servicios de internet y/o datos.

Se revisó la información histórica y se encontró que en abril de 2020 se reportaron 24 averías que cumplían con las características mencionadas.

§     Se eligió una muestra probabilística aleatoria simple con nivel de confianza de 99%, p igual a 50%, e de 5% y Z de 2.575. Al reemplazar estos valores en la fórmula planteada por Triola (2018), esta arrojó un tamaño de muestra de 23.19, lo que se redondeó a 24.

 

§     Se extrajeron de la base de datos los valores de Tiempo de Reparación (TR), los que fueron organizados en tablas usando Excel.

§     Se realizó la prueba de normalidad a los valores de TR, usando Minitab.

§     Se aplicaron las cinco etapas de la metodología DMAIC.

§     La etapa de control se realizó durante 5 meses y se seleccionaron las primeras 24 averías ocurridas en cada periodo de control.

§     La prueba de hipótesis para TR se hizo con respecto a la muestra total del periodo de control completo, mientras que para YTR se hizo con respecto a la muestra conformada por los YTR de cada periodo de control. Para ambas se usó t de Student de una muestra.

RESULTADOS

§  Define

Se aplicaron las herramientas Críticos para la calidad (CTQ) y Project charter para resumir la información del proyecto.

Se usó la herramienta Críticos para la calidad (CTQ) a fin de obtener los requerimientos de calidad desde la perspectiva cliente, así como para fijar los CTQ que deben cumplir cada uno de ellos. En la Tabla 1 se muestra el resultado de la aplicación, donde TR y YTR vienen a ser los Key Performance Indicator (KPI) que serán usados para el control del subproceso reparación de averías.

Tabla  1. Resultado de aplicación de la herramienta Críticos para la calidad.

Driver de Calidad

Requerimiento

Fuente de requerimiento

CTQ

Menor Tiempo de Reparación (TR) promedio

Reducir Tiempo de Reparación promedio.

 

Cliente/Gerencia

TR 3.25 Hrs

Mejor Yield Tiempo de Reparación (YTR)

Incrementar % de averías con TR 3.5 Hrs.

Gerencia

YTR 75%

Fuente: Elaboración propia.

Project charter

Título del proyecto: Mejora del subproceso de reparación de averías individuales con indisponibilidad total.

Contexto y razón de elección del proyecto: La gerencia de Telco se ha trazado como objetivo mejorar la experiencia del cliente, dentro de lo cual la mejora de los tiempos de reparación es un aspecto importante.

Objetivo del Proyecto: Mejorar los dos indicadores del subproceso Reparación:  

§  Tiempo de Reparación: TR ≤ 3.25 Hrs

§  Yield del Tiempo de Reparación: YTR ≥ 75%

Alcance: Subproceso de reparación de averías individuales

Definición de no conformidad: cuando la avería se haya resuelto con TR > 3.5 Hrs

§  Measure

Al hacer uso del TR de la muestra se obtuvo 4.9 Hrs para el estado inicial, luego se aplicó la prueba de normalidad a los valores y, dado que el valor de p fue mayor que 0.05 (Figura 1), se comprueba que los valores siguen una distribución normal, lo que permitirá analizar la capacidad del proceso.

Figura  1. Prueba de Normalidad Variable TR.

Fuente: Elaboración del autor, Minitab.

Se aplicó SIPOC (Figura 2) para obtener una perspectiva general del proceso, donde:

§  Revisar el diagnóstico: Implica extraer la información contenida en el ticket de avería; esta puede incluir síntomas del problema, sede afectada, datos del cliente.

§  Validar diagnóstico: Las averías pueden venir con un diagnóstico preliminar que es necesario validar.

§  Definir plan de acción: El tiempo es un recurso limitado, por ello las actividades a realizar deben ser elegidas cuidadosamente y quedar registradas en un plan.

§  Dirigir reparación: Implica ejecutar el plan de acción y reevaluarlo cuando sea necesario.

§  Cambiar estado de avería: Una vez lograda la reparación, se debe colocar la avería en estatus «resuelta».

Figura 2. Aplicación de Herramienta SIPOC.

Fuente: Elaboración del autor.

La capacidad del proceso fue analizada con Minitab (Figura 3) y se concluyó que el subproceso de reparación se encontraba fuera de control.

Figura 3. Análisis de Capacidad – Condición inicial.

Fuente: Elaboración del autor, Minitab.

§  Analyze

Se aplicó el diagrama de Ishikawa (Figura 4), y las causas raíz fueron clasificadas tal como se observa en la Tabla 2. Con base en la experiencia del gerente de área propietaria del proceso, y considerando los criterios de impacto y frecuencia de ocurrencia de las causas, se concluyó que las causas C9, C6, C7, C1 y C3 son las que afectan en mayor medida en el subproceso. Para ahondar en ellas se aplicó la herramienta 5Whys.

Figura 4. Diagrama de Ishikawa – Análisis de Causas Raíz del subproceso de reparación.

Fuente: Elaboración del autor.

 

C9: Registro no estándar de incidentes de la reparación

§  Why1: En la reparación se realizan diversas actividades en simultáneo.

§  Why2: Hay diversos tickets de averías para ser trabajados.

§  Why3: Los tickets resueltos no se cierran en su debido momento.

§  Why4: Se requiere revisar todo el ticket para obtener los detalles de la reparación, como cuál fue la falla, dónde se localizó la falla, qué acción reparó la falla, a qué hora inició la falla y a qué hora se restableció el enlace o servicios.

§  Why5: Falta definir qué información esencial se debe registrar con respecto a momentos importantes de la reparación y la forma en que estos deben ser registrados.

C6: Ingeniero no define plan de trabajo para técnico de campo

§  Why1: El ingeniero no lo considera una parte importante del proceso.

§  Why2: El ingeniero se encuentra desarrollando múltiples actividades en simultáneo y prioriza las actividades controladas del proceso o aquellas que no ameritan mucha inversión de tiempo de su parte.

§  Why3: Al ser el plan de naturaleza cualitativa y variar de una avería a otra, puede quitarle mucho tiempo al ingeniero.

§  Why4: El plan de trabajo define recursos y acciones que deberá realizar el ingeniero en conjunto con el técnico de campo, proyectar este plan en una situación de incertidumbre como una avería causa que el ingeniero no siempre lo haga.

§  Why5: Los lineamientos de un plan básico que se amolde a la mayoría de las situaciones no están definidos.

C7: Demora en tiempo de desplazamiento de personal técnico

§  Why1: Los protocolos de bioseguridad y controles dificultan los desplazamientos en la vía pública y los protocolos de acceso.

§  Why2: El técnico necesita desplazarse al nodo, a veces, por falla en el diagnóstico remoto.

§  Why3: El diagnóstico falla debido a que el ingeniero no definió bien el alcance del problema.

§  Why4: El ingeniero no hace una correcta definición del problema debido a que no ejecuta pruebas necesarias.

§  Why5: La complejidad del proceso de diagnóstico dificulta definir pruebas estándar mínimas para cualquier escenario.

C1: Diagnóstico incompleto o errado

§  Why1: El ingeniero no reúne suficiente información sobre el problema.

§  Why2: El ingeniero no hace las preguntas correctas cuando contacta al cliente.

§  Why3: Los ingenieros tienen diversos niveles de habilidad para formular preguntas.

§  Why4: Los ingenieros tienen diversos niveles de experiencia y diversos niveles de reacción a las averías.

§  Why5: Cada ingeniero define como realiza y documenta su diagnóstico.

C3: Demora en envío de repuestos a la oficina del cliente

§  Why1: El repuesto no es llevado por el técnico

§  Why2: El técnico no dispone de repuestos necesarios para atender a la avería.

§  Why3: El repuesto fue usado en una avería anterior y aún no ha sido reemplazado por logística.

§  Why4: Logística no tiene conocimiento de que el repuesto debe ser reemplazado.

§  Why5: El ingeniero no regularizó las órdenes para reponer repuestos a Logística, ya que el proceso no estipula cuándo debe hacerlo.

Tabla 2. Clasificación de causas raíz.

Categoría

Código

Tiempo de Reparación

Material

C1

Diagnóstico incompleto o errado

Material

C2

Documentación incompleta de la ingeniería del enlace y servicios

Material

C3

Demora en envío de repuestos a la oficina cliente

Material

C4

Hay averías de alta complejidad

Hombre

C5

Diferente nivel de habilidad en los ingenieros

Hombre

C6

Ingeniero no define plan de trabajo para técnico de campo

Ambiente

C7

Demora en tiempo de desplazamiento de personal técnico

Máquina

C8

Lentitud de acceso a sistemas

Método

C9

Registro no estándar de incidentes de la reparación

Fuente: Elaboración del autor.

§  Improve

La propuesta de mejora se centra en estandarizar el diagnóstico, el registro del diagnóstico y el registro de la acción de reparadora. La Tabla 3 muestra el detalle de la propuesta.

Tabla 3. Propuesta de solución.

Causa

Acciones

Cuándo

Cómo

Dónde

Responsable

La complejidad del proceso de diagnóstico dificulta definir pruebas estándar mínimas para cualquier escenario.

A1. Ejecutar Procedimiento de diagnóstico estándar.

Al iniciar reparación.

Ingresando a Equipos y sistemas de gestión.

Incluir en A2.

Ingeniero que inicia reparación.

Falta definir qué información esencial se debe registrar con respecto a momentos importantes de la reparación y la forma en que estos deben ser registrados

A2. Registrar diagnóstico estándar.

Luego de ejecutar A1.

Mediante una nota titulada Resumen diagnóstico.

En sistema de Gestión de tickets.

Ingeniero que inicia proceso de reparación.

A3. Registro estándar de la acción de reparación.

Al resolverse el problema.

Mediante nota interna titulada Resumen de reparación.

Ingeniero que realiza la reparación.

Fuente: Elaboración del autor.

A1. Procedimiento de diagnóstico estándar: Tiene por objetivo realizar las acciones y pruebas básicas mínimas en un canal caído.

1)  Revisar histórico de consumo de ancho de banda.

2)  Revisar estado de última milla según gestor la tecnología de acceso que posea el enlace.

3)  Revisar histórico de estado de protocolo de enrutamiento dinámico.

4)  Si el enlace tiene redundancia, validar que tráfico haya conmutado.

5)  Si la última milla está operativa y hay indisponibilidad de servicio, realizar prueba de conectividad total mediante ping con tamaño de paquete variable y origen subinterfaz LAN de nuestro router instalado en el cliente.

6)  Si no hay información suficiente, contactar telefónicamente al cliente.

A2. Registro estándar de diagnóstico:  Tiene el objetivo de centralizar y resumir la información sobre el diagnóstico de la avería; contiene como mínimo los siguientes puntos:

1)  Descripción de síntomas del problema: Se sugiere incluir las respuestas a las siguientes preguntas: ¿Cómo se dio cuenta de la afectación el cliente?, ¿qué síntomas tiene la avería?, ¿alguno de los otros servicios le está funcionando?, ¿el módem de última milla tiene algún led en rojo? ¿Cuál es la hora de inicio de afectación?

2)  Resultados de ejecución de diagnóstico estándar y plan de acción. Defina el plan de acción a realizar, al menos las tres siguientes actividades. Refiérase con nombre y apellidos de los responsables y use horas específicas. Si usted observa un potencial riesgo, ya sea por complejidad del problema o falta de recursos, escale con el gerente del área.

A3. Registro estándar de reparación: Busca facilitar el cierre de la avería y cualquier análisis posterior requerido sobre el ticket.

1)  Describir cuál fue la causa raíz del problema.

2)  Describir los servicios que fueron afectados.

3)  Indicar acción que reparó la avería.

4)  Lista de equipos y componentes reemplazados.

5)  Hora de reparación.

6)  Tiempo de indisponibilidad asignado.

7)  Plantear y dejar registrado el plan de monitoreo estándar, ver sección 4.2.5.6.

8)  Configurar Autoclose con un tiempo de 4 horas más sobre el tiempo indicado en el plan de monitoreo, como reserva ante algún imprevisto.

§  Control

El análisis de capacidad del proceso mejorado, luego de los 5 meses, arrojó los resultados mostrados en la Figura 5, donde se observa que el proceso ahora se encuentra bajo control. La Tabla muestra los resultados para TR e YTR para los cinco periodos de Control (C).

Gráfico, Histograma

Descripción generada automáticamente.

Figura 5. Análisis de Capacidad – Post aplicación LSS.

Fuente: Elaboración del autor, Minitab.

Prueba de hipótesis: Dado que en las pruebas de normalidad de TR y YTR se obtiene que p es mayor que 0.05 para ambas variables, se concluye que siguen una distribución normal (Figuras 6 y 7). De lo anterior, se usó la prueba t de Student para ambas variables. Los estadísticos descriptivos para ambas variables se muestran en la Tabla 4.

Gráfico, Gráfico de líneas

Descripción generada automáticamente

Figura 6. Prueba de Normalidad – TR Mejorado.

Fuente: Elaboración del autor, Minitab.

Figura 7. Prueba de Normalidad YTR Mejorado.

Fuente: Elaboración del autor, Minitab.

Tabla 4. Estadísticos descriptivos post aplicación.

N

Media

Desv.Est.

Error estándar de la media

Límite Superior de 95% para µ

120

3.11

0.47

0.04

3.18

5

0.85

0.04

0.02

0.81

Fuente: Elaboración del autor.

Prueba Hipótesis TR:

Hipótesis nula          H: μ = 4.91 La aplicación de LSS no mejora el TR 

Hipótesis alterna H1: H: μ < 4.91, La aplicación de LSS mejora el TR

Valor T: - 41.71

Valor p: 0.00

En la Figura 8, se aprecia de forma gráfica la prueba de Hipótesis. La media de TR es menor que la media del proceso en el Estado 0 o inicial.

Gráfico, Gráfico de cajas y bigotes

Descripción generada automáticamente

Figura 8. BoxPlot Prueba de Hipótesis Variable TR Mejorada.

Fuente: Elaboración del autor, Minitab.

Prueba de Hipótesis YTR

Hipótesis nula          H: μ = 0.21 La aplicación de LSS no mejora el YTR

Hipótesis alterna H1: H1: μ > 0.21 La aplicación de LSS mejora el YTR

Valor T: 35.13

Valor p: 0.00

En la Figura 9 se aprecia de forma gráfica la prueba de hipótesis. La media de YTR del proceso mejorado es mayor que la media del proceso en el estado 0 o inicial.

Gráfico

Descripción generada automáticamente con confianza baja

Figura 9. BoxPlot Prueba de Hipótesis Variable TR Mejorada.

Fuente: Elaboración del autor, Minitab.

Dado que para TR y YTR, el valor de p es menor que 0.05, se rechaza H0 y se acepta H1, que afirma que la aplicación de LSS mejora el subproceso de reparación.

DISCUSIÓN

La Tabla 5 resume los resultados de TR y YTR, antes de la aplicación (E0) y después de la aplicación.

§  La aplicación de LSS logró una reducción de 37% del tiempo de reparación respecto del estado inicial, lo que acorta el tiempo de vida de los tickets en cerca de 1.8 horas.

§  El Yield TR mejoró en un 308% respecto al YTR del estado inicial.

§  La aplicación de LSS permitió obtener valores mejores que los objetivos trazados en el proyecto de mejora: El TR y YTR promedio de los cinco periodos de control fue de 3.11 Hrs versus 3.25 Hrs y 85% versus 75%, respectivamente.

§  Las mejoras principalmente se enfocaron en reducir el TR en base a la propuesta del diagnóstico estándar y a reducir la incertidumbre del proceso por falta de información, estandarizando la documentación del diagnóstico y el registro de la acción reparadora.

Tabla 5. Tabla Resumen de Indicadores TR y YTR

Indicador

E0

C1

C2

C3

C4

C5

C

Mejora

TR (Hrs)

4.91

3.09

3.09

3.09

3.10

3.17

3.11

-0.37

YTR

0.21

0.79

0.88

0.83

0.88

0.88

0.85

3.08

Fuente: Elaboración del autor.

CONCLUSIONES

§  Como todo proceso de mejora, es importante el involucramiento de las personas que participan de la ejecución del proceso, ya sea como proveedores de entradas al proceso o de los que llevan a cabo el proceso en sí.

§  LSS demuestra su valor como herramienta de mejora en la industria de servicios al mejorar un subproceso complejo que tiene salidas no tan parametrizadas como los productos tangibles.

§  A fin de gestionar la dificultad que implica valorar las características intangibles del producto que entrega el subproceso, es conveniente definir los atributos críticos para la calidad.

§  En aplicaciones de LSS en servicios, el nivel de variabilidad que tiene la variable de estudio en el estado inicial puede ser tomado como una referencia del grado de definición que deben tener los atributos críticos para la calidad.

REFERENCIAS BIBLIOGRÁFICAS

[1]       Antony, J., Vinodh, S., y Gijo, E. (2016). Lean Six Sigma for Small and Medium Sized Enterprises: A Practical Guide. Boca Raton, FL, EE. UU.: CRC Press Taylor & Francis Group.

[2]       Barahona, L., y Navarro, J. (2013). Mejora del proceso de galvanizado en una empresa manufacturera de alambres de acero aplicando la metodología Lean Six Sigma. (Tesis de grado). Pontificia Universidad Católica del Perú, Lima.

[3]       Boutros, T., y Cardella, J. (2016). The Basics of Process Improvement. Boca Raton, FL, EE. UU.: CRC Press Taylor & Francis Group.

[4]       Cardenas, R. (2019). Mejora de la eficiencia de formación de una planta de fabricación de envases de vidrio. (Tesis de maestría). Pontificia Universidad Católica del Perú, Lima.

[5]       Evans, J., y Lindsay, W. (2015). Administración y Control de la Calidad (9a edición). México D. F., México: Cencage Learning.

[6]       Felipa, J. (2014). Metodología de implantación de modelo de mejoras de procesos Lean Six Sigma en entidades bancarias. (Tesis de maestría). Universidad de Piura, Piura.

[7]       Franchetti, M. (2015). Lean Six Sigma for Engineers and Managers. With Applied Case Studies. Boca Raton, FL, EE. UU.: CRC Press Taylor & Francis Group.

[8]       Furterer, S. (2015). Lean Six Sigma en el servicio. México D.F., México: Trillas.

[9]       García, Y. (2014). Aplicación de la Metodología Seis Sigma para el mejoramiento de la calidad de las reparaciones, en la Agencia SASA Villa Clara. (Tesis de maestría). Universidad Central Marta Abreu de las Villas, Santa Clara.

[10]    George, M. (2003). Lean Six Sigma for Service: How to Use Lean Speed and Six Sigma Quality to Improve Service and Transactions. EE. UU.: McGraw Hill.

[11]    George, M., Rowlands, D., Price, M., y Maxey, J. (2005). The Lean Six Sigma Pocket Toolbook, a Quick Reference Guide to Nearly 100 Tools for Improving Process Quality, Speed, and Complexity. EE. UU.: McGraw-Hill.

[12]    Kume, H. (2002). Herramientas estadísticas básicas para el mejoramiento de la calidad. Bogotá, Colombia: Grupo Editorial Norma.

[13]    Perales, M. (2018). Análisis, diagnóstico y propuesta de mejora en los procesos administrativos de la dirección general de administración en una universidad pública aplicando Lean Six Sigma. (Tesis de maestría). Pontificia Universidad Católica del Perú, Lima.

[14]    Pérez, J. (2010). Gestión por Procesos (4ta ed.). Madrid, España: ESIC Business and Marketing School.Pérez, H. (2016). El impacto de Lean Six Sigma en organizaciones latinoamericanas y sus factores críticos de éxito. (Tesis doctoral). Universidad Antropológica de Guadalajara, Jalisco.

[15]    Serrano, G., y Ruiz, F. (2018). Aplicación de la metodología Lean Six Sigma en una empresa de lácteos: caso de estudio en la fabricación de quesos frescos, queso mozzarella y mantequilla. (Tesis de maestría). Universidad San Francisco de Quito, Quito.

[16]    Triola, M. (2018). Estadística (12ª edición). México D.F., México: Pearson Education.

[17]    Voehl, F., Harrington, H., Mignosa, C., y Charron, R. (2014). The Lean Six Sigma Black Belt Handbook: Tools and Methods for Process Acceleration. Boca Raton, FL, EE. UU.: CRC Press Taylor & Francis Group.

[18]    Yuiján, D. (2014). Mejora del área de logística mediante la implementación de Lean Six Sigma en una empresa comercial. (Tesis de grado). Universidad Nacional Mayor de San Marcos, Lima.



[1] Magister en Administración de Empresas de la Universidad del Pacífico (Lima, Perú). Actualmente es consultor independiente.

Orcid: https://orcid.org/0000-0002-7967-3210

E-mail: iticonag@gmail.com