WO2001075747A1

WO2001075747A1 - Workflow processes method and system

Info

Publication number: WO2001075747A1
Application number: PCT/US2001/040404
Authority: WO
Inventors: Amy Beard
Original assignee: Siebel Systems, Inc.
Priority date: 2000-03-31
Filing date: 2001-03-30
Publication date: 2001-10-11
Also published as: EP1277155A1; AU2001255823A1

Abstract

Methods and systems for the systematic analysis and evaluation of the operation of an organization to enforce proper business practices and adherence to business processes and procedures. The effect is to maintain the efficiency and productivity of employees and organizations. The methods and systems are characterized by having the capability for monitoring a business process having linked procedures to realize a business objective. This is done by defining the business process by enumerating steps within the business process. The steps are logically linked. The steps are chosen from the group consisting of inputs, where an input defines the conditions to be met to initiate a business process; tasks, where a task is an activity that must be executed as part of a process; decision points, where a decision point is a point where a work item will branch off to different steps, and where each branch has one or more conditions that must be met for a piece of work to follow the branch and subprocesses. The business process is monitored by initiating a process instance; tracking process instances and work items in the process instance; and initiating a step instance.

Description

WORKFLOW PROCESSES METHOD AND SYSTEM

FIELD OF THE INVENTION

The invention relates to methods and systems for the systematic analysis and evaluation of the operation of an organization to enforce proper business practices and adherence to business processes and procedures. The effect is to maintain the efficiency and productivity of employees and organizations.

BACKGROUND

In a modern, multi-divisional, multi-national enterprise, providing products and services through multiple channel organizations, it is absolutely essential to support and enforce the business process. Support for process driven enterprise workflow monitoring, management, and control has become an increasingly critical issue when selecting an enterprise relationship management application. This becomes especially critical in a business environment characterized by one or more of low employee experience levels, low employee training, high employee turnover, large spans of control, many employees performing the same or related tasks, combines a business process of a sequence of processes that must be performed sequentially, according to a defined business process. Management, referred to herein as "end users", want the ability to define their enterprise business processes at increasing levels of granularity and detail using a visual tool. End-users then want the system to automatically enforce these business processes.

There is a clear need for an open, flexible workflow engine and method for supporting the creation and enforcement of these business processes. The end user should be able to enter the business processes using a graphical user interface. The workflow engine should support such diverse business processes as call center workflow, workflow associated with .COM applications, workflow spanning multiple systems, embedding business processes that have already been defined into new business processes, and management of work in process.

It is becoming increasingly critical to embed workflow technology within the front office and eBusiness applications. Most business processes are initiated from front office and eBusiness applications. By embedding the workflow technology within these applications, the processes are easier to administer and are more closely bound to the applications.

SUMMARY

The method and system of the invention provides an open, flexible workflow engine for supporting the creation and enforcement of these business processes. According to the method and system of the invention, an end user, as a member of management or management's IS team, is able to enter the business processes using a graphical user interface. The workflow engine supports diverse, multi-task, multi-thread business processes across various lines of business and multiple enterprises.

The invention described herein provides a system and method for modeling and/or monitoring a business process characterized by having linked procedures to realize a business objective. The method includes defining the business process by enumerating the steps within the business process. These steps are logically linked, and include one (1) start, where a start defines the conditions to be met to initiate a business process, and one or more of the following: (2) tasks, where a task is an activity that must be executed as part of a process, (3) decision points, where a decision point is a point where a work item will branch off to different steps, with each branch having one or more conditions that must be met for a piece of work to follow the branch, (4) subprocesses, where a subprocess is a previously defined business process, and (5) exceptions, where an exception is the handling of an unexpected condition. The invention further includes managing and/or monitoring the business process. This is done by (i) initiating a process instance; (ii) tracking process instances and work items in the process instance; and (iii) initiating a step instance. The tasks can include notifications, inserts, updates, deletions, report generations, assignments, integration message requests, server tasks, and custom actions.

