ITSM vs. ESM: Cómo Saber Cuál Necesita Tu Empresa (y Si Puedes Empezar con Uno y Escalar al Otro)
September 2, 2026
En algún momento de los últimos años, "ESM" empezó a aparecer en las mismas conversaciones que "ITSM," y muchos líderes de TI se quedaron sin saber si se trataba de una categoría nueva, un cambio de nombre, o simplemente otra sigla que los proveedores inventaron para vender lo mismo dos veces. No es ninguna de las tres cosas. ITSM y ESM resuelven problemas distintos, para audiencias distintas, y confundirlos tiene un costo real: hay equipos que terminan comprando más plataforma de la que necesitan, y otros que compran una herramienta que no puede crecer más allá del único departamento para el que fue configurada.
Este artículo explica qué hace cada una en la práctica, cómo saber cuál necesita tu empresa hoy, y si empezar con una te deja o no la puerta cerrada para la otra más adelante. Adelanto de la respuesta: no debería cerrarte esa puerta, pero con frecuencia sucede, dependiendo de lo que hayas comprado.
Parte de la confusión viene de cómo se usan estos términos en una conversación comercial. Un proveedor que vende una herramienta pensada solo para TI a veces estira el término "ESM" para decir que técnicamente tiene un generador de formularios que otros departamentos podrían usar, aunque nadie lo haya configurado realmente para ellos. Un proveedor con una plataforma más amplia a veces usa ESM como término paraguas para todo, TI incluido, lo que hace más difícil distinguir qué es genuinamente distinto entre ambas disciplinas y qué es solo empaque comercial. Para aclarar esto hay que entender qué significa cada término por sí solo, sin depender de cómo lo esté presentando un proveedor en particular.
La Gestión de Servicios de TI (ITSM, por sus siglas en inglés) es la disciplina de operar TI como un servicio para el resto de la empresa, no como un departamento que arregla computadoras cuando fallan. Cubre cómo se registran y resuelven los incidentes, cómo se aprueban y despliegan los cambios en los sistemas sin romper algo más en el proceso, cómo se diagnostican los problemas de raíz en lugar de parcharlos una y otra vez, y cómo se mantiene documentada y actualizada la información de activos y configuraciones detrás de todo esto.
La mayoría de las prácticas de ITSM se apoyan en ITIL: un marco para estandarizar la gestión de incidentes, problemas, cambios y configuraciones, esta última normalmente registrada en un CMDB. Si quieres el ejemplo más claro de cómo dos de estas disciplinas se diferencian en la práctica, nuestra guía práctica de gestión de incidentes frente a gestión de problemas lo explica paso a paso. El alcance es deliberadamente limitado: TI atendiendo a los usuarios de TI, con TI como dueño de la herramienta, los flujos de trabajo y las rutas de escalamiento.
ITSM existe en alguna forma desde los años 80, formalizado a través de ITIL en el Reino Unido. Es un enfoque probado, con casi cuatro décadas de refinamiento detrás, y por eso la mayoría de las herramientas en este mercado nacieron como productos de ITSM y hoy intentan extenderse hacia ESM, no al revés. Eso explica también por qué tantas lo hacen de forma desigual: extender una lógica pensada para TI a otras áreas no es tan simple como activar un módulo nuevo.
La Gestión de Servicios Empresariales toma la misma lógica, tickets, SLA, portales de autoservicio, bases de conocimiento, automatización de flujos, y la aplica a cualquier departamento que reciba solicitudes internas: Recursos Humanos, Legal, Facilities, Finanzas, incluso Marketing. Un colaborador que pide una laptop y otro que pide la revisión de un contrato pasan por el mismo tipo de solicitud estructurada, con la misma visibilidad sobre su estado y la misma exigencia de tiempo de respuesta, aunque los equipos que las atiendan sean completamente distintos.
El objetivo no es que cada departamento actúe como TI. Es darle a toda la empresa una sola forma de pedir cosas y saber en qué va cada solicitud, en lugar de un mosaico de correos, bandejas compartidas y hojas de cálculo que nadie fuera del departamento puede ver. Ya hemos escrito sobre cómo se ve esto en la práctica en cómo Halo hace posible el ESM más allá de TI.
Imagina la primera semana de un colaborador nuevo. Necesita que le entreguen una laptop, un gafete, un puesto asignado, que se procese su formulario de prestaciones y accesos a tres sistemas internos. Con ESM, esas cinco solicitudes viven en un solo portal, cada una enrutada automáticamente al área correcta, y todas visibles para Recursos Humanos como un único checklist de onboarding en lugar de cinco hilos de correo distintos que hay que perseguir uno por uno. Sin eso, ese mismo colaborador pasa su primera semana escribiéndole por WhatsApp a cuatro personas distintas para preguntar si alguien ya vio su solicitud, y Recursos Humanos no tiene forma de ver el panorama completo sin preguntar a cada área por separado.
Ambas se apoyan en la misma mecánica de fondo: tickets, SLA, paneles de control, y las dos dependen cada vez más de IA para clasificar y enrutar solicitudes de forma automática. La diferencia está en quién pregunta, quién responde, y hasta dónde llega el alcance de la plataforma dentro del organigrama.
Aquí es donde muchas empresas se equivocan, y no tiene nada que ver con elegir el marco incorrecto. Se trata de tomar una herramienta configurada con los flujos, la terminología y las cadenas de aprobación de TI, y desplegarla en Recursos Humanos o Facilities sin cambiar nada de eso. Las categorías de tickets de TI no significan nada para un coordinador de Facilities. La jerarquía de aprobación de TI no coincide con cómo Legal realmente firma sus procesos. Cuando la herramienta se siente pensada para otra área, la adopción se frena de inmediato y el departamento vuelve al correo.
Piensa en un equipo de Facilities al que le piden registrar cada solicitud de mantenimiento en un portal con categorías de TI: "hardware," "software," "red." Ninguna de esas categorías encaja con un aire acondicionado descompuesto o con una solicitud para reorganizar una sala de juntas. Entonces el coordinador hace lo que cualquiera haría: sigue gestionando las reparaciones a la antigua, con una llamada telefónica y una nota adhesiva, y el portal queda sin uso, salvo cuando alguien de TI revisa el panel de adopción y pregunta por qué los números se ven mal. Ese no es un problema de Facilities. Es una implementación que se saltó el único paso que realmente importa.
La solución no es complicada, pero es un paso que los equipos se saltan porque sienten que los hace ir más lento: sentarse con cada departamento antes de activar nada, entender sus tipos reales de solicitud y quién aprueba qué, y construir su catálogo y sus flujos alrededor de eso, no alrededor de la plantilla de TI. Los departamentos que hacen esto bien ven el ESM como una herramienta construida para ellos. Los que no, lo ven como la herramienta de TI impuesta desde arriba, y la tratan en consecuencia.
El argumento de negocio detrás de esto no es abstracto. Una encuesta de la industria de 2025, realizada por AXELOS e ITSM.tools, encontró que el 68% de las organizaciones ya tiene algún tipo de iniciativa de ESM en marcha, y más de la mitad considera su implementación bastante avanzada. Pero otras investigaciones apuntan a una brecha mucho más amplia entre tener ESM y tenerlo bien hecho: un análisis distinto sugiere que solo alrededor de tres de cada diez organizaciones cuentan con un programa realmente formalizado que extienda la disciplina de ITSM, no solo su herramienta de tickets, más allá de TI. Cerca de la mitad ha estirado una plataforma de ITSM o de tickets ya existente hacia otros departamentos sin reconstruirla realmente para ellos, lo cual coincide con el problema de adopción que mencionamos antes.
Esa brecha cuesta tiempo real. Los colaboradores siguen perdiendo horas a la semana persiguiendo el estatus de solicitudes por correo o WhatsApp que deberían haber tomado minutos en registrarse y darles seguimiento. Los equipos de Facilities y Recursos Humanos siguen operando su parte del negocio con bandejas compartidas y hojas de cálculo que nadie fuera del departamento puede consultar. Y cuando una solicitud se pierde en el camino, en una aprobación de Finanzas, en el papeleo de un onboarding, en un reporte de mantenimiento, no hay rastro que muestre dónde se estancó ni quién debe resolverlo. Nada de esto es un problema de tecnología que no se pueda resolver. Es un problema de alcance: tratar una necesidad de toda la empresa como si fuera solo un problema de TI.
Empieza por lo que realmente está fallando hoy, no por la sigla que suena más avanzada. Hay señales claras que apuntan en una dirección o en la otra.
Necesitas ITSM primero si: tu equipo de TI está saturado de tickets sin visibilidad sobre incidentes recurrentes, los cambios en los sistemas se hacen sin un rastro de aprobación documentado, tu información de activos y configuraciones vive en la memoria de alguien o en una hoja de cálculo desactualizada, o simplemente no tienes SLA definidos para las solicitudes de TI. Si algo de esto describe a tu función de TI, resolverlo antes de tocar cualquier otra cosa es la decisión correcta. Puedes profundizar en cómo se ve una versión sana de esto en nuestro análisis de por qué los atrasos de tickets de mesa de servicio siguen creciendo.
Estás listo para ESM si: tu mesa de servicio de TI ya es estable y predecible, pero dos o tres departamentos más están claramente hundidos en el mismo caos de seguimiento de solicitudes que TI resolvió hace años. Recursos Humanos atendiendo preguntas de onboarding por correo. Facilities gestionando solicitudes de mantenimiento en una bandeja compartida que nadie revisa con consistencia. Legal registrando revisiones de contratos en una hoja de cálculo que siempre va una versión atrás. Si el problema de TI ya está resuelto y el de todos los demás no, esa es tu señal para ampliar el alcance de la plataforma en lugar de comprarle a TI otra herramienta que no necesita.
Algunas empresas realmente necesitan ambas desde el primer día, sobre todo después de cierto tamaño, donde el volumen de solicitudes en varios departamentos ya superó lo que el correo puede manejar, sin importar qué tan maduro sea el proceso de un equipo en particular. En ese caso, la pregunta ya no es cuál construir primero. Es si la plataforma que elijas puede realmente operar ambas sin convertirse en dos sistemas separados que solo comparten pantalla de inicio de sesión.
Plantear esto como una decisión de uno u otro es donde empieza gran parte de la confusión. ESM no es una categoría que compite con ITSM y a la que "te cambias." Es la misma lógica de ITSM aplicada más lejos. Toda empresa que opera bien su ESM sigue operando ITSM por debajo, específicamente para su departamento de TI. La pregunta nunca fue realmente "ITSM o ESM." Es "cuánto de la empresa necesita esto hoy, y cuánto lo va a necesitar en dieciocho meses." Responder eso con honestidad es lo que realmente define el orden, no una regla que diga que TI siempre va primero.
Sí, y esta es la parte que la mayoría de los proveedores pasa por alto porque la respuesta honesta depende por completo de lo que hayas comprado. Hay dos caminos válidos aquí, y no son lo mismo.
El primer camino, el que más suelen recomendar los proveedores de ITSM con raíces en TI, es construir madurez en ITSM primero: dejar sólidas la gestión de incidentes, problemas y cambios, tener un CMDB confiable, y usar eso como base antes de extender los mismos principios a otros departamentos. Esto funciona bien cuando TI de verdad necesita ese trabajo de base y los demás departamentos todavía no sienten suficiente dolor como para justificar el esfuerzo de gestión del cambio que implica una implementación.
El segundo camino, favorecido por plataformas construidas primero pensando en ESM, se salta por completo esa secuencia: hacer un piloto con el departamento que más dolor tenga en este momento, sea TI o no, comprobar que el modelo funciona, y luego expandir departamento por departamento según dónde surja el siguiente incendio. Ningún camino está equivocado. Lo que importa más que cuál elijas es si tu plataforma realmente soporta esa transición sin obligarte a comprar de nuevo.
Aquí es donde muchas empresas se queman. Muchas herramientas de ITSM están construidas específicamente para los flujos, la terminología y la lógica de aprobación de TI, y extenderlas a Legal o Finanzas significa pelear contra la herramienta todo el camino, o pagar por un producto de ESM aparte que no comparte datos ni inicio de sesión con el ITSM que ya tienes. Eso no es escalar. Es operar dos plataformas y llamarlo una sola estrategia. Si ya estás evaluando opciones pensando en el crecimiento, nuestra guía para elegir una plataforma ESM que escale revisa las trampas específicas que hay que detectar antes de firmar cualquier contrato.
Asumiendo que tu plataforma sí puede soportar ambas cosas técnicamente, la implementación en sí sigue exigiendo trabajo real, y saltársela es exactamente cómo ocurre el "error" que describimos antes. Antes de activar ESM para un nuevo departamento:
Nuestra propia experiencia acompañando implementaciones de portales de autoservicio de Halo confirma esto directamente: la adopción se estanca en apenas una cuarta parte de los colaboradores cuando un portal se instala en un departamento sin este trabajo previo, sin importar qué tan buena sea la plataforma detrás.
La inversión en transformación digital en Latinoamérica está creciendo más rápido que la mayoría de los referentes globales: solo el mercado de transformación digital de Sudamérica avanza a una tasa de crecimiento anual compuesta del 17.69% hasta 2030, y el gasto en servicios de TI en mercados como Brasil y México crece a doble dígito cada año, con el sector de servicios de TI de México proyectado a crecer 11.87% anual hasta 2030. Ese crecimiento está empujando a más empresas medianas a un punto donde manejar solicitudes de forma manual y por correo entre departamentos simplemente ya no aguanta, muchas veces antes de que esas empresas tengan la madurez interna o el equipo necesario para construir un programa formal de ESM desde cero como lo haría una gran corporación.
Ese es exactamente el entorno donde la elección de plataforma pesa más que el debate sobre el orden. Una empresa que crece a ese ritmo no tiene dieciocho meses para cambiar de plataforma porque la herramienta de ITSM que eligió no puede extenderse más allá de TI, y normalmente tampoco tiene un equipo dedicado de ESM para manejar un segundo producto encima de lo que TI ya opera. La respuesta práctica para la mayoría de las empresas en este momento de la región no es "comprar la suite de ESM más avanzada disponible." Es "comprar una plataforma que pueda crecer contigo sin un segundo proceso de compra."
Halo opera IT Service y Enterprise Service como dos configuraciones de la misma plataforma, sobre un solo motor y una sola licencia, no como dos productos que compras por separado y tratas de conectar después. Eso tiene un impacto directo en todo lo anterior: si empiezas con IT Service para resolver los problemas de tu mesa de servicio, y seis meses después Legal y Facilities están pidiendo la misma visibilidad, estás activando una solución dentro de una plataforma que ya tienes, no migrando datos a un segundo sistema ni negociando un contrato nuevo.
Halo AI opera sobre ambas soluciones, así que la misma automatización que contiene tickets rutinarios de TI también puede enrutar una solicitud de Facilities o una pregunta de Recursos Humanos sin trabajo de configuración aparte. Y como es compatible con ITIL y su configuración no requiere código, TI puede montar el catálogo de un departamento sin escribir integraciones a la medida para cada uno. Halo aparece en el Cuadrante Mágico de Gartner 2025 para Aplicaciones de IA en Gestión de Servicios de TI y opera en más de 5,000 organizaciones en más de 100 países, así que la plataforma ya está probada en ambos extremos: mesas de servicio de TI puras y despliegues completos a nivel empresarial.
Ese rango importa en el tipo de organizaciones con las que trabajamos en Latinoamérica y el Caribe. Una empresa manufacturera bajo presión por poner en orden el soporte de TI en planta no tiene el mismo punto de partida que una universidad manejando solicitudes de Facilities y Servicios Estudiantiles junto a su mesa de ayuda, o un retailer que necesita mover onboarding de Recursos Humanos y aprovisionamiento de TI al mismo ritmo durante una etapa de crecimiento. Lo que tienen en común es que ninguna necesita elegir un proveedor distinto en el momento en que sus necesidades crecen más allá de TI. Solo activan una solución que ya forma parte de la licencia que tienen.
Antes de la primera llamada comercial, siéntate con tu equipo y responde con honestidad:
Las respuestas honestas a esas cuatro preguntas dicen más sobre qué camino te conviene que cualquier presentación comercial.
¿Necesito madurar por completo mi práctica de ITSM antes de poder empezar con ESM? No. Ayuda, pero no es un requisito. Muchas empresas hacen su primer piloto de ESM en un departamento fuera de TI, sobre todo cuando el dolor de ese departamento es más urgente que el de TI. Lo que importa es elegir una plataforma que soporte cualquiera de los dos órdenes.
¿ESM es solo ITSM con otro nombre por motivos de marketing? No. La mecánica de fondo se parece, tickets, SLA, flujos de trabajo, pero el alcance, el modelo de propiedad y las métricas de éxito son genuinamente distintos. Tratar el ESM como un simple cambio de nombre es justo cómo las empresas terminan imponiendo una herramienta pensada para TI a departamentos para los que nunca fue construida.
¿Las empresas pequeñas o medianas pueden justificar ESM, o es solo para grandes corporaciones? El volumen de solicitudes, no el número de empleados, es el verdadero disparador. Una empresa de 200 personas con cuatro departamentos ahogados en solicitudes por correo necesita ESM más que una de 2,000 personas con una mesa de TI bien operada y ningún otro departamento con dolor visible.
¿Cuál es el mayor riesgo al escalar de ITSM a ESM? Asumir que la herramienta de ITSM que ya tienes se va a extender sin problemas. Algunas lo logran. Muchas no, y las que no lo logran convierten "escalar" en un segundo proyecto de implementación con una segunda línea de presupuesto.
¿TI tiene que seguir siendo dueño del ESM una vez que otros departamentos ya están en la plataforma? TI suele quedarse como responsable de la plataforma, manejando la configuración de fondo y las integraciones, pero la operación del día a día de cada catálogo, formulario y flujo de aprobación debería estar en manos de ese departamento. Si TI termina siendo dueño de cada flujo de trabajo en toda la empresa, la adopción suele sufrir por la misma razón que una implementación mal planteada: sigue sintiéndose como la herramienta de TI.
¿Cuánto tiempo toma normalmente extender ITSM hacia una implementación completa de ESM? No hay un plazo fijo, y desconfía de cualquier proveedor que te dé uno sin antes preguntarte por tus departamentos. Un solo departamento bien definido, como Facilities o un equipo pequeño de Recursos Humanos, suele estar operativo en cuestión de semanas una vez mapeados su catálogo y sus flujos. Desplegarlo en cuatro o cinco departamentos a nivel empresa es un esfuerzo más largo y por fases, más cercano a un par de trimestres que a un par de semanas, precisamente porque cada uno necesita su propio trabajo de descubrimiento bien hecho.
Ya sea que tu mesa de TI necesite poner primero su propia casa en orden, o que ya tengas a dos departamentos más ahogados en correos mientras TI funciona sin problemas, el siguiente paso correcto es el mismo: consigue una lectura externa de dónde está el dolor real antes de comprometerte con una plataforma. Habla con nuestro equipo y te ayudamos a mapearlo.
