Modulo 01. Que es ServiceNow y como se estructura

Objetivo del modulo

Entender que es ServiceNow, como se organiza la Now Platform y que componentes basicos debe conocer cualquier persona que vaya a operar o configurar la herramienta.

Resultados esperados

• Explicar ServiceNow como plataforma y no solo como aplicacion ITSM.
• Distinguir instancia, modulo, aplicacion y tabla.
• Identificar los grandes bloques funcionales de la plataforma.
• Comprender la diferencia entre configuracion y personalizacion y sus implicaciones.

Desarrollo teorico

ServiceNow es una plataforma cloud multi-tenant construida sobre una arquitectura que combina capacidades SaaS y PaaS. Aunque alcanzo popularidad mundial por su modulo de ITSM, reducirla a una herramienta de tickets es un error estrategico que limita su aprovechamiento. La Now Platform es un motor de datos, procesos, automatizacion y experiencia de usuario sobre el cual se construyen aplicaciones empresariales de muy diversa naturaleza: ITSM, ITOM, HRSD, CSM, SecOps, SPM, GRC y muchas mas. Todas comparten la misma base tecnologica, lo que significa que aprender bien los fundamentos de la plataforma te prepara para operar en cualquiera de esas familias.

La unidad central del modelo de datos es la tabla. Cada tabla almacena registros compuestos por campos. Lo que diferencia a ServiceNow de una base de datos relacional convencional es que sobre esas tablas se superponen automaticamente formularios, listas, ACLs, business rules, client scripts, notificaciones, flujos de trabajo y una capa de experiencia de usuario. Es decir, la tabla no es solo almacenamiento; es el punto de partida de toda la logica de negocio. Cuando creas una tabla o extiendes una existente, la plataforma genera automaticamente interfaz, seguridad basica y capacidad de reporting.

El concepto mas importante para un principiante es la herencia de tablas. La tabla task es la tabla padre por excelencia en ITSM. De ella heredan incident, problem, change_request, sc_req_item y muchas otras. Esto significa que campos como number, state, assignment_group, priority, opened_by y work_notes existen en todas las tablas hijas porque vienen de task. La herencia permite reutilizar estructura y comportamiento: una business rule en task puede afectar a todas las tablas hijas. Si no comprendes este mecanismo, acabaras duplicando campos, creando configuraciones redundantes o sin entender por que un reporte basado en task incluye incidentes, problemas y cambios mezclados.

ServiceNow se organiza por instancias. Una instancia es un entorno completo e independiente de la plataforma con su propia URL, datos, configuraciones y usuarios. Una organizacion tipica mantiene al menos tres instancias: desarrollo (dev), pruebas (test) y produccion (prod). Ademas, los profesionales suelen tener una PDI (Personal Developer Instance) gratuita para practicar y experimentar sin riesgo. Esta separacion existe porque la plataforma no debe configurarse directamente en produccion salvo emergencias controladas. El traslado de cambios entre instancias se gestiona mediante Update Sets en entornos tradicionales o mediante pipelines de Application Repository y Source Control en organizaciones mas maduras. Un Update Set es un contenedor que agrupa todas las personalizaciones realizadas en una instancia durante un periodo, permitiendo exportarlas e importarlas en otra instancia de forma controlada.

La navegacion en ServiceNow se apoya en el Application Navigator, un panel lateral que organiza modulos dentro de aplicaciones. Cada aplicacion agrupa modulos relacionados: por ejemplo, la aplicacion Incident contiene modulos como Create New, Open, All, etc. Mas alla del navegador clasico, la plataforma ofrece Next Experience con menus unificados y workspaces orientados a roles, como Agent Workspace para analistas de soporte o ITOM Workspace para operaciones. Comprender que la interfaz esta separada del modelo de datos es fundamental: puedes tener multiples vistas de formulario para la misma tabla, diferentes layouts por rol y experiencias personalizadas sin alterar la estructura subyacente.

