ServiceNow

ServiceNow ITSM (Incident, Problem, Change)

Intermedio 8 modulos • 24 horas •69 € IVA incluido

Curso centrado en cómo ServiceNow implementa las prácticas ITSM más usadas: Incident, Problem y Change. Explica el modelo de datos, los flujos de trabajo, las tareas, aprobaciones, SLAs, colas operativas y reporting necesario para operar soporte y cambios con trazabilidad.

ServiceNow ITSM no consiste en “rellenar tickets”. La plataforma conecta tablas, estados, asignaciones, SLAs, aprobaciones, work notes y reporting para sostener un modelo operativo. El curso aterriza esa realidad y diferencia claramente incidentes, problemas, cambios y sus relaciones.

El primer modulo es gratuito. Solicita informacion para conocer las condiciones de acceso al curso completo.

Proximamente a la venta. El primer modulo es gratuito: registrate y empieza.

hola@itlabcert.com

Solicitud recibida. Te responderemos a tu correo en menos de 48 horas laborables. No hace falta que la envies otra vez.

Para mi Para mi empresa o equipo

He leido y acepto la politica de privacidad. Usaremos tus datos unicamente para responderte.

hola@itlabcert.com

Modulo 01. Marco ITSM en ServiceNow

Objetivo del modulo

Entender cómo ServiceNow estructura las prácticas básicas de ITSM y cómo se relacionan incidentes, problemas, cambios, tareas y SLAs dentro de la plataforma.

Resultados esperados

Diferenciar los objetivos de Incident, Problem y Change.
Relacionar tablas y procesos ITSM principales.
Ubicar estas prácticas dentro del modelo de datos de ServiceNow.

Desarrollo teorico

ServiceNow implementa ITSM sobre una base comun de tablas derivadas de task. Este diseno arquitectonico no es casual: la tabla task es la tabla padre que define campos compartidos como number, state, assignment_group, assigned_to, priority, opened_at, closed_at, work_notes, additional_comments, short_description y description. Cuando las tablas incident, problem, change_request, sc_req_item y otras heredan de task, reciben automaticamente todos estos campos y los comportamientos asociados (business rules, ACLs, notificaciones). Esta herencia reduce duplicidad tecnica enormemente, pero obliga a entender bien que persigue cada practica para no usarlas como si fueran equivalentes.

Incident Management tiene un objetivo claro y especifico: restaurar el servicio al usuario lo antes posible, minimizando el impacto de la interrupcion. No busca encontrar la causa raiz ni implementar soluciones permanentes. Su exito se mide en tiempo de respuesta, tiempo de resolucion y satisfaccion del usuario. Un incidente bien gestionado puede resolverse con un workaround temporal que devuelve el servicio mientras se investiga la causa raiz por otra via. La tabla incident anade a los campos heredados de task campos propios como caller_id (quien reporta), category y subcategory (clasificacion), impact y urgency (que determinan priority), resolved_by, close_code y resolution_notes.

Problem Management existe para reducir la recurrencia de incidentes y eliminar causas raiz. No se activa para cada incidente individual, sino cuando hay patrones de recurrencia, impacto grave o sospecha de causa comun que justifica una investigacion estructurada. La tabla problem hereda de task y anade campos como known_error, workaround, root_cause y first_reported_by_task (el incidente que lo origino). Un problem record bien gestionado incluye analisis de causa raiz documentado, workaround disponible para el service desk y, cuando la solucion definitiva requiere una modificacion, un change request asociado.

Change Management controla el riesgo de las modificaciones sobre servicios, infraestructura y configuracion. Su objetivo no es frenar cambios sino realizarlos con trazabilidad, evaluacion de riesgo y capacidad de reversion. La tabla change_request hereda de task y anade campos especificos como type (standard, normal, emergency), risk, impact, CAB_required, start_date, end_date, implementation_plan, backout_plan y test_plan. La relacion entre Change y CMDB es bidireccional: los CIs afectados se asocian al cambio para calcular impacto, y los incidentes post-cambio se correlacionan para detectar causas.

La cadena operativa entre estas tres practicas es donde ServiceNow muestra su mayor valor. Un incidente critico recurrente puede abrir un problem record que investigue la causa raiz. El analisis de causa raiz puede determinar que se necesita una modificacion en infraestructura o configuracion, lo que genera un change request. El change request se evalua, aprueba, ejecuta y valida. Si el cambio resuelve el problema, los incidentes relacionados dejan de recurrencia. Si el cambio falla, puede generar nuevos incidentes. ServiceNow facilita esta cadena mediante campos de referencia que vinculan registros entre si: un incidente puede tener un problem_id asociado, un problem puede tener un change_request vinculado, y un change puede tener affected CIs que lo conectan con la CMDB.

