Resumen ejecutivo
A medida que las organizaciones crecen y sus operaciones de TI maduran, la arquitectura fundamental de su plataforma de gestión de servicios de TI (ITSM) puede marcar la diferencia a la hora de lograr agilidad a largo plazo, una integración eficaz y un alto nivel de servicio.
Algunas soluciones ITSM, como HaloITSM, utilizan un modelo simplificado de tabla única (almacenan todos los registros de servicio en una sola tabla unificada). En cambio, Ivanti Neurons for ITSM emplea una arquitectura más avanzada, orientada a objetos, que segmenta procesos ITIL diferenciados (incidencias, problemas, cambios y solicitudes) en entidades modulares independientes.
Este informe técnico analiza las limitaciones del enfoque de tabla única, especialmente en entornos empresariales complejos, y destaca las ventajas de adoptar una arquitectura ITSM más estructurada y escalable.
| Función/capacidad | Tabla única | Módulo |
|---|---|---|
| Flexibilidad de los flujos de trabajo | Limitada | Alta |
| Alineación con ITIL | Básica | Integral |
| Aislamiento de la personalización | Bajo | Alto |
| Granularidad de los informes | Moderada | Avanzada |
| Complejidad de la integración | Alta | Baja |
| Escalabilidad | Moderada | Alta |
| Rendimiento | Moderado | Alto |
| Seguridad | Compleja | Simplificada |
1. Introducción
El panorama de ITSM evoluciona rápidamente, con una demanda creciente de automatización, integración y prestación de servicios centrada en el usuario. Aunque la simplicidad puede ser una ventaja para equipos pequeños o startups, a menudo se convierte en un inconveniente a medida que las organizaciones crecen. Este documento analiza las ventajas y desventajas arquitectónicas entre el modelo de tabla única de HaloITSM y el diseño modular de Ivanti Neurons.
2. Entender el modelo ITSM de tabla única
En las plataformas que utilizan una sola tabla, todos los registros de servicio —ya sean incidencias, solicitudes de servicio, problemas o cambios— se almacenan en una única tabla de “tickets”.
A continuación se muestra una arquitectura ITSM de tabla única con seis campos:
| N.º de registro | Tipo de registro | Nombre del propietario | Asunto | Confidencial | Prioridad |
|---|---|---|---|---|---|
| 1 | Incidencia | Don | Error de VPN | 2 | |
| 2 | Cambio | Jamie | Parche para SQL Server | Baja | |
| 3 | Caso de RR. HH. | Harold | Mi nómina es incorrecta | Sí | Urgente |
| 4 | Incidencia | Don | Fallo de SAP | 1 | |
| 5 | Solicitud | Patricia | Ordenador nuevo | Baja |
Lo primero que observará es el campo denominado “Tipo de registro”. Este determina qué datos se almacenan en el registro y es el campo principal para restringir el acceso a ese tipo de campo.
Seguridad
En primer lugar, analizaremos el marco de seguridad de esta tabla. La siguiente definición describe los permisos de acceso de Harold.
Harold tiene acceso completo a tabla = “tickets” y tipo de registro = “Caso de RR. HH.”.
Esta regla de seguridad garantiza que Harold pueda acceder a la tabla de tickets y consultar únicamente los casos de RR. HH.
Ahora veamos esta regla para Don, que trabaja en TI…
Don tiene acceso completo a tabla = “tickets”.
Surge un reto porque Don, empleado de TI, tiene acceso sin restricciones a toda la tabla. Esto podría revelar inadvertidamente a Don datos confidenciales de casos de RR. HH.
La regla debería ser:
Don tiene acceso completo a tabla = “tickets” y tipo de registro NO = “Caso de RR. HH.”.
Esta complejidad aumenta al conceder a Don acceso completo a “incidencia”, pero solo acceso de lectura a “cambios”.
Configuración
La configuración en un entorno de tabla unificada también puede ser compleja, porque los campos de una misma tabla pueden tener requisitos diversos según el tipo de registro.
Al observar nuestra tabla, vemos distintos tipos de prioridad para los respectivos tipos de registro. Las incidencias se ajustan al estándar ITIL, utilizando un sistema numérico (1, 2, 3, 4), mientras que los cambios y las solicitudes se clasifican con prioridad baja, media o alta. Sin embargo, las solicitudes de RR. HH. se clasifican como bajas, altas o urgentes.
¿Cómo se implementa y mantiene esta complejidad? Aunque un campo de formato libre reduce la integridad y la estandarización de los datos, es preferible una tabla de consulta con filtros por tipo de registro. Aun así, esto sigue planteando el reto de combinar distintos tipos de datos, lo que complica los informes y el mantenimiento de campos/tablas.
La configuración en una tabla única compartida es más compleja, ya que todos los cambios de configuración deben tener en cuenta todos los tipos de registro. Por ejemplo, el campo “Confidencial” es obligatorio para los casos de RR. HH., pero no para otros tipos de registro. Si “Caso de RR. HH.” tuviera su propia tabla, bastaría con hacer que el campo fuera obligatorio a nivel de tabla. Si hacemos este cambio en una tabla única, ese campo también será obligatorio en incidencias, cambios y solicitudes, que no lo requieren. La solución consiste en imponerlo mediante programación como campo obligatorio dentro de una regla de negocio de campo, lo que exige cierta definición y administración adicional.
Ahora supongamos que tenemos un equipo legal que quiere crear una aplicación personalizada para solicitudes legales. En una arquitectura de tabla única, necesitaríamos que el tipo de registro fuera “Legal”, y algunos campos podrían reutilizarse (por ejemplo, “Asunto”, “Descripción”, “Confidencial”). Sin embargo, legal también necesita campos obligatorios adicionales: “Externo” (sí/no), “Procedimientos legales” (sí/no), etc. Estos campos deben añadirse a la tabla de tickets, a los formularios y al flujo de trabajo. Los campos adicionales requieren una planificación cuidadosa para no afectar a los tipos de registro existentes, las definiciones de seguridad y las reglas de negocio.
Rendimiento y escalabilidad
Aunque una arquitectura de tabla única comienza funcionando de forma eficiente, al manejar menos registros y campos OOTB, su rendimiento puede disminuir a medida que crece el volumen de registros, salvo que mantenga rigurosamente la higiene y la indexación de la base de datos. Además, la inclusión de campos personalizados puede agravar aún más posibles caídas de rendimiento.
En general, las mejores prácticas para tablas de bases de datos son:
- Evitar campos de tabla innecesarios.
- Normalizar los datos siempre que sea posible para reducir campos redundantes.
- Consultar y devolver únicamente los campos que necesite.
- Indexar correctamente los campos de la tabla para optimizar el rendimiento.
¿Cómo garantiza el rendimiento y la escalabilidad un sistema ITSM con un enfoque de tabla única?
Aunque un modelo de datos de tabla única simplifica algunos aspectos de la gestión de servicios de TI, presenta limitaciones que debe conocer.
3. El caso a favor de la arquitectura ITSM modular
Una arquitectura ITSM modular es aquella en la que cada proceso ITSM se modela como un objeto de negocio diferenciado y se relaciona con otros objetos de negocio (procesos); por ejemplo, una incidencia con un problema, o un problema con un cambio. Este enfoque modular sigue de cerca los procesos ITSM y garantiza el aislamiento de los datos, lo que aporta varias ventajas.
Flujos de trabajo específicos por proceso
En un flujo de trabajo con diseño de tablas modular, los SLA, las aprobaciones y las reglas de negocio pueden ser exclusivos de la tabla (proceso). No se requiere ningún filtrado especial para impedir que el flujo de trabajo se ejecute sobre un registro de un tipo diferente (proceso ITSM). Por ejemplo: criterios de ejecución de escalado frente a una incidencia cuando se incumple un SLA.
Con este enfoque, la alineación con las mejores prácticas y la gobernanza de ITIL es más fluida, e impide de forma eficaz la ejecución frente a procesos no ITIL (como casos de RR. HH. u órdenes de trabajo de instalaciones).
Seguridad mejorada
Al separar las tablas por proceso, mejora la seguridad y mitiga el riesgo de acceso inadvertido a datos sensibles. En este caso, el acceso se concede solo a quienes cuentan con autorización explícita, con medidas de seguridad adicionales fácilmente adaptables para dirigirse a datos y registros específicos.
Además, la seguridad de tablas separadas garantiza que los informes y las exportaciones sigan las reglas de seguridad estándar de las tablas, en lugar de una seguridad a nivel de fila más compleja.
Personalización mejorada
Las tablas específicas por proceso ofrecen mayor flexibilidad de configuración, garantizando que los cambios en un proceso no afecten a otros (ni a campos de uso generalizado). Las configuraciones de campo únicas a nivel de tabla eliminan la necesidad de reglas de negocio complejas, lo que amplía el soporte a escenarios más complejos, como aprobaciones del CAB para cambios o análisis de causa raíz para problemas.
Informes y análisis avanzados
Con tablas alineadas con los procesos que contienen datos estructurados, los informes granulares, el análisis de tendencias y el seguimiento de KPI en dominios ITIL son ahora más viables, y se simplifica la incorporación de datos relacionados. Por ejemplo, un informe que muestre todas las incidencias resueltas mediante cambios.
Esto también facilita los informes de cumplimiento y los cuadros de mando ejecutivos en objetos de negocio de procesos o empresariales (por ejemplo, casos de RR. HH., órdenes de trabajo de instalaciones).
Mejor integración y extensibilidad
La integración optimizada con sistemas externos incluye tablas individuales alineadas con los procesos. Este método no solo simplifica la exposición de API, sino que también mejora la seguridad (ya que las API requieren acceso explícito a la API de la tabla).
Esto permite una extensibilidad low-code/no-code para acelerar la innovación y ofrece la flexibilidad de ampliar objetos de negocio existentes o crear otros nuevos.
4. Preguntas que debe plantear
Una estructura de datos de tabla única puede limitar el crecimiento futuro. Al evaluar sistemas ITSM, es fundamental comprender en profundidad la arquitectura de datos subyacente.
Plantee las siguientes preguntas a su proveedor de ITSM:
- ¿Tienen tablas separadas para sus procesos ITSM o están en la misma tabla?
- ¿Qué dificultad supone mantenerlo y protegerlo?
- ¿Qué impacto tendría añadir una nueva función, como Solicitudes legales?
- ¿Qué dificultad supone replicar funcionalidad personalizada en la herramienta?
- ¿Cuánto tiempo llevará crear un objeto personalizado?
- ¿Qué dificultad supone proteger los datos frente a accesos no autorizados?
- ¿Puede mostrarme cómo añadir nuevos campos y nuevos objetos?
- ¿Cuántas personas se necesitan?
- ¿Cuál será el coste?
- ¿Podré actualizar?
5. ¿Qué arquitectura ITSM es la adecuada para usted?
Una solución ITSM de tabla única, como HaloITSM, es un buen punto de partida para organizaciones que desean ponerse en marcha rápidamente con una experiencia de usuario simplificada. Sin embargo, estas soluciones pueden generar retos de crecimiento y escalado para operaciones de TI maduras y de nivel empresarial.
A medida que las organizaciones buscan alinearse con ITIL, automatizar flujos de trabajo complejos e integrarse en todo el ecosistema digital, una arquitectura modular como Ivanti Neurons for ITSM proporciona la flexibilidad, la escalabilidad y el control necesarios para el éxito a largo plazo.