Configurable scheduling system

Abstract

A configurable scheduling method and apparatus for scheduling orders and worker according to a constraint set including a programmable constraint set and a fixed constraint set. The programmable constraint set programmed by a service organization to alter the schedule process from a normal process governed by the fixed constraint set to a reconfigured process also governed by the programmable constraint set.

Description

CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims the benefit of U.S. Provisional Applications 60/193,834, 60/193,917, 60/193,832, 60/193,705 and 60/193,833, each of which were filed Mar. 31, 2000, and each of which are incorporated herein by reference

TECHNICAL FIELD

[0002] The technical field relates generally to scheduling, and more particularly, to a system and method for a configurable scheduling system that is configurable by a service organization using the system.

COPYRIGHT NOTICE - PERMISSION

[0003] A portion of the disclosure of this patent document contains materials which are subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever. The following notice applies to the software and data as described below and in the drawings attached hereto: Copyright © 2001, MDSI Mobile Data Solutions Inc., All Rights Reserved.

BACKGROUND OF THE INVENTION

[0004] In many industries which employ a large mobile workforce, such as utilities, taxi companies, and large equipment repair services, the efficiency with which mobile workers can be scheduled and dispatched to customers can have a great impact on customer satisfaction as well as on a service provider's bottom line. From the customer satisfaction standpoint, it is not uncommon for a customer to call a cable television company, or other service provider, to request service only to be told to choose a four-hour service window on good days, or an “all day” service window on bad days. Even when the customer is “lucky” enough to request service on a “good” day, the worker dispatched by the service provider typically will arrive well after the window has closed, or the customer will have waited, and wasted, most of the day for what should typically only be a half-hour service call. This situation arises from an inability of the service provider to accurately predict when a particular worker will complete a given task and how long it will take for the worker to reach the next service location.

[0005] From the financial standpoint, inefficient scheduling and dispatching results in fewer service calls being performed each day, potentially resulting in lower earnings per worker-hour, as well as possible additional expenditures required for hiring and training additional workers. To improve scheduling and dispatching, many service providers have an automated or computerized scheduling system carry out these tasks. Conventional scheduling systems typically perform the scheduling and dispatching tasks through the use of various algorithms that account for many factors in assigning a mobile worker to service a customers work order, such as time availability, skill sets, geographic area, duration of each work order, travel time, and the like. Thus, using scheduling systems such as these allow for a service provider to more efficiently utilize their mobile workers in satisfying customer work orders.

[0006] Although scheduling systems have reduced the difficulty a service provider faces in scheduling and dispatching mobile workers, the systems and algorithms employed are generally difficult customize or reconfigure to the needs of a particular service organization. Although some conventional scheduling systems have incorporated some aspects of configurability by the service organization, the extent of configurability is usually limited to customizing the scheduling system by having the service organization select from a set of predefined scheduling rules. However, any additional configuration of the scheduling system by the service organization involves custom reprogramming of the algorithms themselves, which will require the reprogramming be performed the programmers of the scheduling system. Moreover, in the cases where additional modifications to the scheduling system are required by the service organization, additional reprogramming may be required. As one could imagine, having the algorithms reprogrammed for a custom configuration of the scheduling system can be costly and time consuming. The service organization is also subject to the time constraints of the programmers reprogramming the algorithms. That is, service organizations have no choice but to wait until programmers have time to work on their scheduling systems. For the service organization having limited financial resources, or where reprogramming of the algorithms cannot be completed within the desired timeframe, the service organization is left without any options but to suffer through the use of the existing scheduling system. Therefore, there is a need for a configurable scheduling system having greater flexibility in allowing a service organization using the system to configure the system.

SUMMARY OF THE INVENTION

[0007] The present invention relates to a user-configurable scheduling method and apparatus configurable by a service organization for scheduling orders and workers in accordance with a constraint set including a programmable constraint set and a fixed constraint set. The programmable constraint set alters the schedule process from a normal process governed by the fixed constraint set. The constraint set includes programmable rules and constants. The programmable rules may be programmed in accordance with a rule language convention having a first field containing rule identifier to uniquely identify the data structure, and a field containing a rule body including material for altering the schedule process from a standard process to a reconfigured process configured by the service organization.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] FIG. 1 is a block diagram of a system showing the relationship between a service organization, a scheduling system, mobile service representatives, and customers according to and embodiment of the present invention.

[0009] FIG. 2 is a block diagram showing the scheduling system according to an embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

[0010] In the following detailed description of exemplary embodiments of the invention, reference is made to the accompanying drawings, which form a part hereof, and in which are shown, by way of illustration, specific exemplary embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. Other embodiments may be utilized and structural, logical, electrical, and other changes may be made without departing from the spirit or scope of the present invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims. The present application incorporates by reference the following references:

[0011] Simon Jacobs, Enterprise Scheduling System (ESS) Function Specification, Rev. 4.1 (Jun. 30, 2000); and Simon Jacobs, Configurable WDS (CWDS), Rev. 2.1 (Aug. 1999).

[0012] FIG. 1 is a block diagram of a system 100 according to one aspect of the present invention. The system 100 includes a service organization 102. The service organization 102 performs services for a roster of customers. When a customer 108 is interested in having a service performed by the service organization 102, the customer 108 calls the service organization 102 to make a reservation for a service to be performed. Using the scheduling system 104, the service organization 102 negotiates with the customer 108 to place a reservation on a schedule. The scheduling system 104 provides to the service organization 102 several appointment windows from which the customer 108 may choose. The customer 108 selects an appointment window in which the service will be performed. During the negotiation, the scheduling system 104 makes preliminary assignment to one or more mobile service representatives 106. A mobile service representative 106 is one who is capable of performing the service requested by the customer 108. Each time a reservation is placed, the scheduling system 104 accounts for many factors in assigning the reservation to a mobile service representative 106, such as time availability, skill sets, geographic area, duration of each job, travel times between jobs, and equipment requirements. The scheduling system 104 can be implemented over one machine or several machines with different processors. This allows the scheduling system 104 to be scalable depending on the needs of the service organization 102. As will be discussed in more detail below, the scheduling system 104 is also configurable by the service organization, thus allowing the scheduling system 104 to meet different constraints and objectives as defined by the service organization.

[0013] FIG. 2 illustrates a scheduling system 200 according to an embodiment of the present invention. The scheduling system 200 is similar to the scheduling system 104 shown in FIG. 1 and can be substituted for the scheduling system 104. The scheduling system 200 performs a scheduling process. That is, the scheduling process includes appointment negotiation, assignment and optimization processes. It will be appreciated that additional processes may be included, as well as having one or more of the processes described herein omitted, without departing from the scope of the present invention. The processes of appointment negotiation, assignment and optimization have been provided merely for the purposes of an example. It will be appreciated that “process” is used herein to refer to a logical collection of activities.

[0014] The scheduling system includes a negotiator 204, an assigner 208, and an optimizer 212 which perform negotiating, assigning, and optimizing functions through the use of a negotiation algorithm 216, an assignment algorithm 220, and an optimization function 224, respectively. Negotiating offers appointment windows to a customer to select for a reservation and has performed enough processing to know that the reservation may be assigned to any of the appointment windows that are offered to the customer. Assigning assigns the reservations to a shift of a mobile service representative provided that the shift and the mobile service representative satisfy certain constraints, such as sufficient skill sets to perform the work under the reservation. Optimizing changes the way reservations are assigned by the assigning function to meet optimization objectives defined by the service organization. The optimization may move reservations within a shift of a mobile service representative. It may swap reservations between two shifts of two mobile service representatives as well. The optimization is designed to occur independent from the assignment while new reservations are being assigned.

[0015] It will be appreciated that scheduling system 200 may be implemented using various computer systems and software techniques that are well-known to those of ordinary skill in the art. A more detailed description of a system in which the scheduling system 200 may be implemented is provided in co-pending U.S. Pat. application ______, entitled ENTERPRISE SCHEDULING SYSTEM FOR SCHEDULING MOBILE SERVICE REPRESENTATIVES, filed on Apr. 2, 2001, to Jacobs et al., which is incorporated herein by reference.

[0016] In embodiments of the present invention, operation of the negotiation algorithm 216, the assignment algorithm 220, and the optimization algorithm 224 of the scheduling system 200 is governed by a constraint set, which includes a set of rules and a set of constants. The set of constraints can be defined in a file that is then compiled into a library that are used when the negotiation, assignment, or optimization algorithms are executed. The set of rules include both fixed business rules, which are generally inaccessible by a service organization, and configurable rules that can be programmed by the service organization. Similarly, as will be explained in more detail below, the set of constants are programmable and may be used by the service organization to control the flow of execution of the rules. Their values can be changed at run time by dispatchers and system administrators to adjust the rule set based on different operating conditions. For example, changing the scheduling during a snow store as compared to a sunny day, or scheduling during a major service outage.

[0017] Although the underlying structure of the negotiation, assignment, and optimization algorithms 216, 220, and 224 are fixed, and generally inaccessible to the service organization, the rules, and consequently the constants, are invoked from within the negotiation, assignment, and optimization algorithms 216, 220, and 224 by rule identifiers that are coded into the algorithms. Thus, although the service organization cannot modify the algorithm itself, through the use of the programmable rules and constants, the service organization is provided with a mechanism by which the operation of the negotiation, assignment, and optimization algorithms 216, 220, and 224 of the scheduling system 200 may be customized or configured to the particular needs of the service organization using the scheduling system 200.

