Platform module · IT service management

Run the service on the same map you govern it with.

Requests, incidents, problems and changes work on the same inventory as architecture and risk. An outage is prioritised by the value it takes away, and a change is approved knowing everything it touches.

Along the service line

Service catalogue→ Requests→ Incidents→ Problems→ Changes→ Releases

One catalogue for the whole platform: an access request, a risk assessment or a new server all start here.

What it covers

The service desk, with the whole picture behind it.

Every ticket points to an asset in the shared inventory. Agents see its owner, its dependencies and its value without leaving the record.

Requests

Catalogue and fulfilment

Standard requests from one catalogue, routed through approvals and fulfilled by workflow.

Incidents

Restore by value

Priority and target time set by the value lost, so the most important outage is always first in the queue.

Problems

Fix the cause

Recurring incidents grouped into problems, with known errors and the risks they raise.

Changes and releases

Approve with the impact in view

Every change shows what depends on the asset it touches, and the value at stake if it goes wrong.

Priority by value lost

Not the loudest voice. The largest loss.

When an asset fails, its criticality stays and its maturity drops. The difference, ΔVi, is measured on the same scale as everything else and sets the priority of the incident.

P1 · CriticalΔVi ≥ 300 · < 1 h

P2 · High200–299 · < 4 h

P3 · Medium100–199 · < 24 h

P4 · Low50–99 · < 1 week

P5 · Minimal< 50 · best effort

Thresholds as given in the Management Guideline. Each organisation sets its own.

Inside the module

What service teams work with.

Service deskQueues, assignment and escalation, with the affected asset on every ticket.

One service catalogueIT and governance requests in one place, ordered by the asset categories of the framework.

Configuration from the inventoryNo separate CMDB to maintain: services, applications and infrastructure come from the shared inventory.

Change impactDependencies and value at stake shown on every change before it reaches the approvers.

Service levelsTargets that follow the value of the service, tracked per incident and per request.

Service maturityStrategy, design, transition, operation and continual improvement, assessed on the framework scale.

Already run an ITSM tool?

Connect it instead.

Keep your current service desk. A connector exchanges assets, incidents and changes with it, so architecture, risk and work management still see the service side, and ΔVi still sets the priority.

Part of one platform