PROLIFERACIÓN DE APLICACIONES SAAS · ARQUITECTURA · PRODUCTO · OPERACIONES
Cada nuevo problema parece pedir una herramienta. Un CRM para ventas, un sistema de tickets para soporte, otra wiki para documentación, una plataforma para automatizar tareas y un dashboard que, en teoría, lo reúne todo. La proliferación de aplicaciones SaaS rara vez nace de un plan maestro. Nace de decisiones locales razonables que nadie termina de conectar. El resultado puede ser curioso: las aplicaciones funcionan bien por separado, pero la organización funciona cada vez peor.
Hay un momento bastante reconocible en la vida de una empresa: alguien propone una nueva aplicación y la conversación empieza con un «solo cuesta unos euros por usuario». Nadie está intentando complicar el trabajo. El equipo comercial necesita organizar sus oportunidades, soporte quiere resolver incidencias con mayor rapidez y desarrollo necesita documentar decisiones sin volver a describir el código ni perseguir mensajes antiguos.
Todas son necesidades legítimas. El problema aparece cuando resolvemos cada una sin mirar las anteriores.
Seis meses después, el estado de un cliente está en el CRM, la incidencia en una plataforma de soporte, las tareas en un gestor de proyectos, una hoja de cálculo conecta los tres sistemas y el conocimiento que explica las excepciones vive repartido entre una wiki y un canal de mensajería.
La proliferación de aplicaciones SaaS no es simplemente tener demasiadas suscripciones. Es dejar que cinco decisiones de equipo se conviertan, sin permiso, en la arquitectura de toda la empresa.
TL;DR
Una aplicación SaaS no cuesta solo su licencia: añade identidades, permisos, datos, integraciones, soporte, formación, riesgo contractual y una futura migración. Antes de comprar, conviene inventariar qué capacidad resuelve cada herramienta, quién responde por ella, qué dato gobierna y cómo se accede a ella. Después, decidir entre mantener, consolidar, integrar o retirar. El objetivo no es tener el menor número posible de aplicaciones, sino reducir duplicidades y conseguir que el conjunto se comporte como un sistema gobernable.
La suma de cinco buenas decisiones puede producir un mal sistema
Imaginemos una organización que incorpora una aplicación para cada problema:
- Ventas necesita gestionar clientes y contrata un CRM.
- Soporte incorpora un sistema de tickets.
- Desarrollo elige una herramienta para organizar su backlog.
- Operaciones activa un servicio de automatizaciones.
- Dirección contrata una plataforma de BI para unificar indicadores.
Ninguna decisión parece disparatada por separado. Incluso pueden ser las herramientas correctas para cada departamento. Pero ¿quién mantiene el catálogo de clientes? ¿Qué aplicación determina quién puede ver una incidencia? ¿Dónde se documenta que una tarea ya se ha completado? ¿Quién actualiza el acceso de alguien cuando cambia de departamento?
En ese punto ya no tenemos cinco aplicaciones independientes. Tenemos un sistema distribuido que quizá nadie ha diseñado como tal.
Y lo más delicado: la empresa puede estar pagando por funcionalidad duplicada y, al mismo tiempo, mantener procesos manuales para cubrir aquello que ninguna herramienta resuelve de extremo a extremo.
El precio de una aplicación no es su licencia
Una suscripción de 12 € por persona y mes resulta fácil de justificar si se compara con el tiempo que supuestamente ahorra. Pero esa cifra no describe el coste total de propiedad.
El coste real de la proliferación de aplicaciones SaaS
El mercado SaaS se ha vuelto más incierto. Los proveedores incorporan capas de IA, cambian modelos de precio, añaden consumos variables y amplían contratos a mitad de periodo. El 2026 SaaS Management Index de Zylo describe bien ese escenario: el gasto medio anual en SaaS se sitúa en 55,7 millones de dólares, un 8% más interanual, mientras el número medio de aplicaciones se mantiene en torno a 305. Es decir, el crecimiento ya no viene principalmente de sumar herramientas, sino de cómo esas herramientas se precian, se empaquetan y se expanden con el tiempo. En grandes organizaciones, el gasto anual creció cerca de un 16% interanual.
Conviene leer estos datos como referencia sectorial —proceden del conjunto de datos del proveedor—, pero la dirección es clara: evaluar una incorporación únicamente por su plan mensual resulta cada vez más insuficiente.
Cada aplicación puede añadir trabajo en siete planos:
- Identidad: altas, bajas, SSO, MFA, cuentas de servicio y usuarios externos.
- Autorización: roles, permisos por departamento y excepciones que deben revisarse.
- Datos: duplicados, exportaciones, retención, copias y responsabilidad sobre cada registro.
- Integraciones: APIs, webhooks, conectores, sincronización y tratamiento de errores.
- Operación: incidencias, cambios de proveedor, documentación y formación interna.
- Seguridad y cumplimiento: auditoría, riesgo de terceros y revisión de configuraciones.
- Contrato: renovaciones automáticas, crecimiento de consumo, licencias inactivas y condiciones de salida.
Coste total, valor y responsabilidad
No todos estos costes son iguales ni hay que evitarlos siempre. Hay aplicaciones especializadas que justifican sobradamente su existencia. Lo importante es dejar de mirar solo la factura mensual y empezar a mirar el sistema completo.
El enfoque de FinOps for SaaS propone precisamente combinar inventario, uso, consumo, contratos, responsables y valor para decidir qué conservar, ajustar o consolidar. No se trata de reducir herramientas por estética: se trata de poder justificar qué aporta cada una. Fuente: FinOps Foundation.
La proliferación de aplicaciones SaaS también genera deuda de identidad
A menudo hablamos de deuda técnica pensando en código antiguo. Sin embargo, también podemos acumular deuda fuera de nuestros repositorios.
Una persona entra en la empresa y recibe acceso al correo, al gestor de proyectos, al portal de soporte y a otras seis herramientas. Meses después cambia de equipo. Se modifican sus permisos principales, pero una de las aplicaciones conserva su antiguo rol de administrador. Más adelante abandona la organización y alguien descubre que todavía existe una cuenta local ajena al proveedor central de identidad.
El problema no es que la aplicación sea insegura por definición. Es que hemos incorporado otra frontera de administración sin definir el ciclo de vida de sus identidades.
En esa línea, el proyecto SCuBA de CISA para Microsoft 365 y Google Workspace recuerda algo importante: asegurar aplicaciones cloud no se limita a activar SSO o MFA el día de la implantación. Hace falta definir baselines de configuración segura, revisar permisos, entender identidades híbridas y poder evaluar el estado real del entorno. Para ello, CISA ofrece herramientas como ScubaGear para Microsoft 365 y ScubaGoggles para Google Workspace, que comparan la configuración actual con sus recomendaciones y generan informes visuales de postura de seguridad. Fuente: CISA SCuBA.
Por eso conviene preguntarse antes de contratar:
- ¿Se integra con nuestro proveedor de identidad mediante SSO?
- ¿Permite aprovisionamiento y desaprovisionamiento fiables?
- ¿Qué ocurre con las cuentas locales y las cuentas técnicas?
- ¿Podemos limitar los permisos y revisar quién accedió a los datos?
- ¿Qué conservamos cuando damos de baja la suscripción?
Cómo frenar la proliferación de aplicaciones SaaS antes de comprar
No propongo convocar un comité para aprobar cualquier herramienta de trabajo. Propongo algo más modesto y más útil: construir un inventario suficientemente claro para que la siguiente decisión no se tome a ciegas.
Para cada aplicación deberíamos conocer, como mínimo:
| Pregunta | Información que necesitamos |
|---|---|
| ¿Para qué existe? | Proceso y capacidad que resuelve |
| ¿Quién responde por ella? | Responsable funcional y técnico |
| ¿Quién la utiliza? | Departamentos, usuarios y terceros |
| ¿Qué dato gobierna? | Sistema de referencia de cada entidad |
| ¿Con qué se conecta? | APIs, webhooks, importaciones y dependencias |
| ¿Cómo se accede? | SSO, MFA, roles y offboarding |
| ¿Cuánto cuesta? | Licencias, consumo, mantenimiento e integración |
| ¿Podemos abandonarla? | Exportación, contrato, retención y plan de salida |
La columna más importante puede que no sea el coste, sino «¿qué dato gobierna?». Si un mismo cliente se edita de forma independiente en tres plataformas, eliminar una licencia no arreglará el problema de fondo.
Distingue las herramientas de los sistemas de referencia
Un portal puede presentar información, una intranet puede aplicar reglas de negocio y una plataforma externa puede gestionar tickets. Eso no obliga a que cada una sea propietaria de toda la información que muestra.
Un diseño razonable determina qué sistema manda sobre cada dato, dónde se autoriza cada operación y cómo se propagan los cambios. Así evitamos acabar usando integraciones bidireccionales para reconciliar cinco versiones de la misma realidad.
Mi criterio
Si dos aplicaciones pueden modificar la misma entidad y ninguna está declarada como sistema de referencia, el problema no es de sincronización: falta una decisión de arquitectura.
Cinco señales de que tu stack necesita una revisión
1. Dos aplicaciones resuelven el mismo proceso
Si hay dos tableros donde se asigna y se completa el mismo trabajo, puede que uno sea una vista útil. Pero también es posible que estemos duplicando el estado y generando reuniones para reconciliarlo.
2. Una hoja de cálculo es el pegamento obligatorio
Las hojas de cálculo son herramientas excelentes. El riesgo aparece cuando una persona necesita descargar dos CSV, cruzarlos manualmente y volver a importarlos para que el sistema funcione. En ese momento existe una integración real que no se ha reconocido formalmente.
3. Nadie sabe quién es el propietario
Una aplicación sin responsable suele seguir renovándose por inercia. Nadie puede decidir qué datos almacena, qué cambios admite o cuál sería el procedimiento correcto para retirarla.
4. Las bajas de empleados requieren una búsqueda del tesoro
Si el responsable de sistemas debe preguntar a cada departamento qué herramientas utiliza alguien, el inventario de identidades es incompleto. El problema se agrava cuando existen cuentas compartidas y tokens personales de integración.
5. Dos dashboards ofrecen respuestas distintas
Si ventas y dirección consultan dos cifras de clientes activos que no coinciden, probablemente falta una definición compartida antes que una nueva plataforma de analítica. La discrepancia puede estar en el origen, el filtro o las reglas de negocio.
Caso práctico: AF Informática, centralizar sin meterlo todo en una única herramienta
Esta reflexión tiene un ejemplo cercano y honesto en la reorganización de herramientas que estamos abordando en AF Informática durante 2026. Al revisar la operativa de soporte, desarrollo y gestión de proyectos, la tentación sería buscar una plataforma que lo hiciera absolutamente todo: tickets, planificación, repositorios, documentación, permisos y reporting. Pero cambiar siete aplicaciones por una sola no garantiza haber diseñado mejor el sistema.
Este caso permite observar la proliferación de aplicaciones SaaS como un problema de responsabilidades y fronteras, no como una simple suma de licencias.
La decisión de arquitectura es otra: establecer una entrada reconocible, definir dónde vive cada regla y evitar que dos herramientas compitan por ser la fuente de verdad del mismo dato. La distribución de responsabilidades que guía el trabajo es la siguiente:
| Capacidad | Papel de la herramienta |
|---|---|
| Portal de clientes de AF | Punto de entrada para los clientes y conexión con los servicios internos |
| Intranet desarrollada en Symfony | Reglas de negocio, autorizaciones por empresa o departamento, asignaciones y orquestación de eventos |
| PranaDesk | Registro y ciclo operativo de los tickets; no es el motor de las reglas corporativas |
| Odoo 18 | Proyectos, tareas, planificación y registro de tiempos |
| GitLab | Repositorios, control de cambios y flujo de desarrollo |
| Outline | Documentación y conocimiento compartido |
| Passbolt | Gestión de credenciales y secretos de equipo |
Una arquitectura con responsabilidades explícitas
Pongamos un ejemplo: un cliente comunica una incidencia a través del portal. La capa corporativa comprueba el contexto y aplica las reglas correspondientes; PranaDesk conserva el ticket. Si de esa incidencia deriva un desarrollo que necesita planificación, la relación con la tarea se gestiona en Odoo. No es necesario que Odoo sustituya al ticketing ni que PranaDesk reproduzca toda la estructura de proyectos. El código se mantiene en GitLab y las decisiones que deban perdurar se documentan en Outline, no se convierten en otro hilo de mensajes imposible de encontrar.
Migrar y consolidar sin crear otra capa paralela
El mismo criterio explica dos líneas de trabajo complementarias: trasladar progresivamente la operativa de Redmine a Odoo, proyecto a proyecto, y ordenar los canales de soporte para que el correo directo y el teléfono no se conviertan en sistemas paralelos de seguimiento —sin eliminar la atención telefónica para urgencias—. El objetivo es que una petición tenga un recorrido conocido, responsables identificables y estados que no haya que reconciliar manualmente en tres pantallas.
Conviene precisar que esta reorganización es un proceso en curso, no un caso cerrado al que podamos atribuir un ahorro concreto de licencias o un porcentaje de mejora ya medido. Algunas integraciones y migraciones siguen evolucionando. Su interés como ejemplo está precisamente en la decisión: antes de incorporar otra herramienta, definir las fronteras de las que ya existen y retirar duplicidades a medida que se valida la transición.
Y hay una lección que va más allá del SaaS: en un ecosistema híbrido, con desarrollo propio y servicios externos, centralizar la operativa no significa concentrar todas las funciones en un monolito; significa que el conjunto se comporte como un único sistema para quien lo utiliza.
Gobernar la proliferación de aplicaciones SaaS: mantener, consolidar, integrar o retirar
Cada aplicación debería acabar en una de cuatro situaciones:
| Decisión | Cuándo tiene sentido |
|---|---|
| Mantener | Resuelve una capacidad diferencial y tiene responsable claro |
| Consolidar | Otra herramienta cubre el mismo proceso sin degradar la operativa |
| Integrar | Es especializada, necesaria y se conecta mediante un contrato de datos explícito |
| Retirar | Ya no aporta suficiente valor o su función ha quedado sustituida |
Consolidar no significa obligar a toda la empresa a usar una herramienta genérica para cualquier cosa. A veces mantener dos productos es una buena decisión: uno puede responder a una necesidad regulatoria, a un proceso industrial o a un rendimiento que el otro no alcanza.
La racionalización tampoco consiste en cerrar servicios sin más. Antes de retirar una plataforma hay que revisar dependencias, exportar datos, validar retenciones, migrar usuarios, reemplazar integraciones y conservar la información que pueda ser necesaria para auditoría.
Cómo saber si estás racionalizando de verdad
Un error frecuente es medir el éxito solo por el número de licencias eliminadas. Eso puede ser útil, pero es insuficiente. La proliferación de aplicaciones SaaS no se combate únicamente restando herramientas: se combate mejorando el gobierno del conjunto.
Algunos indicadores más útiles pueden ser estos:
- Porcentaje de aplicaciones con responsable funcional y técnico identificado.
- Número de entidades críticas gobernadas por más de un sistema de referencia.
- Tiempo medio de offboarding: cuántas herramientas quedan pendientes al dar de baja a una persona.
- Cuentas locales, compartidas o técnicas fuera del proveedor central de identidad.
- Licencias inactivas detectadas y renovaciones justificadas por uso real.
- Procesos que todavía requieren reconciliación manual entre aplicaciones.
- Incidentes o casi-incidentes relacionados con permisos excesivos.
- Coste total por proceso, no solo coste por licencia.
Si tras una revisión disminuyen las duplicidades, mejoran los controles de acceso y se reduce el trabajo manual de reconciliación, la racionalización está funcionando. Si solo baja la factura pero aumentan los parches humanos, probablemente hemos trasladado el problema a otro sitio.
Un ejercicio de treinta días, sin comprar otra plataforma para hacerlo
La primera auditoría puede ser bastante sencilla:
Semana 1. Descubrir. Unifica suscripciones, facturas, accesos SSO, herramientas declaradas por departamentos y aplicaciones que intercambian datos. No confíes únicamente en el inventario de TI: puede haber compras descentralizadas, renovaciones automáticas o licencias contratadas desde tarjetas corporativas.
Semana 2. Dibujar dependencias. Representa los procesos y los datos, no solo logotipos conectados con flechas. Marca dónde nace cada entidad, quién puede modificarla y qué ocurre si una integración falla.
Semana 3. Contrastar con los usuarios. Reúne a los responsables de cada proceso. Busca duplicidades, pasos manuales y dependencias que los diagramas no reflejan. Una aplicación poco utilizada puede seguir siendo crítica para un cierre mensual, una auditoría o un servicio concreto.
Semana 4. Decidir y ejecutar un piloto. Selecciona una duplicidad acotada. Define el sistema que permanece, cómo migrar los datos, cómo comprobar la equivalencia funcional y cómo revertir el cambio si algo falla. Después revisa el resultado antes de extender el método.
Un buen indicador de éxito no es «hemos eliminado cinco licencias», sino algo más próximo a «el equipo completa el mismo proceso con menos cambios de contexto, menos duplicación de datos y controles de acceso más claros».
Y ahora también tenemos que contar con los agentes de IA
La facilidad para construir nuevas interfaces, automatizaciones y agentes está bajando la barrera de entrada. Eso es positivo, pero también facilita crear una aplicación para corregir el comportamiento de otra aplicación, y una tercera para vigilar a las dos anteriores.
La IA no solo añade nuevas herramientas: también está cambiando la economía de las existentes. Zylo señala que el gasto en aplicaciones AI-native aumentó un 108%, mientras que el uso de la categoría Artificial Intelligence creció un 181% en el conjunto de su dataset. Además, el 78% de los líderes de TI reportó cargos inesperados ligados a funciones de IA o a modelos de precio por consumo, y el 61% afirmó haber recortado proyectos debido a subidas imprevistas de coste SaaS.
Esta aceleración puede intensificar la proliferación de aplicaciones SaaS y también desplazar el cuello de botella hacia la revisión y validación de todo lo generado.
Si incorporamos un agente, conviene someterlo a las mismas preguntas que planteamos a cualquier sistema: cuál es su propósito, qué datos necesita, con qué identidad actúa, qué permisos tiene, quién supervisa sus acciones, qué registra cuando toma una decisión y qué sucede cuando deja de funcionar.
La IA puede acortar el tiempo necesario para crear una herramienta; no reduce automáticamente el coste de integrarla, gobernarla y mantenerla.
Preguntas frecuentes
¿Cuántas aplicaciones SaaS son demasiadas?
No existe un número universal. El exceso aparece cuando hay capacidades duplicadas, datos sin sistema de referencia, cuentas fuera del ciclo de identidad, integraciones sin owner o renovaciones que nadie puede justificar por uso y valor. Diez aplicaciones bien gobernadas pueden ser más simples que cinco con responsabilidades solapadas.
¿Eliminar aplicaciones SaaS siempre reduce costes?
No. Una retirada mal preparada puede trasladar trabajo a procesos manuales, degradar una capacidad especializada o generar una migración más cara que la licencia. Hay que comparar licencia, operación, integración, riesgo y coste de salida, y verificar que el proceso permanece completo tras la consolidación.
¿Qué información mínima debe tener un inventario SaaS?
Propósito, responsable funcional y técnico, usuarios, datos tratados, sistema de referencia, método de acceso, integraciones, coste, renovación, uso real y plan de salida. Sin ownership y dependencias, el inventario es solo una lista de nombres.
¿Cómo se retira una aplicación sin romper la operativa?
Primero se identifican datos, usuarios, integraciones, obligaciones de retención y procesos dependientes. Después se migra una capacidad acotada, se comprueba la equivalencia, se mantiene una ventana de reversión y solo entonces se cierran accesos, automatizaciones y contrato.
La mejor decisión de arquitectura puede ser no incorporar nada
Hay propuestas que merecen una nueva aplicación. Otras necesitan mejorar un proceso, definir la propiedad de un dato, completar una integración existente o retirar un paso que dejó de tener sentido.
Antes de aprobar otra suscripción, haría tres preguntas en este orden: ¿qué problema concreto queremos eliminar?, ¿podemos resolverlo con las capacidades que ya tenemos? y, si la respuesta es no, ¿quién se hará cargo de la nueva pieza durante todo su ciclo de vida?
La próxima vez que alguien diga «necesitamos una herramienta para esto», quizá convenga responder con una pregunta distinta: ¿necesitamos más software o necesitamos que el software que ya tenemos trabaje como un sistema?
Fuentes y lecturas recomendadas
- FinOps Foundation — FinOps for SaaS: inventario, responsabilidad, consumo y racionalización de herramientas.
- Zylo — 2026 SaaS Management Index: contexto sectorial del consumo de aplicaciones, gasto SaaS, licencias, IA y volatilidad de costes. Los resultados proceden del conjunto de datos del proveedor y no deben extrapolarse sin matices a cualquier empresa.
- CISA — Secure Cloud Business Applications (SCuBA): líneas base de configuración segura para Microsoft 365 y Google Workspace, herramientas de evaluación como ScubaGear y ScubaGoggles, y orientación sobre identidad híbrida y visibilidad.
Deja una respuesta