Cómo detectar aplicaciones infrautilizadas

Introducción

Las aplicaciones empresariales tienden a acumularse. Una herramienta se contrata para resolver una necesidad concreta, otra llega porque incluye una función que la anterior no tenía, una tercera se utiliza durante un proyecto y una cuarta permanece porque nadie está seguro de si todavía resulta necesaria. Con el tiempo, la empresa puede estar pagando y manteniendo más software del que realmente utiliza.

El problema no es únicamente económico. Cada aplicación adicional implica cuentas de usuario, contraseñas, permisos, datos, integraciones, actualizaciones, soporte, documentación y conocimiento que alguien debe conservar. Incluso una herramienta barata puede aumentar la complejidad si duplica funciones existentes o solo la utiliza una persona de forma ocasional.

Detectar aplicaciones infrautilizadas exige algo más que preguntar cuándo se abrió por última vez. Una aplicación puede utilizarse pocas veces y seguir siendo crítica. Un programa de presentación fiscal, una herramienta de recuperación o una utilidad técnica específica pueden ejecutarse esporádicamente y justificar plenamente su existencia. Al contrario, una aplicación abierta todos los días puede aportar poco valor si solo reproduce funciones disponibles en otra herramienta.

Por eso la evaluación debe combinar frecuencia de uso, número de usuarios activos, funciones utilizadas, coste, criticidad, alternativas disponibles, dependencia de datos y valor que aporta al proceso.

Este artículo explica cómo realizar esa auditoría de forma práctica. El objetivo no es retirar software inmediatamente, sino identificar qué aplicaciones merecen una revisión y obtener evidencia suficiente para decidir después si conviene conservarlas, renegociarlas, reducir licencias, sustituirlas o eliminarlas.

Índice

• Qué significa realmente que una aplicación esté infrautilizada
• Empezar por un inventario fiable
• Medir usuarios activos, no usuarios contratados
• Analizar la frecuencia real de uso
• Medir qué funciones se utilizan
• Relacionar cada aplicación con procesos de negocio
• Calcular el coste por uso útil
• Detectar solapamientos funcionales
• Comprobar qué datos dependen de la aplicación
• Revisar integraciones y dependencias ocultas
• Distinguir uso escaso de falta de valor
• Detectar licencias sobredimensionadas
• Localizar aplicaciones fuera del inventario oficial
• Preguntar a los usuarios sin depender solo de opiniones
• Clasificar aplicaciones según evidencia
• Probar la retirada antes de eliminar
• Indicadores para repetir la revisión periódicamente
• Procedimiento práctico paso a paso
• Errores frecuentes
• Conclusión
• Preguntas frecuentes

Qué significa realmente que una aplicación esté infrautilizada

Infrautilizar una aplicación significa que los recursos dedicados a mantenerla son desproporcionados respecto al valor que produce. Esa definición es más útil que limitarse a contar accesos.

Poco uso no equivale siempre a infrautilización

Una herramienta utilizada una vez al trimestre puede ser imprescindible si resuelve una obligación o una operación de alto impacto. El valor debe medirse en función de su finalidad.

Mucho uso tampoco garantiza aprovechamiento

Una aplicación puede abrirse diariamente y utilizarse solo como bloc de notas, repositorio de archivos o intermediario innecesario entre dos sistemas.

Hay varias formas de infrautilización

• Infrautilización por usuarios: se pagan muchas cuentas y solo una parte se usa.
• Infrautilización por funciones: se contrata un plan avanzado pero solo se utilizan capacidades básicas.
• Infrautilización por frecuencia: la aplicación apenas interviene en la actividad real.
• Infrautilización por solapamiento: sus funciones ya están cubiertas por otra herramienta.
• Infrautilización por proceso: existe, pero el proceso para el que se contrató ha desaparecido o cambiado.
• Infrautilización económica: el valor obtenido es muy bajo respecto al coste total.

Una auditoría útil intenta identificar cuál de estas situaciones existe antes de proponer una acción.

Empezar por un inventario fiable

No se puede evaluar lo que no se conoce. El primer paso es construir una lista suficientemente completa de aplicaciones utilizadas por la empresa.

No limitarse a las facturas

