How cost and complexity accumulate
Across the estates Brillio assesses, a familiar set of conditions recurs. Services and tooling have been duplicated, often because acquisitions or business units arrived with their own. Technology stacks have drifted from any single standard. Data sits across multiple stores, which makes a single trusted view harder to establish. Processes differ between functions, and so do the structures that support them. Rarely is this deliberate. It is the cumulative effect of local choices, each reasonable at the time, that together produce an operating model no one designed as a whole.
The platform layer follows the same pattern. A ServiceNow business case assumes efficient use of licenses, streamlined processes and continuous adoption of new capability as it is released. Those assumptions hold at the outset. Over the years that follow, unused modules accumulate, customization raises the cost of every upgrade, and automation opportunities are missed as native capability develops faster than the instance adopts it. Each creates leakage: higher run-costs, unnecessary renewals, avoidable technical debt and lost productivity, and the erosion is gradual enough that no reporting period triggers a review.
Which raises the more useful question. If the platform still works, if tickets still close and services stay available, what exactly has been lost?
The governance conditions that determine whether returns hold
The industry’s answer to service management problems has been standardization: align processes to ITIL, consolidate tooling, publish the operating model. That work is necessary. On its own it is insufficient, because it addresses the layer that is easiest to see.
The constraints often sit underneath.
- Platform ownership is diffuse, so architectural decisions are made locally and accumulate.
- Process owners exist on paper but are not aligned to a common design, so each optimizes for their own function.
- Data is not trusted, so reporting is rebuilt rather than relied upon.
- Users route around workflows they find slow, so measured adoption and real behavior diverge.
These are often symptoms of governance and engagement gaps, and standardization programs do not necessarily resolve them.
Set against that, good looks less like an inventory of capabilities than a set of conditions.
- Services mapped through to the components that support them, so a change in the business has a traceable consequence in the estate.
- Standards that hold across the organization rather than within it.
- A relational data model underpinned by a trusted CMDB, which allows reporting to be built once.
- Repeatable processes rather than locally interpreted ones.
- A coordinated service organization with accountability actively managed.
Holding that in place depends on effective platform ownership, aligned process owners, architectural and data governance, capable BAU support, engaged users, and continuous utilization of new capability as it arrives.
These are organizational conditions, not technical ones, and that is what makes them hard to manage. Availability, SLA attainment, and ticket volumes can all look healthy while ownership is ambiguous, licenses go unharvested, and a significant part of the automation in the platform is switched off. Routine reporting confirms the platform is working. It is not designed to establish whether it is still returning what was modeled.
