ITIL-es » itil

La detección de problemas es asunto de todos

jbanez — Wed, 28 Apr 2010 15:15:43 +0000

Hace unas semanas preparaba la presentación del proyecto de adopción de la Gestión de Problemas para nuestro cliente; una de las diapositivas hacía referencia a quién podía registrar un problema y cuándo debía hacerse; inicialmente, pensaba incluir los típicos actores, los técnicos del SAU, los de Sistemas, los técnicos de cualquier equipo, desarrolladores… luego pensé que era más conveniente ampliar la lista e incluir a los usuarios. Hasta que al final pensé que no era adecuado hacer una lista de autorizados para la detección de problemas, sino transmitir la necesidad de que cada persona relacionada con la organización debe implicarse en la detección de problemas.

Un departamento de sistemas puede tener un equipo dedicado a la investigación y resolución de problemas (¡bienaventurados aquellos con el presupuesto para tenerlo!), y no es exigible al resto de empleados la resolución de los problemas. Pero la detección sí: cabe esperar de cualquier técnico o usuario que vea un posible problema, un agujero, un fallo, lo que sea, que de inmediato aviso de tal fallo.

Un “no es mi trabajo” no es aceptable: los que saben arreglar cosas, deben arreglarlas; los que no saben, deben avisar a alguien que sepa. Y después hacer un seguimiento formal mediante Gestión de Problemas de cada uno de estos problemas para que ninguno se pierda.

Finalmente, concluí la diapositiva con un sucinto “Todos los implicados con los servicios TI deben involucrarse en la detección de problemas proactivamente y debe premiarse el esfuerzo en la detección y la resolución de problemas”.

Sobre el cuándo debe abrirse un problema, fui incluso más sucinto, y sólo incluí: “siempre que sea necesario, útil y que aporte valor”.

El caso es que aún no sé si la presentación fue del gusto del cliente o no. Quizás debería ser menos idealista y ceñirme al estándar español de generar problemas sólo cuando ITIL dice que es imprescindible…

CFIA o de cómo meter el pie en Gestión del a Disponibilidad y la Continuidad sin despeinarse

jbanez — Wed, 20 Jan 2010 08:41:52 +0000

A primera vista, es fácil ver que el Análisis de Impacto de Fallo de Componente (sus siglas en inglés son CFIA: Component Failure Impact Analysis) está relacionada de algún modo con los procesos de Gestión de Problemas y de Disponibilidad, pero sigue siendo un concepto algo difuso para la mayoría. Aunque CFIA suena guay y suena grande, es simplemente una forma de evaluar (y predecir) el impacto de fallos y caídas, y tambien ayuda a la localización de puntos únicos de fallo. Y todo lo que hace falta para hacer ese análisis es una hoja de Excel (o algo aún mejor…). Nada de sumar al pack de herramientas de gestión otra aplicación carísima.

El CFIA permite:

Identificar items de configuración (CI) que pueden provocar un corte de servicio
Localizar CIs que no están redundados o que por lo menos no tienen un backup
Evaluar el riesgo de fallo de cada CI
Justificar la demanda de inversiones
Colabora en la creación y mantenimiento de la CMDB.

Los 3 pasos clave para realizar el CFIA con éxito serían:

1. Seleccionar un servicio TI, obtener la lista de CIs que lo conforman; si tenemos la suerte de tener Gestión de la Configuración, lo obtendremos de ahí, si no… toca recopilar la documentación que tenga el departamento de sistemas y sonsacarle lo que podamos a los administradores: tirar de inventarios, de documentos, de manuales de explotación y de lo que se tenga a mano. O sea, lo de siempre.

2. En una hoja de Excel (o en un folio, o en cualquier papel), listar en la primera fila los servicios que estemos considerando y en una columna los CI que los componen; después, para cada CI bajo cada servicio:

Marca una “X” si un fallo del CI provoca una parada de servicio
Marca una “A” si el CI tiene backup inmediato (el backup entra en acción inmediatamente tras un fallo del CI)
Marca una “B” si el CI tiene backup intermedio (requiere una intervención para activar el backup y supone un corte en el servicio, aunque sea breve).

