20 cosas acerca de ITIL

Image by icanmakeit.de via Flickr Autor: Jose Antonio Trujillo, CIO Perú
Fuente: CIO Perú
Agradecemos a Franca Cavassa, Directora de CIO Perú la autorización para la publicación del presente artículo.




Embarcarse en un proyecto ITIL (Information Technology Infraestructure Library) es cosa seria. Es modificar costumbres (malas y buenas), instaurar procesos y, en general, hacer más sistemática la forma en que se desarrollan las cosas al interior de una organización.

 

No es sencillo. Las personas generalmente se resisten al cambio, es decir, a dejar de hacer las cosas tal y como las venían haciendo por mucho tiempo, y quizás con buenos resultados. ¿Por qué cambiar entonces? La respuesta es simple: porque las cosas se pueden hacer mejor. Y de esta convicción depende el éxito de los proyectos de ITIL. Depende -en gran medida- de las personas, de que los trabajadores operativos vean las bondades del cambio, pero que también sea evidente para la alta gerencia e incluso para el directorio.

 

Es por ello que las reuniones de ITIL se están multiplicando. Aprender de la experiencia de otros y de la de los expertos en la implementación de estos proyectos es vital si se desea llegar a buen puerto. Pink Elephant, la organización que por años se ha dedicado a difundir estas mejores prácticas, tuvo recientemente una reunión en Lima en la que se decidió a “romper los grandes mitos de ITIL” con la participación de un conjunto de expositores que mostraron sus experiencias en diversos campos.

 

De ellos rescatamos las presentaciones de dos viejos conocidos: José Manuel Flores, director general de Pink Elephant México, y George Spalding, vicepresidente de Pink Elephant. Cada uno de ellos expuso sobre 10 cosas importantes a considerar dentro del campo de ITIL, y lo que a continuación les presentamos es una breve reseña de sus discursos.

 

10 equivocaciones

Flores fue directamente al punto. De acuerdo a su experiencia como consultor se pueden establecer diez equivocaciones que las organizaciones generalmente comenten durante el primer año de la implementación de un proyecto ITIL. Quizás no sean todas, pero son las más representativas de acuerdo al representante mexicano.

La primera de ellas es no tener una visión de hacia donde queremos dirigirnos con un proyecto ITIL. Este primer error es fundamental y básico pues lo primero con lo que uno puede chocar es con la sensación generalizada de que “si todos estamos de acuerdo en como se hacen las cosas, ¿para qué cambiarlo?”. Flores señala que debe haber una visión clara de para qué se desea el proyecto; y si ésta no se tiene, hay que replanteársela.

 

El segundo error más común es pensar que no es necesario el apoyo de la alta dirección. No es suficiente con los mandos medios, “Nos hemos encontrado con empresas donde los proyectos nacen por una iniciativa de la gerencia media y deciden no involucrar a la alta dirección porque consideran que no van a tener tiempo para ella. Cuando no se tiene un patrocinador ejecutivo, el dinero y el tiempo de la gente no están asegurados y el proyecto se encuentra en peligro”, señala el ejecutivo.

 

Flores agrega que se requiere de la figura de un champion del proyecto en el directorio de la organización; es decir, de la persona que va a ser una especie de representante ante los directores cada vez que se soliciten recursos para el proyecto. Hay que tomar en cuenta que un directorio probablemente no entiende el tema, y que la forma de vender el proyecto es decirle a este órgano que se va a habilitar un proceso de negocio o la disponibilidad de un proceso de negocio.

 

El tercer error es considerar que no se necesita un caso de negocio. La realidad es que no se llega a ningún lado con una propuesta de ITIL, que no logre articular con claridad los beneficios para el negocio en la implementación del proceso. Por tanto, es necesario hacer un business case, crear una base de referencia (base line) y métricas para respaldar las evidencias de éxito.

 

La cuarta equivocación es considerar que no se va a necesitar una base de referencia (base line) al inicio y que es mejor dejarla para después de la implementación, para mostrar a la gerencia la madurez alcanzada por el proyecto.

 

Lo malo de cometer este error es que no se puede demostrar que se ha mejorado sino se sabe de dónde se partió. Además es bueno saber que le ‘duele’ al cliente para saber qué ‘medicina’ se le debe aplicar. Flores señaló -adicionalmente- que es necesario definir quick wins, es decir, ganancias rápidas. “Un proyecto de procesos que no presenta ganancias rápidas es un proyecto perdido, porque a los ojos de la alta dirección se lo va a ver como algo innecesario”, sostuvo Flores.

 

La quinta equivocación es considerar que este no es proyecto estratégico. Al hacerlo se implementa como si fuera una actividad más, y eso incita a que no se formalice el proyecto ni se estime los recursos necesarios. Esto, a la larga, trae como consecuencia que los recursos se estresen al límite de su capacidad de trabajo. “No se trata de quién esté disponible, sino que se necesita gente con habilidades y motivación para hacer que el proyecto sea un éxito”, asegura.

 

La equivocación seis consiste en pensar que no se requiere de una estrategia de comunicación. Flores enfatizó que un elemento fundamental para el éxito es desarrollar una estrategia y un plan de comunicaciones. Y para ello se deben utilizar todos los elementos que se tengan a mano (mouse pads, salvapantallas, tazas, videos, sitio web corporativo, etc.). Además es bueno y recomendable involucrar a las áreas de recursos humanos y márketing en este esfuerzo.

 

La sétima equivocación es considerar que no se necesita de una estrategia general. Al contrario, se requiere de una estrategia general que defina elementos comunes a todas las instancias involucradas en el cambio. Es bueno contar aquí con una estructura de documentación para el proceso que abarque hasta cuatro niveles: política; procesos, roles y medidas; instrucciones de trabajo; y formularios, registros y documentos.

 

El octavo error es pensar que la implementación no va a durar mucho tiempo. “Hemos visto organizaciones donde los proveedores les han dicho que iban a implementar todo en uno o dos meses. Hay otros que les venden el software con plantillas y señalan que pueden implementar todo en 20 días. La realidad es que esto no funciona así”, sostiene Flores.

 

Primero se debe definir un proceso acorde con lo que va a traer beneficios para la organización y con la estrategia que se definió, y luego se puede escoger la herramienta. Como señala Flores, todo lo que dicen los libros no necesariamente se aplica en la organización. Este es otro error garrafal de los consultores.

 

El penúltimo error que se comente es no considerar los alcances del proyecto. Se tiene que administrar el proyecto y las expectativas que éste genera. Y aquí es necesario tener cuidado al pensar que en el alcance todo está interrelacionado, y que por tanto no se puede cambiar nada.

 

Finalmente, la última equivocación es no esperar una resistencia importante al proyecto. No hay que subestimar los factores relacionados con el personal, sobre todo si se toma en cuenta que las personas racionalizan el cambio primero a nivel emocional y después a nivel lógico. De hecho, hay que esperar la resistencia al cambio y utilizar una metodología de administración del cambio.

 

Lo que quieren escuchar

George Spalding fue el siguiente expositor del evento. Para no quedarse atrás Spalding también confeccionó una lista de 10 cosas que se deben de tomar en cuenta en los proyectos de ITIL. En esta ocasión lo que ofreció fueron las “10 cosas que al CEO o CFO les gustaría escuchar”, una serie de frases que esconden algunas enseñanzas sobre el trabajo de TI en las organizaciones.

 

La primera frase es “tengo una visión estratégica sobre la forma en que TI se integra exitosamente con el negocio”. Spalding, con su característico buen humor, señaló que generalmente en las reuniones se cuenta con una sesión a la que se denomina la “Sesión de Alineamiento de TI con los negocios”, lo cual indica que TI ha crecido separada de los negocios. Pero en la actualidad todas las empresas tienen procesos de negocios que involucran tecnología, de hecho, se encuentran en su core.

 

