Download full articleIntroduction
In my consulting work, I’ve seen the same pattern repeatedly. Organizations spend heavily on ITSM platforms like ServiceNow, Jira or Remedy, expecting that once the tool is in place, ITIL value will follow. But tools don’t deliver ITIL by default. The gap isn’t in the technology – it’s in the way it’s aligned, or often misaligned, with ITIL’s principles. Too many times, I’ve watched tools get configured first, while processes, governance and people are treated as afterthoughts. The result? A sophisticated ticketing system that handles incidents but completely misses the bigger picture: managing value.
This article is based on lessons from the field. I’ll unpack why this gap happens, how it damages trust, efficiency and outcomes, and what it really takes to close it. The answer isn’t in more customization or more modules – it’s in starting with services, using ITIL as the compass, balancing standardization with flexibility, embedding human-centric design and measuring business value beyond SLA numbers. My goal is simple: to help organizations stop treating ITSM tools as an end and start using them as what they really are – enablers of ITIL’s bigger vision of co-creating value and driving continual improvement.
Why this gap keeps happening?
1. Tools first, services later
Too many projects start by configuring the tool before defining services. ITIL 4 makes it clear through its guiding principle “Focus on value” that services must be designed around business outcomes, not just technology. ISO/IEC 20000 reinforces this by requiring organizations to define their service management system (SMS) upfront. But I’ve seen organizations skip this, rushing to “go live.” The result? Tools that automate incidents but don’t reflect real services.
Example: In one organization, ITSM tool was configured without a proper service catalog. Every ticket was logged under “IT support.” To the business, IT looked like a black box. After re-designing the catalog around actual services (e.g., “Payroll system availability” vs. “Generic support”), business stakeholders finally saw where IT added value.
2. Over-customization for the wrong reasons
Every ITSM tool can be customized. The danger is when customization replaces best practice. ITIL 4’s principle “Keep it simple and practical” is often ignored. COBIT 2019 warns against controls that add complexity without business benefit. Yet I’ve seen organizations demand 100+ custom fields in a change form “just in case.” The process slowed down, approvals piled up, and people worked around the system.
Example: A public sector client insisted on duplicating legacy approval chains inside their ITSM tool. The tool worked, but changes that should take 24 hours took weeks. After aligning with ITIL 4’s “Progress iteratively with feedback” and simplifying workflows, throughput doubled without sacrificing governance.
3. Lack of ITIL knowledge in tool teams
One of the most overlooked causes of failure is the lack of ITIL knowledge among developers and architects. I’ve personally worked with teams who believed the Service Request Catalog was the Service Catalog. That confusion is fatal.
Both ITIL 4 and ISO/IEC 20000 emphasize the service catalog as the backbone of value delivery. When teams confuse it with a request menu, they reduce ITSM to “ticket management.” COBIT 2019, with its focus on aligning governance to enterprise objectives, would call this a breakdown in design factors.
Example: In a financial services project, the implementers built a “service catalog” with only password reset, email quota increase, and software installation. Leadership thought IT offered only those services. We restructured the catalog to include “Digital banking services,” “Fraud detection services,” and “Customer support services.” Suddenly, IT wasn’t just a help desk — it was a partner in the bank’s core business.
4. Metrics that don’t tell the story
ITSM tools love reporting on SLA compliance and ticket closure rates. But ITIL 4 pushes us to measure value co-creation, ISO/IEC 20000 requires continual improvement, and COBIT 2019 insists on alignment with enterprise goals. Closing tickets faster doesn’t prove IT is enabling the business.
Example: At one client, SLA compliance was 98%, yet end-users were deeply dissatisfied. Why? Tickets were “resolved” on paper, but issues recurred. After introducing experience-level agreements (XLAs) measuring end-user sentiment and business impact — IT shifted focus from activity to outcomes.
The cost of the gap
From experience, when ITSM tools and ITIL aren’t aligned, the consequences are inevitable:
- Wasted investments: multi-million tools reduced to glorified ticketing systems.
- Lost trust: business leaders see IT as a cost center, not a value enabler.
- Missed opportunities: IT gets stuck firefighting instead of driving transformation.
This isn’t theory. I’ve walked into organizations where ITSM tool licenses sat idle because users bypassed it with spreadsheets. That’s what happens when the tool is the driver.
How to bridge the gap
Here’s what I’ve seen work in the real world:
1. Start with services, not tools
- Build the service catalog before configuring the tool.
- ITIL 4 and ISO/IEC 20000 both mandate service definition as the foundation.
- COBIT 2019 ties this directly to enterprise objectives.
2. Use ITIL as the compass, tools as the vehicle
- ITIL 4 provides principles like “Start where you are” and “Focus on value.”
- The tool should serve these principles, not replace them.
3. Balance standardization with customization
- Stick to out-of-the-box where possible — most vendors design features to align with ITIL/ISO.
- Customize only when it delivers measurable business outcomes.
4. Humanize ITSM
- Success is about adoption. Engage users early, run workshops, communicate benefits.
- ITIL 4’s “Collaborate and promote visibility” applies here.
5. Measure value, not just activity
- Move beyond SLA dashboards. Measure business outcomes, customer experience and value streams.
- ISO/IEC 20000 and ITIL calls for continual service improvement — this requires value metrics, not just ticket metrics.
A real-world example
At a government sector client, the ITSM tool was live, but the business felt no impact. Everything was “incidents and requests.” We introduced a structured service catalog, mapped each service to configuration items (CIs), assigned service owners and built cost models.
Suddenly, the ITSM tool wasn’t just logging issues – it was showing how IT supported Business services. That shift changed conversations with leadership: IT was no longer defending costs; it was demonstrating value.
And here’s the key: no extra licenses, no new modules. Just alignment with ITIL 4 principles, ISO/IEC 20000 requirements and COBIT governance practices.
Conclusion
The truth is simple: ITSM tools don’t implement ITIL – people do.
ITSM tools are powerful enablers, but without ITIL, ISO/IEC 20000 alignment, they’ll never deliver their full potential. The organizations that succeed are those that treat tools as vehicles, guided by frameworks and principles, and anchored in business value.
When the gap is bridged, ITSM stops being about tickets and processes. It becomes what it was always meant to be: a discipline for co-creating value, building trust and enabling digital transformation.