Con esto, se consigue una matriz básica de CFIA. Cada “X” y cada “B” representa una vulnerabilidad potencial, y el último paso, será generar una petición de cambio (RfC) para erradicarlas:

3. Evaluamos las “X” y las “B” de la matriz; las podemos analizar con preguntas del tipo

Es este CI un punto único de fallo?
Qué impacto tiene para el cliente/para el negocio el fallo de este CI? A cuántos usuarios afectará? Cuál será el coste para el negocio?
Cuál es la probabilidad de fallo? Qué puede cambiarse para evitar ese impacto?
Podría prevenirse ese impacto realizando algún cambio de diseño? Sería conveniente dotar ese CI de redundancia o hacerlo más robusto? Y en tal caso, cuánto costaría?

Realmente, es un método sencillo y muy resultón para empujar al departamento de TI a meter el pie en Gestión de la Disponibilidad, que no es uno de los procesos más populares ahora mismo; de paso, lo que me pregunto es si podría expandirse la matriz para incluir los procedimientos o instrucciones de trabajo de recuperación de fallo de esos CI, quizás añadiendolo como una fila en la parte inferior de la matriz CFIA, aunque esto requiere primero que el departamento de TI sea lo suficientemente maduro como para tener todo eso por escrito (voy a dar por hecho que sí; en caso contrario, no tiene ningún sentido plantearse ni CFIA ni disponibilidades sin tener lo más básico listo: algo de documentación).

Añadir la documentación a la matriz CFIA podría usarse para evaluar tanto la organización como la infrastructura, analizandolo con preguntas tipo:

Cómo se responde cuando ese CI falla?
Qué procedimientos se siguen? ¿Están documentados esos procedimientos?
¿Se pueden mejorar esos procedimientos? ¿Se pueden automatizar?
¿Se podrían mejorar los procedimientos formando al personal o usando nuevas técnicas o herramientas?
¿Se podría haber evitado el problema efectuando mantenimientos preventivos?

Si se logara la ejecución metódica y exhaustiva de análisis de impacto de fallo de componentes a todos los niveles (a nivel de infrastructura y de la organización), se generarán RfCs que aporten mejoras reales al negocio pero sin requerir un elevado nivel de madurez en los procesos ni derrochar en software de soporte. Tambien aporta beneficios al departamento TI, porque además de poner un primer pie en Gestión de la Disponibilidad tambien significa meter la cabeza en Gestión de la Continuidad; los datos obtenidos en la preparación de la matriz CFIA sirve como input para Gestión de la Configuración, sobretodo si se añade la documentación de recuperación, que puede aprovechar ese conocimiento para la CMDB. Y por supuesto, Gestión de Incidencias, que usará esos procedimientos de recuperación, y Gestión de Problemas, que recibirá como input el resultado de los análisis efectuados.

Hay que elegir una herramienta de gestión para implantar ITIL.

jbanez — Tue, 12 Jan 2010 14:47:45 +0000

Pese a que puede parecerlo, nunca he dicho que no sea conveniente usar una herramienta de gestión a la hora de implantar ITIL. Es conveniente, útil y contribuye a la gestión del servicio, de la mejora contínua, agiliza las tareas de todos los agentes implicados en la prestación de servicios y tambien de los usuarios. Permite obtener información consistente y útil sobre desempeño, uso, disponibilidad, etc. Muchas cosas. Mola.

Pero para que todo esto sea verdad, es necesario que esa herramienta sea realmente adecuada para apoyar la gestión de servicios basada en ITIL…

Para comprobarlo, Pink Elephant, auténticos apóstoles de ITIL y sin duda de las empresas más reconocidas por su conocimiento y experiencia en ITIL, creó el sistema Pink VERIFY. Recoge una serie de requisitos de cumplimiento obligatorio y otros de integración que ha de cumplir una herramienta software para considerarla apta para apoyar la gestión por procesos ITIL. Y está disponible de forma gratuita.

