FREE ARTICLES & WHITE
Setting the Stage for Innovation
Management - What is it?
5c. Product Quality
& Deviations from Specs
5d. Significance in
5e. Why EDC/CM?
By: Frank Watts, BSME, CCM
5a. Setting the Stage for Innovation - (TOP
APICS e-news Feb 2005
The raw materials for product manufacturing are tools (including
software), people and the design documents. Still, most companies
have a gap between Engineering and Manufacturing / Operations
people, processes and systems with regard to design documents.
Engineering people tend to be very analytical and cautious. Manufacturing
people tend to be movers and doers. Manufacturing people say
that engineers frequently, "throw it over the wall".
Engineering people say they, "can't find anyone who knows
how the product will be processed". Manufacturing folks
say, "Engineering is always changing the design". While
Engineering people say, "Manufacturing people are always
changing the process". Their respective processes tend to
end at the waters edge, sometimes with endless team meetings
intended to bridge the gap between them.
Manufacturing folks have purchased MRP/ERP systems and Supply
Chain systems. Engineering purchased CAD, PDM and PLM systems.
These systems seldom "talk to each other". Multiple
Bills of Material and other major problems result.
A plethora of manufacturing and supply chain papers, articles
and software programs seem to assume the availability of the
right documentation, at the right place, at the right time.
Many folks are caught up in the "buy a system to solve the
problem" mode. Few seem to be working on bridging the gap
/ tearing down the wall between engineering and operations.
Note what Morris and Brandon wrote in Re-engineering Your Business;
"To be sure, information technology was used to support
the new process, but the process redesign came first and the
technology considerations second." Also what Mitch Ratcliffe
wrote in Technology Review; "A computer lets you make more
mistakes faster than any invention in human history - - with
the possible exceptions of handguns and tequila."
Yes, software solutions can help us get the right document to
the right place at the right time, if (that big word) we have
a process in place requiring that to happen. Much more attention
needs to be focused on the design documentation processes before
jumping to "the software solution". This is true whether
we are talking about manufacturing in house or via the supply
chain. One needs only to analyze the root cause for "bad
parts" that end up on the dock or the manufacturing floor.
Or analyze the root cause for customers that sometimes receive
a different configuration of a product than they wanted. Why
do materials/supply chain people often have parts they don't
need and/or are short parts they do need? How many of the product
changes are thought to be "cost reductions" but aren't?
This writer's experience says that the technical document processes,
or lack thereof, are the root cause of a vast majority of many
We need to bridge the gap between engineering and manufacturing
people, processes and systems. Design the engineering documentation
processes first, establish meaningful metrics, streamline the
processes with legacy systems, then seek new software to facilitate
that process design. Focusing on the processes first is the next
great frontier for continuous improvement.
Copyright Frank B Watts Feb 2005
5b. Configuration Management - What is
it? - (TOP OF PAGE)
Midrange Enterprise - Sept 98 Issue
Defining Configuration Management (CM) is very much like
the old story about the Company President hiring a Controller.
Each applicant was asked: "what is two and two?". The
person that was hired answered: "what do you want it to
be?" In some companies CM is a clerical function that keeps
document files. The next company might keep files and process
/ facilitate the design changes. Folks doing DOD or FDA business
have extensive organizations that control every aspect of the
product configuration as required by specifications and contracts.
A few commercial product manufacturing operations have tight
controls on all the interfaces between Engineering and Manufacturing.
The DOD / military folks invented the CM term. Most commercial
enterprises use the term Engineering Documentation Control (EDC).
Since we engineers hate the word "control", the military
term is superior in that regard. There are some who say that
if the proper data processing applications are in place, then
no CM / EDC is needed. Since the writer has not witnessed such
a utopian environment, the conclusion must be that it is like
"paperless systems" - a good long term goal but we
would currently be satisfied with "less paper". Some
folks use boards or teams in the processes, some don't. The natural
conclusion is that CM / Document Control is whatever you want
it to be.
What should you want it to be? The answer varies with the size
of the operation, the culture, the organization structure, the
legacy software applications, regulating agency requirements
and the experiences of the management. In general, it is the
function that bridges the gap (or tears down the wall) between
Engineering and Manufacturing. An interface between Engineering
and the rest of the company. A company that has Engineering and
Manufacturing in the same small business unit is thus going to
have a different answer than a company that designs in the US
and manufactures in several domestic and international sites.
A small operation might not need a change request process where
as a large operation probably does. A company regulated by the
FDA has different traceability requirements than one working
to industry standards. If the management has seen boards in their
prior experience then a board seems to be a necessity. It is
easier to attain shallow BOM structures in a JIT manufacturing
operation than in traditional manufacturing. What do you want
it to be?
Since processes are the essence of business, the answer would
lie in defining the CM/EDC the processes. If we look carefully
at the interface between Engineering and the rest of the company
there are four processes at work. 1. The new product / part /
assembly / document creation and release (called the "Release
Process") 2. The creation, structuring and control of the
Bills of Materials (the "BOM Process"). 3. The requesting
of engineering changes (the Request Process"), and 4. The
making of engineering changes (the Change Process"). So
what you should want "it" to be is four processes -
each fast, accurate, efficient, properly documented and well
These processes touch the very soles of the Engineering, Materials,
Production, Purchasing, Service, QA, Order Entry, Publications
and other company functions. This cross functional nature of
these four processes makes the CM / EDC discipline a very hard
discipline to define, let alone to control. On top of this complication,
add the fact that several of these functions have documentation
that can easily be defined as "engineering" documents.
Often times a product design document will contain manufacturing
process information / specification. Who should control these
documents? Should they all be controlled identically? If all
engineering documents are not controlled by the same department,
how is it all tied together? Thus the plot thickens. Small /
start up companies often give the control of Engineering, Manufacturing,
Publications, and Quality documents to the same department. In
small operations the manufacturing process responsibilities often
lie with the design engineers. They may not have a quality engineer
nor a publications person. As companies grow however, the quandary
develops. "Too many cooks spoil the broth" goes the
old saying. But shouldn't the documents be controlled by the
group that authors the document? What if a design change affects
several functions and documents? In this writers opinion, technical
documentation should be controlled by the department which authors
them. This would mean that there are several document control
functions. Engineering would control design documents, Manufacturing
would control process documents, Quality would control quality
documents, and Publications would control service documents,
etc. This requires a standard to list all the technical documents
and the corresponding responsible function. How are they tied
together? One function should be designated the Configuration
Management function. That function would assure that minimum
control is exercised and that the methods used in the individual
document control function are not in conflict. That function
would assure that the processes are in place to attain the fast,
accurate and well understood results. When a design document
is released the process would assure that the affected functions
are involved in that items development, that the author signs
the document, that the proper "acceptor" (primary user)
signs the document, and that those who need to know are informed
of its release. When a design change is made that function would
assure these same events occur and it would also assure that
the change to the design documents are not held up while the
other documents are being assessed / changed. In other words,
the CM function would develop the standards and flow diagrams
to designate the fast and accurate processes. They would also
assure that the necessary training takes place to make the processes
well understood. Thus the CM function develops the policy, standards,
forms, form instruction and flow diagrams (a picture is better
than a procedure) required for all four processes and trains
all those necessary about those processes. The CM function would
also measure the processes speed, volume, quality and report
to the management on these measures of merit.
But will the various regulating agencies and ISO / QS / AS accept
this arrangement? Their specs do seem to encourage but do not
seem to prohibit distributed control. Personal experience, consulting
experience and seminar customer's reports indicate that distributed
control is acceptable providing the overall minimum control is
present. There seems to be a high amount of pressure from some
regulators to "do it all in the same group". It is
convenient for them if all the control is done in the same group
but is it best for the company?
Thus, Configuration Management will be whatever you want it to
be and you should want it to be four fast, accurate and well
©1998 Frank Watts
Quality and Deviations from Specs -
(TOP OF PAGE)
White Paper, By Frank Watts, April 2009
Deviations, Waivers, Variances, Off-Specs and Concessions
- are all names for bad things. How can they be bad, almost every
product manufacturing company uses them? Well, almost every company
also fails to calculate the cost payback on so-called "cost
reductions". Does near universal practice make it best practice?
When the discrepant material process identifies material which
doesn't meet specifications it should properly be set aside and
promptly examined by a small team of engineers - one from quality,
manufacturing and design. Now is the time for some tough questions.
Are the dimensions, tolerances and other specifications correct
- best for the company and customer? If not, they should be changed.
If so, the material should be reworked to spec, returned to the
supplier, or scrapped. Thus no Deviation process is needed. This
is the practice in a very few companies that are really serious
about the quality of the product.
Further, if the specifications are to be changed, the change
order should be completely processed before the material is released
for use. This is best practice simply because release of the
material first will make the material disposition process a quick
way to make a design change. The change order may never happen
or when it happens, the configuration allowed may be different
than the released parts. Thus, the configuration of shipped material
may be lost to posterity. Thus, the future troubleshooting of
those parts will have a real world configuration unseen and unknown.
Unfortunately the pressures to meet schedule, especially near
the end of the month, cause these practices to prosper. The next
thing that happens is simply human nature faced with a slow change
processing system. The Deviation by whatever name, becomes a
way to make fast design changes. When the "formal"
way of making changes is slow, painful and convoluted, there
is often one or more ways around that system and the Deviation
is usually one of them.
If / when deviations are allowed, they should be posted in the
revision block of the affected drawings or specs. This provides
knowledge of their existence to the engineer faced with a troubleshooting
task at some future time - important in that they may have caused
the problem being investigated.
Thus it is critical that the change process be made fast, accurate,
documented, measured and well understood. Then the Deviation
process can be eliminated - a sure sign of a quality oriented
in Part Numbers -
(TOP OF PAGE)
(print date unknown
- Mid Range Enterprise)
There are zealots on both sides of the issue concerning significance
in part numbers. Most product manufacturing enterprises, at one
time or another have had this controversy. Every new start up
has this issue. The issue permeates the operation. It crosses
all functional lines. Some say that significance (smart number)
is the only way to go. Others say that non-significance (dumb
number) is the only way to go. In this writer's opinion, either
extreme is generally wrong. A generalization for items from the
top level to the bottom level of your structure cannot be made
to stand the test of logic. Also any discussion of part number
design without inclusion of interchangeability consideration
While believing in minimum significance, this writer would submit
that at the top level - your product level - the smart number
might make very good sense for products with few features and
options. Consider the company wherein the salesman structures
a smart number from a catalog when determining what features
and options the customer wishes (catalog configured). Should
we take the order by catalog number and have Order Entry convert
it into a factory part number? Won't the conversion inject a
possibility of error into the process? When the conversion error
occurs (and it will), the customer will receive something different
than they wanted - an intolerable situation. In this circumstance
why not use the configured catalog number as the top level /
end item number in the system. If maintaining a catalog works
for you, look seriously at using that smart catalog number as
your end item number. The same logic might apply to other "configurable
assemblies" within the product that are separate line items
on your sales order.
If your catalog is too difficult to maintain because of numerous
/ added / changing features, then a minimum significant number
for the top level (and configurable assemblies) would be in order.
A modular bill of material or configurator module (essentially
no part number) at the top level could be the answer.
Before exploring lower level items let's ask ourselves "why
significance at all?" The temptation to use a significant
part number is high. The significant part number helps us to
find similar parts. If we don't have significance in the part
number, how do we search to find similar parts? How do we avoid
reinventing the wheel? How do we find a temporary substitute
for a part shortage? How do we know which parts might be manufactured
in a single cell? Or perhaps your history has produced several
part numbers for interchangeable items (17 at one company) and
you want to standardize.
A group technology or class code system (smart numbers) outside
the part number is sometimes the answer. With the power of computer
word searches, an intelligent description field or "naming
convention" (another form of class coding) might be the
answer. With the advent of low cost computing, it might be better
to set up a database with a separate field for each characteristic
that might have otherwise been put into a significant part number.
Then searches can easily be done on those fields. If you are
a new company, or if your smart number has broken down, or you
are merging several operations into one, a good rule to follow
Rule: Put very little significance into the part number
with the possible exception of end items with few features and
Reason: Because significant numbering systems tend to
breakdown. No matter how good you are at anticipating the number
of digits you will set aside for a given characteristic, at some
point it won't be enough. There are many pros and cons to each
practice but the potential breakdown of the significance is the
The next question that should be addressed is whether or not
a separate drawing or document number is required. Many companies
have established (legacy) systems with separate numbers on parts
and documents. This requires cross-references to manage to navigate
from one to the other. If you have this system and it works for
you, don't change it. Again however, if you are a new company,
your smart number has broken down or you are merging several
operations into one and seeking a single part numbering system
a good rule to follow would be:
Rule: Embed the document number in the part number.
Reason: Cross-referencing takes an instant at best. Multiply
that instant times all the people that will have to cross reference
(both ways) for the rest of their lives and their replacement's
This also tends to tear down that wall that often develops between
engineering and manufacturing. They both would use the same number
- what a simple but powerful communication bridge! Face it, embedding
the document number in the part number is a form of significance
even when it is a serial / dumb number.
Last but not least the question must be asked; "what if
we change an item after release non-interchangeably?" The
part number should change. Ever since Eli Whitney, non-interchangeable
changes meant a different part number (in one or more characters).
Some operations say "We don't change part numbers - only
document revisions!" This is a very expensive policy. It
works fine when the product is young and most changes are required
to meet specifications. But what about the mature product wherein
most changes are made to reduce cost? You certainly don't want
to retrofit cost reductions, so we better find the best way to
accomplish part number changes.
Think of all those folks that memorize part numbers - and there
are lots of them. Are we going to ask them to rip the old number
out of their memory and insert a completely new one? The answer
is to attach a "tab" or "dash" number on
the part / document number. One or two digits should do most
operations quite nicely. These digits can also serve to document
similar items on the same document - a basic form of class coding.
Thus on a non-interchangeable change the number would change
from "01" to "02" and a new document is not
needed. It also allows the document revision level to be set
aside for document only and interchangeable changes.
This writer would submit that a part number without a dash is
like a ship without a rudder! Thus the "ideal part number"
would be a format as follows: YYYYYZZ
Where "Y" is a sequential (dumb) document number and
where "Z" is a dash / tab number ("smart")
- all numeric. Together they make up a part number. Thus another
Rule: Always tabulate the part number. If you have an
existing system that does not include this feature, add it as
soon as practical.
Reason: Saves some labor to prepare documents and to revise
them. Allows changing the tab upon non-interchangeable change
and thus is friendly to those many people who memorize part numbers.
Takes away an excuse for not changing part numbers on non-interchangeable
If a company has a couple digits of class code in their current
part number it might be serving them quite well and thus shouldn't
be tampered with. If you have a class code prefix of a couple
of digits of alpha or numeric it would be acceptable to keep
it, especially if that allows you to "sell" the new
Thus the number would be: XXYYYYYZZ where "X" is the
legacy class code.
The total length of the number must a consideration if you are
living with an eight digit limited DOS system. The shorter the
better for minimizing errors as well.
Thus the ideal part number is significant by virtue of embedding
the document number and having a tab suffix. As stated before
the significant part number may have proper use at the top level
in some companies. It is therefore this writer's opinion that
a wise part numbering system may not be either totally significant
or totally non-significant but have "minimum significance".
©1999 Frank Watts
EDC/CM? - (TOP OF PAGE)
CM is a strategic company discipline. It is the bridge between
Engineering and the rest of the company - Manufacturing Operations,
Field Service, QA, Materials/Production Control, Sales, OPrder
Entry, etc. All product manufacturing companies need a function
(part of a person, a person or several people) to be designated
as a CM function. What are the benefits of doing "best in
class" Engineering Document Control / Configuration Management?
It may be better to ask; "What are the pitfalls / undesirable
results / pain of not doing best in class EDC /CM?"
· Companies that have ISO certification believe that they
have the document control / CM "bases covered". In
fact they have only taken the first step out of Chaos. ISO doesn't
care if the processes are fast, efficient/productive, measured
- · Every engineer or designer left to be responsible
for their own doc control not only results in chaos (as many
processes as there are engineers/designers) but it fosters a
climate where it is all too easy to violate basic principles
for expeditious release or change. Example: The Materials/Purchasing/Supplier
need the part drawing/change now because it is a long lead item
required to meet the company schedule. The engineer decides that
it is OK to give the drawing to the supplier even though it hasn't
been reviewed by the team and properly released. The result -
oops - a quarter of a million dollars worth of parts show up
on the dock and are found to be unusable.
- · Any engineer allowed to assign the next revision
level is a truly uncontrolled environment: - same risk as above
with more bad parts on the dock or added supplier cost/waste
that the OEM ends up paying for. The engineer will sometimes
forget to change the rev level on his design drawing and the
supplier builds to an older print. Still more bad parts. If CM
/ Engineering Document Control doesn't have rev control, you
do not have control.
- · The engineers work directly with the supplier and
give them design and development drawings without the team or
buyer knowledge - Result; 1. The best supplier for production
purposes might not be chosen. 2. The best price for prototype,
pilot or production units might not be obtained because the buyer
is now negotiating "from jail".
- · Cross references: Example - doc number to part number
& part number to doc number - are insedious wasters of time.
Result: It only takes a few key strokes to do the cross-referencing
but are talking about a few key strokes every time any person
has one and needs the other, every user, forever! Yes, some CM
decisions can be "forever". Key- strokes do add up!
Cross references are generally evil and can be avoided by proper
process design. One seminar attendee from a medium sized division
reported that the calculated cost of having the document number
separate from the part number resulted in $23,000 in added key
strokes every year.
- · Source (sole or multiple) is sometimes placed on
the vendor document itself. Thus the supplier knows that they
are sole source or they know who their competition is. The result:
usually more costly parts than if the source is contained in
an Approved Manufacturers List and not readily available to the
- · Part numbers that aren't "tabulated",
cause multiple documents to be created for similar items and
costs increase because "reinventing the wheel" is difficult
to avoid. Purchasing buys in smaller, more costly lots. One company
had seventeen different part numbers for the same item. What
did that cost, just in terms of the purchase price? There is
also much resistance to changing part numbers on non-interchangeable
changes if the part number isn't tabulated.
- · Perceived problems in the CM processes are often
addressed by buying more data processing software. The Result:
Bad processes executed faster. An attempt to solve process problems
with systems solutions is a touch of insanity. Processes should
be addressed first, brought to a reasonably fast and well understood
condition and then automated.
- Release Process
· The company release process & phases
are often ill defined. Result: Hours and hours of team time are
wasted because different members understand the terms and process
- · There is often no correlation between the engineering
defined phases of product development and the company phases
of documentation release and control. Result: The non-engineering
people are not "in-sinc" with the engineers and their
management. The process is slowed and the market window gets
smaller. Bad parts result. Hours of clarification discussions
result. Finger pointing is rampant.
- · The lack of or poor utilization of cross-functional
teams results in designs that are costly or impossible to manufacture
by suppliers or the fabrication shop. Assembly test, packaging
time is increased and/or disrupted because their needs have not
been considered "up front" in the process. Problems
are found one or more phases after they might be, thus being
several times more costly to correct - "The rule of Tens".
- · No pilot / sample / soft tool phase exists in the
company. Designs are taken directly from development / prototype
into production. Result: The early units in the production process
experience design / process problems that should have been caught
in a pilot phase. Since parts are now being purchased, produced
and assembled in production quantities, the cost of correcting
those problems is now ten times as expensive as they should have
been - "The rule of Tens".
- · Manufacturing creates "Planning BOMs"
for long lead part ordering via MRP/ERP because Engineering doesn't
want to release those parts. Engineering doesn't want to release
those parts because the change process is so painful &/or
slow. Sometimes simply because they don't understand the need.
The result - Manufacturing is taking the risk for Engineering's
late release/slow/cumbersome change process. Hugh potential for
buying building an item that has known problems in the design
or documentation - more wasted parts cost and labor costs. The
risk is solely in manufacturing while it should be a shared (company)
- · A significant portion of the "bone piles"
in manufacturing are traceable to release phase confusion. The
documents and the data base must reflect the release status precisely,
in order for limited quantities to be purchased or made for prototype
or pilot phases.
- · Often the product specification is circulating between
Engineering and Marketing with red marks all over them. This
"bleading" on the product spec often occurs well into
production. What are the engineers designing? What is test engineering
planning to test? What is manufacturing engineering planning
to process? Are we buying parts that will contribute to the proper
product? Is sales selling product that is different than engineering
can / is designing? What do those false starts and confusion
- · The chief engineer is usually responsible for the
new product release process. He or she is engrossed in the hardware,
firmware and software development and evolution. Who is relating
that complex process to the documentation release and the operation
and integration of a cross functional team. Who is assuring that
the documents and databases reflect the proper release phase
in order to avoid many of the issues mentioned above? Need a
part time or full time CM function/manager?
- Bill of Material Process
· The sales people often use different product identification
than Engineering and Manufacturing. Result: Someone in Order
Entry tries to convert the customer needs into Engineering and
Manufacturing numbers. Thus errors are made resulting in the
customer receiving something different than they ordered. What
is one unhappy customer worth?
- · Often a conscious decision as to which items will
be designated "service parts" is not made. The result:
Customers are lead to believe that all parts and assemblies are
available on a fast turn-around basis. This sets the stage for
more unhappy customers. It also promotes an underground stock
of items taken from the store room or work in process to satisfy
customer needs. Result: The production schedule is missed because
we have robbed Peter to pay Paul.
- · Hours and hours of time that could be spent improving
product or processes are spent debating interchangeability issues
and part number change issues. Good interchangeability rules/standards/logic
will not eliminate the debate but will significantly limit it.
The service people end up with bone piles of material because
of the confusion created. Failure to change part numbers upon
non-interchangeable change leads to a decision to "up-grade
to the latest revision level" - a hugely expensive decision.
Is upgrading a cost reduction a cost reduction? Is installing
a product improvement in all products cost effective or wise?
- · Physically separating inventories by revision level
and physical marking of parts by revision level (expensive processes)
are often the results of poor interchangeability standards /
understanding. Parts don't have revs, documents do!
- · When BOM control is organizationally separate from
design document control, the result puts the respective documents
out of synchronization, resulting in errors and confusion. More
bad parts and wasted labor.
- · Different BOM structures used by different organizations
deepens the gap between those organizations and costs many hours
of clarification time and continued finger pointing. Agreement
on a single structure shouldn't require rocket science.
- · Multiple BOMs for similar products results in duplicate
BOM changes that increase change time and error potential.
- · Often BOMs/Parts Lists are maintained in CAD, PDM,
Publications, MRP/ERP, Process Modules, etc., etc.. Multiple
data entry of BOM parts list data is not only a waste of data
entry time but results in extra effort to reconcile those data
bases. Or left un-reconciled, many material purchase, fabrication,
stocking and assembly errors are created and wasted efforts result
and/or schedules are missed. Sometimes multiple BOMs allow bad
design decisions to be made by someone other than the Design
- · Multiple levels are often introduced in order to
produce a BOM that meets all needs. The result is a very difficult
and costly BOM to maintain. Shallow BOMs are better BOMs. Sometimes
an assembly level is introduced so that the item can be "stocked"
thus resulting in company assets being put into a warehouse out
of sight and out of mind. Inventory carrying costs are estimated
to be as high as 35% of product cost. What would be the savings
if we could reduce stocks of assemblies and bring down the carrying
cost just five points?
- Change Request Process
· Many companies have a statement in their standards which
claim that "any employee can originate a change". This
statement is usually patently untrue. Many employees do not know
how to originate a change to the drawings, specifications, processes,
etc. Thus, many issues go unresolved and are managed by added
labor, parts or by flatly ignoring the documentation - "Redline
it and let's move on!"
- · Often every change request is treated as "an
automatic need to change". Far too many cost reductions
aren't and many products that don't need to be improved are!
One company had eleven "Continuing Engineers" processing
changes. Analysis showed that an equivalent of four engineers
were processing requests / changes (that were called cost reductions
/ save time / ease of / etc.) which didn't have payback within
the newly determined time period. Another three engineers were
improving products that didn't need to be approved based on a
newly stated policy about which products should / shouldn't be
improved. One of these people was used to calculate the cost
/ payback of requests. Six engineers were returned to research
and development engineering - a windfall of badly needed people.
- · Most request processes do not make it clear as to
when the Engineering organization takes ownership of manufacturing,
service, QA, Sales, and others problems / suggestions. The result
is a pile of requests laying in Engineering but which Engineering
doesn't feel responsible for. Frustration and even anger on the
other side of the bridge results. If your engineers are avoiding
trips into production, you may have this problem.
- · Failure to review requests and proposed solution
by a cross functional team results in a lost opportunity. Ideas
for help in: the design, rejecting unnecessary requests, a better
fix, manufacturability issues, standard part usage, etc. are
not available to the engineer before they put fingers to keyboard.
- · Engineering does not have unlimited manpower and
we need to quit treating requests as if they did!
- Change Control Process
· Slow change control processes are the most frequent
and insidious problems in the EDC / CM discipline. As already
stated they discourage engineers from releasing documents in
lead-time. The slow change process also:
1. Delays the incorporation of real cost reductions.
2. Delays the change that fixes a customer problem.
3. Delays the availability of a new feature or option.
4. Delays the fix for a field service problem.
5. Increases the bone piles of down level material due to change.
6. Increases the rework / scrap on changes so dispositioned.
7. Increases the work around or line down time on fixes for the
8. Increases purchased item cost because the suppliers have problems
# 5, 6 and 7.
9. Increases the units that will require retrofit in the field.
(ten time more expensive than if changed in production)
10. Causes one or more fast change processes to be created -
followed by the formal process. Thus, the change is documented
twice or, worse yet, the fast change goes undocumented (a troubleshooting
- · The CCB (Change Control Board) meets after
the engineer has investigated, analyzed, estimated, conjured,
re-designed and documented a fix. The team seems to be second
guessing the engineer. They are, or would like to! Bad feelings,
finger pointing, swearing and sometimes even physical confrontations
result. Painful moments in these meetings. Was there team input
during the Request Process? If not, shouldn't the team meet to
discuss the change before the engineer puts fingers to keyboard?
- · The point at which the change is technically released
is usually unclear. The fix can be "fixed"/changed
at any time. This process allows the engineer to launch untested/incomplete
changes. Sometimes the Designers make/add new changes to the
change when they are updating the masters. Sometimes engineers
make changes / additions when they are called on to sign the
revision block. An inefficient and poor culture? Often a rule
is made that the MRP/ERP won't be updated until the revised documents
are signed and released. This rule then creates an atmosphere
that discourages any parallel implementation activity to shorten
process and implementation time.
- · Failure to properly disposition old design parts
(in Manufacturing, Service and at Suppliers) during the design
change process contributes to the "bone pile" of down
level material. Often thousands of dollars of material exists
in limbo which might have been used, reworked, returned to the
supplier or scrapped on a timely basis. Is the supplier more
likely to give some return credit today of some months later?
- · Who signs and how many sign a change is often a
divisive issue. How can anyone affected by a change be denied
a signature? It is universally believed among EDC/CM people that
more signatures add significantly to the process time/cost but
add little to the quality of the change. Signers are absent from
the CCB and add a week to the process. Often the signers watch
for "Charlie" to sign and when he does, they will.
Is this a bit of insanity?
- · While the formal slow process creeps along, the
"redline change" is done on the production floor with
one or two signatures. The formal change may never be processed.
When it is, the formal change often looks somewhat different
than the floor change. Thus the floor configuration is undocumented.
Why not make two redlines, get and ECO number on the redlines
and require the now formal change to be in CM within 24 hours?
Do it once, fast, by the formal process.
- · Bundling of the Manufacturing Process Docs and Service
Docs into the design change before release is a common practice
that makes the change process very slow. The Design Change needs
to be completed first and the other documents completed as a
second step in the process. This will speed up the process and
eliminate considerable finger pointing. This doesn't go to say
that the teams shouldn't be involved in the process early on.
- · Failure to trace certain changes to their effective
date/serial number/etc. leaves the service and design engineers
with a time consuming quandary when later dealing with a failure
problem. Given a failed unit(s), did a change fix the problem
or could a change have caused the problem?
- · Failure to make Field Change/Retrofit decisions
during the change process leads to an abdication of the decision
- usually to the Service function - often excluding the Engineering
function and the change team. The result is costly retrofit of
changes that may not need to be retrofit.
- · Everyone knows the change process is long, painful,
costly, divisive and somewhat insane but no one seems to be responsible
for the process. Management folks often use the change process
as a crutch - because there are many functions involved - it
is frequently stated; "Everyone knows how screwed up that
process is!" Should a single person be given responsibility
and authority to improve the process with or without a small
team to assist? What a concept? What will we call him or her?
Maybe Configuration Management!
©Dec 2002 Frank Watts
5f. Interchangeability - (TOP
(ACDM Journal Date? Updated
Can interchangeability be defined in a phrase such as form,
fit and function? How about a page or two? Perhaps we could develop
a definition of interchangeability in a page or two but how about
the question as to when to / not to change part numbers? When
addressing the part number change in light of service parts requirements
the plot thickens. The discussion of interchangeability in my
book takes eighteen pages including one figure. I would submit
that anything less will lead to improper conclusions. It is a
subject that this writer finds difficult even to discuss generally
in a magazine length article. Allow me then to deal here only
with some of the myths on the topic.
"We follow Fit, Form and Function rules!" I ask
my seminar students if that doesn't mean that any change that
affects fit, form or function is non-interchangeable? In other
words any change that affects the product is non-interchangeable.
I challenge them to think of any change that affects the product
that one cannot say affects fit, form (appearance) or function.
They are hard pressed to come up with a rare example. Some materials
changes perform identically and do not appear different - but
beyond such changes, what others. After some discussion they
agree that saying form, fit and function is not enough. Tightening
a tolerance does affect fit but the old and new may be totally
interchanged? If it looks different is that a sufficient criteria
to say non-interchangeable? No - some appearance issues are important
to customers and some aren't. If the product is improved in some
regard over and above the functional spec, is that non-interchangeable?
Not in my mind! What if the change is to meet spec? Then I'd
say it is not interchangeable.
Some say that if the process by which the part is produced
is affected then the change is non-interchangeable and the part
number should change. Allow me to submit that interchangeability
and changing part numbers has nothing to do with the process
by which a part is produced. Not even in a medical product environment
where the FDA has a paranoia about the process by which an item
is produced (a carry over from their beginnings in the drug world)
should that be an issue of interchangeability/part number change.
If it were, then when a process is automated - with a robot for
example - we would have to change all the part numbers involved.
The parts do not know what process they were produced by. They
do not know if they were produced by a man at a lathe or a CNC
machine. The assembly doesn't know if the sequence of assembly
was changed. The process by which the part or assembly is produced
therefor has no bearing on interchangeability.
It is written in DOD specs that any change which will affect
the pricing will be a "Class I" - implied non-interchangeable.
Now the government has a perfect right and some reason to do
this but that doesn't make the change necessarily non-interchangeable.
DOD contractors must do what the agency wants but price doesn't
necessarily correspond to non-interchangeability - no relationship!
One magazine article said; "Assign a new part number
whenever the part has been fundamentally altered." This
begs the question as to what a fundamental alteration is? The
answer should be; have we affected the interchangeability of
the old and new parts. A clear, crisp definition is needed to
further define fit per the drawing dimensions and tolerances,
form and function per the product specifications. In the old
days we called this "a dimension and tolerance stack-up"
The product specifications must be inclusive of reliability
and safety requirements.
Often times the issue of changing part numbers and interchangeability
get commingled. Avoid getting the cart in front of the horse.
First decide if the change is interchangeable or not and then
decide whether or not to change part numbers. They are separable
decisions and should be made in exactly that order.
Many engineers resist changing part numbers. They understand
each and every change and often want only to change the document
rev and be done. They understand very well (they think) which
revs are interchangeable with prior revs and which aren't - just
ask them. Other folks say; "Just change the part number(s)
to be sure!" Both extremes are unworkable. In either case,
a rule usually follows which says we must rework everything to
the latest rev/part number. This is a policy that works OK in
the early life of the product because almost all changes early
on are made to meet spec - thus non-interchangeable. But later
on, this will result in retrofitting cost reductions (making
them cost additions) and changes to improve the product - some
of which you may wish to retrofit but, just as certainly, many
of which need not be retrofitted. Such policy is very expensive,
so why not distinguish interchangeability in the beginning and
change the part number when necessary? Engineers must bow to
customer and service considerations.
Often resistance to changing part numbers comes from company
people who memorize part numbers - and there are a lot of them.
If you ask them to rip a whole part number out of their head
and insert a complete new one they will resist. This is the primary
reason why I advocate a tab number on all part numbers. Thus
the tab can change while the base number stays the same. The
"memorizers" can handle the tab change.
Some say that if the new design is "compatible"
then we don't need to change part numbers. Compatible means (to
most engineers) that the new can be used in place of the old.
This is a condition that should be identified on service parts
especially because it allows the service people to quit ordering
the old and only order the new. This cannot be practically done
without a part number change, however. Another way of looking
at the same issue; if the old part (returned from a customer
or out of service stock or a cannibalized unit) can't be used
to replace the new part (both way interchangeable) then the part
number should change.
Are there times when the parts are non-interchangeable but
we don't need to change part number? This writer thinks so! For
example if we are in Design and Development Phase, I would not
change part numbers. If in Pilot Production, consider the rule
"If one unit is shipped - yes", and "If none are
shipped and Production agrees to find and fix all pilot units
(and they should), then - no!"
Any part can ultimately be sold even though we haven't placed
it on the service part list. So the general rule for non-interchangeable
change is that items should change part number after shipment
of the first unit. Even then there are exceptions. Parts of inseparable
assemblies (such as a Weldment) won't be sold or serviced and
thus don't have to change part numbers.
When discussing part number changes, the question arises as
to "Don't we have to change the next higher assemble?, and
the next?, right up to the end item? This is a process that I
refer to as part number "rolling". Many companies also
adopt a policy of rolling revs. I call such policies a "touch
of insanity". This writer would encourage you to examine
all assemblies and place the service level assemblies on the
spare parts list. Only change part numbers (upon non-interchangeable
change) of those assemblies that are service level (sometimes
called FRUs - Field Replaceable Units). See the logic diagram
in my book.
At the end item level, adopt a rule that says we won't change
the end item part number (even if it is non-interchangeable)
- by policy. There are too many issues with UL/CSA/etc, regulators
and customers that compel us to keep the same end item number.
The exceptions to this rule would be if Marketing wants to sell
both old and new designs or the customer insists. This discussion
presumes that you have a method for tracking non-interchangeable
changes (and other such changes as you or your regulators require)
to the end unit. That is, you can tell the critical configuration
(non-interchangeable changes) of each unit.
The most important conclusion that this writer hopes you will
make is to read all eighteen pages on interchangeability, study
them, ask questions and then develop your own definition, rules
and part number change logic diagram for your own circumstances.
Keep in mind that Eli Whitney told this writer (I knew him well!)
that this isn't an easy subject and even developing such a standard
won't eliminate all the debate. It will merely reduce the debate
to a manageable level. It can be done. I've received glowing
reports of step function reductions in debate time, servicing
/ repair costs and finger pointing by adoption of make sense
standards and training.
© Frank Watts Sept 2012
BACK TO LITERATURE PAGE
MANAGEMENT HOME PAGE
©1999 Frank Watts - Copyright
material may be copied from this site for your one time personal
use. Do not reproduce. All rights reserved. Others may visit
this site to obtain a copy.