Actualidad | Artículos | 16 FEB 2015

Guía de uso de mejores prácticas en ITSM

Adoptar un marco de referencia basado en mejores práctica no debería impedirnos utilizar otras fuentes, y mucho menos la más importante de todas.
Tecnologia_puzzle
Javier García Bolao

Tener una certificación ITIL Expert y haber estado trabajando durante los últimos años en el diseño de procesos para la gestión de TI me ha hecho granjearme entre mis colegas y conocidos una cierta fama de resabido y purista en lo que a ITSM se refiere.  Lo noto en que me miran de reojo en las reuniones profesionales; lo noto en algunas de sus respuestas a mis comentarios en foros y redes sociales.  No sé cómo, pero lo noto.

 

Nada más lejos de la realidad.  Y teniendo en cuenta que a ninguno de mis clientes le ha dado por pensar así, he decidido no preocuparme por ello y, de hecho, me he resignado a aceptar que es relativamente fácil ganarse inadvertidamente una cierta reputación de friki.  Sin embargo, sigo sin dejar pasar la ocasión de insistir en que ITIL no es más que un conjunto de mejores prácticas que sirve para gestionar servicios TIC, y que hay que entenderlo como tal.

 

Aclaremos conceptos: escalar una montaña vestido de Armani y calzando zapatos con suela de cuero no es una buena práctica.  Y no lo es porque es bien sabido que así no se avanza, que uno tiende a congelarse y que las posibilidades de despeñarse son ciertamente elevadas.  Se tendrá que hacer cuando no quede otro remedio, pero no es lo que la mayor parte de las personas sensatas hace cuando puede evitarlo.  Las mejores prácticas de escalada seguramente recomiendan usar ropa y calzado adecuados, emplear herramientas de reconocida utilidad en la montaña y disponer de ciertos conocimientos técnicos.

 

Las mejores prácticas son, sobre todo, adaptables.  Si bien no será necesario utilizar el mismo equipamiento para subir un risco en una excursión dominguera que para coronar el Everest, en ninguno de los casos suele ser recomendable utilizar la misma ropa con la que vamos al trabajo.  De lo que se trata es de adoptar esas mejores prácticas a nuestras necesidades particulares.

 

De modo similar, en el momento en que decidimos adoptar en nuestra organización de TI un conjunto de mejores prácticas, estamos poniendo de manifiesto nuestra voluntad de gestionarla inspirándonos en cómo lo han hecho anteriormente otras organizaciones que han tenido éxito en la gestión de los servicios; estamos adoptando un determinado marco de trabajo y adaptándolo a nuestras necesidades.

 

Incluso superado ese primer escollo conceptual, hay quien se comporta a partir de ese momento como si no hubiera en el mundo más guía que el marco de trabajo que ha decidido utilizar como guía.  Grave error, porque hacer eso equivale a renunciar a los beneficios que pueden aportarnos muchas otras fuentes de mejores prácticas.  Si estamos hablando de mejores prácticas, si están reconocidas como prácticas de éxito en otras organizaciones, ¿por qué no adoptar todas aquellas que puedan aportar valor a nuestros servicios?  Si son tan buenas como para ser consideradas “mejores prácticas” en la industria, por definición no debieran ser incompatibles entre sí.

 

Reconozco a ITIL como uno de los muros maestros del edificio ITSM, que es donde se piensan, se diseñan, se ponen en producción, se operan y se mejoran los servicios TIC, que constituyen a su vez el soporte tecnológico de su negocio.  Pero si bien es cierto que no se puede hacer una casa sin paredes, una pared aislada tampoco es una casa.

 

Voy a poner un ejemplo.  Las palabras “efficient” y “efficiently” se repiten nada menos que 246 veces en las 1.962 páginas de los libros de ITIL v2011, lo que arroja un promedio de una mención a la eficiencia por cada 8 páginas.  Dado que la eficiencia se refiere a la habilidad de hacer un uso óptimo de los recursos para llevar a cabo una tarea, parece cabal concluir que ITIL hace un énfasis nada desdeñable en “obtener resultados sin desperdiciar materiales, tiempo o energía”. Bien, pues se da la circunstancia de que el mantra fundamental de Lean es, precisamente, la eliminación de desperdicio.

 

Materializado en sistemas tan probadamente exitosos como el Toyota Production System, Lean ha demostrado ser una potentísima fuente de mejores prácticas en el ámbito de la producción industrial.  Sus incursiones en el sector servicios han resultado evidentemente provechosas y en su conjunto, ha sido capaz de definir una serie de conceptos y de herramientas que bien podemos aprovechar en nuestra gestión de servicios.

 

A fecha de hoy, no me imagino diseñando un proceso para gestión de servicios basado en ITIL (o en MOF,  o en FITS) sin tener en cuenta las enseñanzas de Lean en cuanto a eliminación de desperdicio.  Y les aseguro que por aceptar los consejos de ITIL y de Lean al mismo tiempo, nunca se ha presentado en mi mesa el espíritu de ITIL tachándome de “mente impura” y atizándome con el canto de los libros de v2011.  Ni eso, ni nada parecido.

 