Si teneis que valorar alguna herramienta de soporte, es recomendable imprescindible contar con estos formularios.

Y si teneis que elegir una, Pink VERIFY cuenta con una lista extensa de herramientas ya validadas y aptas.

Por cierto: una herramienta sólo es válida si cumple el 100 % de los criterios obligatorios. No vale menos.

Implantar ITIL va de implantar procesos, no de implantar (más) herramientas de gestión

jbanez — Mon, 21 Dec 2009 08:44:00 +0000

Contratar una consultoría de assesment e implantación de ITIL cuesta un dineral, pero es un producto que, en esta época de crisis, se vende bien. Muchas empresas se han tenido que subir a la movida de ITIL porque algunos directivos creen ver la posibilidad de suturar, al menos parcialmente, la sangrante herida que el departamento de informática supone a la organización. Otros, como algunas administraciones públicas, se han tenido que subir al carro por motivos legales y de convergencia con la Unión Europea.

Si no existe cierto entusiasmo por abrazar ITIL, todo son pegas: los directores de Informática leen la mini-guía de introducción a ITIL y quizás asistan a un par de seminarios donde obtienen una visión general de la gestión por procesos, de cómo los define ITIL y a qué están orientados, y algunos casos de éxito de implantación de ITIL en organizaciones…

De estos seminarios salen con 2 ideas muy claras:

Necesitamos una herramienta para “gestionar ITIL”: y esto se vuelve una obsesión y alcanza una prioridad tan alta elegir esa herramienta que acaba convirtiendose en el foco del proyecto de implantación de ITIL, desplazando el objetivo principal que es… pues empezar a gestionar las TI según las mejores prácticas de ITIL.
Lo de ITIL es muy bonito, si el mundo fuera perfecto, pero tendremos que cambiar algunos procesos porque no se adaptan a lo que nosotros hacemos: hay que tener valor para decir que ITIL, aceptado mundialmente como conjunto de mejores prácticas, no es bueno para nosotros. Vaya, que mejor cambiar ITIL que cambiar cómo funcionan las cosas en nuestra empresa.

Hoy, trataremos la primera perversión que arruina cualquier proyecto de implantación de ITIL.

1. Elegir qué software comprarán para gestionar las incidencias, los cambios y los problemas constituye una obsesión: se estudian soluciones variopintas que incluyen el desarollo ad hoc y otras locuras. La herramienta se convierte en el factor restrictivo del alcance de la implantación. La ambición de generar el cambio en el modelo de gestión TI de la organización es tan grande… como la herramienta permita, según ellos.

Casi todas las empresas tienen una aplicación para la gestión de incidencias, y seguramente esa ya vale. Para el resto de procesos, según el tamaño de la organización y los procesos que desplieguen, quizás no requieran nada aparte de aplicaciones ofimáticas. En cualquier caso, hay que resaltar que ITIL no contaba con un esquema de software hasta el 1 de diciembre de 2009, y lo lanzó como piloto. Es posible que en breve haya un aluvión de herramientas certificadas ITIL Process Compliant; para elegir una, en tal caso, habrá que olvidar si sirve para “gestionar ITIL”, la OGC certifica que sirve. Habrá que seguir los preceptos que se seguirían para cualquier otra compra: precio, flexibilidad, facilidad de uso y administración, robustez, integración con otras herramientas, opciones de entrega de la aplicación…

Pero es más: justo en una etapa de crisis económica, ¿por qué no ahorrar unos dineros en la implantación de ITIL recortando en la elección de las herramientas? Puestos a ser frugales, y suponiendo el caso más habitual (la empresa cuenta con una herramienta de gestión de incidencias y un sistema PIM o una intranet), el set de software necesario para implantar ITIL consistiría en:

