Modulo 01. Service Catalog como producto de servicio

Objetivo del modulo

Entender el catálogo de ServiceNow como capa de servicio y autoservicio, no solo como repositorio de formularios.

Resultados esperados

• Explicar qué papel cumple un catálogo bien diseñado.
• Relacionar catálogo con servicios, solicitudes y fulfillment.
• Evitar catálogos caóticos o centrados en el organigrama.

Desarrollo teorico

El Service Catalog de ServiceNow representa la entrada natural del usuario para solicitar servicios a TI o a otros departamentos corporativos como Recursos Humanos, Facilities, Legal o Finanzas. Su proposito fundamental no es mostrar formularios, sino exponer de forma clara y organizada que servicios puede solicitar un usuario, con que condiciones, que datos necesita proporcionar, que aprobaciones se requieren y que flujo de ejecucion se activara despues. Cuando esto se hace bien, el catalogo reduce tickets mal clasificados, mejora la experiencia del usuario, da trazabilidad completa al fulfillment y permite medir tiempos y costes por tipo de solicitud. Cuando se hace mal, el portal se convierte en un laberinto de formularios duplicados, solicitudes ambiguas y flujos de ejecucion invisibles.

El Service Catalog en ServiceNow se organiza en una jerarquia de tres niveles principales. Los Catalogs son contenedores de alto nivel que agrupan la oferta de servicios por area o proposito (por ejemplo, “IT Services”, “HR Services”, “Facilities”). Las Categories organizan los items dentro de cada catalogo en grupos logicos orientados al usuario (por ejemplo, dentro de IT Services: “Hardware”, “Software”, “Accesos y Permisos”, “Soporte y Reparaciones”). Los Catalog Items son las unidades concretas de solicitud que el usuario puede pedir. Esta organizacion debe disenarse desde la perspectiva del usuario que busca un servicio, no desde la estructura interna de los equipos que lo ejecutan.

El error mas comun en el diseno de catalogos es construirlos siguiendo el organigrama interno de TI. Un catalogo organizado como “Equipo de Redes”, “Equipo de Bases de Datos”, “Equipo de Seguridad” obliga al usuario a saber que equipo se encarga de lo que necesita. Un usuario que quiere pedir acceso VPN no deberia tener que saber si eso lo gestiona el equipo de redes, de seguridad o de identidad. La organizacion correcta es por necesidad del usuario: “Conectividad y Acceso Remoto”, “Software y Aplicaciones”, “Equipos y Hardware”. Esta orientacion reduce errores de clasificacion, mejora la experiencia de autoservicio y disminuye el volumen de solicitudes que llegan al service desk por canales informales.

El concepto de Service Offering conecta el catalogo con el modelo de servicio definido en CSDM (Common Service Data Model). Un Service Offering representa una variante o nivel de un servicio que se expone al usuario. Por ejemplo, el servicio “Email Corporativo” puede tener dos offerings: “Buzon estandar (5 GB)” y “Buzon premium (50 GB)”. Cada offering puede tener su propio catalog item, sus propias variables, sus propias aprobaciones y sus propios SLAs. Esta granularidad permite alinear el catalogo con los compromisos de servicio definidos y medir el cumplimiento por offering.

Cada catalog item debe disenarse con una vision completa que incluya la entrada (que datos necesita el usuario), el control (que aprobaciones son necesarias), la ejecucion (que tareas deben completarse para entregar el servicio) y el seguimiento (como puede el usuario ver el estado de su solicitud). Disenar la entrada sin pensar en la ejecucion produce formularios que capturan datos irrelevantes para el equipo que debe ejecutar el servicio. Disenar la ejecucion sin pensar en la entrada produce equipos de fulfillment que necesitan contactar al solicitante para obtener informacion que deberia haberse capturado en el formulario inicial.