El modelo de estados en cada practica merece atencion especifica. Un incidente tipicamente pasa por New, In Progress, On Hold, Resolved y Closed. Un problem puede estar en New, Assess, Root Cause Analysis, Fix in Progress, Resolved y Closed. Un change request sigue un flujo que incluye New, Assess, Authorize, Scheduled, Implement, Review y Closed. Cada transicion de estado puede disparar business rules, notificaciones, recalculos de SLA y actualizaciones de metricas. Los estados no son etiquetas decorativas: son el mecanismo que conecta la logica de negocio con el dato. Un incidente que permanece en New durante horas consume SLA sin que nadie trabaje en el. Un problem que pasa meses en Assess sin avanzar indica que el proceso de analisis de causa raiz no funciona. Un cambio que salta directamente de New a Implement sin pasar por evaluacion de riesgo ni aprobacion es una senal de alarma de gobierno.

El marco ITSM en ServiceNow tambien incluye componentes transversales que sostienen las tres practicas. Los SLAs definen compromisos temporales por tipo de registro, prioridad y servicio. Las assignment rules enrutan registros al grupo correcto basandose en clasificacion, CI o ubicacion. Las notificaciones informan a los stakeholders relevantes en cada transicion de estado. Los dashboards proporcionan visibilidad operativa y tactica. Los knowledge articles conectan la base de conocimiento con incidentes y problemas para acelerar resolucion y reducir escalaciones. Cada uno de estos componentes depende de la calidad del dato en los registros: si la categoria esta mal, el enrutamiento falla; si la prioridad esta inflada, los SLAs pierden significado; si los CIs no estan asociados, el analisis de impacto es imposible.

Un error estrategico frecuente es tratar ServiceNow como un sistema de tickets en vez de como un sistema de gestion de servicios. Un sistema de tickets almacena solicitudes y las cierra. Un sistema ITSM conecta incidentes con problemas, problemas con cambios, cambios con CIs, CIs con servicios y servicios con valor de negocio. Esta conexion solo funciona si los equipos usan los registros con disciplina, rellenan campos criticos, vinculan registros relacionados y respetan los flujos de estado definidos.

Contenido ampliado

Practica	Objetivo principal	Tabla típica
Incident	Restaurar servicio	`incident`
Problem	Eliminar causa raíz	`problem`
Change	Controlar modificaciones y riesgo	`change_request`
Task asociada	Ejecutar trabajo puntual	Tablas derivadas o relacionadas

Puntos clave

Incident, Problem y Change comparten base de plataforma, pero no objetivo.
La relación entre prácticas es operativa y también de datos.
Work notes, asignaciones y SLAs sostienen el modelo diario.
Una mala calidad de registro distorsiona proceso y reporting.

Checklist operativa

Revisa las tablas principales de ITSM.
Identifica cómo se relaciona un incidente con un problema y un cambio.
Comprueba qué campos son comunes por herencia de task.
Observa cómo el estado afecta a SLA y reporting.

Errores frecuentes

Usar Incident para trabajos que en realidad son Problem o Change.
No vincular registros relacionados.
Tratar ServiceNow como simple repositorio de tickets.
Ignorar impacto del dato sobre automatización y reporting.

Practica sugerida

Dibuja un flujo donde un incidente grave se relaciona con un problem y desemboca en un cambio normal con aprobación.

Preguntas de autoevaluacion

¿Qué diferencia funcional hay entre Incident y Problem?
¿Por qué Change no debe usarse como reemplazo de Incident?
¿Qué aporta la herencia desde task?

Cierre

Comprender el marco ITSM en ServiceNow es entender cómo la plataforma convierte procesos en datos, estados y relaciones operables.

Gestionar incidentes en ServiceNow desde el alta hasta la resolucion, asegurando clasificacion, prioridad, asignacion y comunicacion correctas.

Que aprenderas

Explicar el ciclo de vida completo de un incidente con sus estados y transiciones.
Diferenciar impacto, urgencia y prioridad con criterio operativo.
Mejorar asignacion y resolucion con buen uso del registro.
Entender como el incidente se conecta con SLAs, CMDB y Problem Management.

Contenido del modulo

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