Esa herramienta de que ya disponen para gestionar incidencias. De forma ideal, debería poder modificarse para adaptar las clasificaciones al Catálogo de Servicios
Una intranet o un sistema PIM con calendario y mensajería: para informar a los integrantes de la organización sobre los cambios planificados, impacto sobre servicios, paradas programadas, etc. Google Calendar es ideal. Hasta envía SMS gratis para avisar de los eventos planificados.
Google Docs: tiene un procesador de textos que admite plantillas: suficiente para redactar las peticiones de cambio. Una vez redactadas, se envían al CAB para revisión y aprobación. Tambien sirve para la gestión de problemas, que se beneficia de las hojas de cálculo de Google Docs, por ejemplo, para hacer mapas de causa raíz . Desde luego, para gestionar el Catálogo de Servicios, es suficiente una hoja de cálculo.

Habría más ejemplos de empleo de herramientas gratis, seguras y confiables que resolverían esa fase de elección de software. En cualquier caso, es algo inconsciente confiar la implantación de procesos de ITIL, que introducen cambios en la forma de actuar de personas y la forma de comunicarse entre ellas, a un producto software. No es de recibo que una implantación de ITIL fracase porque no hay consenso sobre qué herramienta comprar o, aún peor, porque la compra descalabra el presupuesto asignado a un proyecto mucho más ambicioso que la implantación de una herramienta software: el cambio organizacional que ITIL introduce.

Mañana hablaremos de la soberbia o, dicho de otro modo, de lo de “tendremos que cambiar algunos procesos porque no se adaptan a la forma en que nosotros hacemos las cosas”…

No esperes a tener tu Catálogo de Servicios cerrado: eso nunca va a pasar (si lo haces bien…)

jbanez — Thu, 10 Dec 2009 12:46:00 +0000

Moisés nos enseña su Catálogo de Servicios v1.0

Revisando peticiones de cambio que había que presentar al CAB semanal, he comentado con mi supervisor 2 de ellas en las que no estaba consignado el servicio afectado; en realidad, sí que constaba algo en el apartado “Servicio afectado”, pero no era un servicio recogido en el Catálogo de Servicios.

Mi jefe no ha querido sustituir lo que había en el campo “Servicio afectado” por alguno de los servicios que constan en el Catálogo porque “el catálogo de servicios aún no está cerrado”. Creía que quería decirme que el Catálogo de Servicios actual es un borrador y no está aún validado, pero no: quería decirme que el Catálogo de Servicios aún no está grabado en piedra, por así decirlo. Eso entiende por “cerrado”. Pues tengo que comentarle que, si hacemos las cosas como Dios manda, eso no va a pasar…

El Catálogo de Servicios no parece un concepto asequible pero quizás porque su utilidad no está tan bien definida como requeriría. O quizás, como yo lo veo, lo que está poco instaurado es el punto de vista con el que mirar al Catálogo de Servicios; es una herramienta que se crea desde la orientación al cliente, que es el punto débil de muchos proveedores de servicios, sean internos, externos, outsourcings, cosourcings o cualquier combinación.

“Orientación al cliente” es algo más que el servilismo que algunos practican o aceptar cualquier petición del cliente por descabellada que sea o por lejos que caiga del ámbito del contrato, de la oferta, del pliego y de todo lo acordado: orientación al cliente es querer ofrecer de forma más ajustada en cuanto a requerimientos de funcionalidad, económicos, de utilidad y de disponibilidad lo que el cliente necesita y que nos ha comprado. El Catálogo de Servicios ha de reflejar esta orientación al cliente; el ejemplo más claro de qué quiere decir esto lo he encontrado en esta entrada en el blog de Joseba Enjuto. En inglés aún lo dicen mejor usando “customer focus”, que puede traducirse como “concentración en el cliente”.

Esta orientación a cliente unido a la naturaleza propia de un mundo en constante cambio requiere que el Catálogo de Servicios sea algo orgánico, dinámico y flexible. El Catálogo de Servicios no se graba en piedra como los 10 Mandamientos; ITIL v3 recoge esto de forma magistral (convirtiendose, para mí, en el mayor acierto de la revisión de ITIL) colocando la Gestión del Catálogo de Servicios dentro de la fase “Estrategia del Servicio” como eje alrededor del cual gira todo el Ciclo de Vida del Servicio, como auténtico rotor.

