WO2001029663A1

WO2001029663A1 - Resource allocation system

Info

Publication number: WO2001029663A1
Application number: PCT/GB2000/004095
Authority: WO
Inventors: Brian Robert Odgers; Simon Giles Thompson; John William Shepherdson
Original assignee: British Telecommunications Public Limited Company
Priority date: 1999-10-21
Filing date: 2000-10-23
Publication date: 2001-04-26
Also published as: AU1040401A; EP1226497A1

Abstract

Methods and systems are proposed for coordinating tasks carried out by operatives. An operational support system (1) defines requirements for work to be carried out by operatives. The operatives receive instructions via an intermediary coordinator (3). The operatives are provided with a software agent (5), which empowers them to make requests. The intermediary (3) reconciles the work requirements with the requests. The method and systems use agent-based negotiation strategies and allow workers and team managers to control the system in a visual interactive fashion. The system can be used to enable workers to set work preferences, trade jobs, share knowledge as well as build informal alliances to help each other with their work. Managers are able to review and control local business rules and scheduling preferences using their own software agent (7).

Description

RESOURCE ALLOCATION SYSTEM

The present invention relates to methods and systems for allocating resources and can find application for instance in co-ordinating work, performed by either machine resources or operatives, with the purpose of fulfilling overall work requirements.

Embodiments of the invention support for instance work co-ordination designed to take into account potential changes in resource availability. Such changes may arise for example as a result of changes in resource capacity, or working rates, requests made by operatives and/or constraints set by local managers.

Where the resource concerned is directly machine-based, there can be several factors controlling use of the resources. All of these factors may change in real-time. There may be global constraints concerning a particular machine model, its maximum permitted working rate and changes in capacity enabled by new installations such as supporting database capacity or other platform capabilities. There may be more local constraints, however still applying across several machines, such as noise control in specific geographical areas, or changes in available infrastructure. Clearly, there can be machine-specific factors such as machines overheating, going off-line or coming back on-line, or software problems blocking up part or all of a machine's capacity. In a machine process environment, operatives may locally wish to use machine capacity for work in addition to a specified work requirement. The consequence of that local use of resource might however conflict with overall work limits for the best operation of the machine.

Most existing work control systems implement a process by co-ordinating a set of activities that comprise a model of that process. Existing workflow systems use Petri Net-like models of work and rigidly enforce these models. Because of this dictatorial style they are often called "naziware" (Dourish et al . 1 996) .

Many workflow systems use a single "correct" process model controlled by a single person . Collaboration while planning a business process is supported by the research system Regatta VPL (Swenson, K et al, 1 994), and its commercial offshoot TeamWARE Flow. They allow business professionals to define and change "their" section of the process (their perspective) by manipulating a visual representation. However, it fails to support control and transparency across different perspectives. According to a first aspect of the present invention, there is provided a method of supporting resource allocation in carrying out respective tasks which together fulfill one or more work requirements, each resource being provided with a resource interface, the method comprising: storing constraint definition data defining constraints on said allocation of resources; storing an initial data representation of resource availability; receiving, from at least one of said resource interfaces, availability data concerning availability of a resource; modifying a copy of said initial data representation according to said availability data to generate a proposed data representation of resource availability; determining whether said proposed data representation is compatible with said constraint definition data; in the case that said proposed data representation is compatible with said constraint definition data, substituting said proposed data representation for said initial data representation to generate a new initial data representation; and in the case that said proposed data representation is not compatible with said constraint definition data, generating and transmitting a rejection signal to said at least one of said resource interfaces. Thus the method enables the allocation of task(s) to each resource such that the work requirements will be met and so as to accommodate availability data received via resource interfaces in the light of predetermined constraints.

The availability data can be entered to the system at the resource interface by operatives who may control equipment resources or who may themselves be resources to which tasks are allocated. Alternatively, an equipment resource may itself enter availability data at the resource interface, generated for instance simply by failing or going offline. In this instance, an embodiment of the invention preferably further comprises, in the case that said proposed data representation is not compatible with said constraint definition data, generating and transmitting a failure indication signal, for instance to a predetermined user interface or to resource allocation means.

An embodiment of the present invention can be used such that either machines or operatives (ie people) can each make inputs (e.g. via a resource interface including or connected to a software agent) to an intermediary system which operates to reconcile the inputs with (real or projected) constraints affecting an overall work project to be carried out,

Preferably, said constraint definition data comprises constraint definition data of at least two types, a first type defining global constraints in respect of resources for carrying out the respective tasks which together fulfill one or more work requirements, and a second type defining constraints with respect to a specified set of resources, the method further comprising storing constraint definition data of said first type, receiving constraint definition data of said second type, and determining whether said constraint definition data of said second type is compatible with the stored constraint definition data of said first type.

Embodiments of the present invention can thus be used to apply both global and local constraints, for instance both a local maximum task load for allocation to a specified resource and a global minimum task load for allocation to resources of a specified type, and to review received local constraints against stored global constraints.

If the system is used for allocating operatives to carry out respective tasks towards an overall work requirement, then the global constraint definition data might define for instance statutory or company requirements in relation to workload while the local constraint definition data might reflect policies for instance on overtime applied by individual team managers.

In an embodiment where the resources to be allocated are machine resources, then the global constraint definition data might relate for instance to a company policy that resources of a particular category should be allocated to tasks before machine resources of a simpler or older category while the local constraint definition data might enable local conditions to be applied such as use of quieter machine resources at weekends.

This means that a local manager with authority over a plurality of resources or operatives may supplement the constraint definition data by constraints chosen by him or her.

Local constraints which a local manager may wish to impose on a team of operatives as resources may be for instance constraints on the type of work to be performed by each operative. In a first example, a local manager may add local (environmental) data characterising the local geography for example (such as journey times between tasks) . The data may be static (e.g. data defining the journey times between locations at which tasks are performed) or time-dependent (e.g. based on present or projected weather or traffic conditions) . In a second example, the local manager may be able to supply constraints relating to individual personnel (e.g. types of task for which individuals are qualified, and constraints relating to combinations of staff who have been found to work together well or badly in the past) .

Where the resources are machines, equivalent constraints might arise from using machines which are close together in a network, to keep network traffic down, or time-dependent in order to make best use of off-peak rates.

