GLPI is in production. Tickets get created, notifications fire, the dashboard is green. Here's a simple test: open your last ten change tickets. Can you tell, without a follow-up query, who approved each one, what risk was assessed, which CI the change touched, and whether it met SLA? If not, the system has collapsed into a logbook.
In practice, that logbook looks like this: a single entity called "IT" for the whole company. Ticket categories where 80% of tickets end up in one catch-all bucket. SLAs defined on the root entity so they technically apply to everything and wake no one up. A "technician" profile assigned to forty people. A change workflow with a CAB approval field that nothing enforces. Half the tickets have no linked item — itemtype null, no CI relation.
Each of these is configurable. None gets noticed until someone asks "show me every change on the domain during Q3."
What a GLPI audit typically finds
It's both a configuration and a process audit — in GLPI the two can rarely be separated. Most findings repeat across installations:
- Entity tree vs. org chart. If they don't match, everything downstream (profiles, SLAs, categories) inherits the wrong structure.
- Profiles and roles. How many accounts have Super-Admin? How many are over-privileged (technician covers 90% of the work)? When was each profile last changed — and by whom?
- SLA coverage. What percentage of tickets is covered by an SLA that has defined actions (escalations, notifications) rather than just a number in a field?
- Asset ↔ ticket link. On how many tickets is
itemtypepopulated? Without the link there is no service-level MTTR, no impact analysis, no postmortem. - Change workflow. Does it block closure without approval, or is approval just a field? Does a change go through the same process when an admin creates it?
- Parallel records. An Excel CI list. A shared mailbox for approvals. A Confluence page with the asset inventory. Each one signals that GLPI isn't covering something it should.
A typical audit produces 20 to 40 findings: roughly a third are quick fixes (hours of work), a third are configuration changes (days), a third are process decisions (weeks). None of it requires an upgrade, a migration, or a new tool.
Why it ends up this way
GLPI is usually deployed as a project. The vendor's contract ends, an internal admin inherits the tool, and further evolution is driven by tickets — "add a field," "create a category," "raise my priority." That isn't configuration, it's maintenance on demand. The process named at implementation time decays year by year into individual exceptions.
Meanwhile the company has acquired two subsidiaries, moved to hybrid cloud, signed on to ISO 27001, and under NIS2 is expected to produce auditable change management. GLPI stayed in its original configuration. A gap opens between reality and what gets written to the system. Reports stop being produced in GLPI and start being produced in Excel.
Where to start if this sounds familiar
Start with entities. If the entity tree doesn't mirror the organization, everything else is compensation. Second, profiles — work out who has what rights and why. Third, take one real process use case (usually change, or incident-to-problem) and redraw it in GLPI so it matches what actually happens.
Everything else follows: SLAs switch to services, categories get cut according to what the team actually handles, reports start coming out of GLPI because the data finally has shape. You don't need to replace the platform. You need to sit down, open the configuration, and remove the exceptions that have accumulated.