Hub IT / ITSM

Objetivo y mapa del hub

El Hub IT es el centro operativo de IT según el marco ITIL. Desde aquí llegas a la consola operativa del service desk y del NOC, a la gestión de incidents, solicitudes, problems y changes, a la Knowledge Base, a los cuadros de mando y a los informes. Es la herramienta diaria de los operadores (L1/L2/L3), de los jefes de equipo y de los managers de IT, y el punto de acceso a las vistas de dirección del servicio.

Esta página se organiza en fichas: primero las páginas del hub (la página de inicio, la consola operativa, Change, Problem, Major Incident, Knowledge Base, Voicemail) y después las ventanas modales transversales que se usan con los tickets (Editor, Composer, Inspector, Taxonomías, Notas internas, Adjuntos, Vínculos, Acciones masivas, Playbook, KB, Dashboard, Control de calidad, Datos históricos). Las páginas ITOM, Events&AIOps, Operations Cockpit, IT Report Center y Customer Service se mencionan aquí, pero se describen en sus propias páginas.

Página de inicio del Hub IT

Para qué sirve. Es la página de entrada del hub: presenta las acciones rápidas del hub y los recuadros (tiles) hacia las páginas operativas, de dirección y de informes.

Cuándo usarla. Al empezar la sesión de IT, para elegir el área en la que trabajar o para lanzar las acciones transversales (KB, CMDB, Control de calidad, Taxonomías).

Cómo abrirla. Desde la Home de Core (recuadro IT Hub) o desde la barra de herramientas «IT Hub» presente en las páginas del hub.

Qué muestra. En la cabecera, una hero strip con el título «IT Hub — Centro operativo IT · Network Operations · Service Desk · Operations & ITSM» y las acciones rápidas del hub:

Knowledge Base: abre la KB del dominio de IT.
CMDB / Assets: abre la CMDB centralizada.
Datos históricos: abre la ventana modal de los datos archivados (cold store); requiere un cliente seleccionado (consulta Datos históricos).
Control de calidad: visible para los roles habilitados; abre la revisión de calidad de los tickets cerrados (consulta Control de calidad).
Taxonomías: visible para los administradores; abre la ventana modal Taxonomías de tickets (Taxonomías de tickets).

Debajo, los recuadros se agrupan en tres secciones:

Operativa (CORE): tres recuadros principales:

NOC · Network Operations: cola operativa con filtro de nivel L1/L2/L3: monitorización, triaje, investigación, escalada.
Service Desk · Asistencia y solicitudes: cola del service desk con filtro de nivel L1/L2/L3: triaje, restablecimientos, incident/problem, catálogo. (El dominio interno sigue siendo OPS.)
Customer Service · grupos por cliente: tickets CS-* sobre los grupos dedicados del cliente (Customer Service, Enterprise Service e ICC).

Dirección de servicios: tres cockpits (visibles para los roles de manager/director, *:MGR):

NOC Service Director: P1/War Room en directo, SLA por cliente, cobertura del turno, escalada, broadcast al equipo.
Service Desk Director: FCR, AHT, volúmenes por canal, CSAT, tiempos de cola, rendimiento de los analistas.
Customer Service Director: dirección de la línea de clientes sobre los grupos por cliente.

Herramientas operativas e informes: recuadros compactos: ITOM, Events & AIOps, Problem Management, Change Management, IT Operations Dashboard, IT Report Center, Voicemail.

Cada recuadro muestra un icono, una insignia de estado (LIVE/NEW/…) y una línea de features (las etiquetas de las funciones principales). En la parte inferior de la página está el dock inferior unificado con softphone, chat y presencia.

Cómo se usa. Haz clic en el recuadro del área que quieras; las acciones rápidas de la cabecera abren sus ventanas modales o páginas. Los recuadros y las acciones visibles dependen del rol (RBAC): la página de inicio filtra los recuadros según los perfiles de acceso del usuario y el nivel requerido.

Qué pasa después. La navegación te lleva a la página o consola elegida; el estado de la sesión (cliente/tenant actual) se propaga a las páginas de destino.

