Many (most) scheduling applications chop up the timeline into discrete intervals that last for one hour, thirty minutes, or some other per-determined length. This means that an activity that lasts for 20 minutes cannot be modeled accurately. If you round down, you can easily produce an unworkable schedule. If you round up, you are obligating resources for too long. Over a period of time, this leads to substantial under-utilization of resources and obscures the real capacity of the enterprise you are scheduling.
The FAST system does not use pre-determined time intervals for any time specifications. Rather, it treats time as a continuous variable and allows users to specify any values of time for activity durations, resource availability intervals, and resource requirements within an activity. So why is this important?
Suppose you were scheduling a baking step in a food manufacturing process. You certainly wouldn’t want to over or under-cook the product! Or in a medical research situation, you want a sample to spend the exact amount of time in the centrifuge. In manufacturing, you know the exact time each procedure takes and to approximate that time will lead to gross misunderstanding of the true capacity of the factory. Money wasted because of the limitation of the scheduler! Similar examples can be cited for service scheduling, project scheduling, medical facility scheduling and many other applications.
The FAST system is an evolution of logic built for NASA to do mission planning and scheduling. In that environment, every minute wasted represented thousands of dollars. Using pre-defined time intervals, called time “buckets”, was unacceptable.
The reason others’ use of time buckets is that the underlying logic is like a spreadsheet. Each time interval is a column in this approach. That makes it easy to add up things in a column and determine resource usage in the interval represented by that column. The FAST system does not use spreadsheet-type logic, Instead it allows the user to specify any time values for activity durations and resource usage intervals. As described in the previous two postings, resource requirements can be specified over any intervals of time with the breakpoints in these profiles being any values. A simple graphic showing this generality is seen on the home page where a generic activity is illustrated.
Even more flexibility for specifying resource requirements is described in the next posting. Be sure to read that it and future postings to see why the FAST system can schedule your environment when other systems have limitations.