Las facturas revelan productos de pago, pero pueden existir herramientas gratuitas, software adquirido hace años, aplicaciones instaladas localmente y servicios contratados directamente por usuarios.

Registrar información mínima

Para cada aplicación conviene anotar:

• nombre;
• finalidad declarada;
• responsable;
• usuarios o licencias contratadas;
• coste;
• fecha de renovación;
• tipo de alojamiento;
• datos que contiene;
• integraciones;
• proceso empresarial asociado.

Incluir aplicaciones pequeñas

Los mayores costes ocultos pueden estar en herramientas aparentemente insignificantes que se acumulan por decenas.

Identificar propietario funcional

Debe existir alguien capaz de explicar por qué se utiliza la aplicación. Si nadie puede hacerlo, ya existe una señal de revisión.

Medir usuarios activos, no usuarios contratados

Uno de los indicadores más directos es comparar las licencias disponibles con las realmente utilizadas.

Definir qué significa usuario activo

No siempre basta con haber iniciado sesión durante el último mes. Puede considerarse activo quien realiza una operación relevante dentro de un periodo adecuado al proceso.

Por ejemplo:

• acceso semanal para una herramienta operativa diaria;
• acceso mensual para un sistema de reporting;
• uso trimestral para una herramienta administrativa periódica.

Detectar cuentas inactivas

Pueden pertenecer a personas que cambiaron de función, empleados que ya no están, usuarios de prueba o cuentas creadas preventivamente.

Comparar licencias con actividad

Si existen veinte licencias y solo ocho usuarios activos de forma sostenida, puede haber margen para reducir el plan sin retirar la aplicación.

Revisar licencias compartidas con cuidado

Reducir cuentas no debe llevar a compartir credenciales cuando la herramienta exige usuarios individuales o cuando esto perjudica trazabilidad y seguridad.

Analizar la frecuencia real de uso

La frecuencia ayuda a descubrir herramientas olvidadas, pero debe interpretarse junto con la criticidad.

Buscar datos objetivos

Las fuentes pueden incluir:

• logs de acceso;
• paneles administrativos;
• historial de actividad;
• registros del proveedor;
• telemetría local;
• documentos creados;
• operaciones realizadas;
• facturas o transacciones procesadas.

Medir durante un periodo representativo

Treinta días pueden ser suficientes para algunas aplicaciones y completamente insuficientes para otras con estacionalidad anual.

Buscar tendencias

Una herramienta que tenía actividad elevada hace un año y ahora apenas se utiliza puede haber sido desplazada por otro proceso sin que la suscripción se haya cancelado.

Considerar picos

Una aplicación puede concentrar casi todo su valor en determinados cierres, campañas o periodos.

Medir qué funciones se utilizan

El número de accesos no revela si la empresa está aprovechando aquello por lo que paga.

Relacionar plan contratado y funciones reales

Puede ocurrir que el plan superior se contratara por una característica que ya no se utiliza.

Detectar aplicaciones usadas para una sola función básica

Si una herramienta compleja se utiliza únicamente para compartir archivos, crear formularios sencillos o mantener una lista, puede haber alternativas ya disponibles.

Revisar módulos adicionales

Los complementos contratados deben evaluarse por separado. La aplicación principal puede ser necesaria y un módulo adicional no.

No forzar el uso de funciones para justificar el coste

“Ya que lo pagamos, usemos más cosas” no siempre es una buena estrategia. La pregunta correcta es si esas funciones resuelven necesidades reales mejor que las alternativas.

Relacionar cada aplicación con procesos de negocio

Una aplicación tiene sentido porque permite ejecutar uno o varios procesos.

Escribir qué proceso sostiene

Ejemplos:

• captación comercial;
• presupuestos;
• facturación;
• gestión de proyectos;
• soporte;
• almacén;
• documentación;
• comunicación interna.

Preguntar qué ocurriría si desapareciera

Las respuestas suelen caer en cuatro grupos:

• el proceso se detendría;
• se haría manualmente con un coste elevado;
• otra aplicación asumiría la función;
• prácticamente no ocurriría nada.

El último caso es una señal potente de infrautilización.

Detectar procesos desaparecidos

Algunas herramientas siguen contratadas porque nadie revisó que la actividad para la que se utilizaban dejó de existir.

Calcular el coste por uso útil

