ServiceNow ITSM (Incident, Problem, Change)
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.
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.
Modulo 02. Incident Management: registro a resolucion
Objetivo del modulo
Gestionar incidentes en ServiceNow desde el alta hasta la resolucion, asegurando clasificacion, prioridad, asignacion y comunicacion correctas.
Resultados esperados
- 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.
Desarrollo teorico
El incidente en ServiceNow representa una interrupcion o degradacion no planificada de un servicio de TI. Su gestion correcta no empieza en la resolucion tecnica sino en la calidad del registro inicial, porque ese registro condiciona todo lo que viene despues: enrutamiento al grupo correcto, calculo de prioridad, activacion de SLAs, visibilidad en dashboards y trazabilidad para posibles problemas recurrentes. Un incidente mal clasificado puede ir al grupo equivocado, incumplir tiempos de respuesta, inflar metricas de areas que no correspondian y dificultar el analisis posterior de tendencias.
El ciclo de vida estandar de un incidente en ServiceNow sigue estos estados: New (recien creado), In Progress (en investigacion o diagnostico), On Hold (pausado por dependencia externa o espera del usuario), Resolved (solucion aplicada pendiente de confirmacion) y Closed (cerrado definitivamente). Cada transicion de estado puede disparar business rules, notificaciones, recalculos de SLA y actualizaciones de metricas. Por eso, los estados no son etiquetas decorativas; son mecanismos que condicionan logica de negocio real. Un incidente que permanece en New durante horas sin asignacion esta consumiendo tiempo de SLA sin que nadie trabaje en el. Un incidente que pasa a Resolved sin documentar la solucion crea deuda operativa para futuros casos similares.
La priorizacion se basa en la combinacion de impacto y urgencia. El impacto mide la amplitud del efecto: cuantos usuarios, servicios o funciones de negocio se ven afectados. Un fallo que afecta a toda la sede tiene impacto alto; un problema en el portatil de un usuario tiene impacto bajo. La urgencia mide la tolerancia temporal: cuanto tiempo puede el negocio soportar la situacion antes de que el dano sea significativo. Un sistema de facturacion caido en dia de cierre fiscal tiene urgencia critica; el mismo sistema caido un sabado por la noche tiene urgencia menor. ServiceNow calcula la prioridad automaticamente a partir de una matriz impacto-urgencia configurable. La prioridad resultante (P1 a P5 tipicamente) determina tiempos de respuesta y resolucion definidos en los SLA definitions.
El error mas comun en priorizacion es que los usuarios o analistas marquen todo como urgente. Cuando el 80% de los incidentes son P1 o P2, la prioridad pierde significado, los equipos se saturan y los incidentes realmente criticos no reciben la atencion diferenciada que necesitan. La solucion pasa por definir criterios claros de impacto y urgencia, formar a los analistas de primer nivel y revisar periodicamente la distribucion de prioridades para detectar inflacion.
La asignacion del incidente al grupo correcto es otro punto critico. ServiceNow permite definir assignment rules que enrutan automaticamente basandose en categoria, subcategoria, CI afectado, localizacion o cualquier combinacion de campos. Cuando estas reglas estan bien configuradas, el incidente llega al grupo responsable sin intervencion manual. Cuando no existen o estan mal definidas, los analistas de primer nivel deben reasignar manualmente, lo que anade tiempo, errores y frustracion. La categoria y subcategoria del incidente son los campos mas influyentes en el enrutamiento y deben alinearse con la estructura de servicios y equipos de soporte.
La relacion entre incidentes y CMDB merece atencion especial. El campo cmdb_ci permite asociar el incidente con el configuration item afectado. Esta relacion habilita multiples automatizaciones: calcular el business service impactado, aplicar SLAs especificos del servicio, enrutar al grupo que gestiona ese CI y alimentar dashboards de disponibilidad. Sin embargo, en muchas organizaciones el campo CI se deja vacio o se rellena incorrectamente. Cuando esto ocurre, el analisis de impacto, la gestion de cambios relacionados y el reporting por servicio se degradan significativamente.
El incidente no debe intentar resolver la causa raiz estructural; esa es la funcion de Problem Management. Sin embargo, un buen registro de incidente es la materia prima para abrir problems bien fundamentados. Las work notes internas deben documentar hipotesis, pasos de diagnostico, workarounds aplicados y cualquier patron observado. Si un analista resuelve un incidente con un workaround pero no deja constancia, el siguiente analista que enfrente el mismo problema empezara de cero. Los additional_comments (customer visible) gestionan la comunicacion con el solicitante: confirmacion de recepcion, actualizaciones de estado y confirmacion de resolucion.
Los SLAs en Incident Management miden tiempos de respuesta y resolucion segun la prioridad. ServiceNow soporta SLA definitions que se activan automaticamente cuando un incidente cumple ciertas condiciones (prioridad, servicio, ubicacion) y pausan o reinician el reloj segun cambios de estado (por ejemplo, On Hold puede pausar el SLA). La salud de los SLAs depende directamente de la calidad de priorizacion, asignacion y gestion de estados. Un equipo que abusa del estado On Hold para evitar breaches de SLA esta enmascarando un problema real de capacidad o priorizacion.
Contenido ampliado
| Campo o concepto | Uso operativo | Efecto si se gestiona mal |
|---|---|---|
| Impacto | Dimensionar alcance del incidente | Prioridad mal calculada, SLA incorrecto |
| Urgencia | Medir criticidad temporal | Incidentes criticos tratados como rutinarios |
| Prioridad | Ordenar tratamiento y activar SLA | Colas saturadas sin diferenciacion real |
| Assignment group | Dirigir el ticket al equipo responsable | Reasignaciones manuales, tiempo perdido |
| Category / Subcategory | Clasificar y enrutar | Enrutamiento fallido, reporting distorsionado |
| cmdb_ci | Asociar con configuration item | Impacto de servicio invisible, SLAs genericos |
| Work notes | Documentar diagnostico interno | Perdida de conocimiento, retrabajos |
| Additional comments | Comunicar al solicitante | Expectativa no gestionada, escalaciones innecesarias |
Puntos clave
- Un buen registro inicial mejora todo el flujo posterior: routing, SLA, reporting y analisis de tendencias.
- Impacto y urgencia no son sinonimos; su combinacion determina la prioridad real.
- El incidente busca restaurar servicio lo antes posible, no resolver siempre la causa raiz.
- La comunicacion con usuario (additional comments) y las notas internas (work notes) deben separarse siempre.
- La relacion con CMDB habilita analisis de impacto y SLAs por servicio.
- Los SLAs dependen de buena priorizacion y gestion honesta de estados.
Checklist operativa
- Verifica categoria, subcategoria e impacto al registrar un incidente.
- Revisa como se calcula la prioridad en tu instancia (matriz impacto-urgencia).
- Asegura que el assignment group es correcto antes de guardar el registro.
- Documenta diagnostico y resolucion con claridad en work notes.
- Asocia el CI afectado siempre que sea posible.
- Confirma con el solicitante que la resolucion es satisfactoria antes de cerrar.
Errores frecuentes
- Marcar casi todo como urgente, vaciando de significado la priorizacion.
- Usar work notes para mensajes al usuario o additional comments para notas internas.
- Reabrir incidentes por mala resolucion o falta de confirmacion con el solicitante.
- No escalar a problem cuando hay recurrencia clara o impacto grave sin causa raiz identificada.
- Dejar el campo CI vacio en la mayoria de incidentes.
- Abusar de On Hold para evitar breaches de SLA en lugar de resolver el problema de capacidad.
Practica sugerida
Analiza tres incidentes (reales o ficticios) con los siguientes datos: servicio afectado, numero de usuarios impactados, tolerancia temporal del negocio, CI relacionado. Para cada uno: (1) justifica impacto y urgencia, (2) calcula prioridad segun la matriz, (3) determina el grupo de asignacion, (4) redacta una work note de diagnostico y un additional comment al solicitante, (5) decide si el caso amerita apertura de un problem record.
Preguntas de autoevaluacion
- ¿Que diferencia operativa hay entre impacto y urgencia?
- ¿Cuando un incidente deberia derivar en la apertura de un problem record?
- ¿Que campos son criticos para que el enrutamiento automatico funcione correctamente?
- ¿Por que abusar del estado On Hold daniha la credibilidad de las metricas de SLA?
- ¿Que informacion deberia contener una work note util para el siguiente analista?
Cierre
Incident Management funciona mejor cuando el registro representa correctamente el problema, las prioridades reflejan el impacto real del negocio y la documentacion guia la resolucion en lugar de anadir confusion operativa.
Registrate gratis para acceder a los 6 modulos restantes, examenes y certificados.
Crear cuenta gratisResultados de aprendizaje
- Explicar cómo ServiceNow modela Incident, Problem y Change.
- Diferenciar los flujos y objetivos de cada práctica.
- Entender tareas, aprobaciones, work notes y colas de trabajo.
- Interpretar SLAs, prioridades y reporting operativo.
- Operar un escenario integrado ITSM con mejor calidad de dato y trazabilidad.
Publico objetivo
Analistas ITSM, administradores ServiceNow, consultores funcionales, service owners y equipos de soporte que trabajen con incidentes, problemas y cambios.
Requisitos previos
Conviene conocer los fundamentos de ServiceNow y nociones básicas de gestión de servicios.
Guia de estudio
Guia de estudio - ServiceNow ITSM (Incident, Problem, Change)
Ritmo sugerido
- Estudiar 1 modulo por sesion, prestando atencion a definiciones, comparativas y errores frecuentes.
- Tomar notas propias y resumir cada modulo en 5-10 ideas accionables.
- Dejar para el final de la sesion la practica sugerida y las preguntas de autoevaluacion.
Plan de avance
- Bloque 1: Marco itsm en servicenow.
- Bloque intermedio: Incident management registro a resolucion y siguientes para consolidar criterio.
- Bloque final: Escenario integrado de operacion itsm y repaso transversal del resto del itinerario.
Metodo recomendado
Leer primero el objetivo del modulo, despues el desarrollo teorico, y solo entonces pasar a tabla, checklist, errores y practica. Ese orden ayuda a construir criterio antes de memorizar detalles.
Evidencias de aprendizaje
- Capacidad para explicar el modulo sin leerlo.
- Capacidad para distinguir conceptos proximos sin confundirlos.
- Capacidad para trasladar el contenido a un escenario de trabajo real.
Examen disponible
Este curso incluye un examen de 15 preguntas. Registrate gratis para acceder al examen y obtener tu certificado digital.
Crear cuenta gratisGlosario - ServiceNow ITSM (Incident, Problem, Change)
Incident Management
Practica orientada a restaurar servicio lo antes posible.
Problem Management
Practica orientada a reducir recurrencia y atacar causa raiz.
Change Enablement
Practica para controlar riesgo al introducir cambios.
Service Request
Solicitud predefinida y normalmente de bajo riesgo.
Service Desk
Punto de contacto entre usuarios y proveedor del servicio.
Known Error
Problema con causa raiz documentada y workaround conocido.
Laboratorio / Taller
Laboratorio o taller - ServiceNow ITSM (Incident, Problem, Change)
Taller orientado a aplicar ServiceNow ITSM (Incident, Problem, Change) en un escenario controlado, convirtiendo teoria en una secuencia de trabajo observable.
Pasos
- Leer el escenario y delimitar objetivo, actores y restricciones.
- Usar como apoyo los modulos: Marco itsm en servicenow, Incident management registro a resolucion, Problem management y analisis causa raiz, Change management y control de riesgo.
- Diseñar una respuesta, configuracion, flujo o decision justificada.
- Validar riesgos, dependencias y evidencias de exito.
- Documentar que pantallas, comandos, politicas o componentes se tocariam en una implantacion real.
Evidencias esperadas
- Artefacto final usable.
- Razonamiento tecnico de las decisiones tomadas.
- Checklist de validacion o criterios de salida.
Caso practico integrador
Caso practico integrador - ServiceNow ITSM (Incident, Problem, Change)
Una organizacion necesita mejorar o implantar capacidades relacionadas con ServiceNow ITSM (Incident, Problem, Change). Tiene restricciones de tiempo, riesgos operativos y multiples actores implicados, por lo que no basta con listar conceptos: hay que convertirlos en decisiones, artefactos y prioridades.
Entregables
- Mapa del problema y contexto.
- Propuesta de enfoque o arquitectura.
- Riesgos, dependencias y decisiones clave.
- Plan de validacion o seguimiento.
Criterios de calidad
- Coherencia tecnica con el contenido del curso.
- Claridad para priorizar y justificar decisiones.
- Aterrizaje realista en entregables y seguimiento.
Modulos especialmente utiles
- Marco itsm en servicenow
- Incident management registro a resolucion
- Problem management y analisis causa raiz
- Change management y control de riesgo
Recursos - ServiceNow ITSM (Incident, Problem, Change)
Referencias oficiales y recomendadas
Estrategia de uso de bibliografia y documentacion
Empieza por la documentacion oficial del fabricante o framework, usa despues el material del curso para consolidar el modelo mental y consulta la referencia tecnica cuando necesites comandos, configuracion o detalles operativos concretos.
Evaluacion
Evaluacion - ServiceNow ITSM (Incident, Problem, Change)
Preguntas abiertas de repaso
- Explica con un ejemplo por que 'Marco itsm en servicenow' importa dentro del curso.
- Explica con un ejemplo por que 'Incident management registro a resolucion' importa dentro del curso.
- Explica con un ejemplo por que 'Problem management y analisis causa raiz' importa dentro del curso.
- Explica con un ejemplo por que 'Change management y control de riesgo' importa dentro del curso.
- Explica con un ejemplo por que 'Tareas aprobaciones y work notes' importa dentro del curso.
Actividades de validacion
- Comparar dos conceptos proximos del curso y justificar cuando usar cada uno.
- Redactar un mini runbook, checklist o decision memo basado en un modulo.
- Explicar a otra persona una decision tecnica o de gobierno derivada del curso.