A generic scheduling format is the way to go. Here’s why:
A domain scheduler is designed and implemented for a particular application area. Here are a few examples :
- Service schedulers have trucks, technicians, test equipment, and “calls.”
- Medical schedulers have physicians, nurses, labs, operating rooms and instruments and appointments.
- Event schedulers have conference rooms, ballrooms, dining rooms, servers, tables and chairs and events.
- Sports schedulers have games, fields, officials, coaches, teams and games.
The problem, however, with domain-oriented schedulers, like those above, is that even if your application is predominately in a particular application area, it probably won’t be an exact fit – and that will be a problem. There will always be peculiarities that leave some of your requirements unsatisfied. To use a domain-based scheduling system, you usually have to do some mental gymnastics or manual procedures to compensate for something the application designers didn’t think of. Or maybe the underlying logic they used is limited by their assumptions about your application area.
On the other hand, a generic scheduling system can eliminate these problems. The designers of such systems have considered a wide variety of scheduling circumstances and avoided assumptions that might be valid for one situation but not for another. It’s more than just the terminology that is peculiar to each different domain. For example, some environments need only resources that are specifically-named items (like machines or people), others require pools of identical but non-differentiated resources (like power, hand tools, tables and chairs). Activities scheduled in one environment might have different descriptions which require different logic to schedule. Experience has shown that most environments do not fit exactly into the restrictions of an application designed specifically for that environment.
To understand the advantages of a generic scheduler, think in terms of the office software applications we’re all experts at using. We all know how to use a generic spreadsheet to build a balance sheet, income statement or invoice. We also know how to use a presentation tool to build briefings–even fancy ones with special effects and themes. We all use word processors. And in using all these programs, we we know what the following terms mean in the context of those applications: “cells,” “rows,” “columns,” “tabs,” “word boxes,” “bullets,” “page breaks,” “transitions,” among many others.
So following this logic, a generic scheduler requires a few of these generic terms as well. The terms “activities” and “resources” have emerged for things that take time and things that are needed. A few other terms like “horizon, ” “ duration” and “constraint” are also common. By mastering the generic vocabulary for scheduling, you can use a generic tool to build an application that not only fits your real environment, but also your organization’s operational peculiarities.
In a previous blog, (http://schedulingdoneright.com/five-steps-to-successful-scheduling/) I described an architecture for scheduling logic that is nearly universal–at least for non-mathematical algorithms–called the “Five Agent Scheduling Technique. By using this architecture and a common (or generic) scheduling lexicon, users can implement capabilities that accommodate virtually all scheduling environments. The goal is to add scheduling to the list of generic applications like spreadsheets, word processors and presentation tools. A little effort to learn the generic lexicon for scheduling will pay off because users in any domain– hybrid or a unique–can find capabilities that handle their requirements.
Have a question? Ask away. I’m happy to answer.