The business process can be instantiated by an event that the user defines in the system. Examples of the types of events that a user could define include inserting a new record, updating a record, a button on the user interface, a hyperlink on a web page, an inbound email and inbound integration messages. Business processes can also be instantiated by an external system.

An example of instantiating a business process from an event would be the creation of a new service request by an employee or customer. A user may have defined a business process for managing service requests that includes assigning the service request to a service representative, sending an email with a reference number to the contact, and creating an activity for the service request. In this example, the user defines an event of New Service Request and the result of the event would be to instantiate the business process for managing service requests. When a new service request is created, the business process is invoked and automatically performed by the system.

Each of the steps in the above example are defined as tasks in the business process. The first task will assign the service request to a service representative, the second will send an email, and the third will generate an activity.

FIGURES

The invention is illustrated in the FIGURES attached hereto.

FIGURE 1 is an overview of the elements of the "Process Definition" and "Workflow Manager" processes of the enterprise workflow modeling and management method and system of the invention.

FIGURE 2 is a flow chart of the method of the invention showing the states and state transitions. FIGURE 3 is a screen shot of the definition of an event that will invoke a process.

FIGURE 4 is an illustration of the method and system of the invention for entering a service request into the system and processing the service request through the system.

FIGURE 5 is an illustration of the process for invoking a new service request by the event defined in the view of FIGURE 3 and illustrated in FIGURE 4.

FIGURE 6 is a screen shoot of the flow chart of the process for assigning a subprocess called in the service request process of FIGURES 3, 4, and 5.

FIGURE 7 is an illustration of the initiation of the method and system of the invention by entering an order into the system.

FIGURE 8 is an illustration of tools used to create a business model, as the create order business model.

OVERVIEW The method and system of the invention is a business process and workflow management tool that enforces the business process, tracks workflow, and is task and mission responsive.

The system and method of our invention break the business process down into granular "elements" as shown in FIGURES 1 and 2. FIGURE 1 is an overview of the logical elements of the "Process Definition" and "Workflow Manager" processes of the enterprise workflow modeling and management method and system of the invention. As shown in FIGURE 1, the business definition starts by defining steps, such as sub- processes, inputs, tasks, or decision points, which call for either a user intentioned action or an automated action. Such actions include notifications, operations, reports, assignments, external object interfaces, server tasks, and external programs, among other. FIGURE 2 is a flow chart of the method of the invention showing the information flows, the states, and the state transitions. To be noted are the various dynamic, batch, and interactive inputs to initialization, as well as the server component. This causes the work item to be processed, which, in turn calls a reevaluation of the instance, and executing the process. Numerous instances of feedback call for starting the process definition, and, through executing the task, an action agent, an action callback, and a timer. The state space diagram shows interacting, shared, and coupled feedback loops that closely couple inputs, processes, and outputs.

FIGURE 3 is a screen shot of the definition of an event, while FIGURE 4 is a flow chart illustrating the initiation of the method and system of the invention by the initiating event shown in the screen shot of FIGURE 3, that is, by entering a new service request. FIGURE 5 is an illustration of the process of invoking a new service request and FIGURE 6 is a screen shot of the flow chart for assigning a new sub- process within the process of FIGURES 3, 4, and 5.

FIGURE 7 is a flow chart illustrating the initiation of the method and system of the invention by entering an order into the system. With the service request, an assignment is made, the priority is assigned, action is taken based on the priority, and an action is taken based on local resolution or escalation. For the new order, shown in FIGURE 5, the order information is collected, customer information is either retrieved from or entered into the database, the creditworthiness determined, and the action completed based upon credit worthiness.

FIGURE 8 is an illustration of tools and a graphical user interface used to create a business model.

The method and system of the invention provide a logical framework that enables monitoring, modeling, and managing the business process and a system for modeling, monitoring, and managing the business process. DETAILED DESCRIPTION

A business process is made up of individual elements that logically and sequentially interact with each other to accomplish a business purpose. The systems and methods for effectuating this interaction are shown in FIGURES 1 and 2.