El catalogo tambien actua como mecanismo de estandarizacion y gobierno. Cuando un servicio solo puede solicitarse a traves de un catalog item bien disenado, la organizacion garantiza que se capturan los datos minimos necesarios, que se aplican las aprobaciones correspondientes, que se generan las tareas adecuadas y que se mide el tiempo de entrega. Sin catalogo, los usuarios solicitan servicios por email, chat, telefono o pasillo, y el equipo de TI recibe trabajo sin estructura, sin datos completos, sin aprobaciones formales y sin metricas de cumplimiento.

La relacion entre el catalogo y el portal de autoservicio es critica. El portal (Service Portal o Employee Center en releases recientes) es la interfaz a traves de la cual el usuario accede al catalogo, busca servicios, completa formularios y hace seguimiento de sus solicitudes. Un catalogo bien disenado con un portal confuso produce la misma frustracion que un catalogo mal disenado con un portal bonito. Ambas capas deben disenarse juntas, priorizando la experiencia del usuario que busca resolver una necesidad concreta con el minimo esfuerzo posible.

Finalmente, el catalogo necesita metricas de uso para evolucionar. Las metricas mas utiles incluyen: volumen de solicitudes por item (que se pide mas), tasa de abandono de formularios (que items son demasiado complejos), tiempo medio de fulfillment por item (cuanto tarda en entregarse), satisfaccion del usuario post-fulfillment (fue buena la experiencia) y items sin uso durante periodos largos (que items deberian retirarse). Un catalogo que se publica y no se revisa se degrada con el tiempo: items obsoletos, descripciones que ya no reflejan el servicio real, aprobaciones heredadas que ya no tienen sentido y flujos de ejecucion que reflejan una organizacion que ya no existe.

Contenido ampliado

Puntos clave

• El catálogo debe diseñarse desde la necesidad del usuario.
• Un catálogo útil reduce ruido operativo.
• La lógica de servicio importa más que el formulario aislado.
• Catálogo y fulfillment deben pensarse juntos.

Checklist operativa

• Revisa si tu catálogo actual está orientado a usuario o a equipos internos.
• Agrupa por servicios o necesidades comprensibles.
• Elimina duplicidades y nomenclaturas confusas.
• Comprueba si cada item tiene fulfillment claro.

Errores frecuentes

• Construir el catálogo según el organigrama.
• Duplicar solicitudes parecidas.
• Diseñar items sin pensar en ejecución posterior.
• Sobrecargar la portada con demasiadas opciones.

Practica sugerida

Rediseña la estructura principal de un catálogo con 6-8 categorías de alto nivel orientadas a usuario.

Preguntas de autoevaluacion

• ¿Qué diferencia hay entre un catálogo orientado a servicio y uno orientado a formularios?
• ¿Qué hace que un item sea confuso para el usuario?
• ¿Por qué fulfillment y catálogo deben diseñarse juntos?

Cierre

El catálogo funciona cuando ayuda al usuario a pedir bien y al equipo a ejecutar con menos ruido.

Modulo 02. Catalog items, record producers y variables

Objetivo del modulo

Distinguir los patrones basicos de construccion del catalogo de ServiceNow y disenar variables utiles, mantenibles y orientadas tanto a la experiencia del usuario como a la calidad del dato.

Resultados esperados

• Diferenciar catalog item y record producer con criterios claros de decision.
• Disenar variables sin formularios innecesariamente complejos ni excesivamente simplificados.
• Relacionar diseno de variables con calidad del dato, fulfillment y reporting.
• Entender la mecanica de variable sets, client scripts de catalogo y UI policies.

Desarrollo teorico

El Service Catalog de ServiceNow ofrece dos patrones principales para capturar solicitudes: catalog items y record producers. Entender la diferencia entre ambos es fundamental porque elegir mal condiciona todo el flujo posterior, desde la experiencia del usuario hasta la ejecucion del servicio.

