Hoping someone has already addressed a similar issue –
We are using MRP, global scheduling and work-queues. We backward schedule and we don’t allow for any scheduling in the past. This all seems to be mostly working or we’re evolving to do things better, but an issue we’re now running into is prioritizing jobs/creating a sense of urgency with operations. With global scheduling running, it looks like all the jobs re on time with respect to the work queue. Is there anyway to have the days late displayed on the work queue screen?
With everything appearing to be on time, we don’t have a way for our operators, or our supervisors to see what machines/jobs take priority to run. Any advice would be greatly appreciated!
If the days late is not already in the data view in the work queue, you could bring in the Global Scheduling Order dataset and use that to highlight the jobs.
Garret, We are newish to Kinetic (May go live) so we are still learning. If I understand correctly, using MRP with backward scheduling, not allowing anything to be scheduled in the past and global scheduling running each night, I think these dates will always show “on-time”. Are there other areas that you’re aware of that would indicate being late? Maybe we have something configured incorrectly.
So, that will cause any started operation to have new dates. Not sure about the start date, but the end date will recalculate. That will make those operations look like they are still on time when they may not be.
You have 100 jobs that are scheduled to start today, 1/5.
10 of these jobs do not get started.
These 10 jobs get rescheduled to start on 1/6. These jobs are lumped in with the jobs that REALLY need to start on 1/6 and you want to know what jobs actually needed to start on 1/5?
That makes sense. Last I talked to the team about unchecking this box there was comments about not being able to move/reschedule any operation of a job after the job has been started. Is this how you understand that to work? It’s not how it reads to me, but I will be honest I haven’t tested it. Probably deserves some testing.
The issue is that from the view our operators have, they can’t see when jobs are past due. Operators use shop floor MES, in their work queue, unless a job is locked which causes other potential issues, the start date and due date keep getting pushed out as global scheduling runs. The job might have a due date of 1/6, but in reality, to be on time to the customers date, we would have had to have it off the machine by 12/31. There isn’t anywhere on the work queue that tells them that original due date or that the job is running behind. As far as I can tell, the way we have our settings, MRP will work to give us anticipated completion dates based on actual production and method times. Hope that makes sense.
If folks insist on being able to prioritize, I would explore the downside of leaving the original dates, etc on the job and not reschedule them. Use this information to determine priority.
Otherwise, jobs do have a scheduling priority code that can be changed. You can even modify the list of available priority codes to suit your needs.
–
In my experience prioritizing jobs is a never ending cycle that doesn’t accomplish much.
I think if the job is due on 1/6 it needs to be finished on 1/6, and if it isn’t, figuring out why and fixing that is the real way to solve your issue.
If you are prioritizing, this usually means you are in a zero sum situation, where you have 2 things that need to be finished today, and you can only do one, so you prioritize it. The thing that didn’t get done today becomes tomorrows priority, ad inifinitum.
Getting Epicor and MRP to spit out useful supply suggestions like POs and jobs with accurate quantities and dates is a feat in and of itself, so if you are there, congratulations.
If your suggestions are accurate and your company simply cannot complete them as written, my advice would be to focus efforts on understanding why. This usually involves comparing what you need with what you actually get, with thing like capacity, vendor and manufacturing cell KPIs, etc.
It’s not standard/best practice to run Global Scheduling every night. From what I’ve heard from others, in my experience, and how we do it is to run it only once a week (over the weekend). This will help keep things from moving around so often.