FIGURE 1 is a hierarchical overview of the business process. As shown in FIGURE 1, the business process, 1, is associated with operational objectives and business relationships. A business process, 1, is a set of one or more linked procedures, which collectively realize a business objective. An example of a business process, 1 , is managing a new service request or an order entry. A business process, 1 , is associated to one and only one business object in the method and system of our invention.

A process definition, 11, is the representation of a business process, 1. A process definition, 11, is comprised one or more steps, 21. The steps, 21, indicate when a business process, 1, starts and ends, and information about individual activities within the business process, 1.

A step, 21, is an activity within a business process, 1. Steps, 21, are logically linked together to create a process definition, 11. A step, 21, is either an input, 22, a task. 23, a decision point, 25, or a sub-process, 27.

One type of step, 21, is a sub-process, 27. A sub-process, 27, is a business process. 1, that has been embedded into another business process, 1, as part of the process definition, 11. A sub-process, 27, has its own process definition. A sub-process, 27, is a type of step, 21. There can be one or more sub-process, 27, steps, 21 , in a process definition, 11.

An input, 22, is another type of step, 21. An input, 22, defines the conditions that must be met in order to initiate an instance of a business process, 1. When the conditions have been met, the process, 1, instance is initiated. There is one and only one input step, 22, per process definition, 1 1. A task, 23, is another type of step, 21. A task, 23, defines an activity that should be executed as part of the process definition, 11. A task, 23, is either a user interaction task, 31 , which involves manual interaction, or an automated task, 33, which is performed by the system. There can be one or more task steps, 23, in a process definition, 11.

A decision point, 25, is still another type of step. A decision point, 25, is a step, 21, in the process definition, 1 1, where the work item will branch off to different steps, 21, depending on a set of conditions. A decision point, 25, consists of all possible branches for that point in the business process. Each branch consists of one or more conditions that must be met in order for a piece of work to follow that branch in the process definition, 11. There can be one or more decision point steps in a process definition, 11. A decision branch is a possible outcome of a decision point, 25. A decision branch can have one or more conditions. A decision branch will be followed by a step, 21 , in the process definition, 11. If all of the conditions for the decision branch are met, the work item will proceed to the step following the decision branch.

A user interaction, 41, is a type of task, 23. A user interaction task, 41, requires manual intervention in order for the step, 21, to be complete. A user interaction task, 41, consists of sending a work item to one or more inboxes, and ensuring that the work item is handled appropriately.

By way of contrast with a user interaction task, 41, an automated task, 43, is a type of task consisting of one or more actions that the system will automatically perform when an automated task step, 41 , is reached in the business process, 1.

Actions, 51, are programs, as single programs, that the system will execute. One or more actions, 51, make up an automated task. An action can be an operation, 53, a notification, 55, a report, 57, an assignment, 59, an external object interface, 61, a server task, 63, or an external program, 65. An operation, 53, is an insert, update, or delete to a business component record or field. Business object logic applies to all operations, 53.

A notification, 55, is a type of action. A notification, 55, is an email, page, fax, or message broadcast to a user or contact. Likewise, a report, 57, is a type of action. A report, 57, action will generate a report, 57, and send it to a user, contact or printer. An assignment, 59, is a type of action that assigns one or more employees or positions to an object.

An external object interface, 61, is a type of action that allows customers to pass data to and from an external application. Another type of task is a server task, 63, that will start or stop a task on the server. An external program, 65 is a type of action that will launch an executable.

The workflow manager, 71, is the engine that will manage the business process instances. The workflow manager, 71, will track the process instances and the work item(s) in the process instance.

Closely related is the process instance, 73. A process instance, 73, is the instance of a business process, 1, that has been initiated. A process instance, 73, is initiated when the input conditions for a process definition have been met. A process instance consists of one or more step instances. A process instance contains one or more work items.

