WO2001006352A2

WO2001006352A2 - Enterprise system that incorporates business process life cycle management capabilities

Info

Publication number: WO2001006352A2
Application number: PCT/US2000/019132
Authority: WO
Inventors: Saytendra P. Rana; Vinkesh O. Mehta; Prasad E. Bandereddi
Original assignee: Exterprise, Inc.
Priority date: 1999-07-14
Filing date: 2000-07-13
Publication date: 2001-01-25
Also published as: WO2001006352A8; EP1203292A2

Abstract

An enterprise system including collaborative agents and incorporating business process life cycle management capabilities to provide a high degree of adaptation and evolution. The enterprise system is implemented on any computer network, such as any internet/intranet-based business process environment. A business process is implemented by nested sub-process and with dynamic collaboration among process agencies and proxy agents. Each sub-process of the business process is represented and managed by a process agency. Each person that participates is represented by an intelligent proxy agent that maintains the person's profile. The proxy agent participates in the process as a proxy for the person owning the agent, and provides a dynamic and adaptive GUI to enable the person to participate in the process at any desired level. Each person participates in various capacities, such as owner, participant, or initiator. Process-level communication allows process agencies and proxy agents to exchange service management information or service level agreements, perform escalations and notification, perform negotiations, and publish their capabilities. Meta-processes are provided for change management, risk management, and evolution.

Description

Title: Enterprise System That Incorporates Business Process Life Cycle

Management Capabilities

Field of the Invention:

The present invention relates to business process automation and systems for supporting business process life cycle management, and more particularly, to computer network business-process oriented enterprise software systems.

Description of Related Art:

Business processes are used in organizations to create understandable, repeatable and manageable structures for accomplishing end-to-end business functions. Organizations performing identical business functions may radically differ in their business processes and thereby have competitive advantages because of more efficient process structures. For example, the end-to-end process for customer support of one organization that has incorporated built-in service level objectives may be more responsive than another organization that is providing customer service primarily based on the skills of individual customer service representatives. As a mechanism for competitive differentiation, the business processes of an organization are part of its intellectual assets.

To stay competitive, business processes of an organization must evolve as the competitive landscape changes and new enabling technologies emerge. Internet, web and related technologies are not only creating new opportunities and threats for businesses but are making it an imperative that organizations continuously monitor the effectiveness of their business processes, learn from the accumulated experience, and rapidly evolve their processes. The business process enabling structures, if rigid and routine, are very limiting for the needs of internet savvy organizations. Current off-the-shelf enterprise software systems often embed some internet technology (IT)-oriented view of business process structures that they are intended to support. Deployment of such systems requires that organizations comply with them and supplement them with additional manual or automatic procedures. When two organizations use the same software system, neither has any competitive advantage over the other that can be attributed to the process automation software. Furthermore, the evolution of processes is severely constrained by the legacy of such off-the-shelf software systems.

Tool-kit oriented software systems allow an organization to realize their unique and proprietary processes by developing internal software systems. Such in-house development efforts are expensive and time-consuming and often reflect a point-in-time understanding of the overall business processes. Such tool-kit oriented software systems, lacking inherent capabilities for evolution, may provide a competitive advantage, but only for a limited duration. Eventually such tool-kit oriented software systems become as constraining as off- the-shelf systems. In several domains, e.g. document flow management, factory floor automation, etc., an enterprise process is often approximated by a workflow system in which the process is specified as a network of tasks, where each task is performed by a person or an automated system. The workflow system coordinates the routing of tasks based on the connectivity information provided in the task network. The task network may be static or created on-the- fly based on connectivity rules. Furthermore, in some systems, tasks may be defined on-the- fly and persons may be dynamically assigned to tasks. Workflow systems are limited, however, as lacking support of meta processes for life cycle management of management processes. Enterprise software system implementations may implicitly reflect a process but generally do not represent and store business processes as explicit information structures.

Due to the absence of any processes as concrete representations, processes cannot be analyzed, understood, manipulated, and evolved. This is particularly true for the existing systems described above.

Workflow management systems, when operating as business process management enabling systems, go beyond individual applications. Workflow management systems, however, are still primitive since such systems focus only on the lower level aspects of transaction and computation. Workflow systems deal with the execution control and information flow among well defined task-level entities.

At least one limitation of prior art enterprise software systems is a neglect of business process and system-wide concerns. Many enterprise systems either completely lack process- orientation, or treat processes from a low-level, task-oriented perspective that do not easily map to high-level business process concepts and concerns. Such enterprise systems are not amenable for life cycle management of processes.

The limitations of the enterprise systems described above, along with many other limitations of such enterprise software systems, are effectively overcome by the present invention.

Summary of the Present Invention:

An enterprise system according to the present invention manages and automates a business process which further comprises a plurality of nested sub-processes where each sub- process further includes roles and work to be performed by process participants. The enterprise system includes a plurality of process agencies and a plurality of proxy agents that dynamically collaborate to manage the business process during its life cycle.

Each process agency invokes and manages the operation of at least one associated sub-process by using service capability knowledge to decompose a service request into roles, by using process participant knowledge to negotiate and delegate roles to perform the sub- process and to monitor the status of delegated roles, and by using meta-processes to monitor and dynamically reconfigure the corresponding process agency and any associated sub- processes if necessary. Each proxy agent represents a corresponding participant to maintain participant capabilities and availability to negotiate with any of the plurality of process agencies to determine role assignments and to monitor and manage the status of any roles performed by the corresponding participant in any one or more of the sub-processes.

The enterprise system may further include a plurality of owner proxy agents where each owner proxy agent represents an owner of a corresponding process agency. Each owner proxy agent is used by a corresponding owner to define and modify the corresponding process agency. In this manner, the process agency utilizes the definitions provided via the owner proxy agent when establishing each service instance of a sub-process associated with the process agency. The owner may further manage, modify and control each sub-process via the corresponding owner proxy agent. For example, the owner proxy agent may be utilized to define entry and exit criteria for a corresponding process agency and any associated sub- processes. Further, the owner proxy agent may be utilized to define policies for the corresponding process agency and any associated sub-processes where such policies may include, for example, escalation, delegation and notification.

Any of the proxy agents may further comprise an initiator proxy agent that requests performance of a service instance of a sub-process. In this manner, each sub-process is initiated by a service request from either an initiator proxy agent or by another sub-process.

In one embodiment, a plurality of business objects may be utilized to perform application level services for the business process. Each sub-process invokes any of the plurality of business objects as often as necessary to perform the roles of the sub-process.

