Existe una diferencia enorme entre “¿TI puede ayudarme con esto?” y “sé exactamente dónde pedir esto, qué necesito informar y cuál es el plazo”. El Catálogo de Servicios es lo que transforma la primera frase en la segunda — estandarizando lo que TI ofrece y cómo el usuario lo solicita.

Esta guía cubre el Catálogo de Servicios y el módulo de Solicitudes del Portal Nyverra ITSM: cómo modelar elementos, formularios y aprobaciones, cómo funciona el ciclo de la solicitud y cómo el catálogo público habilita el autoservicio.

Interfaz del módulo en el Portal Nyverra ITSM.

Catálogo × ticket suelto

ITIL distingue incidente (algo se rompió) de solicitud de servicio (un pedido planificado). El catálogo es el catálogo de pedidos:

Naturaleza	Por dónde entra	Ejemplo
Algo se rompió	Ticket suelto	“El correo electrónico se cayó”
Solicitud estandarizada	Catálogo → solicitud	“Necesito acceso a la carpeta X”

Cuando la solicitud está en el catálogo, obtiene formulario, aprobación y plazo definidos — en lugar de convertirse en un ticket genérico difícil de medir.

Qué contiene un elemento del catálogo

Cada elemento del catálogo describe un servicio y el camino para obtenerlo:

• Identidad: nombre, descripción e icono (ej.: “Aprovisionar máquina virtual”, “Solicitar acceso VPN”).
• Formulario: campos dinámicos por servicio (lo que el solicitante necesita informar).
• Visibilidad: interno (equipo) o expuesto en el catálogo público.
• Aprobación: si el servicio exige autorización antes de la atención.
• SLA de entrega: plazo de suministro, que puede diferir del SLA de incidente.
• Handoff: a qué cola/aprobador va la solicitud después del envío.

El ciclo de vida de la solicitud

Las solicitudes siguen un flujo propio, con estados que orientan la operación:

Estado	Significado
EM_APROVACAO	Esperando decisión; el flujo no avanza hasta que el aprobador responda.
APROVADA	Autorizada; lista para ejecución.
FULFILLED	Servicio entregado (cumplida).
CANCELADA	Solicitud cancelada antes de la entrega.

Las acciones de aprobar/rechazar (SERVICE_REQUEST_APPROVE) y cumplir (SERVICE_REQUEST_FULFILL) siguen el RBAC: solo quien tiene el permiso ejecuta cada etapa.

Quién lo usa

Perfil	Uso típico
Cliente / solicitante	Elige el servicio y abre la solicitud en el portal
Operador	Ejecuta la atención y cumple la solicitud
Aprobador	Autoriza o rechaza la solicitud
Administrador	Mantiene elementos, formularios, aprobaciones y analíticas del catálogo

Cómo usar: paso a paso

Mantener el catálogo (administrador)

1. Modele el servicio: nombre claro, descripción y campos del formulario.
2. Defina si exige aprobación y cuál es el SLA de entrega.
3. Publique en el catálogo interno y/o en el público.
4. Monitoree el uso en analíticas para ajustar la oferta.

Solicitar un servicio (usuario)

1. Abra el catálogo (en el portal o en el área autenticada).
2. Lea la descripción, el plazo esperado y si requiere aprobación.
3. Complete el formulario y envíe.
4. Monitoree en Solicitudes o en Aprobaciones pendientes.

Atender una solicitud (operador)

1. Liste por estado (EM_APROVACAO, APROVADA…).
2. Apruebe, rechace, cumpla o cancele según la etapa.
3. Si es necesario, la comunicación genera un ticket vinculado.

Reglas de negocio

Regla	Explicación
Solicitud ≠ incidente	Catálogo = solicitud planificada; ticket suelto = algo roto o urgente fuera del catálogo.
Aprobación	Los servicios marcados con aprobación se pausan hasta la decisión.
SLA de entrega	Puede diferir del SLA de incidente — lea la expectativa en la pantalla del servicio.
Handoff	Después de crear, el sistema dirige al aprobador o a la cola configurada.

Buenas prácticas

• Mantenga el catálogo esbelto y actualizado — un servicio obsoleto genera confusión.
• Estandarice la nomenclatura y los campos para permitir informes comparables.
• Vincule SLA y aprobación coherentes con el riesgo/costo del servicio.
• Deje en el público solo lo que el cliente realmente puede solicitar.