Preferably, the method further comprises storing, so as to be modifiable via a resource interface, data which is resource specific. This enables a further, important embodiment of the present invention. Preferably, in the case that said proposed data representation is not compatible with said constraint definition data, the method comprises generating and transmitting a rejection signal to a plurality of said resource interfaces, each such resource interface being triggered to review its respective resource specific data and to output availability data concerning availability of its resource in dependence on the outcome of said review. This means that each resource or operative can potentially be provided with, or set, a "personal profile" which is used by the resource interface allocated to that resource or operative to respond to rejection signals concerning other resources or operatives by outputting availability data. This feature makes the method interactive in respect of the resource interfaces without an operative or machine having to make real-time inputs in response to outputs or queries by the system. This interaction is important because the intermediary may transmit a rejection signal to a plurality of resource interfaces and receive an input from one of the plurality which changes the proposed data representation such that it becomes compatible with the constraint definition data. The intermediary can then retroactively accept an earlier input from a resource interface which it would originally have rejected.

Typical inputs to the intermediary by the resource interface, based on a personal profile, might relate to the type of work which the operative or resource does, the order in which it is done, the time(s) at which it is done, and the identities of one or more other of the operatives ("friends") with whom that operative wishes to cooperate. Thus, team-building activities are supported by enabling operatives to build a list of "friends" to help each other out. Team learning and knowledge sharing activities may be supported by using personal profiles to identify people who work on the same task or in the same locality, and to provide information to "the expert" on a given issue.

This type of "personal profile", or resource profile, is also of use where the resource is a machine since it allows for instance a machine to identify a set of existing machines in a system for which it has compatible software installed and for which it can substitute.

A further possibility where resources are operatives or controlled by operatives, is for the method to determine (based on the tasks an operative is to perform, and their experience and qualifications) whether further explanation of the task will be required (or would be helpful) . If so the explanation is transmitted to that operative. Where the resource is a machine, this facility might be used to download data or software which the machine might need in order to fulfill a particular task.

An alternative which is also possible within the scope of the invention is for the method to accumulate instances of availability data, and at any time to determine a selection of instances which are compatible with constraint data based on the work requirements, and to update the data representation according to that selection.

In the method described above, said one or more work requirements may be supplied by an operational support system. Global constraint definition data may also be supplied by the operational support system. Optionally, the operational support system may be adapted to supply work requirements for each of a plurality of local managers, each of whom is responsible for a respective set (team) of resources. The operational support system may be thus able to apportion a large work project into a plurality of sections (one for each team) , each having a number of work requirements. The operational support system may also supply local constraint definition data in respect of each respective set of work requirements, e.g. to the local manager, for use in the method.

The method of the invention expressed above can be carried out using a computer system referred to below in the specific description as an "intermediary" . A local or team manager can be provided with an interface for communicating with the intermediary, and including data input means for inputting local constraint definition data.

It may be useful that a resource profile includes a priority indicator with respect to an availability commitment for its resource, or perhaps with respect to a type of task. When the resource interface receives a rejection message, it can then review its resource profiles(s) for cases where a resource is committed to a task but with only low priority. For instance, the resource might be doing non-system tasks. Or the rejection message may be in respect of a task that the resource is defined to give top priority to. The resource interface may then output availability data in respect of a resource which is already fully booked but which will jettison commitments as necessary if the availability data is accepted . This allows resources to provide selective back up in certain circumstances.

It may also be useful that a method according to an embodiment of the present invention further comprises, subsequent to generating and transmitting a rejection signal, triggering termination of tasks being carried out in respect of a common work requirement to which the rejection signal is related. This allows embodiments of the present invention to close down activity in support of a work requirement where it has emerged that changes in resource availability mean the overall work requirement cannot be met. Preferably, there will be a time out before termination happens, to allow resources to review their priorities.

According to a second aspect of the present invention, there is provided a system for supporting resource allocation in carrying out respective tasks which together fulfill one or more work requirements, the system comprising: a data store for storing constraint definition data defining constraints on said allocation of resources; for each resource, a resource interface for inputting resource availability data; an intermediary for receiving said resource availability data, reviewing it against stored constraint definition data and transmitting a message dependent on the result of the review to at least one resource interface; at least one of said resource interfaces being provided with a resource specific data store, said resource interface being triggerable by receipt of such a result- dependent message to review its resource specific data store and to transmit resource availability data to the intermediary dependent on the outcome of the review; such that allocation of resources can be amended according to interaction between a resource interface and the intermediary, within limits determined by the constraint definition data.

Allocation apparatus may determine an allocation of the work required to perform a work project between a plurality of such systems and transmit to each said system constraint data based on the required work to be performed by the respective resources available to that system . It is possible for the intermediaries of respective systems to bid against each other (e.g. on behalf of their resources) to be allocated a certain section of the work. For this purpose the intermediaries may be provided with bidding functionality.

Embodiments of the present invention have particular strength in that they can support team-based collaboration in complex environments. For example call centre staff could control call routing preferences, on-job training scheduling and so on.

An embodiment of the invention will now be described for the sake of example only with reference to the accompanying figures, in which:

Figure 1 shows schematically the functional structure of elements of a system according to an embodiment of the present invention; Figure 2 shows schematically how the elements of Figure 1 may be supported by platform;

Figure 3 and 4 show schematically the primary components of a resource agent and an intermediary for use in the system shown in Figure 1 ;

Figure 5 shows a PC window displaying resource information in the embodiment of Fig. 1 ; and

Figure 6 shows a PC window displaying intermediary information in the embodiment of Figure 1 .

Referring to Figure 1 , an embodiment of the present invention is illustrated schematically. The system includes an operational support system (OSS) 1 , such as a billing and work scheduling system . The OSS 1 is provided with, or generates, a definition of a work project to be carried out by a number of teams of operatives. For each team of operatives, there is an intermediary 3, in electronic communication with the OSS 1 . Each operative is provided with an intelligent resource interface 5. Each team has a manager, who is also supplied with an intelligent interface 7. Furthermore, there is an intelligent "trusted third party" interface 8 for use by a third party in arbitrating for instance between operatives and managers.

All of these functional blocks communicate using appropriate protocols. (The actual forms of communication are discussed below in more detail.)

Each resource interface 5 and the intermediary 3 can be considered to be a software agent in that each acts on behalf of an entity, has data or rules specific to the entity available to it, and can process incoming message content against the data or rules and output a response based on the outcome of the processing. Referring to Figure 2, there are five primary types of data stored in the system. These are work project, or task, definitions 20, resource availability models 3b, global rules 3c, local rules 7b and resource profiles 5b.

An embodiment of the present invention is brought into use when the OSS 1 sends a definition of a work project to one or more intermediaries 3. The definition of a work project which is sent to each intermediary 3 will be in the form of a set of tasks for performance by the resources available to the respective intermediary 3, in this case by means of its team of operatives. The definition of the work project will be in the form of a schedule allocating resources to the tasks or sub-tasks. The intermediary 3 transmits the scheduling information relevant to each operative to that operative's resource interface 5.