“Pero la pregunta es ¿nos vemos en el core de los negocios? ¿El negocio nos ve en el core?”, se preguntó Spalding. Algunas veces. Y quizás eso significa que ambos tienen visiones diferentes del mundo, y por eso es que se necesita estos ‘alineamientos’. En realidad, lo que se necesita es que TI se encuentre integrada dentro del negocio, y esto no es opcional. Lo extraño es que esto es algo que solo se pide a TI. ¿Alguna vez se ha escuchado del alineamiento del departamento de finanzas? ¿Márketing? Todos ellos se ven como parte del negocio, pero TI se ve a sí misma, debido a la forma en que se desarrolló, como algo externo al negocio.

 

La segunda frase de Spalding es: “He desarrollado un framework de medición así que podemos ver como le está yendo a TI”. Uno en realidad debería medir todo lo que pueda, ya que son las mediciones las que proporcionan una línea base para poder realizar las modificaciones necesarias.

 

Lo primero que uno puede hacer es imaginar qué puede medir, y en un segundo paso determinar qué puede medir en realidad; ya que algunas de las cosas que se quieren medir, en realidad no se van a poder hacerlo. Por ejemplo, el uptime de un servicio como el correo electrónico. Uno puede medir los componentes pero si un usuario no tiene acceso al correo, para él el uptime es cero -a pesar de las cifras que uno pueda tener. La escena cambia si ese usuario es el CEO, por su puesto. Entonces uno no mide todo, sino solo aquello que es significativo, y por significativo podemos entender aquello que nos pueda producir algún cambio.

 

La tercera frase del expositor fue: “No se preocupen, tengo todo bajo control”. ¿Sabe qué componentes tiene en su infraestructura? Si puede responder que sí entonces responda lo siguiente: ¿sabe dónde se encuentran todos esos componentes? ¿Sabe con qué otros componentes se conectan? ¿Qué relación tienen con los procesos o los servicios? Seguramente que no. Pero Spalding advierte: su jefe sí le va a creer que tiene todo bajo control.

 

En realidad uno no tiene nada bajo control, sino solo un poco de personas que lo pueden ayudar.

 

La cuarta frase: “El próximo año TI costará menos? liberando dinero para proyectos de valor añadido”. Cuando se habla de dinero en TI, se puede apreciar que antes el hardware solía ser la parte cara de TI, pero ya no lo es. El hardware es cada vez mas barato. Mientras la mano de obra y de soporte ha subido exorbitantemente. Y se inventaron los blades y la virtualización, todo enfocado en el hardware, y luego se inventó la nube que es muy barata. Y sin embargo, la parte del presupuesto que se destina a ‘mantener prendidas las luces’ significa un 70% del total.

 

Esta parte del presupuesto se destina entonces a algo que se ha convertido en ‘invisible’, nadie sabe donde se encuentra. Y son más bien las funcionalidades, las partes más visibles para el resto de la organización, las que se llevan un porcentaje más pequeño del presupuesto.

 

“Creo que TI es el cliente del outsourcing no su competidor”, señaló Spalding, refiriéndose que ante las posibilidades de hacer outsourcing para resolver las necesidades de la compañía, el departamento de TI debe comportarse como la parte de la firma que se va a encargar del outsourcing y no a sufrir por él. TI, desde esta perspectiva, debe ser el único proveedor de servicios para la organización.

 

A la mitad de su presentación Spalding lanzó su quinta frase: “nuestros costos están bajando. Nuestro uptime” está subiendo. Esto significa mayor productividad de nuestro personal actual.

 

¿Cuándo ocurren los incidentes? Generalmente los lunes. ¿Cuándo se realizan los cambios a los sistemas? Los fines de semana. ¿Se ve la relación? Entonces es momento de arreglar la administración que se realiza de los cambios. “Hacemos mal las cosas”, sentenció Spalding. La solución es tener el control absoluto de todos los cambios en el ambiente de producción.

 

La sexta frase es de antología: “Los proyectos de TI se están llevando a cabo dentro de los plazos, dentro del presupuesto y superando las especificaciones de calidad”.

 

“Si creen en esto les digo que tengo un puente en Nueva York que me gustaría venderles”, bromeó Spalding. Lamentablemente, las estadísticas sobre el éxito de los proyectos, siguen siendo las mismas que hace diez años: el 33% tienen éxito, el 67% fallan. Y por falla se debe entender que cuestan más de lo que suponía que debían costar, o se requirió de mayores plazos a los supuestos, o no hace lo que se suponía que debía hacer desde un inicio, o una combinación de estos tres casos.

 

