Parts Explosion System Application Audit
INTERNAL USE ONLY
The following guidelines should be used in evaluating the facts shown
in the Application Audit (CPB-565). The information shown below relates to
each section and questions asked in the Audit Brochure. Possible meanings
shown for each point do not represent the exact meaning of the answers
obtained, but should serve as clear identifiers or indicators of facts or
problems about a prospect's business and what it could mean
Note: Use of these Evaluation Guidelines should be used in conjunction
with a knowledgeable pre-sales AE and/or your Regional application
specialist to insure maximum impact and accuracy.
Suggested Approach - Application Audit Presentation
Use as outline for summarized report for presentation:
1. Section 1 deals with general organization of the customer's company
and assignments of responsibility in the Bill of Material area.
2. Section 2 deals with the characteristics of the Bill of Material
information now available in the customer's present system.
3. Section 3 deals with the characteristics of the customer's present
4. Section 4 deals with the Bill of Material file organization approach
currently in use in the customer's business.
We suggest that the findings from these four areas be used as lead
topics in the summary presentation report-prior to the recommendation
GUIDELINES FOR EVALUATING
Parts Explosion Application Audit Questions
The following points are suggestions, critical points to look for,
etc., tied directly back to questions in the audit and capabilities of the
Parts Explosion System. The prime objective of this documentation is to
assist you in relating capabilities of the system back to specific
business requirements pointed out by the audit.
Business Organization and Responsibility
It is absolutely essential to find out just where, organizationally,
the responsibility lies for information content and accuracy. The
questions asked in this area look simple on the audit, but getting the
true picture is generally very difficult. Watch out for situations where
duplicate files are kept by the various functional areas. They will each
feel that they are primarily responsible, particularly if they add
information to the file. These "mixed" responsibility situations
should be pointed out to the customer in a very objective, factual manner.
Don't get trapped on the question, "Where should the responsibility
lie?" Only the customer can, and/or should, make this decision.
IDS can contribute to the solution of this common business situation in
1. The IDS technique of establishing and maintaining the relationships
between various pieces of information in the business is a significant
step towards solving this problem. In order to keep control in a data
base, where information comes from various functional sources, we must
determine the relationships and interactions of the information. Until
this is provided, you cannot effectively assign responsibility. The
chaining design techniques inherent in IDS make this possible. In a true
common data base, the file is not organized around a prime function-it is
organized by information relationships.
Covered by points under A.
You'll find that duplicate files are the norm, rather than exception.
This occurs because people requiring information cannot get it from a
master file in the time frame required. The integrated IDS file and
inquiry response capability can help in this area. The problem, business
wise, with multiple files is inconsistency of data. There are real
advantages to everyone working from the same data base, even if some data
is in error!
This is a key area to look into. Even if it is stated that product
structure information is conveyed via a specific medium, you will often
find that the people using the information are really getting it in some
other way or combination of ways. (Bill of Material plus drawing as
example) Point this out _n_ow_, because it is disastrous to dry up these
informal sources by installing a new system.
This group producing the present documentation is a key group to point
out the functional capabilities of the system and how it can help their
Characteristics of Bill of Material Information
The information obtained under these three points is useful in several
1. Use (in conjunction with Point G) for file size estimates.
2. General statistics of interest to customer management.
3. Use as some general indicator of common usage of parts-a prime area
for improvement with IDS elimination of redundant information within the
same file as well as across multiple files. Approach:
a = 100,000 individual, unique items.
b = 5 parts, average per assembly.
c = 150,000 total records in present Bill of Material Files (Includes
common usage parts)
Divide (a) the total number of individual unique items in system by (b)
average parts per assembly.
100,000 divided by 5 = 20,000.
This answer provides the total unique assemblies in system (20,000).
Subtract this value for unique assemblies from total unique items in
100,000 - 20,000 = 80,000.
This represents the total number of unique component parts in the
Subtract the value from Step 1 (total unique assemblies) from (c) the
total records in B/M System File.
150,000 - 20,000 = 130,000.
This value is the total number of detail part records (component record
callouts) in the B/M System File.
Subtract the total number of unique detail parts (answer from Step 2)
from the total number of detail component records in system (answer from
130,000 - 80,000 = 50,000.
This value is the total number of multiple uses of _it_e_m_s as opposed
to unique uses. (Used only once.) These records will be both detail parts
and assembly records called out at higher levels as components of some
higher assembly. Relating this value of multiple uses (50,000) back to the
total records in the file (150,000) tells us that 30% of file falls into
this category of multiple use items. This is a tremendous area of possible
improvements using the IDS techniques:
Reducing redundancy: a) the master-detail concept of IDS is very
effective in reducing redundancy by lowering or eliminating the repetition
of match keys;
b) additionally, the use of cross reference pointers allows the
practical storage of common data only once in the file; c) the capability
to link all master records that are related to (affected by ) a detail not
only helps eliminate redundancy, but is a
critical requirement to achieving a truly integrated, common data base.
Communication capability between data records is essential. The
hierarchial file solution of_a_ll sequential oriented approaches does not
effectively have this solution
Note: One condition could distort this analysis of multiple use items.
Typically, master part files in accounting areas (Question A) will be kept
from day one forward. Little or no attempt will be made to purge unused
items. Most people, on the other hand, will make some attempts to purge
Bill of Material system files. The net effect is an
overstating of unique items in the system, which results in
understating the percentage of multiple uses. This will make your
estimates of multiple use very conservative, a point you should point out
to the customer.
This statistic is important to the customer and us for estimating
possible file space savings through a purging scheme. The solution for
this is not easy, nor is there one pat answer for all businesses.
The point is that IDS capability to establish relationships between
information, makes this solution much more practical. Remember,
maintaining the relationships between files (like index sequential) is
only a superficial solution to this area. You have to get down to the
individual data elements level
to be successful!
Any customer that has a mix of pure service parts requirements (parts
not used in current production) with current production parts requirements
has a control problem of Major significance. He
must have the capability to identify "service part only"
items, both "service and production part" items, and
"production part only" items. The Parts Explosion System, as
released, does not provide a canned solution to this control. The IDS data
base techniques, however, do offer sound, practical
solutions. (1) Carrying a code in the Master Item record (only once) is
a possibility. . . with usages linked back. (2) Item type records are a
possibility. (We are doing this in the Inventory Management Phase of MIACS)
The point is IDS offers a variety of possible solutions.
This area is a somewhat similar problem of control to (E). Items from
different types of sources require different types of control. The
possible ways to control with IDS are covered in prior paragraph.
One point, beside control, is important here. In the Parts Explosion
System we use a bottom justified level technique. (See System Manual for
details). This effectively places items in levels
page 3 and 4
|related to their use, as opposed to where
they appear in a structure, (low level position.) In our system, all
purchased parts and raw materials appear in level (l), the lowest level.
This can offer some interesting possibilities for user extensions in this
area of controlling purchased items. For example, in our present level by
level explosion reports, all items in level (I) represent the purchased
parts or raw material requirements for the given explosion. From this
point, a user could introduce
logic for a variety of control approaches.
Required for sizing files (present) and estimating the possible savings
using IDS in the redundancy area. Characters required in IDS to establish
a component record (product structure record) will typically be much less
than any sequential scheme.
The majority of Bill of Material Systems in use today, regardless of
physical system used, will carry information other than pure product
structure data. By going through the analysis provided in the audit, you
can open up many significant areas.
1. By just going through this area with your customer, you will convey
an awareness of the manufacturing problem and a desire on our part to
truly try to understand his business requirements.
2. In sequentially organized systems, knowing what this information is,
and where it is maintained may open up additional redundancy elimination.
3. Maintenance of codes and control data in a multi-file environment is
a fantastic problem. . . and this condition is present in many, many
customer systems today! (As a matter of fact, in almost all systems except
those utilizing an IDS data base. We in GE are naturally prejudiced, but
look around. . . it's a fact!) We have a proven answer in the Parts
Explosion System. . . the Master-detail IDS concept, as applied in our
Material Item Master and Component record structure. We carry the common
data in the Master regardless of where it is used. The component record is
exactly that. . . a relation record that records usage information. Your
customer can add his control information in this
Item master and conveniently tailor the system to his specific control
requirements. We have this at every Parts Explosion test site and are in a
position to prove it through results.
Another significant dimension of control has come out of our test site
experiences. We have demonstrated the ability to provide different types
of control, for the same item, as affected by it's specific use in
different assemblies or use at a given point in time.
Test site users have added certain control data to the component
record. For example:
a. It is possible to carry effectivity data in the component record and
select the proper record based on defined change points.
b. The above can also be accomplished by an effective date record with
items linked to it.
c. Make or buy decisions may be affected by where an item is used.
Carrying this code in the component record will allow for varied
decisions, based on actual use.
d. The key point is capability in IDS to control at the level required
by your customer. . . families of like parts, end items, item level, or
usage in specific assemblies.
The standard Parts Explosion system does not provide control for such
items. This can be handled in IDS file approach, however, by including a
code in the material item record (like any other control code) and add
decision logic to the explosion or inquiry programs. You will find entry
points in all Parts Explosion System programs that allow for such
additions. . . at the COBOL source level not machine code level.
These two areas are complicated and controversial. . . but we should be
aware of them if the conditions exist. The IDS data base will handle these
situations because it is based on relationships of
data, not any significance of item numbers.
(1) (1) usually exists because obtaining where used information either
does not exist or is difficult to obtain.
(2) (K) usually exists because control capabilities are impossible or
difficult to build into the existing system. (Exception is use of this
technique to eliminate drawings in Engineering for
In any case, we can accommodate such item numbering systems. Be very
careful about suggestions to alter the present numbering scheme. . . just
because we can provide the same capabilities in an IDS file structure.
Changing item identification policy is a traumatic experience in a
manufacturing organization that will affect areas never dreamed of.
Approach this a "possibility that must be carefully
planned and thought through."
This is basic information required to develop some estimates of
processing requirements. This is also the area where "random" vs
"sequential" approaches meet head on! The Parts Explosion System
is purely transaction-oriented, utilizing a random data base. We are
dedicated to this approach in GE for many valid reasons. (Refer to the
first section of Application Review for Parts Explosion System).
Additionally, you will find that many customers are batch and sequential
file oriented because nothing else has been available to them. We cannot
afford to overlook or be hypercritical of this fact! Sequential schemes
have been effective (in simple problem areas) but now you can offer a
broader possible solution to the total information requirement and
integrated systems environment.
If the customer has full random capabilities in his objectives,
(transactions, inquiry, and usage of 2 common data base) he will
appreciate our IDS and Parts Explosion System Products.
|Incidently, in even "high volume B/M
transaction situations" . . . break these volumes down to a daily
basis and compare hit ratio to total file size. Batch processing looks
less and less attractive.
Point I is needed to identify that portion of time "outside the
system." It may prove to be a significant portion of the overall time
required to process an engineering change, and the Parts Explosion System
is not going to solve this area (except for responsive inquiry for
engineering research tasks.) Identify the magnitude
so that improvement in the processing area can be identified. There are
many possible areas of improvement in Engineering work, through the use of
computers, but they are outside the scope of this
Point 2 is required to measure possible improvements in our system vs
present or proposed. Remember one point, your competition is sequential
approaches. Be sure to point out to your customer that not only actual
file maintenance runs must be considered, but also pre-sorts, and
restructuring processing, inherent with sequential
file overflow area approaches.
Characteristics of Present System
This area of the audit is designed to clearly identify the customer's
present "system vehicle." We could probably spend the rest of
our lives debating the respective problems of moving from one level of
equipment to another. Let's look at some general points.
Point A-(l) - Going from a manual system to any mechanized system is
pure brute force work! We do believe in GE, however, that the most
effective step, long term, is to go after a basic area like
Parts Explosion in the random device environment. Do it right and
establish a sound base for future system growth in the manufacturing area.
So called short-range, interim steps, only postpone
the final decision. Other work such as Financial can be picked up
parallel. . . but aim for the manufacturing control area!
Point A-(2, 3a, 3b, 3c . . .) - All card-oriented systems have certain
common characteristics and problems.
I. Sequential orientation (Refer to Parts Explosion Application Review.
. . Evolution of Techniques . . Section I.)
2. Quality of Data is typically poor. Card files are wide open to
manual interruption and multiple location maintenance problems for codes
and other common data.
Expect and p_l_a_n for unexpected data quality and conversion
requirements when going from a card system to any magnetic recording mode.
Point A-3-f - If your customer now has a disc B/M system, _y_ou_ have a
prime prospect! He has experienced, personally, the problems of sequential
file organization on disc, or the magnitude of
a self-designed random file approach.
|Provide him with documentation available on
IDS and the Parts Explosion System. Ask for a sample of his actual Bill of
Material data and process it through the Parts Explosion System. Provide
him with available standard outputs from the system and an IDS formatted
file dump. Have qualified Technical Support people work with the customer
in these areas. You will generally find this prospect extremely receptive
to the IDS/Parts Explosion System approach. He has been there!
Point B - This area in the audit is designed to identify the customer's
present system capabilities. It can also serve to identify unsatisfied
requirements he has. We have intentionally structured the points around
capabilities now included in the GE Parts Explosion System. To truly serve
customer's needs match his business requirements with available
capabilities. Every type of function except points 4, 10, and 12 are
available in the Standard Parts Explosion System release. Examples are
displayed in Section 3, Application Reviews.
Point 4 - Selective Bill of Material reports, is possible with minor
modifications. Add control codes to Material Item records and selective
logic to existing Inquiry and Explosion modules.
Point 10 - IDS Fild structure used in the standard release has the
capability to build on implosion capabilities with minimum effort. One
test site, Abbott Laboratories, is implementing this capability as an
extension of the standard release.
Point D - Effectivity control is being implemented as an extension to
the standard release by another test site, Aeroneutronics Division, Philco-Ford.
Effectivity control will be a standard function included in MIACS, phase
2, Inventory Management.
Many of the capabilities provided by the Parts Explosion System are
standard expected functions. (Bill of Material reports, where-use, etc.)
Two areas are particularly outstanding and unique. This system is
capable of providing both gross and n_e_t, level by level explosion, with
lead time set back, multi periods.
We also offer some fundamental input data editing capabilities which is
also unique as compared to competition. All of these capabilities are
covered in detail in the Parts Explosion System Application Review.
Point F - This point was included to get some indication of the
customers' explosion requirements. You will often find that his frequency
and approach are now what he would truly like to do, but is limited
because of system and/or processing capability. Be sure to dig out
"what he would like to do."
Point I - The system as released is not capable of tracking and
controlling discrete orders. Orders are pulled together in summation
during the explosion, for a total net explosion of all items entered.
Inventory Management, phase 2, will have this capability.
Bill of Material File Organization Approach
This section is designed to identify the type of file organization now
in use. It is structured into:
(1) (2) (3) (4)
Card Systems Tape Systems Tape/Disc Systems Disc Systems
The strong and weak points of each type is covered in Section I of the
Parts Explosion System Application Review.
Once the file organization type is identified, use the Application
Review material and other IDS documentation (I) to point out the
respective improvements possible with the IDS data base approach used in
the system. The IDS managed data base approach utilized in this system
(and all current developments) is as significant, or
greater perhaps, than the actual application software. We have a unique
product available to us in IDS and it warrants a major role in the overall
approach. In addition to identifying file organization, sequence schemes,
and storage devices utilized, there are several additional key points
asked for in each section:
1. Where-Used Approach. . . both file capabilities and organization. .
. and present system's functional capabilities. This is one critical area
that the IDS file structure, used in this system, is far superior than any
other technique known today. The Master Detail relationship used in IDS
provides efficient where-used capabilities with proven file integrity.
2. Absolute Addressing vs. Relative Addressing.
IDS utilizes a relative addressing approach as opposed to IBM's Index
Sequential which is absolute. Experience (GE and others) has proven that
absolute addressing (physical hardware addresses) is
much more vulnerable to changing file devices and particularly to overflow
3. How is overflow handled, particularly in IBM's Index Sequential?
Degrading of performance is characteristic of predefined overflow area
techniques as the overflow area fills up. Variations have
been implemented to try to solve this problem such as "overflow to
another overflow area" . . .
In the BOS/MT version of IDS, we also fall off in performance when the
file utilization reaches 65 to 70%. This is vastly improved in IDS
releases utilizing available page inventory capabilities. This can be
pushed up to the area of 90% utilization. . . excellent by anyone's
(1) IDS - A New Concept in Data Management, CPB483A
IDS - Data Base Study - CPB48 I A
IDS User's Guide (first release of a series of documentation of User's
|The prime difference in approaches between
IDS and other techniques is that IDS "spreads" the file across
the total defined available space. Overflow space is not restricted to
predefined physical locations . . . tied to device characteristics such as
a track, etc. This, in effect, allows for available space for additions to
the file to also be "spread" over the file. The logic internal
to IDS looks for the nearest physical space, as required, and stores the
new record in the relationship predefined by file structure selected. It's
important not to misinterpret the term
"spread". The page concept and place near capabilities of IDS
will physically store related information in the same page, or nearest
page with available space, to reduce accessing of the file.
The design logic for overflow in IDS is geared to the concept that all
remaining space is available for overflow. . . as opposed to specific
logic allocations for overflow. Our performance is tied to total file
utilization. . . not the filling up of individual defined overflow areas.
Rebuilding of files to unload overflow areas in Index Sequential is
very time consuming. Throw the multiple file approach in on top of this,
and it becomes a significant task.
4. Linking techniques are also covered in this section. Bi-directional
linking is truly possible in IDS with all of its inherent capabilities in
system design. Without effective bi-directional linking, problems such as
scheduling, re-scheduling, and where-used become unwieldly.
Electric Parts Explosion System Application Audit