The scheduling of tasks received by the intermediary 3 from the OSS 1 is necessarily a "day 1 " scheduling. It will be subject to amendment during performance of the tasks not least because of changes in resource availability from day to day. Where the resources are machines, this may be due to changes in installed versions, faults, updates, non-system workload and the like. Where the resources are controlled by operatives, the changes in availability may also occur as a result of the associated operative availability, for instance days off or preparedness to do overtime.

Having output the respective scheduling data to each resource interface 5, the intermediary agent 3 will receive data from any resource interface 5 for which there is a change in availability, proposed or necessary. The intermediary 3 reviews the incoming availability data from the resource interfaces 5 against global rules 3c and against local management rules 7b and accepts or rejects availability data from respective resource interfaces 5 in accordance with the outcome of the review.

The intermediary 3 for each team thus supports team co-ordination, and interfaces with the OSS 1 . Relevant information is passed from the OSS 1 to the intermediary. The intermediary 3 uses this information along with global and local rules 3c, 7b to support resources and/or operatives in interactive generation of a shared resource availability model. When the intermediary 3 has determined that an acceptable model has been generated, it passes the result back to the OSS 1 for use in its next evaluation cycle. During the evaluation cycle, the OSS 1 can use the model for example to assess which workers are taking overtime so that pay can be varied accordingly, or to assess the quality of a given team or set of resources.

Thus the system provides means for implementing scheduling data from an OSS 1 in respect of resources to carry out a work project, while accommodating changes in availability of the resources without conflict arising over local management rules 7b or global rules 3c. Hence day to day changes in resource availability are acceptable within a predetermined framework.

Each team manager can use their team manager interface 7 to input and modify local rules 7b for their team. A further function of the intermediary 3 is to review the local rules 7b against the global rules 3c which have priority. Hence the intermediary 3 also provides a mechanism for team managers to set local rules 7b without breaking global rules 3c which may, for instance, derive from statutory requirements or corporate policy.

From the operatives' point of view, a particular strength of embodiments of the present invention lies in the provision of resource profiles 5b. Using their resource profiles 5b, operatives can set workload preferences such as task difficulty levels, and build informal alliances to help each other with their requests. Parameters of this type can be implemented in use of the system by the resource interfaces 5. When a resource interface 5 receives scheduling information or notice of a change in availability data regarding another resource, the resource interface 5 reviews the resource profile 5b in respect of its resource (or operative) and in certain circumstances may output availability data to its intermediary 3. This might occur in the following circumstances. A resource or operative may require to change availability, for instance by taking a day off or by being taken out of the service for maintenance. This resource will effectively send a request via its resource interface 5 to its intermediary 3 for a change in availability status. If the intermediary 3, on review of the local rules 7b and/or the global rules 3c, finds that the change conflicts with a rule, the intermediary 3 will return a rejection to the relevant resource interface 5, copied to each other resource interface 5 designated as being in the same team. One of the resource interfaces 5 receiving the rejection notice, on review of its resource profile 5b, may find the resource or operative being rejected listed there as subject to special status. This resource interface 5 may then issue effectively an offer to cover in place of the rejected resource. The intermediary 3 will review the offer and issue an acceptance notice. The resource interface 5 which received the rejection notice may now resend its original request. The intermediary 3 will review the request in light of the offer and, as long as there is no conflict with the local 7b or global rules 3c, will now accept the request.

An operative can thus control their work environment by interacting via their resource interface. Control can either be exercised at run-time (for example by selecting the next task) or at the planning stage (for example by specifying task difficulty preferences for the next day). Once an operative specifies his or her preferences, the resource interface will negotiate these preferences with the rest of the team through the intermediary 3. (One resource interface 5 may serve more than one resource. It will need access then to more than one resource profile.)

The intermediary 3 employs the local and global rules 7b, 3c to balance requests against expected workload for a team. The team manager can develop and change the set of local rules 7b available to the intermediary. This can be done by a mechanism similar to setting the resource profiles. The manager has access via the manager's interface 7 to modify the local rules 7b, and the changes will be submitted to the intermediary 3. The intermediary will check if they are compatible with the global rules 3c and output a rejection message if there is incompatibility.

The same mechanism can be expanded to cover multiple levels of authority, and to allow different people to modify different aspects of the system.

The system can provide support for team collaboration by notifying all resource interfaces 5 of the results of all requests, and the reasons for any rejection. This comparatively simple notification strategy enables a variety of negotiation and collaboration activities when combined with the intelligent behaviour of the resource interfaces 5.

Figure 1 shows the functional communications paths set up between parts of the system in use. Referring to Figure 2, in order to support functionality as described above, the system is structured as follows:

Processing software 3a, 5a, 7a, for the intermediary 3, the resource interface 5 and the team manager interface 7 is provided on a server 205 local to the team. The intermediary 3 and the interfaces 5 , 7 have access to a database 21 0 for storing rules and models for both the intermediary 3 and the interfaces 5, 7. The database 21 0 may be supported by capacity on the server 205 itself, or elsewhere. Users (operatives and managers) can run the processing software 3a, 5a, 7a within appropriate limits by means of graphical use interfaces (GUIs) on their personal computers 5c, 7c. Processing software 8a for an independent manager agent or trusted third party 8 is also provided on the server 205, and a GUI on their personal computer 8c. A computer supporting the OSS 1 is connected to provide work requirements 200 to the intermediary 3.

Communications among the platform elements mentioned above, the server 205, personal computers, database 21 0 and OSS platform, are provided by any suitable links, such as a local area network 21 5, adapted to carry the relevant protocols, further described below.

The distribution of processes and data amongst platform in this arrangement may of course be modified, depending where capacity is or becomes available. For instance, the resource interface processes 5c may in practice be loaded on respective PCs 5c. At a simple level the way the system can work day to day is that an OSS 1 establishes a resource model with an intermediary by sending data concerning resources in their team. For instance, if the resources are people, this will be a list of the people plus their current working status, such as "day off" or "working". The intermediary builds a model of the team from the data. The OSS then issues work requirements 200 to the intermediary 3. These work requirements may for instance be issued as a list of tasks or the intermediary may be equipped to translate a work requirement to a list of tasks. The intermediary 3 issues one or more requests to its resource interfaces 5 for offers of worktime against tasks. Each resource interface 5 reviews the requests against the data it has stored for its respective resource (or operative) , outputs an offer back to the intermediary 3 if the result of the review makes that appropriate, and updates its data to reflect the offer. The intermediary 3 builds a proposed model of resource allocation against tasks, reviews the proposed model against the global rules 3c it has stored, and against local rules 7b set by team managers, installs the proposed model if it satisfies the rules, and issues notices to the relevant resource interfaces 5 that their offers have been accepted or rejected as appropriate.

