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.
Southern ITIL 