En cuanto a la diferencia entre configuracion y personalizacion, este es un punto critico para cualquier equipo. Configurar significa aprovechar capacidades nativas de la plataforma: crear campos, ajustar formularios, definir vistas, activar business rules out-of-the-box, configurar notificaciones, crear catalog items o diseñar flujos en Flow Designer. Personalizar implica escribir codigo custom, alterar scripts del sistema, crear componentes UI propios o modificar comportamientos de la plataforma mas alla de lo previsto. En entornos empresariales maduros se maximiza configuracion y se controla estrictamente la personalizacion por tres razones: cada personalizacion incrementa el coste de mantenimiento, complica las actualizaciones de version (upgrades) y puede generar deuda tecnica dificil de auditar. La regla general es: si la plataforma ofrece una forma estandar de resolver un requisito, usala antes de escribir codigo.

Otro concepto estructural es el de scoped applications versus global scope. ServiceNow permite desarrollar aplicaciones en un ambito protegido (scoped) que encapsula tablas, scripts y configuraciones, evitando conflictos con el resto de la plataforma. Las aplicaciones globales operan en el ambito general y pueden afectar a todo el sistema. Para desarrollos propios o integraciones, el scope protegido es la practica recomendada porque facilita el gobierno, la portabilidad y la seguridad del desarrollo.

Finalmente, la plataforma sigue un ciclo de releases semestrales identificados por nombre de ciudad (San Diego, Tokyo, Utah, Vancouver, Washington, Xanadu). Cada release introduce nuevas funcionalidades, mejora rendimiento y puede deprecar APIs o componentes antiguos. Mantenerse al dia con el roadmap de releases es importante para planificar upgrades y aprovechar mejoras sin acumular deuda tecnica.

Contenido ampliado

Puntos clave

• ServiceNow es plataforma, no solo herramienta de tickets; ITSM es una de muchas aplicaciones.
• El modelo de tablas y herencia desde task es el concepto mas importante para empezar.
• Las instancias separan desarrollo, prueba y produccion; nunca configures directamente en prod.
• Configuracion y personalizacion no son equivalentes; maximiza configuracion, controla personalizacion.
• Los Update Sets gestionan el traslado de cambios entre instancias.

Checklist operativa

• Identifica que aplicaciones usa tu organizacion sobre ServiceNow.
• Ubica que instancias existen (dev, test, prod) y quien gestiona cada una.
• Revisa las tablas base de ITSM: task, incident, problem, change_request, sc_req_item.
• Distingue al menos tres ejemplos de configuracion frente a personalizacion en tu entorno.
• Verifica si tu organizacion usa Update Sets o pipelines de Application Repository.
• Comprueba que version (release) tiene tu instancia de produccion.

Errores frecuentes

• Pensar que cada modulo o aplicacion vive en una plataforma distinta e independiente.
• Ignorar la herencia entre tablas y crear campos duplicados en tablas hijas.
• Configurar directamente en produccion sin pasar por dev y test.
• Personalizar con codigo algo que ya existe como capacidad estandar de la plataforma.
• No controlar Update Sets, mezclando cambios de distintos proyectos en un solo set.
• Subestimar el impacto de los upgrades cuando hay personalizaciones extensas.

Practica sugerida

Accede a una PDI gratuita y realiza lo siguiente: (1) navega al Application Navigator y localiza los modulos de Incident, Problem y Change, (2) abre la tabla task desde System Definition > Tables y observa que tablas la extienden, (3) crea un Update Set con tu nombre en la instancia y verifica que queda activo, (4) identifica al menos dos campos que incident hereda de task.

Preguntas de autoevaluacion

