This case study covers the process-governance side of my Operations Excellence work. It describes the standard work, operating procedures, visual management, Kanban, training and handover practices I applied so that manufacturing improvements kept working after the project that created them was finished.
Earlier projects in this portfolio each had a defined physical outcome. These included commissioning a louvre manufacturing line, developing a jig-stripping facility, introducing specialist powder-coating capability and developing production tooling. Across that work, the harder problem was often what happened afterwards. A new process without a defined method, trained operators and a clear owner can slowly drift back toward old habits and informal workarounds. It can also come to depend on the few people who know how it really works. This work was aimed at closing that gap.
| Project Fact | Detail |
|---|---|
| Project Type | Process standardisation and improvement governance |
| My Role | Operations Excellence Engineer |
| Scope | Manufacturing processes, production support and operational handover |
| Methods | Value stream mapping, standard work, SOPs, visual management, Kanban |
| Key Interfaces | Production, engineering, quality, systems, toolroom, purchasing, contractors |
| Nature of Work | Ongoing approach applied across multiple improvement projects |
Why Improvements Drift
Manufacturing processes rarely stay still. New products are introduced, equipment is modified, operators change, volumes rise and fall, tooling is replaced and customer requirements evolve. Each change is usually small. Without some form of process governance, though, the changes add up. Methods start to differ between people and shifts, and undocumented workarounds appear. Documentation falls behind, work-in-progress builds up, the same problems recur, and new employees become harder to train because the real method lives in someone's head.
The familiar pattern is simple: the project is completed, the team moves on and the process gradually drifts. The aim of this work was to replace that pattern with a cycle. In that cycle, each improvement is standardised, trained, owned and reviewed, and the review becomes the starting point for the next improvement.
[Diagram: The Improvement Cycle, see Section F]
My Role
As an Operations Excellence Engineer, I worked across production, engineering, quality and systems to define, implement and hand over process improvements. My involvement included:
- Reviewing current-state workflows and supporting value stream mapping
- Defining improved process flows and developing standard work and SOPs
- Implementing Kanban and visual-management concepts where they suited the process
- Coordinating operator training and supporting early production after changes
- Defining handover requirements so that improved processes had clear operational ownership
- Defining operational requirements for business-system changes, with the specialist systems team carrying out the system configuration
- Tracking improvement actions across departments and reviewing performance after implementation
The Approach
Understanding the process as it actually runs
Each improvement began with the current state. This meant looking at workflow, material movement, operator sequence, information flow, waiting, work-in-progress, rework and handoffs between operations. The most useful insight usually came from the difference between how a process is assumed to work and how it actually operates on the floor.
Value stream mapping helped widen the view beyond individual workstations. It traced how demand, material, processing, inventory and information connected across the whole flow. This made it easier to see where delays, excess inventory or unclear handoffs sat between operations. The map itself mattered less than the shared understanding it created. When production, engineering and management stakeholders are looking at the same picture, improvement decisions are easier to agree on and easier to justify.
Turning a better method into a defined standard
Once a better method had been established, it needed a documented baseline. Standard work defined what should be done, in what sequence, using what method and with what expected result. A standard does not prevent improvement. It is what makes improvement measurable, because without a defined baseline there is no reliable way to tell whether a change actually helped.
Where processes needed more detailed instruction, I developed standard operating procedures. These covered new equipment, jig stripping, specialised manufacturing processes, operating sequences, safety-related activities and handover requirements. The intent was not to produce documents for compliance. It was to capture critical knowledge so that it belonged to the organisation rather than only to the person performing the task.
Documents also need to stay current. An obsolete procedure can be worse than none if people assume it is correct. Part of the work was therefore making sure it was clear which revision was current, where it was kept and who was responsible for updating it when the process changed. Standardisation was also applied with judgement. In a mixed manufacturing environment with changing volumes, the aim was to define clearly what must stay controlled, while leaving reasonable room to manage genuinely unusual conditions.
Making the process visible
Visual management was used to make normal and abnormal conditions recognisable at a glance. This applied to material locations, production status, work priorities, tooling status, process sequence and action tracking. The goal was to reduce situations where the information existed but could only be obtained by asking the right person.
Where appropriate, Kanban principles replaced replenishment that relied on someone noticing a shortage and then finding someone to fix it. Material consumption instead triggered a visible signal and a defined replenishment response. This reduced dependence on individual memory and gave clearer control over work-in-progress. The objective with inventory was not to minimise it everywhere. It was to decide where an intermediate buffer was genuinely needed and where it was simply waiting. Controlled work-in-progress makes bottlenecks and constraints visible instead of hiding them.
Handover, training and ownership
A key governance question for any improvement is who owns the process once the project is complete. If that stays unclear, the improvement team can end up permanently responsible for routine production issues. Handover therefore needed to establish the process owner, operator responsibilities, escalation path, documentation, maintenance requirements and review expectations. In short, project ownership had to become operational ownership.
Training supported that transfer. Depending on the change, it covered the new workflow, equipment operation, material handling, procedure requirements, quality and safety expectations, and how to use the visual controls. The aim was for operators to understand both what had changed and how the new process should run.
Change management mattered as much as the technical solution. In practice, this meant:
- explaining the reason for a change
- involving the operators who would run the process
- watching for practical problems in early use
- adjusting where the feedback justified it.
A technically correct process has limited value if the people running it cannot, or will not, adopt it.
Coordinating across functions
Improvement work rarely sits within one department. A single change might involve operations, engineering, production, quality, systems, the toolroom, purchasing and external contractors. A simple action-tracking discipline helped keep this moving between meetings. Each action had an owner, a due date and a visible status, rather than relying on memory.
Some process changes also required changes to business systems. My role was to define the operational requirement and make the process decisions. The specialist systems team carried out the configuration and master-data setup. Operations then validated that the resulting workflow ran as intended. This followed the same discipline I had used earlier in product development, where a change moved in a controlled way from CAD to drawing to tooling to product. For processes, the chain runs from process change to documentation, training and systems, and then into production. In both cases, a change should not exist only in one person's notes while production carries on using the old method.
Reviewing what happened after implementation
Once a change was in place, the question became whether it had actually produced the expected result. The relevant indicators depended on the process. They included throughput, waiting time, work-in-progress, rework, downtime, operator effort, process stability and completion time. Not every improvement needed a dashboard, but every improvement needed its effect checked rather than assumed.
The real test often came months later. The checks at that point were practical:
- whether the visual controls were still being used
- whether Kanban quantities still suited current demand
- whether procedures were still current
- whether workarounds had reappeared.
Recurring problems were treated as information about the system rather than isolated events. The underlying question was what condition allowed the problem to keep happening. The answer might be weak standard work, equipment reliability, tooling, unclear ownership, material flow or a training gap.
The Outcome
The work helped establish a more structured way of implementing, documenting, transferring and sustaining manufacturing improvements. Each improvement was not treated as a standalone technical fix. Instead, process design, documentation, visual control, training, ownership and review were connected into one sequence. This strengthened the transition of project outcomes into normal production.
The most valuable result was not any single procedure, Kanban loop or process map. It was a more consistent approach to making improvement part of how production operates, rather than a temporary project activity.
Professional Perspective
My career began with toolmaking, design and product development, where the discipline of controlled change was built around drawings, tooling and products. Project delivery then broadened that into equipment, contractors and commissioning. This work extended it again, into the operating arrangements that determine whether a completed project keeps delivering value.
The common thread is a practical one. Engineering solutions only matter if the organisation can run them reliably without the person who designed them standing beside the process. This work reflects that perspective: defining standards, transferring knowledge, clarifying ownership and checking results, while coordinating across functions where I had no formal authority over every party involved.
Portfolio note: This case study describes my professional experience and contribution at a high level. Certain names, figures, technical details, images and commercial information may be omitted, generalised or anonymised to respect confidentiality, intellectual property and the interests of employers, customers, suppliers and project partners.