A step instance, 75, is the instance of a process definition step that has been initiated. An input step is initiated when all conditions defined for the input step have been met. A decision point step is initiated when all conditions for a decision branch have been met. All other steps are initiated when the previous step has completed.

A work item is the representation of the work that is being processed in the context of a step within a process instance. A work item is an instance of a business object. Use of enterprise workflow can vary from a simple process, such as entering a product order, to a complex process such as managing call center workflow. Complex processes can be comprised of multiple smaller processes.

The state diagram of FIGURE 2 further elucidates the architecture of the method and system of the invention through the information relationships and the process flow:

The business process begins with an external entity requesting the engine to initialize 311 and process a work item. The external entity can be a server component, 301 , or a dynamic, 303, or batch, 305, or interactive, 307, request. The work item causes the workflow manager engine to evaluate and re-evaluate, 321 , existing process definitions and currently running instances for the work item, if necessary to add to the queue of instances to be processed, by starting the definitions, 315, and execute, 321, the steps in the process necessary to execute the particular task, 327.

During instance execution, 323, a sub-process may need to be initiated, 331, for example, by starting the task definition, 315. This results in looping back to evaluate this sub-process definition, 335, for example, for necessary process definitions and process instances. In one embodiment, when, during instance execution, an instance may become blocked waiting for a task to complete, the task is paused, and when the task completes, the engine resumes the blocked instance.

A timer, 341, keeps track of all the instances that have a maximum or required duration. When that time is reached, it signals the engine to reevaluate the instance, 321.

The workflow manager server, including one or more elements of FIGURE 2, is preferably a multi-threaded server that services requests from client programs such as thick clients, an object manager or web server or application server, for example, for thin clients, 117, a Server Request Processor, 1 15, (on behalf of mobile clients), and the Workflow Monitor, 111. When clients use a Server Request Manager, 113, to submit requests, the workload planning server can take advantage of automatic load balancing, queuing and other Server features. When a client program sends a request for a given item (e.g. a Service Request), the Workflow Manager Server reads data from the database tables, evaluates the Business Process Definitions for potential new invocations, evaluates existing Process Instances for the object, and maintains the Step Instances in both cases.

For purposes of illustration, some business processes are illustrated below. For example, the event that initiates the service request has the screen representation shown in FIGURE 3, while the process for a new service request is shown in FIGURE 4. The FIGURE shows the steps and decision points that are involved when a new service request comes into the organization. The steps and decision points are displayed in the diagram in such a way that the flow of work is clear.

A user enters the business process as shown in FIGURE 4. Each step is interpreted as follows:

New Service Request, 401 is the input that initiates the process instance. The work item is the new service request.

Assign Service Request, 403, is an automated task. Siebel will assign the service request to the appropriate agent based on the assignment rules. The service request will appear in the agent's inbox.

SR Priority?, 405, is a decision point. The service request priority will determine the next step in the process instance, either a message broadcast, 407, or direct to solve the service request, 409.

Send Message Broadcast, 407, is an automated task. If the service request priority is high, the system will send a message broadcast to the agent that has been assigned ownership.

Solve SR, 409, is a user interaction task. Once the SR has been assigned and routed to an agent's inbox, the agent is responsible for resolving the service request. SR Resolved, 41 1, is another decision point. The decision point may have a duration associated to it. If the service request has been resolved within the duration, the service request will follow the "Yes" flow, 412, to send a confirmation, 413. If the service request has not been resolved within the duration, the service request will follow the "No" flow, 412, to an escalation 415.

Send Confirmation Solution, 413, is an automated task. When the service request reaches this step in the process instance, the system will send an email with the solution to the contact.

Escalate, 415, is sub-process. When the system reaches this step in the process instance, the system launches into another business process. The Escalate business process will take the service request and escalate it to another agent or manager.

FIGURE 5 is a screen shot of the process for invoking a new service request by the event shown in FIGURE 3 and having the flow chart shown in FIGURE 4. FIGURE 6 is a screen shot of the "Assign Service Request" subprocess initiated in the process shown in FIGURES 3-6.

