En las últimas semanas hemos hablado bastante de Assets. Primero vimos por qué tener los activos conectados con los tickets cambia la forma en que trabaja una Mesa de Servicio, después profundizamos en cómo construir un modelo que permita relacionar equipos, personas, licencias, contratos y solicitudes.
Pero hay algo que todavía no hemos abordado y que suele generar bastante sorpresa: Assets no tiene por qué quedarse dentro de TI.
Una organización puede utilizarlo para administrar notebooks y servidores, pero también mobiliario, salas, instalaciones, vehículos, contratos, equipamiento de oficina y muchos otros recursos que forman parte de la operación diaria.
Y eso abre un espacio muy interesante para áreas como Servicios Generales o Facilities.
El mismo problema de TI también existe fuera de TI
Pensemos en algo bastante cotidiano.
Un colaborador informa que una silla está dañada, que el aire acondicionado de una sala no funciona o que un proyector presenta una falla. La solicitud llega por correo, teléfono o WhatsApp y alguien comienza a reconstruir el contexto:
- ¿En qué oficina ocurrió?
- ¿Quién es responsable de mantenerlo?
- ¿Tiene garantía?
- ¿Existe un contrato de mantenimiento?
- ¿Ha presentado la misma falla antes?
Es exactamente el mismo problema que vimos en una Mesa de Servicio TI. La información existe, pero está distribuida entre planillas, correos, carpetas compartidas o personas que conocen la historia. Con Assets, ese contexto puede formar parte del mismo flujo donde se recibe y gestiona la solicitud.
Assets puede representar mucho más que notebooks
Assets utiliza una estructura flexible de objetos, atributos y relaciones, por lo que no obliga a que todo lo registrado sea infraestructura tecnológica, de hecho, puede utilizarse para representar prácticamente cualquier recurso que sea relevante para la operación.
Por ejemplo:
- Instalaciones: edificios, sucursales, oficinas, salas y bodegas.
- Mobiliario y equipamiento: escritorios, sillas, proyectores, climatización y equipos de seguridad.
- Vehículos: automóviles, camionetas y equipamiento asociado.
- Contratos y proveedores: garantías, mantenciones, fechas de renovación y responsables.
La clave sigue siendo la misma que explicamos en el artículo anterior: el verdadero valor no está en crear listas, sino en crear relaciones.
Un ejemplo: gestionar una sala de reuniones
Imaginemos que un colaborador quiere reportar que el proyector de una sala dejó de funcionar. En lugar de escribir: “el proyector de la sala grande del cuarto piso no funciona”, puede seleccionar directamente la sala o el equipo afectado desde su solicitud.
A partir de ahí, el equipo de Servicios Generales puede recibir mucho más contexto.
Por ejemplo:
- Sala: Directorio 401.
- Ubicación: Casa Matriz, piso 4.
- Equipo: Proyector Epson EB-L260F.
- Estado: En servicio.
- Fecha de instalación.
- Contrato de mantenimiento asociado.
- Últimas solicitudes relacionadas.
La solicitud ya no llega aislada, llega conectada con el elemento que está generando el problema, y desde el propio activo también es posible mantener la relación con las solicitudes que se han generado a lo largo del tiempo.
Del ticket al ciclo de vida del activo
Aquí aparece una diferencia importante. Con Jira Service Management podemos gestionar la solicitud, pero al conectarla con Assets también empezamos a construir el historial del activo.
Un equipo puede pasar, por ejemplo, por distintos estados:
Disponible → Asignado → En mantenimiento → Disponible → Fuera de servicio → Dado de baja
Lo mismo puede ocurrir con mobiliario, vehículos, contratos o equipamiento. Eso permite comenzar a responder preguntas bastante más útiles:
- ¿Qué equipos están actualmente en mantenimiento?
- ¿Qué activos generan más solicitudes?
- ¿Qué contratos están próximos a vencer?
- ¿Qué elementos ya deberían ser reemplazados?
Assets deja de funcionar solamente como inventario y comienza a entregar trazabilidad sobre el ciclo de vida.
Automatizar tareas que hoy dependen de alguien
Otro beneficio aparece cuando Assets se combina con automatización. Jira Service Management puede utilizar reglas para actualizar información de los objetos y ejecutar acciones relacionadas con los activos.
La misma lógica puede aplicarse a procesos de Servicios Generales.
Por ejemplo:
Si un contrato está próximo a vencer
→ generar una alerta o una solicitud de revisión.
Si un activo cambia a “En mantenimiento”
→ asignar la solicitud al proveedor correspondiente.
Si un activo es dado de baja
→ evitar que siga apareciendo entre las opciones disponibles para nuevas solicitudes.
Lo importante es que el inventario empiece a participar en el proceso, en lugar de depender de que alguien recuerde actualizar una planilla después.
¿Y esto se puede hacer con Jira Service Management Standard?
Actualmente Assets está disponible en los planes pagados de Service Collection, incluido Standard, y este plan contempla hasta 5.000 objetos incluidos.
Esto vuelve especialmente interesante comenzar con casos de uso acotados. Una organización no necesita incorporar de inmediato todos sus edificios, vehículos, muebles, contratos y equipos.
Puede partir, por ejemplo, con: salas y equipamiento de reuniones o mobiliario de una oficina o vehículos corporativos o incluso contratos de mantenimiento y proveedores.
El objetivo no es llenar Assets de información, es elegir un proceso donde hoy exista poca visibilidad, mucho trabajo manual o demasiadas planillas y demostrar valor desde ahí.
La mirada de TICBLUE: partir por un problema, no por el inventario
Cuando hablamos de Assets es fácil entusiasmarse y comenzar a pensar en todo lo que podríamos registrar, pero ese normalmente no debería ser el punto de partida. Antes de crear un esquema de Servicios Generales conviene identificar dónde está hoy el problema:
¿Se pierde demasiado tiempo identificando los equipos?
¿Los contratos vencen sin que nadie lo advierta?
¿Es difícil conocer el historial de mantenimiento?
¿Existen varias planillas con información diferente?
El primer modelo debería ayudar a resolver uno de esos problemas, después puede crecer.
Conclusión
Assets no es solamente una herramienta para administrar notebooks, servidores o licencias.
Su modelo flexible permite llevar la misma lógica de contexto, relaciones y trazabilidad a otros recursos importantes para la organización.
Para Servicios Generales, eso puede significar pasar de planillas dispersas y solicitudes sin contexto a un modelo donde instalaciones, mobiliario, equipamiento, contratos, proveedores y solicitudes empiezan a formar parte del mismo flujo.
Y no es necesario modelar toda la empresa desde el primer día.
Basta con encontrar ese proceso que hoy depende demasiado de Excel y empezar por ahí.
En TICBLUE ayudamos a diseñar e implementar modelos de Assets conectados con los procesos reales de cada organización, tanto dentro como fuera de TI.
Deja tu comentario