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.
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.