Ese es un record muy pobre para los proyectos de TI, y no ha mejorado en diez años. A pesar de todas las metodologías de administración de procesos y certificaciones no se hace bien, y ciertamente no siempre es culpa de la gente de TI, pero la verdad es que los proyectos no se hacen bien. “Y no estoy seguro de la razón”, sostuvo Spalding. Pero una buena pista es que si se culpa a otra persona por el error, también se debe recordar que cuando esa persona realizaba la acción que iba a estropear el proyecto, todos los demás se quedaron callados. Y el proyecto falla.

 

La siguiente frase tiene que ver con una falsa sensación de mejora: “Los llamados por incidentes a la Mesa de Servicio han bajado, pero las solicitudes de servicio han subido. Esto significa que como las cosas se descomponen menos los usuarios están encontrando nuevas formas de usar sus sistemas”.

 

La extensa frase tiene más de una explicación. Una es que los llamados a la Mesa de Servicios han bajado porque el servicio es tan malo que todos han dejado de llamar. El otro tiene que ver con una de las medidas más utilizadas en la evaluación de una mesa de ayuda: la resolución del problema a la primera llamada. Tener una alta tasa de resolución de incidentes en la primera llamada se logra gracias a que hay una alta tasa de incidentes repetidos. La mesa de ayuda repara el mismo incidente una y otra vez, y cuando se hace eso se logra una alta tasa de resoluciones a la primera llamada. Pero si se le pregunta a la Mesa de Ayuda de dónde provienen los incidentes lo más probable es que no tengan la menor idea.

 

La solución es llegar a la raíz del problema y eliminarla. Esto no solo reduce el número de incidentes sino también el número de incidentes repetidos, lo que ocasiona que la mesa de ayuda enfrente incidentes nuevos. El tiempo de resolución de los incidentes sube y la resolución a la primera llamada cae. Así que uno repara la raíz de los incidentes, pero puede ser penalizado porque su tasa de incidentes resueltos a la primera llamada se desploma.

 

“Las únicas personas felices con todo esto son los clientes”, bromeó nuevamente Spalding.

 

La siguiente frase fue sacada de un caso real: “Detengamos todo y volvamos a hacer los procesos para poder pasar la auditoría”.

 

Spalding fue a una compañía y pidió que le mostraran el proceso de cambios. “¿Cuál?”, le preguntaron. “¿Cuántos tienen?” “Solo dos. El verdadero, y el que creamos para los malditos auditores” “¿Son el mismo?” “No, no hubiéramos podido pasar la auditoría con el verdadero”

 

“Es una historia real. Pero la moraleja es que los auditores no deben de ser llamados al final del diseño de un proceso sino desde el inicio para que ellos puedan garantizar que es auditable, medible y que podrán revisarlo también luego”, sostuvo el expositor.

 

La penúltima frase: “Nuestra gente de seguridad ha dejado de hacer las cosas por su cuenta y ahora están usando un estándar de seguridad TI de nivel mundial”.

 

Las personas de seguridad siempre buscan un framework que les de una ruta para responder a la eterna pregunta: ¿Cuán seguros quieren ser? Uno puede estar completamente seguro, pero lo mejor es utilizar los entornos de seguridad que ofrecen los estándares como los ISO.

 

La frase final fue: “Estamos realizando más cambios que nunca, pero con menos impacto negativo”.

 

Esto permite que TI sea más responsable con las solicitudes del negocio. Algunos consideran que TI debe escuchar al negocio y luego hacer lo que le piden porque el cliente siempre tiene la razón. “Pero eso no es cierto”, sostuvo. Los usuarios esperan que se les brinden los servicios que piden, pero que todo lo demás siga funcionando bien. Ellos no van a pedir algo que ponga en peligro la infraestructura porque no saben lo que están pidiendo. TI les debe decir a los usuarios que esa pequeña cosita que piden puede poner en problemas a toda la infraestructura.