Each of the process agencies of the enterprise system may further include a service decomposition block, a service delegation block, a service monitoring block and a life cycle management block. The service decomposition block tracks current capabilities and decomposes service requests into roles. The service delegation block negotiates and delegates roles and exchanges service instance information. The service monitoring block monitors delegated services, performs reconfigurations, responds to escalations and logs measurement data of any associated sub-process. The life cycle management block provides an interface for the corresponding process agency and performs dynamic changes of the corresponding process agency as necessary.

Each process agency may further include a process agency state store and a service instance management block. The process agency state store stores the execution state of any associated sub-process service instances of the corresponding process agency. The service instance management block manages execution of any associated sub-processes and registers its capabilities with other process agencies.

Each process agency of the enterprise system may further include a service capability knowledge store, a process participants knowledge store, a service management knowledge store and a process configuration knowledge store. The service capability knowledge store stores information about any other of the plurality of process agencies and any proxy agents pertinent to the corresponding process agency. The process participants knowledge store stores information of capability and availability of process participants. The service management knowledge store stores policies of the corresponding process agency including an escalation policy, a delegation policy and a notification policy. The process configuration knowledge store stores configuration of the corresponding process agency.

Each of the proxy agents of the enterprise system may further include a model management block, a work management block and a role management block. The model management block maintains a participant profile and keeps track of assigned and authorized roles for the corresponding proxy agent. The work management block monitors and manages roles and work delegated to the corresponding participant and provides any notifications. The role management block shows reports and measurements and provides an interface for escalations and notifications. Each proxy agent may further include a proxy agent state store and a main role block.

The proxy agent state store stores the internal state of the corresponding proxy agent. The main role block provides a user interface with a corresponding participant and orchestrates other roles as necessary to coordinate with other proxy agents and any of the plurality of process agencies. Each proxy agent may further include a user knowledge store, a work assignment knowledge store and a roles knowledge store. The user knowledge store stores the participant profile of the corresponding participant. The work assignment knowledge store stores work-related information. The roles knowledge store stores role-related information. The work-related information stored in the work assignment knowledge store may further include a list of delegated work, a status of the work in progress and notifications to the corresponding participant. The participant profile may include identification, capabilities, availability and roles of the participant corresponding to the proxy agent.

An enterprise system according to the present invention is preferably implemented using a plurality of network computers where each proxy agent includes a graphic user interface executed on any one of the computers to enable access and control of the proxy agent to a corresponding participant. In one embodiment, owner proxy agents are included where each includes a GUI executed on any of the network computers to enable access control of the corresponding owner proxy agent. A collaborative agents-based system for initiating, executing and managing service instances of a sub-process of a business process according to the present invention includes a process knowledge store, a process participants store, a service knowledge store, a process agency and a plurality of proxy agents.

The process knowledge store maintains knowledge of the sub-processes. The process participants store maintains knowledge of each participant of the business process. The service knowledge store maintains current status of each service instance of the sub-process. The process agency utilizes knowledge from the process knowledge store and the process participants store to initiate, execute and manage each service instance of the sub-process. The process agency further builds a record of the new service instance in the service knowledge store. Each proxy agent interfaces the process agency to manage the roles and related work performed by the corresponding process participant.

At least one of the proxy agents may comprise a process initiator that requests initiation of a service instance of the sub-process. The system may further include a business object store that stores a plurality of business objects utilized to perform application services of the business process. A business object link is provided between the process agency and the business object store. The system may further include at least one external system that performs at least one activity of the sub-process. A process handoff agent is then provided between the process agency and any external systems. The system may further include a sub-process agency that enables negotiation and delegation of roles to another proxy agency. In this embodiment, an owner proxy agent may also be provided that is utilized to define and modify the process agency. Alternatively, the owner proxy agent may be utilized to define entry and exit criteria for the process agency and is further utilized to define policies for the process agency including escalation, delegation, and notification policies.

An agent-based enterprise system according to the present invention is executed on a network computer system and utilizes meta-processes in business process life cycle management of a business process comprising a plurality of nested sub-processes. The enterprise system includes a process specification agency, a process participant agency, a process execution system configuration agency, a service management agency, a resource mapping agency, a process execution agency and a process life cycle agency.

The process specification agency incorporates a plurality of process agencies each representing at least one corresponding sub-process of the business process. The process specification agency manages the sub-process of the business process. The process participant agency incorporates a plurality of proxy agents each representing a process participant of the business process. The process execution system configuration agency tracks system level configuration information about the network computer system. The service management agency tracks information necessary for initiating and controlling service instance executions. The resource mapping agency cooperates with the process specification agency and the process participant agency to track current information about each process participant's information. The process execution agency initiates and executes each service instance of each sub-process and orchestrates the operation of the process agencies and proxy agents. The process life cycle agency implements meta-processes for dynamic changes during the life cycle of the business process.

The agent-based enterprise system may further include a process definition knowledge store, a participants knowledge store, a system configuration knowledge store, a service levels and instance knowledge store, a process agents knowledge store, a process measurement store and a life cycle process knowledge store. The process execution agency may further include a platform agency, a process communication agency and a notification and monitoring agency. The platform agency manages the life cycles of the plurality of proxy agents and the plurality of process agencies. The process communication agency enables the plurality of proxy agents and plurality of process agencies to collaborate on business process management activities. The notification and monitoring agency provides for monitoring and escalation on behalf of any of the plurality of proxy agents and process agencies. The process execution agency may further include a process execution state store that maintains a state of the business process.

The platform agency may be capable of creating, modifying, activating, deactivating, suspending and leading each of the plurality of proxy agents and process agencies as necessary. The process communication agency may utilize a process communication language that provides high level messages and protocols to enable collaboration between the proxy agents and process agencies.

An enterprise system according to the present invention comprises a collaborative and intelligent agent-based technology that incorporates business process life cycle management capabilities. The present invention is particularly useful for the internet/intranet based business process environment in which a high degree of adaptation and evolution is an essential characteristic. In one embodiment, business processes and sub-processes are represented in a software system as autonomous intelligent entities. Each process of an overall business process, or sub-process, is represented in the system by an intelligent agent referred to as a process agency or simply as an agency. A process agency is responsible for managing all aspects, including the life cycle management, of the corresponding process.

Each person that participates in the business process is explicitly represented in the system by a corresponding intelligent proxy agent that maintains the person's profile. The proxy agent participates in the process as a proxy for the person owning the agent. The agent provides a dynamic and adaptive graphical user interface (GUI) to enable the owner to participate in the process. Each person may participate in the process in various capacities, such as, for example, a process owner, a process participant, and /or a process initiator. A business process is implemented by the dynamic collaboration among process agencies and proxy agents.

