Modifying your ZoneScheduler system via FlowingPipes

If you did not already know, SD's ZoneScheduler system allows you to divide your territory into multiple zones (any quantity between 1 and 30, with each zone defined as a set of zipcodes), and allocate JobCount capacities for each. ServiceDesk then keeps track of the total JobCount burden for each zone, and interdicts if a call-taker attempts to schedule above allocation. More significantly, the same setup is used to keep outside entities informed of your availability for added service in any zipcode. The provided information is based on the zone in which a potential new job falls, and on a comparison between that zone's allocation for any given day and the jobs as presently booked. The entities that Rossware software may keep informed of such availability include ServiceBench, ServicePower, LG, techs using SD-Mobile, and your own customer when using the On-Line Scheduling feature.

This document concerns an add-on feature we call FlowingPipes. This add-on is designed to address a little quirk in zone-scheduling that otherwise may arise. In a nutshell, it's possible you could have one zone fill up, while still having much unused capacity in another. If new people still want to schedule in the filled-up zone, you may want to accommodate them -- based on the fact that, given the unused capacity in the second zone, you still have capacity overall. This is particularly true if it's easy to shift a tech, who otherwise would be handling allocations in the still-with-vacancies zone, over into the otherwise-overbooked zone.

Regardless, the simple concept behind FlowingPipes is, it gives you a mechanism to address this. Specifically, it allows you to create a specification that, in essence says: if Zone A is otherwise fully-booked but someone wants to schedule there, and if Zone B otherwise has sufficient vacancies to take Zone A's excess, we'll deem Zone A to have a vacancy.

We call the devices FlowingPipes because, in a sense, you can think of them as allowing JobCount burdens to "flow" from one zone (the otherwise fully- or over-booked one) into another. With such flow, the otherwise fully- or over-booked zone may once again show vacancies.

