Hay una expresión que se ha vuelto comodín en el mundo del software: "sistema administrativo". Se usa para vender cualquier cosa: un ERP en la nube, un CRM, una plataforma de facturación, un gestor de inventarios, un sistema de nómina. Todo cabe bajo esa etiqueta. Y sin embargo, en la mayoría de los casos, lo que estamos comprando no es un sistema administrativo: es acceso condicionado a la infraestructura de otro.
Esa diferencia no es semántica. Es la diferencia entre tener el control de tu operación y depender de la buena voluntad, la estabilidad y la permanencia de un tercero. Y como valuador técnico, he visto suficientes casos como para saber que esa distinción tiene consecuencias reales, medibles y a veces irreversibles.
Este
artículo no es un ataque al SaaS. Es una reflexión sobre lo que
deberíamos exigirle a algo antes de llamarlo "sistema administrativo".
La promesa del SaaS: todo suena perfecto hasta que deja de sonar
Empecemos por reconocer lo bueno. El Software como Servicio (SaaS) resolvió problemas que durante décadas fueron un dolor de cabeza:
No haces mantenimiento. El proveedor se encarga.
No haces actualizaciones. Llegan solas, sin que tengas que migrar nada.
No corriges errores. Alguien más lo hace por ti.
No compras servidores. Pagas una suscripción y listo.
No contratas personal técnico dedicado. El soporte viene incluido.
Hasta ahí, todo bien. Para muchas empresas pequeñas, el SaaS fue la puerta de entrada a herramientas que antes eran inalcanzables. No lo niego.
El problema no está en la promesa. Está en lo que no se dice cuando se firma el contrato.
El problema real: no es tu sistema, es el de otro
Cuando contratas SaaS, no estás comprando un sistema. Estás alquilando acceso a un sistema que pertenece a otra empresa, que corre en servidores de otra empresa, que se actualiza cuando esa empresa decide, que cambia de precio cuando esa empresa quiere, y que puede desaparecer cuando esa empresa lo determine.
Eso no es un sistema administrativo. Es una dependencia con interfaz gráfica.
Y las dependencias fallan. Siempre fallan. La pregunta no es si van a fallar, sino cuándo y qué tan caro te va a salir.
Veamos los escenarios más comunes.
Los cuatro escenarios donde "tu sistema" deja de ser tuyo
1. El proveedor cambia todo y tú no tienes voto
Un día entras y la interfaz es distinta. Los flujos cambiaron. Los reportes que usabas ya no existen. El módulo que necesitabas ahora está en un plan superior. Las integraciones que habías configurado se rompieron.
No hubo consulta. No hubo migración asistida. No hubo opción de quedarte en la versión anterior. Simplemente cambió, porque el proveedor decidió que era momento de cambiar.
Eso no pasa con un sistema que controlas. Pasa con uno que te controla.
2. Se cae el internet y te quedas sin operar
Parece trivial hasta que pasa. Se va la conexión en tu oficina, en tu planta, en tu sucursal. Y de repente:
No puedes facturar.
No puedes consultar inventario.
No puedes registrar pagos.
No puedes atender a un cliente.
Tu operación entera queda detenida esperando que vuelva un servicio que no controlas. En un sistema instalado localmente, puedes seguir trabajando en modo offline y sincronizar después. En la nube pura, no. Estás a merced de la conexión.
3. El servidor del proveedor falla
No es tu internet. Es el de ellos. Y da igual que tengas fibra óptica simétrica y respaldo eléctrico: si el proveedor tiene una caída, tú también.
Los SLA prometen disponibilidad del 99.9%. Ese 0.1% suena pequeño hasta que cae en el cierre de mes, en el día de la declaración, o en plena temporada alta. Y cuando pasa, el soporte te responde con un correo genérico y un "estamos trabajando en ello".
4. El proveedor se va del país (o del mercado)
Este es el escenario que más he visto y el que menos se menciona en las conversaciones sobre SaaS.
Muchas empresas de software operan en mercados pequeños o inestables. Un día hacen números, concluyen que vender aquí no es rentable, y se van. Cierran la operación local, descontinúan el servicio, o simplemente dejan de responder.
¿Y tus datos? ¿Y tus años de historial? ¿Y la operación que dependía de esa herramienta?
En el mejor caso, te dan un export en un formato que nadie puede leer. En el peor, te enteras por un correo automático de que el servicio se descontinúa en 30 días.
Eso no es un sistema administrativo. Es una relación de dependencia sin garantías.
Lo que un "sistema administrativo" debería garantizar
Si vamos a llamar "sistema administrativo" a algo, deberíamos exigirle un mínimo:
Control sobre los datos. Que puedas exportarlos en formatos abiertos, completos y utilizables, cuando quieras y sin pedir permiso.
Continuidad operativa. Que puedas seguir trabajando aunque falle la conexión, aunque caiga el proveedor, aunque cambie el contrato.
Estabilidad de la herramienta. Que las actualizaciones no rompan tu operación ni te obliguen a reaprender todo cada seis meses.
Permanencia garantizada. Que si el proveedor decide irse, haya un plan de transición, no una carta de despedida.
Portabilidad real. Que puedas migrar a otro sistema sin perder historial, configuraciones ni integraciones.
Nada
de eso es exótico. Todo eso era estándar en el software instalado de
los años 2000. Lo perdimos a cambio de comodidad, y ahora lo llamamos
"modernización".
No es un problema del SaaS, es un problema de cómo lo usamos
Quiero ser justo: el SaaS no es el enemigo. Hay SaaS excelentes, bien diseñados, con exportaciones limpias, con APIs abiertas, con planes de continuidad serios. El problema no es el modelo. El problema es la forma en que se vende y se compra.
Se vende como "sistema administrativo" cuando en realidad es acceso condicionado.
Se compra sin preguntar qué pasa si el proveedor se va.
Se firma sin exigir portabilidad, sin pedir exportaciones, sin negociar continuidad.
Y después, cuando el proveedor cambia, cae o se va, nos sorprendemos.
Cómo evaluar un "sistema administrativo" antes de adoptarlo
Desde mi rol como valuador técnico, estas son las preguntas que hago siempre antes de recomendar cualquier plataforma:
¿Puedo exportar todos mis datos, completos y en formato abierto, en cualquier momento?
¿Qué pasa si el proveedor cierra o se va del país? ¿Hay plan de transición?
¿Puedo seguir operando si se cae el internet?
¿Las actualizaciones son opcionales o forzosas?
¿Puedo quedarme en una versión estable si la nueva rompe mi flujo?
¿Hay contrato de permanencia o pueden cambiar precios y condiciones unilateralmente?
¿El proveedor tiene presencia local, soporte real y trayectoria verificable?
Si
la respuesta a varias de estas es "no" o "depende", entonces no estás
comprando un sistema administrativo. Estás alquilando una dependencia
con otro nombre.
Llamemos a las cosas por su nombre
Un sistema administrativo debería estar bajo tu control. Debería servirte a ti, no al revés. Debería seguir funcionando cuando el proveedor falla, cuando el internet se cae, cuando el mercado cambia.
Cuando eso no se cumple, no estamos hablando de un sistema administrativo. Estamos hablando de acceso condicionado a la infraestructura de otro, con un contrato de por medio y una interfaz bonita.
Y eso está bien si lo sabes. Lo que no está bien es llamarlo "sistema administrativo" y creer que tienes el control.
Porque el día que el proveedor cambie todo, se caiga o se vaya, vas a descubrir —tarde— que nunca fue tuyo.
No olvides suscribirte a mi newsletter:
0 Comentarios
Deja tu comentario: