NexTool Solutions

GLPI open source non ha canone mensile, ma "senza licenza" è molto lontano da "senza costi". Confrontare solo il prezzo di listino di GLPI self-hosted con quello di un ServiceNow sbaglia i conti in entrambe le direzioni: sottostima ciò che il self-hosted consuma in esercizio e sovrastima ciò che il SaaS offre di serie. Questo confronto mette fianco a fianco i quattro modelli che implementiamo di più - GLPI self-hosted, GLPI Cloud, ServiceNow e Jira Service Management - sull'asse che muove davvero il TCO: l'unità di fatturazione e il lavoro di esercizio.

I quattro modelli, in una frase ciascuno

• GLPI self-hosted (open source): software gratuito, senza limite di utenti; paghi infrastruttura e manodopera.
• GLPI Cloud (Teclib): lo stesso GLPI, ospitato e gestito da Teclib, con abbonamento per tecnico.
• ServiceNow: piattaforma ITSM enterprise, licenza per agente su preventivo, orientata ad automazione e governance su larga scala.
• Jira Service Management: l'ITSM di Atlassian, abbonamento per agente in piani, forte per chi vive già nell'ecosistema Jira/Confluence.

I tre a pagamento fatturano per agente o tecnico: il costo cresce in modo pressoché lineare con la dimensione del team di supporto. Il self-hosted ribalta la logica - il software è fisso a zero e il costo viene dall'esercizio. È questa differenza di natura, e non il prezzo di un singolo mese, a decidere quale sia più economico su un orizzonte di tre anni.

Confronto diretto

Quanti "agenti" paghi davvero

Ecco la trappola che emerge solo al momento della fattura: nei modelli per agente, a costare è l'utente con interfaccia tecnica (centrale), non il richiedente che apre solo ticket dal self-service. I richiedenti sono di solito illimitati e gratuiti in tutti e tre. In altre parole, il numero che definisce la tua fattura non è "quante persone usano GLPI", ma "quante hanno un profilo da tecnico".

Nel self-hosted quel numero è invisibile - nessuno lo fattura, così le organizzazioni distribuiscono il profilo centrale con larghezza: il coordinatore che vuole solo vedere una dashboard, il manager che "ogni tanto deve guardare la coda", lo stagista che ha chiuso due ticket l'anno scorso. Nella migrazione verso un qualsiasi SaaS per agente, ognuno di loro diventa una riga in fattura. Prima di chiedere un preventivo, esegui questa query sul database del tuo GLPI per conoscere il numero reale:

-- Quanti "agenti" pagheresti in un SaaS a consumo per agente?
-- Agente fatturabile = utente con profilo a interfaccia centrale (tecnico),
-- non l'utente self-service (helpdesk), di solito illimitato.
SELECT COUNT(DISTINCT pu.users_id) AS agenti_fatturabili
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'   -- interfaccia centrale (esclude helpdesk)
  AND u.is_active  = 1
  AND u.is_deleted = 0;

Abbiamo visto quel numero tornare del 40% sopra ciò che il cliente stimava "a memoria". Prima di confrontare i prezzi con il SaaS, fai pulizia: retrocedi a self-service chi non gestisce davvero ticket. Questo riduce la fattura futura e, come bonus, ripulisce i report di produttività all'interno dello stesso GLPI.

Il costo nascosto che non entra mai nel foglio di calcolo

Nella manutenzione di parchi GLPI per i clienti, la voce che fa esplodere di più il TCO del self-hosted non appare in nessuna tabella: è il debito di aggiornamento. Il cliente installa GLPI, funziona, e nessuno lo tocca per due anni. Quando finalmente serve una funzione nuova o un plugin compatibile, scopre che passare da una 9.5 a una 11 non è "cliccare su aggiorna" - è migrare lo schema, rivedere i plugin che si sono rotti e testare in staging. Quella che era manutenzione di 2h/mese è diventata un progetto. L'errore comune è preventivare il self-hosted solo per il VPS e trattare l'aggiornamento come un evento raro; è ricorrente e richiede una finestra, un backup testato e un ambiente di test.

E c'è l'altro costo che nessuno mette in conto: il backup che esiste ma non è mai stato ripristinato. Nel self-hosted, il DR è interamente tua responsabilità - e un dump che nessuno ha testato è un backup che non hai. Il minimo indispensabile è un dump giornaliero del database e dei file, con verifica periodica:

# /etc/cron.d/glpi-backup - dump giornaliero del database + file di GLPI.
# In self-hosted, backup e DR sono al 100% tuoi; un dump mai ripristinato non 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
# Conserva una copia FUORI dall'host e prova il ripristino almeno una volta a trimestre.

Su GLPI Cloud, ServiceNow e Jira SM, aggiornamento, backup e disponibilità sono inclusi nel prezzo dell'abbonamento - è esattamente ciò che compri pagando per agente. La domanda giusta non è "quale costa meno", ma "questo lavoro operativo resta nel mio team o è esternalizzato nel canone?".

Verdetto per scenario

• Usa GLPI self-hosted quando hai (o assumi) qualcuno che gestisca Linux, il database e i backup, tieni alla sovranità dei dati e vuoi un tetto di costo prevedibile anche raddoppiando il team di agenti. È imbattibile sul costo per agente man mano che il team cresce; se è questa la strada, parti dall'installazione via Docker.
• Usa GLPI Cloud quando vuoi lo stesso GLPI - stessa base, stessi concetti, stessi plugin compatibili - senza mantenere infrastruttura, e il team di tecnici è abbastanza piccolo perché l'abbonamento resti sotto il costo di un sysadmin dedicato.
• Usa ServiceNow quando il bisogno reale è automazione e governance enterprise (flussi complessi, integrazioni aziendali, compliance) e c'è budget per la fascia più alta del mercato. Prendere ServiceNow solo per aprire ticket è pagare un aereo per attraversare la strada.
• Usa Jira Service Management quando l'azienda gira già su Jira/Confluence e vuole l'ITSM incollato a quell'ecosistema, accettando la fatturazione per agente e i limiti di inventario/CMDB rispetto a GLPI.

Costo ed effort, con fasce oneste

L'asse della decisione non è la licenza - è dove va il lavoro di esercizio. Nel self-hosted, l'esborso in denaro è basso (un VPS da poche decine a poche centinaia al mese, a seconda della scala), ma richiede ore tecniche ricorrenti: un'implementazione fatta bene raramente sta in meno di qualche giorno di lavoro, e la manutenzione chiede una finestra mensile per aggiornamento e verifica del backup. Nei modelli per agente, l'esborso è maggiore e cresce linearmente col team, ma le ore di esercizio dell'infrastruttura tendono a zero. Il conto a tre anni tende a favorire il self-hosted quanto più grande è il team di agenti e quanto più economica è l'ora tecnica disponibile; favorisce il SaaS quando il team è ridotto e non c'è chi gestisca l'infrastruttura. Non fissare un numero di TCO chiuso prima di avere il totale degli agenti fatturabili e il costo reale della tua ora tecnica - senza questi due, ogni confronto è un'ipotesi.

In NexTool implementiamo e manteniamo tutti e quattro gli scenari presso i clienti - dal GLPI self-hosted snello a quello migrato in Cloud - e la decisione che rende di più è sempre la stessa: dimensionare il costo sull'unità giusta (agenti fatturabili) e sul lavoro di esercizio che il tuo team può assorbire. Se vuoi un TCO onesto per il tuo caso, senza tirare a indovinare il prezzo di listino, la nostra consulenza costruisce questo confronto con i tuoi numeri.

Questo contenuto è stato prodotto con l'ausilio dell'intelligenza artificiale e revisionato dal team di Nextool Solutions.