[0018] Examples of the types of rules and constants shall now be discussed to illustrate their use in customizing or configuring the scheduling system 200. It will be appreciated, however, that the following description, although describing particular embodiments, is provided by way of example, and should not be interpreted in limiting the scope of the present invention.

[0019] As mentioned previously, the rules of the constraint set include both fixed business rules and configurable or programmable rules programmed by the service organization. However, the rules, both the fixed and configurable ones, can also be generally categorized by a type as well. For example, the rules of the constraint set can be categorized according to the following types.

[0020] Order candidacy rules, which govern which orders can be considered by the appointment, negotiation, assignment, and optimization algorithms;

[0021] Mobile user candidacy rules, which govern which mobile users can be considered by the appointment, negotiation, assignment, and optimization algorithms;

[0022] Assignment candidacy rules, which determine which order and user pairs constitute valid assignments;

[0023] Score rules, which provide a measure of the quality of the assignment or an order to a mobile user, and is used in assignment and optimization as well; and

[0024] Intermediate rules refer to those rules that are referenced by other rules. The intermediate rules are used to build up complex high level rules.

[0025] The three candidacy rules, namely, the order, mobile user, and assignment candidacy rules return a value of true or fail. The score rules return a numerical value, typically between zero and one. There can be a variety of score rules. For example, there are a number of instances of each type of candidacy rule, where all instances of each type must be true for the order or user to be considered a candidate. It will be appreciated that the various rules previously described can be used or accessed by one or all of the algorithms executing in the scheduling system, including the negotiation, assignment and optimization algorithms. As will be explained in more detail below, certain types of business rule values are available to corresponding types of rules.

[0026] As mentioned previously, the grammar for the rule language is designed to provide enough flexibility to express the various business rules that need to be defined for the scheduling system. A programmable rule is written by a service organization according to a language convention, which is subsequently translated into a rule grammar format. The same language convention could be used for the fixed business rules and constraint sets as well, except that the fixed business rules are inaccessible by the service organization. A suggested language convention is as follows.

[0027] A programmable rule is identified by a <rule_id> which is a label starting with the symbol “R:”. The <rule_id> must be unique within the rule context group. The rule is composed of a rule body or rule clause composed of different rule types or more rule identifiers. The rule clause is bounded by a pair of brackets ({}), and each of the rule identifiers therein are separated by a semicolon (;). The rule is then terminated by a period (.).

[0028] In addition to defining the rule language convention, data types are defined as well. The following list provides examples of those data types that can be defined within the language.

[0029] Rule label. This label identifies a rule for future reference. Rule labels begin with R:.

[0030] Variable label. This type of label is enclosed in [square brackets] and denotes a value that is returned by the system that the rule may access. The value is returned by a function and may be a single field in a database or the result of combining information from a variety of sources (e.g. a synthesis of different database fields). The motivation for providing this label mechanism is to furnish the service organization with the ability to reference values that are logically related to one another (e.g., the wage paid to a given mobile user). A variable label may be composed of one or more elements, each separated by a period (.). Each of the elements denotes a sub-field of those to its left; for example, [order.date] denotes the date belonging to the order object, and [order.assignedUser.state] denotes the state of the mobile user assigned to the order.

[0031] Variables may, as will be discussed in more detail below, represent literals, numbers, dates and strings. If the variable label is preceded by a dollar sign ($) the label is taken to be a database field name and not an accessor function. This is done in order to allow for the possibility that a service organization creates a customized database field or configurable fields that can be used by the rules and constants. For example, some configurable fields include customer contact number, completion codes (showing work done and parts or materials used to complete and order), customer account number, previous work history, and the like.

[0032] Dates. Dates are bounded by a pair of percentage signs (%%) and are specified in the following format:

[0033] yyyy/mm/dd (numeric year, month, and day)

[0034] Times. Times are bounded by a pair of ampersand signs (&&) and are specified in the following format:

[0035] hh:mm:ss (hours, minutes, and seconds)

[0036] Datetimes. Datetimes are bounded by a pair of “at” signs (@@) and are specified in the following format:

[0037] yyyy/mm/dd-hh:mm:ss

[0038] Numbers. These may be signed or unsigned, integers or real numbers base ten. Real numbers are specified in floating point format only.

[0039] Strings. These are delimited by a pair of double quotes (“”) and may contain alphanumeric or special characters.

