- O desvio de subscrição consiste num aumento não autorizado do conjunto de direitos de software entre uma renovação e a seguinte – não havendo um momento específico em que o total acumulado seja comparado com as necessidades reais.
- De acordo com os resultados do terceiro trimestre do ano fiscal de 2026 (o trimestre mais recente divulgado), a Synopsys obtém atualmente cerca de 60 % das suas receitas de produtos através de licenças baseadas no tempo, do tipo subscrição, contra 40 % provenientes de pagamentos iniciais.
- As famílias de produtos modulares apresentam a maior exposição à deriva – o TestMAX da Synopsys (DFT, ATPG, Diagnosis, Manager, Advisor, ALE) e o Calibre da Siemens EDA (nmDRC, nmLVS, PERC, Auto-Waivers, SONR, Fab Insights) –, enquanto as ferramentas de núcleo único, como o Design Compiler, acompanham o ritmo de tape-out em vez de a deriva.
Quando uma equipa de conceção de semicondutores solicita mais um módulo TestMAX DFT para cumprir um prazo de tapeout, o pedido parece insignificante e é aprovado em poucos minutos – um único item no portfólio de software da Synopsys. A fase termina, o módulo permanece disponibilizado e a sua libertação não é da responsabilidade específica de ninguém. Multiplique esse padrão por um conjunto de conjuntos de licenças partilhadas que servem vários milhares de engenheiros, e uma organização de conceção pode acabar por adicionar duas dúzias de licenças flutuantes num ano que ninguém aprovou individualmente e que ninguém analisou coletivamente — um acúmulo que aparece na fatura de renovação.
Quando uma equipa de conceção de semicondutores solicita mais um módulo TestMAX DFT para cumprir um prazo de tapeout, o pedido parece insignificante e é aprovado em minutos — um único item na lista do portfólio de software da Synopsys. A fase termina, o módulo permanece disponível e a sua libertação não é da responsabilidade específica de ninguém. Multiplique esse padrão por um conjunto de conjuntos de licenças partilhadas que servem vários milhares de engenheiros, e uma organização de conceção pode acabar por adicionar duas dúzias de licenças flutuantes num ano que ninguém aprovou individualmente e que ninguém analisou coletivamente – um acúmulo que aparece na fatura de renovação.
O desvio na subscrição é o aumento lento e não aprovado do conjunto de direitos de software entre uma renovação e a seguinte. Uma licença adicionada aqui, outra ali, e ninguém reavalia nada disso antes de o período de subscrição ou manutenção chegar ao fim. Cada alteração é aprovada individualmente. Ninguém verifica o total de doze meses. O número de direitos varia ao longo do ano. A primeira vez que alguém vê o total é na fatura de renovação.
No setor do design de semicondutores, isto manifesta-se mais rapidamente nas famílias de ferramentas que têm duas características em comum: são normalmente vendidas com base em renovações — a Synopsys, por exemplo, obtém atualmente cerca de 60 % das suas receitas de produtos através de licenças temporárias, do tipo subscrição, contra 40 % pagas antecipadamente, de acordo com os resultados do seu último trimestre divulgado — e estão divididas em vários módulos licenciados separadamente, em vez de um único produto global.
O conjunto de ferramentas TestMAX da Synopsys para design para teste (DFT) – dividido em DFT, ATPG, Diagnóstico e vários outros produtos complementares – é um ambiente em que é muito mais fácil perder a noção do que ainda é necessário do que o Design Compiler, a ferramenta de síntese de núcleo único que praticamente todas as equipas de design digital utilizam diariamente. Adquirir mais um módulo TestMAX para uma fase do projeto é, em cada ocasião, uma decisão pequena e justificável. Retirá-lo após o término dessa fase não é tarefa de ninguém em particular.
Numa organização de design que gere os seus conjuntos partilhados com vários milhares de engenheiros, duas licenças adicionais por mês parecem insignificantes. Se somarmos essas licenças ao longo de um ano, o conjunto cresceu em duas dúzias de licenças que ninguém aprovou individualmente, e essa conta é feita discretamente em segundo plano em quase todos os ambientes de design com vários locais.
Um conjunto de licenças flutuante não infringe nenhuma regra
Um prazo de tapeout leva à disponibilização de um módulo de testabilidade antecipada para uma fase do projeto, a par da ferramenta DFT base que a equipa já executa continuamente. O módulo cumpre o prazo, a fase termina e a licença permanece registada – ninguém se encarrega de a libertar. Um conjunto de licenças de «design-for-test» expandido há dois anos para um programa nunca é reduzido. Cada passo é pequeno, documentado e justificável por si só.
O que falta é uma visão global ao longo das etapas. Na maioria dos fluxos de trabalho, nada questiona se as adições deste ano, consideradas no seu conjunto, ainda fazem sentido em relação à linha de base do ano passado — muito menos se um determinado módulo adicional continua a ser utilizado. O registo mostra o que foi aprovado. Não mostra o que se acumulou, nem o que deixou silenciosamente de ser utilizado assim que a fase que o justificava terminou.
Para uma organização de design que utiliza licenças de EDA em vários locais — muitas vezes com vários milhares de engenheiros a partilhar um número reduzido de conjuntos de recursos para síntese, DFT e layout —, essa lacuna agrava-se rapidamente. Uma equipa de design num determinado local pode solicitar um módulo DFT adicional sem ter conhecimento do que os outros dois locais já adicionaram nesse mesmo trimestre, nem se algum desses locais ainda está a utilizar o módulo do ano anterior.
Por que é que o relatório habitual não o deteta?
A maioria dos relatórios de licenças mostra o que foi retirado, e não o que foi efetivamente utilizado. Essa distinção é importante: uma retirada confirma que uma licença foi atribuída. Não confirma, porém, que alguém tenha trabalhado na ferramenta durante a hora, o dia ou o trimestre que se seguiu.
A solução mais comum para esta situação, no âmbito da medição de licenças, é uma regra de recuperação automática: libertar automaticamente uma licença depois de esta ter sido atribuída e de permanecer inativa durante um período de tempo definido. Isto resolve o caso mais simples – uma licença deixada aberta durante a noite sem que nada aconteça nela. No entanto, continua a inferir a atividade a partir do tempo de atribuição da licença, em vez de a medir.
A deriva dos direitos de acesso ultrapassa facilmente essa lacuna. Uma licença adicionada em março e que, desde então, raramente foi utilizada, continua a aparecer como uma licença normal e em uso em qualquer relatório elaborado apenas a partir dos registos de check-out e dos temporizadores de inatividade. O número parece satisfatório. Ninguém analisou a utilização subjacente.
Aspetos que vale a pena verificar antes da sua próxima renovação
| Assinar | O que isso normalmente significa |
|---|---|
| O conjunto de licenças de síntese, DFT ou layout tem vindo a crescer ao longo de vários ciclos de renovação sem que ninguém tenha aprovado o valor total | As adições foram aprovadas uma a uma – o montante em si nunca foi analisado |
| Os relatórios de tempo de inatividade indicam uma utilização adequada, mas ninguém consegue identificar quem está, de facto, a executar tarefas nas estações de trabalho específicas | Uma visualização que inclui o checkout e o temporizador não representa uma utilização ativa — o relatório está a responder à pergunta errada |
| Uma renovação adapta-se à «utilização atual» sem que seja necessário definir primeiro um novo ponto de referência | Fuga de renovações – a variação deste ano passa a ser o valor mínimo do ano seguinte |
| As equipas dos locais ou dos programas solicitam licenças adicionais sem terem uma visão clara do que os outros locais já adicionaram | O excesso de provisão acumula-se localmente e de forma invisível |
Duas formas de colmatar a lacuna
A maioria das soluções desta categoria resolve o primeiro problema da mesma forma. Onde divergem — e onde a perda de assinantes passa despercebida — é no que acontece a seguir.
A abordagem habitual baseia-se no registo do servidor de licenças: disponibilidade em tempo real que mostra quem ocupa atualmente uma licença, acompanhamento das recusas para saber quem foi recusado e quando, repartição de custos por departamento ou projeto e uma regra de recuperação automatizada que liberta uma licença assim que esta fica inativa durante um período de tempo predefinido. Algumas plataformas desta categoria também incluem uma camada de otimização de subscrições para a reatribuição de licenças na nuvem, embora esse seja um mecanismo distinto da recuperação de licenças EDA.
Tudo isso representa uma capacidade real e identifica um desperdício real – um posto que ninguém se lembrou de libertar, um padrão de recusa que justifica (ou não) a aquisição de mais capacidade, um local que paga discretamente por licenças que ninguém lá utiliza. Nada disso indica se um posto atualmente ocupado está, de facto, a ser utilizado – tudo parte dos mesmos dados de registo de início de sessão e de tempo de inatividade. Uma licença de síntese que é utilizada durante dois minutos a cada vinte, com frequência suficiente para reiniciar o temporizador de inatividade, é considerada ativa durante todo o tempo, independentemente do número de módulos que se encontram nesse mesmo registo.
| O que é necessário esclarecer antes da renovação | A abordagem habitual | Open iT (Nível 1 + Nível 2) |
|---|---|---|
| Este lugar está ocupado neste momento e por quem? | Sim | Sim |
| Alguém foi recusado e, se sim, quando? | Sim – acompanhamento das recusas | Sim – Relatórios de recusa de nível 1 |
| A que local ou unidade de negócio este custo está associado? | Sim | Sim |
| Este lugar já ficou vazio durante tempo suficiente para ser libertado automaticamente? | Sim, em relação a um temporizador fixo de tempo de inatividade | Sim, correlacionado com a inatividade medida, em vez de apenas com o relógio |
| A pessoa que ocupa este lugar está, de facto, a trabalhar neste momento? | Não – deduzido a partir do checkout e do relógio de inatividade, não medido | Sim – atividade do teclado, do rato, da CPU e das entradas/saídas medida no terminal, através do Relatório de Rácio de Trabalho |
| Será que as alterações introduzidas este ano — aprovadas uma a uma, local a local — resultaram em algo que ninguém analisou antes da renovação? | Não – cada relatório é em tempo real ou por local; nada é agregado à linha de base do ano passado | Sim – A equipa de implementação da Open iT valida o valor do desvio com o cliente antes da renovação, e não separadamente por local |
Essa última linha é o ponto de divergência. A disponibilidade em tempo real, o acompanhamento de recusas, a alocação de custos e a recuperação de tempo de inatividade respondem, todos, a questões sobre um único lugar num determinado momento. Nenhuma delas — por si só — responde à questão que uma renovação coloca: será que o total acumulado deste ano, com a adição de algumas licenças de cada vez em todos os locais, ainda corresponde ao que o parque de licenças está realmente a utilizar? Essa é uma questão diferente de «esta licença está inativa neste momento», e uma ferramenta concebida para responder à primeira não responde à segunda.
A noventa dias de uma renovação como esta, a verdadeira questão não é se a plataforma tem relatórios suficientes, mas sim se algum deles responde à questão que importa. Uma longa lista de categorias de relatórios não facilita esse trabalho — limita-se a transferir a incerteza de «será que temos os dados?» para «em que relatório é que eles se encontram?».
A solução é simples: medir quanto do tempo de utilização foi efetivamente dedicado ao trabalho na ferramenta, por licença, por aplicação — e analisar esses números com o cliente antes da conversa sobre a renovação, e não depois.
Mesmo sem intervir diretamente nas máquinas individuais, os dados básicos de utilização e recusa que constam nos registos do servidor de licenças já revelam a natureza do problema: um conjunto que tem vindo a crescer ao longo de vários ciclos de renovação, padrões de recusa que podem ou não justificar a aquisição de mais licenças e sessões que permanecem abertas muito tempo depois de o trabalho ter terminado. Essa é uma resposta concreta e útil à pergunta «este conjunto foi analisado na sua totalidade?», mas não consegue esclarecer uma ambiguidade específica: uma licença utilizada durante dois minutos a cada vinte parece estar continuamente ativa para um relógio, tal como uma licença que foi aberta uma vez e nunca mais foi encerrada. Só a medição do que realmente acontece na máquina permite distinguir estas duas situações.
É isso que a medição direta da atividade — teclado, rato, CPU, E/S — faz: mostra se um módulo provisionado estava efetivamente a ser utilizado antes da renovação, e não depois. Essa distinção é especialmente importante para as famílias de produtos modulares que este artigo aborda: o TestMAX da Synopsys divide-se em DFT, ATPG, Diagnosis, Manager, Advisor e ALE, e o Calibre da Siemens EDA divide-se em nmDRC, nmLVS, PERC, Auto-Waivers, SONR e Fab Insights — cada um deles um produto licenciado separadamente que uma equipa pode provisionar para uma fase do projeto e nunca mais voltar a utilizar. O Design Compiler, o TestMAX, o IC Compiler, o Calibre, o MATLAB e o LabVIEW são ferramentas para as quais esta comparação já se aplica atualmente.
Os dados só valem a pena quando alguém consegue agir com base neles sem ter de esperar que um especialista interprete o relatório.
Perguntas mais frequentes
O que é o desvio de subscrição na gestão de licenças de software?
O desvio nas subscrições consiste no crescimento gradual e não revisto de um conjunto de direitos de software: postos, licenças ou capacidade de funcionalidades adicionais que vão sendo incorporados de forma incremental ao longo do tempo, sem que haja um momento específico em que o total acumulado seja comparado com as necessidades reais.
Em que medida é que o desvio na subscrição difere de uma compra excessiva pontual?
Uma compra excessiva pontual é uma decisão isolada que pode ser revista e revertida. A deriva não se deve a uma única decisão específica. É a soma de muitas adições, razoáveis individualmente, que ninguém somou até ao momento da renovação.
Como é que se pode detetar o desvio nos direitos antes da renovação?
Ao comparar regularmente o conjunto total de direitos com a utilização efetiva, medida nos terminais, e não apenas no momento da renovação, e ao dispor de uma visão global de todo o parque de equipamentos, em vez de um relatório por local ou por gestor de licenças.
A próxima renovação vai acontecer de qualquer forma. A única escolha real é se ela virá com um valor que a vossa equipa consiga explicar, ou com um valor que ambos estejam a ver pela primeira vez.