Notas. Los KPI del hub se han retirado deliberadamente de la página de inicio: con la vista entre tenants no serían significativos; las métricas están en las páginas específicas (consola NOC, cuadro de mando de SLA, cockpits).

Consola operativa L1/L2/L3 (NOC y Service Desk)

Para qué sirve. Es la consola de gestión de los tickets en cola, compartida por el NOC y el Service Desk mediante el mismo motor de diseño. Permite supervisar la cola, seleccionar un ticket, ver su detalle y actuar con acciones rápidas y herramientas de contexto. Una sola pantalla cubre los tres niveles (L1/L2/L3) mediante un filtro de nivel.

Cuándo usarla. Es el puesto de trabajo del operador durante toda la jornada: asunción, diagnóstico, escalada, resolución.

Cómo abrirla. Desde la página de inicio del IT Hub, recuadros NOC o Service Desk. La consola Problem (Problem Management Console) usa el mismo diseño.

Qué muestra. Un diseño de tres paneles:

Cola (izquierda): la lista de tickets, con:
- filtros rápidos: Todos, P1/P2, Míos, Unassigned, + L2/L3;
- búsqueda por clave, asunto o CI;
- actualización automática cada 60 segundos (con la hora de la última actualización y un contador).
Detalle (centro): el ticket seleccionado con todos sus datos; desde aquí se abren el Editor (Editor de ticket) y las acciones.
Herramientas (derecha): pestañas de contexto que cambian según el nivel.

Arriba, una franja de KPI. Para el NOC L1: Tickets abiertos, P1/P2 activos, Incumplimientos de SLA, MTTR (min), Resueltos hoy.

Las acciones rápidas (L1): Asumir (asignármelo), Escalate L2/L3 (equipo GRP-NOC_L2), Resolver, Abrir Major Incident (escalada MIM). Las herramientas del L1: CI vinculados (explorador de la CMDB), Runbook (KB NOC L1, Playbook de incident), Monitorización (Grafana, Alertmanager), Temporizador SLA (tiempo restante), Dashboard (abre el cuadro de mando de KPI en una ventana modal).

Al pasar al nivel L2 cambian los KPI, las acciones y las herramientas: KPI Incidents abiertos, P1/P2 abiertos, Change window, MTTR, Root-cause pending; acciones Take ownership, Escalate L3, Iniciar RCA (5-why + cronología), Abrir Change (RFC → CAB), Escalate MIM; herramientas RCA workspace (creador de cronologías, plantilla 5-why), Change mgmt (calendario del CAB, nueva RFC), Runbook L2/L3.

Abajo, los enlaces a Service Topology e ITOM Health, y el dock inferior con softphone (SIP), chat y presencia.

Cómo se usa. Filtras y buscas en la cola, seleccionas un ticket (detalle en el centro), actúas con las acciones rápidas o abres el Editor para la gestión completa; las herramientas de la derecha dan acceso a la CMDB, los runbooks, la monitorización y los SLA. Las selecciones múltiples habilitan las acciones masivas (Acciones masivas).

Qué pasa después. «Asumir» asigna el ticket al operador; «Escalate» lo pasa al equipo superior; «Resolver» lo cierra; «Abrir Major Incident» inicia el workbench MIM (Major Incident Workbench). Cada acción actualiza la cola, los KPI, la cronología y las notificaciones.

Notas. El filtro de nivel y las matrices de escalada, los nombres de los equipos (GRP-NOC_*, GRP-OPS-*) y las colas se gobiernan de forma centralizada; la actualización automática mantiene la cola al día sin recargar la página.

Editor de ticket

Es la ventana más usada de todo exoCortex Core: la describimos en dos secciones.

Para qué sirve, cuándo y cómo se abre

Para qué sirve. El Editor de ticket es el panel lateral (drawer) de trabajo de un único ticket: permite leer todos sus datos, cambiar su estado (transiciones de workflow), modificar sus campos, comentar, gestionar adjuntos y notas internas, y consultar los SLA, la cronología, los tickets vinculados y la traza de auditoría.

Cuándo usarla. Cada vez que asumes o actualizas un ticket: asunción, actualización del avance, petición de información, resolución, cierre.