• ¿Por que ServiceNow debe entenderse como plataforma y no solo como herramienta ITSM?
• ¿Que aporta la tabla task a modulos como Incident, Problem o Change?
• ¿Que riesgos tiene personalizar demasiado pronto sin agotar las opciones de configuracion?
• ¿Para que sirve un Update Set y por que no debe configurarse directamente en produccion?
• ¿Que diferencia hay entre scope global y scoped application?

Cierre

La mejor base para aprender ServiceNow es entender su estructura logica: tablas, herencia, instancias, configuracion versus personalizacion y ciclo de vida de cambios. Sin eso, el resto de la plataforma parece una coleccion de pantallas en vez de un sistema coherente y gobernable.

Modulo 02. Interfaz, navegacion y experiencia de usuario

Objetivo del modulo

Moverse con soltura por la interfaz de ServiceNow y entender cómo la experiencia de usuario condiciona productividad y calidad del dato.

Resultados esperados

• Distinguir listas, formularios, menús y workspaces.
• Navegar por módulos y registros con criterio.
• Entender por qué la interfaz influye en operación y calidad de información.

Desarrollo teorico

La interfaz de ServiceNow ha evolucionado significativamente a lo largo de los anos. La UI clasica (UI16) fue durante mucho tiempo la experiencia estandar, con su Application Navigator en el panel izquierdo, banner superior y frames de contenido. Con la llegada de Next Experience (UI Builder, Unified Navigation), ServiceNow introdujo una interfaz mas moderna con navegacion unificada, busqueda global mejorada (All menu), favoritos accesibles y una estetica que se alinea con estandares actuales de aplicaciones web. Ademas de estas capas de navegacion general, la plataforma ofrece workspaces orientados a roles especificos: Agent Workspace para analistas de soporte, ITOM Workspace para operaciones, CSM Workspace para servicio al cliente y otros. Cada workspace optimiza la experiencia para las tareas mas frecuentes de ese perfil, mostrando informacion contextual, listas filtradas y acciones rapidas sin necesidad de navegar por menus generales.

A pesar de esta evolucion estetica, la logica basica sigue siendo similar: el usuario navega por aplicaciones o modulos, abre listas, filtra resultados, accede a formularios y ejecuta acciones relacionadas con registros. Dominar esta mecanica parece basico, pero influye directamente en productividad, consistencia del trabajo y calidad de datos. Un analista que no sabe guardar un filtro repite la misma busqueda veinte veces al dia. Un gestor que no configura su homepage pierde tiempo navegando por menus que podria evitar.

El Application Navigator organiza la plataforma en aplicaciones y modulos. Una aplicacion es un conjunto funcional (Incident, Problem, Change, Service Catalog), y cada aplicacion contiene modulos que son puntos de entrada a listas, formularios o vistas especificas. Por ejemplo, la aplicacion Incident contiene modulos como Create New, Open, All, Resolved y My Groups Work. Cada modulo esta vinculado a una tabla y a un filtro predefinido. Entender esta estructura ayuda a navegar con intencion en vez de buscar a ciegas.

Una lista es la vista tabular de registros de una tabla o de una consulta sobre esa tabla. Desde la lista se puede filtrar, ordenar, agrupar, exportar o guardar vistas utiles. Las listas soportan multiples capacidades que muchos usuarios desconocen: personalizacion de columnas visibles por usuario, agrupacion por campo (por ejemplo, agrupar incidentes por assignment_group), list editing para actualizar campos directamente desde la lista sin abrir el formulario, y context menus con acciones rapidas. Un filtro bien guardado convierte una cola generica en una vista operativa util, por ejemplo "incidentes P1/P2 abiertos para mi grupo" o "solicitudes pendientes mas antiguas de cinco dias". Los filtros se construyen mediante el condition builder, que permite combinar condiciones con AND/OR, usar dot-walking para filtrar por campos de tablas referenciadas y guardar la vista para reutilizarla o compartirla con el equipo.

