- La desviación en las suscripciones es un aumento no autorizado en el conjunto de derechos de software entre una renovación y la siguiente; no existe un momento concreto en el que se compare el total acumulado con las necesidades reales.
- Según los resultados del tercer trimestre del ejercicio fiscal 2026 (el último trimestre del que se dispone de datos), Synopsys obtiene actualmente alrededor del 60 % de sus ingresos por productos a través de licencias de tipo suscripción basadas en el tiempo, frente al 40 % que procede de pagos por adelantado.
- Las familias de productos modulares son las que presentan una mayor exposición a la deriva —TestMAX de Synopsys (DFT, ATPG, Diagnosis, Manager, Advisor, ALE) y Calibre de Siemens EDA (nmDRC, nmLVS, PERC, Auto-Waivers, SONR, Fab Insights)—, mientras que las herramientas de un solo núcleo, como Design Compiler, se adaptan al ritmo de salida a producción en lugar de sufrir la deriva.
Cuando un equipo de diseño de semiconductores solicita un módulo TestMAX DFT más para cumplir con el plazo de entrega, la solicitud parece insignificante y se aprueba en cuestión de minutos: una simple partida en la cartera de software de Synopsys. La fase finaliza, el módulo sigue asignado y liberarlo no es tarea específica de nadie. Si multiplicamos ese patrón por un puñado de fondos de licencias compartidas que dan servicio a varios miles de ingenieros, una organización de diseño puede acabar sumando dos docenas de puestos flotantes en un año que nadie ha aprobado individualmente ni revisado colectivamente: una acumulación que acaba apareciendo en la factura de renovación.
Cuando un equipo de diseño de semiconductores solicita un módulo TestMAX DFT más para cumplir con el plazo de entrega del diseño, la solicitud parece insignificante y se aprueba en cuestión de minutos: una simple partida en la cartera de software de Synopsys. La fase finaliza, el módulo sigue asignado y liberarlo no es tarea específica de nadie. Si multiplicamos ese patrón por un puñado de fondos de licencias compartidas que dan servicio a varios miles de ingenieros, una organización de diseño puede acabar sumando dos docenas de puestos flotantes en un año que nadie ha aprobado individualmente ni nadie ha revisado colectivamente: una acumulación que acaba reflejándose en la factura de renovación.
La deriva de las suscripciones es el aumento lento y no autorizado del número de licencias de software entre una renovación y la siguiente. Se añade una licencia por aquí, otra por allá, y nadie lo revisa antes de que vuelva a llegar el plazo de renovación o mantenimiento. Cada cambio se aprueba por sí solo. Nadie comprueba el total de los doce meses. El número de licencias varía a lo largo de todo el año. La primera vez que alguien ve el total es al recibir la factura de renovación.
En el sector del diseño de semiconductores, esto se aprecia con mayor rapidez en las familias de herramientas que comparten dos características: suelen venderse mediante renovaciones —Synopsys, por ejemplo, obtiene actualmente alrededor del 60 % de sus ingresos por productos a través de licencias de tipo suscripción con vencimiento temporal, frente al 40 % de pagos por adelantado, según sus últimos resultados trimestrales— y se dividen en numerosos módulos con licencias independientes, en lugar de constituir un único producto global.
La suite TestMAX de Synopsys para el diseño orientado a pruebas —dividida en DFT, ATPG, diagnóstico y varios otros productos complementarios— es un entorno en el que resulta mucho más fácil perder la noción de lo que aún se necesita que Design Compiler, la herramienta de síntesis de un solo núcleo que casi todos los equipos de diseño digital utilizan a diario. Adquirir un módulo más de TestMAX para una fase del proyecto es una decisión menor y justificable en cada ocasión. Desinstalarlo una vez finalizada esa fase no es tarea de nadie en concreto.
En una organización de diseño que gestiona sus grupos compartidos con varios miles de ingenieros, dos puestos adicionales al mes pueden parecer insignificantes. Si los sumamos a lo largo de un año, el grupo ha crecido en dos docenas de puestos que nadie ha autorizado de forma individual, y esa operación aritmética se lleva a cabo silenciosamente en segundo plano en casi todos los entornos de diseño con múltiples sedes.
Un fondo común de licencias flotante no incumple ninguna norma
Al acercarse la fecha límite de «tapeout», se asigna un módulo de testabilidad temprana a una fase del proyecto, junto con la herramienta DFT básica que el equipo ya utiliza de forma continua. El módulo cumple con el plazo, la fase finaliza y la licencia sigue registrada: nadie se encarga de liberarla. Un conjunto de licencias de «diseño para pruebas» que se amplió hace dos años para un programa nunca se reduce de nuevo. Cada paso es pequeño, está documentado y es justificable por sí mismo.
Lo que falta es una visión global que abarque todas las etapas. En la mayoría de los flujos de trabajo no se comprueba si las incorporaciones de este año, en su conjunto, siguen teniendo sentido en comparación con la referencia del año pasado —y mucho menos si un módulo adicional concreto se sigue utilizando siquiera—. El registro muestra lo que se aprobó, pero no muestra lo que se ha ido acumulando, ni lo que dejó de utilizarse discretamente una vez finalizada la fase que lo justificaba.
Para una empresa de diseño que gestiona licencias de EDA en múltiples sedes —a menudo, varios miles de ingenieros que comparten un puñado de recursos comunes para síntesis, DFT y diseño—, esa brecha se agrava rápidamente. Un equipo de diseño de una sede puede solicitar un módulo DFT adicional sin saber qué han añadido ya otras dos sedes en el mismo trimestre, ni si alguna de ellas sigue utilizando el módulo del año pasado.
Por qué el informe habitual no lo detecta
La mayoría de los informes sobre licencias muestran lo que se ha activado, no lo que se ha utilizado realmente. Esa distinción es importante: la activación confirma que se ha reservado una licencia, pero no confirma que alguien haya trabajado con la herramienta durante la hora, el día o el trimestre siguientes.
La solución más habitual para esto en el ámbito de la gestión de licencias es una regla de recuperación automática: liberar una licencia automáticamente una vez que ha estado en uso y permanece inactiva durante un tiempo de espera establecido. Esto resuelve el caso más sencillo: una licencia que se ha dejado abierta durante la noche sin que se haya producido ninguna actividad en ella. Sin embargo, sigue deduciendo la actividad a partir del tiempo de uso, en lugar de medirla.
La deriva en los derechos de acceso supera fácilmente esa brecha. Una licencia añadida en marzo y que apenas se ha utilizado desde entonces sigue apareciendo como una licencia normal y en uso en cualquier informe elaborado únicamente a partir de los registros de uso y los temporizadores de inactividad. La cifra parece correcta. Nadie ha analizado el uso que hay detrás.
Aspectos que conviene comprobar antes de tu próxima renovación
| Firma | Lo que suele significar |
|---|---|
| El fondo común de licencias de síntesis, DFT o diseño ha ido creciendo a lo largo de varios ciclos de renovación sin que nadie haya aprobado el importe total | Las adiciones se revisaron una por una; la suma en sí nunca se revisó. |
| Los informes de tiempo de inactividad indican un buen nivel de utilización, pero nadie puede precisar quién está ejecutando realmente tareas en puestos concretos. | Una vista que combina el proceso de pago con un temporizador no supone un uso activo: el informe responde a una pregunta equivocada |
| Una renovación se adapta al «uso actual» sin que nadie tenga que actualizar primero los valores de referencia. | Fuga en la renovación: la desviación de este año se convierte en el mínimo de año que viene |
| Los equipos de cada centro o programa solicitan plazas adicionales sin saber cuántas han añadido ya los demás centros | El exceso de aprovisionamiento se acumula a nivel local y de forma invisible |
Dos formas de reducir la brecha
La mayoría de las opciones de esta categoría resuelven el primer problema de la misma manera. Donde difieren —y donde, concretamente, se cuela la pérdida de suscriptores— es en lo que ocurre a continuación.
El enfoque habitual se basa en el registro del servidor de licencias: disponibilidad en tiempo real que muestra quién ocupa una licencia en ese momento, seguimiento de los rechazos para saber a quién se le ha denegado el acceso y cuándo, asignación de costes desglosada por departamento o proyecto, y una regla de recuperación automatizada que libera una licencia una vez que ha permanecido inactiva durante un tiempo de espera establecido. Algunas plataformas de esta categoría también añaden una capa de optimización de suscripciones para la reasignación de licencias en la nube, aunque se trata de un mecanismo independiente de la recuperación de licencias EDA.
Todo eso es capacidad real y detecta un desperdicio real: una licencia que nadie se acordó de liberar, un patrón de denegación que justifica (o no) la compra de más capacidad, una sede que paga discretamente por licencias que nadie abre allí. Nada de eso te indica si realmente se está trabajando en una licencia actualmente ocupada; todo ello sigue partiendo de los mismos datos de registro de inicio y tiempo de inactividad. Una plaza de síntesis a la que se accede durante dos minutos cada veinte, lo justo para reiniciar el temporizador de inactividad, aparece como activa todo el tiempo, independientemente de cuántos módulos haya en ese mismo registro.
| Lo que hay que aclarar antes de la renovación | El enfoque habitual | Open iT (Nivel 1 + Nivel 2) |
|---|---|---|
| ¿Está ocupado este asiento en este momento? ¿Y quién lo ocupa? | Sí | Sí |
| ¿Se rechazó a alguien y, en caso afirmativo, cuándo? | Sí – seguimiento de denegaciones | Sí – Informes de denegación de nivel 1 |
| ¿A qué centro o unidad de negocio corresponde este coste? | Sí | Sí |
| ¿Ha estado este asiento desocupado el tiempo suficiente como para que se libere automáticamente? | Sí, con respecto a un tiempo de espera fijo para el modo de inactividad | Sí, se ha correlacionado con la inactividad medida, en lugar de solo con el reloj. |
| ¿La persona que ocupa este puesto está trabajando en él en este momento? | No — deducido a partir del proceso de pago y la frecuencia de reposo, no medido | Sí: actividad del teclado, el ratón, la CPU y las E/S medida en el terminal, a través del informe «Work Ratio Report» |
| ¿Acaso las incorporaciones de este año —aprobadas una a una, sitio por sitio— conformaban un conjunto que nadie había analizado antes de la renovación? | No: cada informe es en tiempo real o por centro; ningún dato se acumula con respecto a la referencia del año pasado. | Sí: el equipo de implementación de Open iTcomprueba la cifra de desviación con el cliente antes de la renovación, y no por cada sitio de forma aislada. |
Esa última fila es el punto de divergencia. La disponibilidad en tiempo real, el seguimiento de denegaciones, la asignación de costes y la recuperación de tiempo de inactividad responden a preguntas sobre un único puesto en un momento concreto. Ninguna de ellas, por sí sola, responde a la pregunta que plantea una renovación: ¿el total acumulado de este año, al que se han ido sumando unas cuantas licencias cada vez en todas las sedes, sigue coincidiendo con lo que el parque de licencias está utilizando realmente? Esa es una pregunta diferente a «¿está inactiva esta licencia en este momento?», y una herramienta diseñada para responder a la primera no responde a la segunda.
A noventa días de una renovación como esta, la verdadera pregunta no es si la plataforma cuenta con suficientes informes, sino si alguno de ellos responde a la pregunta que realmente importa. Una larga lista de categorías de informes no simplifica ese trabajo; simplemente cambia la duda de «¿tenemos los datos?» a «¿qué informe los contiene?».
La solución es sencilla: medir cuánto tiempo del tiempo de uso registrado se dedicó realmente a trabajar con la herramienta, por puesto y por aplicación, y analizar esas cifras con el cliente antes de la conversación sobre la renovación, no después.
Incluso sin tener que acceder a cada máquina por separado, los datos básicos sobre la asignación y el rechazo que figuran en los registros del servidor de licencias ya revelan la naturaleza del problema: un grupo de licencias que ha ido creciendo a lo largo de varios ciclos de renovación, patrones de rechazo que pueden justificar o no la compra de más licencias, y sesiones que permanecen abiertas mucho tiempo después de que el trabajo haya finalizado. Esa es una respuesta real y útil a la pregunta «¿se ha revisado este parque de licencias en su conjunto?», pero no puede resolver una ambigüedad concreta: una licencia a la que se accede durante dos minutos cada veinte minutos parece estar activa de forma continua para un contador de tiempo, al igual que una licencia que se abrió una vez y nunca se cerró. Solo midiendo lo que realmente ocurre en el equipo se pueden distinguir ambas situaciones.
Eso es precisamente lo que hace la medición directa de la actividad —teclado, ratón, CPU, E/S—: muestra si un módulo aprovisionado se estaba utilizando realmente antes de la renovación, no después. Esa distinción es fundamental precisamente para las familias de productos modulares de las que trata este artículo: TestMAX de Synopsys se divide en DFT, ATPG, Diagnosis, Manager, Advisor y ALE, y Calibre de Siemens EDA se divide en nmDRC, nmLVS, PERC, Auto-Waivers, SONR y Fab Insights —cada uno de ellos un producto con licencia independiente que un equipo puede aprovisionar para una fase del proyecto y no volver a utilizar nunca más—. Design Compiler, TestMAX, IC Compiler, Calibre, MATLAB y LabVIEW son herramientas para las que esta comparación ya es válida en la actualidad.
Los datos solo valen la pena cuando alguien puede actuar en función de ellos sin tener que esperar a que un especialista interprete el informe.
Preguntas frecuentes
¿Qué es la desviación de la suscripción en la gestión de licencias de software?
La deriva de las suscripciones es el crecimiento gradual y sin control del conjunto de derechos de uso de un software: puestos, licencias o capacidad de funciones adicionales que se van añadiendo de forma incremental con el paso del tiempo, sin que en ningún momento se compruebe si el total acumulado se ajusta a las necesidades reales.
¿En qué se diferencia la desviación en la suscripción de una compra excesiva puntual?
Una compra excesiva puntual es una decisión aislada que se puede revisar y revertir. La deriva no se debe a una única decisión concreta. Es la suma de muchas adiciones que, por separado, eran razonables, pero que nadie sumó hasta que llegó el momento de la renovación.
¿Cómo se puede detectar la desviación en los derechos antes de la renovación?
Analizando periódicamente el total de derechos asignados en comparación con el uso real medido en los terminales, y no solo en el momento de la renovación, y disponiendo de una visión global de todo el parque informático en lugar de un informe por centro o por gestor de licencias.
La próxima renovación llegará de todas formas. La única decisión real es si vendrá acompañada de una cifra que tu equipo pueda justificar, o de una que ambos veáis por primera vez.
