Na governança de tecnologia da informação e infraestrutura corporativa no âmbito do gerenciamento de produtos e serviços digitais (DPSM), o identificador único (ID) atua como a chave primária que conecta o item físico ou lógico ao seu ciclo de vida dentro do ecossistema de gestão. Ele é o elo indispensável que amarra o registro cadastral, o histórico de manutenção, a contabilidade financeira, os contratos de suporte e as atribuições de uso por parte de usuários e setores.

A relevância técnica e operacional do identificador único baseia-se em quatro pilares fundamentais:

• Rastreabilidade e Integridade: Garante que cada intervenção técnica, atualização de firmware, alteração de configuração ou substituição de peças seja associada com precisão cirúrgica ao equipamento correto, eliminando ambiguidades em parques heterogêneos.
• Desambiguação em Atendimentos: Na Central de Serviço (Service Desk), impede que chamados de incidentes ou requisições de serviço sejam vinculados a ativos homônimos ou a equipamentos substitutos sem a devida atualização do histórico na CMDB.
• Confiabilidade em Auditorias: Permite confrontar a base inventariada (registro lógico) com a presença física durante auditorias patrimoniais, validando a depreciação fiscal e os prazos de garantia sem margem para dúvidas.
• Ciclo de Vida Integrado: Mapeia o ativo desde a sua aquisição e homologação até o seu descarte sustentável, passando por transferências de propriedade, alocações e manutenções preventivas.

A Problemática da Ausência de uma Área de Patrimônio Centralizada

É um cenário recorrente nas organizações a ausência de um setor central de gestão patrimonial encarregado do tombamento e da etiquetação formal de ativos no momento do recebimento. Nessas estruturas, a responsabilidade pela criação da numeração de inventário acaba sendo delegada diretamente às equipes operacionais que gerenciam os ativos (como TI, Facilities ou Engenharia Clínica).

Essa descentralização gera distorções severas que impactam diretamente a governança e a eficiência do atendimento:

Duplicidade e Conflito de Numeração

Sem um livro tombo unificado ou um repositório central de controle, equipes distintas criam sequências numéricas isoladas. A TI pode gerar uma sequência manual para notebooks enquanto o setor de Facilities utiliza a mesma faixa numérica para mobília ou unidades de climatização. O resultado direto é a coexistência de patrimônios idênticos no banco de dados corporativo.

Falta de Padrão e Discrepância Formática

A ausência de uma regra centralizada resulta em formatos inconsistentes. Um analista pode cadastrar um item como NOTEBOOK-001, enquanto outro utiliza NTB_1 ou insere apenas o número de série do fabricante no campo de patrimônio. Essa discrepância invalida pesquisas lógicas, paralisa a geração de relatórios consolidados e compromete integrações via API com sistemas de ERP.

Ativos Operando sem Registro (Invisibilidade / Shadow IT)

Quando a identificação fica sob a responsabilidade exclusiva da equipe operacional, a prioridade da tarefa costuma ser direcionada à resolução do problema técnico imediato em detrimento da rotina administrativa. Equipamentos são colocados em produção sem a devida etiqueta de identificação, gerando o fenômeno dos “ativos invisíveis”, os quais não constam em relatórios de cobertura de garantia nem no cálculo de depreciação do negócio.

Ineficiência no Atendimento ao Usuário (Service Desk)

No suporte aos usuários, a ausência de um código visível e padronizado obriga a equipe de atendimento a despender tempo confirmando endereços MAC, números de série gravados no chassi ou nomes de host na rede. Essa checagem manual eleva o Tempo Médio de Atendimento (TMA) e aumenta dramaticamente a taxa de chamados registrados contra ativos incorretos.

Mecanismo de Geração Sequencial no Verdanadesk e GLPI

Tanto o GLPI quanto a plataforma profissional Verdanadesk resolvem essa demanda ao oferecer um mecanismo nativo de autopreenchimento de nomes e números de inventário por meio do uso estratégico de modelos (templates) de ativos.

Em vez de depender da digitação manual por parte do operador, o sistema avalia a máscara de formatação definida no modelo e consulta a base de dados no momento da criação da ficha para incrementar automaticamente o último número utilizado.

Sintaxe e Variáveis

A lógica de automação exige que o padrão de incremento seja delimitado pelos sinais de menor e maior (< >). As variáveis suportadas incluem:

• #: Define a quantidade de dígitos numéricos preenchidos com zeros à esquerda (ex: #### resulta na sequência 0001, 0002, …).
• \g: Força o sistema a buscar o último número global gerado com aquele exato formato na base de dados e incrementar uma unidade.
• \Y / \y: Insere o ano corrente com 4 ou 2 dígitos (ex: 2026 ou 26).
• \m / \d: Insere o mês e o dia da criação do registro do ativo.

Exemplo prático de máscara aplicada ao campo Nome ou Número de Inventário: <VDT-\Y-COMP-\g####>

O primeiro computador cadastrado através deste modelo receberá o identificador VDT-2026-COMP-0001, o segundo receberá VDT-2026-COMP-0002, e assim sucessivamente.

Limitações Técnicas: Risco de Sobreposição entre Classes de Ativos

Embora o recurso de incremento automático garanta a padronização e elimine os erros de digitação manual, existe uma limitação operacional que precisa ser sanada durante a fase de arquitetura de dados.

Se a máscara configurada utilizar apenas caracteres genéricos de incremento, como < \g#### >, aplicada de forma idêntica em modelos de classes de ativos distintas (por exemplo, na classe Computadores e na classe Impressoras), o parâmetro \g buscará a sequência considerando a tabela ou a consulta lógica específica da classe de ativo. Dependendo da construção da consulta no banco de dados, corre-se o risco de gerar dois ativos com a mesma numeração final em classes diferentes (ex: Computador 0100 e Impressora 0100), o que, do ponto de vista na norma ISO/IEC20000-1, seria uma não conformidade.

Ter um computador e uma impressora compartilhando o mesmo código 0100 recria a ambiguidade patrimonial no inventário geral da organização, comprometendo a confiabilidade das auditorias.

Proposta de Solução: Prefixos Estáticos por Classe de Ativo

Para contornar em definitivo o risco de sobreposição e manter a desambiguação completa em todo o parque corporativo, a solução consiste na inclusão de um prefixo estático de classe na própria estrutura da máscara de incremento de cada modelo de ativo.

Modelo Recomendado de Formatação

A regra de nomenclatura deve combinar: [Identificador da Empresa] + [Sigla Estática da Classe] + [Ano] + [Incremento Global].

Classe de Ativo	Máscara Configurada no Modelo	Resultado Gerado
Computadores (Notebooks/Desktops)	<VDT-CMP-\Y-\g####>	VDT-CMP-2026-0001
Impressoras e Multifuncionais	<VDT-IMP-\Y-\g####>	VDT-IMP-2026-0001
Equipamentos de Rede (Switches/Roteadores)	<VDT-RED-\Y-\g####>	VDT-RED-2026-0001
Monitores e Displays	<VDT-MON-\Y-\g####>	VDT-MON-2026-0001

Vantagens Principais dessa Abordagem:

1. Garantia de Unicidade Absoluta: A presença do elemento estático da classe (CMP, IMP, RED) garante que, mesmo que os contadores numéricos coincidam, a chave alfanumérica completa seja estritamente única em todo o banco de dados.
2. Reconhecimento Visual Imediato: Ao visualizar o número de inventário em uma tela de chamado da Central de Serviço ou em uma etiqueta física, o analista identifica instantaneamente a categoria do ativo sem necessidade de abrir o cadastro completo.
3. Autonomia com Governança: As equipes operacionais mantêm a agilidade para cadastrar seus ativos via modelos, permanecendo em conformidade rigorosa com os requisitos formais de controle patrimonial corporativo.

Nota de Engenharia & Governança no Verdanadesk

• Integridade Estrutural na CMDB: A aplicação de máscaras padronizadas por modelo de hardware no Verdanadesk fortalece a prática de Gerenciamento de Configuração de Serviço (ITIL 5). Ao garantir que cada Item de Configuração (CI) nasça com uma chave primária única e estruturada, a plataforma elimina o risco de vinculação incorreta de chamados pelo suporte técnico.
• Sincronismo com Módulos Verdanatech: Esse rigor na identificação alimenta de forma síncrona o plugin vServices durante as automações de rotinas de atendimento, enquanto os critérios do módulo vTerms asseguram que a garantia e os prazos contratuais vinculados àquele identificador específico sejam auditados sem falhas, mantendo o histórico do ciclo de vida no Verdanadesk perfeitamente rastreável.