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:
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. Cardenas (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.
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:
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.
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».
La capacidad del proceso fue analizada con Minitab (Figura 3) y se concluyó que el subproceso de reparación se encontraba fuera de control.
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.
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.
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.
A1. Procedimiento de diagnóstico estándar: Tiene por objetivo realizar las acciones y pruebas básicas mínimas en un canal caído.
Revisar histórico de consumo de ancho de banda.
Revisar estado de última milla según gestor la tecnología de acceso que posea el enlace.
Revisar histórico de estado de protocolo de enrutamiento dinámico.
Si el enlace tiene redundancia, validar que tráfico haya conmutado.
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.
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:
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?
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.
Describir cuál fue la causa raíz del problema.
Describir los servicios que fueron afectados.
Indicar acción que reparó la avería.
Lista de equipos y componentes reemplazados.
Hora de reparación.
Tiempo de indisponibilidad asignado.
Plantear y dejar registrado el plan de monitoreo estándar, ver sección 4.2.5.6.
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).
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.
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.
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.
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.
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.