Two kinds of ownership
People often say “who owns this?” about a shared tool without noticing that the question has two parts. One is who is responsible for the system: the software, its settings, its availability and its cost. The other is who is responsible for the process: the sequence of work the business carries out, partly with the help of that system.
Mixing them up causes a familiar pattern. A technology team is blamed for a slow approval workflow that is really a policy matter. A business team asks for a new field without understanding the effect on the shared platform. Separating the two roles makes it clearer who can fix what.
The system owner
A system owner is accountable for a system as a managed asset. Typical responsibilities, adapted to the organization, include:
- keeping the system available, supported and appropriately secured;
- managing changes, in line with a change control approach;
- managing the budget, licences and supplier relationship;
- deciding, with others, how requests for new features are prioritized;
- keeping documentation and an account of who has access;
- planning for the system’s eventual upgrade or replacement.
System owners are often located in IT, but not always. A finance system may sensibly be owned by a finance leader who relies on IT for technical support. What matters is that the person has the authority and the time to carry out the role.
System ownership usually involves delegation. A system owner may rely on administrators, vendors and specialists for the detail, and remains accountable for outcomes.
The process owner
A process owner is accountable for how a business process works from start to finish, whichever systems it touches. A process such as hiring, ordering supplies or handling customer complaints may use several systems and involve several teams. The process owner looks at the whole flow.
Typical responsibilities include:
- defining the steps, roles and handoffs, often recorded as standard operating procedures;
- deciding what good looks like, and how it is measured;
- spotting delays, errors and rework, and leading improvements;
- ensuring staff know and follow the process;
- representing the process when system changes are discussed.
Process owners usually sit in the business, close to the work. In a central model there may be a global process owner who sets the common design and local leads who run it in each unit.
An illustration
Consider a shared purchasing system used by several business units. This is a made-up example.
- The system owner keeps the platform running, manages access, schedules updates and decides how technical change requests are handled.
- The process owner for purchasing decides the approval steps, thresholds and supplier onboarding rules, and watches how long orders take.
Suppose a unit complains that approvals are slow. If the cause is a technical fault, it is the system owner’s matter. If the cause is that the process requires three approvals for small orders, the process owner is the one who can change it, probably with some input from finance. If the owners do not talk to each other, the system may be reconfigured to speed up a process that should be simplified instead.
Why both are needed
A system without a process owner tends to become a collection of features that automate whatever was done before, regardless of whether it makes sense. A process without a system owner can depend on tools nobody maintains. When both roles exist and cooperate, changes are checked from both directions: is it feasible and safe in the system, and is it right for the work?
Working together
Some habits help the two roles cooperate:
- Agree boundaries in writing. A short description of each role and its decisions avoids overlap. A RACI matrix is one way to record this.
- Meet regularly. A recurring conversation about upcoming changes, problems and improvements is generally enough.
- Share priorities. When a request affects both the system and the process, decide together or through the committee overseeing the system.
- Escalate cleanly. If they cannot agree, a named person or forum should resolve it.
Data adds another dimension. Questions about what information is held and whether it is accurate often involve data stewardship roles as well, which are a third, related kind of ownership.
Pitfalls
- Ownership by title only. A name on a chart without time, authority or understanding does not amount to ownership.
- Too many owners. Shared ownership by committee frequently means no ownership. Prefer a single accountable person, with others consulted.
- Owner as bottleneck. If every decision waits for one person, availability becomes a problem. Define who covers absences.
- Orphaned systems and processes. When an owner leaves, the role must be reassigned. Periodic governance reviews can catch gaps.
- Confusing ownership with control. An owner is accountable for the outcome, but good owners consult the people affected.
Smaller organizations
In a small business one person may hold both roles for many systems. That is workable as long as the two responsibilities are still recognised: someone has to keep the tool functioning, and someone has to ask whether the work is being done sensibly. Where IT support is only part-time, the arrangement for ownership needs particular care, so that nothing slips between roles.