Qué es un RMM y en qué se diferencia de un ITSM

Un RMM (Remote Monitoring and Management) es el software con el que un MSP administra a distancia los equipos de sus clientes: los monitorea, los parchea, los inventaría y los controla en remoto. Un ITSM (IT Service Management) es el software con el que ese mismo MSP administra los pedidos y los incidentes de las personas que usan esos equipos: tickets, prioridades, tiempos de respuesta. Se contratan juntos, se confunden seguido y resuelven problemas distintos. Esta guía define cada uno, marca la frontera y explica qué es un PSA, que es donde más se enreda la terminología.

Qué hace un RMM

Un RMM instala un agente en cada equipo administrado y desde una consola central permite cinco cosas: monitorear (CPU, memoria, disco, servicios, disponibilidad), inventariar hardware y software, aplicar parches del sistema operativo y de las aplicaciones, tomar control remoto del equipo y automatizar tareas con scripts sobre muchos equipos a la vez.

El problema que resuelve es de escala: sin RMM, administrar cientos de equipos repartidos en decenas de clientes exige ir físicamente o conectarse uno por uno, y enterarse de los problemas cuando el cliente llama. Con RMM, el MSP ve toda la flota en una pantalla y trabaja sobre el problema antes de que se note. El usuario final casi nunca lo ve: es una herramienta interna del MSP, y su unidad de trabajo es el equipo.

Qué hace un ITSM

Un ITSM ordena el servicio: registra cada pedido o incidente como un ticket, lo asigna, mide el tiempo de respuesta contra el SLA comprometido y le da al usuario un portal donde abrir pedidos y ver el estado de los suyos. Los flujos típicos son la gestión de incidentes (algo se rompió), de pedidos (necesito algo) y de cambios (vamos a modificar algo).

La mayoría de los ITSM toma sus conceptos de ITIL, un marco de buenas prácticas para gestionar servicios de IT. No hace falta implementar ITIL de manera formal para usar un ITSM, pero de ahí vienen términos como incidente, problema y cambio. La unidad de trabajo del ITSM no es el equipo: es el pedido de una persona.

La diferencia de fondo, con un día de trabajo

El RMM mira máquinas; el ITSM mira pedidos de personas. Un día cualquiera de un MSP lo muestra. A las 9, el RMM alerta que el disco de un servidor pasó el umbral del 90%; un técnico libera espacio por control remoto y el cliente nunca se entera: no existió ticket, porque nadie pidió nada. A las 11, una empleada del cliente no puede imprimir y abre un ticket desde el portal; la impresora no tiene agente ni aparece en el RMM, pero el ticket vive en el ITSM con su SLA corriendo hasta que alguien lo resuelve. El primero es un problema de máquina detectado por software; el segundo es un pedido de una persona que hay que ordenar, priorizar y responder.

Dónde se solapan y dónde no

Se solapan en un punto concreto: la alerta que se vuelve ticket. Si el RMM detecta un disco lleno y eso dispara un ticket con su SLA, la frontera se cruza, y esa integración es justamente lo más valioso de tener los dos. También se cruzan cuando el técnico que atiende un ticket necesita el historial del equipo (parches aplicados, alertas previas, inventario) para diagnosticar.

No se solapan en el resto: el RMM no gestiona SLA ni pedidos que no tocan ningún equipo (un alta de usuario, un permiso, una consulta), y el ITSM no parchea, no monitorea ni toma control remoto de nada. Por eso uno no reemplaza al otro.

Qué es un PSA y por qué se confunde con el ITSM

PSA significa Professional Services Automation, y en el mercado MSP se usa casi como sinónimo de ITSM. Ahí está el lío real: un PSA incluye el ticketing y los SLA de un ITSM, y le suma la capa comercial del negocio: contratos, tiempo facturable y facturación. Un ITSM ordena el servicio; un PSA además lo cobra. Cuando un producto se vende como PSA, esperá tickets más contratos y facturación; cuando se vende como ITSM, esperá tickets y SLA, y la parte de facturación puede no estar.

Los nombres los pone cada proveedor: Atera, por ejemplo, se vende como RMM y PSA integrados en un solo producto; la comparativa con Atera muestra su alcance. Lo importante no es la sigla sino qué trae: fijate si el producto que evaluás incluye facturación y contratos o solo tickets.

Cuándo alcanza con uno y cuándo hacen falta los dos

Lo que no puede faltar a ninguna escala es el RMM: sin monitoreo, parches ni control remoto no hay operación de MSP, aunque los pedidos se anoten en un cuaderno. El ITSM formal, en cambio, tiene un umbral: un MSP de 2 técnicos con 40 equipos probablemente no lo necesita; los pedidos entran por WhatsApp o por correo, los técnicos se cruzan en la misma oficina y una lista compartida alcanza.

Los dos hacen falta cuando aparece alguna de estas señales: los pedidos empiezan a perderse o a responderse dos veces, firmaste contratos con SLA que tenés que poder demostrar, o el cliente pide ver el estado de sus tickets. Ese es el momento de sumar ITSM, no antes.

Cómo se combinan en la práctica

Hay tres caminos, cada uno con su costo.

• Producto único, RMM e ITSM en la misma consola. Una licencia, un proveedor, y la alerta y el ticket viven juntos: del disco lleno al ticket resuelto sin cambiar de pantalla. La contra es que cada mitad suele tener menos profundidad que un producto especialista. NinjaOne trae ticketing propio en su plataforma, Atera integra RMM y PSA, y KairosLink une RMM e ITSM en la misma consola.
• Dos productos integrados. Elegís un RMM especialista y un ITSM o PSA especialista y los conectás. Ganás profundidad en cada mitad; pagás dos licencias y dos contratos, y la integración queda a tu cargo: cuando se corta, cada proveedor mira al otro. ConnectWise, por ejemplo, vende Automate (el RMM) y su PSA como productos separados de la misma casa; la comparativa con ConnectWise Automate tiene el detalle. Los números de esa cuenta doble están en la guía de cuánto cuesta un RMM.
• Dos productos sueltos, sin integrar. Funciona al principio y es el camino más barato de entrada, pero el costo aparece en la operación: los técnicos cargan el contexto dos veces y la trazabilidad entre la alerta y el ticket se pierde. Si elegís este camino, que sea una etapa, no el destino.

Guías relacionadas

• Cómo elegir un RMM para un MSP pequeño
• Cuánto cuesta un RMM: modelos de precio comparados

Preguntas frecuentes