A practical introduction to improving processes, responsibilities and quality, with measures that help teams decide what to change.
Operational excellence is a phrase that can sound abstract, associated with large improvement programmes, specialist methods and dedicated teams. In everyday terms it is simpler than that. It is the habit of looking carefully at how work gets done, deciding where it could be better and making changes that people can sustain. Organisations of any size can apply it, and the benefits usually come from steady, well-chosen improvements rather than a single transformation.
This article explains what the approach involves in practice, how to choose where to begin and how to tell whether a change has helped.
Start with a useful definition
Operational excellence is an approach to improving how an organisation works over time. It connects process, people, information and measures with the outcomes the organisation needs to deliver.
It does not mean every process runs perfectly. The useful question is where clearer responsibilities, fewer unnecessary steps or better information would help.
A working definition matters because it shapes what people do. If operational excellence is understood as cost reduction, teams will focus narrowly on efficiency and may overlook quality or user experience. If it is understood as adopting a particular method, effort can go into training and terminology rather than improvement. A balanced definition keeps attention on outcomes: work that is reliable, proportionate in effort, clear in responsibility and satisfying for the people who receive it.
It also helps to recognise that improvement is continuous. Processes drift as people change roles, systems are updated and requirements evolve. A process that worked well two years ago may now include steps that no longer serve a purpose. Periodic review is part of the discipline, not a sign that something has gone wrong.
Choose the right improvement
Look at delays, rework, customer experience and the effort required from staff. Identify a priority process and agree what improvement would look like.
Involve the people who perform and receive the work. A change that makes one stage faster may add work elsewhere.
Good candidates for improvement tend to show some familiar signs. Work waits in queues for approval. Requests are returned because information is missing. The same data is entered into several systems. Staff rely on workarounds or personal spreadsheets to get things done. Customers or internal requesters ask repeatedly for updates because they cannot see progress.
When choosing where to start, weigh the impact of the problem against the effort needed to address it. A process that affects many people, causes frequent rework and is within the team’s control to change is usually a better first choice than one that depends on several external parties or a major system replacement.
Consider an illustrative scenario. A procurement team notices that purchase requests often take longer than expected. Speaking with requesters and approvers reveals that most delays occur because requests arrive without the budget code or supplier details needed. The improvement might be a clearer request form and short guidance, rather than an additional approval layer or a new system. Involving both sides of the process makes this visible early, and avoids a change that speeds up one stage while pushing work back to requesters.
Make the process and responsibilities clear
Map the current workflow, establish the target steps and agree who makes decisions. Guidance, training and accessible information can be as important as a new system.
Methods such as Lean or Agile may help structure the work, but using a method does not by itself establish regulatory compliance or guarantee delivery on time and budget.
Mapping the current process is often revealing. Teams frequently discover steps that exist only because of a historic requirement, approvals that duplicate each other or handovers where responsibility is unclear. A simple map, agreed by the people who do the work, provides a shared basis for deciding what to keep, remove or redesign.
The target process should be described just as clearly, including who is responsible for each step, who makes decisions and what happens when something goes wrong. Questions worth asking at this stage include:
- Does every step add value for the person receiving the work, or meet a genuine requirement?
- Is it clear who owns each decision, and do they have the authority to make it?
- Can people find the guidance they need without asking a colleague?
- Where a system is involved, does it support the process or force workarounds?
Technology can support a clearer process, but it should follow the process design rather than lead it. Where a spreadsheet-based workflow has become difficult to manage, a purpose-built application with defined steps, permissions and records may be the right response. Our process automation application for a pharma company’s European operations is an example of replacing spreadsheets with a structured workflow. Where the process is still unsettled, it is usually better to stabilise it first.
Measure and improve
Compare the result with a baseline and review quality, effort and user experience. Use the findings to decide whether to refine, expand or reconsider the change.
Measurement does not need to be elaborate, but it does need to begin before the change. Without a baseline it is difficult to tell whether an improvement has worked or whether the organisation has simply become used to a different set of problems. Useful measures might include the time from request to completion, the proportion of work that needs to be returned or corrected, the effort involved for staff and feedback from the people who receive the output.
A common pitfall is relying on a single measure. If speed is the only indicator, quality may decline without anyone noticing. Balancing two or three measures, and combining them with conversation, gives a more reliable view. Another pitfall is declaring success too early. Some changes look effective in the first weeks and then erode as attention moves elsewhere. A review after a few months shows whether the improvement has held.
The findings should lead to a decision. If the change has worked, it may be extended to similar processes. If it has partly worked, it can be refined. If it has not, the organisation has learned something useful at modest cost.
Where to start
A focused starting point is to select one process that causes visible difficulty, map it with the people involved, agree a small set of measures and test a change over a defined period. That approach builds evidence and confidence for further improvement.
Glyz supports process improvement, programme delivery and practical digital tools. Our AI and digital transformation service includes process review and improvement planning, and where a tool is needed, our development and automation team can build applications that fit the agreed process.
