An ITSM platform is not a ticketing tool. Most companies run it as one.

Walk into most IT organisations and ask what the ITSM platform does. The answer is “tickets”. Incidents come in, get assigned, get closed. Requests come in, get approved, get fulfilled by somebody doing something somewhere else. The platform records that work happened. It rarely does the work, and it almost never knows what the work was about.

That is a ticketing tool. It is useful. It is also a small fraction of what the platform can do.

What “operational platform” means

An operational platform answers questions a ticketing tool cannot:

• What depends on this server? A ticketing tool has a free-text field called “affected CI”. An operational platform has a CMDB with relationships that were populated by discovery and reconciled against the cloud provider yesterday.
• What happens when this request is approved? In a ticketing tool, a person reads the ticket and clicks through three other systems. In an operational platform, a workflow creates the account, assigns the licence, updates the CMDB and tells the requester when it is done.
• Is this change risky? A ticketing tool asks the requester to pick “low / medium / high”. An operational platform calculates it from the CIs involved, their business criticality, the change window and the history of similar changes.

The difference is not features. Every one of these capabilities ships with the platform. The difference is four decisions that were made, or not made, in the first six months.

Decision 1: The CMDB is a product, not a table

A CMDB that nobody trusts is worse than none, because people design processes around it and then route around it. The fix is not a data-cleansing project. It is ownership: someone owns the data model, aligned with a documented service data model, someone owns each data source (discovery, cloud connectors, imports), and there is a health dashboard that is looked at in a meeting.

If your ITSM platform’s CMDB does not have an owner with a calendar entry, you have a table.

Decision 2: Configuration over customisation, enforced

Every ITSM system that has become impossible to upgrade got there one reasonable script at a time. The rule that prevents it is simple and unpopular: out-of-the-box first, configuration second, scripting only with a written reason and a plan for the next upgrade. Enforcing it needs a platform owner who can say no, a review step before releases move, and automated test coverage for the things that matter.

Decision 3: The catalog describes services, not forms

A catalog with 400 items that are really 400 forms is a filing cabinet. A catalog built from the question “what do people need to get done?” has fewer items, each with a fulfilment workflow that ends in a delivered outcome. The test for a catalog item is whether it can be fulfilled without a human reading the ticket. If not, either automate it or accept it as a manual service and measure it as such.

Decision 4: Processes are designed with the people who run them

Incident, change and request processes that were copied from a framework and configured by a partner in a workshop nobody from operations attended will be bypassed within a quarter. The processes that stick were designed with the service desk lead, the change manager and the two engineers who do most of the changes, and then the platform was configured to make the agreed path the easiest path.

Where to start

Not with a re-implementation. Start with an honest assessment: CMDB health, customisation debt, catalog fulfilment rate, and which processes are actually followed. Pick the one area where the gap between “recorded” and “operated” costs the most, usually request fulfilment or change risk. Fix that end to end, including the CMDB data it needs. Then the next one.

Your ITSM platform is already there. The work is to make it reflect reality and then to let it act on it.