Cómo abrirla. Haciendo clic en un ticket en cualquier lista (consola operativa, colas, resultados de búsqueda, widgets) o con el atajo ⌘O (Ctrl+O), que abre un selector en el que escribes la clave del ticket.

Característica distintiva: varios tickets. El Editor gestiona hasta 6 tickets abiertos a la vez, cada uno en su propia pestaña (tab) en la parte superior. Pasas de un ticket a otro con un clic o con ⌘Tab. Una pestaña con cambios sin guardar muestra el indicador de cambios pendientes (dirty). Cada ticket se cierra con la «x» de su pestaña.

Modos de visualización. El panel admite tres modos: anclado a un lado (side-by-side), a pantalla ancha (focus) y minimizado (PIP) en la parte inferior. Esc minimiza el panel (collapse) sin perder su contenido.

Qué muestra: barra de estado y pestañas internas

Bajo las pestañas de los tickets hay una barra de estado con los atributos clave y los controles rápidos: estado actual y botones de transición (confirmación con ⌘↵); prioridad (Highest/High/Medium/Low/Lowest); asignatario (control «Asignar», que abre el selector de usuario); indicadores de cola/equipo, tipo y clave.

El cuerpo se organiza en pestañas internas:

Detalle: los campos del ticket: asunto, descripción (texto plano), prioridad y los campos personalizados (custom fields) del issue type, cargados desde el catálogo y editables junto con los demás. Se guarda con ⌘S.
Timeline: la cronología de los eventos (creación, transiciones, comentarios, cambios).
Comentarios: el historial de comentarios (autor, fecha), mostrado en Markdown, con el área de escritura y el botón Enviar comentario (activo solo cuando hay un borrador).
SLA: los SLA asociados con cuenta atrás «en directo».
Linked: los objetos vinculados (tickets, llamadas, chats, enlaces) con fecha y origen; se añaden con el Link Picker (Vincular tickets).
Adjuntos: la lista de archivos con Ver, Descargar, Eliminar y la carga; los adjuntos son inmutables (para «modificarlos» se eliminan y se vuelven a cargar).
Notas internas: anotaciones reservadas al equipo (Notas internas).
Audit: la cronología del ciclo de vida.
Postmortem: la ficha de revisión posterior al incidente, para los tipos que la prevén (Major Incident, SOC Incident).

Cuando el ticket afecta a un CI/host está disponible Consola PAM (acceso privilegiado zero-knowledge al sistema).

Cómo se usa y qué pasa después

Cambiar el estado: eliges la transición; el workflow avanza, la cronología registra el evento y se disparan las notificaciones y las automatizaciones (asignaciones, SLA, escaladas).
Modificar los campos: editas en la pestaña Detalle y guardas con ⌘S; los cambios se envían en bloque. La descripción y los comentarios están en texto plano (fuente única): lo que escribes es lo que se guarda y se vuelve a leer.
Comentar: escribes en la pestaña Comentarios y envías; el comentario entra en el historial y se notifica según la matriz de notificación.
Gestionar adjuntos / asignar: desde sus pestañas o controles.

Atajos: ⌘O abrir selector · ⌘S guardar · ⌘↵ transición · Esc minimizar · ⌘Tab ticket siguiente.

Notas. Las acciones disponibles (transiciones, modificación de campos, eliminación de adjuntos, visibilidad de las notas internas) dependen de los permisos del rol. La pestaña Postmortem solo aparece para los tipos que la prevén.

Composer, creación de tickets

Para qué sirve. Es la ventana de creación de un nuevo ticket por parte del operador (en nombre de un usuario o cliente, o a raíz de una llamada o un chat).

Cuándo usarla. Al abrir un nuevo caso: llamada al service desk, solicitud por chat, aviso que hay que supervisar, creación manual de un incident, una request o un change.

Cómo abrirla. Desde el botón de creación en las listas o cockpits, o con Ctrl+N. El contexto se puede heredar de un chat o una llamada activos: informante, asunto, descripción, CI, adjuntos, incident relacionado, tipo.

Qué muestra. Una ventana modal centrada (con modo focus a pantalla ancha y PIP abajo a la izquierda), en tres pasos que se van mostrando progresivamente:

Identify: proyecto/tenant de destino, canal, solicitante (reporter).
Classify: tipo de ticket (issue type) y dominio (menú filtrado por la sección del dominio), prioridad y categoría.
Detail: asunto, descripción, campos específicos, adjuntos y, si procede, una nota interna inicial.

Cada paso tiene un indicador de estado (pendiente/en curso/completado). Al lado está el panel AI Copilot: sugerencia del título, propuesta de prioridad, categorización, detección de duplicados, artículos de la KB y runbooks pertinentes.

Cómo se usa. Rellenas los tres pasos (el tipo determina los campos obligatorios: Solicitudes de servicio). Varios borradores: hasta 5 borradores abiertos, guardados en el servidor y en local, con guardado automático cada 3 segundos. Envío con Ctrl+Enter o desde el botón: se crea el ticket; la nota interna inicial, si la hay, se añade justo después. Atajos: Ctrl+N nuevo borrador · Ctrl+S guardar · Ctrl+Enter enviar · Esc minimizar.

Qué pasa después. El ticket entra en el workflow de su tipo, se enruta a la cola o equipo competente según las reglas de enrutamiento del dominio y se generan las notificaciones. Puedes abrir el ticket enseguida en el Editor (Editor de ticket).

Notas. El tenant de destino debe ser concreto: los valores comodín (*, __ALL__) se rechazan. Si no se indica dominio, no se fuerza ningún tipo predeterminado.

Vista previa del ticket

Para qué sirve. Muestra un ticket en solo lectura con vista previa, impresión y exportación, sin abrirlo para editarlo.

Cuándo usarla. Para una consulta rápida, para imprimir o para copiar el enlace a un ticket y compartirlo.

Cómo abrirla. Desde las listas y los widgets con la acción de vista previa.

Qué muestra. Los datos del ticket y los comentarios: asunto, solicitante, estado, prioridad, descripción e historial de comentarios.

Cómo se usa. Botones de imprimir/exportar y Copiar enlace.

Qué pasa después. Los datos no cambian (solo lectura). Para actuar pasas al Editor.

Notas. Los comentarios son opcionales (si no hay, la vista sigue siendo válida).

Taxonomías de tickets

Para qué sirve. Define las categorías y subcategorías de servicio que usa el Composer para clasificar los tickets. Es la herramienta de configuración de la taxonomía global.

Cuándo usarla. Cuando el administrador tiene que crear o modificar las categorías de clasificación de los tickets.

Cómo abrirla. Desde la acción Taxonomías de la cabecera de la página de inicio de IT (visible para los administradores).

Qué muestra. El árbol global de Category/Subcategory con las entradas existentes y los controles de creación, modificación y eliminación.

Cómo se usa. Añades o modificas categorías y subcategorías; estas rellenan el selector «Tipo/Categoría» del Composer (Composer, creación de tickets) y se usan para el enrutamiento y los informes.

Qué pasa después. Los cambios pasan a estar disponibles en el Composer y en las herramientas de clasificación; las taxonomías son una fuente única.

Notas. Es una función administrativa.

Notas internas

Para qué sirve. Gestiona las anotaciones reservadas al equipo sobre un ticket, que el solicitante no ve.

Cuándo usarla. Para anotar información de trabajo, hipótesis, contactos o detalles sensibles que no deben aparecer en la comunicación con el usuario.

Cómo abrirla. Desde la pestaña Notas internas del Editor (Editor de ticket).

Qué muestra. La lista de notas internas del ticket con autor y fecha, y el área para introducir una nota nueva.

Cómo se usa. Añades una nota; solo la ven los operadores o equipos con permiso.

Qué pasa después. La nota queda registrada en el ticket (en un canal separado de los comentarios públicos) y contribuye a la trazabilidad interna.

Notas. La visibilidad de las notas internas está sujeta a los permisos del rol.

Visor de adjuntos

Para qué sirve. Permite ver, imprimir y descargar los adjuntos de un ticket sin tener que descargarlos para abrirlos.

Cuándo usarla. Para examinar un archivo adjunto (imagen, PDF, log) mientras trabajas en el ticket.