Errores comunes

Situación	Qué hacer
Servicio “comodín” que hace todo	Divídalo en elementos específicos; los formularios y el SLA se vuelven más precisos.
Formulario con demasiados campos	Pida solo lo necesario para ejecutar y aprobar.
Solicitud entrando como ticket común	Dirija al usuario al catálogo; medir la solicitud por separado mejora los indicadores.

Preguntas frecuentes

¿Cuál es la diferencia entre catálogo y KB?
El catálogo es lo que se puede solicitar; la KB es el conocimiento de cómo hacer. Catálogo = acción; KB = consulta.

¿La solicitud siempre pasa por aprobación?
No. La aprobación es una característica del elemento — algunos servicios son directos.

¿Puedo exponer el catálogo al cliente?
Sí, en el catálogo público, sin inicio de sesión — es la puerta del autoservicio.

Automatice vía API

El módulo está expuesto por API (/api/servicos-catalogo, /api/requisicoes-servicos, aprobar/rechazar/cumplir/cancelar; y el catálogo público en /api/public/servicos-catalogo). Referencia en developer.nyverra.com.

Escenarios de uso: de la solicitud al cumplimiento

1. Acceso con aprobación. El analista solicita acceso a un sistema sensible. El elemento del catálogo recopila el formulario, lo envía al gerente para aprobación y, una vez aprobado, cumple con el aprovisionamiento. El historial muestra quién solicitó, quién autorizó y cuándo se entregó.

2. Aprovisionamiento estandarizado. “Solicitar máquina virtual” tiene campos fijos (sistema, tamaño, entorno) y SLA de entrega. El equipo siempre recibe la información completa — sin el ida y vuelta de “faltó el entorno”.

3. Onboarding de colaborador. Un conjunto de elementos del catálogo (correo electrónico, acceso a la red, equipo, suscripciones) se convierte en un flujo predecible para cada nueva persona — en lugar de solicitudes sueltas.

KPIs del catálogo y de las solicitudes

Indicador	Qué revela
Tiempo medio de cumplimiento	Eficiencia de la entrega
Solicitudes por elemento	Demanda por servicio
Tasa de aprobación/rechazo	Alineación de políticas
Solicitudes canceladas	Ruido en el catálogo
Tiempo en EM_APROVACAO	Cuello de botella de aprobación

Con estos números, el catálogo deja de ser “vitrina” y pasa a ser un instrumento de gestión de la demanda.

Integración y automatización

Los elementos del catálogo pueden disparar automatizaciones: al aprobar “acceso VPN”, crear la tarea en el grupo de red; al cumplir una solicitud, notificar al solicitante. Conectado al CMDB, el cumplimiento puede registrar el activo entregado; conectado a contratos, puede debitar del pool de horas cuando corresponda. El catálogo se convierte en el punto de entrada de un flujo automatizado, no en un formulario que genera trabajo manual.

Checklist de implementación del catálogo

1. Defina las categorías de servicio (lo que ofrece TI).
2. Modele cada elemento: nombre, descripción, campos del formulario y visibilidad.
3. Determine qué elementos exigen aprobación y quién aprueba.
4. Asocie el SLA de entrega a cada servicio.
5. Publique en el catálogo interno y, lo que tenga sentido, en el público.
6. Capacite al equipo y comunique a los usuarios dónde pedir cada cosa.
7. Revise el uso periódicamente y ajuste los elementos poco utilizados.

Preguntas frecuentes adicionales

¿Cuántos elementos debo tener en el catálogo?
No existe un número mágico. Comience por los servicios de mayor demanda y crezca a medida que aparecen las solicitudes reales. Un catálogo inflado confunde más de lo que ayuda.

¿Puedo tener el mismo servicio en versiones diferentes?
Sí, siempre que la diferencia sea clara (ej.: “VM estándar” y “VM alta performance”). Lo importante es que el nombre y los campos comuniquen la diferencia.

¿Cómo sé que el catálogo está funcionando?
Cuando las solicitudes llegan a través de él en lugar de por ticket suelto — señal de que el usuario encontró el camino correcto.

Conclusión

Con un catálogo bien modelado, la demanda deja de ser impredecible y pasa a ser un flujo estandarizado, con aprobación, plazo y trazabilidad. Es la diferencia entre atender solicitudes y administrar servicios.