Re: Analysis of transfers

Objective-1 can be a major challenge. People are expecting a particular
kind of error, and can be oblivious to another kind of error. Management
can impose rules to try to fix some error, where there was inadequate
checking to know if that was happening, and the new rules make things worse.

Look into ways to measure inventory and other potential problems.
The data for JIT300 can be used to figure percent scrap, then generate list
of items where high percentage scrap and considerable production.
We have a report listing inventory on-hand, unused in 1 year, 2 years.
Current design has a hassle identifying unused when it is brand new use of
an item # previously for a different purpose.
We have a slow moving inventory report. In my opinion, one of the worst
items on the list, we have enough to satisfy our needs in 500 years.
When there is an engineering change, do you have ways to identify items
which become orphans (no longer needed), or whose usage needs dramatically
change due to the engineering changes, so inventory settings such as safety
stock, MRP codes, should be altered?

I suggest exploring ways to measure the different kinds of transactions
going on, to see what patterns occurring.

When we identify a particular type of error, there is an associated reason
code. How frequently is the same type of error re-occurring with the same
items? What proportion of our items are experiencing what types of
identified errors?

Items accumulate aggregate: consumed in production or ship to customer;
manufactured or received from vendor; and adjusted. In theory, the
adjustments should be a tiny percentage of the total transaction volume.
Calculate that percentage, sort to list items where just about everything
happening with that item is adjustments, not consumed nor produced.

Contents and values of files can be changed by BPCS programs, modified
programs, human manual tweaking, other. How much is going on of each kind?

ITE has list of currently valid transaction effects. ITH can have any of
them, and can also have invalid transactions. How many of each are we
processing?

I suggest an effort to list the different kinds of errors which could occur,
then figure out how to measure them.

Engineering errors for example . there was an engineering change in which
the rules got broken, so what is being made in the factory does not match
the info in BPCS, so when shop orders consume inventory, they are consuming
something different than what was actually happening.

Lots more ideas this area.

Al Mac (WOW) = Alister William Macintyre
via WOW WAY.com ISP
day job = www.kewire.com Lawrenceville Il (near Vincennes In) via VPN/400
(our division dates back to 1955)

-----Original Message-----
From: bpcs-l-bounces@xxxxxxxxxxxx [mailto:bpcs-l-bounces@xxxxxxxxxxxx] On
Behalf Of Bailey, Dick
Sent: Monday, March 04, 2013 8:34 AM
To: BPCS ERP System
Subject: Re: [BPCS-L] Analysis of transfers


1 - Our inventory control Manager wants to identify and analyze
particular transfers his people make in the corrections they make as a
result of their cycle count work - to identify and count repetitive errors
made by material handlers, for example,

Dick