In this document we will discuss the Realtrac Schedule
engine in a general manner, and then discuss what happens when Outside Service
and Service Receive router lines (a new feature added in Realtrac Client
10.x.xx) are used.
For the sake of simplicity and clarity, we will present a
very simple router that only has entire days worth of work (rather than
scheduling down to the minute, as our scheduling engine does) and we will
assume our organization is open 7 days a week (so we don’t have to worry about
testing if a specific day is a weekend and move it, which would only muddle the
presentation).
Normal Scheduling
First, let’s take a look at a simplified router:
|
OP #
|
Route Code
|
Center / Vendor
|
# Days (Queue + Work Time)
|
|
10
|
RUN
|
SAW
|
2
|
|
20
|
RUN
|
MILL
|
2
|
|
30
|
RUN
|
GRIND
|
3
|
|
40
|
OUTSIDE SERVICE
|
SMITH HEAT TREAT
|
5
|
|
41
|
SERVICE RECEIVE
|
RECEIVE DOCK
|
1
|
|
50
|
RUN
|
FINAL ASSEMBLY
|
4
|
|
|
|
|
17 DAYS
|
Figure 1
- Simplified router for a part
From vendor after we’ve released them. (Think of it as our
analogue to the queue time for a work center.) So in this specific case, our
user has informed us that, on average, Smith Heat Treat takes 5 days to turn
around parts.
Our user sets this job to be backwards scheduled, and provides
Realtrac with a Due Date of 04/01/2016. (As you read, please keep in mind
Realtrac will attempt to schedule a job to finish the day before the due date,
so in following Figures, note that you’ll see work completing up on
03/31/2016.)
Let’s take a look at how Realtrac will initially schedule
this job. At this point the user has not cut a purchase order for the outside
service, nor has any work actually started on the job.
start to finish, our operations calculate out to about 17
days’ worth of work. You’ll note we highlighted the “Center / Vendor” and “#
Days” columns differently for OP 40. This is to indicate that in the Realtrac
system, we will ask the user to pick a specific vendor for this operation, not
a work center as they would normally do for a RUN or SETUP operation. Within
the Vendor Setup interface for each Vendor, Realtrac provides a value titled
“Turnaround Time”. This is the average amount of time our parts spend at the
Figure 2
- Initial Schedule of Realtrac Job
With the schedule built, we see that if we begin working on
03/15/2016, we expect that we will finish our parts right on time and be ready
to ship. If we looked at this job on 03/01/2016, it would have an On Time value of 14, meaning we have 14
additional days to begin working on this job before the schedule would slip
and, barring extra efforts, we will miss our job’s due date.
Router with Outside Service, a PO and an Expected Receive Date
With the addition of the Outside Service and Service Receive
routers, users are able to cut a Realtrac purchase order, and tie that purchase
order to a specific set of Outside Service and Service Receive operations.
Reflecting on the sample router shown in Figure 1, a user is able to tie
generate a Purchase Order specific to operation 40 for our vendor, Smith Heat
Treat. On this purchase order, they are able to set an expected date either for
the specific purchase order item, or for the purchase order as a whole.
So, let’s examine what happens when the user cuts a PO, and
tells us that they expect Smith Heat Treat will return our goods on 03/24/2016.
(We’ve not even started this job yet, so there is no labor of any kind here on
confuse the matter.) Figure 3 below shows a Realtrac PO made out to Smith Heat
Treat.
 |
|
Figure 3
- Realtrac PO, with line tied to Router Operation and an Expected Date Set for
Our Outside Service
|
Note that Figure 3 has the Expected Date set for the
specific item. If that was missing, but the PO itself had an Expected Date set,
Realtrac would use that date for scheduling. If neither date is set, then
Realtrac will schedule this job as discussed in the section labeled
Normal Scheduling above.
Let’s take a look at our schedule now that we have a specific
date for when the parts are going to return from our Heat Treat.
 |
|
Figure 4
- The results of setting the PO Expected Date to 03/24/2016 for our Purchase
Order
|
When we take a look at Figure 4, we do see some differences
from Figure 2. Since the Purchase Order tells us that are parts are being
returned on 03/24/2016, we’ve had to shift Operation 41 (the operation to
receive the incoming goods) a few days ahead to accommodate this. This
effectively tells us that we expect the parts to arrive on Thursday, but as far
as scheduling goes, we are not expecting the user to do anything on Friday
(03/25), Saturday (03/26) or Sunday (03/27). Loading wise, there would be
nothing related to this job scheduled on those days.
Also important to note, that when the user looks at this job
on 03/01/2016, they will now see an On
Time value of 11, not 14 (previously the shop needed to start the job on
03/15, but now in order to meet the vendors return date, we will need to start
the job on 03/12).
Router with Outside Service, a PO and a
less friendly Expected Receive Date
Vendors can’t always deliver exactly when we need it. What
happens if we cut a purchase order with a less friendly expected receipt date
for our goods. Let’s take a look at what happens when the vendor tells us they
will return our parts on 03/29/2016. (Note that the job still has a Due Date of
04/01/2016).
 |
|
Figure 5
- Our vendor has given us an expected return date of 03/29/2016.
|
We can tell off hand this date is probably going to give us
trouble. The vendor is returning our parts on 03/29/2016, but I have 4
additional days of labor on the parts in OP 50, which I know is going to make
me miss my due date. Let’s see what the schedule will look like:
 |
|
Figure 6
- March schedule for our Job
|
 |
|
Figure 7
- April schedule for the job
|
As we see in Figure 7, our job will now not complete
operations on the floor until April 2, leaving parts available to ship on April
3 or later. This is because we had to peg Operation 41 on 03/29/2016 due to the
PO Expected Date; we’re expecting our goods back from the vendor on that day,
so the schedule has to be adjusted accordingly.
Note that if a user
looks at this job on 03/01/2016, we will now present them with an On Time value
of -2. Typically, this means the user is running 2 days behind. While that
is somewhat true in this case, it is slightly different. Even if the user
started working on the job on 03/01/2016 (even though Figure 6 shows they don’t
really need to begin until 03/17/2016), the job will always have an On Time of
-2; in other words, it will perpetually be 2 days behind schedule.
In some ways, this runs contrary to anything we’ve done
before in the system, so our users will need to be cautioned. In any other
scenario, if a user is running behind in their On Time value, then working
faster on the parts (generating more parts per hour) or logging in to multiple
workstations simultaneously to produce parts would allow the user to “catch up”
and get the job back on track.
Other Notes
In addition to the schedule, the inclusion of this system
will generate some new Business Intelligence messages. Knowing a user may not
go to the schedule immediately, if we detect during scheduling that a purchase
orders expected date will shift the schedule, we will make sure to let the user
explicitly know this via a Business Intelligence message.
As more data enters the system, Realtrac will automatically
recalculate the schedule. So many factors can adjust the calculations shown
above. When the parts are returned from the outside services, Realtrac will
automatically recalculate the schedule. So keep in mind that the schedule
described in the section
Router with Outside
Service, a PO and a less friendly Expected Receive Date, if the Vendor
returns the parts early, we will note that and recalculate the schedule.
