NexTool Solutions

O GLPI open source não tem mensalidade, mas "sem licença" está muito longe de "sem custo". Quem compara apenas o preço de tabela do GLPI self-hosted com o de um ServiceNow erra as contas nas duas direções: subestima o que o self-hosted consome em operação e sobrestima o que o SaaS entrega de origem. Este comparativo coloca lado a lado os quatro modelos que mais implementamos - GLPI self-hosted, GLPI Cloud, ServiceNow e Jira Service Management - no eixo que realmente move o TCO: a unidade de faturação e o trabalho de operação.

Os quatro modelos, numa frase cada

• GLPI self-hosted (open source): software gratuito, sem limite de utilizadores; paga infraestrutura e mão de obra.
• GLPI Cloud (Teclib): o mesmo GLPI, alojado e mantido pela Teclib, com subscrição por técnico.
• ServiceNow: plataforma ITSM enterprise, licença por agente sob cotação, orientada a automação e governação em larga escala.
• Jira Service Management: o ITSM da Atlassian, subscrição por agente em planos, forte para quem já vive no ecossistema Jira/Confluence.

Os três pagos cobram por agente ou técnico: o custo cresce de forma aproximadamente linear com a dimensão da equipa de atendimento. O self-hosted inverte a lógica - o software é fixo em zero e o custo vem da operação. É essa diferença de natureza, e não o preço de um mês isolado, que decide qual sai mais barato num horizonte de três anos.

Comparativo direto

Quantos "agentes" paga na realidade

Aqui está a armadilha que só aparece na hora da fatura: nos modelos por agente, quem custa é o utilizador com interface técnica (central), não o requerente que só abre pedidos pelo autoatendimento. Os requerentes costumam ser ilimitados e gratuitos nos três. Ou seja, o número que define a sua fatura não é "quantas pessoas usam o GLPI", mas sim "quantas têm perfil de técnico".

No self-hosted esse número é invisível - ninguém o cobra, por isso as organizações distribuem o perfil central com folga: o coordenador que só quer ver uma dashboard, o gestor que "às vezes precisa de ver a fila", o estagiário que fechou dois pedidos no ano passado. Na migração para qualquer SaaS por agente, cada um deles passa a ser uma linha na fatura. Antes de pedir cotação, execute esta consulta na base de dados do seu GLPI para saber o número real:

-- Quantos "agentes" pagaria num SaaS por agente?
-- Agente faturável = utilizador com perfil de interface central (técnico),
-- não o utilizador de autoatendimento (helpdesk), que costuma ser ilimitado.
SELECT COUNT(DISTINCT pu.users_id) AS agentes_faturaveis
FROM glpi_profiles_users pu
JOIN glpi_profiles p ON p.id = pu.profiles_id
JOIN glpi_users     u ON u.id = pu.users_id
WHERE p.interface = 'central'   -- interface técnica (exclui helpdesk)
  AND u.is_active  = 1
  AND u.is_deleted = 0;

Já vimos esse número vir 40% acima do que o cliente estimava "de cabeça". Antes de comparar preços com o SaaS, faça a limpeza: rebaixe para autoatendimento quem não atende de facto. Isso reduz a fatura futura e, já agora, limpa os relatórios de produtividade dentro do próprio GLPI.

O custo oculto que nunca entra na folha de cálculo

Na sustentação de parques GLPI para clientes, o item que mais dispara o TCO do self-hosted não aparece em tabela nenhuma: é a dívida de atualização. O cliente instala o GLPI, funciona, e ninguém lhe toca durante dois anos. Quando finalmente precisa de uma funcionalidade nova ou de um plugin compatível, descobre que saltar de uma 9.5 para uma 11 não é "clicar em atualizar" - é migrar o esquema, rever os plugins que partiram e testar em pré-produção. O que era manutenção de 2h/mês tornou-se um projeto. O erro comum é orçamentar o self-hosted só pelo VPS e tratar a atualização como um evento raro; ela é recorrente e exige uma janela, um backup testado e um ambiente de testes.