Cómo abrirla. Desde la acción Ver de la pestaña Adjuntos del Editor, o desde los puntos en los que se muestra un adjunto.

Qué muestra. La vista previa del archivo con los comandos de impresión y descarga.

Cómo se usa. Abres el adjunto, lo consultas y, si quieres, lo imprimes o descargas.

Qué pasa después. El archivo no se modifica (los adjuntos son inmutables).

Notas. Para «modificar» un adjunto, lo eliminas y cargas una nueva versión.

Vincular tickets

Para qué sirve. Crea un vínculo entre tickets (relación con tipo: p. ej. «duplica», «bloquea», «relacionado»).

Cuándo usarla. Para relacionar un ticket con otros (incidents del mismo problem, solicitudes duplicadas, dependencias).

Cómo abrirla. Desde la pestaña Linked del Editor.

Qué muestra. El tipo de vínculo, un campo de búsqueda del ticket de destino (que excluye el ticket de origen para evitar vínculos consigo mismo) y un comentario opcional.

Cómo se usa. Eliges el tipo, buscas y seleccionas el ticket de destino, y confirmas.

Qué pasa después. Se crea el vínculo y la pestaña Linked del ticket se recarga mostrando la nueva relación.

Notas. El catálogo de tipos de vínculo es una fuente única; no se permite vincular un ticket consigo mismo.

Acciones masivas

Para qué sirve. Ejecuta acciones sobre varios tickets seleccionados a la vez: cierre masivo y escalada masiva.

Cuándo usarla. Para despachar en bloque varios tickets homogéneos (p. ej. cerrar una serie de alertas ya resueltas o escalar un grupo de tickets al mismo equipo).

Cómo abrirla. Seleccionando varios tickets en la cola o la lista y eligiendo la acción masiva.

Qué muestra. La lista de tickets seleccionados, la elección de la acción (cerrar/escalar) y los parámetros necesarios (resolución para el cierre, equipo de destino para la escalada; los proporciona el contexto, no están fijados en el código).

Cómo se usa. Confirmas la acción: cerrar cierra los tickets seleccionados y escalar los pasa al nivel siguiente. Se requiere una selección válida.

Qué pasa después. Los tickets se actualizan en bloque; la cola y los KPI se recargan; cada cambio queda registrado en la auditoría.

Notas. Las resoluciones y los equipos disponibles dependen de la configuración del tenant.

Lanzador de playbooks

Para qué sirve. Enumera y ejecuta los playbooks/runbooks aplicables al contexto de la página o del ticket.

Cuándo usarla. Para aplicar un procedimiento estandarizado (diagnóstico, remediación, comunicación) a un incident o a un CI.

Cómo abrirla. Desde la acción rápida Playbook de las páginas de gestión o desde el icono registrado en el dock inferior.

Qué muestra. Los playbooks aplicables filtrados por dominio y etiqueta y habilitados para el tenant, con la posibilidad de aportar datos de contexto (p. ej. el CI afectado).

Cómo se usa. Eliges un playbook y lo ejecutas en Dry-run (simulación) o con Ejecutar (ejecución real), reutilizando la API de playbooks.

Qué pasa después. La ejecución produce sus efectos (acciones automáticas, actualizaciones del ticket o del CI) y registra el resultado.

Notas. El tenant es el de la sesión y no se indica a mano; las acciones sensibles están protegidas por barreras.

Knowledge Base

Para qué sirve. Busca y consulta los artículos de la Knowledge Base directamente mientras trabajas, para la resolución rápida y el KB-deflection.

Cuándo usarla. Durante el triaje o el diagnóstico, para encontrar un procedimiento o un artículo útil sin salir de la página.

Cómo abrirla. Desde la acción rápida KB de las herramientas de la consola operativa o desde los puntos que integran la búsqueda en la KB.

Qué muestra. Un campo de búsqueda y la lista de resultados; al seleccionar un artículo, la vista del artículo con título, metadatos y cuerpo.

Cómo se usa. Escribes una consulta y buscas; abres el artículo y lo consultas; vuelves a la lista con «atrás».