[0040] Literals may be any of the date, number or string types. A literal label represents a label that has been equated to a literal. Literal labels are delimited by a pair of colons (::). Some special literals are defined for the rule language:

[0041] Boolean values are treated as literals e.g., :true: and :false:. An undefined or non-existent value is :nil:

[0042] Sets are supported in so far as there are operators to perform membership comparisons on sets. There is no defined mechanism for defining a set literal (via a literal label).

[0043] Based on the rule semantics and data types previously defined, an example programmable rule is provided:

[0044] R:o11 {[order.state] eq :pending:} is a Boolean rule where “R:o11” is the rule label and “[order.state] eq pending:” is the rule clause. Within the rule clause, “order.state” is a variable label which provides the current state of the order, and “:pending:” is a literal label. Essentially, the rule R:o11 will return a “true” value for all the orders that are currently pending. As will be shown in various examples below, simple rules such as R:o11 can be combined with other rules to configure the operation of the negotiation, assignment, and optimization algorithms.

[0045] The rules written according to the rule language convention previously described are subsequently translated into a rule grammar. The following list provides an example rule grammar as expressed using a BNF notation. That is, the expression to the left of the “::=” symbol are expanded to the expression provided to the right. Additionally, optional selection of a terminal or non-terminal symbol is indicated with an OR symbol “¦”, where terminal symbols are in bold and non-terninal symbols are enclosed in angle brackets “<>”. 1 Rule definition: <rule> <rule_id> <rule body> <rule_id> R: <id_label> <space> <rule body> <allof_rule> <anyof_rule> | <oneot rule> | <cond_rule> | <expr_rule> | <exec_rule> <allof_rule> all-of <blnk> {<blnk> <allof_body> <blnk> } <allof body> <rule id> | <rule_id> ; <allof_body> <anyof_rule> any-of <blnk> {<blnk> <anyof body> <blnk> } <anyof body> <rule ad> | <rule_id> ; <anyof_body> <oneof_rule> one-of <blnk> {<blnk> <oneof_body> <blnk> } <oneof body> <rule id> | <rule_id> ; <oneof_body> <exec_rule> exec-fn <blnk> {<id_label> } <expr rule> {<blnk> <exp body> <blnk> } <exp body> <rule_id> | <rule_id> ; <exp_body> <cond_rule> if <blnk> {<blnk> <cond_clause> <blnk> }<blnk> then <blnk> {<blnk> <expr_clause> <blnk> }<blnk> else <blnk> {<blnk> <expr_clause> <blnk> ) <cond_clause> <clause body> | <rule Id> <expr _clause> <expr> | <rule_Id> Rule clause definition: <rule_clause> <rule id> {<rcl body> }. <rcl_body> <blnk> <rcl_item> <blnk> <rcl_item> <clause_body> | <rule_body> | <rule_id> <clause_body> <value> <logop> <value> | <setval> <setop> <setval> Expression definition: <expr> <numexp> | <date_exp> <num_exp> <numval> | (<blnk> <num_exp> <numop> <numexp> <blnk> ) <date_exp> <dateval> | (<blnk> <dateval> <dateop> <numval> <blnk>) <numval> <number> | <literal> | <variable> <dateval> <date> <literal> <variable> <value> <blnk> <val_type> <blnk> <setval> <<set body> > <set_body> <set_element> <set_element> <blnk> <set body> <set_element> <number> | <date> <literal> <val type> <number> <string> | <date> <literal> <variable> <rule_id> <literal> <id_label> <variable> [ <var_label> ] | [ <var_label_1> ] <var_label_1> $<var_label> <var_label> <id_label> | <var_label> <var_label> <id_label> <alpha> <alphanum> <alphanum> <alpha> | <numeric> <string> “<string_body>” <string_body> <ans> <string_body> <ans> <number> <sign> <real> <space> <sign> <integer> <space> <date> % <date_defn> % <date_defn> <yyyy> / <man_man> / <dd> <time> & <time_detn> & <time_defn> <hh> / <min_min> / <ss> <datetime> @ <date_defn> - <time_defn> @ <real> <integer> <floatpart> <floatpart> <null> | <integer> <integer> <numeric> | <integer> <numeric> <ans> <alpha> | <number> | <special> <sign> <null> | + | − <dd> <integer> Range: 01-31 <mon man> <integer> Range: 01-12 <yyyy> <integer> Range: 0-9999 <hh> <integer> Range: 0-23 <mm mm> <integer> Range: 0-59 <55> <integer> Range: 0-59 <lagap> eq | neq | lt | leq | gt | geq | <setop> seq | mem | nmem | in | notin <numop> + | − | * | / | ** <dateop> + | − <alpha> a | b | c | d | e | f | g | h | i | j | k | l | m | n | o | p | q | r | s | t | u | v | w | x | y | z | A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z <numeric> 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 <special> ! | @ | # | $ | % | ˆ | & | * | / | + | _ | <space> <blnk> <spaces> | <null> <spaces> <space> | <spaces> <space> <space> UNICODE space character <null> No token required