El coste anual adquiere más significado cuando se relaciona con actividad.

Si necesitas profundizar en todos los componentes económicos, conviene revisar cómo calcular el coste real de software. Para detectar infrautilización puede bastar con indicadores más sencillos.

Coste por usuario activo

Coste anual de la aplicación ÷ usuarios realmente activos.

Coste por operación

Coste anual ÷ operaciones relevantes realizadas.

Coste por hora ahorrada

En herramientas de automatización puede compararse el coste con las horas de trabajo que evita.

Interpretar, no aplicar umbrales universales

Un coste de 100 euros por operación puede ser absurdo para una tarea administrativa y excelente si evita una intervención externa de 2.000 euros.

Incluir mantenimiento

Una aplicación aparentemente gratuita puede tener un coste alto si exige muchas horas técnicas.

Detectar solapamientos funcionales

La infrautilización aparece con frecuencia cuando varias aplicaciones cubren funciones parecidas.

Construir un mapa de capacidades

En filas pueden situarse las aplicaciones y en columnas capacidades como:

• tareas;
• documentos;
• mensajería;
• formularios;
• calendario;
• CRM;
• automatización;
• informes;
• almacenamiento;
• videollamadas.

Buscar funciones repetidas

Tres herramientas pueden permitir crear tareas, pero solo una ser el sistema donde realmente se gestiona el trabajo.

Distinguir capacidad disponible de capacidad adecuada

Que dos aplicaciones puedan hacer lo mismo no significa que lo hagan con la misma calidad. Hay que valorar experiencia de usuario, integraciones, permisos y fiabilidad.

Detectar software adquirido por una función que ahora ya existe en otro sistema

Las suites evolucionan. Una función que antes requería un producto independiente puede haberse incorporado a otra aplicación que la empresa ya paga.

Comprobar qué datos dependen de la aplicación

Una herramienta puede parecer prescindible hasta que se descubre que contiene años de información histórica.

Identificar datos únicos

Pregunta qué información existe exclusivamente allí.

Comprobar exportación

Antes de considerar una retirada conviene verificar si los datos pueden recuperarse en un formato utilizable.

Separar necesidad de datos y necesidad de aplicación

Puede ser necesario conservar el histórico y no seguir pagando la herramienta. En algunos casos es posible exportar, archivar y mantener la información de otra forma.

Revisar obligaciones de conservación

Determinados datos pueden necesitar mantenerse por razones legales, contractuales u operativas aunque la aplicación deje de utilizarse.

Revisar integraciones y dependencias ocultas

Una aplicación con pocos usuarios puede realizar trabajo automático importante.

Buscar APIs y conectores

Puede alimentar informes, mover datos, generar documentos o participar en automatizaciones sin que nadie abra su interfaz.

Revisar cuentas técnicas

Un usuario aparentemente inactivo puede ser una identidad utilizada por una integración.

Buscar webhooks, scripts y tareas programadas

La dependencia puede estar fuera de la propia aplicación.

Comprobar autenticación

Algunas herramientas funcionan como proveedor de identidad para otras. Retirarlas sin saberlo puede bloquear accesos.

Mapear la dependencia antes de clasificar como innecesaria

La ausencia de uso humano visible no demuestra falta de utilidad.

Distinguir uso escaso de falta de valor

Este es uno de los puntos más importantes de la auditoría.

Herramientas de emergencia

Software de recuperación, diagnóstico o continuidad puede no utilizarse durante meses y ser valioso cuando ocurre una incidencia.

Herramientas periódicas

Procesos anuales, trimestrales o estacionales justifican patrones de uso bajos.

Aplicaciones que reducen riesgo

Un sistema de copias, seguridad o auditoría no debe valorarse únicamente por cuántas veces interactúa un usuario con él.

Aplicaciones de cumplimiento

Pueden responder a necesidades que no generan actividad cotidiana.

Valorar impacto si no estuviera disponible

La pregunta útil es cuánto costaría no tenerla en el momento en que fuese necesaria.

Detectar licencias sobredimensionadas

La aplicación puede ser útil y el contrato estar infrautilizado.

Exceso de usuarios

La situación más evidente es pagar cuentas que nadie utiliza.

Plan demasiado alto

Puede haberse elegido por almacenamiento, número de automatizaciones o una función que ya no se necesita.

