BOM Modification Thoughts Dreams Revision Reality -- BPCS-L

BOM by Customer Implications - Introduction to Idea

Here are concepts behind a BOM modification on my to-do list.  We need it in
green screen RPG III for BPCS 405 CD without AS/Set, however I will probably
be busy with other stuff for a few months before making significant process on
it.  

Perhaps other folks with similar interests can suggest useful techniques,
pitfalls, similar modifications that are easier to implement, & whether you
welcome this sort of discussion topic.  Does SSA have anything comparable on
V6, or will it be in the works for V7?  Perchance does an add-on already exist
which does something like this?

BOC430 is an old BPCS/36 mod needing BPCS/400 replication - possibly run thru
NCS PRO to re-use some of the code.  We are a make-to-order manufacturer of
wiring harnesses with heavy model changes from some of our customers, so this
Report of BOM implications by customer was invaluable every time some
components were dropped from a customer's needs.  It was a string of programs
that built some data, then did reports on results.

Design Overview

User inputs customer, end item range, historical cut-off, & component criteria
such as item type class ranges.

>From current requirements & sales history, capture working list of items we
supply that customer = PARENT-WORK-FILE-A indexed by item, eliminating
duplicates.

Go down BOM & get children used on that customer's selected parts, expecting
multiple hits on some components - create secondary reference WORK-FILE-B
indexed by item, eliminating duplicates.

Go back up Where-Used on children to end items - compare hits to the
PARENT working list-A ... Is this part used exclusively to that customer or
common to several customers?  On BPCS/36 all I did was flag the items Yes/No,
but it might be useful to do a count of other hits on current requirements for
other customers, other hits that have current requirements for other parts for
same customer, and so forth.  On BPCS/400 we use item master field IDRAW for
customer# that we make an end item for (Revision in IFII), but this has not
been kept current, so I need to adjust some reports to highlight omissions.

The down / up product structure work led BOC430 to reports of all components
used by the customer, with columns clarifying which are exclusive to that
customer & which are common with other customers.  It also printed current on-
hand & on-order & MRP requirements total. Secondary reports listed just
components
exclusive to this customer. The original prompt offered which reports to print
& how many copies, different across reports.

A related modification idea = list only what is invalid by current effectivity
date criteria, so we can see how we USED to use this part, to explain how come
we have so much obsolete stuff on-hand.  Current choices are include
everything or just include what is valid with current effectivity dates.  I
think that should be pretty simple to implement, by cloning off existing BOM2
something.

What kinds of BOM modifications do other BPCS sites typically end up creating?

Business Justification Bottom Line

The business case for this modification relates to what reality is without
this info.  A customer's engineering changes results in some component no
longer having requirements, and being orphaned by active BOM, but we have a
bit on-hand & POs requiring more to be sent, then later plant management asks
"Why did we order this expensive stuff that we have no use for?"  A variation
is when it is a sub-component in production.  It is much cleaner at time of
model change to identify implications, STOP input of no longer need, & settle
up with customer.

The same data used to be generated manually, before BOC430 came into
existence, and now our users are back to doing it that way.  Run some BPCS
reports, scribble heavily on them, transcribing info from inquiries, use the
data to run some other reports, go on plant floor & do cycle counts on
hundreds of items, run more BPCS reports, correlate information from them,
implement the customer engineering changes, do some more report analysis,
conclude which materials were used on the old models but have no further
corporate need, & perhaps in 2 weeks of very tedious work, get the information
that BOC430 got in 5 minutes, then negotiate with the customer to make sure
that we are compensated for the cost of the orphaned materials, but not the
human effort to gather the data.

Ultimately the value of MIS to Corporate is not just getting us to the latest
SSA revision level without serious costs, but how do we use BPCS opportunities
to enhance the value of what has been invested in MIS.

As a newcomer to BPCS_L and also inexperienced in OS/400, I asked the list
moderator about the suitability of some topics not in the guidelines, and used
this as an example of one of my larger challenges, probably easier to explain,
than some stuff we have created off BPCS data that does not even look like any
BPCS report, & also of naming convention policies for modifications - BOC430
was fine for BPCS/36 but it has SSA security conflicts for BPCS/400.  He asked
if we had considered Features & Options & after his clarification, I realized
some of what I am talking about may be a bit ambiguous, for other kinds of
manufacturers.

We are a Make to Order JOB SHOP which means that the END PRODUCT is dictated
to us by the Customer Blue Print.  Although we do have an extruder division
that creates spooled wire (100,000 feet of some guage, copper alloy, etc.)
that is sold to other companies in the wiring harness business, the typical
work load is figuring out how to manufacture to precise Customer
specifications, where the typical customer has no idea how to make what they
want, leading to give & take between our engineers & their's on our ideas how
to make a better mouse trap (ie. do their job more productively at lower
cost).  We use the Customer Part Number as our BPCS Item # & only rarely have
had to have a work around because 2 customers use similar # systems, or their
part# is more than 15 characters.

Commonality for us is at the sub-assembly level, in which if you look at
Wiring Harnesses inside Office PhotoCopier or Air Conditioner or Telephone
SwitchBox or whatever, many wires are made out of the same materials & same
lengths & connections - the electrical theory is the same & leads to similar
configurations.  When we are manufacturing a particular configuration, it will
have an item# specific not to end customer, because many customers sub-
assembly have identical configuration.

The only time we need more than one version of the same end item:
a) Customer has 2 divisions at 2 different revision levels of same product,
due to a different schedule of converting - this is rare - most customers
specialize in type of product, like an Appliance Customer has one division
making refrigerators & another one making washing machines, with no parts in
common at the end level
b) RMA - they return an old revision that they want us rejiggered to latest
revision - obviously it needs a different BOM & Routing than a brand new
production that does not already contain many common components
c) RMA - they return an old revision that oops has a problem we need to fix,
but do it at the old revision
d) A customer is in the process of switching revisions, so we have current
production at the old revision and also current requirements at the new
revision

BPCS/36 did not recognize the reality that we might need to have concurrent
production of more than one revision of the same end item, so we used a system
of copying BOM with appended "R" for RMA/Revision-Variation etc. which we have
not been able to do on BPCS/400, and I modified BPCS/36 shop order release to
include current revision AT THE TIME OF RELEASE within the shop papers, so as
to distinquish from current revision AT THE TIME OF REPORTING transactions.  I
have no idea how my engineering & production departments are coping with this
- I am up to my ears with other problems they have shared with me.  But this
statement is merely to show that I doubt Features & Options are relevant to
us, on the basis of Dave's explanation.

Regards

Al Macintyre
Struggling Programmer
http://www.evansville.net/~ceneled
+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---