Working ≠ Delivering Value
Many organizations already use GLPI. The system is installed, tickets are created, requests are processed, notifications are sent. Formally, the ITSM tool is implemented and “working.”
But working does not automatically mean delivering value.
The difference becomes visible when management starts asking questions. How many changes were delayed? Which services generate the most incidents? Where are the bottlenecks? Are we meeting our SLAs? Who is responsible for a specific asset and its related changes? If the answer is “we need to look that up,” the system may be running — but it is not steering.
When the System Only Records
It is common to see GLPI deployed in its basic form. All tickets flow into one structure, roles are generic, change approvals happen outside the system, SLAs are not tied to services, and reporting is done manually in Excel. The asset database exists but is not connected to operational processes. The IT team works hard, yet the system does not provide a clear picture of risk, workload, or improvement areas.
Consider a typical scenario. A change is created and assigned to “IT department.” Approval happens via email. Implementation notes are written in a comment. The ticket is closed. A year later, someone needs to find out who approved the change, what risk was assessed, and which asset was affected. The data exists — but not in a structured, traceable way. The system records history, but it does not support governance.
When the System Starts Governing
The same tool, however, can work very differently. When entities reflect the organizational structure, roles clearly represent responsibilities, change workflows include managed validations and approvals, SLAs are linked to services, and assets are connected to incidents and changes, GLPI becomes a decision-support system.
Management gains visibility into workload, service risk, and process bottlenecks. The IT team gains clarity, accountability, and fewer parallel spreadsheets. Reports are no longer manually built — they emerge naturally from structured processes. The difference is not in the tool. The difference is in the architecture.
The Gap Between Reality and Data
In practice, the gap between a “running” system and a “value-generating” system rarely comes from tool limitations. It usually results from the natural evolution of the organization. GLPI is implemented as a project, but its further development is not continuously managed. Meanwhile, the organization changes, services grow, security requirements increase, and reporting expectations rise.
The system remains in its original configuration. Over time, it stops reflecting reality and creates a gap between how the organization operates and what the data shows. And that gap is where value is lost.
Most companies already have a solid foundation in place. There is no need to change the platform or start from scratch. A structured assessment, refined entity and role architecture, improved workflows, SLA alignment, and process integration can transform a “running tool” into a governing system.
GLPI is running.
The question is whether it works for you.