The diagram for a Create Order business process is shown in FIGURE 7. Each step of the Create Order business process would be interpreted as follows:

Create Order, 501, is the input that initiates the process instance.

Collect Order Info, 503, is a user interaction task. The agent collects the information needed to create the order.

Existing Customer?, 505, is a decision point. The outcome will determine if the user should enter a new customer or do a credit check. Enter New Customer, 507, is a sub-process entered if the customer is not an existing customer. Enter New Customer, 507, contains launches the process definition for entering a new customer into the system.

Send and Receive Credit Check, 509, is an automated task. Send and Receive Credit Check, 509, will use External Object Interfaces to send the customer information to the accounts receivable application and determine if the customer has good credit.

Credit OK?, 511, is a decision point. The results of the credit check, 509, will determine the next step in the process instance.

Complete Order, 513, is a user interaction task for a determination, 511, of a satisfactory credit check, 509. The agent can now complete the order and submit it for processing.

Order Complete?, 515, is a decision point. Certain conditions must be met in order for the order to be complete.

Escalate to Manager, 521, is an automated task. If the credit check, 509, does not come back favorably, the order request will be escalated to the agent's manager.

Manager Approve?, 523, is another decision point. The outcome of the manager's approval will determine the next step in the business process, either to reject the order, 525, or to complete the order, 513.

Reject Order, 525, is a business process. Reject Order contains the steps that are involved in handling a rejected order.

FIGURE 8 illustrates the screen view, 601, for creating a business process using the method and system of the invention. Particular tasks are linked together, as shown in FIGURES 1 and 3, so as to create processes, as shown in FIGURES 4 and 5. Particular tasks, as input, 61 1 , decision points, 613, user interactions, 615, automated tasks, 617, subprocesses, 619, and connectors, are shown along the left side of the screen A business process being created is shown in the work area of the screen. The business process is created using standard drag and drop methods.

The method and system of our invention has a Graphical User Interface (GUI). This is to provide a method that lets users define and monitor Business Processes through a visual tool. The method and system of the invention must make it easy for customers to customize the process and system. This means that the system must create an open, flexible workflow engine for supporting the creation and enforcement of business processes. In this way, customers can easily define the business process and easily extend the business entities that can be placed in a system. Customers can easily extend the actions that can be invoked.

The method and system of the invention supports connected, thin and mobile clients. That is, it must support all types of clients. For connected and thin clients, the system and method must synchronously communicates with a workflow server component and return results to the user in real-time. For mobile users, the system and method of the invention queues the request until the next time the mobile users synchronize with the remote server. Some steps can be executed directly on the thick and mobile clients.

The workflow management method and system preferably provides integration with CTI. For example, through built in support for CTI events. The workflow management method and system of our invention should also provide integration with the server and the server infrastructure, with built in support for server infrastructure events. This support includes the ability for a business process to retrieve data from the server infrastructure.

The workflow management method and system of our invention also has integration with Inbound Email. This could be provided through built in support for Inbound Email events. Appendix A illustrates the data about the tables used in one exemplification of the method and system of the invention. As shown in the Appendix, S_WF_STEP is a table that stores all the steps that are defined in Front Office Workflow. A business process is defined as a runnable step of type Process. S_WF_STEP_BRNCH is a table that stores the conditional and exceptional branches used in step definitions.