For a picture-oriented image of how the device works, go to your ZoneScheduler form in ServiceDesk (Shift-F5), and look at how the graphs are setup for each zone (this assumes you've actually done a setup with multiple zones). Now, picture each graph/box as a water tank, and imagine you can create a little pipe that allows water to flow from one tank into another -- not any tank into any other, but just particular pipes (one-way ones at that) to allow water (or, actually, JobCount burdens) to flow from just below the top of one tank into a particular other tank.

That's the metaphor. The reality is you can make as many 'pipes' as you want, each of which will allow JobCounts to be shifted (for the purpose of tallying against maximum allocations) from one zone to another. In every case, the pipe allows flow when the flow-from zone is at or above maximum allocation (i.e., to potentially open up vacancies there), and when the flow-to zone still has one or more vacancies.

In this connection, you'll see that the ZoneScheduler form has a new checkbox labeled "adjust view for flowing pipes." This box will remain disabled until and unless you setup some pipes. Once you do, you'll find that with it checked the graphs change per the above-described scheme (i.e., to make vacancies, if possible, within any zones that were fully booked and in respect to which you've made pipes flow into zones that still have space).

No sooner did we first create this FlowingPipes facility than we discovered persons who'd created what we now call "Reciprocal Pipes." It was not a dynamic we'd contemplated, and quickly we realized it's not one that makes much sense, either. This is the situation, simply, where you have a pipe flowing from Zone A to Zone B, and also one flowing from Zone B back to Zone A.

Why does this not make sense?

Quite simply, if you have pipes flowing both ways between a pair of zones, it effectively makes that pair into a single zone so far as allocations are concerned. If that pair has effectively become a single zone, why even bother with the separation? If operatively you're going to make it into the functional equivalent of a single zone regardless, it's far more logical to actually have it as a single zone.

This realization lends itself to a brief discussion on where separation into multiple zones makes sense, and why.

Our analysis at Rossware is that, to separate any portion of your territory into a separate zone makes sense only if that region is so geographically remote, from another, as to make it inefficient on any given day to move techs who'd more typically be working, in the other region, into that one (i.e., in the event that other techs' normal area happens to be under-burdened on a given day, while the area in question gets greater-than-normal demand). By separating that region into its own zone, you can allocate to it solely the capacity as can reasonably be met, there, in an efficient manner (i.e., without having techs drive excessive distances).

A perfect (but not the only possible) illustration, of where zone-separation makes sense, can be pictured if you imagine a service company that is centered within a significant metropolitan area. Say, Omaha, Nebraska. Let's suppose this is you. Overall, this greater metropolitan area is sufficiently compact and homogenous that there is no real impediment if on a given day the southern half happens to be more busy than the northern half, to send more techs that way, and vice versa. Given this, it's logical to make that entire area into a single zone. However, let's suppose there's a remote community to the north you want to service, another to the south, and one each to the west and east. Each of these communities is a far enough drive, and with a small enough population, that for each you want to pick a particular day of the week you'll be sending a tech there (for as many jobs as you can put on his roster when he goes), and otherwise you'll endeavor to avoid investing in the long drives those communities require.

Given the above structure, you setup each of those four satellite communities as their own unique zones, giving you five zones total (let's suppose you give them Zone numbers 2, 3, 4, and 5, while naming your core/main Zone as 1). Let's further assume it's one tech you're sending to each of those remote zones on a given day of the week (e.g., going to Zone 2 on Monday, 3 on Tuesday, etc.), and his typical capacity is 9 jobs. Given this, you setup your ZonePlanner to allocate zero jobs to each of these zones, except on the particular day-of-the-week when you intend to send the tech, and for that day (in respect to each as applicable) you allocate 9 (in the meantime, and depending on quantity of techs, you may have allocated, say, 45 to your Zone 1).

Let's suppose it's also typical for these remote zones to under-utilize their allocation. Suppose on a given Monday, for example, only three jobs are booked for Zone 2. Assuming your tech is driving from the core area out to the remote community, it's likely easy for him to do some jobs both within the core, while also doing the three booked for him in Zone 2. Certainly, you don't want to refrain from booking him another six, in the core. For this reason, it makes sense to let excess JobCount burdens flow, from the core, into the unused capacity of Zone 2 (thus making vacancies available within the core).

But what about the "reciprocal" opposite (i.e., having burdens flow from Zone 2 into the Zone 1 core)? In particular, let's consider this for days of the week other than Monday (the exclusive day you're allocating for Zone 2). Please bear in mind, in this regard, the direct counterpart of burdens flowing in one direction is capacity flowing in the opposite. If burden were to flow from Zone 2 to the core, it would effectively mean capacity flows from the core to Zone 2 -- which would effectively open Zone 1 capacity to Zone 2 use -- on any and every day of the week. This is positively not a result you want.

This is to show you that, fundamentally, reciprocals not only lack a good basis in logical design; they can also lead to results that are conceptually antithetical to your own sensible purpose. All between-zone flows should be one-way only. As you design your FlowingPipes, please be sure to abide by this rule.

In principle, it's very simple. You just need to create a document with two columns, and as many lines as wanted. Each line is a pipe. The first number in each line describes a flow-from zone. The second describes the flow-to zone. The two numbers are separated with a simple tab. Thus, your document will look something like this:

This example would create four pipes, one allowing flow from Zone 2 to Zone 1, one from Zone 3 to Zone 1, one from Zone 4 to Zone 1, and one from Zone 5 to Zone 1.

Anyhow, the idea is to create a document similar to the above, then save it with the name, format and location-spec that ServiceDesk expects.

In practice, if you have Microsoft Excel, it's likely easiest to create your document there (using the columns and rows that are inherent to that environment). Just make sure you save in Tab-Delimited format. If you don't have Excel, do it in any text editor (e.g., NotePad, WordPad, Word, etc.), but make sure you're saving it in Plain-Text format.

The filename ServiceDesk expects (and hence that you should save your document as) is FlowingPipes.TXT

The location where ServiceDesk will look for the file is in the sd\netdata folder on your server drive.

It will be easy, after you've created the document, to see if you did it right.

In ServiceDesk, go to the ZoneScheduler form (Shift-F5). If the new little check box ('adjust view for flowing pipes') is now enabled, it means that at least ServiceDesk found the file in the expected location and with the expected name. Otherwise, it means either you put it in the wrong place, or didn't give it the right name. Go back and check those details. (Remember, there's a Windows setting that may be hiding an extension on you, and applications like Word and WordPad are notorious for adding extensions without you knowing it).

If, on the other hand, you get an error when you go to the ZoneScheduler, it's likely you saved the file in the right location and with the right name, but there's a fault in the format. Unfortunately, besides being notorious for the unadvertised adding of filename extensions, text editors are also notorious for adding invisible internal formatting to a document, even when you don't want it. You won't see those invisible characters when you have the document open within the editor, but they're there.

To avoid both problems, be sure to use the 'Save As' option (under 'File' on the application's menu), and be certain that in the 'Save As Type' box (within the dialog where you choose the name, and so on) you specify 'Plain-Text', 'Text Document' or similar choice that denotes nothing but naked text will be saved (in Excel, again, it would be 'Text - TabDelimited'). If you fail to do that, you're likely to encounter both of the above frustrations.

Also, try not to be put off by the fact that the application asks if you want to save after (per the above) you've already done it. Whether it's Excel, NotePad, WordPad, or whatever, they're all anxious to save in their own format. Even if they know you've already saved as plain text (or Tab-Delimited if from Excel), they're hoping you'll save in their native format as well. In this case you should decline -- since (for the purpose you're fulfilling here) there simply is no need.