Posted: Junio 26th, 2009 | Author: jbanez | Filed under: Sin categoría | Tags: Uncategorized | 2 Comments »
Hace un rato, he recibido un mail de un centro de formación TI ofreciendo cursos de ITIL V2 Practitiioner, parcialmente subvencionados por la Generalitat de Catalunya. Estoy hablando sobre cursos de “Service support” y “Service delivery”, ya sabeis, todo ese rollo de ITIL V2. O sea, espero que quede claro: es V2 de lo que se habla, en ese mail, ni rastro de V3 en ninguna línea de ese correo.
Insisto tanto en lo de que solo hay cursos de ITIL V2 porque en España se ha establecido la opinión general de que V2 es mejor que V3, aunque nadie sabe decir exactamente por qué.
Después del salto, las tont… perdón, justificaciones más comunes para apoyar semejante afirmación…
Posted: Junio 12th, 2009 | Author: jbanez | Filed under: rca | Tags: analisis de causa raiz, gestion de problemas, rca | No Comments »
El análisis de causa raíz (RCA) es una actividad intuitiva y nos sentimos naturalmente inclinados a hacerlo en nuestra vida cotidiana; disponemos de las técnicas y los métodos para realizar análisis profundos y precisos de nuestros eventos diarios, desde la enumeración de factores causales hasta la generación de recomendaciones y la implementación de cambios para eliminar la causa subyacente.
¿Por qué resulta entonces tan difícil trasladar esa habilidad al entorno laboral?
A nivel de gerencia IT, existe una cierta conciencia sobre la necesidad de integrar la gestión de problemas dentro de los procesos de gestión IT, pero con muchas reticencias a la hora de implementarla efectivamente, basándose en un puñado de motivos poco fundamentados. Es de esperar que si la dirección es resistente a la adopción de la gestión de problemas, más lo serán los técnicos implicados en ejecutarlo, por partida doble:
- El primer efecto percibido es un aumento en su carga de trabajo: cualquier organización mediana o pequeña evitará la dedicación exclusiva de ningún recurso al análisis de causa raíz porque es caro; de manera inmediata, sin entrar en cálculos de ROIs o VOIs y otros indicadores aún más etéreos, es cierto que supone un desembolso desde el inicio. Los técnicos han de compaginar en su jornada la prestación rutinaria del servicio y, además, investigar incidencias graves o recurrentes, y una vez hallada la causa raíz, proponer los cambios y mejoras necesarios para erradicarla.
- El administrador de sistemas medio no sabe por dónde empezar… pero tampoco dónde acabar.
Ese fue mi caso cuando me vi por primera vez en el brete de hacer un RCA y gestionar un problema: “¿cómo hago un análisis de causa raíz?”
Después del salto, intento arrojar algo de luz sobre esto…
El terror del registro de problema en blanco
Imaginemos: el ServiceDesk recibe un aluvión de llamadas de usuarios reportando que no les funciona el correo electrónico; se inicia el proceso de Incidente Grave, se desencadena el plan de acción, llega a Sistemas y un administrador lo resuelve; actualiza el registro de incidencia con la información de la resolución y se comunica a los usuarios el restablecimiento del servicio.
En una organización que haya iniciado la adopción de ITIL, un incidente grave requiere la apertura de una investigación de problema; y ante la extensión inmaculada del registro de problema recién abierto se encuentra el administrador de sistemas encargado de completarlo. ¿Por dónde empezar?
Lo primero: identificar el servicio y sus componentes afectados por el incidente, algo que ya no es trivial en un departamento que no haya adoptado la Gestión de la Configuración y que tenga un catálogo de servicios incompleto, con poca sustancia, en resumen: más bien flojo. Tener que hacer el ejercicio de determinar los componentes de un servicio afectados por un incidente durante la investigación de problema tiene una ventaja: puede convertir esa información generada en input para la Gestión del Catálogo de Servicios para enriquecerlo y así hacerlo más preciso y útil.
Lo siguiente es saber cómo documentar un registro de problema; requiere que contenga una descripción fiel y detallada del desarrollo de los acontecimientos desde la primera notificación del incidente hasta su resolución. La forma más clara: contarlo como si fuera una crónica periodística, en la que se establece primero el marco del suceso (fecha, hora y lugar) y después se detalla la secuencia cronológica de eventos. Una vez realizada esta crónica, comienza el análisis; para realizar esa parte, es conveniente disponer de un cuerpo de preguntas que:
- vertebre la investigación
- prevenga el dejar cabos sueltos o áreas de responsabilidad vacías
- nos ayude a identificar y formalizar las mejoras que conformarán la solución permanente al problema, y que es, en definitiva, el producto principal que debe extraerse de la gestión de problemas.
Exponiendo los hechos: la verdad, toda la verdad y nada más que la verdad
Un registro típico de problema podría empezar con algo como:
“A las 10:15 am, el usuario Joaquín Báñez contactó al Service Desk por teléfono y reportó que al abrir MS Outlook para acceder al correo se producía el siguiente mensaje de error…”
El primer paso en la investigación es, por tanto, recopilar todos los registros de incidencias relacionados con el problema que tratamos; el primero de ellos, se convertirá en el cabo del ovillo del que iremos tirando para responder a una colección de preguntas similar a:
- cuándo fue detectado el incidente?
- cómo se detectó?
- ¿qué se hizo para resolverlo?
- ¿qué impacto causó a los usuarios?
- ¿ha pasado antes? ¿es un problema recurrente?
- ¿se pudo de alguna manera detectar antes este problema?
- ¿se pudo de alguna manera resolver antes este problema?
- ¿existía documentación sobre esta incidencia en la base de datos de conocimiento? En tal caso, la instrucción de trabajo era adecuada para la resolución?
- ¿Debe algún otro equipo o proveedor estar involucrado en la investigación del problema?
En siguientes entradas, daré más detalles sobre cómo documentar, argumentar y contestar, de manera metódica y estructurada (y, sobretodo, documentada), todas estas preguntas.
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: Junio 2nd, 2009 | Author: jbanez | Filed under: it | Tags: analisis, gartner, hype cycle, it, magic quadrant, research, tendencias | 3 Comments »
No creo que haya ninguna fuente de información del mundo IT más importante que Gartner; ofrece análisis e investigación sobre casi cualquier aspecto relacionado con el universo tecnológico. Es donde debe uno acudir para saber en qué fase del hype-cycle se encuentra la movida del cloud computing, si lo del VDI es la poción mágica que liberará a las empresas de la poco carísima y poco productiva gestión de escritorios, qué nivel de madurez se ha alcanzado en la adopción de procesos ITIL, CobIT, Six Sigma o CMMI, se discute la pertinencia de conseguir una ISO 20000, cuál es el proveedor más molón en cada área tecnológica…
Leer más…
