En nuestro artículo anterior hablamos de una oportunidad que hoy muchas organizaciones todavía no están aprovechando: Assets ya viene incluido en Jira Service Management Standard.
Eso permite comenzar a ordenar equipos, licencias, contratos y otros elementos importantes para la operación sin depender exclusivamente de planillas o registros aislados.
Pero hay un punto clave que vale la pena profundizar:
Cargar una planilla dentro de Assets no significa necesariamente haber implementado una gestión de activos.
El verdadero valor aparece cuando esa información se estructura, se relaciona y empieza a participar directamente en los procesos de soporte.
El error de convertir Assets en otro Excel
Una organización puede importar cientos de notebooks, monitores o licencias y, aun así, seguir trabajando prácticamente igual que antes.
Esto ocurre cuando Assets se utiliza solo como un repositorio:
- Un listado de equipos.
- Un listado de personas.
- Un listado de licencias.
- Un listado de proveedores.
La información está más ordenada, pero sigue funcionando de manera aislada. Assets permite construir algo bastante más útil: un modelo en el que los objetos se conectan entre sí.
Dentro de un esquema pueden existir tipos de objetos, objetos individuales, atributos, estados y referencias. Estas referencias permiten representar las relaciones entre los distintos elementos de la operación. Por ejemplo, un notebook puede estar relacionado con:
- El colaborador que lo tiene asignado.
- Su modelo y fabricante.
- La ubicación donde se utiliza.
- Las aplicaciones instaladas.
- El contrato o proveedor asociado.
- Su fecha de garantía.
- Los incidentes que ha generado.
Las relaciones son las que cambian el soporte
Imaginemos que un colaborador informa que no puede conectarse a la VPN. Sin Assets, el agente probablemente tendrá que preguntar:
- ¿Desde qué equipo te estás conectando?
- ¿Cuál es el número de serie?
- ¿Qué sistema operativo utilizas?
- ¿El equipo es corporativo?
- ¿Tiene instalada la versión correcta del cliente VPN?
Con un modelo bien construido, buena parte de esa información ya puede estar asociada al activo seleccionado en el ticket.
El agente no recibe solamente una solicitud, también recibe el contexto del equipo, su responsable, su estado, su historial y sus relaciones. Eso permite comenzar el diagnóstico desde un punto mucho más avanzado.
Cómo podría verse un modelo inicial en Assets
No es necesario comenzar diseñando una CMDB gigantesca. Para una primera etapa, un esquema de activos TI podría considerar algunos grupos básicos.
Personas
Puede incluir colaboradores, responsables, áreas o equipos internos.
Hardware
Notebooks, computadores de escritorio, monitores, teléfonos, impresoras o servidores.
Software y licencias
Aplicaciones corporativas, licencias, fechas de vencimiento y usuarios asignados.
Ubicaciones
Oficinas, sucursales, pisos, bodegas o centros de datos.
Contratos y proveedores
Garantías, contratos de soporte, fechas de renovación y empresas responsables.
Servicios
Servicios técnicos o de negocio que dependen de determinados equipos, aplicaciones o componentes.
Lo importante no es crear la mayor cantidad posible de categorías. Lo importante es decidir qué información necesita realmente el equipo para resolver mejor.
Qué atributos conviene registrar
Cada tipo de objeto puede tener atributos distintos. En un notebook, por ejemplo, podrían ser:
- Número de serie.
- Marca y modelo.
- Estado.
- Usuario asignado.
- Ubicación.
- Fecha de compra.
- Fin de garantía.
- Sistema operativo.
- Nivel de criticidad.
No todos los datos disponibles necesitan convertirse en atributos. Uno de los errores más habituales es construir fichas demasiado grandes, difíciles de mantener y llenas de información que nadie consulta. Como criterio técnico, conviene mantener los tipos de objetos acotados; la estructura recomendada por Atlassian considera un máximo de 35 atributos por tipo de objeto para favorecer el rendimiento y la mantención.
Una buena pregunta antes de crear cada atributo es:
¿Este dato ayudará a resolver, automatizar, filtrar o tomar una decisión?
Cuando la respuesta es no, probablemente no sea necesario incluirlo.
Cómo conectar Assets con los tickets
El modelo empieza a generar valor operativo cuando los objetos aparecen dentro de las solicitudes de Jira Service Management.
Mediante un campo de objetos de Assets, es posible incorporar un activo dentro del formulario del portal o de la vista del agente. Al seleccionar un objeto, se crea una relación bidireccional: desde el ticket se puede acceder al activo y, desde el activo, revisar los tickets asociados. Esto permite crear campos como:
- Equipo afectado.
- Aplicación involucrada.
- Servicio impactado.
- Licencia solicitada.
- Sucursal afectada.
Pero tampoco se trata de mostrar todos los activos a todos los usuarios, con AQL, el lenguaje de consulta de Assets, es posible filtrar qué objetos aparecen en cada campo. Por ejemplo, se puede configurar el portal para que una persona vea solamente los equipos que tiene asignados, en lugar de buscar entre todo el inventario de la organización.
Incluso es posible utilizar automatizaciones para identificar al informador del ticket y completar automáticamente el campo con sus activos asociados.
Un ejemplo práctico: incidentes asociados a notebooks
Veamos cómo podría funcionar un caso sencillo, un colaborador entra al portal y selecciona la opción “Tengo un problema con mi equipo”, en el formulario aparece el campo Equipo afectado, pero no muestra todos los notebooks de la organización, solo muestra aquellos asociados a esa persona, el colaborador selecciona su notebook y envía la solicitud.
Al abrir el ticket, el agente puede revisar inmediatamente: el modelo del equipo, su antigüedad, sistema operativo, garantía, usuario asignado, los tickets anteriores relacionados, el proveedor responsable, cuando corresponda.
Si el mismo notebook ya registra varios incidentes similares, el equipo puede evaluar si seguir reparándolo, reemplazarlo o analizar una posible causa común.
El ticket deja de ser un evento aislado. Pasa a formar parte de la historia del activo.
Tres errores que conviene evitar
1. Copiar exactamente la estructura de Excel
La planilla puede servir como fuente inicial, pero no necesariamente como modelo definitivo. Es importante revisar duplicados, nombres, estados y relaciones antes de importar.
2. Intentar modelarlo todo desde el primer día
Mientras más grande sea el alcance inicial, más difícil será mantener los datos actualizados. Jira Service Management Standard incluye actualmente hasta 5.000 objetos en Assets. Esto permite abordar casos concretos, como hardware corporativo, licencias críticas o procesos de incorporación y salida de colaboradores, sin necesidad de construir una CMDB completa desde el comienzo.
3. No definir quién mantiene la información
Assets necesita responsables, debe quedar claro quién actualiza una asignación, quién registra una baja, quién controla las garantías y qué fuente se considera válida para cada dato. Sin esa gobernanza, cualquier inventario vuelve a quedar desactualizado, aunque ya no esté en Excel.
¿Por dónde conviene continuar?
Una buena implementación no parte preguntando cuántos objetos se pueden cargar, parte preguntando:
- ¿En qué solicitudes estamos perdiendo más tiempo buscando contexto?
- ¿Qué información preguntamos una y otra vez?
- ¿Qué activos generan más incidentes?
- ¿Qué procesos siguen dependiendo de planillas?
- ¿Qué decisiones podríamos tomar mejor si tuviéramos trazabilidad?
A partir de esas respuestas, se puede seleccionar un primer proceso y construir un modelo pequeño, útil y conectado con la operación, puede ser la atención de incidentes de hardware, la gestión de licencias o el onboarding y offboarding de colaboradores.
Conclusión
Assets no genera valor únicamente porque permita registrar notebooks, licencias o contratos, el valor aparece cuando esa información se relaciona con personas, servicios, solicitudes e incidentes.
Ese es el paso que convierte un inventario en una herramienta operativa: permitir que el agente tenga más contexto, que el usuario entregue menos información repetida y que la organización pueda tomar mejores decisiones a partir del historial.
En TICBLUE ayudamos a diseñar modelos de Assets con un alcance realista, conectados con los procesos de Jira Service Management y pensados para que la información no solo esté almacenada, sino que efectivamente ayude a resolver mejor.
Deja tu comentario