Thinking in Services

From technology to service

A technology-centred IT function manages servers, networks and applications. A service-centred one manages the outcomes those things enable: taking an order, paying staff, dispatching an engineer, keeping a plant running. The distinction matters because the business does not consume a database — it consumes a capability, and a component that is technically healthy while the capability is unusable is not a success.

A service is defined by what it enables, who uses it, what they can expect, and what it costs. Maintaining a service catalogue — a plain list of the services offered, their owners, hours, and support arrangements, written in the language the business uses — is the foundation of everything else and is frequently missing.

ITIL and the practices

ITIL is the most widely used framework and is a source of good practice rather than a standard to be implemented literally. Its guiding principles are worth knowing on their own merits:

• Focus on value — every activity should trace to a benefit for someone.
• Start where you are — assess what exists before replacing it.
• Progress iteratively with feedback.
• Collaborate and promote visibility — hidden work cannot be improved.
• Think and work holistically — services span people, process, technology and suppliers.
• Keep it simple and practical — remove anything that does not contribute.
• Optimise and automate — optimise first, then automate; automating a bad process produces a faster bad process.

The four dimensions

Every service depends on organisations and people, information and technology, partners and suppliers, and value streams and processes. Improvement efforts that address only the technology dimension routinely fail because the constraint was in one of the others — typically skills, or an unclear process.

Other frameworks

• ISO/IEC 20000 — the certifiable service management standard, sometimes required contractually.
• COBIT — governance, focused on control objectives and alignment with business goals.
• Site reliability engineering — a complementary engineering-led approach using error budgets, automation and blameless review, increasingly blended with traditional service management.

Avoiding bureaucracy

Service management fails most often by becoming process for its own sake: forms nobody reads, approvals that add delay without judgement, and categories nobody can choose correctly. Every step should have a purpose someone can state. If a control exists only because the framework mentions it, remove it.