[0046] The operators used in the above grammar are defined as follows.

[0047] all-of

[0048] This operator applies to all clauses identified in the rule body. A logical AND operation is performed on the clauses, thus:

[0049] R:xyz all-of {R:o1; R:o2; R:o3 }. is equivalent to:

[0050] R:o1 AND R:o2 AND R:o3

[0051] The value returned by this operator is a Boolean (true or false).

[0052] any-of

[0053] This operator applies to all clauses identified in the rule body. A logical OR operation is performed on the clauses, thus:

[0054] R:xyz any-of {R:o1; R:o2; R:o3 }. is equivalent to:

[0055] R:o1 OR R:o2 OR R:o3

[0056] The value returned by this operator is a Boolean (true or false).

[0057] one-of

[0058] This operator applies to all clauses identified in the rule body. A logical exclusive OR (XOR) operation is performed on the clauses, thus:

[0059] R:xyz one-of {R:o1; R:o2; R:o3 }. is equivalent to:

[0060] R:o1 XOR R:o2 XOR R:o3

[0061] The value returned by this operator is a Boolean (true or false).

[0062] Expression rule

[0063] An expression rule may consist of an expression that can either be a numeric, date or string expression or may consist of a number of rule identifiers. The result of the execution of the rule is the value of the expression or, in the case of a number of rules, the value returned by the last rule executed. An “if” statement without an “else” clause is only considered to execute if the condition is true. Thus, the rule:

[0064] R:xyz {R:o1; R:o2; R:o3 }.

[0065] executes each of the rules and returns the value of the last rule that executed. Thus, if no conditional clauses are evaluated the result of executing rule R:xyz will be the result returned by rule R:o3. The expression rule provides a flexible mechanism for performing a number of conditional clauses where the rule is expected to yield a value corresponding to the conditional clause that succeeded.

[0066] exec-fn

[0067] This operator applies to a single named function in the rule body. The result returned by the rule is that returned by the named function. This operator is provided so that complex expressions may be invoked as a single rule clause without requiring the service organization to program the expression.

[0068] Conditional clause

[0069] Conditional expressions only have a consequent and “else”clause. The former is evaluated if the logical expression of the conditional evaluates to true otherwise the “else” expression is evaluated. The syntax used is the following:

[0070] If clause then expression else expression. The clause may be a simple Boolean clause or may be a rule identifier. The expression may be numeric (returning an integer or real value), a date expression (returning a date) or a rule identifier.

[0071] Logical Operators (A op B)

[0072] Logical operators must be provided with operands of the same type. In the event that one or both operands are undefined (:nil:) the result of the operation will be :false:

[0073] In the following expressions, if A and B evaluate to numeric or date values the comparison is done based on the arithmetic relationship between the operands. If A and B evaluate to strings the comparison is done according to the UNICODE collating sequence. 2 eq Returns true if A = B neq Returns true if A ≠ B leq Returns true if A ≦ B geq Returns true if A ≧ B lt Returns true if A < B gt Returns true if A > B

[0074] Set Operators (A op B)

[0075] In the following expressions, A and B must represent sets of similar objects. 3 mem Returns true if A ∩ B ≠ Ø nmem Returns true if A ∩ B =Ø seq Returns true if A = B in Returns true if A ∈ B notin Returns true if A ∉ B

[0076] The following tables describe valid label sets that can be used in the grammar for the rule language, given the type of rule being created. The tables presented below list the variable labels that the service organization is allowed to reference and the values that the variables referenced may take.

[0077] Order Candidacy and Assignment Candidacy. The following table provides some examples of the types of business rule values that may be used in expressions for order candidacy and assignment candidacy: 4 <var_label> Type Value order.state Literal en-route|pending|on- site|dispatched| complete|cancelled| suspended order.isAssigned Literal true|false order.scheduleDate Date date|nil order.isAutoDispatchable Literal true|false order.priorityType Literal normal|emergency order.context Literal current|future|undated order.assignedUser Label Mobile User identifier order.area Variable The area for the order order.amountCollected Number Amount collected

[0078] Mobile User Candidacy and Assignment Candidacy. The following table enumerates the business rule values that may be used in expressions for mobile user candidacy and assignment candidacy: 5 <var_label> Type Value user.isAutoDispatchable Literal true|false user.state Literal available|unavailable| en-route|on-site| emergency user.isInEmergencycontrol Literal true|false user.area Variable The mobile user's assigned area user.wage Number mobile user wage

