US 20050137925 A1
A resource scheduling system includes a set of resources and associated resource attributes, a representation of resource demands, and a scheduling module for generating a schedule of resource utilization. The representation of resource demands and availability may include information about time slots, calendars, and shifts. A slot is a representation of a demand for one or more individual item. A calendar is a representation of dates when resources are needed. Each shift represents a set of time intervals of resource demands. Additionally, the system keeps track of individual resource availability and preferences and attempts to create a resource utilization schedule that satisfies all constraints generated based on the time slots, calendars, shifts, and resource schedules.
1. A computer-implemented resource scheduling system comprising:
a set of resources and associated attributes;
at least one calendar representing dates for resource utilization;
at least one slot representing demand for one or more individual resource items;
a set of resource constraints generated based on the at least one calendar and the at least one slot; and
a scheduling module for generating a schedule of resource utilization that satisfies at least a subset of the resource constraints.
2. The computer-implemented system of
at least one shift representing a recurring demand for a pattern of resource allocation.
3. The computer-implemented system of
4. The computer-implemented system of
at least one constraint.
5. The computer-implemented system of
user interface for generating the at least one additional constraint.
6. The computer-implemented system of
7. The computer-implemented system of
8. The computer-implemented system of
9. The computer-implemented system of
10. The computer-implemented system of
11. The computer-implemented system of
a user interface for creating and specifying objects.
12. The computer-implemented system of
13. The computer-implemented system of
14. The computer-implemented system of
15. The computer-implemented system of
16. The computer-implemented system of
a user interface for editing the at least one calendar.
17. The computer-implemented system of
an automatic calendar generator that generates a new calendar based on the at least one calendar.
18. The computer-implemented system of
a user interface for graphically displaying a match between demand for an individual resource and availability of the resource, using rectangular array to display time intervals divided among a plurality of classes.
19. The computer-implemented system of
20. The computer-implemented system of
21. The computer-implemented system of
22. The computer-implemented system of
23. The computer-implemented system of
24. The computer-implemented system of
25. The computer-implemented system of
26. The computer-implemented system of
user interface for designating a generated schedule as accepted and generating a permanent record of the generated schedule.
27. A computer-implemented method for resource utilization scheduling, said method comprising:
recording information about a set of resource items;
associating attributes with the set of resource items;
recording demand information about the set of resource items;
generating constraints based on the demand information; and
generating a schedule of resource utilization based on the generated constraints.
28. The computer-implemented method of
providing a user interface for generating constraints.
29. The computer-implemented method of
describing constraints in a natural language; and
allowing for modification of constraint clauses expressed in the natural language.
30. The computer-implemented method of
31. The computer-implemented method of
32. The computer-implemented method of
propagating the constraints using constraint back propagation.
33. The computer-implemented method of
generating a list of resource slots; and
assigning the resources to appropriate slots in the list of the resource slots.
This application claims the benefit of U.S. Provisional Application No. 60/513,666, filed on Oct. 23, 2003. The entire teachings of the above application(s) are incorporated herein by reference.
To function effectively, complex organizations must coordinate the work schedules of many individual employees, different kinds of employees, and other resources. Moreover, because skilled and experienced workers are often a scarce resource, and because payroll is the single largest expense for many businesses, schedules must use employees' time as efficiently as possible. The preferences of individual employees as well as union and government regulations further constrain acceptable work patterns. Creating a work schedule that satisfies requirements like these—arising from multiple, potentially conflicting sources—is a challenging mathematical problem. In practice, it is often impossible to find the best schedule with ‘pencil and paper’ methods, even when a relatively small number of employees are involved.
As an example, consider the problem of staffing a hospital ward, an emergency room, or an operating room. An adequate staffing pattern must satisfy many requirements: a certain number of doctors must always be physically present, another number of doctors must be available ‘on call,’ and these numerical demands will be higher during hours and days of expected peak demand. Among the doctors present, several must be senior or board-certified physicians. Physicians in training cannot legally work more than 100 hours per week, or more than 36 hours consecutively. Operating room teams must be scheduled together, and must be present whenever a surgeon is present. There must be at least one physician anesthesiologist to supervise every three nurse anesthetists. Staff with various religious affiliations will be unavailable on certain days of the week and on religious holidays that vary from one religion to another. Other employees may be unwilling or unable to work night shifts, or to work more than half time. Some employees may dislike each other and demand that their schedules not overlap. No one in the nurses' union can be required to work on three consecutive weekends, and no one can be in two places at once.
A traditional way to deal with such overwhelming complexity is simply to avoid it. Organizations routinely create work schedules by disregarding individual preferences and by fitting their workers into simple fixed, repeating shifts. But overly rigid schedules are inefficient and waste employees' time. And when skilled workers are in demand, businesses are at a competitive disadvantage unless they can offer potential employees flexibility and consideration of their individual needs.
It is therefore desirable to have systems that automate the difficult process of constructing employee schedules. Many currently available employee scheduling systems are little more than ‘fill-in’ programs. They allow a user to enter an employee name into a work position on a single day or on a succession of days and then reformat the schedule and compile hourly work statistics. A few more sophisticated programs allow users to choose from a small number of hard-wired scheduling patterns or templates, and help the user fill those in.
The present invention relates to a computer method and system for calculating work schedules for employees in an organization and, more generally, for calculating the scheduled allocation of constrained resources. Because the system's constraint language for specifying problems and the automatic scheduling algorithm used to solve these problems are so flexible, they may be used to set up and solve many ‘NP-Complete’ problems. One aspect of the present invention is a highly flexible system and method for setting up a very broad variety of employee scheduling and other resource allocation problems subject to an unlimited number and kinds of constraints and automatically solving those problems. Having constructed an acceptable schedule, the system may also help employers track the actual attendance of employees. When employees are unexpectedly absent, the system may guide the employer in finding suitable available substitutes.
In one aspect of the invention, a resource scheduling system includes a set of resources and associated resource attributes, a representation of resource demands, and a scheduling module for generating a schedule of resource utilization. The representation of resource demands may include information about time slots. A slot is a representation of a demand for one or more individual item. The representation for resource demands may also include calendars, which represent dates for resource utilization. The system may automatically create calendars based on those already entered in the system. Additionally, resource demands may be expressed as one or more shifts, each shift representing a set of time intervals of resource demands.
A set of constraints may be generated either automatically by the system, or manually by a user, the set of constraints taking into account resource demands and resource availability information. Such resource availability information may include resource schedules, which denote when a particular resource is available for scheduling.
Resource constraints may be entered or edited by a system user using graphic user interface that allows for easy constraint creation. In the user interface, constraints and/or their parts may be displayed using natural language, such that the user does not need to use a programming language to create or edit a particular constraint. In order to use the natural language for constraint creation, the user interface presents a range of choices for each of the constraint components and parts.
System user interface may also allow for creating, modifying and displaying descriptive attributes and for creating an acceptable range of values of each such attribute, as well as for associating to each type of data object in the system, a subset of said descriptive attributes that describe objects of the type. The types of data objects may include individual resource items, calendar sets, shifts, slots, assignments, substitutions and absences. The user interface may also allow for assigning a name to every object, thereby preventing two objects of the same type from having identical names, and for assigning values to an object for any attribute associated with the type of a particular object. An object may be switched between active and inactive status. Besides slots and shifts, additional classes of constraints that limit and describe acceptable schedules may be used.
The resource utilization system may then automatically construct resource schedules, each schedule representing an assignment of individual resource items to instances of demand for resources as denoted by a system of shifts and slots, subject to the limitations of resource availability, patterns of demand, and other constraints. Where no such schedule is possible, the system may generate and present diagnostic information, identifying resource shortages and irresolvable conflicts among the demands, resource availability and constraints.
Descriptive attribute may include names and data types. Each data type may be one or more of the following: an integer type, a numeric type, an enumerated type, a Boolean type, and a string type. Thus, acceptable values for attributes are restricted, attributes of integer type accepting integer values only, attributes of number type accepting values of positive or negative rational numbers only, attributes of enumerated type accepting as values only a finite set of alphanumeric strings, attributes of Boolean type accepting only values selected from the group consisting of true and false, and attributes of string type accepting as values any alphanumeric string.
Resource constraints may be conditional, depending on a set of other demands and/or constraints. In general, a constraint may be expressed as zero or more “if” clauses and one or more “then” clauses. A negative constraint may be rewritten as a positive one to follow the same representation. During the scheduling, the system may generate a list of resource slots and then attempt to assign individual resources to those slots. If no assignment is possible, a partial schedule may be presented to a user. Alternatively, the system may generate diagnostic information, including indication of resource demand and availability and/or constraint conflicts.
The system user interface may allow for manual modification of resource schedules, or for “accepting” a particular schedule and generating a permanent record of it. Furthermore, a user may enter or delete resources and/or constraints to test how those modifications will affect overall scheduling. In addition to scheduling resources, the system may keep track of resource utilization and of individual resource attributes. For example, numeric resource attributes may be declared cumulative, and the scheduling system may then sum up those attributes across an appropriate group of scheduled object. In such a way, a user may be able to generate cost or other estimates.
The foregoing and other objects, features and advantages of the invention will be apparent from the following more particular description of preferred embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention.
A description of preferred embodiments of the invention follows.
The system and methods described herein can be used for solving general resource scheduling problems in a variety of environments. In the case of employee scheduling problems, employees are one of the resources, but the algorithm and system described here are highly general and can allocate or schedule many other kinds of resources. For example, in scheduling one or more hospital operating rooms, employees, surgical equipment, and operating rooms are all tightly constrained resources that need to be scheduled and coordinated. A typical constraint might be, “No heart surgeon is scheduled for a heart transplant ‘shift’ unless a suitable operating room, an anesthesiologist, and a cardiopulmonary bypass team work the same ‘shift’”.
Similarly, in a factory, skilled workers, pieces of machinery and sub-assemblies are resources to be scheduled for the purpose of assembling a prescribed number of cars or computers.
An example of a less obvious kind of problem that the system can solve is the need for colleges to match up classes and classrooms. In this case, the classrooms are the resource to be allocated and the classes (or courses) are demands on the resource.
In one embodiment of the present invention, four semi-permanent data structures are created and maintained: employee library 124, shift or demand library 122, preference library 128, and constraint library 126. Two other libraries, attribute library 104 and calendar library 108, are used to help construct entries in the employee, shift, slot, and constraint libraries.
Depending upon the needs of the particular user, each of the libraries may be supplied to the user partially filled but allowing for user modification.
Each of the libraries may be in the form of a relational database and support all usual database functions. Each library entry has a unique numerical identifier. The user can also assign an optional alphanumeric name to any library entry. Libraries can be searched and ordered by identifier, by name, and by various properties or attributes of the entries.
Additionally, the following functions for managing the libraries are available:
Scheduling problems are described by copying items from these libraries to create three more data structures—employee database 204 (
Attributes and Classes
In order to describe the details of a scheduling problem, the user may create any number of ‘attributes’ (Step 102) using attribute library 104. Attributes are descriptive properties of objects used in setting up a scheduling problem. Position, seniority, and specialty are examples of possible attributes of employees.
Each attribute is assigned one of five attribute types by the user. An attribute may be of Boolean, integer, numeric, enumerated, or string type. Boolean attributes take only the values ‘yes’ and ‘no’ or ‘True’ and ‘False’. Integer attributes can take any whole number as a value, and the user may further designate maximal and/or minimal permissible values for an integer attribute. Numeric attributes can take any floating point number as a value and the user can designate maximal and/or minimal permissible values. For enumerated attributes, the user must supply a list of permissible values, each of which has the form of an alphanumeric character string. For string attributes any string of alphanumeric characters is a permissible value.
The user of the system can associate attributes with types of objects. There are seven of these types of objects: calendars, employees, shifts, slots, assignments, absences and replacements. Once an attribute is associated with a type of object, all objects of that type can be given values for that attribute.
Any attribute can also be declared ‘private.’ Private attributes express useful information about employees but are not displayed in the general employee library displays. Examples of common private attributes are employee's address, social security number or home telephone number.
Any integer or numerical attribute can also be declared ‘cumulative.’ Cumulative attributes support additional display and statistical procedures, involving the summation of the values of the attribute over a schedule. So, for example, ‘Hourly Salary’ is a useful cumulative attribute since summing it across a schedule will yield the payroll cost of the schedule, but ‘height’ and ‘weight’ of employees are usually not useful cumulative attributes.
Users can group objects into classes. Classes can be created either by listing their members or by specifying acceptable attribute values or ranges of values for membership in the class. The members of each class are limited to a single object type. Classes, once created, are named and stored in class libraries, where they can be modified and reused. Classes of the same type can be combined to form new classes, using Boolean operations: union, intersection, complementation and difference.
The user can create and name any number of ‘calendars’ (step 106). A calendar is any collection of designated days. Some examples are the calendar of all Tuesdays, the calendar of all weekend days, and the calendar of all state holidays. Calendars for each weekday, and ‘every day’ are integral to the system and always available to the user. The system has facilities for displaying each calendar in the typical format of a wall calendar, with days in the calendar highlighted.
Individual days or blocks of days can be added to or removed from a calendar by highlighting and clicking on the appropriate entries. The system also permits existing calendars to be combined with one another using Boolean operations: union, intersection, complementation and difference. Once created and named, calendars are entered into calendar library 108 and are available for use throughout the system.
Every calendar has a name, an alphanumeric string, that uniquely identifies that calendar. The user may also associate any user-defined attribute with calendars.
The user can create and name any number of employees (step 116). Each employee has a name. The name is an alphanumeric string, whose value uniquely identifies that employee.
The user can associate any user-defined attribute with employees. Among employee attributes one is given special treatment—‘Position.’ Position is always an enumerated attribute, and is intended to provide an initial sorting of the employees into job categories. In a hospital staff scheduling problem, for example, the positions might be ‘Doctor,’ ‘Nurse,’ ‘Administrator,’ ‘Technician’, etc. Lists of positions appropriate to a wide range of work environments can also be supplied with the system or imported from other sources so that the user can find many, if not all, of the position titles he requires within existing lists.
The user may associate any other attribute either to all employees or just to those employees with a given position attribute value. So, for instance, doctors may have ‘Specialty’ and ‘Board Certification’ attributes but not an ‘Hourly Salary’ attribute, whereas nurses may have an ‘Hourly Salary’ attribute but not a ‘Board Certification’ attribute. Similarly, every employee may have an ‘Age’ and a ‘Home Telephone Number’ attribute.
The user enters employees into employee library 124, specifying for each employee the values of the relevant attributes. In each case, the entry of attribute values is set up so that values outside of any specified numerical limits, or values not on the enumerated list of acceptable values for an enumerated attribute, cannot be entered. The user may leave attribute fields blank. Lists of employees can also be brought in from other resource libraries and database systems.
The system allows each employee to specify what times he or she is available to work (step 114); the scheduling interval is broken down into segments, and an employee can designate that he is or is not available for each of those segments. The size of the segments is determined by the user. For instance, the segments can be made 15 minutes long each.
There are multiple ways for an employee to specify when he is available to work and he can combine these ways:
The employee can select a single time interval or a set of time intervals on a graphical representation of the scheduling interval and declare himself available or unavailable for the selected interval or intervals.
The employee can select a Calendar Class, a Shift Class and a Slot Class, and declare himself available or unavailable for every time interval occurring on a day in that Calendar Class and during which a shift within that Shift Class and containing a slot within that Slot Class occurs. So, for example, an employee can declare himself unavailable on Sundays, or for the 5 to 11 shift on weekends, or declare himself available to work whenever there is demand for a nurse in the emergency room.
Each time one of these operations is performed, the graphical representation of the employee's availability changes to reflect the change in his availability. The graphical representation of availability also displays a comparison between the employee's declared availability and those times during which the employee could potentially work, based on the employer's needs as expressed in the shift database.
There is an ‘active/inactive’ switch associated with each employee. When an employee is inactive, the system does not schedule him to work. Inactive employees are visible in the employee library but their names and attributes are displayed in gray rather than in black. The active/inactive switch allows the user to enter employee information once, save it in the employee library and have it available for future use. By using their ability to declare employees (and also shifts, slots and constraints) active or inactive, users can easily experiment with modifications in their scheduling problems. For instance, the user can explore the effect on payroll cost of adding or removing employees.
Besides displaying employees and their attributes in a database format, the system also allows the creation of a virtual ‘index card’ for each employee. The system contains a flexible form design feature for these cards, so that the employee and his attributes can appear in an unlimited range of formats. Each employee's index card also can display that employee's private attributes. Displays of the employee's availability, constraints, preferences and Time Limits relevant to that employee (these terms are explained below), the current schedule of that employee, the attendance history of that employee, and statistical reports on that employee's attendance and schedule can also be associated with the employee's index card.
The user creates a demand or shift database 122 in step 118 to express the pattern of his needs for employees. This database is made up of any number of user-created shifts. Each shift expresses the request for a certain number and type of employee to work at specified and recurring times and days. The user can associate any number of user defined attributes with shifts. Each shift may have the following elements:
The user creates slot database 122 in step 120 to express patterns of demand for employees. This library is made up of any number of user-created slots. Each slot expresses a request for a certain number and type of employee to work. The user can associate any number of user defined attributes with slots. Each slot may have the following elements:
For any slot, the user may then define a ‘slot demand function’, by algebraically combining any number of demand variables. The value of the slot demand function corresponding to a slot on a given day defines the multiplicity or number of employees required to fill that slot on that day. If the rotation for a shift includes more than one day, the multiplicity for any slot in any day of the rotation is the maximum value of that slot's demand function calculated over all the days of the rotation.
For example, a car dealership could define a demand variable ‘number of cars to be serviced’ and then set the multiplicity of the ‘mechanics’ slot to be 1+(0.1 times the number of cars to be serviced).
In designating the class of eligible employees by attribute value, the user can designate a range of acceptable values of that attribute for any number of employee attributes, including employee name. If acceptable values are designated for more than one attribute, eligible employees for the slot must have acceptable values for every designated attribute.
For example, if the attribute ‘Position’ is given the value range ‘=Surgeon’, and the numerical attribute ‘Seniority’ is given the value range ‘>=15’, only employees who are surgeons with 15 or more years ‘Seniority’ are eligible to fill the slot.
Values and Ranges
When the system requires the input of a value of an attribute, the user is prompted to enter either an integer, a floating point number, a character string, or to select from a list of choices, depending on whether the attribute is of integer, numerical, string, or enumerated type. If the attribute is of integer or numerical type and there are upper or lower limits defined for the attribute, these limits are also visible, and the user is prevented from entering values outside the limits.
At some points, the system requires input not of a single attribute value, but a range of acceptable attribute values. This occurs, for example, in the specification by attribute value of acceptable employees to fill a slot.
When the system requires the input of a range of values of a string or enumerated attribute, the user is prompted for an attribute value, as above, and also for a comparison operator. For string and enumerated attributes, the only comparison operators are ‘equal to’ and ‘not equal to.’
When the system requires the input of a range of values for a numerical or integer attribute or other parameter, the above options are available.
Alternatively, the user may enter lower and upper bounds for the range and two comparison operators. Either bound may be omitted. Zero and ‘unlimited’ are the default values for the lower and upper bounds. The comparison operator for the lower bound is either ‘greater than’ or ‘greater than or equal to’ and the comparison operator for the upper bound is either ‘less than’ or ‘less than or equal to.
The user can create any number of constraints (step 112) to further specify and restrict acceptable schedules. Constraints are archived in constraint library 126 so that, once created, they can be reused.
Each scheduling problem has associated with it a database of constraints. The user can add or delete constraints from this database. When the user attempts to associate a constraint with a scheduling problem the system checks that all the terms in the constraint are defined for that scheduling problem. Constraints in the database of a scheduling problem can be toggled between active and inactive states. Inactive constraints are ignored in the scheduling process.
As constraints are constructed, they are immediately translated into English language paraphrases that are visible to the user. Highlighting any part of such a paraphrase makes visible and available for modification the choices in the constraint entry screen that were used to generate that part of the constraint.
The program has a built-in library of constraint templates. These are the grammatical forms of commonly encountered constraints but with some entries pre-set.
These templates can be used as a short cut in constructing commonly encountered constraints.
There are four kinds of constraints:
Each Time Limit expresses a limitation on the amount of time or number of assignments that one or more employees can be scheduled to work, counting those assignments with a specified class of shifts and to a specified class of slots within a specified class of calendars.
Examples of Time Limits are ‘Each nurse works at least 10 and no more than 40 hours in every 6 week interval, counting only the emergency room shift and only time worked on weekends and holidays,’ or ‘The total number of hours worked by all the junior surgical residents on any weekend is between 100 and 200 hours.’
Each Time Limit may have the following elements:
If either limit is omitted, a default value is used. The default value for the lower limit is zero. The default value for the upper limit is ‘unlimited.’
This range specifies the number of time units that may be worked in any interval of the specified interval size.
Each Conditional Constraint expresses a restriction on acceptable schedules of the form ‘if a certain pattern of work assignments occurs in the schedule, then another must (or must not) occur.’
Some examples of Conditional Constraints are:
Each Conditional Constraint is designated by the user as either a ‘weak’ or ‘strong’ Conditional Constraint, and the user may toggle a Conditional Constraint between these two designations. Strong Conditional Constraints must be satisfied in any acceptable schedule. Weak constraints may be violated, although the automatic scheduling algorithm is designed so that they will be satisfied in most cases.
Conditional Constraints are specified by a formal grammar and comprise a limited programming language. However the system is structured so that the user creates Conditional Constraints by making a series of choices and selections from lists, rather than by creating program code. As a constraint is constructed, an English language translation of the constraint is simultaneously constructed and displayed. The user is thus shielded from the complexity of the underlying programming language and no programming skill is required to use the system.
In one embodiment of the invention, the user has access to a simplified and restricted version of the full Conditional Constraint construction mechanism, in addition to his access to the full Conditional Constraint construction mechanism. These simplified versions are of two types:
1—The user is presented with structured and indexed lists of frequently occurring forms of Conditional Constraints, each form having only a few variable parts to be specified. For instance, the user is presented with the form:
The system will automatically turn this form into a Conditional Constraint once the user specifies values for the Employee Class and the integer N.
2—The user is presented with the Conditional Constraint composition screen, but with certain ‘advanced’ features unavailable. Such advanced features that may be unavailable include the ‘N As A Group’ construct for employees, and parts B and D of the Duration Specifier (see below).
Each Conditional Constraint contains an optional ‘If’ part and a required ‘Then’ part. Whenever a schedule satisfies the conditions in the ‘If’ part of the constraint it must also satisfy all the conditions in the ‘Then’ part. The ‘If’ part of a constraint may be empty; in that case, the ‘Then’ part of the constraint must be satisfied by the schedule unconditionally.
The ‘If’ part of a Conditional Constraint consists of an unlimited number of clauses. For the ‘If’ part of a Conditional Constraint to be satisfied by a schedule, all these clauses must be simultaneously satisfied by the schedule. The ‘Then’ part of a Conditional Constraint consists of a single clause.
In some embodiments of the invention, the Conditional Constraint language may be extended to permit clauses to be connected with an ‘or’ connective as well as an ‘and’ connective, and also to permit the ‘Then’ part of a constraint to contain an arbitrary number of clauses.
A clause describes a class of employees and a temporally structured pattern of times and/or shifts, and asserts that some or all of the described employees work (or don't work) within the described temporal pattern. Therefore, each clause has two principal components—an Employee Pattern and a Time Pattern. A third component of the clause, the connective, bridges the Employee Pattern and the Time Pattern.
Tools for constructing and manipulating Conditional Constraints include:
The Employee Pattern of a clause has two parts.
The first part of the Employee Pattern, the ‘Employee Class’ describes the set of employees to which the clause refers. The Absolute Employee Class Specifier of a clause may designate a class of employees without reference to the employee class of a preceding clause in the same constraint—an Absolute Absolute Employee Class Specifier—or in relation to the employee class of a preceding clause in the same constraint—a Relative Absolute Employee Class Specifier. If a clause is the first clause in a constraint, it can contain only an Absolute Absolute Employee Class Specifier.
An Absolute Absolute Employee Class Specifier for a clause designates a class of employees using the same mechanisms as in the description of the employee class of a Time Limits Constraint above; thus a class of employees may be designated by listing its members, by restricting membership to employees who have certain attribute values, or by importing a previously defined employee class.
A ‘Relative Absolute Employee Class Specifier’ designates a class of employees for a clause in relation to the employee class of an earlier clause of the constraint. For example, if the preceding clause says:
A Relative Employee Class is created by choosing a preceding clause in the same constraint so as to select the employee class that is being referred to, and selecting one of:
In the example above, the classes of employees defined by these selections are:
In constructing a Relative Employee Class, the user has the option of selecting which of the preceding clauses in the constraint is being referred to. The default selection is the nearest preceding clause using (containing?) an Absolute Employee Specifier. The user has a similar option for the other Relative Class constructions described below.
The second part of the Employee Pattern describes the pattern of use of the employees in the employee class. This second part is created by choosing one of:
If this option is chosen, the clause applies individually to every employee in the employee class. The clause is satisfied only if the condition on employee assignments specified by the remainder of the clause is satisfied by each employee in the employee class.
If this option is chosen, the user specifies at least one of a minimum and maximum value of an integer range. The clause is satisfied only if the number of employees in the employee class of the clause that satisfies the condition on employee assignments specified by the remainder of the clause is in the specified range.
If this option is chosen, the user specifies at least one of a minimum and maximum value of an integer range. The clause is satisfied only if the total number of employees in the employee class working throughout the time specified by the clause's Time Pattern is in the specified range.
A clause with this option imposes no further requirements on the employees working at any instant and, in particular, does not require that the same employees work throughout the time specified, nor that the same group of employees work together throughout.
If this option is chosen, a total of N employees from the employee class is selected. The clause is satisfied only if the times that those N employees are all working satisfies the condition on work assignments specified by the remainder of the clause. The user specifies the value of N.
For example, if the employee class is ‘doctors’ and remainder of the clause is ‘works three Saturdays in March’ then the clause constructed with each of the above choices is
For options 2, 3, and 4 above, whether or not the clause is satisfied will depend on which employees are chosen, and the group of employees chosen may be referenced by subsequent relative employee specifiers in the constraint. In effect, Conditional Constraints with such variable parts in one or more of their clauses, create a family of constraints, one for each way of assigning objects to the variable parts that satisfies all the clauses in the ‘If’ part of the constraint.
To indicate the connective of a clause, the user chooses either:
The Time Pattern of a clause describes a pattern of times and shifts, and slots that the employees described by the Employee Pattern must or must not be assigned to work to satisfy the clause. The Time Pattern has four parts: a Calendar Class, a Shift Class, a Slot Class and a Duration. The Duration describes a temporal pattern to be worked. The Calendar Class, Shift Class and Slot Class describe which calendar days, shifts and slots are counted within the temporal pattern specified.
The Calendar Class gives the user a filtering mechanism to describe which calendar days occur within the time specified. The Calendar Class can be described by either an Absolute Calendar Class Specifier or a Relative Calendar Class Specifier.
An Absolute Calendar Class is specified either by selecting a previously defined Calendar Class or by selecting any number of calendars. If this latter option is chosen, the user specifies whether the Calendar Class is the union or intersection of the selected calendars. The default Calendar Class is the ‘every day’ calendar.
A Relative Calendar Class is specified by selecting a preceding reference clause in the constraint and specifying whether the Calendar Class of the present clause is
For example, if the reference clause is
The Shift Pattern describes the class of shifts to which the clause refers, and how those shifts are combined. The first part of the Shift Pattern, the Shift Class is either an Absolute Shift Class or a Relative Shift Class. An Absolute Shift Class is defined either by selecting a pre-defined Shift Class, by choosing shifts from a list, or by selecting shifts according to their attribute values.
A Relative Shift Class is specified by selecting a preceding reference clause and selecting one of:
The second part of the Shift Pattern describes how the members of the Shift Class determine whether a clause is satisfied. This part is selected from:
If this option is chosen, the user enters at least one of a minimum and maximum value defining an integer range. A set of N members of the Shift Set is selected. The clause is satisfied if the number of shifts in the Shift Class that satisfy the condition on shifts defined by the remaining parts of the clause is in the range.
If this option is chosen, the union of the members of the Shift Class is considered as a single shift. The clause is satisfied if it is satisfied by this single unified shift.
If this option is chosen, a set of N members of the Shift Class is selected. The union of these N shifts is then considered as a single shift. The clause is satisfied if it is satisfied by this single unified shift.
For example, if the rest of the clause says ‘Joe works . . . 5 days in March’ and the Shift Class is the morning evening and graveyard shift then the above choices correspond to the following clauses
The Duration of a clause describes a pattern of times to be worked. A pattern of time consists of one or more specified intervals of time. A Duration may be either absolute or relative. An Absolute Duration is a duration that does not refer to the duration of a preceding clause. A Relative Duration is a Duration that refers to the duration of a preceding clause.
An Absolute Duration has three parts, a Fine Pattern, a Large Pattern, and an optional Date Range. The Fine Pattern is a finely detailed amount and pattern of time. The Large Pattern is a coarser pattern within which the Fine Pattern is distributed.
For example, an Absolute Duration might describe, ‘four consecutive days in each of three consecutive months.’ In this example, the Fine Pattern is ‘four consecutive days’ and the Large Pattern is ‘each of three consecutive months.’
The Date Range limits the Duration to the interval between a start and End Date.
For the Quantifier List, ‘Each’ is the default value.
For the Order List ‘All’ is the default value.
The selections on the Object List specify the size of the time pattern. The selections are:
The default choice for the Object List of Part A is ‘Instances’.
The Large Pattern of a Duration is a larger time pattern within which the Fine Pattern is distributed. A Large Pattern is created by making a selection from each of three lists, the Quantifier List, the Order List and the Object List. (These lists are distinct from the lists for the Fine Pattern, above.)
The default choice for the Quantifier List of the Large Pattern is ‘Anytime’.
The Order List of the Large Pattern restricts the possible choices of objects. The options on the Order List are:
For the Order List ‘All’ is the default value.
The options on the Object List of the Large Pattern, specify the size of the time pattern used. The options are the same as for the Object List of the Fine Pattern, except that the option ‘Instances’ is omitted and the option ‘Years’ is added. Thus, the options are
The default choice for the Object List for the Large Pattern ‘Days’.
The Date Range of the duration specifies the range of dates from which intervals making up the Fine Pattern can be chosen. If no start/End Date is selected, the default dates are the start/End Dates of the constraint, if they exist. Otherwise, the default dates are the start/End Dates of the scheduling problem.
Durations can be absolute or relative. An Absolute Duration specifies a temporal pattern without reference to durations in earlier clauses. A Relative Duration specifies a pattern of intervals that stand in a specified relationship to the duration of a preceding clause. Examples of Absolute Durations are ‘one shift on each of two consecutive days’ and ‘every day from March 10 to March 17.’ Examples of Relative Durations are ‘the next rotation’ and ‘the first Tuesday in the next month.’
If a clause is a second or later clause in a constraint, the duration specified of that clause can be relative or absolute. Thus, the user has available all the means for constructing an absolute Fine Pattern as well as means for constructing Relative Fine Patterns. Similarly the user has available all the means for constructing absolute Large Patterns, as well as means for constructing Relative Large Patterns.
The Date Range of a Relative Duration has one additional option, ‘same date range as reference duration.’
Relative Fine Pattern
To describe a Relative Fine Pattern, the user selects a preceding reference clause and one item from each of: The First Quantifier List; The Relation List; The First Object List; The Second Quantifier List; and The Second Object List.
The meaning of these five parts and how they together specify a Relative Fine Pattern of time intervals is explained in reverse order below. In outline, the selections made from the Second Quantifier list and the Second Object list are used to construct a pattern of time intervals by referring to the intervals comprising the fine pattern of the reference clause. The Second Quantifier list describes the number and arrangement of time units in this pattern and the Second Object list describes the size of the time units. Together, the choices from these two lists create a set of intervals ‘R’, the ‘Reference Set.’
The choices from the first three lists—the First Quantifier List, the Relation List and the First Object List—specify the Relative Fine Pattern as a set of intervals or instances that stand in a specified temporal relation to the members of the set R.
Suppose that the Fine Pattern of the reference clause is a set ‘S’ of instances or time intervals. This set S can be described as a set of time units of any of several sizes. That is, it can be re-described as a set S*—a set of hours, or a set of instances, or a set of days, weeks, months or years—where an hour, a day, week, month, or year is included in S* if any part of S occurs within that hour, day, week, month, or year.
The entries for the Second Object List, correspond to these ways of re-describing the set S. They are (1) ‘Instances’; (2)‘Hours’; (3) ‘Days’; (4) ‘Weeks’; (5) ‘Months’; (6)‘Years’.
The entries in the Second Quantifier List specify the reference set R as a subset of S*. They are:
The user's choices from the first three lists for defining a Fine Pattern, combined with the reference set R, construct the Relative Fine Pattern.
This construction occurs in two stages. First, the choices from the Relation List and the First Object List create a set, ‘E’, the set of objects initially eligible for inclusion in the Relative Fine Pattern. The size of the time units in E is specified by the choice from the First Object List, and membership in E is determined by R and the choice from the Relation List.
Lastly, the members of E included in the Relative Fine Pattern, are specified by the choice from the First Quantifier List.
The entries in the First Object List, specify the size of the time intervals in the set E. The options on the First Object List are:
The options on the Relation List define the set E by specifying time intervals in E by their temporal relationship to the members of the Reference Set, R. The options on the Relation List are:
‘Anytime’ is the default selection for the First Quantifier List.
Relative Large Pattern
The mechanism used to construct relative large time patterns, is almost identical to the mechanism used to construct relative small time patterns. A reference set, R, is derived from the large time pattern of a preceding clause, then a set E of intervals bearing a temporal relation to members of R, and the Relative Large Pattern is selected from E.
The only differences between the construction of a Relative Fine Pattern and a Relative Large Pattern are:
There are three kinds of scheduling preferences:
Preferences of all three types can potentially conflict with one another, and the system provides a mechanism for resolving these conflicts. In one embodiment of the system, all three kinds of preferences associated with a scheduling problem are maintained on a single list which can be reordered by the user. When two Preference Constraints conflict, for an assignment, the Preference Constraint higher on the list is used and the Preference Constraint lower on the list is ignored for that assignment.
To express an Optimization Preference the user can specify (step 110):
The user defined ‘Objective Function’ of an optimization preference is an algebraic combination of one or more integer or numerical employee attributes. The objective function can be as simple as a single numerical attribute.
The meaning of an optimization preference is that the value of the Objective Function associated with each employee, summed over assignments for members of the Employee Class occurring within the Shift Class, Slot Class and Calendar Class should be minimized or maximized by the automatic scheduling algorithm. For example, an optimization preference can direct the automatic scheduling algorithm to seek a scheduling solution that minimizes the total payroll cost of a class of employees or that maximizes the sum of years of employee experience.
Some employees may not have values for the Objective Function because they are missing values for one or more of the attributes employed in the definition of the objective function. If ‘Avoid Missing Values’ is selected, the automatic scheduling algorithm will attempt to minimize the assignments of those employees. If ‘Prefer Missing Values’ is selected, the algorithm will attempt to maximize the assignments of these employees. For example, a factory may have some employees who are paid a fixed wage and other employees who are paid an hourly wage. If the employer sets up an optimization preference to minimize his payroll costs, they system will preferentially assign employees with lower hourly wage rates. The employees paid a fixed wage do not have an hourly wage. By choosing ‘avoid’ or ‘prefer’ missing value, the user tells the system whether to try to maximize or minimize the assignment of employees with a fixed salary.
To express a Preferred Employees Constraint, the user specifies:
A Preferred Employees Constraint directs the automatic scheduling algorithm to prefer employees in the Employee Class to other employees for assignments within each of the Calendar Class, the Shift Class, and the Slot Class, and that within the Employee Class, preference for these assignments should be made according to the Preference Ordering.
Employee Specified Preferences
To express an Employee Specified Preference the user specifies:
An Employee Specified Preference directs the automatic scheduling algorithm to minimize or maximize the assignments within each of the Calendar Class, Shift Class and Slot Class for a single employee. In some embodiments of the system, employees will be able to enter Employee Specified Preferences directly, whereas more global constraints will be entered by the employer or system administrator.
To express a Regularity Constraint, the user specifies:
The meaning of a Regularity Constraint is that, to the extent possible, each employee in the Employee Class should have a ‘regular’ or highly repetitive schedule of assignments within the Shift Class, Slot Class and Calendar Class. Whenever the automatic scheduling algorithm assigns an employee in the Employee Class to a qualifying slot-instance, the algorithm attempts to repeat this assignment for any unassigned instances of the same slot in the same shift and within the Calendar Class.
In other embodiments of the program, the expressive power of constraints is enlarged by permitting variable attribute values allowing attribute values across different types of objects, and across clauses in Conditional Constraints, to be matched and compared. For example, this feature permits creation of clauses like:
‘No employee with security-clearance less than value x works in a slot with slot-security clearance value greater than or equal to x.’
Creation and Modification of Schedules
One embodiment of the invention has a facility for creating and storing scheduling problems and partial and complete solutions to scheduling problems. The system allows users to create, rename and delete scheduling problems. Users may save partially or completely solved scheduling problems and move from one problem to another, so that a user can work on more than one scheduling problem.
To create a scheduling problem the user specifies:
Once a scheduling problem has been set up, the user may create new constraints and preferences or associate already created constraints and preferences with the problem.
Once a user has specified a scheduling problem, a class of slot-instances is created. A slot-instance is a request for one employee to work during a shift on a given date. Whenever a shift in the shift database for a scheduling problem occurs on a date in the calendar database for that scheduling problem, slot-instances are created for every slot associated with the shift which is also in the slot database for the scheduling problem. If the multiplicity of the slot is an integer N, N slot-instances are created for that shift, slot and date, signifying a request for n employees. If the multiplicity of the slot is a demand function F, N slot-instances are created, where N is the maximal value of F over all the days in the calendar database and in the rotation of the shift containing the date. (Because assignments take place one rotation at a time, if M employees are needed for the slot on one day in the rotation, M employees will be assigned throughout the rotation. This set of slot-instances over the course of a rotation is known as a rotation-instance.)
Solving a scheduling problem (step 132) consists of assigning an employee to each of these slot-instances in a way consistent with all the constraints, Time Limits and other restrictions inherent in the problem. Such an assignment of an employee to every slot-instance in the problem is a ‘complete schedule’ or a ‘complete solution’ to the scheduling problem.
However, at various stages in solving a scheduling problem, only some of the slot-instances may have an assigned employee. These states of partial assignment are ‘partial schedules’ or ‘partial solutions’ to the scheduling problem (202, see
The state of the problem just after it has been set up, with no employee assigned to any slot-instance, is an ‘empty schedule’ or ‘empty schedule problem solution.’ In order to create a complete solution 142 to the scheduling problem, the user begins with an empty schedule and repeatedly modifies and builds partial schedules.
Two auxiliary functions—Verify 138 and Lock/Unlock are available to the user to assist him in this process.
At any point during the process of constructing a schedule solution the user can check whether the current partial or complete solution violates any active constraints, Time Limits, employee availability requirements and slot requirements. In general, constraint violations occur only after manual modification of schedule solutions, since the automatic scheduling algorithm rejects assignments that violate constraints or other conditions on the problem. Given a schedule solution, the verify function provides a list of all violations of every active constraint, Time Limit, employee availability requirement and slot requirement.
Each assignment of an employee to a slot-instance in a schedule solution can exist in one of two states, ‘Locked’ or ‘Unlocked’. If an assignment is locked, the automatic scheduling algorithm will not backtrack over that assignment as it searches for a complete schedule solution, unless explicitly instructed to do so. Attempts to manually modify the schedule that would change a locked assignment will cause a warning to appear. To manually modify a locked assignment, the user must take explicit action to override the lock.
There are two ways to change the Locked/Unlocked status of assignments:
1—Using any schedule display format (see below), the user may graphically select one or more assignments and lock or unlock all the selected assignments.
2—The user may select a class of employees, a class of shifts, a class of slots, a Calendar Class and a date range and lock or unlock all assignments for those employees to slot-instances within the Shift Class, Slot Class, and Calendar Class.
The locked/unlocked status of each assignment is displayed with a graphical icon in each schedule display format.
There are two ways to modify schedules, manually and automatically.
Manual Schedule Modification (Step 142)
Using any schedule display format, the user may select any slot-instance in the problem and view the list of employees who are available and qualified to fill that slot-instance, as well as lists of employees available but not qualified for that slot-instance, qualified but not available, and neither qualified nor available. The user can remove an assigned employee from a slot-instance, replace one employee with another, or assign an employee to an empty slot. Whenever the assignment of a slot-instance is modified, the user has the option to extend that modification to a larger class of slot-instances. To do so, he makes a choice from two lists of options. The first list is:
The second list further specifies the set of slot-instances receiving the modified assignment. The options on the second list are:
The user is also warned whenever one of his manual assignments violates an active Constraint or Time Limit.
Automatic Schedule Modification
At any point after a scheduling problem has been specified, the user can deploy the system's automatic scheduling algorithm to go from an empty schedule solution or partial schedule solution to a complete schedule solution 142. For example, the user can manually enter the schedule assignments for a specific day or week, or the assignments for a specific employee or group of employees, and direct the scheduling algorithm to generate a complete schedule that includes his manual entries.
The user can also require that a schedule solution be consistent with a temporally preceding schedule solution or attendance record for some or all of the same employees, shifts and slots. For example, if a Time Limit requires that no nurse work more than 3 Saturdays in any two months, and nurse J has actually worked 2 Saturdays in February, this feature would insure that nurse J was assigned no more than 1 Saturday in March.
If applied to a scheduling problem with an empty schedule, the automatic scheduling algorithm will search for and, if possible, generate a complete schedule consistent with the problem's constraints. If no such schedule exists—because of conflicts among the problem's constraints and requirements—the algorithm will produce as nearly complete a partial schedule as possible and indicate why the schedule cannot be completed.
If the automatic scheduling algorithm is applied to a scheduling problem with a partial schedule, the algorithm will search for and, if possible, generate a complete schedule that contains all the locked assignments in the partial schedule.
Parameters for the Automatic Scheduling Algorithm
Prior to starting the automatic scheduling algorithm, the user enters several parameters that further describe the problem to be solved. These parameters are:
In one embodiment of the invention, if the search depth is the integer n, the search for a schedule solution is limited by permitting only N failed attempts at assigning an employee to a rotation-instance before backtracking to an earlier assignment, thereby limiting the breadth of the algorithm's search tree. In another embodiment of the program, if the search depth is the integer N, the algorithm will backtrack over only N assignments before declaring a rotation-instance ‘unfillable’ and moving on to the remaining unassigned rotation-instances. Combinations of these two strategies can also be used. If the search depth is ‘unlimited,’ there is no restriction on the search.
In alternative embodiments of the invention, the search depth is variable, not a constant, and depends on the number of employees eligible and available for a rotation-instance, the point in the search at which the rotation-instance is encountered, the amount of time used thus far by the algorithm, and other factors.
The default value of the ‘Fill optional slots’ parameter is ‘Fill no optional slots.’
Automatic Scheduling Algorithm
The pre-processing phase of the automatic scheduling algorithm is a preliminary phase in which data structures that facilitate the search phase of the algorithm are set up, and certain immediately apparent assignments and/or inconsistencies are detected. The assignments made during the pre-processing phase of the algorithm are those assignments that are not the result of any arbitrary choices in making assignments and which, therefore, must be present in any acceptable schedule solution. Because these assignments must be present, no backtracking over assignments is necessary or possible in the pre-processing phase of the algorithm. The pre-processing phase consists of the following steps:
Using the algorithm parameters to calculate the set of slot-instances (steps 212-214). This set consists of one or more slot-instances for each slot in the Slot Class parameter associated with a shift in the Shift Class parameter, for each date between the Start Date parameter and the End Date parameter, and in the calendar parameter, and on which the shift occurs. The number of slot-instances generated by a slot on a date is the maximum value of the multiplicity of that slot over the days in the rotation of the shift containing the slot in which the date occurs.
Calculating and associating to each slot-instance a slot list—the list (step 216) of those employees available throughout the duration of the shift associated with the slot-instance on each date on which the rotation containing the slot-instance occurs, and contained in the class of employees acceptable for assignment to the slot associated with the slot-instance, thereby creating a list of those individuals both available and acceptable for assignment throughout the rotation-instance containing the slot-instance.
For each active constraint and preference, calculating the actual values of employee classes, Calendar Classes, Shift Classes, and Slot Classes in each active constraint, resulting from the values of the algorithm parameters. This step may discover that some active constraints either have no effect or cannot be satisfied. For instance, if there are no nurses in the employee parameter, the constraint
‘If a nurse works the dayshift, a doctor works the same shift’
For each Conditional Constraint without an antecedent, with a consequent clause with a ‘doesn't work’ connective, and without variable parts, removing employees in the employee class of the clause from the slot list of every slot-instance within a rotation-instance intersecting the time pattern of the clause.
After this step, this class of constraints is ignored for the remainder of the scheduling algorithm.
For each slot-instance for which the associated slot list contains a single employee, and for each slot-instance already assigned an individual by the choice of parameter 3 above, designating that employee as assigned to the slot-instance. If any of these assignment designations fails at steps (a) or (b) below, the algorithm halts and reports the failure to the user.
When an employee is assigned to a slot-instance either at this step, or at later steps in the algorithm, the following actions take place:
For each Conditional Constraint without an antecedent, with a consequent clause with a ‘works’ connective, and without variable parts, assigning every employee in the employee class of the clause to slot-instances throughout the time pattern of the clause (step 230).
After this step, this class of constraints is ignored for the remainder of the scheduling algorithm.
Clauses containing an ‘equal’ operator are rewritten as a pair of clauses with <=and >=n place of =. So, for example, a clause containing the expression ‘N=5’
Clauses in all active constraints are rewritten to remove double negations. A clause can be made negative in several ways—either by choosing ‘doesn't work’ as the connective, or by an occurrence of a ‘less than’ or ‘less than or equal’ numerical operator within the clause. Thus,
The algorithm replaces the original doubly negated clause with this positive equivalent. Where there are more than two negations in a clause, the same procedure is repeatedly used to replace it with an equivalent clause with either no negations or one negation.
These rewritten constraints, with extra negations removed from their clauses, are not visible to the user of the program.
Contrapositive Generation (Step 214)
The algorithm next enlarges the set of active Conditional Constraints. For each active Conditional Constraint with a non-empty antecedent, the algorithm calculates a set of new constraints, called the ‘contrapositive’ of the original constraint, and adds these new constraints to the list of active constraints. Each set of contrapositive constraints is logically equivalent to the constraint it is derived from and, therefore, imposes no further restriction on acceptable schedule solutions. However adding contrapositive constraints speeds up the search procedure by causing early pruning of branches of the search tree that cannot lead to scheduling solutions. Contrapositive constraints are not visible to the user of the program.
Obviously, any schedule solution which satisfies the first of these constraints also satisfies the second, and vice versa, so adding the contrapositive to the list of active constraints does not eliminate any candidate schedule solutions. However, the effect of the contrapositive constraint is to cause Joe to be removed from the candidates for assignment to the slot-instances on a Tuesday as soon as Al has been assigned to a slot-instance on the next day. The prompt removal of these potential assignments, which would ultimately lead to failure if they were tried, speeds up the search procedure.
If the Employee Pattern in C requires that N or more employees individually work a pattern of assignments, the Employee Pattern in Not C will require that fewer than N employees work the same pattern of assignments. In case the Employee Pattern requires that between N and P employees, with P>N, individually work some pattern of assignments, Not C will be expressed by two clauses, one requiring that more than P employees work the pattern, and one requiring that fewer than N employees work the pattern. ‘Not C’ is satisfied if either of these two clauses are satisfied. The two clauses generate two distinct contrapositives, with one of the two clauses standing in place of ‘Not C’ in each of the two contrapositives.
If the Employee Pattern in C requires that N total employees work some pattern of assignments, the Employee Pattern in Not C and a modified Duration Specifier in Not C will require that fewer than N employees work at some point in the same time and shift pattern.
If the Employee Pattern in C requires that N employees as a group work a pattern of assignments, Not C will state that no N employees as a group work that pattern.
Not all Unconditional Constraints are used to generate contrapositives, since the Unconditional Constraints without variable part are used and removed at an earlier pre-processing step. An Unconditional Constraint generates a contrapositive only if its consequent clause contains a variable part. For example, the unconditional negative constraint ‘no doctor works the night shift’ has no variable part. But ‘some doctor does not work the night shift’ does have a variable part. It is satisfied by choosing a doctor—who will not work the night shift—from among the set of doctors. Similarly, satisfying ‘Joe works the morning shift some day in January’ requires choosing from among the days in January.
The Search Phase (Steps 218-254)
If, at the end of the pre-processing phase, there are either unfilled required slot-instances, unsatisfied Time Limit minima, or unfilled optional slot-instances within the ‘fill optional slot’ parameter class, the algorithm moves to the search phase to complete the schedule. During the search phase, repeated choices of employees and slot-instances are made in order to generate new assignments. Because these choices are, in general, underdetermined by the available data, arbitrary choices must be made at some points in the search procedure.
Choices are required at 2 points in the algorithm:
For example, to satisfy the constraint
To satisfy the constraint
After making one or more assignments, the algorithm may discover that a contradiction has been reached and that no acceptable scheduling solution containing the current assignments is possible. In this case, the algorithm must backtrack, removing one or more of the current assignments and trying a different employee or slot-instance. In one embodiment of the program, this backtracking takes place by replacing the most recently made assignment (chronological backtracking). In other embodiments of the program, the assignment to be replaced is determined in another way, for example, by replacing the assignment that led to the largest number of contradictions, or that caused the largest number of employees to be deleted from a slot list that ultimately became empty (dependency based backtracking).
If the algorithm needs to backtrack from an assignment but no such further backtracking is possible (because all ‘earlier’ rotation-instances are unfillable) the algorithm adds the rotation-instance under consideration to the list of unfillable rotation-instances and removes it from the list of unassigned rotation-instances. The algorithm then selects another unassigned rotation-instance to fill.
Whenever any assignment is made during the processing phase, that assignment is placed on a list of new assignments and this list of new assignments is checked against the active Time Limits, Conditional Constraints, and Regularity Constraints to see what further facts about acceptable schedules can be drawn from the presence of the new assignments. This checking process may itself produce new assignments and these further assignments are themselves checked against the active Time Limits, Conditional Constraints and Regularity Constraints. This subroutine (constraint propagation) continues until no further assignments are generated.
The processing phase of the scheduling algorithm comprises five steps:
Drawing further consequences from the assignments made during the pre-processing phase. This step comprises two substeps:
Since more than one such group of assignments may be possible, the scheduling algorithm may backtrack to this group of assignments and replace it with another group of assignments that meets the Time Limit
Making assignments as needed to satisfy any Unconditional Constraints with variable parts (steps 228-238).
Repeatedly selecting (step 242) a rotation-instance and assigning an eligible employee to that rotation-instance. This set of assignments, and every assignment made during the processing phase, is first checked for violation of a Time Limit maximum. If such a violation is found, the assignment fails and backtracking takes place. Next, the CR-loop is run with these new assignments as input. If the CR loop fails, backtracking takes place. This process is repeated until either every required slot-instance has either been assigned an employee or found to be unfillable.
This procedure requires repeatedly choosing an unfilled rotation-instance. In one embodiment of the invention, the unassigned rotation-instance with the smallest number of eligible employees is chosen, with ties among rotation-instances being broken in chronological order.
This procedure also requires repeatedly choosing an employee from among the eligible employees for a rotation-instance. In one embodiment of the invention, the employee chosen is that employee who has not yet been tried for assignment to the rotation-instance, and who is in first place on the largest number of the slot-lists of the slot-instances comprising the rotation-instance. Ties among employees are broken by looking at successively lower places on the slot-lists. In other embodiments of the program other criteria for the selection of employees may be substituted or combined with this method of ranking. These other criteria may include the total number of assignments for an employee thus far and the proximity to meeting or violating various Time Limits for individuals.
If there are still Time Limits with a violated minimum value, repeatedly selecting unfilled rotation-instances (steps 248, 250) that increase the number of assignments that count for one or more of these Time Limits, assigning an eligible employee to the rotation-instance, applying the CR loop with these assignments as input, and backtracking if the CR loop fails, until either no such Time Limits remain or no such unfilled rotation-instances remain.
If there are still Time Limits with violated minimum values after this step, these violations are reported to the user when the schedule is displayed. If there are still unfilled optional slot-instances within the ‘fill optional slot’ class parameter, repeatedly selecting unfilled optional rotation-instances containing such an unfilled slot-instance, assigning an eligible employee to the rotation instance, and applying the CR loop with these assignments as input, until no unfilled optional slot-instances within the ‘fill optional slot’ class parameter remain. In one embodiment of the program, this sequence of assignments is made without backtracking—if an assignment causes an inconsistency, the slot-instance of that assignment is simply left unfilled.
When the processing phase is completed, algorithm halts and a display screen shows the employee assignments for all assigned slot-instances and the unassigned slot-instances, if any.
In carrying out the above steps, the algorithm repeatedly calls a subroutine called the ‘Constraint and Regularity Loop (CR-Loop) (244).’
The Constraint and Regularity Loop subroutine is illustrated in
When passed a list of new assignments as input (step 302), this list becomes the initial value of an internal queue maintained by the CR-Loop. The CR-Loop tests each of the assignments on the queue against all the Conditional Constraints (by calling the ‘Constraint Propagation’ subroutine 304), and then tests each input assignment against all the Regularity Constraints (by calling the ‘Regularity Propagation’ subroutine 312). Each of these two subroutines may generate new assignments, which are added to the end of the queue (steps 308,314). The CR-Loop processes the assignments on the queue until it is empty (step 318).
The Constraint Propagation subroutine (described in more detail below) compares a single input assignment with the active Conditional Constraints, and makes all possible inferences based on the constraints and the input assignment, detecting constraint violations, and possibly making new assignments or removing employees from slot lists. Whenever new assignments are produced, they are added to the queue of the CR-loop (steps 308, 314).
The Regularity Propagation subroutine 312 compares its input assignment with all active Regularity Constraints. Whenever a Regularity Constraint applies to the input assignment, the employee in the input assignment is assigned to every unfilled rotation-instance specified by the Regularity Preference, for which the employee is eligible and which does not violate a Time Limit maximum. These new assignments are placed on the queue of assignments for the CR-Loop.
The Constraint Propagation subroutine is illustrated in
Constraint Propagation is a subroutine of the CR-Loop. Whenever one or more employees are assigned, the algorithm repeatedly calls the Constraint Propagation subroutine 304, successively passing it each of the new assignments.
The Constraint Propagation subroutine 304 compares its input assignment with the antecedent clauses of each Conditional Constraint in every possible way (steps 406-416). Whenever all the antecedent clauses in an Conditional Constraint are satisfied by an instantiation of the variable parts of the antecedent clauses that involves the new assignment in some way, action is taken to satisfy the consequent part of the constraint, if possible.
If, in this process, a Conditional Constraint either cannot be satisfied or leads to an immediate contradiction, that constraint fails (steps 418 and 422). If a strong Conditional Constraint fails, the constraint propagation subroutine fails and the input assignment is withdrawn, as are any already calculated consequences of the input assignment. If a weak Conditional Constraint fails, the immediate effects of that constraint are withdrawn, but the input assignment is not withdrawn.
Constraints with a positive ‘then’ clause are violated when the ‘If’ part of the constraint is satisfied, but no assignment can satisfy the ‘Then’ part of the constraint (step 418). For example, if the input assignment assigns Joe to a slot-instance on a Tuesday, the Conditional Constraint
If such a constraint does not fail, it causes a new assignment. For example, if the input assignment assigns Joe to a slot-instance on a Tuesday, the above Conditional Constraint will cause a new assignment, assigning Al to a slot-instance on the same day as the input assignment.
If new assignments are made, they are immediately extended and checked according to the procedure at step 5 of the pre-processing phase. If these steps fail, the constraint that caused the assignments fails. Otherwise, the new assignments are placed on the queue of assignments for the CR-Loop.
Employees are removed from slot lists by constraints with negative ‘then’ clauses. For instance, if the input assignment assigns Joe to a slot-instance on a Tuesday, the Conditional Constraint
If employees are removed from slot lists, and any slot list becomes empty, the constraint that caused the slot list to become empty fails. Also, if employees are removed from slot lists, Time Limits involving these slot lists are checked to see if any Time Limit minima become unsatisfiable, and for minimum exact matches. If one or more minima become unsatisfiable, the constraint that caused this fails. If the slot list of a slot-instance contains only one employee as a result of removing employees from that slot list, the remaining employee is assigned to that slot-instance, and that assignment is checked and placed on the queue. If an exact match is detected between a Time Limit minimum and the resources necessary to satisfy that minimum, assignments satisfying the exact match are made, if possible, and placed on the queue. If no such assignments are possible, the constraint causing the exact match fails.
The description of Constraint Propagation given above depends on the notion of a clause being satisfied by a partial schedule. How a clause is satisfied depends on whether the clause is positive or negative.
Satisfaction for positive clauses is straightforward. A partial schedule P satisfies positive antecedent clause, C, for a given instantiation of the variable terms in C, if C is true in P with these instantiations.
For example, the clause
Similarly, if either of these two clauses occurs as the consequent clause in a constraint, the algorithm adds assignments to P in order to satisfy the clause using the same criteria, e.g., if Joe is not already working 2 or more days in the week of March 10 to March 17, the algorithm creates extra assignments to make sure that Joe does work at least 2 days in the week.
Satisfaction of negative clauses by partial schedules is more subtle. Simply to say that a negative clause is satisfied by a partial schedule P if the condition expressed by the clause is true in P would not work. For example, the negative clause
In the actual program, this hard to calculate criterion for satisfaction is replaced by a simpler one—a negative clause is satisfied by a partial schedule P when it can be shown in some immediate and easily calculated way that the clause must be true in every schedule extending P. In one embodiment of the program, this is done by counting available resources. So for example, the negative clause C
Similarly, if a negative clause occurs in the consequent of a constraint, the same satisfaction criterion is used by the algorithm to make sure that the clause is satisfied. For example, to satisfy
If, as in this example, the satisfaction of a negative ‘Then’ clause involves making choices among employees or time periods, the number of such choices is restricted by the search depth parameter, and these choices may be revisited by backtracking.
To test the Conditional Constraints against a new assignment in every possible way, each antecedent clause in each active Conditional Constraint is successively tested against the new assignment (steps 416-424).
If a clause is positive, the assignment is examined to see whether the assigned employee and slot-instance fall within the Employee Pattern and time pattern of the clause respectively. If they do, any interpretations of the variable parts in the clause that are made in matching the assignment to the clause are carried over to the other clauses in the antecedent of the constraint. Then, if all the antecedent clauses can be satisfied, action is taken to satisfy the consequent of the constraint.
For example, suppose the assignment is of Joe, a doctor, to a slot-instance on Tuesday, March 25. In the constraint
If a clause is negative, all interpretations of the variable parts of the clause which make the corresponding positive clause impossible to satisfy are listed. Each of these interpretations is tested with the new assignment missing. Only those interpretations which make the clause impossible to satisfy with the new assignment included but not with the new assignment excluded are kept. Each of these interpretations is then carried to the other antecedent clauses, and then to the consequent clause.
For example, if the assignment is as above, in the constraint
After all Conditional Constraints and Time Limits have been tested against the input assignment, new assignments may have been made. If so, the Constraint Propagation subroutine places these new assignments on the queue of the CR-loop and then terminates.
Scheduling Diagnosis Functions
Whenever the automatic scheduling algorithm cannot completely solve a scheduling problem, the user has access to several diagnostic tools that help him find the cause of the scheduling failure.
On any schedule display format, the user can highlight any slot-instance or rotation-instance and view the associated slot-list of employees. After use of the automatic scheduling algorithm, the slot-list will be annotated to show which employees were tried in filling the slot, and why each of these tried employees were unable to fill the slot. If the slot-instance was assigned, the reason for the assignment—manual entry, assignment already in schedule, Time Limit, Regularity Constraint, Conditional Constraint, etc, will also be shown. In the case of Conditional Constraints and Regularity Constraints, the assignments that triggered the constraint will also be viewable.
For each Time Limit, the user can view a list of all employees who have reached a maximum value of the Time Limit and where in the schedule each maximum was reached. The user can also view all those employees who cannot reach a minimum value of the Time Limit and where the failure to reach the minimum occurred.
Any schedule display format can be filtered to show only unfillable slot-instances. The user can also view filled-slot-instances with either a numerical count or graphical representation of the number of trial assignments that were made before the slot was filled. Slot-instances or rotation-instances that required many trial assignments represent potential ‘bottlenecks’ in the scheduling problem that the user may need to modify in order to completely solve a scheduling problem.
For each active constraint, the user can view a count of the number of times that constraint caused backtracking, and a graphic display of the slot-instances where a given constraint caused backtracking. Constraints that cause frequent backtracking are most likely to be responsible for scheduling failures, and may need to be modified or made inactive in order to completely solve a scheduling problem.
Whenever a partial or complete schedule is displayed, the user has access to a display of all the input parameters of the Automatic Scheduling Algorithm that gave rise to that schedule.
Schedules and partial schedules can be displayed and modified using several formats—Grids, Lists, and Employee Calendar Displays. Each of these display formats supports a common set of features:
Grids show assignments in a rectangular array. There are two grid formats:
In the first Grid format, rows are labeled by employee names and columns by dates in the schedule. Within each cell of the array is a description of the corresponding employee's assignments for that date.
In the second Grid format, rows are labeled by shifts (and slots) and columns by dates in the schedule. Within each cell of the array is a description of the employee assignments for the given shifts and slots for that date.
Assignments can also be displayed in list format. Assignments can be listed either by day or by rotation. If assignments are listed by day, the days within the schedule interval are listed chronologically. For each day, all the assignments are displayed, showing the assigned employee, the shift, the slot, the starting and ending times, and the total number of hours worked.
If assignments are listed by rotation, assigned rotations are listed chronologically by starting date. Each rotation assignment display shows the assigned employee, the shift, the slot, the starting date and ending date of the rotation, the daily hours, the days comprising the rotation and the total number of hours and days in the rotation.
Employee Calendar Displays
Employee Calendar Displays show the schedule for a single employee or specified employee class in a format resembling a traditional wall calendar, and are suitable for printing and distribution to employees. The dates in the schedule range are graphically displayed in a monthly calendar format. Time intervals during which the selected employee or employees work are shown as colorable horizontal bands and are labeled with the shift and slot assignment. Statistical summaries of the number of days and hours worked per week are shown at the right side of the display.
There are two statistics display screens—‘Group Statistics’ and ‘Individual Statistics.’ The statistics screens display statistical summaries of any partial or complete schedule solution. The statistics screens can be configured and printed so as to produce standard reports.
Statistics are displayed in a rectangular array. In the ‘Group Statistics’ screen, each row of the array is labeled by an Absolute Employee Class Specifier chosen by the user. Each column is labeled by Shift Class, Slot Class, and Calendar Class specifiers chosen by the user. Each cell of the array displays the amount of time worked by all members of the corresponding employee class during the corresponding shift, slot and Calendar Classes. Time can be displayed in units of minutes, hours, days, shifts, or rotations.
The total time for each employee class summed over all the specified classes is listed at the far right of each row and the total time for each shift, slot and Calendar Class summed over the specified employee classes is shown at the bottom of each column. If any employees or shifts are listed in more than one class, the totals are adjusted so as to avoid counting a shift or employee twice.
The accumulated values for cumulative numerical attributes summed over rows and columns can also be viewed at the right hand side of the rows or the bottom of the columns.
In the ‘Individual Statistics’ screen, rows are labeled by individual employees and columns by Shift Class, Slot Class and Calendar Class. Each cell of the array displays the amount of time worked by the corresponding employee within the corresponding Shift Class, Slot Class and Calendar Class.
A modified form of the statistics screens, showing scheduled statistics vs. the statistics of actual attendance, absences and substitutions is available in the Attendance Mode of the program (below). The entries for attendance, absence and substitution are further filterable by attribute ranges for the attributes attached to attendance, absences and substitutions.
The program has an additional operational state, the ‘Attendance Mode.’
In the Attendance Mode the user is able to keep track of the actual attendance of his employees. The Attendance Mode becomes available once a user has generated and ‘accepted’ a schedule. This schedule is fixed and archived and is used as the basis for the expected attendance.
In Attendance Mode, the user can record whether or not an employee is present for his scheduled assignments and, if present, enter the actual times that the employee starts and ends work. The program records and archives this actual attendance, displays it and calculates statistics based on it.
When an employee has either been declared absent for an assignment, marked late for an assignment, or if no assignment for a slot-instance has been made by the time the assignment begins, the program prompts the user for a substitute employee to fill the unfilled slot-instance and provides lists of available and qualified substitute employees so that the user may manually fill the slot-instance. Alternatively, the user may allow the scheduling algorithm to make one or more substitute assignments as necessary. In this case, the algorithm uses the actual attendance up to the present and the scheduled attendance form the present forward as a partial schedule to complete. Since actual attendance has already occurred, the algorithm will not backtrack over actual attendance.
If an employee's attributes include communication information such as a phone number or pager number, the program allows the user to automatically notify substitute employees of their new assignments.
The attendance statistics can be transferred to payroll, human resource management, personnel management or enterprise management software. In general any of the data or library entries can be exchanged between the system and other software databases, libraries and programs using the system's import and export features. The system can also be configured to take advantage of the information sharing capabilities of the internet.
While this invention has been particularly shown and described with references to preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the invention encompassed by the appended claims.