Move time scheduled for completed operations during a reschedule

Yahoo Archive
1
I am running 8.03.404B. Is anyone else having difficulty with move time
being scheduled for completed operations during a reschedule? I have
discussed this with Epicor and the developers state that this is working as
designed. Consider the following scenario with 2 days move time for each
resource group and production works Mon - Thurs. I perform a reschedule
and this is what I get...

1st Op (completed) scheduled to start 5/27/08
2nd Op (completed) scheduled to start 5/29/08
3rd Op (completed) scheduled to start 6/3/08
4th Op (open and needs to start today) scheduled to start 6/5/08.

In my opinion, if I forward schedule from today, the above stated job
should start today on the 4th op. Am I crazy, should the move time between
completed operations be calculated in a reschedule? According to Epicor,
this is how it is suppose to work.

They say this is how it's always worked but I don't think we had this
problem when running 8.03.305. If you are running an earlier version than
404 could you test this for me.

Thanks,
Tonia R. Blakely
Enterprise Systems & Logistics Manager
Automatic SMP
Ph: 256-353-1931 ext. 256
Fx: 256-355-3612
2
How are your resource groups (and resources) set up? (Do you have "auto-move" checked or unchecked?)

"The developers" of course ARE full of it - no matter how you have this set as, if both the 'move from' and 'move to' OPs are completed, there is no move to accomplish and the move should be negated (along with the move time) from the schedule.

Let's assume they are 'right' though and you haven't set your resources for auto-move or performed a manual move between OPs: Ask "the developers" why the move time DOESN'T GET CONSUMED OVER TIME. (This same issue exists for queue time.)

There IS a record in the db (labor detail table) of when an OP is completed. Any post OP specified MOVE (or pre OP specified Queue) should be consumed by the scheduler as time passes.

This is late 70's MRPII functionality.

...But of course 'the developers' wouldn't KNOW that as they likely weren't born yet and never read that book (and certainly NONE OF THEM have ever done any real world scheduling and have any experience to base their INANE opinions on).

Keep the pressure on Epicor and go over development's heads. Their development group is a self serving silo unto themselves... Perhaps it's time for Epicor's customer base - en masse - to tell the board of directors this is unacceptable.

If Epicor is an ethical corporation truly dedicated to fulfilling their service obligations to their paying customers, they will listen as that "is how it is supposed to work".

Rob Brown





--- On Tue, 5/27/08, tblakely@... <tblakely@...> wrote:
From: tblakely@... <tblakely@...>
Subject: [Vantage] Move time scheduled for completed operations during a reschedule
To: vantage@yahoogroups.com
Date: Tuesday, May 27, 2008, 5:14 PM












I am running 8.03.404B. Is anyone else having difficulty with move time

being scheduled for completed operations during a reschedule? I have

discussed this with Epicor and the developers state that this is working as

designed. Consider the following scenario with 2 days move time for each

resource group and production works Mon - Thurs. I perform a reschedule

and this is what I get...



1st Op (completed) scheduled to start 5/27/08

2nd Op (completed) scheduled to start 5/29/08

3rd Op (completed) scheduled to start 6/3/08

4th Op (open and needs to start today) scheduled to start 6/5/08.



In my opinion, if I forward schedule from today, the above stated job

should start today on the 4th op. Am I crazy, should the move time between

completed operations be calculated in a reschedule? According to Epicor,

this is how it is suppose to work.



They say this is how it's always worked but I don't think we had this

problem when running 8.03.305. If you are running an earlier version than

404 could you test this for me.



Thanks,

Tonia R. Blakely

Enterprise Systems & Logistics Manager

Automatic SMP

Ph: 256-353-1931 ext. 256

Fx: 256-355-3612
3
Auto Move is unchecked. I tested it with the Auto Move checked and got the
same results when the job is rescheduled.

Tonia R. Blakely
Enterprise Systems & Logistics Manager
Automatic SMP
Ph: 256-353-1931 ext. 256
Fx: 256-355-3612



Robert Brown
<robertb_versa@ya
hoo.com> To
Sent by: vantage@yahoogroups.com
vantage@yahoogrou cc
ps.com
Subject
Re: [Vantage] Move time scheduled
05/28/2008 12:03 for completed operations during a
AM reschedule


Please respond to
vantage@yahoogrou
ps.com











How are your resource groups (and resources) set up? (Do you have "auto-move"
checked or unchecked?)

"The developers" of course ARE full of it - no matter how you have this set as, if
both the 'move from' and 'move to' OPs are completed, there is no move to
accomplish and the move should be negated (along with the move time) from the
schedule.

Let's assume they are 'right' though and you haven't set your resources for
auto-move or performed a manual move between OPs: Ask "the developers" why the
move time DOESN'T GET CONSUMED OVER TIME. (This same issue exists for queue time.)

There IS a record in the db (labor detail table) of when an OP is completed. Any
post OP specified MOVE (or pre OP specified Queue) should be consumed by the
scheduler as time passes.

This is late 70's MRPII functionality.

...But of course 'the developers' wouldn't KNOW that as they likely weren't born
yet and never read that book (and certainly NONE OF THEM have ever done any real
world scheduling and have any experience to base their INANE opinions on).

Keep the pressure on Epicor and go over development's heads. Their development
group is a self serving silo unto themselves... Perhaps it's time for Epicor's
customer base - en masse - to tell the board of directors this is unacceptable.

If Epicor is an ethical corporation truly dedicated to fulfilling their service
obligations to their paying customers, they will listen as that "is how it is
supposed to work".

Rob Brown

--- On Tue, 5/27/08, tblakely@... <tblakely@...> wrote:
From: tblakely@... <tblakely@...>
Subject: [Vantage] Move time scheduled for completed operations during a
reschedule
To: vantage@yahoogroups.com
Date: Tuesday, May 27, 2008, 5:14 PM

I am running 8.03.404B. Is anyone else having difficulty with move time

being scheduled for completed operations during a reschedule? I have

discussed this with Epicor and the developers state that this is working as

designed. Consider the following scenario with 2 days move time for each

resource group and production works Mon - Thurs. I perform a reschedule

and this is what I get...

1st Op (completed) scheduled to start 5/27/08

2nd Op (completed) scheduled to start 5/29/08

3rd Op (completed) scheduled to start 6/3/08

4th Op (open and needs to start today) scheduled to start 6/5/08.

In my opinion, if I forward schedule from today, the above stated job

should start today on the 4th op. Am I crazy, should the move time between

completed operations be calculated in a reschedule? According to Epicor,

this is how it is suppose to work.

They say this is how it's always worked but I don't think we had this

problem when running 8.03.305. If you are running an earlier version than

404 could you test this for me.

Thanks,

Tonia R. Blakely

Enterprise Systems & Logistics Manager

Automatic SMP

Ph: 256-353-1931 ext. 256

Fx: 256-355-3612
4
8.03.404B global is broken in so many ways I can't count them anymore.

I doubt however (even if auto-move checked), the move time was ever consumed as time passed (based on date/time of previous op completion) in 8.03.

Do you really need MOVE? In general (unless your operations truly are performed at great distances from each other requiring several days move), move (and queue) are bad practices in use and simply make your lead times (and WIP value) higher than they could/should be.

With forward scheduling, if you truly feel you need artificial buffer time between ops - queue is the 'least worst' as it is typically only applied to the slowest cycle time (or thruput time if multiple machines process the op in parallel) constraining OP. By maintaining a *just*big*enough* planned queue of available work in front of the resource(s) that tend to be contraining OP related, you insure they always have work available and are utilized & running at full capacity.

That improves the thruput of you entire plant.

Ideally, the contraining OP is the 1st OP so all subsequent OPs process at the same pace as the 1st (balanced production). You can use this 'balanced productio' concept to slow down some (say for CNC turning equipment) spindle rates - increasing tool life & part quality variability and also minimizing human tending needs.