An intelligent agent platform is provided for dynamically creating, starting and executing process agencies and proxy agents. The agents are instantiated from their specifications retrieved from a persistent store, such as the memory of a computer system. The platform also provides for process life cycle event management for all agencies and proxy agents.

In one embodiment, a language is provided for process-level communication among process agencies and proxy agents, as opposed to task-level communication. The process communication level allows process agencies and proxy agents to exchange service management information or service level agreements, perform escalations and notifications, perform negotiations, and publish their capabilities.

Another embodiment of the invention provides for the rule-based specification of process agencies and proxy agents and for modifying these specifications at build or execution time. Agencies have a life time endowed from the process itself and extends beyond a run-time execution in the system. Likewise proxy agents have a life-time inherited from their owner's participation in the process.

In another embodiment, process-level concerns are separated from application or task level concerns by providing a clean interface between business objects and agents. This separation provides for enhancing an object-based enterprise software system to a business- process oriented system by snapping on process agencies and proxy agents on top of existing business objects. The same separation mechanisms work for dealing with process hand-off issues when extending the processes to external sub-systems.

In one embodiment, meta-level processes are provided for change management, risk management, and evolution. In this embodiment, the system provides for life-cycle management of processes by incorporating end-to-end business process effectiveness measurements as integral part of process agencies and by providing mechanisms for incrementally modifying policies and procedures.

Brief Description of the Drawings:

A better understanding of the present invention can be obtained when the following detailed description of the preferred embodiment is considered in conjunction with the following drawings. Figure 1 is a block diagram of an exemplary enterprise process system implemented according to an embodiment of the present invention.

Figure 2 is a block diagram of an exemplary collaborative agent-based model for execution of service instances within a business process.

Figure 3 is a block diagram of an exemplary meta-process architecture for business process life cycle management.

Figure 4 is a block diagram of the process execution agency of Figure 3. Figure 5 is a block diagram of an exemplary structure of a proxy agent. Figure 6 is a block diagram of an exemplary structure of a process agency. Figure 7 is a simplified block diagram illustrating a business process implementation and structure according to an embodiment of the present invention.

Detailed Description of the Preferred Embodiment(s):

Figure 1 is a block diagram illustrating an exemplary enteφrise process system 100 implemented according to an embodiment of the present invention. One or more process owners 101 each use a respective computer 102 to communicate with a computing system 108 of the enteφrise process system 100 via a network 107. Each process owner 101 is a person that performs any one or more of a plurality of functions, such as defining, manipulating, measuring, analyzing effectiveness, refining, etc. a corresponding process or sub-process of a business process. A business process is a set of procedures and policies to accomplish a business objective. A business objective is often broken into one or more types of service with corresponding service level objectives or agreements in context. The artifacts accompanying a service objective constitute the deliverables of a process. The services are initiated by service requests. Each process owner 101 can delegate some of these responsibilities to other persons, such as process participants 103 or process initiators 105, in accordance with meta-processes as further described below. As used herein, the term "process" refers to the overall business process and any processes invoked to perform the business process. Each process invoked to perform the overall business process may be referred to as a "sub-process" relative to the business process. Further, one or more processes may be invoked to perform a higher level process, so the that lower level processes are subordinate to the higher level process. Thus, the terms "process" and "sub-process" are used interchangeably, where the prefix "sub" is used to refer to a relative position of a process in a business process hierarchy. In this manner, the business process is represented by a hierarchy of sub-processes which may be referred to as nested sub-processes. The network 107 may comprise a single, local network, a large network or a plurality of small or large networks interconnected together. The network 107 may comprise any type or number of local area networks (LANs) broadband networks, wide area networks (WANs), etc. The network 107 may include the Internet or incoφorate portions thereof, such intranet(s), extranet(s), etc. Further, the network 107 may incoφorate one or more LANs, wireless portions and may incoφorate one or more of various protocols and architectures such as TCP/IP, Ethernet, ATM, etc. The network 107 may also incoφorate other types of public networks, such the public switch telephone network (PSTN) or the like.

The computing system 108 is a computing environment that includes one or more computers and database stores that are used by the enteφrise for recording and managing information pertaining to the life cycle of one or more business processes of the enteφrise. A "database store" is a "persistent" store, or simply a "store", that comprises any type of memory or memory system, such as comprising dynamic or static random access memory (RAM), read only memory (ROM) or the like, or any types of auxiliary or mass storage devices, such as disks, diskettes, magnetic tapes, CD- ROMs, etc. Any "store" (including persistent, database, etc.) described herein may be implemented as any type of memory or memory system. A business process life cycle management system 109 resides within the computing system 108 on top of a plurality of business objects 110 also residing in the computing system 108. The life cycle of a business process involves the definition, launch, execution, monitoring, measurement, analysis, refinement, and replacement of the business process. The life cycle activities of a business process are managed using meta processes such as change management, risk management, resource management, evolution management, etc. The process owner 101 is responsible for making most or all key decisions influencing the life cycle of the business processes in the system 109 and for determining potential process participants 103 and process initiators 105. A process participant 103 is a person that participates in some capacity during the performance of a process or sub-process by taking responsibility for one or more action items arising out of a service instance. A service instance is the representation of the end-to-end execution of an individual service request within a process context. A process participant 103 engages in a process as the performer of one or more "roles". A process role is a view of process activities from an individual process participant's perspective. Alternatively, a role is a logically related set of activities performed by the same process participant 103 within the context of a process. Process roles may be nested where a higher level is described as a collection of lower level roles. The lowest level roles are not split further without significantly impacting the process, and thus are usually assigned to the same person.

A service instance in a process is in operation when process participants 103 are all performing their roles in the process. A process initiator 105 is a person or entity that provides a trigger for the start of a new service instance of a process. A profile for a process initiator 105 may influence the goals for the service instance. In a similar manner as described above for the process owners 101, the process participants 103 and process initiators 105 each use a respective computer 102 to communicate with the computing system 108 of the enteφrise via a network 107. The computers 102 are any type of computer or computing device, such as desktops, portables, notebooks, handheld devices, PDA's etc., that have communication capabilities for coupling to the network 107 for interfacing the computing system 108. It is noted that any number of computers 102 may be utilized, typically one for each person involved in the business process. A given computer may also serve multiple purposes and functions corresponding to the roles or functions of its user, such as a process owner who also serves as a participant or initiator or a process participant who also serves as an initiator, etc.

