I hope you had a good "holiday" Rob...
I have now found the scheduling codes in 305, so I will have a look
at those, thanks...
I think we need to re-visit our thoughts on the buy-direct stuff, but
after having used it on one of our first jobs through the system, we
found this to be a bit inflexible especially where job boms change
mid process. Additionally where customers have not issued us finite
boms ( remember we are a contract manufacturer so we make their
products for them ), we find ourselves putting planning jobs into the
system so that we can order the long lead time materials, and then
when the proper boms are engineered we scrap the planning jobs and
replace them with proper ones. Where parts are tied to jobs we found
this more difficult to manage.
I am also worried about scheduling and how we get this to reflect
reality. We tend to get pulled around by our customers quite a bit,
and therefore changes to schedules happen on a daily basis. I feel we
are going to end up spending more time managing the plan than we are
actually making the stuff! Particulalty the setting of "bandwidth"
via the scheduling blocks is an issue as this may well vary from job
to job. I might stick 5 people on a job today, but 10 next time
around because I have much less time to play with. Obviously if we
want Vantage to make sensible suggestions we are going to have to
keep it up to date in terms of how many schedluing blocks we want to
use on any given job.
As for the go-live target date, we have been running Vantage "live"
now for about 3-months with roughly 10% of our output going through
Vantage. Ideally I would like to have full migration completed by
Christmas, but we still have a lot of work to do. Our old system had
been developed ( by ourselves ) over the last 25-years, and it was
very slick at certain things, particularly quality management, non-
conformance management, shop floor data collection, user-
friendliness!!. We are having to look at how we use Vantage to
emulate the functionality we had in our old system. That's the part
that is taking the time.
You are totally correct however in that we are going to have to bite
the bullet before long and move the other 90% of our business over to
Vantage. I am sure however that I will have no hair left after we
have done that...! ;o)
Many thanks,
Nick
--- In vantage@yahoogroups.com, Robert Brown <robertb_versa@...>
wrote:
indicate whether the code is forward or backward schedule and what
scheduling priority multiplier to use when the global does a first
pass to determine what sequence it should attempt to schedule all of
your jobs into available capacity. It also allows one code to be set
as the default. Finally (but perhaps not yet in 305) a code can be
set to a 'minimize WIP' option (that hasn't proven to work in 404 but
we haven't yet tested in 305a).
is very wrong with a job schedule driving the requirement if it was
supposed to be purchased 1000 days ago!)
(yesterday's capacity - utilized or not - is already gone). Allowing
this can produce deceptively optimistic due dates on other jobs
requiring those same resources that are NOT yet past due (as the past
due start date load of the other jobs is not competing for 'today'
and future finite capacity of the resources).
due to start in the past but wasn't)... A condition that can be
handled with over time typically to 'get back on schedule'. If it
proves to be a common condition, I wouldn't do it. Better to see the
other competing jobs for resources come back with Due dates after
your required by dates.
available resources.
(assuming you aren't a 24x7 order entry operation). I'd also run full
regens and save the net changes for manually invoked runs if you feel
they will clean up messaging during a specific day because of
extraordinary suggestions processed.
total 'real' supply/demand and capacity conditions.
(compared to our highly optimized over time legacy system) - there is
something to be said for 'ripping off the band aid' and going to it
100%.
2 ways to do something is always asking for trouble (as processes get
fuzzy and difficult to improve upon). Vantage itself (in many areas)
offers 2 (or more) ways to accomplish the same thing - so we've spent
a great deal of time determining which way best suits the general
needs and then limiting users to use only the chosen method.
I have now found the scheduling codes in 305, so I will have a look
at those, thanks...
I think we need to re-visit our thoughts on the buy-direct stuff, but
after having used it on one of our first jobs through the system, we
found this to be a bit inflexible especially where job boms change
mid process. Additionally where customers have not issued us finite
boms ( remember we are a contract manufacturer so we make their
products for them ), we find ourselves putting planning jobs into the
system so that we can order the long lead time materials, and then
when the proper boms are engineered we scrap the planning jobs and
replace them with proper ones. Where parts are tied to jobs we found
this more difficult to manage.
I am also worried about scheduling and how we get this to reflect
reality. We tend to get pulled around by our customers quite a bit,
and therefore changes to schedules happen on a daily basis. I feel we
are going to end up spending more time managing the plan than we are
actually making the stuff! Particulalty the setting of "bandwidth"
via the scheduling blocks is an issue as this may well vary from job
to job. I might stick 5 people on a job today, but 10 next time
around because I have much less time to play with. Obviously if we
want Vantage to make sensible suggestions we are going to have to
keep it up to date in terms of how many schedluing blocks we want to
use on any given job.
As for the go-live target date, we have been running Vantage "live"
now for about 3-months with roughly 10% of our output going through
Vantage. Ideally I would like to have full migration completed by
Christmas, but we still have a lot of work to do. Our old system had
been developed ( by ourselves ) over the last 25-years, and it was
very slick at certain things, particularly quality management, non-
conformance management, shop floor data collection, user-
friendliness!!. We are having to look at how we use Vantage to
emulate the functionality we had in our old system. That's the part
that is taking the time.
You are totally correct however in that we are going to have to bite
the bullet before long and move the other 90% of our business over to
Vantage. I am sure however that I will have no hair left after we
have done that...! ;o)
Many thanks,
Nick
--- In vantage@yahoogroups.com, Robert Brown <robertb_versa@...>
wrote:
>I am working like a fool!).
> Sorry Nick. I'm 'off' today (national Labor Day holiday... yet here
>a group of codes you can define in Scheduling code maintenance. They
> Scheduling Codes: Every Job is assigned a scheduling code which is
indicate whether the code is forward or backward schedule and what
scheduling priority multiplier to use when the global does a first
pass to determine what sequence it should attempt to schedule all of
your jobs into available capacity. It also allows one code to be set
as the default. Finally (but perhaps not yet in 305) a code can be
set to a 'minimize WIP' option (that hasn't proven to work in 404 but
we haven't yet tested in 305a).
>scheduling direction as the reset is all Global related.
> If you're not running global - none of that matters except the
>today. (As you said - it is a blatantly clear signal that something
> If I was just running MRP, I would too also allow dates prior to
is very wrong with a job schedule driving the requirement if it was
supposed to be purchased 1000 days ago!)
>it is a company config setting.)
> My other comment was for Job start dates prior to today. (I think
>are being scheduled to a time when capacity no longer exists
> If you allow it, any job schedules allowed to start earlier today
(yesterday's capacity - utilized or not - is already gone). Allowing
this can produce deceptively optimistic due dates on other jobs
requiring those same resources that are NOT yet past due (as the past
due start date load of the other jobs is not competing for 'today'
and future finite capacity of the resources).
>might be useful as it is a clear sign something is wrong. (Job was
> If you find this would be a rare condition for you environment, it
due to start in the past but wasn't)... A condition that can be
handled with over time typically to 'get back on schedule'. If it
proves to be a common condition, I wouldn't do it. Better to see the
other competing jobs for resources come back with Due dates after
your required by dates.
>aren't (daily/weekly) rejuggling your schedules to optimize use of
> Again - Unless you run Global, not much of that matters as you
available resources.
>however, set it up as a recurring task to routinely run nightly
> I think your on the right track since you only run MRP. I would
(assuming you aren't a 24x7 order entry operation). I'd also run full
regens and save the net changes for manually invoked runs if you feel
they will clean up messaging during a specific day because of
extraordinary suggestions processed.
>best path to take. Right now you are not subjecting to your
> Until you are fully running the business, you really won't know the
total 'real' supply/demand and capacity conditions.
>Vantage has proven to be a pretty inefficient planning tool for us
> Do you have a target date to move entirely to Vantage? While
(compared to our highly optimized over time legacy system) - there is
something to be said for 'ripping off the band aid' and going to it
100%.
>people '2 ways' (old system and Vantage) to do things. Giving people
> That way you focus entirely upon optimizing it and also don't give
2 ways to do something is always asking for trouble (as processes get
fuzzy and difficult to improve upon). Vantage itself (in many areas)
offers 2 (or more) ways to accomplish the same thing - so we've spent
a great deal of time determining which way best suits the general
needs and then limiting users to use only the chosen method.
>and we have, in some cases, changed our chosen method as a result.
> Again, that makes it easier to see where process bottlenecks lie
>8.03.305K
> Good luck!
>
> Rob
>
>
>
> --- On Mon, 9/1/08, nmtaylor1969 <n.taylor@...> wrote:
> From: nmtaylor1969 <n.taylor@...>
> Subject: [Vantage] Re: Material Lead Time / MRP Calculation In
> To: vantage@yahoogroups.comtaxes
> Date: Monday, September 1, 2008, 11:27 AM
>
>
>
>
>
>
>
>
>
>
>
>
>
> O dear Rob, my head hurts again...!
>
>
>
> Would you like a job in England ?! The weather is always great,
>and
> are low, and petrol/gas is as cheap as chips...! *NOT* ;o)
>
>
>
> Ok, I am not running the Global scheduling at all at the moment,
>a
> really we are scheduling our jobs manually rather than trying to
>
> setup scheduling to mimic what happens in real life. We are only
>
> putting 10% or less of our output through Vantage at this point in
>
> time anyway so this isn't really causing issues. We tend to run MRP
>seemed
> couple of times a week as we feel necessary, and this has not been
>
> scheduled to run automatically yet. ( I can feel you squirming in
>
> your seat even from here! ).
>
>
>
> Are you suggesting that the ATP algorithm will take into account
>
> material lead times ? I played around with this earlier and it
>buyers
> to consider labour only ?
>
>
>
> Job scheduling codes ? I haven't seen those in 8.03.305 ?
>
>
>
> I am currently running MRP with the "allow negative dates" option
>
> checked as this at least alerts the buyers to those parts which are
>
> really the drivers for the entire job. Seeing something that we
>
> should have ordered 100-days ago does focus the mind somewhat!
>
>
>
> As always you are way ahead of me at the moment, and I am worried
>
> about your comment of jobs not being considered as load. Could you
>
> just expand on that a little please ?
>
>
>
> I think the bottom line here is that its the discipline of the
>rubbish
> to feed back dates which are outside of our requirements that is of
>
> paramount importance, otherwise the whole thing just turns to
>we
> ( which is where we are right now! ). Perhaps I need to approach it
>
> from the angle that anything is possible until my buyers tell me
>
> otherwise. Then the job gets rescheduled by the planners and round
>accurately
> go again...!?
>
>
>
> Is that making any sense...?!
>
>
>
> Thanks as always...
>
>
>
> Nick
>
>
>
> --- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ ...>
>
> wrote:
>
> >
>
> > Nick,
>
> >
>
> > Not knowing if you are running Global scheduling (and how
>
> frequently) and MRP (how frequently, full regen or net change, and
>
> before or after global?) it is hard to give you a firm answer.
>
> >
>
> > In general, the only Vantage process that comes close to
>to
> producing a material availability influenced schedule is the ATP
>
> function in Order Entry. Unfortunately, that resulting schedule
>
> remains valid a very short period of time (becoming invalid as soon
>
> as any activity is reported, and/or resources-required capacities &
>
> competing load change, and/or purchasing suggestions are converted
>option
> actual POs with actual due dates varying from the 'prefect world'
>
> part lead time calculates dates and/or you run the Global).
>
> >
>
> > Assigning your Jobs scheduling codes with the 'Minimize WIP'
>using
> was SUPPOSED to take into account material availability (in an
>
> indirect way) - but the capability DID NOT WORK on 403-404 and we
>
> haven't bothered to test it on 405a (as we have no intention of
>on
> it at this time anyway).
>
> >
>
> > Does anyone out there know if Minimize WIP now works
>messaging
> 405a?
>
> >
>
> > All that said, you should be able to get MRP to act as a
>regen)
> engine to warn you of the scenarios you described.
>
> >
>
> > To do so, Global would run 1st (daily/nightly) and MRP (full
>wrong
> second. You would want MRP set to NOT finite schedule UnFirmed
>
> suggested jobs and you would want to (carefully!) experiment with
>
> allowing schedule dates prior to 'today'. (You may find allowing
>
> start dates before today & PO dates prior to today might be a
>
> managable signal to your buyer planners that something is very
>material
> and requires immediate action... Just don't leave your jobs in this
>
> condition or they will not be considered load.)
>
> >
>
> > Running MRP 2nd would result in material planning change messages
>
> based on the clean Global reschedule (that is undisturbed by MRP
>
> UnFirmed jobs as you have told MRP not to schedule them - just plan
>
> them).
>
> >
>
> > MRP being a 'push' paradigm, your messages would be on the raw
>
> materials required by jobs. Example Job XYZ starts 10/8 but
>the
> required at start is not due on PO 123 until 10/10 - so MRP gives
>10/10
> Buyer an expedite message (expedite in 2 days).
>
> >
>
> > It is then up to that Buyer to either do it successfully - or
>
> notify the job planner that the job can't be started until the
>and
> PO receipt.
>
> >
>
> > We actually run MRP 1st (and finite schedule the unfirmed jobs)
>results
> global 2nd as we don't rely on MRP for this type of messaging (and
>
> also don't want to lose a day to waiting for a job planner to firm
>
> and schedule the unfirmed jobs before raw material planning begins).
>
> >
>
> > Few companies have this level of coordinated action and
>
> communication (which is why MRP is such a lousy paradigm and
>all
> in tons of WIP).
>
> >
>
> > To combat that, we use a job release/review process. We review
>have
> jobs due to start in the next 2 days for material availability and
>
> only release those jobs that are 'clear to build'. Any jobs that
>on
> shortages are pushed out (and we send the buyers expedite requests
>(start
> the materials).
>
> >
>
> > We also have a review process for jobs 30 calendar days out
>in
> date) which helps reduce the amount of expediting at release time.
>
> (30 days works for us - other manufacturing scenarios I've worked
>later).
> would require a different 'fence' period - some sooner, some
>at
> >
>
> > It works as the jobs get reviewed and any expediting needed done
>8.03.305K
> initial job creation time, 30 days out, and 2 days prior to planned
>
> start.
>
> >
>
> > Rob
>
> >
>
> > --- On Mon, 9/1/08, nmtaylor1969 <n.taylor@ .> wrote:
>
> > From: nmtaylor1969 <n.taylor@ .>
>
> > Subject: [Vantage] Material Lead Time / MRP Calculation In
>of
> > To: vantage@yahoogroups .com
>
> > Date: Monday, September 1, 2008, 6:17 AM
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > Can anyone answer this one for me please...?
>
> >
>
> >
>
> >
>
> > Much of our business is conducted on a make-to-order basis. Many
>times,
> >
>
> > those products contain raw materials which are on long lead
>are
> >
>
> > and are not available immediately from the vendor. Many of them
>flag
> >
>
> > also make to drawing parts again being on extended lead times.
>
> >
>
> >
>
> >
>
> > If the customer orders a part and requires delivery inside on the
>
> >
>
> > known lead time ( which is usually the case ) I would like to
>loading
> >
>
> > this up somehow in Vantage. After all, what is the point of
>
> a
>
> >
>
> > ship-by date if we cam never achieve that anyway.
>
> >
>
> >
>
> >
>
> > What I can't figure out is that loading lead times against either
>
> the
>
> >
>
> > raw materials or the finished products itself within the MPF
>
> appears
>
> >
>
> > to have no effect on the job scheduling calculation. It always
>
> seems
>
> >
>
> > to schedule on labour capacity only.
>
> >
>
> >
>
> >
>
> > Surely part lead times defined in the MPF must have an effect on
>
> the
>
> >
>
> > scheduling of jobs ?
>
> >
>
> >
>
> >
>
> > Am I missing the point...?
>
> >
>
> >
>
> >
>
> > Thanks,
>
> >
>
> >
>
> >
>
> > Nick
>
> >
>