[0079] Assignment Candidacy. The following table enumerates the values that may be used in expressions for assignment candidacy: 6 <var_label> Type Value user_order.travelTime number mobile user travel time

[0080] Area Data. The following table enumerates some of the values that may be used in expressions involving areas: 7 <var_label> Type Value area.travelMin number Minimum area travel time area.travelMax number Maximum area travel time

[0081] System Data. The following table enumerates some of the system values that may be used in expressions for mobile user or order candidacy: 8 <var_label> Type Value SystemDate date Date SystemMinUserwage number Minimum mobile user wage SystemMaxUserwage number Maximum mobile user wage SystemAmountCollectedMin number Minimum amount collected SystemAmountCollectedMax number Maximum amount collected SystemSchedulingActivity literal scheduled|redistribution| Type in-day|floater|suggest| forecast|auto-distribute

[0082] Constants, as briefly discussed above, allow a service organization to control the flow of execution within the rules. Constants are a mechanism for replacing global constants that would otherwise require explicit reference in the programmable business rules. This feature is illustrated by the following example.

[0083] Let there be a Boolean constant X that the service organization sets to establish some configuration. Additionally, the service organization has included a programmable rule that should be invoked if the value of X is true. Through the use of constants, the rule could be formulated in the form:

[0084] Rule R1: If (X=true) and (Y or Z) then expression.

[0085] This rule could be recast in the following form, using a constant:

[0086] Constant C1: true.

[0087] Rule R2: If (C1) and (Y or Z) then expression.

[0088] Thus, this mechanism allows the service organization to change the behavior of rules by manipulating secondary level rules (those invoked explicitly by other rules) rather than referencing a global value explicitly.

[0089] The following are some examples illustrating the use of the programmable rules and constants that may be created by the service organization using the rule language convention previously described. It will be appreciated that the following examples have been provided to illustrate various aspects of the present invention, and are not intended to limit its scope.

[0090] Constants

[0091] Emergency Order Dispatching

[0092] This constant allows for emergency order dispatching. It is checked in the order candidacy rule.

[0093] R:EmergencyOrderDispatching {{:true:}}

[0094] If we wish to turn off emergency order dispatching the constant would read thus:

[0095] R:EmergencyOrderDispatching {{:false:}}

[0096] Rules

[0097] Order Candidacy Rules

[0098] This example uses the constant rule R:EmergencyOrderDispatching previously defined. The order candidacy rule (R:OrderCandidacy) describes the conditions under which an order can be automatically assigned by the scheduling system to a mobile user. For example, for an order to be assignable, the order state must be pending (R:o11) or dispatched (R:o12), the order must be enabled for automatic assignment (R:o6), as well as a number of other conditions. The order candidacy rule also makes use of a constant. For example, there is a constant that indicates whether an emergency order can be automatically dispatched (R:EmergencyOrderDispatching). If the value of this constant is false, that is, emergency orders cannot be automatically dispatched, and the order is an emergency order, then it cannot be automatically assigned. However, if the value of this constant is true, then the order can be dispatched even it is an emergency order. 9 R:OrderCandidacy all-of{R:ol; R:o3; R:o4; R:o6; R:o7; R:o9 }. R:ol {any-of {R:oll;R:o12}}. R:o11 {[order.state] eq :pending:}. R:o12 {[order.state] eq :dispatched:}. R:o3 {[order.isAssigned]eq :false:}. R:o4 {[order.scheduleDate]le [systemDate]}. R:o6 {[order.isAutoDispatchable] eq :true:}. R:o7 {any-of {R:o71; R:o72}}. R:o71 {[order.priorityType] neq :emergency:}. R:o72 {all-of {R:o721; R:EmergencyOrderDispatching}}. R:o721 {[order.priorityType] eq :emergency:}. R:o9 {R:Usercandidacy}.

[0099] Mobile User Candidacy Rules

[0100] The mobile user candidacy rule (R:UserCandidacy) describes the conditions under which a mobile user can be automatically assigned orders. For example, to be assigned orders, a mobile user must be enabled for automatic assignment (R.f100) and must not be in an emergency state (R:f100), as well as a number of other conditions. 10 R:UserCandidacy all-of {R:f100; R:f101; R:f102; R:f105 }. R:f100 {[order.assignedUser.isAutoDispatchable] eq :true:}. Rf101 {[order.assignedUser.state] neq :emergency: }. Rf102 {[order.assignedUser.isInEmergencyControl] neq :true:}. Rf105 {any-of{R:f1051; R:f1052}}. R:f1051 {[order.assignedUser.mode] neq :local:}. R:f1052 {all-of {R:f10521; R:UserlocalModeDispatch }}. R:f10521 {[order.assignedUser.mode] eq :local:}.