Figure 2 is a block diagram depicting an exemplary collaborative agent-based approach for execution of service instances within a business process. This collaborative agent-based approach provides a realization of business processes within a computational environment for enabling execution and management of the business processes. Collaborative agents provide a responsive, proactive, highly flexible and adaptable environment in which to realize life cycle management capabilities of each business process. In one embodiment, a proxy agent is a persistent and intelligent software entity that uniquely and explicitly represents a process owner 101, a process participant 103 or a process initiator 105 in the system. A separate proxy agent called a process owner agent 201 is provided for each of the process owners 101. The process owner agent 201 may reside, or otherwise be executed on, the computer 102 of the process owner 101 or in the computing system 108 of the enteφrise process system 100. The Process Owner Agent 201 is semi- autonomous and acts either independently on behalf of process owner 101 or in concert with process owner 101 to collaborate with a process agency 206 to engage in process life cycle management activities for defining, modifying, refining, etc. the process agency 206. In one embodiment, a process agency is a persistent and intelligent software entity that uniquely and explicitly represents a process in the system and facilitates the processing of all life cycle events for the process in question. The process agency 206 keeps knowledge about a corresponding process in a process knowledge store 202 and knowledge about process participants 103 in a process participants knowledge store 209. In a similar manner, a process participant agent 204 is a proxy agent that is provided for each process participant 103. Each process participant agent 204 collaborates with its corresponding process participant 103 and the process agency 206 to provide the performance of roles for which the process participant 103 is responsible. The process participant agent 204 is responsible for showing a list of pending activities, status of activities in progress, extending necessary GUIs for performing the pending activities and for serving notifications by a selectable mechanism to the process participant 103.

In a similar manner, a process initiator agent 208 is a proxy agent that is provided for each process initiator 105. Each process initiator agent 208 acts as an intermediary between a corresponding process initiator 105 and the process agency 206. A process initiator 105 requests the performance of a service instance through a GUI extended to process initiator 105 by the coπesponding process initiator agent 208. The request is received by the process agency 206, which initiates the new service instance using the knowledge kept in a process knowledge store 202 and builds a record of the new service instance in a service knowledge store 210. The current status of the service instance is also stored in the service knowledge store 210.

The process agency 206, while executing a service instance, interacts with, and if necessary, activates all proxy agents using information from the process participants knowledge store 209 and any process agencies, such as a sub-process agency 203 using information from the process knowledge store 202. The process agency 206 also invokes any of a plurality of business objects in business objects store 213 via a business object link 202 as needed during the performance of a service instance. Finally, the process agency 206 collaborates with a process hand-off agent 211 whenever service instance execution requires some activities to be performed externally by any external systems 212. Figure 3 is a block diagram illustrating an intelligent agent-based structure 300 for realizing meta-processes in business process life cycle management, which uses an expanded view of the knowledge stores shown in Figure 2. A process life cycle processes knowledge store 301 keeps information about the meta-processes, which is entered and modified through a process life-cycle agency 302. A process definition knowledge store 307 keeps information about the business processes. A process specification agency 303 enters and modifies information in the process definition knowledge store 307. A process participant agency 304 keeps profile information about each of the process participants 103 in process participants knowledge store 308. Such profile information may include, for example, identification, job- functions, roles, skills, availability, etc., for each process participant 103. A resource mapping agency 311 integrates the profile information from the process participants knowledge store 308 with information from the process definition knowledge store 307 to produce information stored in a process agents knowledge store 312. The process agents knowledge store 312 always maintains current information about who is available for participation in any process and in what role.

A system configuration knowledge store 309 keeps information about system level configuration that influences the execution of service instances within the computer system 108, as determined and tracked by a process execution system configuration agency 305. A process execution agency 313 provides the necessary platform for execution of service instances of processes. The process execution agency 313 also produces measurements information that is entered in a process measurements store 314, which information is used by the process life cycle agency 302 to monitor and analyze the effectiveness of business processes. A service levels and instance knowledge store 310 keeps all information necessary for initiating and controlling service instance executions by the process execution agency 313. The information in the service levels and instance knowledge store 310 is entered and modified by a service management agency 306. The process life-cycle agency 302 collaborates with the agencies 303, 304, 305, and 306 to provide implementation of all meta processes such as change management, risk management, resource management, service management, evolution, and performance management.

Figure 4 is a block diagram of a high level overview of an exemplary structure of the process execution agency 313. The process execution agency 313 orchestrates process agencies 405 and proxy agents 403 and uses and implements core agent platform services for the puφose. A platform agency 401 manages the life cycle of the process agencies 405 and the proxy agents 403. The process agencies 405 and the proxy agents 403 are created, activated, de-activated, suspended, or deleted all using the services of platform agency 401. The proxy agents 403 are similar to and correspond with any of the agents 201, 204 and 208 of Figure 2. The process agencies 405 are similar to and correspond with the process agency 206.

During the execution of a service instance after creation and activation, the proxy agents 403 and the process agencies 405 communicate among each other using a Process Communication Language (PCL) using the services of a process communication agency 404. The process communication agency 404 provides high-level messages and protocols that allow the proxy agents 403 and the process agencies 405 to collaborate on business process management activities. A process execution state store 402 maintains the state of process at all times and is updated by the proxy agents 403 and the process agencies 405. A notification/ monitoring agency 406 provides for monitoring and escalation on behalf of the process agencies 405 and the proxy agents 403.

Figure 5 is a block diagram of an exemplary structure of a proxy agent 500, which represents any of the process agents 201, 204, 208 or 403. The particular functions of proxy agent 500 may depend upon whether it is operating as a process owner, a process participant or a process initiator. A process initiator agent may be a process participant agent that requests or otherwise causes a service instance of a process to be invoked. A process owner agent may also be a process participant agent for the owned process or any other process. The internal state of the proxy agent 500 is stored in a proxy agent state store 502. The information in the proxy agent state store 502 is read and updated by a user main role 501. The user main role 501 provides for a top level user interface for the corresponding process participant, such as GUIs or the like, and orchestrates other roles as needed, such as a user model management role 503, a user work management role 504 and a user role management role 505, to coordinate interaction with the process participant and any process agencies. The user model management role 503 allows a user to configure the proxy agent's behavior by specifying preferences, capabilities and availability. The user model management role 503 maintains a user profile in the user knowledge store 506. A user is either an owner, a participant or an initiator depending upon the particular function being performed. The user model management role 503 also keeps track of which roles the user is assigned or authorized to perform in the overall processes.

The user work management role 504 in the proxy agent 500 keeps track of the work for which the user is responsible. Work includes any activities, functions, tasks, messages, etc. related to or otherwise associated with one or more corresponding roles. Through the user work management role 504, the user receives or views a list of all work that has been delegated to it, can accept, delegate or re-route work to others and can receive alerts and notifications as part of process management activities. The user work management role 504 gets work related information from a work assignment knowledge store 507. In one embodiment, only an owner proxy agent for a given process is authorized to delegate or re- route roles or work. Alternatively, the owner may authorize delegation powers to a participant, or a participant may have delegation authority by default. In the later case, it is desirable that the owner of a process be notified of any work delegated or re-routed by a participant of the process.

