Re: Jit Workbench

>From Al Mac

Since there is a JIT module in 405 CD that we are using, perhaps someone
should indicate what differences if any are involved with what you are
calling JIT Workbench on BPCS V6.04 & the application JIT on 405 CD.

I have been to a class that explains what JIT means.
What SSA GT is calling JIT is, shall we say, such a small vision by
comparison that no one should be learning what JIT is, exclusively by
studying the SSA documentation.
If you want to learn what JIT is, start with your BPCS tech support & APICS.
http://www.apics.org

We are not using the whole JIT.
Basically we are using JIT600 610 820 in lieu of SFC600 610 620 to report
labor because JIT6 series creates inventory transactions in synchronization
with the labor transactions.
I consider JIT300 to be rather useless - it is showing the data based on the
LAST labor ticket entered on any given item operation, there is no averaging
there.  Now I do not know if this is governed by SYS800 settings, or if that
is native how that operates.
There are a number of problems with this architecture.
Some of the problems are also native SFC problems.

The documentation is rather obtuse.

Life would be so much simpler if all users had a thorough understanding of
what this application DOES.  A lot of our difficulties are fueled by people
thinking that it OUGHT to behave in a certain way, perhaps because they have
formal APICS training or for other reasons expect certain behavior, but the
reality is that BPCS is not functioning how some of our people think it is,
and this leads to discoveries of what people think are bugs that they want
fixed, but upon investigation, BPCS is functioning exactly the way it is
designed to work, so then we need professional guidance whether this or that
modification is ill advised or a good idea.  It might help if the people
making modification decisions, such as myself, had sufficient APICS training
to know which modification requests are ill-advised.

We would not have this kind of problem if the BPCS documentation was
intelligible to a wider spectrum of our users.

There are also problems that tie into our corporate culture.
Management does not want to go to bar coding any time soon.
The labor tickets are keyed in by a clerical person.
Sometimes there are problems with the data being entered ... it could be
misreporting, it could be tickets turned in out of sequence, it could be
miskeying thanks to lousy handwriting.  The error messages & the 610 audit
reports are targeted at someone in production control who has a thorough
understanding of the SFC JIT application & what is going on on the shop floor
which is not a level of comprehension expected of a clerical person
transcribing this data.

We created queries off of file FLT member WORK with some constraints on basis
of user work station entering the labor tickets, so that the clerical people
could get a proof list of what they entered that intelligibly reflected the
information on the first screen of the labor tickets that they entered, so
that they could check their work for any mistranscriptions before actual
posting.

We can have multiple orders open concurrently on the same item to be made.
It goes with the territory that there will be scrap.
During production we immediately replace what is scrapped.
Thus it is normal for a shop order for say 500 pieces to have reported
against it 500 made & 3 scrapped.  BPCS treats this as excess reporting, and
tries to spread the data across multiple orders.  We recently had a case of
this where a human had claimed that the final operation was "Y" complete.
BPCS posted some of the quantity to the right order, posted the excess to the
second order & also said its final operation is "Y" complete, both orders now
coded for purge, although the quantity posted against the second order is
tiny, the excess from the first order, and nothing yet reported on the other
operations of the second order.

I have asked for years that we find another way of dealing with "Y" complete
operations than normal labor reporting, but it has been a political football.
 Recently there has been a request for me to write a program that I might
call a JIT work bench, to go to orders to which stuff has been posted as "Y"
complete by whatever means, and undo which operations & orders are claimed
completed.

I also have a request from several people to modify the 600 620 code where it
has the algorithm to transfer reporting to other shop orders, so as to
exclude scrap from the math.  Earlier there was a request to eliminate the
transfer to other shop orders, but I said that logic is incredibly involved -
it would be simpler for me to do what they agreed to me doing, which I have
not yet done.

Another modification in my pipeline is to provide more graceful error
recovery.
Right now when 620 gets to resetting allocations & totals of open orders, if
some other person is updating the item involved, which is extremely likely
given the fact that some items are used heavily, the error message merely
says that some other user is updating & this program cannot get a lock on an
item in IIM ... it does not specifiy record or the other user.  Even if we
figure that out, the recovery options are a choice between bad & very very
bad.

I have told my people repeatedly to take a "G" to go around the relevant
update, since I can do a reorg that night to clean up any glitches, and not
an "R" because "RETRY" in IBM terms has a totally different meaning from
"RETRY" in Microsoft terms.  However, invariably they take a "G" a couple
times, then do "R" & they think it works, telling me that the "G" did not
work, so they took the "R" & it did work, but a few minutes later the program
is back at the same point, and they treat it like a different instance of
this problem.  What's happening is the labor is flagged that it has gone in,
so when it retries the whole data again, the labor that was posted before the
collision is not reposted, but the inventory is not so flagged, so it gets
duplicate posted.  We have had cases of a large batch of labor tickets with
thousands of inventory transactions being posted in excess duplication.

I have been tempted to suggest I modify so that the allocations are not
refreshed until a dedicated reorg each evening ... in other words modify to
bypass the step that crashes far too often.

There are some modifications we have made / tested / implemented.
There are combinations of input that BPCS does not question, so for example
we used to have people who keyed quantity into the hours field, or hours into
the quantity field, or some other mixup.  We have added some reasonableness
checks to the data input.

There are some modifications we have made that are waiting on user department
quality assurance testing / approval to implement, complicated by the fact
that our different facilities do not report against several fields the same
way & the differences are in a state of evolution.

The nature of the data entry is such that a lot of ticket entry shares field
content with that of the prior ticket, so perhaps not all the fields should
be cleared from one entry to the next ... it is simpler to field exit a field
than to rekey all contents.

Depending on the type of transaction, there are a lot of fields on the 600
screen not relevant to current input.  Our people can take F17 (which I
added) & they get a screen tailored to what is to be keyed in relative to the
current transaction type ... Human Run, Setup, whatever.  For those folks
using PC keyboards whose function key access beyond F12 is a bit of a hassle

(I sure would like to know where we can find keyboards with full IBM key
selection at PC keyboard prices)

They can use ROLL UP ROLL DOWN PAGE UP PAGE DOWN whatever key their keyboard
has & my modified 600 will translate that into F17

We track what machine / mold / applicator was used in labor operations, in
which that data is captured off of the 600 input stream, but the granularity
is not what our people now want ... we are ready to start capturing scrap by
machine / mold / applicator just as soon as the differences across facilities
can be resolved & reprogrammed to handle the new corporate rules.

I hope some of what we are doing can give you meaningful ideas with respect
to what you need to be doing,  I could ramble on with more examples of our
challenges, but then I not certain if this is what you are looking for.

> rom:  k.wiggall@cableinet.co.uk (Keith)
>
>  I have been asked by my company to investigate and  document what is
>  required to implement the Jit Workbench on BPCS V6.04. Currently we are
>  running MRP and a project is underway within our plant to plan for a change
>  to JIT manufacturing.
>
>  If anyone has participated in a project like this, I would be most
> interested to hear about how the project went and what problems if any were
> encountered.

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
AS/400 Data Manager & Programmer for BPCS 405 CD Rel-02 mixed mode (twinax
interactive & batch) @ http://www.cen-elec.com Central Industries of
Indiana--->Quality manufacturer of wire harnesses and electrical
sub-assemblies - fax # 812-424-6838