Friday, April 22, 2016

Windows 10, Realtrac Software and Your Shop

Windows 10 has now been released to the market for nearly a year and by Microsoft's accounting, it is a massive success. As of early 2016, Microsoft has said that around 280 million computers are now running their latest operating system. Of course, Microsoft contributed greatly to the success by literally giving away the software to most users of Windows 7 and Windows 8, but it's still a remarkable number.

Windows 10 is especially unique in one manner; Microsoft has claimed it's essentially the last Operating System they are going to release for consumers. They intend to continually update and improve Windows 10, such that 10 or more years from now, the Operating System they will still sell will be Windows 10. This stability brings unique benefits both for software development companies like Realtrac, but also you in your shop.

For a software development company like Realtrac, we now have a single platform we need to target and test our software against. Of course, we'll continue to support our users of Windows 7 and Windows 8 for the foreseeable future, but having fewer targets to test against is a wonderful, useful benefit for small to medium sized software development houses. Metaphorically, for our client software, Realtrac has to aim at a series of many little individual targets, each with their own little quirks and issues. For example, when Realtrac wants to show the user a calendar, we ask Windows "please make a calendar at this position on the users screen". What the calendar looks like, and how it acts to the user is drastically different in Windows XP compared to Windows 7, and again vastly different between Windows 7 and Windows 10. This means in the course of our development, we need a whole mess of computers running various versions of Windows so each change we make, we can see the results as our many end users will see them. Some day, we will have one very large target – Windows 10 – that we can test exclusively against and feel confident all of our users will have the same stupendous experience. Eliminating this variability means we need less time developing and testing, and we can spend more time writing awesome new features that will be more consistent and user friendly than ever.

The same benefits apply for you and your business. For the folks in your office that work on computers, once they get the hang of Windows 10, they'll be set - possibly for their career. This stability will benefit not only the Realtrac software running on your computers, but all the other CAD, Accounting, Office and other software running in your office as well.
In the end, this makes Windows 10 a compelling opportunity for you and your shop. While it's always a pain to perform such a major update on your systems, if Microsoft is true to their pledge, this could literally be the last time you make such a drastic change in your shop. Additionally, as software developers like Realtrac continue to update their software to support the rich new features in Windows 10, you should begin to see more consistency and ease of use amongst the many applications you need to run your business.

This may actually be an instance where it pays to be an early adopter. If all goes well, you'll get the pleasure of never having to worry about a major Windows upgrade ever again, letting you get back to your business once and for all!

Wednesday, February 24, 2016

Realtrac Scheduling with Outside Services, Service Receive Routers

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)

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.