The user participates in one or more processes essentially through process specific roles exposed to the user by the user role management role 505. The user role management role 505 also shows reports and measurements relevant to the process roles to the user as required. The roles knowledge is maintained in a roles knowledge store 508.

Figure 6 is a block diagram illustrating the internal structure of an exemplary process agency 600. The process agency 600 represents any of the process agencies 206, 405 previously described. Each process agency 600 is responsible for managing the execution of all service instances initiated for a corresponding process. A service instance management role 601 is responsible for negotiating and accepting service instance requests from process initiator agents or other process agencies and stores the execution state of the process in a process agency state store 602. The service instance management role 601 orchestrates the actions in other supporting roles including a service decomposition role 603, a service delegation role 604, a service monitoring role 605 and a life cycle management role 606 for the puφose of achieving service level objectives of service instances of the coπesponding process. The service instance management role 601 is also responsible for regularly registering its capabilities to other higher level process agencies. When a new service instance request is accepted or refined after an escalation, the service decomposition role 603 gets activated and refines and decomposes the service instance request into smaller requests that can be delegated to other process agencies or proxy agents. In order to do so, the service decomposition role 603 uses the service capability knowledge of other process agencies and proxy agents pertinent to the particular process, as stored in a service capability knowledge store 607.

After the service decomposition is performed, service assignment is performed by the service delegation role 604, which is responsible for contacting, negotiating service level objectives, and transferring all service instance information to any and all applicable proxy agents or process agencies. In order to do so, the service delegation role 604 refers to information stored in a process participants knowledge store 608.

As soon as a service instance is delegated, the service monitoring role 605 begins tracking and responds to escalation and service level management issues by either redirecting the request to the service decomposition role 603 for alternative approach or by performing escalations as determined by service management policies. The behavior in the service monitoring role 605 is governed by policies in a service management knowledge store 609. Such policies may include, for example, entry and exit criteria, an escalation policy, a delegation policy, a notification policy, an abort policy, etc. The Service monitoring role 605 also produces pertinent measurements data for life-cycle management processes. The life cycle management role 606 in the process agency provides for necessary interface with meta-processes for life-cycle management. In particular, through this interface, the process agency 600 may be dynamically re-configured by updating information in a process configuration knowledge store 610. Figure 7 is a simplified block diagram illustrating a business process implementation and structure. One or more persons utilize an application software program (not shown) to develop a business process 701 to achieve a business objective. The application program may be executed on any type of computer system, such as the computer system 102, and includes an appropriate GUI interface to facilitate the business process definition and implementation. The application software is written to enable complete flexibility for defining the business process 701 including any sub-processes and roles to be performed to achieve the business objective. In one embodiment, a plurality of templates may be provided to facilitate the definition of various processes or roles that are associated with particular types of business processes.

As shown in Figure 7, the business process 701 is ultimately performed by a series of sub-processes 703, 705, 707 and 709, where the sub-process 703 is further performed by sub- processes 711 and 713. A business process agency 715 is also established to facilitate definition and management of the business process 701. A process owner, such as any of the process owners 101, utilizes an owners proxy agent 717 to define, manage and control the business process agency 715 and to ultimately control the business process 701. The process owner 101 also defines a plurality of process agencies 720, 722, 724, 726 and 728 that are used to manage and control the service instances of sub-processes invoked to perform the business process 701, such as the sub-processes 703, 705, 707, 709, 711 and 713. The process owner 101 may further define a plurality of owner proxy agents 730, 732, 734, 736, 738 to control the corresponding process agencies 720 - 728, respectively.

The process owner 101 of the business process 701 interfaces an appropriate GUI associated with the owner proxy agent 717 to interface the business process agency 715 to instantiate or invoke the business process 701. The process owner 101 may further request, via the owner proxy agent 717, a service instance of a process associated with the process agency 720, which in this case is the sub-process 703. Alternatively, once the business process 701 is invoked, the business process agency 715 may operate autonomously to request that the process agency 720 invoke the sub-process 703. An owner of the process agency 720 may be involved in the service request and negotiation via the owner proxy agent 730. However, the owner of the process agency 720 may have established and defined processes associated with the process agency 720, including any and all appropriate policies to enable the process agency 720 to operate autonomously.

The sub-process 703, as controlled by the process agency 720 and possibly by an owner via the owner proxy agent 730, determines that at least two other sub-processes 711 and 713 must be invoked to perform the sub-process 703. The sub-process 703 also determines that one or more participants are necessary to perform the sub-process 703. In a similar manner as previously described, the sub-process 703 requests a service instance of the sub-process 711 via the process agency 726 and requests an instance of the sub-process 713 via the process agency 728. Again, the corresponding owners may participate in the negotiation via corresponding owner proxy agents 736 and 738, respectively. Further, management and control of the sub-processes 711 and 713 may be performed autonomously by the process agencies 726 and 728, respectively, although the corresponding owners may participate via the owner proxy agents 736 and 738. The sub-process 703 also determines that one or more roles must be performed by each of one or more participants. In the example shown, the sub-process 703 negotiates with two participants via coπesponding participant proxy agents 740 and 742. In a similar manner, the sub-process 711 determines that two participants are necessary and negotiates with the participants via participant proxy agents 744 and 746 to perform the necessary roles for the sub-process 711. Also, the sub-process 713 negotiates with the participant proxy agent 746 and another participant proxy agent 748 to perform the roles necessary to perform the sub-process 713.

The process owner 101 may further request instantiation of the sub-process 705 via the process agency 722 either alone or as controlled by the corresponding process owner 732. In the example shown, however, the participant proxy agent 742 also serves as a process initiator to request an instance of the sub-process 705. While performing roles for the sub- process 703, the participant proxy agent 742, acting on behalf of its coπesponding participant, requests that the process agency 722 invoke an instance of the sub-process 705. The process agency 722, as established by the owner proxy agent 732, invokes the sub- process 705 and negotiates with one or more participants to perform corresponding roles in a similar manner as previously described. As shown, the process agency 722 and/or the sub- process 705 negotiates with participant proxy agents 750 and 752 to delegate roles to be performed by the coπesponding participants. The sub-process 707 may also be invoked by the process owner 101 or the business process agency 715. In the example shown, however, the sub-process 707 is initiated by the process agency 724 in response to a request by the sub-process 705. The sub-process 707 then negotiates with the participant proxy agent 752 to perform the roles associated with the sub-process 707. Also in the example shown, either the sub-process 705 or the sub-process 707 requests the process agency 724 to invoke another sub-process 709. In this case, the sub- processes 707 and 709 are instantiations of the same process type via the process agency 724. It is noted, however, that the sub-processes 707 and 709 may be dynamically changed and altered during the respective life cycles by the process agency 724 and/or the owner of the processes via the owner proxy agent 734. Thus, the sub-processes 707 and 709 may ultimately have different roles or functions associated therewith, where the particular roles would usually be performed by different participants. The sub-process 709, via the process agency 724, negotiates with participants to perform its respective roles. As shown, the sub- process 709 negotiates with the participant proxy agent 752 and another participant proxy agent 754 to have its roles performed by corresponding participants in a similar manner as previously described.

