CMMS en la nube frente a on-premise: cómo elegir la arquitectura adecuada
Comparación técnica entre CMMS cloud, SaaS y on-premise: seguridad, conectividad, operación offline, costos e integraciones antes de elegir arquitectura.
Elegir entre un CMMS en la nube y un despliegue on-premise no depende de una preferencia general por el cloud o por el servidor propio. La decisión combina políticas de seguridad, conectividad de planta, capacidad del equipo de IT, integraciones existentes, continuidad operativa y costo total.
El desacuerdo aparece cuando cada área evalúa criterios distintos. Mantenimiento busca acceso móvil, disponibilidad para varias sedes y menos dependencia de solicitudes internas. IT necesita controlar identidades, respaldos, actualizaciones, interfaces y recuperación ante incidentes. Compras compara licencias y suscripciones, aunque parte del costo real suele quedar fuera de la propuesta inicial.
Una arquitectura viable en una planta conectada puede fallar en un sitio remoto si cambian la cobertura, el soporte o el tiempo aceptable de recuperación. Por eso, la evaluación debe comenzar por las condiciones de la operación y por una distribución explícita de responsabilidades.
Respuesta breve: un CMMS cloud suele encajar mejor cuando la organización necesita acceso distribuido y no desea administrar infraestructura. On-premise merece evaluación cuando existen redes aisladas, requisitos de alojamiento propio o capacidad interna para operar y recuperar la plataforma. La decisión final depende de conectividad, integraciones, RTO, RPO, gobierno de datos y alcance real de la operación offline.
Diferencias entre CMMS cloud, SaaS y on-premise
Cloud se refiere al uso de recursos informáticos accesibles por red; SaaS describe un modelo en el que el proveedor entrega y opera la aplicación; on-premise indica que el sistema se despliega bajo infraestructura controlada por la organización. NIST separa los modelos de servicio, como SaaS, de los modelos de despliegue cloud.
Qué implica contratar un CMMS como SaaS
El proveedor administra la aplicación y una parte significativa de la infraestructura. La empresa conserva responsabilidades sobre usuarios, permisos, dispositivos, procesos, calidad de datos y uso de la información. La evaluación debe aclarar quién gestiona actualizaciones, monitoreo, respaldos, restauración, disponibilidad, incidentes, exportación de datos y cambios de capacidad. La etiqueta SaaS no informa por sí sola el SLA, el RPO ni las condiciones de salida.
Qué implica desplegar un CMMS on-premise
La aplicación se instala en infraestructura administrada por la organización o por un tercero contratado. Ese control exige responsables para redes, servidores, base de datos, parches, certificados, respaldos, restauración, acceso remoto y compatibilidad entre versiones. Instalar el sistema dentro de la red corporativa no garantiza disponibilidad: la continuidad dependerá del diseño y de las pruebas de recuperación.
Comparativa y árbol de decisión para elegir la modalidad
| Criterio | CMMS cloud / SaaS | CMMS on-premise | Pregunta de decisión |
|---|---|---|---|
| Infraestructura | La administra principalmente el proveedor. | La administra la empresa o su contratista. | ¿Quién operará servidores, base de datos y monitoreo? |
| Actualizaciones | Se aplican según la política del proveedor. | Se coordinan entre cliente y proveedor. | ¿Quién prueba compatibilidad y reversión? |
| Seguridad | Responsabilidades compartidas. | Mayor carga directa sobre la empresa. | ¿Qué controles puede demostrar cada parte? |
| Conectividad | Depende del acceso al servicio y de las funciones offline. | Depende de LAN, WAN, VPN y enlaces entre sedes. | ¿Qué tareas deben continuar durante una caída? |
| Integraciones | API, conectores, túneles o middleware. | Acceso local potencial, sujeto a controles internos. | ¿Dónde reside el dato maestro de cada entidad? |
| Escalabilidad | Se amplía según el plan y la capacidad contratada. | Depende de la infraestructura instalada. | ¿Se incorporarán plantas, usuarios o módulos? |
| Recuperación | Depende del SLA y del procedimiento del proveedor. | Depende de respaldos y pruebas internas. | ¿Cuáles son el RTO y el RPO aceptables? |
| Portabilidad | Depende del contrato y de los formatos de exportación. | Depende del modelo de datos y del acceso técnico. | ¿Cómo se recuperará el historial al cambiar de esquema? |
La tabla no debe convertirse en una suma automática de ventajas. Una red aislada, una política corporativa o un requisito contractual pueden pesar más que varias diferencias menores.
Cuando una política contractual, regulatoria o corporativa obliga a alojar la aplicación en infraestructura definida por la empresa, debe evaluarse on-premise o una arquitectura dedicada que cumpla esa condición.
Sin personal y procedimientos para administrar servidores, base de datos, monitoreo, respaldo y recuperación, el despliegue local incorpora una dependencia que debe contratarse o desarrollarse.
Si trabajan varias plantas, contratistas o usuarios externos, cloud puede simplificar el acceso, siempre que se revisen identidad, conectividad y trabajo offline.
Una red de planta aislada o con restricciones a servicios externos puede requerir instalación local, segmentación o un esquema dedicado acordado con Seguridad e Infraestructura.
Las aplicaciones locales sin API pueden favorecer ciertos flujos on-premise, pero no eliminan la necesidad de autenticación, trazabilidad, monitoreo y gestión de errores.
On-premise permite mayor intervención en el calendario, siempre que exista una política para probar compatibilidad y no acumular versiones sin soporte.
Las tareas que deben seguir durante una caída determinan el alcance offline, el almacenamiento local y las reglas de sincronización.
La decisión tampoco tiene que ser binaria. Un CMMS puede operar en la nube, integrar un ERP local mediante API o middleware y utilizar una app offline en zonas sin cobertura. También puede mantenerse un despliegue dedicado con acceso móvil mediante una capa controlada. Cada flujo debe documentar su responsable y su condición de recuperación.
Seguridad, conectividad y operación offline
La seguridad no se determina solo por la ubicación del servidor.
Un sistema local puede quedar expuesto por cuentas compartidas, versiones sin soporte o copias de seguridad nunca probadas. Un servicio cloud también presenta riesgos si el contrato no asigna responsabilidades o si la empresa administra mal usuarios y dispositivos. CISA recomienda tratar la seguridad cloud mediante un modelo de responsabilidad compartida.
| Capa | Qué debe verificarse |
|---|---|
| Identidad | Cuentas individuales, altas y bajas, MFA o SSO y acceso de contratistas. |
| Autorización | Permisos por planta, rol, activo, proceso o tipo de registro. |
| Datos | Cifrado, respaldo, retención, restauración, residencia y eliminación. |
| Aplicación | Actualizaciones, vulnerabilidades, registro de cambios y soporte. |
| Infraestructura | Servidores, redes, almacenamiento, monitoreo y certificados. |
| Continuidad | SLA, RTO, RPO, escalamiento y evidencia de restauración. |
| Salida | Formato de exportación, adjuntos, plazo de entrega y eliminación posterior. |
La empresa conserva responsabilidades incluso en SaaS: retirar accesos, revisar privilegios, controlar dispositivos, definir campos obligatorios y mantener la calidad del historial técnico. El proveedor debe documentar arquitectura, incidentes, respaldos, actualizaciones y recuperación.
El alojamiento define dónde se ejecuta el sistema; la operación offline define qué puede hacer un usuario cuando el dispositivo no logra comunicarse. Un CMMS on-premise puede quedar inaccesible para otra sede si falla la VPN. Un CMMS cloud puede permitir trabajo de campo sin señal cuando la aplicación almacena y sincroniza las tareas necesarias.
La prueba debe cubrir el flujo real: consultar órdenes asignadas, registrar horas, completar checklists, adjuntar evidencia, informar repuestos y cerrar la intervención. También debe verificar conflictos de sincronización, protección del dato local y comportamiento ante la pérdida del equipo. En sitios remotos, la sincronización no debe duplicar consumos ni sobrescribir datos aprobados; en plantas conectadas por VPN, la disponibilidad depende además de enlaces, firewalls, DNS y del centro de datos.
Actualizaciones, continuidad, costos e integraciones
En SaaS, el proveedor suele definir el ciclo de versiones. El cliente debe conocer ventanas de mantenimiento, cambios funcionales, compatibilidad con integraciones y procedimiento de reversión. En on-premise, la organización interviene más en el calendario, pero debe coordinar pruebas, respaldo, instalación y soporte de versiones.
La continuidad necesita evidencia: RTO, RPO, SLA, responsables, frecuencia de pruebas y escalamiento deben expresarse con datos verificables. Una copia diaria no demuestra recuperación si nadie controla su resultado ni mide cuánto tarda restaurar la base y los archivos adjuntos.
El precio de la licencia o de la suscripción no alcanza para comparar modalidades: conviene revisar los planes y precios completos antes de decidir. On-premise debe incluir infraestructura, base de datos, almacenamiento, monitoreo, administración, parches, pruebas y renovación. Cloud debe revisar usuarios, almacenamiento, soporte, entornos, integraciones, exportación y condiciones de salida.
Las integraciones tampoco se definen por el alojamiento. Un CMMS cloud puede intercambiar datos con un ERP local mediante API, middleware, túneles seguros o procesos programados. Un despliegue on-premise puede reducir cierta complejidad de red, pero sigue necesitando autenticación, trazabilidad, reintentos, monitoreo y un responsable del dato maestro.
Cómo cambia la decisión y qué verificar antes de aprobar
| Operación | Condición dominante | Punto de decisión |
|---|---|---|
| Manufactura multiplanta | Usuarios distribuidos, catálogos comunes, ERP central y enlaces entre sedes. | Acceso, permisos, continuidad por planta y ownership de datos. |
| Alimentos y bebidas | Evidencia, adjuntos, aprobaciones y recuperación durante auditorías. | Control de cambios, retención, perfiles y restauración. |
| Minería u Oil & Gas | Cobertura irregular, sitios remotos y soporte a distancia. | Probar flujo offline y sincronización, no solo el acceso inicial. |
| Facility management | Edificios distribuidos, contratistas y solicitudes externas. | Permisos por ubicación, acceso de terceros y consolidación de reportes. |
| Utilities e infraestructura | Redes segmentadas, activos dispersos y exigencias de continuidad. | Arquitectura de acceso, escalamiento y recuperación por sitio. |
El alojamiento no corrige un proceso mal definido. Una plataforma disponible con órdenes incompletas, usuarios genéricos o catálogos duplicados seguirá produciendo información débil. La arquitectura debe facilitar la adopción en operaciones distribuidas como las de facility management, pero la disciplina de cierre y el gobierno de datos continúan bajo responsabilidad de la operación.
Checklist técnico de evaluación
La aprobación debe basarse en documentación sobre seguridad, disponibilidad, recuperación, integración y portabilidad, no solo en la etiqueta cloud u on-premise.
La elección debe quedar respaldada por responsables, evidencia y criterios de aceptación. La arquitectura adecuada es la que puede mantenerse después de la puesta en marcha, soporta el trabajo de campo y conserva la trazabilidad cuando aparecen fallas, cambios de versión o interrupciones de red.
Validá la arquitectura antes de cerrar la decisión
Compartí cantidad de sedes, usuarios, sistemas a integrar, restricciones de conectividad y requisitos de datos para revisar qué modalidad conviene evaluar y qué puntos requieren validación con IT.