Y Lean es tan sólo un ejemplo.  Nadie duda de que utilizar estándares como fuente de mejores prácticas es a su vez una buena práctica.  Aunque nuestro negocio no nos exija obtener una certificación de seguridad de la información en nuestra empresa, usar ISO/IEC 27001 como referencia a la hora de organizar nuestro sistema de gestión de la información nos garantiza que estamos haciendo las cosas como se hacen en aquellas empresas que gestionan la seguridad de manera reconocible y auditable por terceros.  Del mismo modo, el concepto de política de calidad descrito en ISO 9001 nos puede ofrecer muchas ideas trasladables a nuestro entorno cuando estemos trabajando con el proceso de mejora continua.

 

Aunque tal vez de forma menos evidente, o menos extendida, o menos formalizada que en el caso de Lean o de los estándares, DevOps es otro buen ejemplo.  Muchas organizaciones deciden utilizar metodologías ágiles de desarrollo para dar solución a requerimientos de negocio tales como la reducción del “Time to market” o como la adaptabilidad de los proyectos de desarrollo a los cambios que sufren durante su ciclo de vida.  DevOps puede entenderse como una consecuencia de estas metodologías, que reconoce la interdependencia de los equipos de desarrollo y los de operación y que se enfoca en la integración de esos equipos a través de la colaboración.

 

Llevamos años diciendo en ITIL que las fases del ciclo de vida de los servicios pretenden ser simplemente agrupaciones lógicas de procesos, que todo debe entenderse y tratarse como un gran sistema.  Más concretamente, llevamos tiempo explicando que las fases de diseño y operación están eternamente condenadas a entenderse entre ellas y a través de la fase de transición.  Y aún más específicamente, llevamos años diciendo que las entradas, salidas e interfaces entre procesos y funciones deben cuidarse para asegurar que todo funciona como esperamos que lo haga.  Sin embargo, y aunque es usual que los traspasos entre los equipos de desarrollo y operaciones estén más o menos bien definidos en muchas organizaciones, no todas ellas han sido capaces de dar un soporte eficaz, continuo, ágil y bidireccional a esas necesidades de integración entre el desarrollo y la operación.

 

La cuestión no es exactamente que ese soporte no esté definido en ITIL, sino que la práctica –la mejor práctica– nos la están enseñando desde hace unos pocos años aquellas organizaciones en las que se ha puesto en marcha lo que estamos empezando a tomar en serio bajo el nombre de DevOps.  ¿Por qué no aprovechar también esta fuente de buenas prácticas?  Ya se trate de cambios organizativos demostradamente necesarios, de procesos reconstruidos por completo, de actitudes o de recomendaciones, todo vale mientras demuestre un camino válido hacia la maximización de la entrega de valor al negocio.

 

Hablamos de estándares, de metodologías y de marcos de trabajo como fuentes de ejemplos a seguir.  No obstante –y esto no debería sorprender a nadie–la fuente más fiable de mejores prácticas para gestionar los servicios TIC de una organización se encuentra en la propia organización.  Una empresa es, por definición, quien mejor entiende su empeño por lograr algo, y es -eso sí, en función de su madurez como tal- quien mejor puede entender el valor que aporta a ese empeño cada una de las acciones que lleva a cabo.  Y es de aquí de donde se deduce el inmenso valor que tiene para cualquier organización una adecuada gestión de su conocimiento.

 

Tengo para mí que el mejor “coach” no es aquel que nos imbuye de ideas innovadoras que han funcionado para mejorar a otros, sino aquel que nos ayuda a buscar dentro de nosotros para mejorar los aspectos que más pueden aportar a nuestro desarrollo futuro. Puede que éste sea el mejor papel a asumir en una organización respecto a la búsqueda de las mejores prácticas.  Están ahí, más o menos ocultas, pero están.  Y puede que las hallemos empezando por hacer un ejercicio que no todas las organizaciones hacen regularmente: redescubrir su visión, su misión y sus valores.

 

Porque el único libro en el que encontraremos nuestro camino al éxito lo tenemos que escribir nosotros mismos.

 

 

Javier García Bolao

Consultor independiente, especializado en gestión de servicios TIC, Gobierno de TI y Seguridad de la Información. Más de 20 años de experiencia en prestigiosas firmas internacionales al frente de departamentos TI, en Seguridad de la Información o como Director de Calidad del Servicio. Madrid, España.

 

 

Contenidos recomendados...

Comentar
Para comentar, es necesario iniciar sesión
Se muestran 0 comentarios
X

Uso de cookies

Esta web utiliza cookies técnicas, de personalización y análisis, propias y de terceros, para facilitarle la navegación de forma anónima y analizar estadísticas del uso de la web. Consideramos que si continúa navegando, acepta su uso. Obtener más información