During operation of the business process 701, the participant associated with the participant proxy agent 752 may determine that they are unable to perform all of the roles required to complete the sub-process 709. In one embodiment, the participant proxy agent 752 may negotiate and delegate any one or more roles for the sub-process 709 to any other capable participant. As shown by the dashed line 760, the participant proxy agent 752 negotiates and delegates roles it is performing for the sub-process 709 to the participant associated with the participant proxy agent 748. Such a change in role performance, however, should be reported to the sub-process 709 and/or the process agency 724 to ensure proper management.

In an alternative embodiment, the participant proxy agent 752 negotiates with the sub- process 709 to delegate one or more of its roles for the sub-process 709 to another participant. In this case as shown by a dashed line 762, the sub-process 709 negotiates with the participant proxy agent 748 to transfer one or more roles from the participant proxy agent 752 to the participant proxy agent 748.

An exemplary sub-process of an overall business process is now described. In particular, an E-Campaign marketing process includes a Campaign Launch Process which is a sub-process of the overall E-Campaign process. The Campaign Launch Process handles the E-Campaign process after an initial setup has been completed. The actual campaign and its launch schedule are managed in the Campaign Launch Process sub-process.

Entry criteria is first defined including a list of activities or tasks that must be completed or specified in order to initiate the Campaign Launch Process. In particular, the following entry criteria is described:

Email Lists have been set up.

Customer Segments have been set up.

Campaign Newsletters have been set up.

Campaign Showrooms have been set up.

Value Elements and related Content have been set up.

Value Categories and Channels have been set up.

Value Mapping Policies have been specified.

An exit criteria is also defined to establish the end of the Campaign Launch Process. In this example, the exit criteria occurs when the campaign is approved and a launch schedule is set up.

A set of default or initial policies are also established that are defined for the

Campaign Launch Process and any sub-processes associated therewith. These policies may include an escalation policy, a delegation policy, a notification policy, and an abort policy.

Exemplary policies are as follows: Escalation Policy - If Set up campaign has failed, notify assignor and mgrx@qwerty.com. Delegation Policy - If role assignee does not accept the assigned task within 24 hours, reassign. Notification Policy - If role assignee is not done in 3 days, ask the assignee for status and, if no reply, reassign.

Abort Policy - If abort request comes in, abort after current process roles complete.

A few sub-processes are defined for the Campaign Launch Process of the E-

Campaign marketing process. Each sub-process further has a plurality of roles defined for each of the sub-processes. In this example, the following sub-processes Setup Campaign and

Launch Campaign are defined for the Campaign Launch Process: Setup Campaign

Define Campaign

Associate Customer Segments to Campaign Associate Newsletter to Segments Associate Showroom to Segments

Set up Measurements

Launch Campaign

Review Campaign If role assignee has not completed task in 1 day, ask the assignee for status and, if no reply, escalate. Set up Launch Schedule

It is noted that a notification policy is further defined for the Review Campaign role of the

Launch Campaign sub-process. Also, one or more job functions are defined for participants in the Campaign Launch

Process including Campaign Manager and Campaign Administrator as described below:

Campaign Manager

/^♦Process Roles*/ Define Campaign Review Campaign

Campaign Administrator /^♦Process Roles*/

Set up Measurements Set up Launch Schedule

In a similar manner as previously described, the sub-processes Setup Campaign and Launch Campaign are invoked and negotiate with a plurality of users as participants depending upon the capabilities and availabilities of the prospective participants. For example, a particular user may be given the Campaign Manager job function and thus perform Define Campaign and Review Campaign roles for the Campaign Launch Process.

It is now appreciated that a system and method according to the present invention explicitly represents and creates a business process as an entity that can be measured, manipulated, and refined. The present invention recognizes that people are integral part of all processes, whether the processes are automated or not. Thus, the profile and behavior of the people involved in the process (process participants) are explicitly modeled, so that the people involved and the associated factors are taken into consideration during process execution. People aspects are incoφorated as integral aspects to thereby achieve an effective process automation system. The present invention allows active entities to be defined that serve as proxies for persons in the system and provides dynamic and configurable interfaces for their owners.

The present invention further allows for the integration of end-to-end service level objectives and ensures that these objectives are achieved at the process or at service execution level. A clean separation of business logic and functionality from process level concerns is achieved and capabilities for incremental process evolution and process management is provided.

A system according to the present invention allows users to capture business process concepts as well as business participants models directly into the systems as adaptive, dynamic and active entities that can change and evolve as changes occur in the business processes, participants behavior, and business process environment. A system according to the present invention provides a process entity that not only coordinates the activities in the process, but that also deals with issues pertaining to process escalation, handoffs, integration, negotiation, end-to-end service level agreements and objectives. These issues are handled while also maintaining a clean separation from the lower level business logic of performing the activities or tasks associated with the process.

In some embodiments, meta-processes are incoφorated that serve to monitor, measure, change and evolve business processes implemented by the system. An owner or manager is able to create a business process object with its own meta-level methods and properties. Meta-processes that operate on business processes themselves, such as change management and risk management processes auxiliary to the project management process, are supported to ensure proper life cycle management of the business processes.

Although a system and method according to the present invention has been described in connection with the preferred embodiment, it is not intended to be limited to the specific form set forth herein, but on the contrary, it is intended to cover such alternatives, modifications, and equivalents, as can be reasonably included within the spirit and scope of the invention as defined by the appended claims.

Claims

Claims:

1. An enteφrise system for managing and automating a business process comprising nested sub-processes, each sub-process further comprising roles and work to be performed by process participants, the enteφrise system comprising: a plurality of process agencies, each that invokes and manages operation of at least one associated sub-process by using service capability knowledge to decompose a service request for each associated sub-process into roles, by using process participant knowledge to negotiate and delegate the roles to perform each associated sub-process, to monitor status of delegated roles, and by using meta processes to monitor and dynamically reconfigure the corresponding process agency and any associated sub-processes, if necessary; a plurality of proxy agents, each representing a corresponding participant, that maintains participant capabilities and availability, that negotiates with any of the plurality of process agencies to determine role assignments for the corresponding participant, and that monitors and manages status of any roles performed by the corresponding participant in any one or more of the sub-processes; and the process agencies and proxy agents dynamically collaborating to manage the business process during its life cycle.

2. The enteφrise system of claim 1, further comprising: a plurality of owner proxy agents, each representing an owner of a corresponding process agency, and each being utilized to define and modify the coπesponding process agency.

3. The enteφrise system of claim 2, further comprising: each owner proxy agent utilized to define entry and exit criteria for the corresponding process agency and any associated sub-processes; and each owner proxy agent utilized to define policies for the corresponding process agency and any associated sub-process, including escalation, delegation and notification policies.

4. The enteφrise system of claim 1, further comprising: at least one of the plurality of proxy agents comprising an initiator proxy agent that requests performance of a service instance of a sub-process; and each sub-process initiated by a service request from either an initiator proxy agent or by another sub-process.

5. The enteφrise system of claim 1, further comprising: a plurality of business objects that are utilized to perform application level services for the business process; and each sub-processes invoking any of the plurality of business objects as often as necessary to perform the roles of the sub-process.

6. The enteφrise system of claim 1, each of the plurality of process agencies further comprising: a service decomposition block that tracks current capabilities and that decomposes service requests into roles; a service delegation block that negotiates and delegates roles and that exchanges service instance information; a service monitoring block that monitors delegated services, that performs reconfigurations, that responds to escalations and that logs measurement data of any associated sub-processes; and a life cycle management block that provides an interface for the corresponding process agency and that performs dynamic changes of the corresponding process agency as necessary.

7. The enteφrise system of claim 6, each of the plurality of process agencies further comprising: a process agency state store that stores the execution state of any associated sub- process service instances of the corresponding process agency; and a service instance management block, interfacing the process agency state store and the service decomposition, delegation, monitoring, and life cycle management blocks, that manages execution of any associated sub-processes including negotiating service instance requests and that registers capabilities of the coπesponding process agency with other process agencies.

8. The enteφrise system of claim 6, each of the plurality of process agencies further comprising: a service capability knowledge store, utilized by the service decomposition block, that stores information about any other of the plurality of process agencies and any proxy agents pertinent to the corresponding process agency; a process participants knowledge store, utilized by the service delegation block, that stores information of capability and availability of process participants; a service management knowledge store, utilized by the service monitoring block, that stores policies of the corresponding process agency including an escalation policy, a delegation policy, and a notification policy; and a process configuration knowledge store, utilized by the life cycle management block, that stores configuration of the corresponding process agency.

9. The enteφrise system of claim 1, each of the plurality of proxy agents further comprising: a model management block that maintains a participant profile and that keeps track of assigned and authorized roles; a work management block that monitors and manages roles and work delegated to the corresponding participant and that provides any notifications; and a role management block that shows reports and measurements and that provides an interface for escalations and notifications.

10. The enteφrise system of claim 9, further comprising: a plurality of business objects; and wherein the role management block further automates access to the plurality of business objects.

11. The enteφrise system of claim 9, each of the plurality of proxy agents further comprising: a proxy agent state store that stores an internal state of a corresponding proxy agent; and a main role block, interfacing the proxy agent state store and the model, work and role management blocks, that provides a user interface for the coπesponding participant and that orchestrates other roles as necessary to coordinate with other proxy agents and any of the plurality of process agencies.

12. The enteφrise system of claim 9, further comprising: a user knowledge store, utilized by the model management block, that stores the participant profile of the corresponding participant; a work assignment knowledge store, utilized by the work management block, that stores work related information; and a roles knowledge store, utilized by the role management block, that stores role related information.

13. The enteφrise system of claim 12, the work related information comprising: a list of delegated work; a status of work in progress; and notifications to the corresponding participant.

14. The enteφrise system of claim 9, wherein the participant profile includes identification, capabilities, availability and roles of the corresponding participant.

15. The enteφrise system of claim 1, further comprising: a plurality of networked computers; and each of the plurality of proxy agents including a graphic user interface (GUI), executed on any one of the plurality of networked computers, that enables access and control of the corresponding proxy agent by the corresponding participant.

16. The enteφrise system of claim 15, further comprising: a plurality of owner proxy agents, each that is utilized to define and modify the corresponding process agency and any associated sub-processes; and each of the plurality of owner proxy agents including a GUI, executed on any one of the plurality of networked computers, that enables access and control of the coπesponding owner proxy agent.

17. An enteφrise system, comprising: a business process agency that defines a business process by defining a plurality of sub-processes and roles for each of the sub-processes, that establishes relationships between the plurality of sub-processes, and that dynamically interfaces the plurality of sub-processes to implement any modifications during the life cycle of the business process; a plurality of process agencies, each that invokes and manages operation of a corresponding sub-process by using service capability knowledge to decompose a service request for the sub-process into roles, by using process participant knowledge to negotiate and delegate for roles to perform the sub-process, and by using meta processes capable of monitoring and dynamically reconfiguring the sub-process, if necessary; a plurality of proxy agents, each representing a corresponding process participant, that maintains participant knowledge and capabilities, that negotiates with any of the plurality of process agencies to determine role assignments for the corresponding process participant, and that is capable of monitoring and managing status of any roles performed by the process participant in any of the sub-processes; and the business process agency, the plurality of process agencies and the plurality of proxy agents dynamically collaborating to manage the business process during its life cycle.

18. The enteφrise system of claim 17, further comprising: a plurality of owner proxy agents, each representing an owner of at least one sub- process, and each being utilized to define and modify the coπesponding sub-processes.

19. The enteφrise system of claim 18, further comprising: each owner proxy agent utilized to define entry and exit criteria for a coπesponding process agency and any associated sub-processes; and each owner proxy agent utilized to define policies for the coπesponding process agency and any associated sub-process, including escalation, delegation and notification policies.

20. The enteφrise system of claim 17, further comprising: a plurality of business objects that are utilized to perform application level services for the business process; and each of the plurality of sub-processes invoking any of the plurality of business objects as often as necessary to perform the coπesponding sub-process.

21. The enteφrise system of claim 17, each of the plurality of process agencies further comprising: a service decomposition block that tracks current capabilities and that decomposes service requests into roles; a service delegation block that negotiates and delegates roles and that exchanges service instance information; a service monitoring block that monitors delegated services, that performs reconfigurations, that responds to escalations and that logs measurement data of any of the plurality of sub-processes; and a life cycle management block that provides an interface for the corresponding process agency and that performs dynamic changes of the coπesponding process agency as necessary.