Exceptional branches specify runtime exceptions (attribute-, timer- or error-related) for step definitions. S_WF_PROC_FLOW is a table that stores the normal and exceptional transitions between process definition steps. Exceptional transitions specify the actions to execute when exceptions are raised for step instances. S WF PROC PROP is a table that stores the runtime properties of process definitions. S_WF_COND_CRIT is a table that stores the criteria fields used in input and decision branch conditions. A field may be a business component field, process property or Assignment Criteria. S WF COND VAL is a table that stores the criteria values used in input and decision branch conditions. The first string value may be a query expression for the Free Form comparison method. S_WF_STEP_ARG is a table that stores the input and output arguments of a process or task step. The value of an input argument may be constant or dynamic (a business component field, process property or Assignment Criteria value). S_WF_STEP_RECIP is a table that stores the task step recipients. A dynamic recipient is identified by a process property or Assignment Criteria. S_WF_STEP_INST is a table that stores all the step instances. A root process instance does not have a row in the Process Steps table. S_INBOX_ITEM is a table that stores the work items sent to a user's inbox. If Workflow is supported on the Client, this Inbox Item references the corresponding sub- process definition associated with the user interaction task. Otherwise this Inbox Item is created standalone with a given business object, subject and optionally a drilldown view. S EMP INBOX is a table that stores the work items sent to an employee's inbox. S_POSTN_LNBOX is a table that stores the work items sent to a position's inbox. S_ASGN_ATTR_FIELD (repository table) is a table that stores the assignment attribute fields that specify the actual mappings of assignment attributes to business component fields. It is the BO/BC-based version of S_ASGN_ATTR_COL. While the invention has been described with respect to certain preferred embodiments and exemplifications, it is not intended to limit the scope of the invention thereby, but solely by the claims appended hereto.

APPENDIX A

Table Definitions

S_WF_STEP

This table stores all the steps that are defined in Front Office Workflow. A business process is defined as a runnable step of type Process.

S_WF_STEP_BRNCH

This table stores the conditional and exceptional branches used in step definitions. Exceptional branches specify runtime exceptions (attribute-, timer- or error-related) for step definitions.

Name Null? Type Description

ROWJD (PK) NOT NULL I VARCHAR2(15) | System-generated identifier

S_WF_PROC_FLOW

This table stores the normal and exceptional transitions between process definition steps. Exceptional transitions specify the actions to execute when exceptions are raised for step instances.

S_WF_PROC_PROP

This table stores the runtime properties of process definitions.

S _WF_COND_ CRIT

This table stores the criteria fields used in input and decision branch conditions. A field may be a business component field, process property or Assignment Criteria.

S_WF_COND_VAL

This table stores the criteria values used in input and decision branch conditions. The first string value may be a query expression for the Eree Form comparison method.

S_WF_STEP_ARG

This table stores the input and output arguments of a process or task step. The value of an input argument may be constant or dynamic (a business component field, process property or Assignment Criteria value).

S_WF_STEP_RECLP

This table stores the task step recipients. A dynamic recipient is identified by a process property or Assignment Criteria.

S_WF_STEP_ΓNST

This table stores all the step instances. A root process instance does not have a row in the Process Steps table.

S_WF_INST_PROP_VAL

This table stores the runtime values of process properties.

S_LNBOX_ITEM

This table stores the work items sent to a user's inbox. If Workflow is supported on the Client, this Inbox Item references the corresponding sub-process definition associated with the user interaction task. Otherwise this Inbox Item is created standalone with a given business object, subject and optionally a drilldown view.

S EMP LNBOX

This table stores the work items sent to an employee's inbox.

S POSTN LNBOX

This table stores the work items sent to a position's inbox. Name Null? Type Description

ROWJD (PK) NOT NULL VARCHAR2(15) System-generated identifier

INBOX JTEMJD NOT NULL VARCHAR2(15) Inbox item (FK to SJNBOXJTEM)

POSTNJD VARCHAR2(15) Posihon (FK to S_POSTN)

REPLD DT DATE Date the position responded to the box

STATUS VARCHAR2(30) Status of the mbox item for this position (Open, Cancelled, Accepted, Done)

PROCJNSTJD VARCHAR2(15) Parent sub-process instance (FK to S_WF_STEPJNST)

S_ASGN_ATTR_FIELD (repository table)

This table stores the assignment attribute fields that specify the actual mappings of assignment attributes to business component fields. It is the BO/BC-based version of S ASGN ATTR COL.

Claims

We claim:

1. A system for monitoring a business process having linked procedures to realize a business objective, said system being configured to: (a) define the business process by enumerating steps within the business process, (i) said steps being logically linked, (ii) said steps being chosen from the group consisting of