Basic Lean 101 stuff (or, 5 years ago - Flow manufacturing or, 10 years ago - Theory of Constraints or... you get the picture).

Even if Queue also doesn't get consumed, at least by only applying it (again -as little as possible to make sure your constrained equipment or process isn't starved for work) - it will only be on one OP.

Your resulting schedules will be much less distorted.

Rob Brown

--- On Wed, 5/28/08, tblakely@... <tblakely@...> wrote:
From: tblakely@... <tblakely@...>
Subject: Re: [Vantage] Move time scheduled for completed operations during a reschedule
To: vantage@yahoogroups.com
Date: Wednesday, May 28, 2008, 11:32 AM











Auto Move is unchecked. I tested it with the Auto Move checked and got the

same results when the job is rescheduled.



Tonia R. Blakely

Enterprise Systems & Logistics Manager

Automatic SMP

Ph: ext. 256

Fx:



Robert Brown

<robertb_versa@ ya

hoo.com> To

Sent by: vantage@yahoogroups .com

vantage@yahoogrou cc

ps.com

Subject

Re: [Vantage] Move time scheduled

05/28/:03 for completed operations during a

AM reschedule





Please respond to

vantage@yahoogrou

ps.com







How are your resource groups (and resources) set up? (Do you have "auto-move"

checked or unchecked?)



"The developers" of course ARE full of it - no matter how you have this set as, if

both the 'move from' and 'move to' OPs are completed, there is no move to

accomplish and the move should be negated (along with the move time) from the

schedule.



Let's assume they are 'right' though and you haven't set your resources for

auto-move or performed a manual move between OPs: Ask "the developers" why the

move time DOESN'T GET CONSUMED OVER TIME. (This same issue exists for queue time.)



There IS a record in the db (labor detail table) of when an OP is completed. Any

post OP specified MOVE (or pre OP specified Queue) should be consumed by the

scheduler as time passes.



This is late 70's MRPII functionality.



...But of course 'the developers' wouldn't KNOW that as they likely weren't born

yet and never read that book (and certainly NONE OF THEM have ever done any real

world scheduling and have any experience to base their INANE opinions on).



Keep the pressure on Epicor and go over development' s heads. Their development

group is a self serving silo unto themselves.. . Perhaps it's time for Epicor's

customer base - en masse - to tell the board of directors this is unacceptable.



If Epicor is an ethical corporation truly dedicated to fulfilling their service

obligations to their paying customers, they will listen as that "is how it is

supposed to work".



Rob Brown



--- On Tue, 5/27/08, tblakely@automatics mp.com <tblakely@automatics mp.com> wrote:

From: tblakely@automatics mp.com <tblakely@automatics mp.com>

Subject: [Vantage] Move time scheduled for completed operations during a

reschedule

To: vantage@yahoogroups .com

Date: Tuesday, May 27, 2008, 5:14 PM



I am running 8.03.404B. Is anyone else having difficulty with move time



being scheduled for completed operations during a reschedule? I have



discussed this with Epicor and the developers state that this is working as



designed. Consider the following scenario with 2 days move time for each



resource group and production works Mon - Thurs. I perform a reschedule



and this is what I get...



1st Op (completed) scheduled to start 5/27/08



2nd Op (completed) scheduled to start 5/29/08



3rd Op (completed) scheduled to start 6/3/08



4th Op (open and needs to start today) scheduled to start 6/5/08.



In my opinion, if I forward schedule from today, the above stated job



should start today on the 4th op. Am I crazy, should the move time between



completed operations be calculated in a reschedule? According to Epicor,



this is how it is suppose to work.



They say this is how it's always worked but I don't think we had this



problem when running 8.03.305. If you are running an earlier version than



404 could you test this for me.



Thanks,



Tonia R. Blakely



Enterprise Systems & Logistics Manager



Automatic SMP



Ph: ext. 256



Fx: