Mettere HR, Ufficio Legale e Facilities sullo stesso GLPI dell'IT non è premere un pulsante: è una decisione di architettura. L'Enterprise Service Management (ESM) riutilizza il motore ITSM che già gestisce, ma ciò che separa un progetto che scala da uno che diventa un caos è come viene isolata ogni area: per entità, per categoria o per gruppo. Sbagliare questa scelta costa rilavorazioni e, nel caso di HR e Legale, espone dati riservati.
La prima decisione: entità, categoria ITIL o gruppo?
Prima di creare un modulo o uno SLA, definisca l'unità di isolamento. GLPI offre tre vie per modellare un'area fuori dall'IT, e ciascuna ha un compromesso reale tra riservatezza e sforzo di manutenzione.
| Approccio | Isolamento dei dati | SLA/calendario proprio | Sforzo di manutenzione | Quando usarlo |
|---|---|---|---|---|
| Entità dedicata | Totale (ticket, allegati e report separati) | Sì, per entità | Alto (profili, regole e categorie per entità) | HR e Legale, dove c'è riservatezza |
| Categoria ITIL + gruppo | Parziale (chi ha l'entità vede tutto) | Condiviso; lo SLA può variare per categoria | Basso | Facilities e aree senza forte riservatezza |
| Sotto-entità sotto l'IT | Alto, ereditando la governance della casa madre | Sì | Medio | Area che risponde alla stessa direzione |
La regola pratica che applichiamo: se un ticket dell'area può contenere un dato che l'IT non dovrebbe leggere - buste paga, un contratto, una causa di lavoro - la risposta è un'entità dedicata. Per il resto, categoria più gruppo risolvono con una frazione dello sforzo.
Isolamento dei dati: il punto cieco di HR e Legale
Nella manutenzione di parchi GLPI per i clienti, l'errore che vediamo più spesso in un progetto ESM non riguarda i moduli, ma la visibilità. Qualcuno crea l'entità "Legale", cura le categorie, ma concede il profilo agli analisti IT in modo ricorsivo dalla radice - ed ecco fatto: l'IT vede ora tutti i ticket del Legale, allegati compresi. Peggio: in GLPI l'allegato eredita l'entità del ticket (il legame Document_Item richiede che documento e oggetto siano nella stessa entità), quindi un contratto allegato a un ticket in un'entità condivisa diventa visibile a chiunque abbia accesso a quell'entità. Proprio per questo, per il Legale, isoliamo per entità, mai per categoria.
Prima di aprire qualsiasi area sensibile, eseguiamo questo audit per trovare chi ha un accesso troppo ampio:
-- Audit di visibilita: chi vede i ticket di TUTTE le aree.
-- Da eseguire sul database GLPI. L'accesso ricorsivo dalla radice (entities_id = 0,
-- is_recursive = 1) permette all'utente di vedere i ticket di tutte le entita figlie.
SELECT u.name AS utente,
p.name AS profilo,
e.completename AS entita_base,
pu.is_recursive
FROM glpi_profiles_users pu
JOIN glpi_users u ON u.id = pu.users_id
JOIN glpi_profiles p ON p.id = pu.profiles_id
JOIN glpi_entities e ON e.id = pu.entities_id
WHERE pu.is_recursive = 1
AND pu.entities_id = 0
ORDER BY p.name, u.name;Ogni riga è un utente che vede tutto. Per le aree riservate, il legame profilo-utente deve puntare all'entità specifica con is_recursive disattivato. E attenzione a un dettaglio di GLPI: l'entità con id 0 è la radice, un valore valido - non la tratti come "vuota".
SLA e calendario per area: l'errore dell'8x5 in Facilities
Lo SLA in GLPI è legato a un calendario (orario di lavoro), e il calendario è definito per entità. L'errore comune è creare Facilities ereditando il calendario 8x5 dell'IT e promettere uno SLA di manutenzione degli edifici che, in pratica, non gira di notte né nel fine settimana - proprio quando un condizionatore di datacenter o un guasto elettrico richiedono risposta. Prima di pubblicare lo SLA di un'area, verifichi:
- Calendario: Facilities critico spesso richiede 24x7; HR e Legale funzionano bene in 8x5.
- Festività: il calendario di GLPI accetta festività e chiusure - le popoli, altrimenti lo SLA conta tempo fuori orario.
- Escalation: definisca il gruppo tecnico dell'area prima di attivare lo SLA, altrimenti il ticket sfora senza destinatario.
Onboarding multi-area: il flusso che ripaga l'ESM
Il caso che giustifica l'investimento più in fretta è l'onboarding. Un modulo "Nuovo dipendente" (nativo in GLPI 11, o FormCreator in GLPI 10) genera ticket coordinati: l'IT crea email e accessi, Facilities prepara la postazione, l'HR gestisce i documenti. Ogni ticket nasce nell'entità giusta, con il gruppo giusto, e notifica il responsabile. Un estratto di un modello di notifica che usiamo per l'avviso di apertura dell'area:
Oggetto: [##ticket.entity##] Onboarding: ##ticket.title## (##ticket.id##)
E' stata aperta una nuova richiesta ed e in attesa della tua area.
Ticket......: ##ticket.title##
Entita......: ##ticket.entity##
Categoria...: ##ticket.category##
Richiedente.: ##ticket.authors##
Gruppo......: ##ticket.assigntogroups##
Scadenza SLA: ##ticket.time_to_resolve##
Apri........: ##ticket.url##I ##...## sono tag nativi di GLPI, sostituiti al momento dell'invio. L'errore comune qui è creare le categorie dell'area e dimenticare di contrassegnarle come visibili nell'helpdesk (il campo is_helpdeskvisible): il dipendente apre il portale self-service e non trova la categoria HR, perché è nata visibile solo per l'interfaccia tecnica.
Checklist di implementazione
- Mappi i servizi dell'area (cosa gestisce) prima di toccare GLPI.
- Decida l'unità di isolamento con la tabella qui sopra (entità vs categoria vs gruppo).
- Crei l'entità dall'interfaccia - mai via SQL (GLPI costruisce l'albero con getSonsOf e un INSERT diretto resta invisibile nella gerarchia).
- Configuri il calendario e lo SLA dell'area.
- Crei le categorie ITIL e contrassegni la visibilità nell'helpdesk.
- Crei il gruppo tecnico e i profili, con il corretto ambito di entità (esegua l'audit di ricorsività).
- Costruisca il modulo (nativo su 11 o FormCreator su 10) e lo provi con un ticket reale in staging.
- Solo allora apra agli utenti e pubblichi le metriche.
Cosa misurare (intervalli onesti)
Con le aree sullo stesso GLPI, confronta ciò che prima era inconfrontabile: tempo medio di risposta, volume per categoria e tasso di riapertura, fianco a fianco tra IT, HR e Facilities. Non prometta un numero magico: ridurre l'"email persa" è di solito il guadagno più visibile nel primo mese, perché ogni richiesta diventa un ticket tracciabile. Il guadagno di tempo nell'onboarding dipende da quanto del flusso automatizza - più attività il modulo attiva da solo, maggiore è l'effetto.
In NexTool implementiamo e manteniamo GLPI multi-area per i clienti, dalla progettazione delle entità allo SLA e alle regole di instradamento. Se vuole portare GLPI oltre l'IT senza esporre i dati di HR o Legale, i nostri servizi di supporto e manutenzione coprono questa progettazione da capo a fondo.
Revisionato dal team NexTool Solutions.
