JIT, inventario de seguridad e ITIL (2 de 2)

25 de marzo de 2014

diana_blog_Proactivanet2En una serie de dos artículos presentaremos primeramente el concepto de producción JIT frente al uso más tradicional de un inventario de insumos a modo de margen de seguridad para la producción para, a continuación, explicar un ejemplo de cómo trasladar el concepto JIT y sus ventajas a una actividad propia de la Gestión de Incidencias como es el escalado a tercera línea de incidencias.

En la primera parte de este artículo explicamos que la producción JIT permitía, entre otras cosas, evidenciar los fallos tan pronto ocurren y obligaba, por tanto, a resolverlos de manera rápida ya que en caso contrario se para la producción.

Una ventaja del JIT es, por tanto, que obliga a la mejora continua previniendo fallos y evitando, en caso de que sucedan, su repetición. Esta es, sin duda, la esencia de la mejora continua (“kaizen”, en la terminología Toyota) y, en el mundo ITIL, el proceso de Gestión de Problemas.

Después de una primera parte del artículo alejado de ITIL y otros marcos para la Gestión de Servicios de TI, pasaremos a explicar como el concepto JIT puede extrapolarse a otros ámbitos. Vamos a poner un ejemplo muy concreto en el concepto de escalado de incidencias.

Suponga que usted tiene un grupo de soporte que realiza escalados jerárquicos y funcionales a grupos de un nivel superior cuando es incapaz de resolver la incidencia por falta de tiempo o de conocimiento.

Esta idea, sumamente habitual y recomendada, puede provocar al igual que el almacenamiento de insumos como medida preventiva que se escondan fallos y situaciones que deberíamos corregir pero que incluso nos cuesta detectar.

Pensemos por un momento que el grupo de soporte al que hacíamos mención tiene un nivel de conocimiento insuficiente sobre cierta materia y que, por tanto, permanentemente está haciendo escalados funcionales a otro grupo cuando se encuentre una incidencia relacionada. Pensemos también que podría suceder que ese mismo grupo de soporte esté sobrecargado y que, constantemente, deban realizar escalados jerárquicos para evitar que las incidencias incumplan los SLA.

Fíjese que en ambos casos, la existencia de los grupos a los que realizar los escalados jerárquicos o funcionales está ocultando un problema que es la sobrecarga de trabajo o la falta de capacitación del grupo que siempre debe recurrir a los escalados y, mientras no actuemos para corregirlo, estaremos asumiendo el sobrecoste de utilizar más grupos y más personal para resolver incidencias del que tendría que ser necesario.

Una interpretación estricta del método JIT nos sugiere que no deberían existir grupos a los que realizar escalados jerárquicos o funcionales para que, en caso de existir falta de capacidad en el grupo de soporte que atiende las incidencias, esta se haga evidente y así podamos ser conscientes del problema y actuar para resolverlo.

No le negaré que por mucho que me guste el concepto JIT y el TPS esta opción me parece inasumible porque en este caso, lo mejor puede ser enemigo de lo bueno. Es decir, hacer que sean evidentes las incapacidades de ese grupo de soporte puede provocar incumplimientos graves de los SLA que tengan consecuencias serias en forma de penalización económica o mala imagen frente al cliente.

Sin embargo, no tenemos por qué resignarnos a no aplicar el TPS ya que este también acepta la flexibilidad en su interpretación, llegando incluso a admitir que la existencia de cierto inventario de seguridad puede mejorar la calidad entregada al cliente, como sucede en nuestro ejemplo de los escalados al tener como “inventario de seguridad” los grupos a los que realizar el escalado jerárquico o funcional.

Eso sí, no debemos permitir que los fallos permanezcan ocultos o en ese caso nos será imposible la mejora continua (“kaizen” en terminología Toyota) y tendremos que asumir como inevitable el sobrecoste de utilizar personal en exceso para resolver las incidencias.

Por eso aquí recomendaría una combinación de dos principios: no se conoce lo que no se mide y utiliza el control visual siempre que sea  posible, este último también un principio del TPS que no es más que la plasmación de que una imagen vale más que mil palabras.

Por lo tanto, lo que recomendaría es tener siempre sobre observación los escalados de incidencias entre grupos para detectar situaciones inadecuadas como sobrecarga de un grupo que provoca muchos escalados jerárquicos o falta de conocimiento de un grupo que provoca muchos escalados funcionales.

Pero esta observación debe ser ágil y sencilla, por lo que nada mejor que algo que permita supervisión visual, como por ejemplo unas métricas del dashboard de Proactivanet

Por último comentar que esta situación la hemos vivido en el soporte de Proactivanet y que, para poder identificar fácilmente los grupos de soporte que estaban sobrecargados o que requerían formación no quedó más remedio que quitar esa “red de protección” a modo de “almacén de seguridad” que era el ámbito de responsabilidad compartido sobre las incidencias entre todas las oficinas.

En el momento en el que las distintas oficinas con personal de soporte se responsabilizaron de su ámbito geográfico en exclusiva, cuando una oficina era incapaz de resolver su trabajo podía realizar un escalado jerárquico o funcional (así garantizábamos la atención a nuestros clientes). Pero bastó con hacer esta situación explícita para que se pudiese identificar con facilidad los cuellos de botella sobre los que aplicar las acciones de mejora y, por tanto, avanzar hacia una mejor calidad en la atención a nuestros clientes aplicando la mejora continua.

 José Luis Fernández

Suscríbete a nuestro Blog

Loading
“La combinación perfecta entre agilidad y potencia”