Está bien, “salvar la vida” es un poco exagerado. Pero puede hacer que tu vida profesional sea más fácil y próspera. Puede ahorrarle a tu empresa muchas molestias, tiempo y dinero. ¿Interesado? Genial. Entonces, ¿qué es un RTSM?

Por alguna razón, algunos piensan que un proyecto ITIL tiene que empezar con una CMDB. Si bien no hay nada malo con las CMDBs per se, tratar de crear una CMDB perfecta significa años de esfuerzo. Y nadie nunca pudo.

De hecho, la mayoría de los proyectos de CMDB “exitosos” son solo proyectos de gestión de activos y poco más. Cuando llega el momento de “conectar los puntos” de los miles de componentes recolectados y crear relaciones entre ellos para representar realmente el servicio de negocio todos se pierden en el camino.

¿Por qué? Por muchas causas… que merecen su propio post. (Entre ellas: mala comunicación entre IT y Negocios, la falta de una idea cabal cerca de qué es un servicio, la inmadurez de la tecnología subyacente, el uso de enfoques de abajo hacia arriba en lugar de de arriba hacia abajo, la complejidad general de la herramienta, la falta de integración de herramientas de monitorización puntuales de múltiples empresas (o de una misma gran empresa que compró diferentes compañías para crear una hermosa Torre de Babel), enfoque “inside-out”, y otras.)

Generalmente todo termina en sangre, sudor, y lágrimas, creeme. A menos que alguien inteligente decida que la gestión de activos es lo suficientemente buena para el proyecto CMDB, pare el carro, cante victoria, y se olvide del tema.

Pero después de todo este trabajo, muchas compañías todavía no pueden responder estas preguntas:

1) ¿Los servicios de negocio están en marcha y produciendo resultados de negocio reales dentro de los objetivos establecidos?

2) ¿Cómo distinguir un incidente de 5 dólares de uno de un millón?

3) ¿Cómo mejorar continuamente los servicios de negocio?

Con un Real Time Service Model (RTSM) se responde fácilmente a todas estas preguntas.

Un RTSM comienza con servicios. Y si sos inteligente, hablamos de un puñado de servicios críticos de negocio reales, no de servicios internos de IT.

Recordemos que los servicios tienen objetivos de negocio (el servicio de cotización de seguros debe hacer que la compañía tenga al menos 1000 clientes nuevos al mes, por ejemplo). Los servicios tienen procesos. Los procesos tienen pasos. Los pasos tienen objetivos establecidos (la autorización de una tarjeta de crédito no tiene que tardar más de dos segundos, por ejemplo). Los usuarios tienen una expectativa sobre los tiempos de respuesta para los pasos del proceso (una nueva tarjeta de crédito no tiene que tardar más de dos semanas en llegar a casa, por ejemplo). Los pasos del proceso dependen de una o más aplicaciones. Las aplicaciones tienen interfaces entre ellas. Hay muchas cosas que pueden funcionar mal en estas interfaces (la información de ventas de las sucursales tiene que ser recibida a las 11 p.m. de cada día, por ejemplo). Y finalmente, sí, las aplicaciones tienen componentes.

Y todo tiene controles de seguridad y necesidades de auditoría.

La forma ideal de representar todo esto es a través de un Real Time Service Model. ¿Por qué?

Primero, porque la infraestructura cambia tan rápido (pensá en la virtualización y la adaptación bajo demanda) que necesitás que el modelo sea fácil de cambiar, incluyendo el uso de automatización (pero atención: la automatización no va a cubrir el 100% de esto, ni se va a acercar siquiera. Si lo hace, no estás modelizando lo que deberías). Necesitás un proceso ágil para modificar el modelo, y tecnología escalable y apropiada con una interfaz de usuario de gran usabilidad.

Segundo, porque un RTSM calcula el estado de disponibilidad para tus servicios automáticamente. Todas las reglas de las relaciones en un RTSM son computables. En una CMDB tradicional podés crear todo tipo de relaciones-spaghetti (incluso personalizadas) que no significan nada. E incluso se pueden agregar referencias circulares sin darte cuenta. Un buen RTSM, en cambio, te facilita la creación de un modelo coherente.

El Service Model es la base. Si te sentís cómodo con él, lo vas a mantener. Si no, se va a convertir en obsoleto bastante rápido y vas a haber perdido tu tiempo.

Pero tercero, y tal vez más importante, no estás limitado al concepto de CIs (“ítems de configuración”). Podés dejar afuera los CIs que no agregan valor. Y podés agregar al RTSM cualquier cosa que sea relevante para el negocio – incluso procesos de los cuales IT no es siquiera responsable. Controles Lógicos. Chequeos de tendencia de KPIs. Información externa. Pasos manuales de procesos. Controles de Seguridad. Todo lo que haga al modelo más fuerte, más preciso y más útil.

Si el modelo es correcto, es el paraíso. El cálculo de los estados del servicio es automático. La causa raíz más probable de un incidente es automática. La priorización de incidentes orientada al negocio es automática. La indicación de componentes que fallan frecuentemente es inmediata, con lo cual podés mejorar continuamente tus indicadores de servicio (la disponibilidad, MTBF, MTTR, MTBSI, etc.) y podés obtener presupuesto para mejoras de infraestructura mucho más fácilmente.

Y atención: no hace falta tener todo el modelo resuelto desde el primer día. No hay problema en empezar con infraestructura si tenemos una mente abierta para hacerlo evolucionar. Está bien. El RTSM te va a permitir avanzar. Después vas a poder ir agregando indicadores, controles end-to-end y más, a medida que profundices en los servicios de negocio.

Un proyecto exitoso de monitorización empieza por un enfoque correcto. Y se convierte en un proyecto de Visibilidad muy rápidamente. Después vas a empezar a crear hermosos dashboards para encontrar cuellos de botella y áreas de oportunidad para toda la empresa, que incluso consumirán usuarios de fuera de IT. Y ahí es donde empieza el reconocimiento. Lo único que hace falta es la herramienta correcta.

Un RTSM puede ser implementado en semanas, no en años. Es el camino más corto hacia el éxito.

Pero, eh, ¿es compatible con ITIL?

La respuesta correcta es: “¿a quién le importa?” Pero, sí, por supuesto que lo es. ITIL V3 extiende el concepto de CMDB en el de CMS (Configuration Management System-Sistema de Gestión de Configuración). Una forma de verlo es que CMDB más RTSM igual CMS.

En resumen, no necesitás empezar con la CMDB. La podés agregar después. O, tal vez, nunca.