ITSM: quizás sea hora de volver a hacerlo simple

El verano es una época en la que puedes reflexionar con algo más de tranquilidad, detenerte y salir por unos momentos del día a día que a menudo nos mantiene atrapados en un ciclo que deja poco margen para cuestionarnos cómo hacemos las cosas.

El anuncio, hace unas semanas, de la nueva versión de ITIL, la v5, y las lecturas que he hecho al respecto me han provocado precisamente una de esas pausas. Y he llegado a una conclusión personal: con ITIL, yo llego hasta aquí.

No porque haya dejado de creer en el ITSM. Todo lo contrario. Creo más que nunca que necesitamos gestionar bien los servicios, definir responsabilidades, medirlos, gestionar incidentes, problemas, cambios, configuraciones, proveedores, continuidad y, sobre todo, mejorar continuamente.

Lo que cuestiono es si necesitamos cada vez más abstracción y complejidad para conseguirlo.

Conozco ITIL desde la versión 1.5 y me entusiasmó especialmente la familia de documentos de ITIL v2. Tenía carencias, evidentemente, pero sobre todo tenía una virtud: era útil.

Para mí, ITIL v2 representó probablemente el mejor equilibrio entre rigor y pragmatismo. Sus documentos permitían que responsables de servicios y técnicos pudiéramos convertir con relativa facilidad sus recomendaciones en procesos reales dentro de nuestras organizaciones.

ITIL v3 corrigió algunas de las carencias que quienes habíamos adoptado v2 ya habíamos detectado. La visión del ciclo de vida del servicio aportaba cosas interesantes, pero también empezaba a hacer crecer considerablemente el modelo.

Con ITIL 4, personalmente, perdí una parte importante de aquella conexión con la realidad operativa.

Service Value System, Service Value Chain, cuatro dimensiones, guiding principles, value streams, co-creation of value, practices en lugar de procesos...

Conceptos interesantes, sin duda. Pero también sucesivas capas de abstracción que es necesario interpretar antes de poder convertirlas en mecanismos concretos de gestión.

Y ahora llega ITIL v5.

Una nueva evolución que amplía todavía más el perímetro: gestión integrada de productos y servicios digitales, experiencia, estrategia, transformación, liderazgo, gobernanza de la IA...

Todo esto es importante. La pregunta que me hago es otra:

¿Tiene ITIL que resolverlo todo?

Si el problema que algunos ya encontrábamos en ITIL 4 era que había dejado de ser una guía relativamente directa para gestionar servicios TI para convertirse en un marco mucho más amplio y abstracto, no tengo claro que ampliar todavía más su perímetro sea la respuesta.

Al mismo tiempo, ITIL ha evolucionado desde un marco promovido originalmente desde el sector público británico hacia un ecosistema de propiedad, contenidos, formación y certificación gestionado comercialmente.

Y tengo la sensación de que esta evolución también ha ido desplazando su centro de gravedad: de ayudar principalmente a los profesionales a gestionar mejor sus servicios hacia alimentar un ecosistema cada vez más amplio de formación, certificación y consultoría.

Es en este contexto en el que hace unos años conocí FitSM.

FitSM es un modelo ligero de ITSM, nacido en el marco de un proyecto cofinanciado por la Comisión Europea y actualmente mantenido por una organización sin ánimo de lucro. Sus materiales son públicos y pueden consultarse, descargarse y reutilizarse de acuerdo con las correspondientes licencias Creative Commons.

Y, sobre todo, cuando lo descubrí me recordó en cierta medida aquel espíritu pragmático que yo había encontrado en ITIL v2.

FitSM no intenta explicarlo todo.

Intenta definir el mínimo necesario para gestionar bien los servicios.

Durante un tiempo lo dejé en un cajón. No veía una adopción suficientemente generalizada como para hacerme apostar decididamente por él. Pero algunos comentarios recientes de buenos compañeros de profesión y, paradójicamente, la publicación de ITIL v5 me han llevado a recuperarlo.

Y creo que merece la pena volver a prestarle atención.

Para quienes no lo conozcáis, podéis encontrar toda la documentación en fitsm.eu. No solo están las especificaciones del modelo, sino también plantillas y materiales de formación.

Es un modelo deliberadamente ligero, pragmático e implementable. Y tiene una característica que cada vez valoro más: una organización razonablemente pequeña o mediana puede entenderlo y empezar a aplicarlo sin necesidad de construir previamente una enorme capa metodológica a su alrededor.

Esto no significa que debamos tirar ITIL a la basura.

Todo lo contrario.

ITIL acumula décadas de conocimiento extraordinariamente valioso sobre gestión de servicios. Podemos seguir utilizándolo como una magnífica biblioteca de buenas prácticas, profundizando en ella cuando necesitemos resolver un problema concreto.

Pero una cosa es utilizar ITIL como fuente de conocimiento y otra asumir que toda esa complejidad debe constituir necesariamente la arquitectura central de nuestro sistema de gestión.

Quizás podamos hacerlo al revés.

FitSM como esqueleto sencillo de nuestro sistema de gestión de servicios. ITIL como biblioteca de buenas prácticas a la que recurrir cuando necesitemos mayor profundidad. E ISO/IEC 20000 como referencia cuando necesitemos avanzar hacia un sistema formal de gestión o una eventual certificación.

Y creo que esta reflexión va más allá del ITSM.

Quienes gestionamos tecnología trabajamos con modelos para la gestión de servicios, proyectos, programas, portafolios, arquitectura empresarial, seguridad, gobernanza, datos...

Quizás deberíamos preguntarnos más a menudo cuánto necesitamos realmente de todos esos modelos.

Un framework más grande no hace necesariamente que una organización sea más madura.

Una organización madura es aquella que sabe qué tiene que hacer, quién es responsable de hacerlo, lo hace de forma repetible, lo mide y es capaz de mejorarlo.

El resto es metodología.

Después de muchos años trabajando con ITIL, cada vez estoy más convencido de que, en algunos ámbitos de la gestión tecnológica, hemos confundido profundidad con complejidad.

Quizás sea hora de recuperar modelos mínimos, abiertos, comprensibles e implementables.

Quizás sea hora de volver a los orígenes y recordar por qué nacieron estos frameworks: para ayudarnos a gestionar mejor, no para complicarnos la gestión.

Hagamos un KISS !

Keep It Simple, Stupid.