any idea how to identify jobs that maybe at risk of not being completed on time.
could be a BAQ or any means to highlight
Can you be more specific about what you mean?
Like jobs that won’t be completed by the job due date, or jobs where the due date is after the ship by for the finished good…?
Could probably do a BAQ on JobHead/JobOper
Sum up the JobOper values…((Estimated Hours - Actual Hours) / 24) where OpComplete is false…that’ll give you a “days remaining” of work to be completed
Add that to the current date - if it exceeds/equals the JobHead due date then include on report
jobs that wont be completed by the job due date
Any job where an operation upstream from the final op was completed late?
Final Op start date < today and hasn’t been started yet?
Thanks let me try that
BAQ is a fine place to start.
Keep in mind that the job’s due date may be a moving target. When operation deadlines go zooming by, the rest of the job may be rescheduled forwards so that work is scheduled on days that are going to exist.
The job’s required by date doesn’t follow the scheduled completion date, but may also change when requirements change. That’s likely fine and expected. A job’s requirements should reflect when the job’s output is ultimately required, assuming we’re telling the system what we actually want.
The lowest effort method would be to look for jobs with a due date later than the required date. Scanning due-vs-required dates on the Job Tracker landing page grid is already an option with zero development work. It’s not perfect but it’s a free 80% solution. Jobs that are scheduled in advance of requirements for capacity or whatever reasons could be overlooked.
Looking at operation start and end dates can be more proactive. Those may be shifted by scheduling as well, but it’s easy enough to schedule a task just before scheduling that returns operations which aren’t started or completed and have a start or due date <= today. That’ll be more informative about sources of delayed work at the moment it happens, and if jobs that have been scheduled in advance of requirements are running late.
1 Like
I am currently wrapping up something similar. As @kananga said If you look at the Required By Date, it may throw you off as schedulers could change it tomorrow.
I think the best way is to only consider a Job that has been started in your calculations, there are a few options:
- Look at JobHead.ProdQty vs JobHead.QtyCompleted
- Look at JobOper.LastLaborDate
- Look at JobOper.RunQty vs JobOper.QtyCompleted
- Join on LaborDtl.JobNum, LaborDtl.AssemblySeq, LaborDtl.OprSeq to get Calculated_HasAnyLabor
If you go the Qty routes, it won’t update the values until someone does Report Qty or End Activity.
If you want to actually figure out the EarnedHrs before any Qty is reported, you would have to do something like this BAQ - Time Conversion - #18 by JakeM (Calculate Realtime LaborHrs), once you have that and you have the JobOper.EstProdHours + JobOper.EstSetupHrs you can find the bottle necks, as well using JobOper.ProdStandard you can determine the Attained Standard, the trend etc, but only if they report qty otherwise you don’t really know how much they have completed, how much went to scrap etc…
TLDR; I would determine if a Job has been started and then consider the dates vs today’s date, or look at Operations Completed, or at Estimated Hours vs Realtime Labor Hours and you can determine with that information even if they are behind, when they will be done (BetterEstimatedCompletionDate). You can only get the trend if they report some qty.
1 Like
Just to add a quote from Mr. Jones that I tend to agree with. This is another question that comes up often when to report qty. I love partial reporting. This is why @jgiese.wci has PLCs reporting Qty, and not Humans whenever possible 
we use earned hours (the hours the customer is paying us) to calculate the efficiency number. So if the operation/job was for 10 units, and we estimated it should take 2 hours per unit. If they complete 7 units, then they earned 14 hours. If it took them 12 hours to complete those 7 units, then efficiency would be calculated as 14 / 12 = 116.7%
If they don’t report quantity on the job until it is 100% finish, do no reporting partials; I would look at the estimated versus the actual then and when your actual starts to exceed the estimated, that is when it becomes concerning.
I find it bad practice to not report partial quantities. It has the tendency to impact your schedule and capacity planning. Nothing worse that looking at the schedule and seeing we have 100 hours of work to do, and then the next second that drops to 25 because the shop floor decided then to report their quantities for the week
1 Like
Some more context her, for us, 99% of the time a partial qty is the difference of time 10-15 minutes in our load at worst case. Compared to the schedule that’s pissin’ in lake Michigan. So in the interest of not introducing math, I try to avoid partials at all cost. A partial for someone else could be the difference of days. Our load just isn’t affected that much so, a mileage may vary sort of situation.
1 Like