FREE ARTICLES & WHITE PAPERS

5a. Setting the Stage for Innovation - (TOP OF PAGE)
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 manufacturing problems.
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.

Frank B Watts, BSME, CCDM
copyright EC3 Corp 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 understood.
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 understood processes.

Frank Watts ©1998 EC3 Corp

5c. The Orphan Discipline - (TOP OF PAGE)
Published in the ACDM Journal 3Q2002

Who but a few of we hard-core CMers has even heard of Configuration Management? Isn't that something that software folks do? It's a military term isn't it? Oh yes, my past company had lots of that red tape in order to sell to the government! If we talk about Engineering Documentation Control (EDC) they might begin to get the drift. Even then, many will say; "Oh sure, that clerical function that takes care of the drawings!"

Colleges and Universities don't teach EDC/CM. The manufacturing / production side of the business (as represented by their primary organization - APICS), hardly notices the EDC/CM discipline. Their magazine almost never makes reference to EDC/CM. The myriad of engineering and technical society magazines only occasionally mention the discipline. Yet we (CMers) encompass what can easily be presented as the most important set of processes for any manufacturing company. Is the release of a new product or item and its documentation from engineering to manufacturing a critical company process? Is the creation, structuring and control of the parts list / bills of material an important process to the company? Requesting and making changes to the product and its documentation are processes which are only needed by a few companies who don't "do it right the first time" - yeah right!

For years the MRP/ERP folks have been focusing on micro-management of inventory, schedules, work in process, supply chain, process control, bar coding, automated warehouses, JIT, on ad-nausea. In the meantime they almost ignore the fact that the primary input to MRP/ERP is from the CM processes - engineering documentation and changes their-to. It is as though the specs, drawings, part numbers, parts lists, changes, etc. come to MRP/ERP exactly correct by some magic carpet. The right drawing at the right place at the right time is assumed.

Much is written these days about the "Supply Chain" and all the wonderful tools and advice available in that "new found" arena. By my reading, almost no one recognizes that the primary input to the supply chain comes from the engineering documentation and changes there-to. There seems to be no recognition that many, if not most, of the reasons for "unusable material" to show up on the dock are traceable to problems with the engineering documentation release control and change control. Garbage into the MRP/ERP and Supply Chain" results in, guess what, garbage out.

Engineers often act as though all the changes are made at the behest of manufacturing. And manufacturing folks often act as though all the changes are to correct engineering errors. MRP/ERP systems typically treat EDC/CM lightly if at all. PDM systems typically do the same. Chaos often reins. The solution for some years was Design Teams or Cross Functional Teams. A wonderful idea providing they are used wisely as an integral part of the CM processes. When one reads about the great things that teams can do, the writers seldom integrate the idea with the CM processes.

The ownership of the CM processes is often unclear or placed with someone who is so busy that they have little or no time to address process improvement. The management sometimes use ciaos or slowness in the release or change process as an excuse - after all, "Everyone knows how many functions are involved and how screwed-up that process is!" Often, the ownership of the processes is unclear - no one wants it - it's a hot potato!

It sometimes seems as though the discipline is orphaned. Yet there is hope! A dozen years ago, most of the EDC folks hadn't heard about CM. More and more companies are becoming aware of the benefits of fast, accurate, well understood CM processes. More and more books, web sites, consultants, training and software is available. The creation and growth of the ACDM organization and its web site have become a marvelous rallying point. With the Association and continued struggle, we CMers will prevail.
Frank Watts © 2002 EC3 Corp

5d. Significance 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 an interchangeability consideration is ludicrous.
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 is probably 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 would be:
Rule: Put very little significance into the part number with the possible exception of end items with few features and options.
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 final determiner.
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 lives.
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:
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 changes.
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 number format.
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".

Frank Watts ©1999 EC3 Corp

5e. Why EDC/CM? - (TOP OF PAGE)

• Premise
  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?"
  
• General
  · 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 or systematic.
• · 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 suppliers.
• · 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 differently.
• · 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) risk!
• · 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 factors cost?
• · 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 Engineering function.
• · 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 related problem.
  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 nightmare).
• · 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!
  Frank Watts ©Dec 2002 EC3 Corp

5f. Interchangeability - (TOP OF PAGE)
(ACDM Journal Date?)
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 two pages 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. After some discussion they agree that saying form, fit and function is not enough. If I tighten a tolerance, that might affect fit, but the old and new may be totally interchangeable. If it looks different is that a sufficient criteria? No - some appearance issues are important to customers and service 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 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 the changing of 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 in part number changing. 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 is a fundamental alteration? 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. The product specifications must also 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 every change, 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 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 is that parts should change part numbers (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 I would 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 others 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 me 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.

© EC3 Corp Frank Watts 12 Feb 2002

(TOP OF PAGE)
BACK TO LITERATURE PAGE
For More Info

EXCEPTIONAL CONFIGURATION MANAGEMENT HOME PAGE

---

©1999 EC3 Corp - 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.