Un catalog item es una solicitud que genera un flujo de fulfillment estructurado propio. Cuando un usuario pide un catalog item, ServiceNow crea un request (sc_request), una o varias requested items (sc_req_item) y potencialmente varias catalog tasks (sc_task) para cada paso de ejecucion. Este patron es adecuado para solicitudes que representan un servicio o entrega con multiples pasos, aprobaciones y equipos involucrados. Ejemplo: solicitar un nuevo portatil implica aprobacion del manager, verificacion de stock por el equipo de assets, preparacion por el equipo de soporte y entrega al usuario. Cada paso puede ser una catalog task asignada a un grupo distinto.

Un record producer, en cambio, genera directamente un registro en una tabla destino con una experiencia de formulario simplificada. En vez de crear un request/requested item/task, crea directamente un incidente, un caso, un problema o cualquier otro tipo de registro. La experiencia para el usuario es similar (un formulario en el portal), pero el backend es muy distinto. El record producer es adecuado cuando solo necesitas crear un registro en otra tabla con una interfaz mas amigable que el formulario nativo. Ejemplo: un record producer que permite al usuario reportar una incidencia de software crea directamente un incidente en la tabla incident con categoria y subcategoria prepobladas.

El criterio de decision puede resumirse asi: si la solicitud requiere fulfillment propio con tareas, aprobaciones y entregables, usa catalog item. Si solo necesitas crear un registro en una tabla existente con mejor experiencia de usuario, usa record producer. Elegir record producer cuando necesitas fulfillment complejo obliga a construir toda la logica manualmente. Elegir catalog item cuando solo necesitas crear un incidente anade complejidad innecesaria al modelo de datos (request > req_item > task cuando solo necesitabas un incidente).

Las variables son la interfaz real entre el usuario y la plataforma dentro del catalogo. Cada variable representa un campo que el usuario completa al hacer su solicitud. Los tipos de variable mas comunes incluyen: Single Line Text (texto corto), Multi-Line Text (texto largo), Select Box (lista desplegable), Reference (referencia a otra tabla, por ejemplo seleccionar un usuario o un CI), CheckBox, Date, Attachment y Lookup Select Box (busqueda filtrada en otra tabla).

El diseno de variables determina la calidad del dato capturado y la eficiencia del fulfillment posterior. Si pides demasiados datos, el usuario se frustra, abandona la solicitud o rellena campos con informacion basura. Si pides demasiado poco, el equipo de fulfillment recibe trabajo incompleto y debe volver al solicitante para pedir informacion, duplicando esfuerzo y alargando tiempos. El equilibrio se consigue analizando que informacion es realmente necesaria para ejecutar el servicio (variables obligatorias) y cual es util pero opcional (variables opcionales con buenos textos de ayuda).

Los variable sets permiten reutilizar conjuntos de variables en multiples catalog items. Si cinco items distintos necesitan capturar los mismos datos de ubicacion (edificio, planta, puesto), un variable set evita definir esas variables cinco veces. Ademas, cualquier cambio en el variable set se propaga automaticamente a todos los items que lo usan. Esta modularidad mejora mantenimiento y consistencia.

Las dependencias entre variables se gestionan mediante UI Policies y Client Scripts de catalogo. Una UI Policy puede mostrar u ocultar variables condicionalmente: si el usuario selecciona "Nuevo portatil" como tipo de solicitud, aparecen variables de especificaciones; si selecciona "Ampliacion de memoria", aparecen variables distintas. Los Client Scripts de catalogo permiten logica mas compleja: validaciones en tiempo real, auto-poblado de campos basado en la seleccion del usuario o consultas dinamicas a la plataforma. Por ejemplo, cuando el usuario selecciona su ubicacion, un client script puede auto-rellenar el campo de centro de coste correspondiente.

La validacion de variables es otro aspecto critico. Una variable obligatoria sin validacion acepta cualquier texto, incluyendo entradas sin sentido. ServiceNow permite definir validaciones con regex patterns, scripts de validacion y mensajes de error personalizados. Una buena practica es validar formatos (email, telefono, codigos internos) y rangos (fechas futuras para solicitudes de provisionamiento, cantidades dentro de limites razonables).

