Re: Shop Order Days Ingredients

["Tim Armstrong" <tma@xxxxxxxxxxxxxx>]

E-mail from Al Macintyre at Tim's PC at Central.
____________________________________________

We are on PTF Rel 1 of 4 0 5 CD, which of course is not the most current
version.  There may be additional SSA bugs fixed in PTF-2 or later BMRs.
PTF-1 did update SFC739 with some fixes to SSA bugs, such as
BMR22132 to not loop when
a) Negative Move Time
b) Forward Scheduled
c) Today is a Holiday

I consider it rather unlikely that people might be running work on a day
they have scheduled as a holiday, but very likely that the shop calendar is
not as up-to-date as it should be.

You might want to visit OSG & download lists of any other relevant bugs
known to SSA whose fixes might not yet be installed at Day Spring.

I am currently working on an improved version of SFC230 for us (instead of
grouping by work done so far, group by MRP story on past due & within MRP
due date group work due the same day by setup criteria) & I noticed some
fields that you might like to check out.

WCAL - apparently a work center can be coded to bypass the shop calendar.

WEFF - past efficiency of reporting work done through a work center might
impact future scheduling & one really bad reporting mistake can undo your
month ... how do you average month to month? (alpha factor in system
parameters) ... if the extra days are thrown in when launching orders at the
beginning of your fiscal month, I'd look at the alpha factor as one possible
suspect.
____________________________________________

>From Stephen @ Day Spring
>
>We have stepped through the scheduling engine (SFC739) - arduous task - and
>are very confused about something.  It would seem that as the program loops
>from one operation to the next, regardless of work center correlation, the
>hours of capacity remaining from the previous operation's work center
serves
>as the basis for the next operation's hours remaining of capacity.  Maybe I
>am completely missing something, but to my simple mind this makes no sense
>at all.  The previous operation's work center capacity remaining is
>irrelevant to the next work center's capacity.  Can anyone shed some light
>on this for me?  Each of our work centers has a variable amount of standard
>capacity and these remainder hour quantities leave us with partial days
>which are apparently rounded up to whole days.  I think that is why we end
>up with 5 days of operation queue.

>From Stephen @ Day Spring

>At the big picture level, we really don't want a work center's capacity to
>impact the start and end dates of any operations on a shop order.  Whether
>forward or backward scheduling, we want the days between operations to
>consistently be the sum of the queue and move days defined in the routing.
>We want to see we are overloaded on the capacity reports etc, but do not
>want the operation start and end dates to be affected.
____________________________________________

from Al.M @ Central.

Stephen's theory is fine if you have the unused capacity (2nd shift &
weekends) to address the overload.  If not, you may need to work in the
planning & simulation areas, or maintain orders to reschedule when you are
going to work on them.
____________________________________________



>From Harmon @ Nexgen

>A major source of difficulty for the poor author of SFC739 is that he does
not
>have any shift start and end times kept in BPCS. So he has to play games to
>approximate clock time from capacity used.
____________________________________________

from Al.M @ Central.

The shop calendar has hours in a day, so the only times in question are from
today's unreported input.  I do not see that this is a problem outside the
scenario Harmon related of the possibility that different work centers might
be working different hours.
____________________________________________

>From Harmon @ Nexgen

>Now for the vast majority of customers the time spent at an operation is
>extremely important. Make the ideal assumption that move and que are zero.
If
>operation 1 takes a half day and operation 2 takes a full day, and you do
not
>overlap operations (an option in BPCS) you will not finish the order in one
day
>if both shifts start and end at the same time. SFC739 assumes that you
start
>both shifts use the same amount of clock time, and assumes the transfer of
the
>entire lot (when it is finished) between operations.  It tries to consume
>available time on the second operation because of the half day consumed on
the
>first operation. Your move and que times may be large enough to cover for
your
>entire run time, but many  BPCS users are not so fortunate. So while I
agree
>that the 'BPCS way' is clumsy and could use a lot of improvement (and may
not
>fit your environment as well as it could) if they did not use run times in
>scheduling they would have lost an incredible amount of sales.
____________________________________________

from Al.M @ Central.

We do overlap operations, which can be simulated by negative numbers in the
separation times.

We also have a bit of turmoil due to personnel turn-over & changing
philosophies on how far out to release shop orders, and how best to reflect
setup times in the engineering data.  The report I am working on improving
is like 100 pages of current work load in just one shop floor department in
one facility.  I think they have passed the point of being able to cope
using simple green bar reports.  But I do not have a solution beyond
suggesting that the company hire a MASTER PLANNER, instead of letting MRP &
CAP reccommendations run the show, driven by rapidly changing customer
orders.

____________________________________________
>From Harmon @ Nexgen

>In most shops an order for 80,000 takes longer to complete than an order
for
>10,000. If run times never become part of the calculation, than size of the
>order never becomes a consideration in scheduling.
____________________________________________

from Al.M @ Central.

I agree completely.

Other complications, which may be unique to our type of manufacturing:

The first operation of our wiring harness business is "cutting" wires to
specific lengths with specific "terminals" attached, in which it is not
unusual to have small lots with 2 minutes of run time and 10 minutes of
set-up time.  We are now exploring the idea of safety stock of some
sub-assemblies to be better able to react to customer order changes on short
lead times.

BPCS works with the data we provide it in routings etc. & sometimes our
modifications need to supplement the big picture, but we need to understand
all the ingredients that go into that big picture.

____________________________________________
Al Macintyre
Central Industries of Indiana, Inc.
www.cen-elec.com


+---
| 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
+---