Y a continuación, alguien que lo explica mucho mejor que yo (pero en inglés).

Anunciada la Certificación ITIL V3 Master

jbanez — Wed, 02 Dec 2009 11:27:00 +0000

La OGC ha anunciado hoy el lanzamiento de la Certificación Oficial ITIL V3 Master.

¡ITIL te busca!

jbanez — Wed, 18 Nov 2009 11:49:00 +0000

Cuando se lanzó ITIL V3 en junio de 2007, la OGC anunció el establecimiento de un programa cíclico de actualización y mejora de los libros de soporte, para tener en cuenta los últimos avances en mejores prácticas de Gestión de Servicios TI.

Ahora, la OGC y la Stationery Office (la editora de las publicaciones de la OGC) están reclutando colaboradores para actualizar las publicaciones principales (los 5 libros del Ciclo de Vida del Servicio y el de “Introducción al Ciclo de Vida del Servicio ITIL”). Los colaboradores se dividirán en dos categorías: autores y revisores.

Aquí se puede consultar el anuncio ofical. No queda del todo claro qué se obtiene a cambio, aparte del prestigio de aparecer en los créditos de los libros. Bueno, realmente, sólo eso sería más que suficiente para mí… aunque quizás podrían tambien regalar una invitación todo-incluido al próximo congreso del ITSMF… valdría la pena el esfuerzo (y podrían pensar en un destino exótico para el próximo, que Barcelona no me resulta precisamente atractiva -vivo ahí).

¿Qué te parece? ¿Te gustaría participar en la revisión de ITIL? ¿Te parece que esta campaña pública de reclutamiento es un buen paso para ampliar el alcance de ITIL e incorporar las nuevas tendencias (y, sobretodo, las nuevas realidades) a sus guías? Por favor, ¡comparte tus ideas en los comentarios!

Twitter + ITIL = Win-win combination

jbanez — Tue, 02 Jun 2009 20:49:00 +0000

Es un poco agotador leer casi cada día un post en un blog que contiene un caso de éxito del uso de Twitter en la empresa; algunos de ellos, obviamente, en equipos de soporte IT, aunque ninguno sobre cómo usarlo como herramienta de soporte en la gestión por procesos ITIL. ¿Cabe Twitter entre las herramientas de soporte ITIL?

Seguid leyendo e intentaré explicar cómo…

Daños autoinfligidos: la dolencia más frecuente

Una organización mediana o grande, con sistemas de gran complejidad o muy críticos (pongamos un aeropuerto o un banco de inversiones), posiblemente cuenta con un departamento IT grande, y posiblemente ya gestiona sus servicios IT con ITIL; son organizaciones que responden con rapidez a cualquier cambio en el negocio y exigen una respuesta igualmente rápida al departamento de IT; se registran, por tanto, un alto número de peticiones de cambio (RFC) semanalmente, sin contar los cambios de emergencia. No son compañías que puedan evitar hacer cambios en los meses de mayor volumen de negocio, que puedan esperar a periodos de baja actividad para implementarlos por temor a incidencias derivadas de un cambio; así no puede funcionar un negocio que se dedica a negociar fondos en bolsa, por ejemplo, y mucho menos establecer una diferencia competitiva con sus rivales. Los cambios han de diseñarse, evaluarse e implementarse contrarreloj.

Si para cualquier equipo, en cualquier área o sector, la comunicación es el punto más débil y habitualmente el más inmaduro, en un departamento de sistemas más o menos numeroso y que debe trabajar contra el reloj, es una problemática especialmente sensible; el correo electrónico ya no sirve como via rápida de comunicación dado el volumen de correo manejado a día de hoy por cualquier persona; cada llamada de teléfono supone una interrupción brusca en el ritmo de trabajo de un técnico. La mensajería instantánea se reveló de gran utilidad en sus inicios, pero se pervierte fácilmente su uso y se desvirtúa su bienintencionada finalidad.