[0101] Amount Collected Rule

[0102] The amount collected rule provides a score, between 0 and 1, that indicates the relative value of (that is, the revenue generated by) working on an order. Higher values represent more revenue collected. Note that rule R:ac10 is used in many places in the following example. Thus, the R:ac10 rule provides a good example of the use of an intermediate rule. 11 R:AmountCollectedScore {R:ac1; R:ac2; R:ac3 }. R:ac1 {if {R:ac10 leq 0} then { 0 }}. R:ac2 {if {R:ac20 }} then { R:10 }}. R:ac20 all-of { R:ac21; R:ac22 }. R:ac21 { R:ac10 gt 0 }. R:ac22 { R:ac10 lt 1 }. R:ac3 {if{R:ac10 geq 1} then { 1 }}. R:ac10 {if {[systemAmountCollectedMax] eq [systemAmount CollectedMin]} then { 1 }else {R:ac101}}. R:ac101 {( 1 − (([order.amountCollected] − [systemAmount CollectedMin]) / ([systemAmountCollectedMax] − [systemAmount CollectedMin]))}.

[0103] Mobile User Wage Rule

[0104] The mobile user wage rule provides a score, between 0 and 1, that indicates the whether the mobile user is expensive to assign to orders. Lower values represent more expensive mobile users. 12 R:WageScore { R:w1; R:w2; R:w3 }. R:w1 {if {R:w10 leq 0} then { 0 }}. R:w2 {if {R:w20 }} then { R:10 }}. R:w20 all-of { R:w21; R:w22 }. R:w21 { R:w10gt 0}. R:w22 {R:w10 lt 1 }. R:w3 {if {R:w10 geq 1}then { 1 }}. R:w10 {if {[systemMaxUserWage] eq [systemMinUserWage]} then { 1 }else {R:w101}}. R:w101 {(1 − (([user.wage] − [[systemMinUserWage])/ ([systemMaxUserWage] − [systemMinUserWage])))}.

[0105] It will be appreciated that certain details have been set forth herein to provide a sufficient understanding of the invention. However, it will be clear to one skilled in the art that the invention may be practiced without these particular details. In other instances, well-known circuits, control signals, timing protocols, and software operations have not been shown in detail in order to avoid unnecessarily obscuring the invention. Additionally, computer and/or software implementation of embodiments of the present invention are well-known to those of ordinary skill in the art. It will be further appreciated that, although specific embodiments of the invention have been described herein for purposes of illustration, various modifications may be made without deviating from the spirit and scope of the invention. Accordingly, the invention is not limited except as by the appended claims.

Claims

1. A method for configuring a schedule process, comprising:

scheduling an order into a shift of a worker according to a set of rules; and

configuring the set of rules to change the act of scheduling.

2. The method of claim 1 wherein configuring comprises programming a rule to control which orders are considered in the schedule process.

3. The method of claim 1 wherein configuring comprises programming a rule to control which workers are considered in the schedule process.

4. The method of claim 1 wherein configuring comprises programming a rule to control whether an order can be assigned to a worker.

5. The method of claim 1 wherein configuring comprises programming a rule to provide a score when comparing a workers to an order.

6. The method of claim 1, further comprising programming a set of constants to control the flow of execution within the rules, the constants replacing global constants that would otherwise require explicit reference in the configured set of rules.

7. The method of claim 1 wherein scheduling comprises negotiating a reservation, assigning the reservation, and optimizing the reservation.

8. A method for configuring a schedule process, comprising:

scheduling an order into a shift of a worker according to a set of rules; and

programming a constraint set to change the act of scheduling.

9. The method of claim 8, wherein programming a constraint set includes programming a set of rules, each rule programmed in accordance with a rule language convention having:

a first field containing rule identifier to uniquely identify the data structure; and

a field containing a rule body including material for altering the schedule process from a standard process to a reconfigured process.

10. The method of claim 8 wherein scheduling comprises negotiating a reservation, assigning the reservation, and optimizing the reservation.

11. A method for performing a schedule process, comprising:

programming a programmed constraint set to supplement or change a fixed constraint set; and

executing a scheduling process that performs a process of scheduling orders to a worker in accordance with the programmed constraint set and the fixed constraint set.

12. The method of claim 11 wherein the programmed constraint set comprises programmable rules and constants.

13. The method of claim 12, further comprising translating the first set of rules from a defined configurable rule language convention into a predefined grammar.

14. The method of claim 13 wherein translating the first set of rules comprises compiling the first set of rules into a library that is used when the schedule process is performed.

15. The method of claim 12 wherein executing the scheduling process comprises performing the scheduling process according to a standard process except where the programmed first set of rules have altered performance of the scheduling process to a reconfigured process.

16. A scheduling system for a scheduling environment, comprising:

a negotiator to negotiate the reservation of orders; and

an assigner to assign the orders to workers,

the negotiator and assigner respectively negotiating and assigning the orders according to a constraint set including a fixed set of business rules and a set of programmable configuration rules.

17. The scheduling system of claim 16, further comprising an optimizer to optimize the reservation of orders.

18. The scheduling system of claim 16 wherein the negotiator and assigner are implemented in a computer system having a processor and a memory coupled thereto.

19. The scheduling system of claim 16 wherein the set of configuration rules programmed according to a rule language convention defining a first data field containing data to uniquely identify a respective configuration rule and a second data field containing data representing a rule clause for altering a scheduling process from a standard process to a reconfigured process.

20. A scheduling system, comprising:

a memory for storing a set of rules having a set of fixed business rules and a set of configurable rules programmed by a service organization; and

a processor coupled to the memory for executing a scheduling process that performs a schedule process of scheduling orders and workers in accordance with the set of rules as altered by the set of configurable rules.

21. The scheduling system of claim 20 wherein execution of the scheduling process by the processor includes invoking the set of rules from defined locations in a negotiation algorithm.

22. The scheduling system of claim 20 wherein the processor further executes an assignment algorithm in accordance with the set of rules as altered by the set of configurable rules to assign orders to a worker.

23. The scheduling system of claim 20 wherein the processor further executes an optimization algorithm in accordance with the set of rules as altered by the set of configurable rules to assign orders to a worker.

24. The scheduling system of claim 20 wherein the processor further executes negotiation, assignment, and optimization algorithms in accordance with the set of rules as altered by the set of configurable rules to schedule orders to a worker.

25. The scheduling system of claim 20 wherein the set of configurable rules programmed by the service organization are compiled from a defined rule language convention into libraries and stored in the memory according to a defined rule grammar format.

26. A scheduling system, comprising:

a first algorithm for negotiating the reservation of work orders;

a second algorithm for assigning work orders to workers;

a set of rules that are invoked from defined locations in the first and second algorithms to govern execution of the algorithms, the set of rules including a fixed set of business rules augmented by a set of programmable rules for altering execution of the algorithms from the execution according to only the fixed set of business rules.

27. The scheduling system of claim 26 wherein the first and second algorithms are implemented in a processor and the set of rules are stored in a memory coupled to the processor.

28. A computer-readable medium having stored thereon a data structure, comprising:

a first data field containing data to uniquely identify the data structure; and

a second data field containing data representing a rule body including data for altering a scheduling process from a standard process to a reconfigured process.

29. The computer-readable medium of claim 28 wherein the scheduling process comprises negotiating a reservation, assigning the reservation, and optimizing the reservation.

30. The computer-readable medium of claim 28 wherein the second data field includes a variable label denoting a value that is returned when the data structure is accessed.

31. The computer-readable medium of claim 30 wherein the second data field includes bracket delimiters to identify the variable label.

32. The computer-readable medium of claim 28 wherein the second data field includes an operator and a rule body, the rule body bounded by a pair of braces and the operator operating on the rule body.

33. The computer-readable medium of claim 32 wherein the operation comprises a Boolean operator.

34. The computer-readable medium of claim 32 wherein the operation comprises a set operator.

35. A computer-readable medium having instructions stored thereon for causing a computer to perform a method for performing a schedule process, comprising:

scheduling an order into a shift of a worker according to a set of rules; and

configuring the set of rules to change the act of scheduling.

36. The method of claim 35 wherein configuring comprises programming a rule to control which orders are considered in the schedule process.

37. The method of claim 35 wherein configuring comprises programming a rule to control which workers are considered in the schedule process.

38. The method of claim 35 wherein configuring comprises programming a rule to control whether an order can be assigned to a worker.

39. The method of claim 35 wherein configuring comprises programming a rule to provide a score when comparing a workers to an order.

40. The method of claim 35, further comprising programming a set of constants to control the flow of execution within the rules, the constants replacing global constants that would otherwise require explicit reference in the configured set of rules.

41. The method of claim 35 wherein scheduling an order comprises negotiating a reservation, assigning the reservation, and optimizing the reservation. 42. A computer-readable medium having instructions stored thereon for causing a computer to perform a method for performing a schedule process, comprising executing a scheduling process that performs the schedule process of scheduling orders to a worker in accordance with a programmed constraint set and the fixed constraint set, the programmed constraint set programmed by a service organization and augmenting the fixed constraint set to alter performance of the schedule process to a desired configuration.