Qué pasa después. El artículo puede resolver el caso (deflection) o proporcionar los pasos que hay que seguir; la KB también alimenta las sugerencias del AI Copilot del Composer.

Notas. El endpoint de búsqueda es el canónico; la KB completa se gestiona en su página específica (Knowledge Base).

Dashboard de KPI

Para qué sirve. Abre en una capa superpuesta un cuadro de mando editorial de KPI, sin abrir una página aparte.

Cuándo usarla. Para consultar al momento los KPI de un área (p. ej. NOC L1 Monitoring) mientras trabajas en la consola.

Cómo abrirla. Desde la acción rápida Abrir Dashboard KPI de las herramientas de la consola.

Qué muestra. El informe editorial generado a partir de los datos reales: KPI, tendencias, desgloses.

Cómo se usa. Lo abres y consultas los gráficos y los valores; sustituye a los antiguos cuadros de mando separados.

Qué pasa después. Los datos no cambian (solo lectura); al cerrarlo vuelves a la consola.

Notas. Si el entorno de ejecución del informe no está disponible, la ventana modal falla de forma explícita (fail-loud), sin datos ficticios.

Change Management

Para qué sirve. Gobierna el ciclo de vida de los changes de infraestructura según ITIL: Standard (preaprobado, sin CAB), Normal (aprobación del CAB) y Emergency (aprobación del eCAB), con las ventanas de Change Freeze.

Cuándo usarla. Para registrar, evaluar, aprobar y planificar los cambios, y para gestionar las reuniones del CAB y las ventanas de bloqueo.

Cómo abrirla. Desde la página de inicio del IT Hub, recuadro Change Management, o desde la consola operativa (acción «Abrir Change» en el nivel L2).

Qué muestra. Una fila de KPI y cuatro pestañas:

Lista: los changes con estado, tipo, riesgo, ventana y resultado.
CAB: la agenda del Change Advisory Board: RFC en discusión, participantes, votos (tipo IT-CAB-MEETING).
Calendar Window: el calendario de las ventanas de cambio (cuadrícula mensual), con la «Window propuesta».
Audit Trail: la traza de las acciones sobre los changes.

Cómo se usa. Creas o evalúas un change (RFC), lo llevas al CAB para su aprobación y planificas la ventana de ejecución; desde cada change abres el Editor para el avance y el registro de las aprobaciones (Aprobación de changes (CAB)).

Qué pasa después. Un Normal Change requiere la aprobación del CAB antes de ejecutarse; un Emergency sigue la tramitación del eCAB (aprobación retroactiva). Durante un freeze, los changes no se pueden aprobar sin autorización explícita del Change Manager.

Notas. Las reuniones del CAB se pueden generar periódicamente; el acta y el resultado de la votación se registran en el IT-CAB-MEETING correspondiente.

Aprobación de changes (CAB)

Para qué sirve. Registra la decisión de aprobación sobre un change (normalmente un Normal Change en el CAB).

Cuándo usarla. En el CAB/eCAB, cuando el change está pendiente de aprobación y el usuario figura entre los aprobadores.

Cómo abrirla. Desde la pestaña CAB o desde el Editor del change (pestaña Aprobaciones). Es la misma ventana modal descrita en Aprobación, aplicada aquí a los changes.

Qué muestra y cómo se usa. La cadena de aprobación con los pasos y su estado, y las decisiones Aprobar / Rechazar / Pedir información / Delegar, con comentario. Si se requiere, la firma.

Qué pasa después. La aprobación del último paso habilita la ejecución del change en la ventana planificada; un rechazo lo devuelve; todas las decisiones se notifican y quedan registradas.

Notas. Las reglas del CAB/eCAB y los freezes condicionan el resultado (consulta Cockpits y vistas de dirección/Procesos de IT).

Problem Management Console

Para qué sirve. Gestiona los problems y el análisis de las causas raíz (RCA), hasta los Known Errors con workaround documentado.

Cuándo usarla. Cuando varios incidents comparten una causa común, o para realizar un análisis estructurado de la causa raíz.

Cómo abrirla. Desde la página de inicio del IT Hub, recuadro Problem Management.