El orden y la agrupacion de variables dentro del formulario afectan directamente a la experiencia. Las variables deben seguir un orden logico que refleje el proceso mental del usuario: primero identificar que necesita, luego especificar detalles, finalmente confirmar datos de entrega o aprobacion. La agrupacion visual mediante containers y separadores ayuda a que formularios largos sean comprensibles.

Finalmente, las variables capturadas se almacenan en la tabla sc_item_option_mtom y pueden accederse desde workflows, flows y business rules mediante la API de variables. El fulfillment team accede a ellas desde la requested item o catalog task. Si las variables estan mal nombradas (nombres tecnicos poco descriptivos como variable_1, variable_2), el equipo de fulfillment pierde tiempo interpretando que significa cada campo. Usar nombres descriptivos tanto en el name interno como en el question text visible es una practica basica de mantenibilidad.

Contenido ampliado

Puntos clave

• Catalog item y record producer no cumplen la misma funcion; elegir mal complica todo el flujo.
• Las variables deben equilibrar experiencia de usuario y necesidad real de datos para fulfillment.
• Un mal formulario genera ruido, retrabajo y datos de baja calidad.
• El diseno de la entrada (variables) condiciona fulfillment, reporting y satisfaccion del usuario.
• Los variable sets permiten reutilizacion y consistencia entre items.
• UI Policies y Client Scripts de catalogo habilitan formularios dinamicos y validaciones.

Checklist operativa

• Decide si el caso necesita catalog item o record producer aplicando el criterio de fulfillment.
• Revisa numero y calidad de variables: elimina las que no aportan valor al fulfillment.
• Asegurate de que cada variable obligatoria tiene validacion y texto de ayuda claro.
• Identifica variables comunes entre items y crea variable sets reutilizables.
• Comprueba que las descripciones (question text y help text) ayudan realmente al usuario.
• Verifica que el equipo de fulfillment puede acceder y entender las variables capturadas.
• Testea el formulario completo como si fueras un usuario sin conocimiento tecnico.

Errores frecuentes

• Crear record producers cuando en realidad hace falta un catalog item con fulfillment completo.
• Pedir demasiados datos "por si acaso", creando formularios largos que el usuario abandona.
• Disenar variables ambiguas sin textos de ayuda ni validacion de formato.
• Ignorar como el equipo de fulfillment consumira la informacion capturada.
• No usar variable sets, duplicando variables identicas en multiples items.
• Usar nombres internos de variables poco descriptivos que dificultan scripting y mantenimiento.
• No probar el formulario desde la perspectiva del usuario final.

Practica sugerida

Disena dos elementos de catalogo: (1) un catalog item para "Solicitar nuevo portatil" con al menos seis variables (tipo de equipo, sistema operativo, ubicacion de entrega, centro de coste, justificacion, fecha necesaria), aprobacion del manager, una catalog task para preparacion y otra para entrega. (2) Un record producer para "Reportar incidencia de software" que cree directamente un incidente con categoria "Software", subcategoria prepoblada y tres variables (aplicacion afectada como referencia a tabla de aplicaciones, descripcion del problema, urgencia percibida). Justifica por que cada caso usa el patron elegido.

Preguntas de autoevaluacion

• ¿Cuando usarias un record producer en lugar de un catalog item y viceversa?
• ¿Que variable probablemente sobra en una solicitud y como lo determinas?
• ¿Como afecta el diseno del formulario a la calidad del fulfillment y del reporting?
• ¿Que ventaja tienen los variable sets frente a definir variables individualmente en cada item?
• ¿Por que es importante probar el formulario desde la perspectiva del usuario final?

Cierre

El patron correcto (item vs producer) y las variables bien pensadas reducen friccion en la entrada del usuario y errores en la ejecucion del servicio. Un catalogo bien disenado no es el que tiene mas formularios, sino el que captura el dato justo para que el servicio se ejecute con calidad.