Posted: Enero 12th, 2010 | Author: jbanez | Filed under: Sin categoría, itil | Tags: gestión de servicios, herramientas, itil, Sin categoría, soporte | 1 Comment »
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…
Seguir leyendo…
Posted: Diciembre 21st, 2009 | Author: jbanez | Filed under: itil | Tags: cambio, cambio cultural, gestión de servicios, herramientas, implantación, itil | 4 Comments »
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…
Y qué pasa después?
Posted: Diciembre 10th, 2009 | Author: jbanez | Filed under: itil | Tags: calidad, catálogo de servicios, estrategia del servicio, itil, itil v3, orientación a cliente | No Comments »
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…
Seguir leyendo…
Posted: Diciembre 2nd, 2009 | Author: jbanez | Filed under: itil | Tags: certificacion, itil, itil v3, ogc | 2 Comments »
La OGC ha anunciado hoy el lanzamiento de la Certificación Oficial ITIL V3 Master.
Posted: Noviembre 18th, 2009 | Author: jbanez | Filed under: itil | Tags: itil, ogc, tso | 11 Comments »
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!
Posted: Junio 2nd, 2009 | Author: jbanez | Filed under: itil | Tags: gestion de cambios, gestion de incidencias, gestión del conocimiento, itil, knowledge management, servicedesk, twitter | No Comments »
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.
Posted: Abril 27th, 2009 | Author: jbanez | Filed under: itil, rca, root cause analysis | Tags: analisis de causa raiz, deming, gestion de problemas, ingenieria, itil, metodologia, rca, root cause analysis, six sigma | 2 Comments »
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…
Posted: Abril 27th, 2009 | Author: jbanez | Filed under: itil | Tags: calidad, ciclo, continual quality improvement, deming, deming cycle, it skeptic, itil, mejora continua, pdca, quality management | No Comments »
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.