Complementos abandonados

Módulos que se probaron durante unos meses pueden seguir facturándose.

Capacidad reservada no utilizada

Algunos servicios cobran por volumen, almacenamiento o recursos contratados aunque no se consuman.

Revisar antes de cada renovación

La fecha de renovación es un buen punto de control para ajustar el contrato con datos de uso reales.

Localizar aplicaciones fuera del inventario oficial

El denominado shadow IT aparece cuando personas o departamentos adoptan herramientas sin incorporarlas al control tecnológico general.

Por qué ocurre

Normalmente porque resuelven una necesidad rápidamente, la herramienta oficial resulta incómoda o registrarse con una tarjeta es muy sencillo.

Por qué importa para la infrautilización

Puede haber dos aplicaciones oficiales poco utilizadas porque el trabajo real se ha desplazado a una tercera que nadie había inventariado.

Buscar señales

• cargos pequeños recurrentes;
• inicios de sesión corporativos en servicios externos;
• archivos compartidos desde plataformas desconocidas;
• automatizaciones creadas por usuarios;
• encuestas internas;
• extensiones y aplicaciones autorizadas.

No convertir la revisión en una caza de culpables

Las herramientas no oficiales suelen revelar necesidades que el ecosistema actual no está resolviendo bien.

Preguntar a los usuarios sin depender solo de opiniones

Los datos de uso necesitan contexto humano.

Preguntas concretas

Es más útil preguntar “¿qué tarea haces con esta aplicación y qué alternativa utilizarías si no existiera?” que “¿te gusta esta herramienta?”.

Identificar funciones críticas

Una persona puede utilizar una característica pequeña que no aparece claramente en las métricas pero resulta esencial para su proceso.

Detectar resistencia por costumbre

“Siempre lo hemos hecho así” no demuestra valor. Conviene identificar qué consecuencia real tendría cambiar.

Detectar falsa infrautilización por falta de formación

Una herramienta puede estar mal aprovechada porque nadie sabe utilizarla. En ese caso, la decisión puede ser formar, simplificar o sustituir.

Contrastar opinión con evidencia

Una persona puede percibir que utiliza una aplicación constantemente cuando los registros muestran dos accesos mensuales. Ambas fuentes de información ayudan a entender el proceso.

Clasificar aplicaciones según evidencia

Después de recopilar información, puede utilizarse una clasificación sencilla.

Mantener

Aplicación con uso y valor claros, coste razonable y función diferenciada.

Optimizar

La herramienta aporta valor, pero existen licencias, módulos o recursos sobrantes.

Reactivar o formar

Existe una capacidad útil que no se aprovecha por desconocimiento o implantación incompleta.

Consolidar

Sus funciones pueden trasladarse razonablemente a otra aplicación ya utilizada.

Sustituir

El proceso sigue siendo necesario, pero la herramienta actual ofrece mala relación entre coste, uso o mantenimiento.

Retirar

El proceso ha desaparecido, existe una alternativa suficiente o el valor es claramente inferior al coste y complejidad.

Investigar

No hay información suficiente para decidir. Es mejor mantener provisionalmente que retirar a ciegas.

Probar la retirada antes de eliminar

Una aplicación identificada como candidata no debería cancelarse impulsivamente.

Congelar nuevas altas

Puede dejar de incorporarse información nueva mientras se observa si el proceso continúa correctamente en otro sistema.

Reducir usuarios primero

En algunos casos es posible mantener una licencia administrativa mientras se retiran cuentas ordinarias.

Exportar datos

Debe comprobarse la integridad y utilidad de la exportación antes de cancelar el acceso.

Desactivar integraciones controladamente

Hay que verificar qué procesos dejan de recibir datos.

Definir periodo de observación

Durante varias semanas puede registrarse si alguien necesita recuperar la herramienta.

Conservar plan de reversión

Si aparece una dependencia no detectada, debe existir una forma de recuperar temporalmente el servicio.

Indicadores para repetir la revisión periódicamente

La auditoría no debería realizarse únicamente cuando el presupuesto obliga a recortar.

Porcentaje de licencias activas

Usuarios activos ÷ licencias contratadas × 100.

Coste por usuario activo

Permite detectar planes sobredimensionados.

