Most IT organizations can point to a service management tool humming in the background — a ticketing system, a CMDB, a workflow engine — and call it “our ITSM.” Fewer can say with confidence whether the processes running through that tool are mature, or whether the tool is configured well enough to support them. That gap is what an ITSM Process and Tool Maturity Assessment is designed to close: it treats process and tooling as two separate things to measure, not one bundled impression of “how good is our ITSM.”
This distinction matters because the two rarely move in lockstep. It’s entirely possible to have a textbook-perfect incident process documented in a governance binder while the tool executing it is a patchwork of unused fields and manual workarounds. It’s equally possible to own an expensive, feature-rich platform that technicians route around because nobody redesigned the process to match how the tool works. An ITSM Process Maturity Assessment answers one question; an ITSM Tool Maturity Assessment answers a different one — and an organization that only asks one is flying half-blind.
This article unpacks why process and tool maturity need separate scores, walks through a five-level scale you can apply to both, and shows how to turn that scoring into an improvement plan rather than a shelf report.
Two Different Kinds of Maturity, One Shared Scorecard
Process maturity describes how consistently and predictably your organization performs a practice — incident management, change enablement, problem management, request fulfillment — regardless of which system it runs in. It asks whether roles are clear, whether the process runs the same way on the night shift as the day shift, whether metrics are tracked and acted on, and whether the process improves over time based on evidence rather than opinion.
Tool maturity is different: how well the platform is configured, integrated, and actually used to support that process. A tool can be enterprise-grade and still be immature if categorization is inconsistent, automation is unused, reporting is manual and spreadsheet-based, or the CMDB is stale and untrusted. A modest tool that’s well-configured and consistently used can outperform a premium platform that’s half-implemented.
ITIL 4 encodes this separation. Its “four dimensions of service management” split process-and-people concerns from the technology dimension, because an organization can be strong in one and weak in the other (Beyond20, ITIL 4 Maturity Model overview). Treating maturity as one blended number hides where the real risk sits.
The Four Maturity Quadrants: Mapping Process Against Tool
Plot process maturity on one axis and tool maturity on the other, each running from low to high. Every IT organization sits somewhere on this grid, whether or not it has ever measured itself.
Low Process, Low Tool
The “figuring it out as we go” quadrant. No documented process, and the tool — if one exists — is a glorified email inbox. Work happens through heroics and tribal knowledge, with no consistency, audit trail, or scalability.
High Process, Low Tool
Real process design work exists — clear workflows, defined roles, escalation paths — but the tool can’t enforce any of it. Analysts coordinate through spreadsheets or chat, and the tool becomes a compliance formality filled in after the fact.
Low Process, High Tool
The classic “we bought the platform, we didn’t redesign the work” trap. Automation and integrations sit mostly dormant because nobody rebuilt the process to use them; configuration just mirrors the old tool. Expensive licensing, underwhelming outcomes.
High Process, High Tool
The target state: a well-designed process the tool actively enforces, with automation reducing manual steps, dashboards providing real visibility, and CMDB data trustworthy enough to drive decisions. Getting here is the point of an ITSM Process and Tool Maturity Assessment — it tells you which quadrant you’re actually in, not the one you assume.
A Five-Level Scale for ITSM Process Maturity Assessment
To score process maturity in a way that’s comparable and defensible to a CIO or audit committee, most practitioners borrow the logic behind CMMI (Capability Maturity Model Integration), also mirrored in the ITIL 4 Maturity Model — a five-point scale running from ad hoc activity to fully optimized, data-driven practice (CMMI Institute, “Levels of Capability and Performance”; Beyond20, ITIL 4 Maturity Model overview). A practical version adapted for a standalone ITSM Process Maturity Assessment looks like this:
- Level 1 — Ad Hoc / Initial: Work gets done, but inconsistently. No agreed process, no documented roles, outcomes depend on who happens to pick up the ticket.
- Level 2 — Repeatable: A process exists and is followed by some teams some of the time, often driven by individual habit rather than organization-wide standard. Performance is inconsistent across shifts, teams, or locations.
- Level 3 — Defined: The process is documented, agreed, and applied consistently organization-wide. Roles, inputs, outputs, and escalation paths are clear and repeatable regardless of who is on duty.
- Level 4 — Managed: The process is measured. KPIs are tracked, reviewed regularly, and used to catch drift before it becomes a problem. Decisions are backed by data, not anecdote.
- Level 5 — Optimized: The process improves continually based on evidence. Root-cause trends feed back into process design, automation reduces manual toil, and the organization actively pursues efficiency rather than just maintaining stability.
Applying the Same Scale to ITSM Tool Maturity Assessment
The same five levels apply to the tool, but the evidence is different. An ITSM Tool Maturity Assessment earns points on configuration quality, data integrity, automation adoption, and integration depth — not on whether a policy document exists.
At Level 1, the tool is a passive record-keeper: tickets get logged, nothing more. At Level 3, categorization, SLAs, and workflow states are configured consistently, and the CMDB is populated and reasonably reliable. At Level 5, the tool actively drives the process: automated routing, self-service deflection, integrations keeping the CMDB accurate, and reporting built into the platform rather than exported to spreadsheets.
A tool assessment looks at configuration decisions (are defaults still in place years after go-live?), automation usage rates, integration completeness, adoption patterns, and whether dashboards are trusted in real decisions.
Why an ITSM Process and Tool Maturity Assessment Beats Assessing Either Alone
Scoring only the process gives you a governance narrative with no operational teeth — your incident process may be “Defined” on paper without knowing whether the tool enforces priority, escalation, or SLA clocks. Scoring only the tool gives you a technology audit showing the platform is capable of more than it delivers, usually because nobody redesigned the process to use those capabilities or trained staff on them.
A combined assessment surfaces the mismatch directly. Many organizations discover they’ve landed in the “High Process, Low Tool” or “Low Process, High Tool” quadrant — meaning the investment already exists, and the fix is a targeted redesign rather than a full re-platform. That’s far cheaper to solve once you can see it clearly, which is the value of measuring the two axes independently.
How to Run a Combined Assessment in Practice
A credible assessment combines a few methods rather than a single survey. Structured interviews with process owners and frontline analysts reveal the gap between documented process and lived reality. A hands-on review of the tool’s configuration — workflow states, automation rules, integration health, CMDB data quality — reveals the technical reality independent of what anyone says. Benchmarking both scores against recognized frameworks — ITIL 4 practices, SIAM operating model expectations, and The Open Group’s IT4IT reference architecture — gives the results external validity instead of grading on the organization’s own curve.
The output should never be one composite number — it should be two scores per practice area, plotted on the quadrant grid, with a prioritized list of the gaps that matter most and a realistic sequence for closing them.
Get Your Free ITSM Maturity Assessment from DesQcon
DesQcon runs exactly this kind of assessment as a vendor-neutral advisory partner, not a platform reseller with a reason to point every finding toward a new license. Our framework benchmarks People, Process, and Tools independently against ITIL 4, SIAM, and IT4IT, so you get a clear-eyed view of both axes instead of one blended score that hides where the real gap is.
If you’re not sure whether your real problem is process, tooling, or both, that’s exactly what the assessment is built to resolve. Take DesQcon’s free ITSM Maturity Assessment to get an evidence-based read on where you sit on both scales, or explore our broader IT Service Management consulting and training services to turn the results into a prioritized roadmap.
Sources
- Beyond20, “An Overview of the ITIL 4 Maturity Model and Assessment (and why they’re important)” — https://www.beyond20.com/blog/itil-4-maturity-model-and-assessment-overview/
- CMMI Institute, “Levels of Capability and Performance” — https://cmmiinstitute.com/learning/appraisals/levels
- Wikipedia, “Capability Maturity Model Integration” — https://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration
- ISO, “ISO/IEC 20000: A Practical Guide” handbook — https://www.iso.org/files/live/sites/isoorg/files/store/en/PUB100441_preview.pdf
- Service Desk Institute, “A Guide to ITSM Maturity Models and Finding Your Best Fit” — https://www.servicedeskinstitute.com/resources/itsm-maturity-models/