Qué muestra. El diseño de cola de la consola operativa (KPI, lista con actualización automática cada 60 s), especializado en los problems, con el enlace al calendario del CAB y a los incidents relacionados. Muestra la RCA (5-why + motor) y la Known Error DB (KEDB).

Cómo se usa. Abres un problem, realizas el análisis RCA (plantilla 5-why, cronología) y documentas la causa raíz y el workaround; desde un problem promueves un Known Error y creas el artículo de la KB correspondiente.

Qué pasa después. Un Known Error publicado pone el workaround a disposición del primer nivel (KB-deflection) y reduce el tiempo de resolución de los incidents recurrentes. La plantilla KEDB recoge: Síntoma, Causa raíz, Workaround temporal, Solución permanente / change asociado, CI afectados, Incidents relacionados.

Notas. La RCA también se puede iniciar desde el nivel L2 de la consola operativa (acción «Iniciar RCA»).

Major Incident Workbench

Para qué sirve. Es el panel de gestión de las crisis (Major Incidents): coordina la war room, las actualizaciones, las acciones y el cierre.

Cuándo usarla. Cuando se declara un Major Incident (manualmente o por una regla automática cuando un Incident P1 supera los 30 minutos).

Cómo abrirla. Desde la acción Abrir/Escalate Major Incident de la consola operativa o desde los enlaces directos.

Qué muestra. El título Major Incident Workbench, el botón Resolve Major Incident, el panel Impact y cuatro pestañas:

Timeline: la cronología de los eventos del incidente.
Actions: los Action items, las acciones asignadas durante la crisis.
Comms: las comunicaciones (actualizaciones a las partes interesadas o al cliente).
Postmortem: la revisión posterior al incidente.

Está disponible el Incident Bridge (botón Config MI / editar bridge): enlace a la llamada de crisis, Incident Commander, participantes, cronología de las actualizaciones en tiempo real. La sección Linked tickets muestra los tickets vinculados al incidente.

Cómo se usa. Abres o actualizas el bridge, registras los action items y las comunicaciones, y actualizas la cronología; al cerrar, pulsas Resolve Major Incident.

Qué pasa después. Tras la resolución es obligatorio un PIR (Post-Incident Review), que se rellena en la pestaña Postmortem. Las actualizaciones se comunican a las partes interesadas según las comunicaciones configuradas.

Notas. Los umbrales y la clasificación de los Major Incidents (P0–P3) se configuran en la ventana modal Config MI (Configuración de Major Incidents (Config MI)) y en la página Admin MI Config (Admin MI Config).

Configuración de Major Incidents (Config MI)

Para qué sirve. Configura los parámetros de los Major Incidents: umbrales de activación y clasificación de la severidad.

Cuándo usarla. Durante la puesta en marcha o la revisión de las políticas MIM.

Cómo abrirla. Desde el botón Config MI del Major Incident Workbench o desde la página Admin MI Config (Admin MI Config).

Qué muestra y cómo se usa. Los parámetros de umbral (p. ej. el tiempo tras el cual un Incident P1 pasa a ser Major) y la clasificación P0–P3 (Clasificación de Major Incidents). Los defines y los guardas.

Qué pasa después. Las reglas automáticas de creación de Major Incidents usan estos parámetros.

Notas. Es una función administrativa.

Knowledge Base

Para qué sirve. Es la gestión completa de la Knowledge Base: búsqueda, artículos, redacción, análisis de uso y administración. Alimenta el autoservicio y el KB-deflection.

Cuándo usarla. Para buscar, crear, actualizar y analizar los artículos de la KB (tipo IT-KB).

Cómo abrirla. Desde la acción Knowledge Base de la página de inicio de IT o desde el recuadro KB.

Qué muestra. Cinco pestañas:

Search: búsqueda de artículos con campo de consulta, resultados, prueba de una consulta (para comprobar qué encontraría el usuario) y sugerencias.
Articles: la lista de artículos con filtro por categoría y la lista de categorías; botón Nuevo artículo.
Editor: la redacción del artículo: 1 frase de resumen, categoría, etiquetas, cuerpo, adjuntos y estado de publicación.
Analytics: las métricas de uso (número de artículos, artículos por categoría).
Admin: la administración de la KB (categorías, aplicabilidad por país, p. ej. «IT, FR, DE»).