Coste por operación relevante

Ayuda en aplicaciones vinculadas a transacciones concretas.

Días desde la última actividad

Útil como alerta inicial, no como criterio definitivo.

Número de funciones realmente utilizadas

Puede compararse con las capacidades que justifican el plan contratado.

Número de aplicaciones por proceso

Un crecimiento continuo puede indicar fragmentación.

Aplicaciones sin responsable

Deberían revisarse prioritariamente.

Renovaciones próximas sin revisión

Un calendario de contratos evita que las suscripciones se renueven automáticamente sin evaluación.

Procedimiento práctico paso a paso

1. Crear el inventario

Reúne aplicaciones de pago, gratuitas, locales y servicios contratados directamente por usuarios.

2. Asignar proceso y responsable

Cada aplicación debe tener una función empresarial explicable.

3. Recoger costes y renovaciones

Incluye suscripción, módulos, usuarios y mantenimiento relevante.

4. Medir actividad

Obtén usuarios activos, frecuencia y operaciones durante un periodo representativo.

5. Revisar funciones utilizadas

Comprueba si el plan contratado corresponde al uso real.

6. Mapear solapamientos

Identifica capacidades cubiertas también por otras herramientas.

7. Revisar datos e integraciones

Busca dependencias invisibles antes de considerar una aplicación prescindible.

8. Hablar con usuarios clave

Contrasta métricas con el proceso real.

9. Clasificar

Mantener, optimizar, formar, consolidar, sustituir, retirar o investigar.

10. Actuar primero sobre casos claros

Licencias inactivas, módulos abandonados y herramientas sin uso ni dependencias suelen ofrecer mejoras de bajo riesgo.

11. Probar antes de retirar

Exporta datos, reduce accesos y observa dependencias.

12. Repetir periódicamente

Una revisión semestral o asociada a renovaciones puede evitar que la acumulación vuelva a crecer.

Errores frecuentes

Cancelar solo porque nadie inició sesión recientemente

Puede tratarse de una herramienta estacional, automática o de emergencia.

Medir número de usuarios y olvidar funciones automáticas

Las APIs y procesos en segundo plano también generan valor.

Conservar software porque “algún día puede hacer falta”

Si no existe un escenario concreto y razonable, ese argumento puede perpetuar aplicaciones obsoletas.

Intentar justificar planes caros usando más funciones

El objetivo es resolver necesidades, no aumentar artificialmente la utilización.

Eliminar antes de exportar los datos

Puede convertir un ahorro pequeño en una pérdida de información importante.

No revisar renovaciones automáticas

Muchos costes innecesarios sobreviven simplemente porque nadie mira el contrato antes de renovarse.

Confundir infrautilización con mala implantación

Si la herramienta es adecuada pero nadie fue formado o el proceso no se adaptó, la solución puede ser distinta de retirarla.

Mirar solo el precio

Una aplicación barata puede introducir mucha complejidad; una cara puede ser crítica y rentable.

Conclusión

Detectar aplicaciones infrautilizadas no consiste en buscar iconos que nadie abre y empezar a cancelar suscripciones. Consiste en entender qué valor produce cada herramienta en relación con el coste y la complejidad que introduce.

La evidencia debe combinar usuarios activos, frecuencia, funciones utilizadas, procesos asociados, coste, datos, integraciones y criticidad. Solo así puede distinguirse una aplicación realmente infrautilizada de otra que se utiliza pocas veces pero resulta esencial.

Muchas oportunidades no requieren retirar completamente una herramienta. Reducir licencias, bajar de plan, cancelar módulos o trasladar una función secundaria puede producir ahorro con mucho menos riesgo.

Cuando una aplicación sí resulta prescindible, la retirada debe llegar después del análisis: primero se comprueban los datos, las integraciones, los usuarios y las alternativas; después se realiza una prueba controlada.

Una empresa pequeña obtiene una ventaja importante cuando conoce qué software utiliza realmente. Reduce costes, cuentas, permisos, duplicidades y conocimiento disperso. Y, sobre todo, evita que su ecosistema tecnológico crezca por inercia.

El objetivo no es utilizar menos aplicaciones a cualquier precio, sino que cada aplicación que permanezca tenga una función clara y un valor demostrable.

Preguntas frecuentes