(1) starts, wherein a start defines the conditions to be met to initiate a business process; and at least one of the following: (2) tasks, wherein a task is an activity that must be executed as part of a process,

(3) decision points, wherein a decision point is a point where a work item will branch off to different steps, each branch comprising one or more conditions that must be met for a piece of work to follow the branch;

(4) subprocesses, where a subprocess is a previously defined business process; and

(5) exceptions, where an exception is the handling of an unexpected condition; and (b) monitor the business process by

(i) initiating a process instance;

(i) tracking process instances and work items in the process instance; and

(iii) initiating a step instance.

2. The system of claim 1 wherein said tasks are chosen from enduser interaction tasks and automated tasks.

3. The system of claim 1 wherein said tasks are chosen from the group consisting of notifications, inserts, updates, deletions, report generations, assignments, external object interfaces, server tasks, and external programs.

4. The system of claim 1 wherein said system is configured to instantiate the business process by entering a service request.

5. The system of claim 4 wherein said system is configured to assign the service request to an agent according to assignment rules.

6. The system of claim 4 wherein said system is configured to determine the service request priority, and determine a subsequent step based on the priority.

7. The system of claim 6 wherein said system is configured to determine that the service request priority is high, and broadcasting a message.

8. The system of claim 6 wherein the system is configured to resolve or escalate the service request.

9. The system of claim 1 wherein said system is configured to instantiate the business process by creating an order.

10. The system of claim 9 wherein said system is configured to collect customer information.

11. The system of claim 10 wherein said system is configured to determine if the customer is an existing customer or a new customer, and thereafter

(a) enter customer data for a new customer, or (b) call up customer data for an existing customer.

12. The system of claim 10 wherein said system is configured to send a credit check and receive a credit check response.

13. The system of claim 12 wherein said system is configured to determine if the customer is creditworthy, and either complete the order if the customer is creditworthy or escalate the order if the customer is not creditworthy.

14. A method for modeling and/or monitoring a business process having linked procedures to realize a business objective, said method comprising

(a) defining the business process enumerating steps within the business process, (i) said steps being logically linked,

(ii) said steps being chosen from the group consisting of

(1) starts, wherein a start defines the conditions to be met to initiate a business process; and at least one of the following:

(2) tasks, wherein a task is an activity that must be executed as part of a process,

(3) decision points, wherein a decision point is a point where a work item will branch off to different steps, each branch comprising one or more conditions that must be met for a piece of work to follow the branch, (4) subprocesses, where a subprocess is a previously defined process; and

(5) exceptions, where an exception is the handling of an unexpected condition; and

(b) managing and/or monitoring the business process by (i) initiating a process instance;

(i) tracking process instances and work items in the process instance; and (iii) initiating a step instance.

15. The method of claim 14 wherein said tasks are chosen from enduser interaction tasks and automated tasks.

16. The method of claim 14 wherein said tasks are chosen from the group consisting of notifications, inserts, updates, deletions, report generations, assignments, external object interfaces, server tasks, and external programs.

17. The method of claim 14 comprising instantiating the business process by entering a service request.

18. The method of claim 17 comprising assigning the service request to an agent according to assignment rules.

19. The method of claim 17 comprising determining the service request priority, and determining a subsequent step based the priority.

20. The method of claim 19 comprising determining the service request priority is high, and broadcasting a message.

21. The method of claim 19 comprising resolving or escalating the service request.

22. The method of claim 14 comprising instantiating the business process by creating an order.

23. The method of claim 22 comprising collecting customer information.

24. The method of claim 23 comprising determining if the customer is an existing customer or a new customer, and thereafter (a) entering customer data for a new customer, or

(b) calling up customer data for an existing customer.

25. The method of claim 22 comprising sending a credit check and receiving a credit check response.

26. The method of claim 25 comprising determining if the customer is creditworthy, and either completing the order if the customer is creditworthy or escalating the order if the customer is not creditworthy.