Deming y la adquisición de herramientas

Estoy leyendo estos días “Out of the crisis” de W. Edwards Deming, en el que básicamente expone las claves de su sistema para mejorar la calidad y la productividad, exhortando a la industria estadounidense a seguir sus 14 claves para alcanzar la calidad total y salir de la decadencia en que su tejido empresarial se encuentra. Desde el primer capítulo, Deming insiste en un punto: no hay que empezar comprando robots, máquinas, ordenadores u otros aparatejos para empezar a mejorar la calidad, sino centrarse en las personas. Para él, el primer paso en la mejora de la calidad es cambiar la forma en la que las personas trabajan, para que trabajen mejor, no más.

Y esto coincide plenamente con uno de los puntos que siempre remarco en los proyectos de adopción de procesos ITIL en los que he trabajado:  no hace falta empezar por la elección de las herramientas de gestión, no hace falta empezar gastando tiempo y dinero en la elección de una herramienta, la configuración, personalización y formación de los usuarios. Es importante hacerlo, pero no debe ser el puntal de un proyecto de cambio de organización, y tampoco es necesario que sea el primer paso. En muchos clientes, nuestro acercamiento empieza por analizar qué hacen y cómo lo hacen, y proponer pequeños cambios iniciales que dan resultados muy rápidamente. Generalmente, esta aproximación genera un cierto recelo por parte de los managers de informática, acostumbrados a adquirir herramientas nuevas para la implantación de nuevos modelos de gestión, pero comprobar cómo, iterando estos ciclos de pequeños cambios, conseguimos grandes resultados, les ayuda a despejar las dudas y a poder replantear la búsqueda de una herramienta de gestión adecuada contando con más argumentos de decisión, al entender cómo va a seguir cambiando su departamento TI y hacia dónde se dirige.

El motivo principal que esgrime Deming para no comenzar un proceso de mejora con la adquisición de productos, es que sin un análisis previo (las preguntas típicas, “cuál es la visión? dónde estamos? dónde queremos estar? cómo llegamos allí?”) y sin revisar primero qué hacen las personas y cómo impacta a la calidad y la productividad, no se puede determinar qué carencias o defectos resolveremos con las adquisiciones ni que beneficios (o qué pérdidas) obtendremos.

Lo cierto es que esta aproximación iterativa de pequeños cambios sobre los “componentes” humanos de un departamento de TI suele ser un éxito, no sólo porque ayudan a vencer la inercia de oposición al cambio natural en cualquier organización (y en cualquier individuo), sino tambien porque permiten la obtención de beneficios rápidamente; podría decirse que se persigue uno de los objetivos de las metodologías ágiles de desarrollo de soft, aunque no sería exacto; de todos modos, Rob England defiende un acercamiento ágil a la gestión de servicios que resulta interesante, y os ánimo a echarle un vistazo. Por otro lado, hay un artículo de Antonio Valle en el que comenta la naturaleza fractal del ciclo de Deming, donde destaca que cada gran vuelta de un ciclo PDCA está compuesta por pequeñas iteraciones del mismo ciclo, como si un sistema orbital fuera. Merece un vistazo.

¿Cómo habeis vivido vosotros los procesos de selección de una herramienta de gestión ITSM? ¿Qué elementos son los que más valoran las empresas para elegir una u otra? ¿Cómo lo habeis vivido?

Club de Lectura: leyendo a los Profetas

Yo no soy religioso, pero me gustan los textos ságrados; suelen ser lecturas curiosas, extrañas y amenas a la vez, en ocasiones ininteligibles y opacas, tanto por lo volátil de sus contenidos como por lo poético. Decía que no soy religioso, pero he leído 2 veces los libros del Pentateuco, los Evangelios y algunos libros de los profetas, Jeremías, Ezequiel, y vi que era bueno y lo he disfrutado.

