Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q10/00—Administration; Management
  • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling

Definitions

• 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.
• a method of supporting resource allocation in carrying out respective tasks which together fulfill one or more work requirements 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.
• 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
• 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.
• an equipment resource may itself enter availability data at the resource interface, generated for instance simply by failing or going offline.
• 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,
• 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.
• 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.
• 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.
• 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.
• 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) .
• 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) .
• the method further comprises storing, so as to be modifiable via a resource interface, data which is resource specific.
• 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.
• 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 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• a system for supporting resource allocation in carrying out respective tasks which together fulfill one or more work requirements 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.
• 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 ;
• Figure 6 shows a PC window displaying intermediary information in the embodiment of Figure 1 .
• the system includes an operational support system (OSS) 1 , such as a billing and work scheduling system .
• OSS operational support 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.
• Each operative is provided with an intelligent resource interface 5.
• Each team has a manager, who is also supplied with an intelligent interface 7.
• there is an intelligent "trusted third party" interface 8 for use by a third party in arbitrating for instance between operatives and managers.
• 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.
• data 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.
• the intermediary agent 3 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.
• the intermediary 3 passes the result back to the OSS 1 for use in its next 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.
• 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.
• 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.
• a particular strength of embodiments of the present invention lies in the provision of 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.
• 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.
• 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
• GUIs graphical use interfaces
• 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.
• the resource interface processes 5c may in practice be loaded on respective PCs 5c.
• 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 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.
• 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.
• ACL Agent Communication Language
• 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.
• 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 .
• ACL Agent Communication Language
• 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.
• 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:
• 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.
• 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":
• 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.
• 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:
• 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:
• 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 .
• 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.
• 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.
• 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.
• 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".
• 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.
• the intermediary 3 again generates a proposed model which will now be as follows:
• 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.
• the intermediary 3 now loads the proposed model as the current confirmed model which becomes:
• 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.
• 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.
• 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.)
• 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.
• 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.
• the intermediary will also send an agreement message to the GUI for the relevant manager.
• Agreement Message
• GUI can offer the manager free text input, such as "only give Fred days off” .
• GUI can offer a visual rule builder.
• a new rule request is then submitted by the GUI to the intermediary 3 as before.
• the intermediary 3 sends the new rule request to an interface 8 for a more senior manager for verification.
• 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.
• 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.
• the new rule is added to the rule set and an agreement message is sent back to the originating manager.
• a 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.
• the availability data relates to operators.
• the system can equally well be used to support changes in machine or processing capacity.
• the OSS might load the system by providing data of the following type:
• 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":
• 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.
• 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 .
• 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.
• 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.
• 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 :
• the intermediary takes the confirmed model (4.2 above), subtracts 1 from the MIDIat64Kbits/s field and uses it as the proposed model:
• 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.
• 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".
• 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.
• the GUI preferably provides a highly responsive style of interaction (Burnett, Baker, and van Zee 1 995), in a manner similar to a spreadsheet.
• VPL Visual Processing Languages
• 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.
• GUI 5c for a resource interface 5 which can be constructed as a form with a limited set of work preferences
• 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) .
• Repenning and loannidou 1 997) .
• 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.
• 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.
• 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.
• 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.
• GUIs 5c 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.
• FIPA98 FIPA- compliant wrapper
• ACL agent communication language
• the complexity of the proposed model and the process of determining if it is viable will vary.
• 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 intermediary 3 employs a relatively simple threshold .
• 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.
• 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.
• the system can enable call centre staff to control call routing preferences and participate in scheduling their on-job training.

Landscapes

• Engineering & Computer Science (AREA)
• Business, Economics & Management (AREA)
• Human Resources & Organizations (AREA)
• Strategic Management (AREA)
• Economics (AREA)
• Entrepreneurship & Innovation (AREA)
• Educational Administration (AREA)
• Game Theory and Decision Science (AREA)
• Development Economics (AREA)
• Marketing (AREA)
• Operations Research (AREA)
• Quality & Reliability (AREA)
• Tourism & Hospitality (AREA)
• Physics & Mathematics (AREA)
• General Business, Economics & Management (AREA)
• General Physics & Mathematics (AREA)
• Theoretical Computer Science (AREA)
• Multi Processors (AREA)

Priority Applications (1)

Applications Claiming Priority (4)

Publications (1)

Family

ID=8241689

Family Applications (1)

Country Status (3)

Cited By (1)

Families Citing this family (7)

Family Cites Families (2)

• 2000
  • 2000-10-23 EP EP00971565A patent/EP1226497A1/de not_active Withdrawn
  • 2000-10-23 AU AU10404/01A patent/AU1040401A/en not_active Abandoned
  • 2000-10-23 WO PCT/GB2000/004095 patent/WO2001029663A1/en active Application Filing

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events