Un formulario es la vista detallada de un registro concreto. En el formulario aparecen los campos del registro, las related lists (listas de registros relacionados, como las tareas asociadas a un cambio o el historico de actividad de un incidente), el activity log con work notes y additional comments, y las acciones disponibles mediante UI Actions (botones como Resolve, Close, Assign to me). El formulario puede tener multiples vistas (views) configuradas para distintos roles o propositos: una vista para el analista con campos tecnicos y otra para el gestor con campos de seguimiento. La personalizacion de vistas de formulario es una de las capacidades de configuracion mas potentes de la plataforma porque permite adaptar la experiencia sin alterar el modelo de datos subyacente.

Saber cuando trabajar en lista y cuando entrar en formulario ahorra mucho tiempo. Para revisar backlog y reasignar varios incidentes, la lista es ideal porque permite ver multiples registros, comparar estados y actuar en bloque. Para entender el historico completo, revisar work notes anteriores y actualizar correctamente un incidente critico, el formulario es mas apropiado porque ofrece contexto completo del registro.

La diferencia entre work notes y additional comments merece atencion especifica porque confundirlos es uno de los errores mas frecuentes y potencialmente graves en operacion. Las work notes son notas internas visibles solo para usuarios con rol itil o equivalente. Se usan para documentar diagnostico, hipotesis, pasos de troubleshooting y coordinacion entre equipos tecnicos. Los additional comments (customer visible) son visibles para el solicitante a traves del portal o por email. Se usan para comunicar estado, pedir informacion adicional o confirmar resolucion. Si un analista escribe informacion tecnica sensible o interna en additional comments, el solicitante la vera, lo que puede crear problemas de confidencialidad, confusion o percepcion de servicio poco profesional.

La experiencia de usuario importa porque condiciona comportamiento operativo real. Si un formulario oculta campos importantes como categoria o CI afectado, los analistas los dejaran vacios. Si la lista no permite ver prioridad o estado, los equipos no priorizaran correctamente. Si el portal de autoservicio presenta demasiadas opciones sin organizacion clara, los usuarios crearan incidentes genericos en vez de usar el catalogo. La interfaz no es cosmetica: es una herramienta de gobierno del dato y del proceso.

ServiceNow permite personalizar la experiencia a multiples niveles. Los administradores pueden configurar homepages por rol, definir vistas de formulario y lista, crear menus de favoritos, configurar UI Policies que muestren u oculten campos segun condiciones y disenar portales de autoservicio con Service Portal o Employee Center. Cada una de estas capacidades tiene impacto directo en como los usuarios interactuan con la plataforma y, por tanto, en la calidad del dato que generan. Un formulario bien disenado no solo es mas agradable: produce registros mas completos, mas consistentes y mas utiles para reporting y automatizacion.

Contenido ampliado

Puntos clave

• La interfaz no es cosmética; afecta a cómo se trabaja.
• Listas y formularios sirven para tareas distintas.
• Filtros guardados y vistas bien diseñadas mejoran consistencia.
• La experiencia de usuario condiciona la calidad del dato.

Checklist operativa

• Localiza los módulos de uso diario.
• Guarda un filtro útil para tu cola de trabajo.
• Revisa qué información necesitas ver en lista y en formulario.
• Comprueba diferencias entre vista clásica y workspace si aplica.

Errores frecuentes

• Trabajar todo desde formulario aunque sea tarea de lista.
• No guardar filtros repetitivos.
• Confundir comentarios internos y externos.
• Ignorar el impacto de una mala vista sobre la calidad del dato.

Practica sugerida

Crea una rutina de revisión de backlog usando un filtro guardado y define qué campos deberían verse en la lista para tu equipo.

Preguntas de autoevaluacion

• ¿Cuándo conviene usar lista y cuándo formulario?
• ¿Cómo influye una mala interfaz en la calidad del dato?
• ¿Qué aporta un workspace frente a la navegación clásica?

Cierre

Dominar la navegación básica permite operar más rápido y con menos errores desde el primer día.