E há o outro custo que ninguém contabiliza: o backup que existe mas nunca foi restaurado. No self-hosted, o DR é inteiramente da sua responsabilidade - e uma cópia que ninguém testou é um backup que não tem. O mínimo viável é uma cópia diária da base de dados e dos ficheiros, com verificação periódica:

# /etc/cron.d/glpi-backup - cópia diária da base de dados + ficheiros do GLPI.
# No self-hosted, backup e DR são 100% seus; uma cópia nunca restaurada não conta.
30 2 * * *  root  mysqldump --single-transaction glpi | gzip > /backup/glpi-$(date +\%F).sql.gz
45 2 * * *  root  tar czf /backup/glpi-files-$(date +\%F).tar.gz /var/www/glpi/files
# Guarde uma cópia FORA do host e teste o restauro pelo menos uma vez por trimestre.

No GLPI Cloud, no ServiceNow e no Jira SM, a atualização, o backup e a disponibilidade entram no preço da subscrição - é exatamente isso que compra ao pagar por agente. A pergunta certa não é "qual é mais barato", mas sim "esse trabalho operacional fica na minha equipa ou subcontratado na mensalidade?".

Veredito por cenário

• Use GLPI self-hosted quando tem (ou contrata) quem opere Linux, a base de dados e os backups, valoriza a soberania de dados e quer um teto de custo previsível mesmo duplicando a equipa de agentes. É imbatível no custo por agente à medida que a equipa cresce; se for esse o caminho, comece pela instalação via Docker.
• Use GLPI Cloud quando quer o mesmo GLPI - mesma base, mesmos conceitos, mesmos plugins compatíveis - sem manter infraestrutura, e a equipa de técnicos é pequena o suficiente para a subscrição ainda sair abaixo de um sysadmin dedicado.
• Use ServiceNow quando a necessidade real é automação e governação enterprise (fluxos complexos, integrações corporativas, conformidade) e há orçamento para o patamar mais alto do mercado. Contratar o ServiceNow só para abrir pedidos é pagar por um avião para atravessar a rua.
• Use Jira Service Management quando a empresa já corre em Jira/Confluence e quer o ITSM colado a esse ecossistema, aceitando a faturação por agente e os limites de inventário/CMDB face ao GLPI.

Custo e esforço, com intervalos honestos

O eixo da decisão não é a licença - é para onde vai o trabalho de operação. No self-hosted, o desembolso em dinheiro é baixo (um VPS de poucas dezenas a poucas centenas por mês, conforme a escala), mas exige horas técnicas recorrentes: uma implementação bem feita raramente cabe em menos de alguns dias de trabalho, e a sustentação pede uma janela mensal para atualização e verificação de backup. Nos modelos por agente, o desembolso é maior e cresce linearmente com a equipa, mas as horas de operação de infraestrutura tendem para zero. A conta de três anos costuma favorecer o self-hosted quanto maior for a equipa de agentes e quanto mais barata for a hora técnica disponível; favorece o SaaS quando a equipa é reduzida e não há quem opere infraestrutura. Não fixe um número de TCO fechado antes de ter o total de agentes faturáveis e o custo real da sua hora técnica - sem esses dois, qualquer comparativo é um palpite.

Na NexTool implementamos e sustentamos os quatro cenários em clientes - do GLPI self-hosted enxuto ao migrado para Cloud - e a decisão que mais compensa é sempre a mesma: dimensionar o custo pela unidade certa (agentes faturáveis) e pelo trabalho de operação que a sua equipa consegue absorver. Se quiser um TCO honesto para o seu caso, sem palpites de preço de tabela, a nossa consultoria monta esse comparativo com os seus números.

Este conteúdo foi produzido com o auxílio de inteligência artificial e revisto pela equipa Nextool Solutions.