Do any of these sound familiar?
- This project has several tasks that can be done by any of my qualified technicians, but it’s best if the people who start the project complete all of the tasks.
- Umpires can work multiple games in a day, but its best if they don’t have to move from one field to another in the same day.
- My crew members should get about the same number of assignments each week but never more than 15.
- I’d like to use the minimum number of work stations to fulfill this order, but the order must be delivered on time.
- It’s best that the participants in my tennis league get about the same number of matches.
- I’d like to delay the start of this project as long as possible, but it must be done by the promise date.
Clearly one type of scheduling application cannot satisfy a variety of objectives like the ones described above. A “one size fits all” approach is not going to work!
Many applications avoid this dilemma by automating only the record keeping and reporting parts of scheduling while leaving the decision making up to the user. For example, the drag-and-drop schedulers make no decisions, do no optimizing and find no alternatives. All of the cognitive tasks are left to the user. The application merely records or displays those decisions.
Although clerical tasks are necessary and important to simplify, the heart of the scheduling task is really two-fold:
- Generating alternatives that are feasible (that satisfy the essentials), and
Selecting the ones that are the best (most desirable).
A good scheduling application is based on separating the essentials from the desirables. The essentials are used to eliminate alternatives, and the desirables are used to rank them. This approach leads us to the question, “How should the alternatives be ranked?”
Here are a few metrics that can be evaluated and given a numeric value:
- Consistency in choosing resources
- Continuity in resource assignments
- Start time preferences (e.g. earliest to latest)
- Number of assignments in a specified period
- Cost
- Proximity to target values
This list can be extended, but it probably captures most situations. It is easy to recognize, however, that most real-world situations require compromises among competing objectives. For example, “I would like to use the same people on all tasks, but not if it means that my project will be late or will cause Joe to work ridiculous overtime hours.” Notice the competing objectives?
To support the competing objectives, we can use a blend of metrics like those in the previous list and let the user tune this blend until it mimics his tradeoffs. Now we have a truly adaptive decision support application. It’s a lot better than a “one size fits all” application or a “no decision support” application. Don’t you agree?