ServiceNow

ServiceNow Service Catalog & Portal

Intermediate 6 modules • 14 hours •49 € VAT included

Curso centrado en Service Catalog y Portal en ServiceNow: catálogo como producto de servicio, catalog items, record producers, variables, aprobaciones, fulfillment y experiencia de autoservicio.

Un catálogo útil no es una lista de formularios. Debe representar servicios solicitables, variables bien diseñadas, tareas de fulfillment, aprobaciones razonables y una experiencia de portal que reduzca fricción y errores.

The first module is free. Request information about full-course access.

Please note: the course material (modules, exam, glossary and labs) is written in Spanish. Only the site interface is available in English. A good reading level of Spanish is required.

On sale soon. The first module is free: sign up and start.

hola@itlabcert.com

Request received. We will reply to your email within 48 working hours. No need to send it again.

For myself For my company or team

I have read and accept the privacy policy. We will only use your data to reply to you.

hola@itlabcert.com

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

Elemento	Propósito
Categoría	Agrupar servicios o solicitudes de forma lógica
Catálogo	Organizar la oferta de servicios solicitables
Item	Unidad concreta de solicitud
Fulfillment	Trabajo posterior que ejecuta la entrega

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.

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.

What you will learn

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.

Module contents

Desarrollo teorico
Contenido ampliado
Puntos clave
Checklist operativa
Errores frecuentes
Practica sugerida
Preguntas de autoevaluacion
Cierre