22. The enteφrise system of claim 21, each of the plurality of process agencies further comprising: a process agency state store that stores the execution state of any corresponding sub- process; and a service instance management block, interfacing the process agency state store and the service decomposition, delegation, monitoring, and life cycle management blocks, that manages execution of corresponding ones of the plurality of sub-processes and that registers capabilities of the coπesponding process agency with other process agencies.

23. The enteφrise system of claim 21, further comprising: a service capability knowledge store; a process participants knowledge store; a service management knowledge store; and a process configuration knowledge store.

24. The enteφrise system of claim 17, each of the plurality of proxy agents further comprising: a model management block that maintains a participant profile and that keeps track of assigned and authorized roles; a work management block that monitors and manages roles and work delegated to the coπesponding participant and that provides any notifications; and a role management block that shows reports and measurements and that provides an interface for escalations and notifications.

25. The enteφrise system of claim 24, each of the plurality of proxy agents further comprising: a proxy agent state store that stores an internal state of a coπesponding proxy agent; and a main role block, interfacing the proxy agent state store and the model, work and role management blocks, that provides for top level user interface for the coπesponding participant and that orchestrates other roles as necessary to coordinate with other proxy agents and any of the plurality of process agencies.

26. The enteφrise system of claim 24, further comprising: a user knowledge store that stores the participant profile of the coπesponding participant; a work assignment knowledge store that stores work related information; and a roles knowledge store that stores role related information.

27. The enteφrise system of claim 17, further comprising: a plurality of networked computers; and each of the plurality of proxy agents including a graphic user interface (GUI), executed on any one of the plurality of networked computers, that enables access and control of the coπesponding proxy agent by the corresponding participant.

28. The enteφrise system of claim 27, further comprising: a plurality of owner proxy agents, each that is utilized to define and modify a corresponding sub-process; and each of the plurality of owner proxy agents including a GUI, executed on any one of the plurality of networked computers, that enables access and control of the coπesponding owner proxy agent.

29. A collaborative agents-based system for initiating, executing and managing service instances of a sub-process of a business process, comprising: a process knowledge store that maintains knowledge of the sub-process; a process participant store that maintains knowledge of each participant of the business process; a service knowledge store that maintains cuπent status of each service instance of the sub-process; a process agency, interfacing the process knowledge store, the process participant store and the service knowledge store, that utilizes knowledge from the process knowledge store and the process participant store to initiate, execute and manage each service instance of the sub-process, and that builds a record of the new service instance in the service knowledge store; and a plurality of participant proxy agents, each interfacing the process agency to manage the roles and related work performed by a corresponding process participant.

30. The system of claim 29, further comprising: one of the plurality of participant proxy agents comprising a process initiator that requests initiation of a service instance of the sub-process.

31. The system of claim 29, further comprising: a business object store that stores a plurality of business objects that are utilized to perform application services of the business process; and a business object link provided between the process agency and the business object store.

32. The system of claim 29, further comprising: at least one external system that performs at least one activity of the sub-process; and a process hand-off agent provided between the process agency and the at least one external system.

33. The system of claim 29, further comprising: a sub-process agency, interfacing the process agency, that enables negotiation and delegation of roles to another proxy agency.

34. The system of claim 33, further comprising: an owner proxy agent, interfacing the process agency, that is utilized to define and modify the process agency.

35. The system of claim 33, further comprising: an owner proxy agent, interfacing the process agency, that is utilized to define entry and exit criteria for the process agency and that is utilized to define policies for the process agency, including escalation, delegation and notification policies.

36. An agent-based enteφrise system, for execution by a networked computer system, that utilizes meta processes in business process life cycle management of a business process comprising a plurality of nested sub-processes, the enteφrise system comprising: a process specification agency that incoφorates a plurality of process agencies, each representing at least one corresponding sub-process of the business process, to manage the sub-processes of the business process; a process participant agency that incoφorates a plurality of proxy agents, each representing a process participant of the business process, to track information about each process participant of the business process; a process execution system configuration agency that tracks system level configuration information about the networked computer system; a service management agency that tracks information necessary for initiating and controlling service instance executions; a resource mapping agency that cooperates with the process specification agency and the process participant agency to track current information about each process participant's information; a process execution agency that initiates and executes each service instance of each sub-process of the business process, and that orchestrates the process agencies and the proxy agents; and a process life cycle agency that collaborates with the process specification agency, the process participant agency, the process execution system configuration agency and the service management agency to implement meta processes for dynamic changes during the life cycle of the business process.

37. The enteφrise system of claim 36, further comprising: a process definition knowledge store, interfacing the resource mapping agency, that maintains information of each sub-process of the business process as entered and modified by the process specification agency; a participants knowledge store, interfacing the resource mapping agency, that maintains information of each process participant including capabilities, roles, authorizations and availability information as entered and modified by the process participant agency; a system configuration knowledge store, interfacing the process execution agency, that maintains system level configuration information about the networked computer system as entered and modified by the process execution system configuration agency; a service levels and instance knowledge store, interfacing the process execution agency, that maintains information necessary for initiating and controlling service instance executions as entered and modified by the service management agency; a process agents knowledge store, interfacing the process execution agency, that maintains cuπent information about each process participant's availability and roles as entered and modified by the resource mapping agency; a process measurements store, interfacing the process life cycle agency, that maintains information about the effectiveness of business process operation as entered and modified by the process execution agency; and a life cycle process knowledge store that maintains information about meta processes for dynamic changes of the business process as entered and modified by the process life cycle agency.

38. The enteφrise system of claim 36, the process execution agency further comprising: a platform agency that manages life cycles of the plurality of proxy agents and the plurality of process agencies; a process communication agency that enables the plurality of proxy agents and the plurality of process agencies to collaborate on business process management activities; and a notification and monitoring agency that provides for monitoring and escalation on behalf of any of the plurality of proxy agents and the plurality of process agencies.

39. The enteφrise system of claim 38, the process execution agency further comprising: a process execution state store, interfacing the plurality of proxy agents and the plurality of process agencies, that maintains a state of the business process.

40. The enteφrise system of claim 38, the platform agency capable of creating, modifying, activating, deactivating, suspending and deleting each of the plurality of proxy agents and the plurality of process agencies as necessary.

41. The enteφrise system of claim 38, the process communication agency utilizing a process communication language that provides high-level messages and protocols to enable collaboration between proxy agents and process agencies.