En las últimas semanas hemos hablado de Assets desde distintos ángulos: inventario, relaciones entre activos, ciclo de vida y casos de uso fuera de TI.

Hoy queremos avanzar un paso más, porque una cosa es saber qué servidores, aplicaciones o equipos tenemos, y otra bastante distinta es entender qué servicios dependen de ellos y qué impacto puede generar cuando algo falla, ahí es donde entra el Catálogo de Servicios.

Un servicio no es lo mismo que un activo

Un activo puede ser un servidor, una aplicación, una base de datos, una licencia o un equipo de red. Un servicio representa algo que entrega valor a un usuario o a un área de la organización.

Por ejemplo:

Servicio: Portal de Clientes

Ese servicio podría depender de:

Aplicación web → API → Base de datos → Infraestructura

Para el usuario, todos esos componentes técnicos son prácticamente invisibles. Lo que realmente le importa es que el Portal de Clientes esté disponible.

Por eso, cuando hablamos de gestión de servicios, no basta con saber qué componente falló. También necesitamos entender qué servicio está siendo afectado.

Services y Assets empiezan a trabajar mucho más cerca

La nueva experiencia de Services en Jira Service Management utiliza esquemas de Assets como modelo de datos. Esto permite gestionar los servicios con una estructura similar a la que ya conocemos en Assets: objetos, atributos, responsables y relaciones.

Actualmente existen dos esquemas principales:

Software Registry, orientado a servicios técnicos, aplicaciones y otros componentes de software.

Business Portfolio, pensado para representar servicios y productos más cercanos a la operación del negocio.

Ambos pueden relacionarse entre sí y también con otros objetos almacenados en Assets.

En términos simples, Assets ya no ayuda solamente a responder “qué tenemos”, también puede aportar contexto para entender “qué servicios entregamos y de qué dependen”.

Del componente técnico al servicio

Imaginemos una organización que tiene un servicio llamado:

Plataforma de Ventas Online

Para funcionar puede depender de:

Plataforma de Ventas Online
↓
Aplicación Ecommerce
↓
Servicio de Autenticación
↓
Base de datos
↓
Infraestructura

Cada uno de esos elementos puede tener responsables, criticidad y relaciones con otros componentes, cuando esa estructura está bien definida, dejamos de mirar únicamente elementos individuales.

Si falla la base de datos, la pregunta ya no es solamente:

“¿Qué servidor tiene problemas?”

También podemos comenzar a responder:

“¿Qué servicio está siendo afectado y quién necesita saberlo?”

Ese cambio de perspectiva es especialmente importante durante incidentes.

Más contexto cuando ocurre un incidente

Cuando un servicio está relacionado con los componentes que lo soportan, el equipo puede entender con mayor rapidez el alcance de una falla.

Por ejemplo:

  • Qué servicio está afectado.
  • Qué nivel de criticidad tiene.
  • Quién es responsable.
  • Qué otros servicios dependen de él.
  • Qué equipos deberían participar en la respuesta.

Esto evita que buena parte del tiempo inicial de un incidente se utilice intentando descubrir quién conoce el sistema o qué procesos pueden verse afectados. El problema técnico sigue siendo importante, pero ahora tenemos algo más: contexto sobre su impacto en la operación.

Una fuente de información más conectada

En muchas organizaciones la información necesaria para responder estas preguntas ya existe, pero está distribuida: las aplicaciones están en una planilla, los responsables están en otra, las dependencias las conoce arquitectura, los contratos están en otra herramienta. Y cuando ocurre un incidente, alguien debe juntar todas esas piezas.

Un servicio dentro de Assets puede incorporar información como:

  • Nombre.
  • Criticidad.
  • Equipo responsable.
  • Estado.
  • Respondedores.
  • Relaciones con otros servicios.
  • Dependencias con otros objetos.

El objetivo no es almacenar información por almacenarla, sino hacer que esté disponible cuando realmente se necesita.

No necesitas construir un catálogo gigantesco

Aquí aplica la misma lógica que hemos recomendado durante toda esta serie de Assets.

No hay que modelarlo todo desde el primer día.

Un Catálogo de Servicios útil no es necesariamente el que tiene más elementos, sino el que permite responder preguntas importantes:

  • ¿Cuáles son nuestros servicios críticos?
  • ¿Quién es responsable de cada uno?
  • ¿De qué componentes dependen?
  • ¿Qué ocurre si uno deja de estar disponible?

Una buena primera etapa podría considerar solamente los servicios más importantes para la operación.

Después el modelo puede crecer.

¿Esto está disponible en Jira Service Management Standard?

Sí.

Services está disponible actualmente en los planes Standard, Premium y Enterprise, y su nueva experiencia utiliza Assets como base para administrar los servicios.

Esto abre una oportunidad interesante para organizaciones que ya están comenzando a trabajar con Assets en Standard.

Después de ordenar activos, responsables y relaciones, pueden avanzar hacia una visión donde también comienzan a representar los servicios que esos componentes soportan.

No es necesario construir una CMDB completa para empezar.

Lo importante es identificar primero qué servicios son realmente críticos.

La mirada de TICBLUE: partir por el servicio

Cuando hablamos de Assets es fácil comenzar preguntando:

“¿Qué objetos deberíamos cargar?”

Pero para construir un Catálogo de Servicios puede ser más útil cambiar la pregunta:

“¿Qué servicios necesitamos entender mejor?”

A partir de ahí podemos identificar qué equipos los soportan, quién es responsable, cuáles son sus dependencias y qué tan críticos son para la organización.

El modelo técnico viene después.

Porque el objetivo final no debería ser tener el esquema más grande o más detallado, sino poder comprender rápidamente qué está pasando y qué impacto tiene cuando algo cambia o falla.

Conclusión

Assets puede ayudarnos a responder qué activos tenemos, dónde están y cómo se relacionan.

El Catálogo de Servicios agrega otra capa:

qué servicios entregamos, de qué dependen y qué se ve afectado cuando algo falla.

Ahí la gestión de activos empieza a conectarse directamente con la gestión de servicios.

Y ese es un paso importante para dejar de mirar servidores, aplicaciones o tickets de forma aislada y comenzar a entender cómo todos ellos sostienen la operación.

En TICBLUE ayudamos a las organizaciones a diseñar modelos de Assets y Catálogos de Servicios con un alcance progresivo, conectados con los procesos reales de Jira Service Management.

Solicitar Asesoría