Welcome to my blog for all things related to business quality (processes, systems and ways of working), products and product quality, manufacturing and operations management.

This blog is a mixture of real-world experience, ideas, comments and observations that I hope you'll find interesting.



The winds of change…

In a recent blog I wrote about Deviations and Concessions, temporary changes that allow you – when necessary and under control – to not do things the way you normally do them.

But what happens when the change is permanent; how do you manage change?

This is a well-established part of quality management and you may be quite familiar with Change Requests or ECRs (Engineering Change Requests) and Change Orders or ECOs (Engineering Change Orders) or sometimes ECNs i.e. Notes. So, rather than go through the basics, I thought it might be useful to look at some of the issues and subtleties.

What system do you need?

Quality Management Systems invariably have a change control facility built-in, as do Product Lifecycle Management systems (e.g. Agile) and many MRP or ERP systems. There are also many stand-alone systems available.

For organisations that mainly produce documentation, an integrated document control system such as SharePoint or CogniDox (or others) could provide the required version and change control.

For companies that produce software, configuration and version management is crucial and they will probably want to use an established tool, from an open-source system such as CVS or Subversion up to an enterprise-level application such as IBM’s Rational ClearCase.

However, for many hardware-producing companies, if they don’t already have an integrated system for change control they don’t necessarily need to make a large investment; it can be provided via a simple paper or e-forms based system or a DIY database.

How many forms?

Many organisations that take a DIY approach use separate documents or templates or e-forms, etc, for ECRs and ECOs (or ECNs), the former being used to request a change and the latter to implement it. However, some organisations use one single form or template to request a change, assess it (see below), approve and implement it.

You can also use the same process to release products or documents for the first time rather than to change them.

What are the consequences?

All ECRs / ECOs / ECNs should define what needs to change and why. However, for me a key part of change control – and one that is often missed – is to assess the consequences of making the change before you commit to it.

What are the costs, including re-work or scrappage? What effect will it have on timescales? What risks will it introduce? Will it invalidate any approvals or require re-testing? Will customer, sales or marketing documentation need to be changed? Will customers need to be advised (does it affect compatibility with other products)? Will test systems need to be changed? Will production systems need to be changed? Will you need to swap-out sales or production product samples?

Any actions resulting from these consequences will need to be properly managed if the change is implemented.

You will want to make sure these questions are asked and the results and actions agreed by all the ECR / ECO signatories who must cover all the relevant parts of the business and must agree that the change is worthwhile after taking into account all these consequences…

Who signs it, and why?

How often do you see these things being signed without the person actually reading the document? Are people signing to say they are merely aware of the document’s existence or to say they take full responsibility for everything contained within, including costs and consequences?

Here’s a thought – if you are designing a template or form that has sign-off boxes, write down exactly what each signatory should check and sign for. Make it explicit, then it can becomes a meaningful process rather than tokenism. (Then use internal audits to verify they are doing it right!)

How do you know the change has been made?

You make be able to implement the change immediately or you may have to wait until a certain time, or after a certain number of units has been produced, or at a certain product serial number.

Your system should allow this cut-in point to be specified; you should ‘close the loop’ and make sure that the implementing of the change is recorded as proof that it was done correctly.

How do you keep track of what has changed?

You may have very few changes in what you do and may not need anything other than a record of the changes having been made. Lucky you! However, for many companies the changes accumulate and become complex to administer, especially if using third parties and especially for low volume, high mix products.

How do you know what changes were applied to product XX, serial number ABC12345? How do you know what changes the system shipped to Customer YY on 08/04/2009 had applied to it? Can you identify all the products shipped with Change ZZZ applied to them?

There are two main ways of answering these questions. The first requires a detective job in which you cross-check build records, change control cut-in dates, serial numbers, etc, etc, and work out what changes applied to any given item. It can be painful and slow, but it’s the way that many companies do it.

The second is to fully manage product configuration; you keep a record of what changes / deviations / concessions / etc, and often what specific subassemblies or parts, are applied to every single product. This is more difficult to do, requiring more comprehensive systems or databases, but gives better traceability and is a must-do for high integrity / high safety systems; only you can decide if it is worthwhile for your business.

I hope this has given a few useful pointers as to how Change Control can best meet your requirements. For many organisations it doesn’t need to be complex, but to be meaningful and effective it has to go beyond mere tokenism; you should be actively managing change, not merely watching it wander, out of control, past the window!

Leave a Reply




You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>