I don't believe there is a perfect solution. You need to explore
alternatives, do some testing, determine which is best fit to your needs.
Needs vary with company, but something that has been important to us is
simplicity of procedures. We need our people to get practiced at doing
things a certain way.
If they have to remember ...
if this set of circumstances we are to do things one way
if that set of circumstances we do things some other way
with a bunch of different scenarios
then there is high risk that some scenarios will get done a way that is
right in some circumstances, but the wrong way for that scenario
plus the process of figuring out which alternative way to use, that can
introduce inefficiency, slow down into clerical work
We better off having some system of coding such that when the orders are
entered to customer orders, forecast, the independent demand ... that is
correct, then everything else falls into place..
I think managing the purchasing consolidation is the easiest.
You can have thousands of different items for many different customers &
internal all aiming at same component used ordered from some supplier in
the BOM. The MRP will calculate for you what quantity of the componenent
needs to be ordered. The PUR process does not need to know why we ordering
this part on behalf of what end items, MRP aggregates or consolidates the
needs for you.
Likewise production of sub-components & sub-assemblies does not need to
know why this or that part being made for what end customer or for OUR end
item #s ... you do the work efficiently through MRP netting. We have in
our routing instructions, which prints on the labor tickets, where the part
is to go after completion, or what is to be done next, to expedite movement
through the factory. A copy of the labor ticket becomes an inventory tag
... what this is, where it goes next, what needs to be done with it.
We also have a miniature BOM where-used printed on the labor ticket, so if
the part is a common, it is showing the non-commons that use the part, that
have current requirements. Supervisors of final part assembly have an
inquiry ... they can key in some part that we are about to start work on
... the screen tells them which components are not yet ready, and where in
the factory they supposed to get ready.
We accomplish this by thinking through how to structure BOM and routings,
not just how to make the parts, but how to track the parts needs.
A potential challenge comes when you have parts in inventory, and in
production, that are physically identical but identified with different
item #s. It is very easy for a worker to go get the materials that
physically are exactly what's needed, but end up with transactions that are
for a different item #, leading to inaccuracies, when you need BPCS to
aggregate quantities of what's physically identical. This is one reason
why we went to commons. We use our # system and customer # system only
for parts that are truely unique. We are able to sort descriptive info
from item master and routings to identify where there are different items
that are physically identical. Then we replace them with a system of part
#s based on what's in common identical.
Thus we have several different part # logic systems.
* item #s based on OEM where the parts are truely unique
* item #s based on our internal, also unique
* item #s describing physical characteristics of parts that are common to
multiple places
* codes on ends of item #s to identify special handling, with respect to
pricing, QC etc.
We also use some fields of item master that BPCS does not use, to flag some
items as needing special handling. For example, we have identified some
bottlenecks in our factory, where we want to keep the work going through
there busy all the time, never idle, and sometimes prioritize what parts
are going through there. So we have a code to identify parts that at some
point in their production will be going through a particular bottleneck,
and print that on reports showing lists of items in production, to let
certain people know to watch out, make sure these parts not fall behind
because of that bottleneck.
Al Mac
BPCS nerd
Thanks, Al. I'm mulling all if this over - there is a lot to it!
Don
midrange.com