The effect of this is that the intermediary 3 can resolve conflict and apply both team (local) and global rules. Conflict can arise for instance because a team manager sets a new team rule, such as increasing the amount of overtime to be done per operative, and that new team rule conflicts with an existing global (eg company or legislative) rule. The intermediary 3 reviews any new team rule immediately against the global rules and notifies the relevant manager agent 7 of any conflict. Operative preferences can also conflict with the rules. This will be resolved automatically by the intermediary 3 in use since it will simply reject offers and requests issued by a resource interface 5 which conflict with the rules, with an explanation.

Referring to Figures 1 and 3, taking the components of the system in turn, a resource interface 5 comprises a GUI 5c, processing software 5a, data in the form of a resource profile 5b, and a message handler 5e of known type for sending and receiving messages using the known Agent Communication Language (ACL), compliant with the de facto FIPA standard. In use, the resource interface 5 will also maintain a real time record 5d of current commitments, offers and rejections, in respect of its resource.

The role of the resource interface 5 is to maintain the resource profile of a specified resource or operative, to maintain the real time record 5d, and to use the profile and real time record in negotiating with the intermediary 3 on behalf of the resource or operative. The resource interface 5 provides a GUI 5c for instance by downloading forms, drop down menus and the like, to the operative's personal computer in order for them to input the profile. This might include for instance the following: ξ Screen appearance ξ Information filters ξ User or resource groups ("friends") ξ Task difficulty levels ξ Working practices (such as "only pay back overtime owed to another operative" or "only allocate tasks to this resource if a resource of another type is unavailable")

The resource interface 5 stores this profile 5b as a set of rules. The real time record 5d meanwhile records the resource's or operative's actual and proposed commitments. These are determined by interaction with the intermediary 3. Referring to Figure 4, an intermediary 3 comprises OSS interface software 40, processing software 3a and, again, a message handler 3e for sending and receiving messages using the Agent Communication Language (ACL), compliant with the de facto FIPA standard . The message handler will be used by the intermediary 3 in communicating with the resource, team manager and trusted third party interfaces 5, 7, 8.

The role of the intermediary 3 is to maintain a model 3b of the current availability of its resources, to maintain the local and global rules 7b, 3c, receive availability messages from resource interfaces 5 , review them against the local and global rules 7b, 3c and issue rejection messages, or acceptance messages, appropriately to resource interfaces 5. It also receives task definitions 20 from the OSS 1 , uses them to generate at least an initial model 3b of task allocation amongst resources, reviews an existing task allocation model 3b in the light of incoming availability messages from resource and interfaces 5b and outputs data on actual task performance to the OSS 1 to support management processes therein. The following provides an example of the system in use, with examples of message content being passed between elements of the system. It is primarily given in terms of the resource interfaces 5 acting for operatives of resources to carry out tasks but it will be clear that the same principles will apply where the resource interfaces 5 are acting for resources themselves.

1 . Setting up

In order to set the system up, the OSS 1 provides data to the intelligent components in the system. For instance, the resource interfaces 5 will need data in respect of their resources before they are equipped to act on behalf of those resources. The OSS 1 provides information such as:

1 .1 Workers name details and working status Eg Employeelnfo

{name: Fred Smith person' s name

Computer: 1 43.1 99.1 23.456 computer address

Job description: manager engineer | manager

Workstatus: working} working | day off | overtime

If not already instantiated, this data is used to instantiate the resource interfaces 5 in a team, and the team manager's interface 7, via the relevant intermediary 3. Depending on the circumstances, it may also be necessary that the OSS 1 provides time or date information so that availability information can be mapped against time or date. The intermediary 3 itself then selects data with respect to availability of its resources and forms an initial "confirmed availability model":

1 .2 Confirmed model: {ListOfEmployees{all Employeelnfo} WorkersDayOff = 0 sum of employees taking day off

WorkersOvertime = 1 } sum of employees taking overtime

In order for the system to be enabled to respond in use on behalf of specific resources or operatives, the resource interfaces 5 need to be loaded with respective resource profiles 5b. This can be done by operatives via the GUIs 5c. Alternatively, profiles could be loaded from an output of the OSS 1 . This might be more appropriate for instance where the resource interface 5 is to act for a resource and the data involved in a resource profile 5b might comprise aspects such as communications protocols the resource is equipped to use, available processing capacity and the like.

2. The method for getting a day off An operative (Ken) clicks the day off button on his GUI 5c. The resource interface 5 uses its processing software 5a and message handler 5e to translate this into the following agent message and sends it to the intermediary 3:

2.1 Request

