You know this line: “Relax, we only changed…”.
Only the tooling, the layout. Only the process location. Only the sub-supplier. And an even bigger pathology is when the new launches manager says it’s just a “running change”, so official change management “is not needed”.
A week later complaints from production start coming in that subcomponents are getting harder and harder to assemble, and shortly after that the customer calls asking whether, by any chance, there have been any changes in the process. Suddenly it turns out that all those “only + running change” moves have added up to a potential escalation topic.
Most customer-specific requirements and the IATF 16949 standard are explicit that any change of process, relocation, product modification, change of supplier or design change at the supplier must be properly communicated inside the organization and to the customer. Why? Because this is exactly the area that can derail a stable process and the relationship with the customer.
Change management – introduction
In this article I focus on this exact piece of reality:
• change of the production process (e.g. new parameters, new equipment, different sequence of operations),
• relocation of a process or entire line (within the plant or to another location),
• change of the product manufactured by the organization (material, geometry, function),
• change of sub-supplier (new company, new location, new technology),
• design change of a part produced by the sub-supplier (new drawing, different tolerances, design correction).
If you work as a quality engineer, SQE, quality manager or process engineer and you’ve already had at least one “innocent” change or a pathological “running change” that later came back as a complaint – this article is for you.
I’m not going to focus on the soft side of “organizational change management” with slide decks, vision and mission statements. We’ll stick to a very down-to-earth topic: what happens when you physically move, change or outsource a chunk of the process. And how to keep it under control so that:
• the customer doesn’t find out about the change from an 8D report – because at that point it basically looks like shooting yourself in the foot,
• the auditor doesn’t start a series of extra questions that are hard to answer in a logical way,
• production doesn’t have to “put out the fire” for the next few weeks.
Why process change is not “just a parameter tweak”
On the shop floor, the word “change” often sounds like an obstacle. And it’s hard to blame anyone for that. The operator wants peace and quiet, the production manager wants the numbers, maintenance wants a machine that doesn’t keep breaking down. When someone comes up with ideas like:
• “Let’s increase the temperature, it’ll be faster,”
• “Let’s shorten the cycle time, we’re not keeping up” – I clearly remember how this exact approach led to hundreds of instrument cluster housings being returned by the customer. Why? Because the injection-moulding operator decided to shorten the cooling time to finish the shift earlier. The result was parts out of tolerance.
• “We’ll swap in parts from another project for this stamping tool, most of them fit anyway” – and not only that. I’ve also seen other assembly lines being stripped for spare parts just to keep the “priority” line running.
Change management is basically a built-in safety brake in the system. Before someone twists a knob, moves a line or changes a supplier, one question has to appear:
“What will happen to the product if we do this?”
And this is not about a casual chat over coffee, but about consciously going through the process: raising a change request, assessing the impact, making a decision, validating the change and monitoring it after implementation.
Change management for processes, relocations and sub-suppliers
Process changes, relocations, product changes and sub-supplier changes all have one thing in common: the risk that the part will stop behaving the way it’s supposed to.
A few typical situations:
• The line is moved to another hall. Supposedly the same machines, same product, same parameters. After a few weeks the measurement distribution looks different, scrap goes up and no one is sure whether the issue comes from environmental conditions or from slightly different settings.
• You change the material sub-supplier. The data sheet looks similar, incoming inspection doesn’t show anything dramatic. Two months later the customer reports that the part behaves differently in final assembly. And if it was a directed-buy supplier chosen by the customer, you suddenly become the escalation hero of the week in your organization.
• The supplier modifies the part design. For them it’s “just a tweak of a radius and one tolerance”. On your side this tiny change shifts the distribution, changes how the cylinder presses the bearing into the aluminium housing and creates shop-floor problems.
If every type of change has its own path, its own forms and its own “someone will take care of it”, something will eventually fall through the cracks. That’s why companies that have this under control build one coherent change-management process. Customer manuals like VDA 2 or customer procedures (e.g. Stellantis “Product and Process Changes in Serial Life”) are a big help here.
IATF 16949, customer requirements and harsh reality
IATF 16949 doesn’t have one big section titled “Management of Change”, but the topic of changes shows up in several areas.
When it comes to process, relocation, product and suppliers, the key clauses are:
8.3 – design and development – when the product or the supplier’s design changes,
8.4 – suppliers – when the sub-supplier, their location or their process changes,
8.5.6 – control of changes – when the production itself changes: machine, parameters, sequence, layout.
The minimum required for real change management
You can have a fancy procedure, a nice flowchart with coloured arrows and several forms in circulation, and still not have real change management.
In practice, if you want it to actually work, you need at least:
A place where the change is officially raised
Not “by word of mouth”, not just in an email. A form, a ticket, anything that won’t disappear after a week. We’ve recently started using an app built in Power BI for this, which allowed us to get rid of the paperwork.
Impact assessment on product and process
Link it to the FMEA, control plan and customer requirements. Without that it’s just roulette.
A decision and a clear “go / no go”
Someone takes responsibility for allowing the change to go live – with customer requirements in mind.
Validation before start of production
No launch into mass production without checking how the process behaves after the change.
Monitoring after implementation
A defined monitoring period, extra controls and a ready reaction plan for when things start to go the wrong way.
Sounds like a lot? Compared to the cost of complaints, sorting at the customer and late-night crisis calls with the OEM – it’s still the bargain option.
Step-by-step change management process – a copy-paste model
In the previous section we sorted out which types of changes must fall into the system. Now let’s get to the core: what the process should look like from the moment someone says “we want to change something” until the moment the new way of working is on the shop floor and not causing surprises.
Below you have a model you can safely copy into your own company. No fireworks, but it includes elements that actually help keep things under control.
Step 1 – Raising the change: “What exactly do we want to do?”
Without this first step, the rest doesn’t make sense. If the change is not officially raised, it practically doesn’t exist – and later it’s very hard to figure out who made the decision, on what basis and when.
What should happen here:
someone initiates the change (process, relocation, product, sub-supplier, supplier design),
they fill in a change request form (name it however you want – Change Request, ECR, etc.),
the form goes to the person / team responsible for change management.
What’s worth having in the form from the start:
what the change refers to: process / location / product / supplier / supplier design,
a description of the change “understandable for humans” – not only a drawing number, but what actually changes,
the reason for the change (cost, quality issue, material availability, customer requirement, design change),
scope: which part numbers, lines, locations, suppliers are affected.
At this stage the goal is not risk analysis. The point is to catch the change and give it an ID you can later come back to.
Step 2 – Impact assessment: “Where can this change hit us?”
Here quality, engineering and sometimes logistics and purchasing step in. This is where change management turns from an “idea” into an evaluated decision.
Questions that must be asked:
Does the change affect critical or significant characteristics?
Does it change the way the product behaves at the customer?
Do process parameters, manufacturing method or inspection method change?
Does the change require re-PPAP or formal notification to the customer?
Does it concern a sub-supplier or their location?
What you actually do:
open the process FMEA and product FMEA (if you co-own the design),
check which entries are linked to the area of the change,
decide whether the FMEA needs to be updated (in many cases the answer is yes),
check the control plan – does it still fit the process after the change?
This is not about rewriting the entire FMEA. It’s about answering one question:
“After this change, is the risk different than before and are the current controls still enough?”
At this stage you create an initial recommendation:
the change is acceptable under certain conditions,
the change is possible, but requires extra actions,
the change is not acceptable in the proposed form.
Step 3 – Decision and required approvals: “Who takes responsibility?”
Without a clear decision, everything hangs in the air. The request exists, the analysis is done, but nobody has actually said “we go ahead” or “we don’t”.
At this stage:
someone responsible for the area (e.g. quality manager, plant manager, engineering manager) makes the decision,
if the change requires customer communication – a decision is taken when and in what form the customer will be informed,
the scope is set: on which parts, lines, locations the change will apply.
For the types of changes mentioned above, a formal customer approval and re-PPAP are often required.
Many companies make a classic mistake here: they implement the change first and only then ask the customer for acceptance, effectively presenting them with a done deal. Reversing that order is much safer.
Step 4 – Validation plan: “How will we check that it works?”
If the change is to move from theory into practice, you need to define clearly how you’ll test it before it becomes the new standard.
Elements that usually go into a validation plan:
production trials (e.g. pilot run on the new line, after relocation, with the new material),
extra measurements and analyses: process capability, MSA for the new gauge / method,
specific functional tests (e.g. in extreme conditions, at the customer, in the lab),
acceptance criteria: what the results must look like so you can say the change is safe.
Example: You move a process to another hall.
The validation plan may include:
comparing Cp/Cpk before and after relocation,
increased control of the first production batches (e.g. under a Safe Launch Plan),
functional tests for batches from the new location,
checking whether environmental conditions affecting the material have changed.
For changes of sub-supplier or supplier design, the validation plan often links your process with the supplier’s process – samples, joint tests, extra incoming inspection.
Step 5 – Preparing production: “Are people and the system ready?”
Before the first batch after the change hits the line, you need to prepare the process environment:
documentation: up-to-date drawing, control plan, work instructions, machine parameters,
labels: clear distinction between the old and new version,
people: operators, maintenance and quality inspectors need to know what is changing and how to spot that something is wrong.
A few practical points:
remove old document versions from circulation – two different drawings in one office is asking for trouble,
make sure traceability can distinguish between the old and new version (different code, cut-over date, batch number range),
prepare a short “start-up” instruction for the change – what to check more frequently, what people should pay particular attention to.
At this stage, change management is on a collision course with everyday reality: if the change lives only in the engineer’s head and not at the workstation, the system starts to fall apart.
Step 6 – Start of production and monitoring after implementation
This is the moment when the change stops being a project and becomes part of normal work. Many companies drop the ball right here – they did the trials, “it looked fine”, topic closed. Without sensible monitoring after implementation, it’s easy to miss signals that only show up after a few days or weeks.
What’s good to have planned:
a period of increased control (e.g. first batches from the new process / location / supplier),
indicators to watch: scrap rate, recurring types of nonconformities, measurement results, customer feedback,
agreed reaction thresholds – when you start corrective actions and when you stop shipments.
Example:
You introduce a new material sub-supplier.
For a defined period you:
carry out additional incoming inspections,
monitor process results in tight time windows,
have a ready plan for what to do if deviations appear: sorting, batch blocking, joint analysis with the supplier.
Only after this monitoring period you can honestly say that the change has “settled” in the process.
Step 7 – Closing the change: “Do we have a trace of what we actually did?”
The last step is often the most boring, but without it it’s hard to come back to the change during an audit or the next modification. What’s good to have in the “change file” at the end:
the original change request with a description of what it was about,
impact assessment results,
decisions and approvals (internal and from the customer),
validation plan and results,
description of post-implementation monitoring (how long, what came out),
the date from which the change is effective and its scope (lines, part numbers, locations, suppliers).
This is not documentation for the sake of documentation. It’s your insurance policy for:
customer or certification audits,
questions like: “When exactly did you implement this change?”,
future changes – you can look back and see how the process reacted last time.
Finally…
In the Templates and tools for effective work section you’ll also find a checklist to use during change management, which you can download for free.
Dariusz Kowalczyk