Pero aún no he leído a los profetas de la calidad, que es el tema que me ocupa en este blog, así que ya tengo en camino “Out of the crisis”, el libro que W. Edwards Deming publicó en 1982 y que supone el corpus de su predicatura. Porque si la calidad tiene un profeta, es él, y por tanto es bueno conocer sus enseñanzas de primera mano. Hizo más que dibujar un círculo (y que la mayoría de veces, además, se dibuja mal), hizo más que promover el milagro japonés en los 50: apostó por algo como perseguir la calidad en todos los procesos de una organización desde la cadena de producción a la cúpula directiva mientras el resto del mundo miraba en otra dirección.

Ya, ya sé que no parece la lectura más amena para llevarme a la playa este verano, pero creo que es imprescindible leer al Mesías, por lo menos una vez.

*El Club de Lectura es un espacio donde compartir, recomendar, reseñar o vapulear libros relacionados con todo lo que interesa a este blog. Sugerencias bienvenidas, claro!

RCA: incomprendida, mal valorada, pero sobretodo desconocida.

Llevo unos 8 años trabajando en el sector informático, siempre en equipos de soporte (menos una temporada en que el equipo de soporte era sólo yo). En los últimos 2 años, más allá de la explosión del hype de ITIL como receta dorada para convertir los departamentos de sistemas en máquinas perfectas (como si eso bastara), una de las expresiones más utilizadas para vender y comprar servicios de soporte IT es “mejora contínua”.

Seguir leyendo…

En enero de 2008 me incorporé en un equipo de soporte IT formado por 5 personas, donde desempeñé el rol de administrador de sistemas; el cliente era un grupo empresarial privado al que mi empresa vendió un servicio de soporte gestionado y la implantación de algunos procesos ITIL: gestión de incidentes, gestión de problemas y gestión de cambios.
Yo nunca conocí nada parecido, en el mundo de la administración de sistemas, a la gestión de problemas, cuya misión es encontrar la causa raíz que subyace bajo los incidentes graves o recurrentes, y una vez encontrada, proponer un cambio (en la infrastructura, en los procedimientos de operación, en la documentación o donde haga falta) para erradicar esa causa y, por tanto, erradicar la recurrencia de esos incidentes.
Estos procesos son comunes en cadenas de producción industrial, descritos desde hace años en estándares como Six Sigma y otras tambien basadas en el ciclo de Deming, pero descubrí que en el entorno IT resulta muy complejo implantarlos con éxito; pensé que sería debido a la idiosincrasia particular de la empresa en la que intentábamos implantarla, pero tras varias charlas con colegas y algunas búsquedas en Google descubrí que el mayor obstáculo es que clientes, proveedores y técnicos no comprenden adecuadamente el análisis de causa raíz (RCA en adelante, siglas en inglés de la expresión Root Cause Análisis).
Entienden, en la mayoría de casos, la importancia que puede tener para la mejora de la infrastructura, del servicio ofrecido por el departamento IT, incluso alguno es capaz de medir esa importancia con conceptos avanzados como TCO y ROI (y la ventaja que el uso de esos datos frente a la Dirección aporta), pero en pocos casos se entrevé un conocimiento profundo del RCA, de la visión necesaria para afrontarla, de qué información relevante debe desprenderse de un RCA, qué output esperar y cómo usar esa información.
Esto provoca que una implantación de ITIL en una organización sea incapaz de completar los 4 pasos del ciclo de Deming, convirtiendo el ciclo “Plan, Do, Check, Act” en “Plan, Do, Stop”.
Algunos de los obstáculos principales que se pueden encontrar en una organización (y más que obstáculos, frecuentemente, es resistencia del propio departamento IT), incluyen excusas como:

• No hay tiempo: los técnicos no disponen de tiempo para efectuar RCA, porque casi todo su tiempo lo invierten en apagar fuegos; no implementar la gestión de problemas o cualquier otro método de RCA, y obviamente ejecutar los cambios que se extraigan como solución para extirpar la causa raíz de dichos incidentes, alimenta esos fuegos y las tareas de extinción consumen cada vez más tiempo, más recursos… y consumen tambien la imagen de profesionalidad que pueda quedarle al equipo IT en la organización.

• No hay dinero: un cambio, casi siempre, requiere una inversión; si de un RCA se espera como salida una propuesta de cambio, se debe contar con la necesidad de realizar un gasto (gasto, por otro lado, justificable simplemente con el contenido del RCA, si es correcto, profundo y bien documentado). La realidad es: pueden los jefes de unidades IT conseguir ese dinero? Están dispuestos a partidas ya asignadas, por ejemplo, a la renovación de la electrónica de red, solicitada, sin embargo, con muchos menos argumentos que la petición de cambio extraída de un RCA? Tienen estos responsables una visión clara y realista del coste que tienen, para su departamento y para toda la organización, los incidentes IT (el descenso en la productividad de los usuarios afectados o las horas invertidas por el personal IT en solventar esos incidentes?)

• No se sabe a ciencia cierta de qué incidentes se trata: los técnicos de un Service Desk están más preocupados por resolver las incidencias que reciben que por recoger todo tipo de detalles relativos a las circunstancias en que se ha producido el incidente; asimismo, suele ser frecuente el desinterés a la hora de relatar las acciones seguidas para solventarlo, si resuelven el incidente. Por último, los service desks suelen contar con un sistema manual de clasificación y calificación de incidentes; esto hace que la relación de incidentes atribuibles a una causa raíz común sea generalmente incompleta, parcial y pobre, y dificulta cuantizar tanto el impacto que tendría sobre la organización no erradicar el problema que se está analizando como el beneficio de implementar el cambio propuesto para erradicarlo.

Todo lo anteriormente expuesto, cristaliza, en el mundo real, en una pregunta que directivos, responsables IT y técnicos lanzan al que defiende la imperiosa necesidad de implantar la gestión de problemas y los RCA: “¿para qué?”.

Y eso demuestra que no sólo no comprenden la importancia de conocer la causa raíz que detona los incidentes graves en su organización, sino que tampoco tienen una visión clara del impacto que incidentes graves o menos graves tienen sobre la productividad de su organización y, aún peor: de su departamento.

Sobre esto último tengo que hablar largo y tendido, porque otra de las actitudes que más detesto en el mundo de la informática es la incentivar el comportamiento de bombero entre los técnicos, el considerar héroes a los resolutores veloces de incidencias graves y fomentar la actitud cowboy de cabalgar a lo loco sobre la administración de sistemas. Este es el rollo en el equipo donde trabajo ahora, y la verdad es que se tiene que acabar, es demasiado 90′s…

Por qué no mejora la calidad de algunos servicios TI

La mayoría de las metodologías orientadas a la mejora continua de la calidad se fundamentan sobre las teorías de Deming desarrolladas después de la Segunda Guerra Mundial, que contribuyeron al milagro japonés de la postguerra; uno de los pilares sobre los que se apoyaba el trabajo de Deming era su ciclo PDCA (Plan, Do, Check, Act: planea, haz, revisa, actua).

ITIL tambien usa ese ciclo de Deming como piedra fundacional de todo el sistema de buenas prácticas, pero con una salvedad: la mayoría de representaciones del ciclo de Deming que aparecen en publicaciones de ITIL ¡están mal!¡giran mal!

ITIL representa el ciclo de Deming como una bola que gira a lo largo de un plano inclinado, que representa el aumento en el nivel de calidad del servicio prestado en cada iteración del ciclo, pero tal y como lo proponen, en vez de PDCA el ciclo se convierte en PACD, y así no va; así no funciona.

Por suerte, frente a los fanáticos fervientes de ITIL y otras metodologías de mejora continua de la calidad, existen los escépticos.

*Encontrado en The IT Skeptic.