(Request

:sender KenAgent receiver Intermediary

:content :effect Ken is an Employee who is seeking day off :id 1

:context 1

(Although not shown here, the request may of course also need to contain time or date information if the request is relevant to a specific time or date.) The intermediary takes the confirmed model ( 1 .2 above) , adds 1 to the WorkersDayOff field and uses it as the proposed model:

2.2 Proposed model: {ListOfEmployees{all Employeelnfo}

WorkersDayOff = 1 WorkersOvertime = 1 }

The intermediary 3 now checks the proposed model against the relevant local and global rules 7b, 3c. The rule for taking a day off is that 2 employees need to be doing overtime before a person can take a day off .

2.3 Rule: if (WorkersDayOff * 2 < WorkersOvertime) DayOff = true

Else

DayOff = false The proposed model fails the rule so the request is refused and the proposed model abandoned. The refuse message below is sent to all the resource interfaces 5.

2.4 Refuse Message: (Refuse

:sender Intermediary receiver PatAgent

:content :ActionContent :effect Ken is an Employee who is seeking day off

:ReasonContent: Fact is we are 2 short of ^' overtime' volunteers.

:id 2 :context 1

Ken's resource interface 5 will make the message available via the GUI 5c.

Ken's resource profile may have a rule that in the event of a refuse message on a question of a day off, the resource interface 5 should resubmit the request after a fixed time period. Alternatively, the GUI 5c can be used to enter that information on receipt of the refuse message. The other resource interfaces 5, on receipt of the refuse message will read the "ReasonContent" part of the refusal and, on reviewing the rules in their resource profiles 5b, may then issue a message to the intermediary 3 for at least two reasons. The resource profile 5b may for instance include a rule to request overtime in the event of receiving any message indicating that overtime is available. Alternatively, the resource profile 5b may include a rule to request overtime in the event of receiving a refuse message against a day off request which identifies Ken or Ken's resource interface. This latter rule type provides strong flexibility in the system with respect to individual operators.

2.5 Simple Rule

If (ReasonContent = ??? short of ^* overtime' volunteers) Then (evaluateOvertimeRequest) Evaluation of the overtime request may mean for example reviewing the real time record 5d of current commitments for a resource against the resource profile 5b in order to see whether the resource is already committed to overtime and whether the resource has a rule to do or not to do overtime in respect of "Ken". Depending on the outcome of the evaluation, the other resource interfaces 5 can either ignore the message or request overtime. This can either be done automatically or on confirmation via a GUI 5c by the relevant employee. In the case that the outcome of the evaluation indicates that overtime should be offered, a request is sent to the intermediary 3.

2.5 Overtime Request

(Request

:sender MelAgent receiver Intermediary xontent :effect Mel is an Employee seeking overtime

:id 3 ontext 1

The intermediary 3 again generates a proposed model which will now be as follows:

2.6 Proposed model: {ListOfEmployees{all Employeelnfo} WorkersDayOff = 0

WorkersOvertime = 2}

The new proposed model will now be found to satisfy the rule for overtime. The intermediary 3 agrees to the overtime and the following message is sent to the other employees.

2.7 Accept Message (Agree :sender Intermediary receiver PatAgent

:content :ActionContent :Effect Mel is an Employee seeking overtime

:PreconditionContent Done :id 4 xontext 1

The intermediary 3 now loads the proposed model as the current confirmed model which becomes:

2.8 New Confirmed Model

{ListOfEmployees{all Employeelnfo} WorkersDayOff = 0

WorkersOvertime = 2}

The original resource interface 5 (for Ken) can evaluate from the accept message that there is an increased chance of a day off . Ken's resource interface 5 (either automatically or by getting validation from a user) can then resubmit the original request for overtime. This time the request will be accepted.

In a system acting for resources instead of operatives of resources, an equivalent scenario for the one given above might arise for example where a self- diagnostic resource has detected an increased rate of faults occurring and issues notice of a requirement for (effectively a "request for") downtime so that it can reboot. If the requirement for downtime is then refused, only resource interfaces for resources which can offer equivalent functionality might then be triggered to offer increased processing capacity, enabling the faulty resource to go offline.

3. Local Rules

A second function of the intermediary 3 is to receive and validate local rules against global rules. This allows a team manager to add or modify a rule. The manager's interface 7 provides a GUI which allows pre-existing local rules 7b to be manipulated by pull down menus. For example, there may a preexisting rule that "x" people need do overtime for "y" people to take a day off, where x and y can be changed by the manager. (Where the resource interfaces 5 are acting directly for resources, an equivalent rule might arise for instance where there's a need for a fixed amount of spare processing capacity to be available at all times. A request by a resource to use capacity for running a standby process instead of an allocated task might then be controlled by a local rule determining the relevant level of spare processing capacity in the team.) In order to change the rule, the manager changes x or y and submits the new rule. The GUI submits the new rule in the form of a request as follows.

3.1 New Rule Request (Request :sender PatAgent receiver Intermediary

:content :effect OvertimeRule dayOff y Overtime x :id 1

:context 2 )

The intermediary 3 reviews the request against the stored global rules 3c. If the outcome of the review is positive, the local rule 7b for that manager's team is changed.

3.2 Modified Rule if (WorkersDayOff * x < WorkersOvertime*y) DayOff = true Else DayOff = false

The intermediary will also send an agreement message to the GUI for the relevant manager. 3.3 Agreement Message

(Agree

:sender Intermediary receiver PatAgent

:content :ActionContent :Effect OvertimeRule dayOff y Overtime x :PreconditionContent Done :id 2 ontext 2

If a completely new rule is required, it is possible for the GUI to offer the manager free text input, such as "only give Fred days off" . Alternatively, the GUI can offer a visual rule builder. A new rule request is then submitted by the GUI to the intermediary 3 as before.

3.4 New Rule Request (Request :sender PatAgent receiver Intermediary

:content :effect NewRule only give Fred days off :id 1 xontext 2 )

In this case, because the new rule has been entered in free text and is not a modified version of an existing rule type, available via a pull down menu, the intermediary 3 sends the new rule request to an interface 8 for a more senior manager for verification.

3.5 Rule Verification Request (Request :sender Intermediary receiver SeniorManager

:content :effect VerifyRule only give Fred days off :id 1 :context 2

The senior manager can then either refuse this rule or agree with it. If refusing, a refuse message is sent which the team manager's interface 7 makes available to the manager.

3.6 Rule Refusal Message

(Refuse

:sender SeniorManager receiver Intermediary

:content :ActionContent :effect VerifyRule only give Fred days off :ReasonContent Rule not legal. )

If on the other hand the rule is agreed then the Senior Manager via a user interface 8 will enter the rule as a new local rule 7b, in a machine understandable form, and send an agreement message to the manager.

3.6 Agreement and Installation of New Rule

(Agree

:sender SeniorManager receiver Intermediary

:content :ActionContent :Effect VerifyRule only give Fred days off

:PreconditionContent if (Fred = employee && request = dayoff) dayoff = true; else dayoff = false :id 3 :context 2

The new rule is added to the rule set and an agreement message is sent back to the originating manager.

It is available to a manager to include a rule in the local rule set 7b which triggers the intermediary 3 to send a message to the manager's interface 7 under certain conditions. For instance, if a resource is requesting more than a certain amount of downtime in a fixed period, or an operative is requesting more than a certain number of days off . The manager might then have the means to override the decision of the intermediary 3. A valuable aspect of this is that the manager alternatively might be able to detect trends reflecting the status of available resources for carrying out tasks and take appropriate action, such as bringing additional or substitute resources online.

Using the framework of messages between the interfaces 5 ,7,8, work co^¬ ordination applications can be built. These not only allow control at multiple levels of authority, but also inform people of what is happening, why it is happening, and how they can help other members of their team. Thus use of the system to support operatives also provides support for team building and social interaction processes in a distributed work team.

In the example given above, the availability data relates to operators. The system can equally well be used to support changes in machine or processing capacity. For instance, the OSS might load the system by providing data of the following type:

4. Setting up 4.1 Equipment details and capacity status

Eg Equipmentlnfo

{Computer: 1 43.1 99.1 23.456 computer address

Model description: desktop pc server | desktop pc ProcSpeedmaxstatus: 250MHz 0MHz I 250MHz | 500MHz Modemmaxstatus: 8Kbits/s 8Kbits/s I 32Kbits/s | 64Kbits/s Protocolstatus: ISDN;MIDI ISDN I MIDI RAMmaxstatus: 32 Mbytes 32 Mbytes | 64 Mbytes Hardmaxstatus: 7 Gbytes} 7 Gbytes | 1 4 Gbytes

This shows that for a desktop personal computer (pc) available to the system, the maximum processor speed available for applications to be run by the system is half the maximum available, the modem speed is badly reduced, the pc has ISDN and MIDI capability, the random access memory (RAM) is already half full and so is the hard disc.

Again, it may also be necessary that time or date information is provided so that availability information can be mapped against time or date. This could be provided to the intermediary 3 by the OSS 1 but might better be provided by the resource interfaces 5. (If the time or date information is provided by the resource interfaces 5 , each resource interface need only send capacity data to the intermediary 3 with respect to the dates/times at which capacity on its resource is available to the system.) The intermediary 3 then selects data with respect to availability of its resources in the light of tasks to be performed and forms an initial "confirmed availability model":

4.2 Confirmed model:

{ListOfEquipment{all Equipmentlnfo}

MIDIat64Kbits/s = 3 sum of MIDI PCs available at full modem speed

ISDNat32Kbits/s = 1 5 sum of ISDN PCs available at half modem speed

PCsatδOOMHz = 4} sum of PCs available at top processor speed

This particular availability model might be generated in the light of tasks involving downloading audio and music, and running major software applications. In order for the system to be enabled to respond in use on behalf of specific machines, the resource interfaces 5 again need to be loaded with respective resource profiles 5b. This can be done manually but it could also be done from the "Equipment details and capacity status" provided by the OSS 1 . Hence the resource interface 5 for a specific PC may have a profile loaded for that PC which shows that the PC is MIDI enabled, or has enabling software loaded for running a particular application.

5. The method for reallocating capacity away from the system

An operative may enter data to the resource interface 5 for a particular PC which indicates that the actual available modem speed of that PC is to be reduced, for instance because the same PC is to be used for downloading non-system data. Alternatively, the PC may itself generate the data as a result of technical changes occurring, such as a fault. The resource interface 5 uses its processing software 5a and message handler 5e to translate this into the following agent message and sends it to the intermediary 3 :

5.1 Request (Request

:sender 1 43.1 99.1 23.456Agent :receiver Intermediary ontent :effect 1 43.1 99.1 23.456 is a MIDI PC available at full modem speed whose speed is to be reduced :id 1 ontext 1 )

The intermediary takes the confirmed model (4.2 above), subtracts 1 from the MIDIat64Kbits/s field and uses it as the proposed model:

5.2 Proposed model: {ListOfEquipment{all Equipmentlnfo}

MIDIat64Kbits/s = 2 sum of MIDI PCs available at full modem speed ISDNat32Kbits/s = 1 5 sum of ISDN PCs available at half modem speed

PCsatδOOMHz = 4} sum of PCs available at top processor speed The intermediary 3 now checks the proposed model against relevant local and global rules 7b, 3c. It may be that the system can tolerate losing a MIDI-enabled link, at least temporarily, as long as an ISDN connection can replace it, for instance because music destined for download over a MIDI link can be downloaded in a different format over any ISDN link.

5.3.1 Rule: if (ISDNat32Kbits/s + MIDIat64Kbits/s > 1 7) MIDI = true Else

MIDI - false

The proposed model fails the rule so the request is refused and the proposed model abandoned. A refuse message is sent to all the resource interfaces 5. One of the resource interfaces may find, on looking at the resource profile it has stored against its resource, that the resource is MIDI-enabled and has a rule that, if a refuse message in respect of a MIDI enabled PC is received, it will withdraw from a non- system task so that it can effectively offer to add to the tally of "MIDIat64Kbits/s". Thus the resource interface for this resource will issue an offer message in much the same way as "Melagent" offers overtime in the operative-based example above. The intermediary will be triggered to generate a new proposed model and this time it will be found acceptable. The intermediary 3 notifies all the resource interfaces 5 and the resource interface 5 for the MIDI enabled PC which originally requested a speed reduction will successfully resubmit the request. It can thus be seen that the system can be used to co-ordinate availability of machine resources directly and in response to outputs of the resources in real time. Such a system, by using "refuse" and "offer" messages, effectively self-corrects within limits when capacity is lost.

A consequence of a refuse message in these circumstances might be that the work tasks actually have to be completely abandoned in the case that some capacity is lost, because a set of interdependent tasks as a whole is not going to be achievable. A system according to an embodiment of the present invention provides the advantage that this situation is effectively registered and a system can for instance close itself down gracefully and immediately in that event rather than pointlessly completing only some of the necessary tasks.

Referring to Figures 2, 5 and 6, in embodiments of the present invention, if a non-programmer is to control the behaviour and functionality of a software system effectively, the GUI preferably provides a highly responsive style of interaction (Burnett, Baker, and van Zee 1 995), in a manner similar to a spreadsheet.

The object is not so much the "window style" (in the sense of how it appears to a user) , but rather the idea of Visual Processing Languages (VPL) . The goals of VPL designers are to improve the programmer's ability to express program logic and to understand how the program works. These goals cannot be realised simply by switching from text to pictures. Instead the VPLs employed in embodiments of the present invention employ visual techniques to achieve one or more of the following preferable characteristics:

1 . Fewer concepts required to program. For example, in many VPLs the programmer does not deal with pointers, storage allocation, declarations, scope or variables.

2. Concrete programming process. In many VPLs the programmer can see, explore and change specific data values or even sample executions.

3. Explicit depiction of relationships. Constraint and dataflow diagrams are example techniques.

4. Immediate visual feedback. After a program edit, in many VPLs immediate display of updated results helps the programmer find errors sooner.

The system of the invention preferably provides immediate feedback regarding any effects of user actions, without going through a "compile" step. Nardi (Nardi 1 993) argues that, apart from immediate feedback, the system should communicate with the user in a language that is both task-oriented and visual. The power of such a language is its ability to externalise users' mental models of the control task (Mehandjiev 1 997)

Control at different levels of responsibility use different visual representations. For example there will be substantial differences between the GUI 5c for a resource interface 5 , which can be constructed as a form with a limited set of work preferences, and the visual language employed at the GUI 7c, 8c for a manager's interface 7a, 8a to control local rules and conflict resolution policies. This is similar to the layered approach to visual software control and visual programming advocated by Repenning and loannidou ( 1 997) . Whereas they use programming competency as the factor to determine the type of representations at each layer. However, the present invention preferably uses representations in a task-specific language which are determined by the type of task performed by people at different organisational levels.

At higher levels of managerial control the complexity and variety of control tasks will increase to an extent where a single representation is insufficient. A person will have to interact with several different representations depending on the type of control task they perform. A manager, for example, will need one type of representation to control business rules and another type of representation to control the team composition and preferences regarding type of work.

Facilities for integrating different representations into a unified control language with a high level of responsiveness are an important feature of this approach to building work co-ordination software. A worker based embodiment of the present invention is now described from the point of view of the representations available to the users, particularly the managers.

It deals with the domain of job scheduling for Customer Service Teams. Workers can request days off, overtime, and specify preferred task difficulty. They do this through a single representation, but the system is designed so that other representations can be added . Also, different representations can be used for different types of hardware, for example a worker can use a mobile phone, a palmtop computer or PC to interface with the system.

The team manager can control scheduling rules and constraints, and monitor the current team composition in terms of preferred task type, task difficulty, overtime and days off. Referring to Figure 6, in the example, the manager uses three different representations, which are tightly integrated together so that changes on one representation can immediately be seen on the screen in the other representations, and also notifications from the Intermediary. The system keeps users informed of the outcome of their and others' requests following the scenarios described earlier. It specifies reasons for rejection and suggests actions to help others. The system supports two main modes of communication: a mode of synchronous visual interaction between users and their resource interfaces, and asynchronous agent-based message passing and negotiation between the resource interfaces and the Intermediary. This is reflected by the components of the resource interfaces 5 and the intermediary 3 shown in Figures 3 and 4.

Users of the system (workers or managers) will interact using GUIs 5c specialized for the purposes of different control tasks. The user interactions with each window will be translated to commands for instance for changing work coordination preferences, which can be understood by the resource interface 5. The translation for each GUI 5c will be performed by a software module called "Translator" . Different pairs (GUI, translator) can be installed or selected for running to provide different representations and different levels of control at the GUIs 5c.

The resource interface 5 is a software agent which provides support for an individual user of the system, and maintains a local "Model" of their work and team preferences, including a list of "friends" . The manager and trusted third party interfaces 7,8 will have a different functionality than the resource interfaces 5 to provide a higher level of control.

Each interface 5,7,8 communicates with the " Intermediary" 3 using a FIPA- compliant wrapper (FIPA98) and ACL (agent communication language) as a standard language.

In different embodiments, the complexity of the proposed model and the process of determining if it is viable will vary. In some, the proposed model may be created by simple data transformations.

A simple example of forming a model, and of determining whether it is viable (i.e. is compatible with constraint data defining the workload), is for the model to have a register indicating "the number of workers taking overtime" . If a worker requests overtime then in the proposed model "the number of workers taking overtime" is one greater than "the number of workers taking overtime" in the confirmed model. Similarly, the model may have a register recording the number of workers asking for holiday.

The test of whether this is a model consistent with constraints may then just be "is the number of people taking overtime at least twice the number of people asking for holiday? " . In other words, the intermediary 3 employs a relatively simple threshold .

In more complex embodiments (for example in situations in which there are more complex constraints set by a local manager or the OSS) , the mechanism for generating models and/or testing the models against constraints may be more complex, for example involving an expert system such as the classic DENDRAL expert system, as described in the paper " DENDRAL and META: the application dimensions" by Buchanan and Feigenbaum . DENDRAL was directed to " mechanizing" scientific reasoning using artificial intelligence techniques, and in particular the generation of scientific hypotheses consistent with predetermined knowledge and experimental observations. The method included proposing candidate models (that is hypotheses) and testing whether they were consistent with the knowledge and experimental observations (which thus acted as constraints on the search space) . DENDRAL included a module CONGEN which performed this task. These algorithms can be adapted for use in the present invention, for example with management rules playing the role of scientific knowledge and inputs by operators playing the role of experimental observations. The proposed model in the present invention thus broadly corresponds to the proposed hypothesis of the DENDRAL approach . The approach presented here can be generalized in several directions. The architecture is capable of supporting different interfaces, so that for example touch- tone telephones can be used by customers to negotiate service times.

Differentiation between the different levels and types of control can be done at the level of the local resource interface 5 , so managers at different levels of authority may be connected to the system. For example higher levels of management may control scheduling policies and rules.

A domain in which embodiments of the present invention might usefully be applied is that of call centres. For example, the system can enable call centre staff to control call routing preferences and participate in scheduling their on-job training.

References

The following documents are referred to in the text above. Their disclosure is incorporated herein by reference. Buchanan and Feigenbaum (1978), DENDRAL and META-DENDRAL: their applications dimension, Artificial Intelligence, vol. 11, p 5-24.

Burnett, M. M., M. J. Baker, and P. van Zee (1995, March). Scaling up visual programming languages. IEEE Computer 28(3), 45. Dourish, P., J. Holmes, A. MacLean, P. Marqvardsen, and A. Zbyslaw

(1996, November). Freeflow: Mediating between representation and action in workflow systems. In ACM Computer Supported Cooperative Work. ACM.

FIPA98 1998, FIPA 98 Specifications, http:Wwww.fipa. org\

Jennings NR, Faratin P, Johnson MJ, O'Brien P, and Wiegand ME. 1996. Using intelligent agents to manage business processes. In Proceedings of the First International Conference on The Practical Application of Intelligent Agents and Multi- Agent Technology (PAAM96), London, UK. The Practical Application Company Ltd, pp 345-360.

Mehandjiev, N. (1997). User Enhanceability for Information Systems through Visual Languages. PhD thesis, Department of Computer Science, University of Hull, HULL HU67RX, England.

Nardi, B. A. (1993). A Small Matter of Programming: Perspectives on End User Computing. Cambridge, Massachusetts, USA: Massachusetts Institute of Technology. Repenning, A. and A. loannidou (1997, September). Behavior processors:

Layers between end-users and Java virtual machines. In Proceedings of VL'97. IEEE.

Rocco, E. (1998). Trust breaks down in electronic contexts but can be repaired by some initial face-to-face contact, Proceedings of CHI 98, April 1998.

Sachs, P. (1995, September). Transforming work: Collaboration, learning, and design. Communications of the ACM 38(9), 3644.

Swenson, K et al. A business process environment supporting collaborative planning. Journal of Collaborative Computing, 1(1): 15;34, March 1994.

Claims

. A method of supporting resource allocation for use in carrying out respective tasks which together fulfill one or more work requirements, each resource being provided with a resource interface, the method comprising: storing constraint definition data defining constraints on said allocation of resources; storing an initial data representation of resource availability; receiving at data processing means, from at least one of said resource interfaces, availability data concerning availability of a resource; generating a proposed data representation of resource availability, based on the initial data representation together with said availability data; determining whether said proposed data representation is compatible with said constraint definition data; in the case that said proposed data representation is compatible with said constraint definition data, substituting said proposed data representation for said initial data representation to generate a new initial data representation; and in the case that said proposed data representation is not compatible with said constraint definition data, transmitting a rejection signal to said at least one of said resource interfaces.

2. A method according to Claim 1 which further comprises: receiving at the data processing means, from at least one of said resource interfaces, further availability data concerning availability of a resource; generating a further proposed data representation of resource availability, based on the initial data representation together with said further availability data; determining whether said further proposed data representation is compatible with the constraint definition data; in the case that said further proposed data representation is compatible with said constraint definition data, substituting said further proposed data representation for said initial data representation to generate a new initial data representation; and in the case that said proposed data representation is not compatible with said constraint definition data, generating and transmitting a rejection signal to said at least one of said resource interfaces.

3. A method according to either one of the preceding claims, wherein, in the case that a proposed data representation is not compatible with said constraint definition data, the step of generating and transmitting a rejection signal to said at least one of said resource interfaces comprises generating and transmitting a rejection signal to a plurality of said resource interfaces.

4. A method according to any one of the preceding claims wherein at least one resource interface is provided with at least one resource profile, the resource profile comprising data in respect of a resource, the method further comprising the steps of : receiving at a resource interface a rejection signal; reviewing a resource profile provided with respect to that resource interface; and outputting availability data to the data processing means dependent on the outcome of the review.

5. A method according to Claim 4 wherein said resource profile comprises at least first and second data types in respect of a resource, the first data type comprising at least one resource attribute and the second data type comprising availability commitments of the resource.

6. A method according to either one of Claims 4 or 5 wherein the resource profile further comprises a priority indicator for at least one availability commitment of the resource, and wherein said step of reviewing a resource profile comprises reviewing the priority indicator.

7. A method according to any one of Claims 4, 5 or 6 wherein said rejection signal comprises an identifier for a selected resource, or for a selected set of resources, and wherein said steps of reviewing a resource profile and outputting availability data to the data processing means dependent on the outcome of the review comprise reviewing the resource profile for the presence of said identifier and outputting availability data only if said identifier is present.

8. A method according to any one of the preceding claims which further comprises, subsequent to generating and transmitting said rejection signal, triggering termination of tasks being carried out in respect of a common work requirement to which the rejection signal is related.

9. A method according to Claim 8 wherein said step of triggering termination is carried out after a predetermined time has elapsed during which no availability data has been received from a resource interface.

1 0. A method according to any one of the preceding claims wherein said constraint definition data comprises at least two sets of constraint definition data, and the method further comprises: receiving via a user interface a proposed modification to a first set of constraint definition data; reviewing the proposed modification against the second set of constraint definition data; in the case that the proposed modification is compatible with the second set, modifying the first set accordingly; and in the case that the proposed modification is not compatible with the second set, transmitting a rejection signal to the user interface.

1 1 . Apparatus for supporting resource allocation in carrying out respective tasks which together fulfill one or more work requirements, the apparatus comprising: an input for receiving communication signals from at least one resource interface; a constraint definition data store for storing data defining constraints on said allocation of resources; a data representation store for storing an initial data representation of resource availability and a proposed data representation of resource availability; and data processing means the apparatus being adapted, in use, to maintain an initial data representation in the data representation store, to receive an input from at least one resource interface comprising availability data concerning availability of a resource, to generate a proposed data representation of resource availability, to review the proposed data representation of resource availability against the constraints, and either to substitute the proposed data representation of resource availability for the initial data representation or to output a rejection message to at least one resource interface, dependent on the outcome of said review.

2. Apparatus according to Claim 1 1 wherein said constraint definition data store comprises means for storing at least two sets of constraint definition data, each set having at least one respective input, said apparatus having means for reviewing constraint data received at one input against constraint data received at another input, and means for either outputting a rejection message or for loading the received constraint data, in dependence on the outcome of the review.

3. Apparatus according to either one of claims 1 1 or 1 2 wherein each resource interface is provided with a profile store for storing at least one resource profile and, on receipt of a rejection message, each resource interface is adapted to review any resource profiles stored in its profile store and, in the event that a resource profile is identified as relevant to the rejection message, to transmit to the data processing means a signal containing availability data for the respective resource.

4. Apparatus according to Claim 1 3 wherein a resource profile comprises at least one data element and a rejection message comprises at least one data element, review of a resource profile comprising matching the data element from a rejection message against the data element or elements in a resource profile.

5. Resource allocation apparatus, for supporting allocation of resource units to carry out one or more respective tasks, the apparatus comprising: i) a signal input for receiving signals from a plurality of respective resource interfaces, one or more of said signals comprising constraint data with respect to at least one identified resource; ii) a constraint definition data store for storing data defining constraints on said allocation of resources; iii) means for using constraint data received from a resource interface to enter or change data in the constraint definition data store; iv) a notification signal output for outputting notification signals to at least one resource interface, each notification signal identifying at least one task for which resource is required; wherein one or more signals received at the signal input comprises a task acceptance signal from a resource interface and wherein the apparatus is adapted in use to respond to receipt of a task acceptance signal by reviewing the content of the constraint definition data store and, depending on the result of the review, to issue a further notification signal or to allocate resource to a task.

6. Resource allocation apparatus according to claim 1 5, wherein the signal input is also for receiving a management signal input from at least one management interface, one or more of said management signals comprising constraint data with respect to at least one resource, and the apparatus further comprises means for using constraint data received from a management interface to enter or change data in the constraint definition data store, and means to categorise data in the constraint definition data store according to source type, the apparatus being further adapted, on review of the content of the constraint definition data store, to resolve any conflict in constraint data relevant to a task acceptance signal according to its source type.

7. Apparatus according to claim 1 6 wherein data in the constraint definition data store is categorised by location in the store.

8. Apparatus according to either one of claims 1 6 or 1 7 wherein the apparatus is further adapted to store at least a third category of data in the constraint definition data store, the source of data in the third category being requirements of an operational support system for use in performing allocated task(s) .

9. A system for supporting resource allocation in carrying out respective tasks which together fulfill one or more work requirements, the system comprising: a data store for storing constraint definition data defining constraints on said allocation of resources; for each resource, a resource interface for inputting resource availability data; an intermediary for ' receiving said resource availability data, reviewing it against stored constraint definition data and transmitting a message dependent on the result of the review to at least one resource interface; at least one of said resource interfaces being provided with a resource specific data store, said resource interface being triggerable by receipt of such a result- dependent message to review its resource specific data store and to transmit resource availability data to the intermediary dependent on the outcome of the review; such that allocation of resources can be amended according to interaction between a resource interface and the intermediary, within limits determined by the constraint definition data.