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).
First, let’s take a look at a simplified router:
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 backward 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 the 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.
From 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 outside service vendor.
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 to confuse the matter.) Figure 3 below shows a Realtrac PO made out to Smith Heat Treat.
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 Smith Heat Treat.
When we take a look at Figure 4, we do see some differences from Figure 2. Since the Purchase Order tells us that our 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 is 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).
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:
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.
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 order’s 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 enter 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 in 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.