Cómo se usa. Buscas y consultas; con permiso de redacción creas o actualizas un artículo (resumen, categoría, etiquetas, cuerpo, adjuntos) y lo publicas; la pestaña Search permite probar la eficacia de la búsqueda; Analytics mide la adopción.

Qué pasa después. Los artículos publicados están disponibles en la ventana modal de la KB (Knowledge Base), en el triaje (deflection) y en el autoservicio; la aplicabilidad por país rige su visibilidad.

Notas. Existe una vista pública (KB de dominio, artículo y pública) para la consulta externa.

KB de dominio, artículo y pública

KB de dominio: la vista de los artículos filtrada por dominio (IT/NOC/OPS/ITSM), a la que se llega desde la acción KB del hub.
Artículo de la KB: la página de detalle/redacción de un artículo con categoría, etiquetas, autor y cuerpo.
KB pública: la vista de consulta pública de los artículos destinados al exterior.

Voicemail

Para qué sirve. Reúne los mensajes de voz enrutados al service desk (usuarios / avisos de IT) y permite escucharlos, leer su transcripción y convertirlos en tickets.

Cuándo usarla. Para gestionar los mensajes de voz recibidos fuera de horario o cuando el softphone no ha respondido.

Cómo abrirla. Desde la página de inicio del IT Hub, recuadro Voicemail (con contador de mensajes no leídos).

Qué muestra. La bandeja de entrada de los mensajes de voz con reproductor de audio, transcripción con IA (Whisper), puntuación de riesgo (Claude) y la devolución de llamada integrada en el softphone.

Cómo se usa. Escuchas o lees el mensaje, evalúas el riesgo, devuelves la llamada al remitente con un clic (callback del softphone) o abres un ticket a partir del contenido.

Qué pasa después. La devolución de llamada inicia una llamada; la apertura de un ticket te lleva al Composer con el contexto del mensaje de voz.

Notas. La página se comparte con las áreas relacionadas (mismo endpoint canónico).

Control de calidad

Para qué sirve. Realiza la revisión de calidad de los tickets cerrados: documentación, propiedad, cumplimiento de SLA, proceso, resultado y seguridad.

Cuándo usarla. Para las verificaciones de calidad por muestreo o sistemáticas de los tickets de IT cerrados.

Cómo abrirla. Desde la acción Control de calidad de la página de inicio de IT (visible para los roles habilitados para el control de calidad).

Qué muestra y cómo se usa. La lista de tickets cerrados pendientes de revisión y la cuadrícula de criterios de calidad; evalúas cada criterio y registras el resultado de la revisión.

Qué pasa después. Los resultados alimentan los indicadores de calidad del servicio y pueden reabrir o señalar los tickets no conformes (QC-Gate).

Notas. Es una función reservada a los roles de calidad o de gestión.

Datos históricos

Para qué sirve. Consulta los datos históricos archivados que ya no están en la base de datos operativa.

Cuándo usarla. Para recuperar tickets o datos archivados fuera de la ventana operativa.

Cómo abrirla. Desde la acción Datos históricos de la página de inicio de IT.

Qué muestra y cómo se usa. La interfaz de búsqueda en el archivo histórico; requiere un cliente seleccionado (si el contexto es «Todos los tenants» / *, la ventana modal te pide que selecciones uno).

Qué pasa después. Los resultados se muestran en solo lectura desde el archivo frío.

Notas. Afecta a los datos trasladados al archivo histórico según la política de archivado.

Páginas vinculadas al hub (descritas en otras páginas)

Desde la página de inicio de IT también llegas a páginas tratadas en sus propias páginas: ITOM y Events & AIOps (NOC, Observability e ITOM), IT Operations Dashboard / Operations Cockpit y las vistas Service Director (Cockpits y vistas de dirección), IT Report Center (Cockpits y vistas de dirección/Informes), Customer Service (Customer Service, Enterprise Service e ICC), CMDB / Assets (Asset Management y CMDB).