El CAB debe evaluar y autorizar una gran cantidad de cambios; aunque se intente mantener una política de cambio estricta, es insensato esperar que todos los miembros del CAB revisen en profundidad cada RFC para evaluarlo; además los miembros no son semi-dioses con una visión completa y profunda de una plataforma compleja y en constante cambio que les permita detectar todos los posibles daños colaterales de una RFC. Ese es un conocimiento que, sin embargo, sí se encuentra distribuido entre los miembros del equipo técnico, pero esa información no se comparte ni se usa de manera eficiente y efectiva. Por si alguien lo está pensando, la solución no es que al CAB acudan todos los miembros del equipo y que todos revisen todas las RFC a evaluar, eso no sólo sería insensato…

La implementación de un cambio en el entorno descrito puede conducir, con facilidad, a incidentes graves en la infrastructura; y con facilidad, al revisar el incidente y gestionar el problema derivado, si se señala ese cambio como posible causa raíz, algún técnico acaba diciendo: “es que si me hubieran dicho que se iba a hacer X, yo hubiera avisado de que…”. Y el incidente, en tal caso, no se hubiera producido, o hubiera sido por otras causas. Dado el número de cambios realizados semanalmente en dicha empresa… el número de incidencias globales se vuelve inadmisible por las mismas razones que obligan a tantos cambios con tanta prisa.

Cómo usar Twitter y que resulte útil

Twitter puede verse como un chat asíncrono; no es una conversación en tiempo real, sino un tablón de anuncios donde cada miembro puede poner lo que quiera con la condición de que contenga menos de 140 caracteres.

Para usarlo en el departamento IT, cada técnico, antes de realizar un cambio (da igual de qué magnitud), publica en Twitter una breve nota (un “tweet”) con la descripción del cambio y el código de ticket donde está detallado; posiblemente, nadie conteste a esos anuncios y el cambio se realice sin más, pero en otras ocasiones, es posible que otro miembro del equipo reaccione ante el aviso para aportar algún dato no contemplado en la elaboración de la RFC, y así retrasar el cambio o cancelarlo, o ejecutar ciertas acciones antes de que se implemente el cambio para evitar una incidencia post-implementación.

Un beneficio derivado puede ser acortar el tiempo de resolución de incidentes graves; si, por ejemplo, un grupo de usuarios empieza a reportar que no reciben correo en sus Blackberrys y el último tweet avisa de un cambio en las políticas de firewall, la resolución podría comenzar por ejecutar el plan de retirada de ese cambio, así que el mean-time to restore tambien se beneficia, y el cumplimiento de niveles de servicio, etc.

Combinación ganadora

Los puntos fuertes de implantar una solución así serían:

El conocimiento se comparte de forma eficiente y rápida sin apenas carga adicional de trabajo, información o burocracia
Los incidentes graves provocados como daño colateral de la implementación de un cambio se reducen
Cuando esos incidentes se producen, la resolución puede ser más rápida por la asociación entre el anuncio del cambio en Twitter y la detección de la incidencia
Twitter es gratis, privado, fácil de usar y fácil de mantener
Para los paranoicos: hay aplicaciones opensource gratis (gratis como en “cerveza gratis“) tipo Twitter para instalar en casa como Chyrp

Moraleja: no temas al 2.0 ni a las redes sociales

La moraleja de toda esta historia es que no hay que temer el uso de las redes sociales ni de aplicaciones web 2.0, porque todas están enfocadas a resolver los problemas más frecuentes y más peligrosos en los equipos de sistemas: la distribución y el acceso a la información y al conocimiento de la infrastructura y los servicios. Una documentación completa, detallada y actualizada no siempre sirve para tener cambios perfectos y saludables que no impacten los servicios; a veces, el ingrediente necesario es la sabiduría de los técnicos, algo que ningún sistema de conocimiento puede gestionar, pero que aplicaciones como Twitter pueden invocar, si se usan correctamente.

RCA: incomprendida, mal valorada, pero sobretodo desconocida.

jbanez — Mon, 27 Apr 2009 15:01:00 +0000

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

jbanez — Mon, 27 Apr 2009 10:22:00 +0000

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.