En el segundo trimestre de 2026, el 65% de las licencias SaaS analizadas por Vertice estaban inutilizadas o subutilizadas. La cifra obliga a revisar una premisa habitual de la transformación digital: adquirir más tecnología no significa necesariamente aumentar la capacidad de una empresa. Antes de autorizar la siguiente aplicación, licencia o agente de inteligencia artificial, conviene determinar cuánto valor está produciendo la tecnología que ya estamos pagando.
Durante años, buena parte de la transformación digital se ha construido alrededor de una pregunta aparentemente razonable: ¿qué software necesitamos comprar? Un CRM para ordenar las ventas, una plataforma financiera para controlar la operación, herramientas de automatización para reducir trabajo manual, analítica para entender los datos y, más recientemente, inteligencia artificial para ampliar la productividad. Cada necesidad empresarial parece encontrar rápidamente una aplicación dispuesta a resolverla.
El problema comienza cuando adquisición y creación de valor se tratan como si fueran equivalentes. Comprar una capacidad tecnológica no significa utilizarla; utilizarla tampoco significa adoptarla correctamente; y registrar actividad dentro de una plataforma no demuestra que la inversión esté produciendo un resultado empresarial que justifique su costo. Los datos recientes sobre utilización de SaaS permiten observar la magnitud económica de esta diferencia.
El 65% que obliga a revisar la economía del software
Vertice reportó que, al segundo trimestre de 2026, 65% de las licencias SaaS analizadas estaban completamente inutilizadas o subutilizadas. El desglose ayuda a entender el problema: 14% estaban totalmente sin utilizar y 51% se encontraban subutilizadas. Vertice define esta última categoría como herramientas en las que menos de la mitad de las licencias adquiridas están siendo utilizadas. La compañía señala que estos datos derivan de más de US$75 mil millones de gasto global procesado durante 2026.
Una segunda fuente confirma que el desperdicio de licencias no es un fenómeno aislado, aunque utiliza una metodología diferente. El 2026 SaaS Management Index de Zylo, construido a partir de más de 40 millones de licencias y US$75 mil millones de gasto bajo gestión, encontró que las organizaciones dejan en promedio 36% de sus licencias SaaS sin utilizar. No sería correcto enfrentar ese 36% con el 65% de Vertice como si midieran exactamente lo mismo: Vertice incorpora inutilización y subutilización conforme a sus criterios, mientras Zylo reporta licencias sin uso bajo su propia metodología. Lo relevante es que dos conjuntos de datos independientes y de gran escala documentan una misma condición: una parte considerable de la capacidad tecnológica contratada no se aprovecha.
Esta parte merece una revisión detenida porque modifica la naturaleza del problema. El shelfware no es solamente una aplicación que alguien olvidó abrir. Desde la perspectiva financiera, representa capital asignado a una capacidad que no está produciendo en la medida esperada. Cuando esa situación se replica entre aplicaciones, usuarios, departamentos y renovaciones, deja de ser una incidencia de TI y puede convertirse en una fuga estructural de margen.
Una licencia con descuento puede seguir siendo una mala inversión
Las conversaciones sobre compra de software suelen concentrarse en precio por usuario, descuento, funcionalidades incluidas, nivel de edición y ahorro frente a contratar productos por separado. Son variables necesarias para negociar correctamente, pero ninguna responde por sí sola a la pregunta económica principal: ¿qué capacidad obtiene realmente el negocio a cambio de ese gasto?
Una empresa puede negociar un excelente descuento y seguir desperdiciando dinero. Puede adquirir una suite con decenas de aplicaciones y utilizar sólo una parte. Puede disponer de un CRM técnicamente sofisticado y continuar perdiendo oportunidades porque el equipo comercial no mantiene la información, porque los indicadores no representan el proceso real o porque la forma de vender nunca fue traducida correctamente al sistema. Del mismo modo, una organización puede incorporar inteligencia artificial y terminar agregando nuevas suscripciones sobre procesos que siguen siendo deficientes.
Por eso es necesario separar costo tecnológico de valor tecnológico. El primero aparece claramente en una factura. El segundo tiene que observarse en la operación mediante adopción, productividad, reducción de fricción, calidad de información, velocidad de ejecución, control y contribución a indicadores relevantes del negocio. El número de aplicaciones activadas puede describir un proyecto; difícilmente demuestra por sí solo su retorno.
Los incentivos de quien recomienda forman parte de la decisión
Para comprender completamente la economía de una adquisición tecnológica hay otro tema que no debemos dejar pasar sin revisar: cómo gana dinero quien recomienda la arquitectura.
La industria del software se apoya legítimamente en fabricantes, distribuidores, resellers, partners, integradores y consultores. Estos ecosistemas permiten que las plataformas lleguen a más empresas y que especialistas desarrollen conocimiento profundo para implementarlas. Un buen partner puede aportar muchísimo valor y, en determinados proyectos, ser exactamente la alternativa que una empresa necesita.
Al mismo tiempo, el canal tiene una estructura económica que el comprador debería conocer. Zoho documenta públicamente programas en los que existen comisiones vinculadas con compras y renovaciones; por ejemplo, su política pública para partners de Zoho Creator muestra porcentajes de comisión asociados al volumen y al plazo del contrato, mientras otros programas de la compañía también describen comisiones para partners.
Estos hechos no demuestran que un partner recomiende software innecesario. Sería incorrecto extraer esa conclusión. Tampoco convierten el modelo de canal en algo negativo: una comisión puede remunerar legítimamente la adquisición, atención y desarrollo de una cuenta. Lo que sí demuestran es que existe un incentivo económico que debe incorporarse al análisis de compra. Si una organización considera normal examinar conflictos potenciales de interés en inversiones, auditoría, adquisiciones o servicios financieros, resulta razonable aplicar una disciplina similar a decisiones tecnológicas que pueden comprometer presupuesto durante años.
La pregunta no debería ser si un partner es bueno o malo. Una pregunta mucho más útil es: ¿cómo gana dinero quien me está recomendando esta inversión y de qué manera se asegura que su recomendación esté alineada con la economía de mi empresa?
Un ejercicio con inteligencia artificial mostró cómo comienza el problema
Durante la preparación de este análisis realizamos un ejercicio exploratorio con una IA generativa. Planteamos el caso hipotético de una empresa mexicana de servicios con 40 empleados y 20 vendedores que buscaba una arquitectura e implementación de Zoho CRM. La conversación avanzó rápidamente hacia ediciones de CRM, aplicaciones complementarias, Zoho One, fases de implementación, rangos de inversión y una lista de posibles partners.
Las recomendaciones podían ser razonables. Zoho One podría incluso resultar ser la arquitectura correcta para una organización de ese perfil. Lo importante para este análisis fue observar la información que todavía no teníamos cuando ya estábamos discutiendo soluciones: no conocíamos qué software utilizaba la empresa, cuánto pagaba, qué porcentaje estaba adoptado, qué funcionalidades permanecían sin uso, dónde existían duplicidades, qué calidad tenían sus datos ni qué fricciones ocurrían realmente entre ventas, entrega, facturación y cobranza.
Cuando posteriormente pedimos a la misma IA comparar un partner tradicional con una consultoría de arquitectura de negocio como Zherpa, el marco de la conversación cambió. En lugar de concentrarse solamente en qué configurar, comenzó a considerar procesos, datos, gobierno, adopción y resultados. El ejercicio no constituye evidencia científica ni utilizamos las afirmaciones de la IA como hechos sobre Zherpa. Su utilidad es otra: muestra cómo la forma de plantear la pregunta condiciona el espacio de soluciones que examinamos.
Si preguntamos “¿qué CRM necesito?”, comenzaremos comparando CRM. Si preguntamos “¿qué aplicaciones debería contratar?”, comenzaremos buscando aplicaciones. Pero si la pregunta es “¿qué está impidiendo que esta empresa venda, entregue, cobre y decida mejor?”, el análisis necesariamente se amplía antes de seleccionar tecnología.
La arquitectura de negocio invierte el orden de la conversación
Zherpa comienza desde esta segunda perspectiva. Antes de decidir qué aplicación debe incorporarse, buscamos comprender cómo la empresa crea y captura valor: cómo vende, cómo opera, cómo entrega, cómo factura, cómo cobra, cómo utiliza sus datos y cómo convierte esa información en decisiones. Después puede evaluarse qué arquitectura tecnológica necesita sostener esa operación.
La conclusión puede ser ampliar Zoho, incorporar una integración, desarrollar una aplicación específica, automatizar determinados procesos o desplegar capacidades de inteligencia artificial. También puede ocurrir que la organización ya posea buena parte de la tecnología necesaria y que el problema esté en la adopción, la configuración, la arquitectura de datos, la integración entre áreas o el diseño del proceso. En otros casos, el análisis puede identificar aplicaciones redundantes o licencias que deberían reducirse, reasignarse o eliminarse.
Esto no significa que una consultoría independiente deba recomendar siempre menos tecnología. Esa sería simplemente otra forma de sesgo. La independencia adquiere valor cuando permite recomendar más, menos o diferente tecnología según la evidencia del negocio.
Zherpa no comienza vendiendo licencias
Zherpa Digital Systems es una firma independiente de arquitectura de negocio e implementación. Su trabajo integra estrategia, procesos, Zoho, CRM, automatización, datos e inteligencia artificial gobernada para convertir inversión tecnológica en capacidad operativa y resultados que puedan medirse. Su posicionamiento no es el de un vendedor de licencias ni el de un Partner oficial de Zoho; la independencia de criterio forma parte de la manera en que aborda una arquitectura tecnológica.
Eso tampoco significa estar contra Zoho. Zherpa tiene más de dos décadas de experiencia en su ecosistema y la plataforma puede ocupar un lugar central en la arquitectura de muchas empresas. La diferencia está en el orden de prioridades: el negocio determina la arquitectura y la arquitectura determina qué tecnología tiene sentido utilizar.
El Método Nautilius proporciona el marco metodológico para mantener esa conversación orientada hacia creación de valor. Nautilius es la metodología; Zherpa la implementa. Zoho, CRM, automatización, datos e inteligencia artificial son instrumentos que pueden formar parte de la solución, pero ninguno constituye por sí mismo la promesa final. El objetivo es que la inversión tecnológica se traduzca en una capacidad que la organización utilice, pueda gobernar y tenga posibilidades reales de medir.
Este criterio también impone una disciplina sobre Zherpa. Si una herramienta no justifica su lugar dentro de la arquitectura, debe cuestionarse. Si una licencia no produce capacidad suficiente, debe revisarse. Si la inversión adicional no puede vincularse razonablemente con una necesidad empresarial, la recomendación responsable puede ser optimizar primero lo que ya existe.
La era agentiva aumenta la importancia de esta disciplina
El problema adquiere otra dimensión con la aceleración de la inteligencia artificial. El índice 2026 de Zylo encontró que el gasto en aplicaciones nativas de IA aumentó 108% interanual en el conjunto de organizaciones analizadas. La presión competitiva por incorporar copilotos, asistentes y agentes está acelerando la adquisición de nuevas capacidades y hace más importante revisar la arquitectura completa antes de multiplicar herramientas.
Copilotos, asistentes y agentes pueden entrar en una organización desde múltiples departamentos, incorporarse como funciones adicionales de plataformas existentes o contratarse directamente para resolver necesidades locales. Cada decisión individual puede tener sentido y, al mismo tiempo, producir colectivamente una arquitectura fragmentada cuyo costo, riesgo y contribución sean difíciles de observar.
La consecuencia para la era agentiva es importante. Si las empresas ya tienen dificultades para aprovechar plenamente licencias de software relativamente pasivas, la disciplina debe aumentar cuando la tecnología empieza a ejecutar trabajo. Un agente puede consultar información, actualizar sistemas, comunicarse, generar documentos, activar procesos o intervenir en decisiones. La pregunta deja de ser solamente cuánto cuesta su licencia y pasa a incluir qué trabajo realiza, con qué información, dentro de qué permisos, quién supervisa su actuación y qué resultado justifica mantenerlo.
Zherpa aborda estas capacidades desde un principio de IA gobernada: propósito, permisos, límites, trazabilidad, escalamiento y responsabilidad humana. La intención no es desplegar el mayor número posible de agentes, sino integrar capacidades de IA en procesos reales donde exista un trabajo definido y una contribución que pueda observarse.
El shelfware de la era agentiva puede resultar más costoso que una licencia olvidada. Además del gasto, una capacidad autónoma mal integrada puede introducir duplicidad, decisiones inconsistentes, problemas de datos y nuevos riesgos de gobierno. Diseñar la arquitectura antes de multiplicar agentes deja de ser una cuestión de elegancia tecnológica y se convierte en una disciplina empresarial.
¿Cuándo tiene sentido un partner y cuándo una arquitectura independiente?
Una comparación seria también debe reconocer que Zherpa no es necesariamente la respuesta adecuada para todos los proyectos. Si una empresa tiene procesos maduros, requerimientos claramente documentados, buena calidad de datos y sólo necesita configurar o extender rápidamente una aplicación específica, un partner especializado o los servicios profesionales del fabricante pueden ofrecer conocimiento de producto y velocidad de ejecución muy valiosos.
Una consultoría de arquitectura de negocio exige una inversión diferente. Requiere diagnóstico, participación de la dirección y de personas que conocen la operación, acceso a información suficiente para cuestionar supuestos y disposición para revisar procesos antes de automatizarlos. Puede implicar mayor esfuerzo inicial que una implementación limitada a configuración, migración y capacitación. También existe un riesgo de sobreingeniería si se aplica una profundidad de análisis que el problema no requiere.
Zherpa adquiere mayor sentido cuando la pregunta es más amplia que la herramienta: cuando ventas, operación, servicio y finanzas necesitan conectarse; cuando el CRM está funcionando técnicamente pero no ayuda suficientemente a dirigir; cuando existen datos pero la dirección no confía en ellos; cuando las automatizaciones crecieron sin una arquitectura común; cuando nadie puede explicar con suficiente evidencia qué parte del gasto tecnológico produce valor; o cuando la organización quiere incorporar IA y agentes sin perder control sobre procesos y decisiones.
En esas situaciones, comparar únicamente el precio de implementación puede producir una decisión incompleta. También habría que considerar el costo de mantener procesos deficientes, duplicidades tecnológicas, baja adopción, trabajo manual innecesario y decisiones construidas sobre información que la dirección no considera confiable.
De contar aplicaciones a medir capacidad
La transformación digital ha utilizado durante años indicadores de actividad: aplicaciones implementadas, usuarios habilitados, integraciones terminadas, automatizaciones creadas y, ahora, agentes desplegados. Son métricas útiles para administrar un proyecto, pero ninguna demuestra por sí sola que la empresa haya creado valor.
La dirección necesita conectar esa actividad con consecuencias empresariales. Una implementación debería poder analizarse en términos de disciplina comercial, productividad, reducción de fricción, calidad de información, control operativo, velocidad, experiencia del cliente o cualquier otro indicador que haya justificado originalmente la inversión. La métrica concreta dependerá del problema; lo que no debería cambiar es la obligación de establecer la conexión entre tecnología y resultado.
Desde esa perspectiva, una pregunta resume bien el criterio económico que proponemos: ¿cuánta capacidad empresarial estamos obteniendo por cada peso comprometido en tecnología?
No se trata de buscar siempre la alternativa más barata. Una arquitectura más costosa puede ser una excelente inversión si produce una capacidad proporcionalmente superior, reduce riesgos relevantes o permite construir una plataforma de crecimiento que la empresa necesita. De la misma manera, una herramienta barata puede resultar costosa cuando añade complejidad, permanece infrautilizada o no modifica ningún resultado importante.
Lo que debe determinar la arquitectura es la economía del negocio, no la economía del canal.
Antes de la próxima renovación, conviene auditar algo más que el precio
Cuando llegue la siguiente renovación, ampliación de usuarios o propuesta para incorporar inteligencia artificial, la empresa puede comenzar por revisar qué tecnología está pagando, quién la utiliza, qué capacidades permanecen ociosas, qué herramientas se superponen y qué resultados pueden vincularse razonablemente con esa inversión. Después tendrá mejores elementos para determinar si necesita adquirir algo nuevo o si existe más valor disponible dentro de lo que ya tiene.
En esa revisión también conviene incorporar los incentivos del proveedor, del fabricante, del partner y del consultor. Conocer cómo gana dinero cada participante no invalida su recomendación; proporciona contexto para evaluarla. La transparencia de incentivos es compatible con una relación comercial sana y ayuda a que la dirección conserve el criterio sobre una decisión que finalmente afecta a su propio capital.
El resultado de la auditoría puede ser aumentar la inversión. Puede ser migrar a una suite más amplia, incorporar automatización, rediseñar procesos o desplegar agentes de IA. También puede conducir a consolidar aplicaciones, reducir usuarios, reasignar licencias o retirar tecnología que dejó de justificar su costo. La calidad de una arquitectura se demuestra, en parte, por su capacidad de aceptar cualquiera de esas conclusiones cuando la evidencia la respalda.
Antes de comprar más, determine qué debería producir lo que ya tiene
El Diagnóstico Zherpa comienza desde el negocio. Examina procesos, operación, datos, tecnología y oportunidades de automatización para identificar fricciones y fugas de valor antes de decidir cuál debería ser la siguiente inversión.
No parte de la premisa de que una empresa necesita más software. Tampoco supone que necesariamente necesita menos. Busca establecer qué arquitectura necesita la organización para ampliar su capacidad de ejecución con control, continuidad y retorno medible.
Para una empresa que está evaluando una renovación importante, una nueva arquitectura Zoho o la incorporación de agentes de inteligencia artificial gobernados, esa revisión puede realizarse antes de comprometer el siguiente presupuesto.
Diagnostique primero. Decida después qué tecnología merece su inversión.
