Flow designer for establishing and maintaining assignment and strategy process maps

Abstract

A system, method and carrier medium for modeling a Financial service organization (fso) business in a computer software program and for storing the model of the fso business in a database. An object-oriented business model representing the fso may be created and stored in a business model database. The one or more business objects included in the business model may be configured to describe various products, methods, functions and properties associated with an fso. A process map business object may describe a process workflow. The process workflow may identify a sequence of tasks to be performed by an fso production system to process an fso transaction. The sequence of tasks associated with an fso transaction may be consistent with pre-defined business logic for the transaction. Selecting a task object from a plurality of task objects and transferring the task object to a process map display representing the process map business object may create the process workflow. Additional task objects may be transferred and connected to the transferred task objects in a manner consistent with the business logic. An fso production system, which may be configured to process fso transactions, may access the database to request data associated with a particular fso transaction. On receiving the requested data from the business model database, the fso production system may complete the processing of the fso transaction.

Description

PRIORITY CLAIM

This application claims the benefit of U.S. Provisional Application No. 60/151,031 entitled “Flow Designer For Establishing And Maintaining Assignment And Strategy Process Maps,” filed Aug. 27, 1999.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention generally relates to computer software programs to be used in Financial Service Organizations. More particularly, the present invention relates to a system for modeling a Financial Service Organization (FSO) production system for processing FSO transactions.

2. Description of the Related Art

FSOs such as banks, credit unions, insurance companies, mutual fund companies, credit card companies, brokerage houses, etc., market many types of financial products to their customers, such as savings accounts, brokerage accounts, commercial loans, mortgage loans, auto loans, personal loans, and credit cards. To acquire a credit product, for example, a customer of a FSO is typically required to submit an application for the credit product. The FSO then follows an application processing procedure for the credit product to determine whether the application is approved or rejected.

The application procedure includes such steps as gathering financial related information of the customer applying for the credit product, requesting credit reports on the customer, and examining and scoring the credit product application to see if the customer's credit be opened for the assignment map object created in step 830. FIG. 19 illustrates one embodiment of a flow designer window which may be used to design an assignment map. Turning to FIG. 2c, in one embodiment, the assignment map window may be opened by selecting the assignment map object and choosing an “open object” menu choice from a menu in a flow designer program window. In another embodiment, the assignment map window may be opened by opening a properties sheet for the assignment map object and selecting an assignment map panel in the property sheet.

In steps 834-846, task objects are added to the assignment map, resolved, and connected in an assignment flow. These steps may be iterative, with one or more task objects added, their properties resolved, connections made, more task objects added, and so on. Steps 834-846 may also be performed in other orders than shown in FIG. 2c. In one embodiment, task objects may be added by selecting a task icon from a toolbar and dragging and dropping the task icon onto the assignment map. The toolbar may include task icons representing each of the task types available for use in an assignment map. Task objects may be added to the assignment map as pre-defined tasks or as generic tasks. A pre-defined task is a task that was defined previously in the business modeler program. These tasks are reusable, that is, the same task may be added to one or more strategy and assignment maps. Generic tasks are defined in the flow designer program as they are added to an assignment or strategy map. Generic tasks exist only for the assignment or strategy map in which they are created. Generic tasks cannot be reused in other assignment and strategy maps.

In one embodiment of a flow designer, some tasks may be available only for account acquisition assignment and strategy maps, some tasks may be available only for account collections assignment and strategy maps, and some tasks may be available for both account acquisition and account collections assignment and strategy maps.

In step 834, one or more processing task objects may be added. Processing tasks may be configured to perform operations on one or more data elements. Examples of processing tasks include, but are not limited to: calculation tasks, which are configured to perform mathematical operations on one or more data elements or data constants, and; score tasks, which grade or rank one or more data elements. In step 836, decision task objects may be added. Decision task objects provide branching within an assignment or strategy map by comparing data elements or results of previous tasks or operations within the decision task object. Decision task objects manage the flow of business product transactions in an assignment or strategy map by representing possible outcomes of conditions, and the desired result(s) that correspond to the conditions.

In step 838, invoke external interface task objects may be added. Invoke external interface task objects launch an external interface, which may have been previously defined in business modeler. External interfaces send and receive information from outside sources such as credit bureaus and FSO mainframe systems. In step 840, send to organizational unit task objects may be added. Send to organizational unit task objects may be configured to assign a business product transaction to another organizational unit for processing. A send to organizational unit task object may be invoked when a decision task object has determined that the organizational unit that is the parent of this assignment task object is not the preferred organizational unit for processing a business product transaction. In step 842, send to strategy task objects may be added. A send to strategy task object may be resolved to send a business product transaction to a strategy map as illustrated in FIG. 2b.

Other types of task objects may be added to an assignment map. Examples of other types of task objects that may be added to an assignment map include, but are not limited to, the following. Champion challenger task objects may be configured to assign business product transactions with similar characteristics to different strategies based upon a random sampling scheme, and may be used to measure and compare the results of alternative strategies.

In step 844, task objects that have been added to the assignment map may be resolved. In one embodiment of a flow designer program, resolution of tasks objects may involve selecting the added task object and opening the property sheet for the task object. In one embodiment of a flow designer program, a task object resolution property sheet may be opened automatically when a task object is added. Data elements included as properties of the task object may be resolved during the resolution of the task. During resolution of a task object, the source(s) from which the task object is to receive data during processing is specified. The sources may be from data elements included in other business objects and document templates previously defined in business modeler, from external sources through external interfaces, from a list of predefined values in a menu, or from other sources.

In step 846, the business product transaction processing flow for the assignment map may be defined by connecting outputs of task objects to inputs of other task objects. In one embodiment of a flow designer program, task objects may have one or more arrows projecting from the bottom, representing output links. Decision task objects may have two or more output links. Some task objects, such as send to organizational unit objects, may not have output links. In one embodiment of a flow designer program, to connect a first task object to a second task object, an arrow, or output link, on the first object may be dragged on the computer screen to contact the second object. In one embodiment of a flow designer program, all output links must be connected to task objects for the assignment map to be complete. In one embodiment of a flow designer program, circular links may not be allowed; that is, task objects may not be linked in a pattern in which a business product transaction may end up in a circular processing path.

Task objects may be added to the assignment map, resolved, and connected in a processing flow until the desired assignment map for assigning business product transactions is completed. At this point, the process goes to step 848. Here, the assignment map may be saved and closed. Saving the assignment map may include writing the assignment map object, and all the task objects added to the assignment map, to a business model database, as described in step 124 of FIG. 2a.

FIG. 3a—One Embodiment of a Business Modeler Display Screen with Business Model Objects

FIG. 3a illustrates one embodiment of a business modeler display screen with business model objects. A menu bar 450 may be disposed at the top of the screen. Menu bar 450 may include an object menu 452 as well as several other menus (not shown) including menu choices for managing the business model program, defining and managing business model objects, and defining relationships among the objects. A tool bar 464 may be disposed below the menu bar. Tool bar 464 may include several icons which, when selected, may perform functions similar to menu functions. Shown as examples are a properties icon 466 that may be used to open a properties sheet for a selected business model object, an inheritance view icon 468, and a business view icon 470. An object view 492 may be disposed below the toolbar 464. In object view 492, the business model objects may be displayed in either the inheritance relationship or the business relationship. Inheritance view icon 468 and business view icon 470 may be used to toggle the object view between the inheritance and business relationship viewing mode. In some embodiments, menu selections may also be used to toggle between the viewing modes.

The business model objects defined for a business model may be displayed in object view 492. The objects may be displayed in a top-to-bottom sequence corresponding to the inheritance relationship or the hierarchical business relationship of the objects. In one embodiment, the business model objects may be displayed as icons representing the type of object, with the name of the object displayed to the right of the icon. Shown as an example are object 1 icon 472 with object 1 name 474, object 2 icon 476 with object 2 name 478, object 3 icon 480 with object 3 name 482, object 4 icon 484 with object 4 name 486, and object 5 icon 488 with object 5 name 490. An object expansion icon 492 may be displayed to the left of each object icon. Object expansion icons 492 may be used to expand an object icon, that is, to show the children of the object icon. In one embodiment, an expanded object's expansion icon 492 may be displayed as a minus sign (−), and an unexpanded, or collapsed, object's expansion icon 492 may be displayed as a plus sign (+). In this example, object 1 is expanded, showing object 2, object 3, and object 5 as children of the object. Object 2 is not expanded. In some embodiments, children objects' icons may be inset below and to the right of the parent object's icon. In some embodiments, lines 494 may be drawn between object expansion icons 492 and between object expansion icons 492 and object icons.

FIG. 3b—One Embodiment of a Business Modeler Display Screen with an Object Menu

FIG. 3b illustrates an embodiment of the business modeler display screen of FIG. 3a with the object menu 452 opened to reveal some example menu choices that may be included. Some menu choices in object menu 452 may perform an action on a currently selected business model object in object view 492. Expand object menu choice 454 may be used to expand the currently selected business model object in object view 492. Collapse object menu choice 456 may be used to collapse the currently selected business model object in object view 492. New object menu choice 458 may present for selection a list of business model object types and create a new instance of a business model object of the selected type. Delete object menu choice 460 may delete the currently selected business model object in object view 492. Properties menu choice 462 may open a properties sheet for the currently selected business model object in object view 492. In some embodiments, object menu 452 may include other menu choices to perform other operations on business model objects. In some embodiments, the business modeler display screen may include other menus with menu choices for performing other operations in the business modeler system.

FIG. 4—One Embodiment of a Business Model Object Property Sheet

FIG. 4 illustrates one embodiment of a business model object property sheet 500. In one embodiment, a business model object's property sheet may be displayed in response to the selection of a properties icon 466 from a toolbar 464 on the business modeler display screen as shown in FIG. 3a, or alternatively in response to the selection of a properties menu choice 462 from an object menu 452 as shown in FIG. 3b. The business model object's type and name 502 may be displayed at the top of property sheet 500. An object's properties may be grouped into one or more property categories. In one embodiment, the categories of object properties may be shown on separate, selectable panels in the property sheet. Shown as examples of property categories are general properties 504, security properties 506, history properties 508, and audit properties 510. Fields in the property category panels may display the names and values of the object's properties. The inheritance status of the property may also be displayed. In one embodiment, the property value field may be disposed to the right of the property name field. In one embodiment, an inheritance indicator may be disposed to the left of the property name. In the example shown in FIG. 4, general properties panel 504 includes property 1 name 512 with property 1 value 514, property 2 name 516 with property 2 value 518, and property 3 name 520 with property 3 value 522. To the left each property name is an inheritance indicator 524. In one embodiment, inheritance indicators may be colored black to indicate that this is an original property value, gray to indicate that this property value was inherited from an ancestor, or green to indicate that the inherited property value has been overridden, or replaced, for this business model object property.

Property names and values may be modified on the business model object property sheet 500. For example, property 1 value 514 may be selected and a new value entered in the field. Changing property 1 value 514 may result in a change in the inheritance indicator 524 for property 1. In some embodiments, property values may be selectable from a list of predefined values. In this example, a property value selection icon 526 is disposed to the right of property 3 value 522. Selecting property value selection icon 526 may result in a list of possible values for property 3 to be displayed for selection. In some embodiments, business model object property sheet 500 may include one or more buttons for controlling property sheet 500. The example in FIG. 4 includes an OK button 528 and a cancel button 530. Selecting OK button 528 may result in the saving of all changes made to the object properties and the closing of property sheet 500. Selecting cancel button 530 may result in the loss of any changes made to the object properties and the closing of property sheet 500.

FIG. 5a—Business Model Objects at the Highest Level of the Inheritance View

FIGS. 5a-5d illustrate the inheritance relationship of business model objects in a business modeler system 130. The business model objects may be displayed in an inheritance view 132 on a computer screen as described in FIG. 3a. FIGS. 5a-5d may be used to illustrate the relationship of the objects in memory as well as the relationship of the objects as displayed on the computer screen. Referring to FIG. 5a, business modeler desktop 134 may be the root object and may be the ancestor of all other business model objects in the business model. Created as children of business modeler desktop object 134 are several types of business model objects that may be shared by organizational unit objects and other business model objects in the business model. Shared objects may be referenced by any organizational unit the business model. An advantage of shared objects is that an object that is common among many organizational units, such as a business calendar, may be created once, stored as a shared object in the business model hierarchical tree, and used by many organizational units. Shown are examples of shared objects including channels 136, document templates 138, data elements 140, external interfaces 142, processing calendars 144, and processing tasks 146. A shared object, when expanded, may include on one or more sharable descendent objects of the same type as the shared object.

User objects 148 are shown as children of the root object. User objects may be defined at this level because user objects may be used to give employees of the business organization security access to functions of the business modeler and the production system. Properties of user objects may include user name, user title, password, and security information defining what facilities in the business modeler and the production system a particular user may access. FSO systems 150 may be the parent object of the account acquisition and account collections systems, which are in turn the parent objects of the organizational unit objects included in the business model.

FIG. 5b—Business Model Objects Representing One Embodiment of Organizational Units in the Inheritance View

FIG. 5b shows an expanded view of FSO systems 150. Shown as children of the FSO systems 150 are the account acquisition system 152 and the account collections system 164. Organizational unit objects in the inheritance view may be created as children of systems. Shown as children of the account collections system 164 are organizational unit 166 and organizational unit 168. Shown as children of the account acquisition system 152 are organizational unit 154 and organizational unit 160. Organizational unit 154 and organizational unit 160 may not be of the same object type as account acquisition system 152, and thus may not inherit any properties from account acquisition system 152. However, an organizational unit may be able to reference its ancestors, and therefore may be able to reference shared objects created at a higher level as described for FIG. 5a. Organizational unit 154 is shown to have one child organizational unit 156. Note that other object types may also be added as children of organizational units. Organizational unit 156 is shown to have one child organizational unit 158. Organizational unit 160 is shown to have one child organizational unit 162.

As organizational units 154, 156, and 158 are of the same type, organizational units lower on the tree may inherit property values from their ancestor organizational units. Thus, organizational unit 158 may inherit property values from organizational units 154 and 156. An organizational unit may not inherit property values from its descendents. Thus, organizational unit 154 may not inherit property values from organizational units 156 or 158. A business model object may not inherit property values from siblings or siblings' descendents. Thus, organizational unit 160 may inherit property values from its ancestor organizational unit 154, but may not inherit property values from its sibling organizational unit 156 or organizational unit 156's child organizational unit 158. An object may be able to reference siblings or a sibling's descendents. Thus, organizational unit 160 may be able to reference property values of organizational units 156 and 158. Security features of business model objects may also be used to regulate referencing among business model objects. For example, security properties for a business model object may be set to deny referencing of one or more properties to siblings. Thus, security properties for organizational unit 160 may be set to prohibit organizational unit 156 from referencing organizational unit 160's properties.

FIG. 5c—One Embodiment of an Account Acquisition Organizational Unit in the Inheritance View

FIG. 5c shows an expanded organizational unit 154 with child business model objects in the inheritance view. In one embodiment, to create a new child business model object under an existing business model object, the existing business model object may be selected in the object view window and the new object menu selection 458 shown in FIG. 3b applied to the selected business model object. Referring again to FIG. 5c, organizational unit 154 may include document templates 170, products 172, processing tasks 174, master assignment 176, strategies 178, queues 180, and job seats 182. Also shown are unexpanded child organizational units 156 and 160.

FIG. 5d—One Embodiment of an Account Collections Organizational Unit in the Inheritance View

FIG. 5d shows an expanded organizational unit 166 with several child business model objects in the inheritance view. Organizational unit 166 may include agencies 184, queues 186, processing tasks 188, master assignment 190, strategies 192, job seats 194, data elements 196, and document templates 198.

FIG. 6a—One Embodiment of Business Model Objects at the Highest Level of the Business View

FIGS. 6a-6c illustrate the business relationship of business model objects in an embodiment of a business modeler system 130. The business model objects may be displayed in a business view 200 on a computer screen as described in FIG. 3a. Referring to FIG. 6a, business modeler desktop 134 may be the root object and may be the ancestor of all other business model objects in the business model. Operations that may be performed on objects in the inheritance view may also be performed in the business view. FSO systems 150 is shown expanded with its reporting account acquisition system 152 and account collections system 164 visible. The tree is expanded to show the organizational units in both systems in their reporting relationship. The organizational units shown in FIG. 5b in an inheritance relationship are shown in FIG. 6a in a business relationship. Thus, organizational unit 160 is shown reporting to organizational unit 156 rather than as a sibling of organizational unit 156 154, organizational unit 162 is shown reporting to organizational unit 158 rather than as a child of organizational unit 160, and organizational unit 168 is shown reporting to organizational unit 166 rather than as a sibling of organizational unit 166 164.

FIG. 6b—One Embodiment of an Account Acquisition Organizational Unit in the Business View

FIG. 6b shows an expanded organizational unit 154 with reporting business model objects in the business view. Organizational unit 154 may include document templates 170, products 172, processing tasks 174, master assignment 176, strategies 178, processing calendar 206, queues 180, job seats 182, and external interfaces 208. Also shown is unexpanded organizational unit 156 that reports to organizational unit 154. Some objects shown in the business view as reporting to an object may be shown in the inheritance view at a different level in the hierarchical tree. Thus, sharable business model objects shown on the high-level inheritance view in FIG. 5a may be shown as reporting objects to an organizational unit object in the business view. For example, processing calendar 206 may be a shared business model object common to all organizational units.

FIG. 6c—One Embodiment of an Account Collections Organizational Unit in the Business View

FIG. 6c shows an expanded organizational unit 166 with several reporting business model objects in the business view. Organizational unit 166 may include agencies 184, data elements 196, document templates 198, processing tasks 188, master assignment 190, strategies 192, processing calendar 210, job seats 194, queues 186, and external interfaces 212. Also shown is reporting organizational unit 168, which is a sibling of organizational unit 166 in the inheritance view.

FIG. 7—One Embodiment of a Document Template Design Process

FIG. 7 shows one embodiment of a document template design process in a business modeler system 130. Business modeler system 130 may include a document template design subsystem 230. When a new document template object is created as a child of a business model object, a blank template 232 may be displayed for the document template. Data elements that are children of the business model object or that may be referenced by the business model object which is the parent of the document template are made available for adding to the blank template 232. In this example, data elements 234, 236, 238 and 240 are added as fields in template 232. The fields may include the name of the data element and a box for displaying or modifying the value of the data element. The positioning of the fields in template 232 may be how the fields will be displayed and printed in the production system. Properties of the data elements added to template 232 may determine some aspects of how the data element is displayed in the field, for example, the field width and the precision of the data element value. In one embodiment of a document template design subsystem, data elements may be selected from either the inheritance or business view and dragged and dropped onto a blank template. In one embodiment of a document template design subsystem, a position may be selected on a blank template and a data element may be selected from a list of available data elements and added to the blank template at the selected spot. Note that since a document template is an example of a business model object, the document template design subsystem may be viewed as a method for graphically defining a document template object.

Examples of document templates that may be designed with a document template design process as illustrated in FIG. 7 may include, but are not limited to: correspondence letters, product applications, and presentation templates used to display one or more incoming or outgoing data elements of external interface objects.

FIG. 8a—High-Level Business Product Transaction Processing in an Embodiment of a Production System

FIG. 8a illustrates at a high level how an FSO business product transaction 256 may be processed in a production system 250. Production system 250 may include an assignment process 252 and a strategy process 254. The purpose of assignment process 252 may be to choose an appropriate strategy for business product transaction 256. At step 258, assignment process 252 may gather as much information as possible about the customer associated with the business product transaction. At step 262, assignment process 252 may examine the customer information to determine which strategy is best suited for transaction 256. Once an appropriate strategy is chosen, business product transaction 256 is routed to the strategy. This example shows two possible strategies, strategy A 264 and strategy B 268. In this example, if assignment step 262 determines that strategy B 268 is the best strategy for transaction 256, transaction 256 is routed to strategy 268 for processing and final disposition. When strategy B 268 has completed processing transaction 256, transaction 256 may be passed to end strategy B 270 for cleanup. Cleanup operations may include, but arc not limited to, archiving of documents, deletion of the electronic copies of the documents, and the freeing of any memory dynamically allocated during the processing of transaction 256.

FIG. 8b—Modeling High-Level Business Product Transaction Processing in an Embodiment of a Business Modeler System

FIG. 8b illustrates how the high-level business product transaction processing may be modeled in an embodiment of a business modeler system 130. Business modeler system 130 may include an assignment designer subsystem 280 and a strategy designer subsystem 282. In the strategy subsystem, two strategy objects may be defined, one for strategy A and one for strategy B. A strategy A task 292 may be added to the strategy A object. The processing to be performed on a business product transaction in step 264 of the production system shown in FIG. 8a may be defined in strategy task A. An end strategy A task 294 may be added to the strategy A object to perform the cleanup operations of step 266 of the production system shown in FIG. 8a. The output of task 292 may be connected to an input node on task 294 signifying that a business product transaction is to passed from task 292 to task 294. Likewise, a strategy B task 296 and an end strategy B task 298 may be added to the strategy B object to model strategy B processing as shown in the production system of FIG. 8a.

In the assignment designer subsystem shown in FIG. 8b, a start assignment task 286 may be added to an assignment object. Task 286 may be defined to gather the customer information needed at step 258 of the production system shown in FIG. 8a. Thus, task 286 may reference one or more external interface objects to gather customer information from other computer systems and databases. The gathered information may be mapped to data elements included as fields on document templates associated with a business product transaction. A choose strategy task 290 may be added to the assignment object. Task 290 may be defined to choose among two or more strategies as required at step 262 of the production system shown in FIG. 8a. The output of task 286 may be connected to an input node on task 290 signifying that a business product transaction is to be passed from task 286 to task 290. Note that the output of a choose strategy task in the assignment designer subsystem may not be routed directly to a strategy object in the strategy designer subsystem. Strategy objects may be chosen from a list of available strategies and assigned as destinations for business product transactions on decision branches in a choose strategy task in the assignment designer subsystem.

FIG. 9—A High-Level Assignment and Strategy Process in an Embodiment of a Production System

FIG. 9 illustrates an embodiment of a production system, showing how a business product transaction is processed in an organizational unit 310 in a production system 250 and the possible destinations of a business product transaction in the system. Organizational unit 310 may include a master assignment process 312 and a strategy process 314. At step 316 of the assignment process, the business product transaction may be examined to see if organizational unit 310 is responsible for processing this business product transaction. If organizational unit 310 is not responsible for the processing of the business product transaction, the business product transaction may be routed to another organizational unit 320 by step 318. If organizational unit 310 is responsible for processing the business product transaction, the business product transaction may be routed to step 322 for strategy selection. In step 322, the business product transaction is examined to determine which strategy available to organizational unit 310 is best suited for processing the business product transaction. The business product transaction may then be passed to strategy 314. At step 324 of strategy 314, the business product transaction is examined to see if it can be automatically processed. If the business product transaction cannot be automatically processed, it may be posted to queue 328 for manual processing by step 326. If step 324 determines the business product transaction can be automatically processed, the business product transaction may be routed to step 330 for automatic processing. Thus, in this embodiment of a production system, a business product transaction entering an organizational unit's assignment process must either end up in a strategy process or in another organizational unit's assignment process, and a business product transaction entering an organizational unit's strategy process must either end up being automatically processed in the strategy process or being posted to a queue for manual processing.

FIG. 10—An Example Master Assignment Model in an Embodiment of a Business Modeler System

FIG. 10 illustrates how an assignment process may be modeled in an embodiment of a business modeler system 130. Business modeler system 130 may include an assignment designer subsystem 280. A master assignment object may be defined as a child of organizational unit A. A master assignment design screen 340 may be opened for the master assignment object. In one embodiment, task objects may be selected from either the inheritance or business view and dragged and dropped onto master assignment design screen 340. In some embodiments, generic task objects may also be available in a generic task object list and may be added to master assignment design screen 340. Generic task objects may be predefined tasks not created or displayed in the inheritance or business views but that are available for use in assignments and strategies. In one embodiment, generic task objects are displayed as icons in a generic task window and may be dragged and dropped onto an assignment or strategy design screen. In one embodiment, generic task objects may be listed as menu choices in an add generic task menu available during assignment and strategy design. In one embodiment, a task object added to design screen 340 may appear as an icon on the design screen. The name of the task object may also be displayed. Once a task object is added to master assignment design screen 340, the task object's property sheet may be opened and properties of the task object may be resolved. An example of resolution of a task object property may be to specify the sources of data for filling in the values of data elements included in document templates.

In master assignment 340, the first task added may be start assignment task 342. Task 342 may be configured to gather data from internal (production system) and external (other system) sources. Decision task A 344 may be added to master assignment 340 and configured to evaluate one or more data elements in a business product transaction to determine the routing of the business product transaction. A send to organizational unit task 346 may be added to master assignment 340 and the property sheet of task 346 may be opened to specify what organizational unit to send a business product transaction to. In this example, the properties of task 346 are resolved to route a business product transaction to organizational unit B. An output node on task 344 is connected to an input node on task 346. On master assignment 340, the link between nodes may be signified by a line drawn between the output and input node.

Processing task A 348 and decision task B 352 may then be added to master assignment 340. Outputs from task 344 may be connected to inputs on task 348 and task 352. Send to strategy A task 350 may then be added to master assignment 340. The property sheet of task 350 may be resolved to route a business product transaction to a previously defined strategy A. Send to strategy task 354 and processing task B 356 may then be added to master assignment 340. Outputs from decision task 352 may then be connected to inputs on tasks 354 and 356. Send to strategy task 358 may be added to master assignment 340. An output from task 356 may be connected to an input on task 358. Finally, the property sheets of task 354 and 358 may be resolved to route a business product transaction to strategies B and C, respectively.

Note that the process described for FIG. 10 is used to define a master assignment object. Thus, the process may be viewed as a graphical method for defining a master assignment object. The tasks added to the master assignment object may be said to be referenced by the master assignment object.

FIG. 11—An Example Strategy Model in an Embodiment of a Business Modeler System

FIG. 11 illustrates how a strategy process may be modeled in an embodiment of a business modeler system 130. Business modeler system 130 may include a strategy designer subsystem 282. A strategy object may be defined as a child of organizational unit A. A strategy design screen 360 may be opened for the strategy object. In one embodiment, task objects may be selected from either the inheritance or business view and dragged and dropped onto strategy design screen 360. In some embodiments, generic task objects may also be available in a generic task object list and may be added to strategy design screen 360.

In strategy 360, the first task added may be start strategy task 362. Task 362 may be configured to perform some initial processing on the data elements in a business product transaction. Decision task C 364 may be added to strategy 360 and configured to evaluate one or more data elements in a business product transaction to determine the routing of the business product transaction. A send to queue task 366 may be added to strategy 360 and the property sheet of task 366 may be opened to specify what queue to send a business product transaction to. In this example, the properties of task 366 are resolved to route a business product transaction to queue A. An output node on task 364 is connected to an input node on task 366.

Processing task C 368 and decision task D 372 may then be added to strategy 360. Outputs from task 364 may be connected to inputs on task 368 and task 372. End strategy 370 may then be added to strategy 360. An output from task 368 may be routed to an input on task 370. Send to queue task 374 and end strategy 376 may then be added to strategy 360. Outputs from task 372 may then be connected to inputs on tasks 374 and 376. The properties of task 374 may then be resolved to route a business product transaction to queue B.

FIG. 12—The Relationship Among Organizational Units in Customer Processing in an Embodiment of a Production System

FIG. 12 shows a production system 250 in which several organizational units may be configured to process business product transactions for customers of an FSO. This illustration is used to show how linking master assignments in a business model system's assignment and strategy design subsystems may be used to model an FSO-wide business product transaction processing production system involving several organizational units. A customer's business product transaction 380 may enter the production system and may start at organizational unit A's master assignment 384. Master assignment 384 may examine business product transaction 380 to determine if organizational unit A 382 is responsible for handling transactions of this type. If organizational unit A 382 is responsible for processing transaction 380, master assignment 384 may pass transaction 380 to strategy 386 for processing. If organizational unit A 382 is not responsible for processing transaction 380, master assignment 384 may forward transaction 380 to organizational unit B 388. Organizational unit B's master assignment 390 may examine business product transaction 380 and determine that organizational B is not responsible for processing transaction 380. Master assignment 390 may forward transaction 380 to organizational unit C 394 for processing.

FIG. 13—An Embodiment of a Database Store Process for Business Modeler Objects

FIG. 13 shows an embodiment of a business modeler system similar to the one described in FIG. 1a. This embodiment includes an object store process 400 as part of business modeler program 30. Object store process 400 may take one or more business model objects currently residing in business modeler program 30's program memory and store the objects in business modeler database 40. Object store process 400 may decompose the objects into their component properties and store each property as a line or record in database 40. In this example, two objects are shown, object A 402 and object B 410. Object A 402 includes three properties. Property A1 404 and property A2 406 may be alphanumeric values such as object name, object type, numerical value, identification number, or any other property that describes object A 402. Reference to object B 408 is a special type of property. A reference property is an object property that describes the relationship an object in the business model has to another object in the business model. A reference property may describe a parent-child relationship between objects or it may describe a relationship where one object refers to another object that is not a child of the first object. In this example, reference property 408 refers to a child object B 410. Object B 410 includes two properties, property B1 412 and property B2 414. Another example of a property relationship is a send to organizational unit task which is resolved to send a business product transaction from one organizational unit's assignment map to a second organizational unit's assignment map. The first organizational unit's send to organizational unit task object may include a reference property specifying the assignment map object of the second organizational unit.

Object store process 400 is aware of the business model objects included in the business model currently loaded in business modeler program 30's memory. Object store process 400 may iterate through the objects, decompose each object into its component properties, and store the objects' properties as records in business model database 40. The object property records in business model database 40 may include enough information to reconstruct the business model and all of the business model objects included in the business model in a subsequent execution of business modeler program 30.

FIG. 14—An Embodiment of a Process for Converting a Business Model Defined in an Embodiment of a Business Modeler System into a Production System Database

FIG. 14 illustrates one embodiment of a process for converting a business model defined in an embodiment of a business modeler system into a production system database. Business model database 40 may have been created or updated by a process such as that illustrated in FIG. 13. A production build program 422 may reside on the business modeler system or may reside on another system having access to the business modeler system. In one embodiment, production build 422 may be a subprogram or component of the business modeler system. In another embodiment, production build 422 may be a standalone program.

Production build 422 may include information describing the format of business model database 40 and production system database 420. In one embodiment, production build 422 may compare the business transaction processing business model described in business model database 40 with a previously implemented business transaction processing database stored in production system database 420. Production build 422 may search for differences between the new model and the previously implemented model. In one embodiment, production build 422 may create production build scripts 424 including instructions for updating production system database 420 to match the updated business model described in business model database 40. Script 424 may then be prepared for application to production system database 420 by a database administrator. Scripts 424 may then be executed to apply the updates to production system database 420. The execution of scripts 424 may be performed when the production system is offline and not accessing the database or scripts 424 may be executed when the production system is online. In another embodiment, production build 422 may directly update production system database 420, bypassing the creation of scripts 424. In yet another embodiment, a business model database 40 created in a business modeler system may be used directly as a production system database 420 without going through a production build process.

Production build 422 may also output display and printing templates 428 in response to the comparison between business model database 40 and production system database 420. Display and printing templates 428 may be used in a production system to display customer information including documents included in a business product transaction on client systems and to print documents on printers available to the production and client systems. Display and printing templates 428 may have a one-to-one correspondence to document template objects defined in the business modeler system.

FIG. 15—A Flowchart Describing an Example of a Business Product Transaction Processing Flow in an Embodiment of a Production System that was Modeled in an Embodiment of a Business Modeler System

FIG. 15 shows a flowchart of a business product transaction processing example in an embodiment of a production system that was modeled in an embodiment of a business modeler system. The example illustrates a typical example of a customer applying for and being approved for a loan. In step 500, the customer enters the FSO office and requests a loan. In step 502, a loan officer sitting at a client system in the production environment brings up a loan application template on the client system screen and enters basic customer information such as name and social security number, and submits the loan application to the production system. In step 504, the production system uses the customer information from the loan application to gather existing information on the customer. This may include sending a request to search for the customer in the FSO's customer database over an external interface. In step 506, the production system may populate the loan application with customer information received from external sources via external interfaces and present the populated loan application to the loan officer on the client system. In step 508, the loan officer may then fill out more information specific about this loan for this customer. In step 510, the loan officer submits the completed application to the production system for processing. The production system then may evaluate all the information gathered about the customer, score the customer's application for this loan, and decide that the loan is approved in step 512. In step 514, the production system sends a message to the client system to notify the loan officer that the loan is approved. The customer may then accept the terms of the loan and notify the loan officer, who may tell the production system the loan is accepted in step 516. In step 518, the production system may send the loan information to external FSO computer systems for loan issuance.

FIG. 16 Illustrates How the Example in the FIG. 15 May be Modeled in an Assignment and Strategy Map in One Embodiment of a Business Modeler System.

FIG. 16 illustrates how the example in FIG. 15 may be modeled in an assignment and strategy map in one embodiment of a business modeler system. Part of the loan application process illustrated in FIG. 15 is modeled as tasks in the assignment process 600. The rest is modeled as tasks in the strategy A process 602. This example shows the assignment process map and strategy process map as a series of simplified, sequential tasks and leaves out branches such as alternative strategies at step 616 and loan rejection at task 622.

Task 604 is configured as a starting task for assignment process 600. Assignment process 600 may be configured to process applications for a particular FSO product. Task 604 may be configured to accept an application for a product. In this example, task 604 is configured to accept a request for a loan application. Task 606 may be configured to send a loan application to a client system. Task 608 may be configured to accept a loan application with basic customer information filled in. Task 610 may be configured to invoke an external interface to the FSO's customer database to retrieve information on a customer and to map the retrieved customer information onto a loan application. Task 612 may be configured to send a partially completed loan application to a client system. Task 614 may be configured to accept a completed application from a client system. Task 616 is a decision task that may be configured to choose an appropriate strategy for a loan application based upon information on the loan application and any other customer information that is available. Task 618 may be one of several branches off task 616. Task 618 may be configured to send a loan application and all available information to a strategy, in this example strategy A 602.

Strategy process A 602 may start at task 620, which may be configured for receiving a loan application and associated customer information from an assignment process. Task 622 is a decision task, and may be configured to gather more information about a customer, perform calculations on data elements in a loan application, and score the loan application. Task 622 may then compare a score for a loan application against a loan accept/decline score constant to determine if the loan is approved. Task 624 may be one of several branches off task 622. Other branches may include a task to be invoked if a loan application is not approved. Task 624 may be configured to notify a client system that a loan application is approved. Task 626 may be configured to accept a loan acceptance confirmation message from a client system. Task 628 may be configured to invoke one or more external interfaces to FSO systems to inform the systems to implement and record a newly approved loan. Task 630 may be configured to clean up a production system by deleting any temporary files created in the production system during loan application processing.

FIG. 17—A Block Diagram of an Embodiment of a Production System Illustrating the Usage of a Production System Database

FIG. 17 shows an embodiment of a production system 700 and is included to illustrate the usage of a production system database, display templates, and printer templates created by the process described in FIG. 14. This embodiment of a production system may be described as a client/server system configured to process business product transactions in a distributed, transaction-processing environment. A definition of a distributed, transaction-processing environment as used herein is a system including multiple computer systems acting as servers, wherein copies of a business product transaction processing program reside on one or more servers, and wherein a transaction router program configured to distribute transactions among the business product transaction processing programs resides on a server. A transaction may be executed by any of the business product transaction processing programs. The transaction router may choose a business product transaction processing program based upon available resources and workload. Users at client workstations may enter business product transactions into the system, and results of transaction processing may be reported to the users at the client workstations.

Referring to FIG. 17, production system 700 may include a distributed transaction processing system 702, one or more transaction sources 710, one or more manual transaction processing clients 718, a production system database 704, and display and printer templates 706. Distributed transaction processing system 702 may be configured to receive business product transactions from one or more sources or clients, perform business product transaction processing on the received transactions, and report the results of the transaction processing back to the clients. Distributed transaction processing system 702 may include a transaction router 712, one or more copies of a business product transaction processing program 714 residing on one or more servers, one or more manual transaction processing queues 716, and one or more external interfaces 722.

Business product transaction processing program 714 may include one or more implementations of processing tasks. Processing tasks perform operations on work packets. A work packet may be defined as a collection of documents associated with a particular customer's business product transaction. Examples of operations that may be performed on work packets include, but are not limited to, adding documents to a work packet, modifying data elements in the documents, performing calculations with data elements, making decisions based upon data elements, invoking external interfaces, sending work packets to queues, and sending work packets to other organizational units.

Production system 700 may be described as a data-driven system. The processing tasks included in business product transaction processing program 714 are preprogrammed into the system. However, the actual paths through the processing tasks that transactions may take while being processed by business product transaction processing program 714 are not preprogrammed. Instead, the paths through the processing tasks are dynamically defined by the contents of the production system database 704 at runtime. The formats and contents of documents, display screens, and printed output may also be defined in production system database 704 or in display and printer templates 706 and may be dynamically accessed by business product transaction processing program 714 at runtime. FIGS. 18a and 18b, described below, graphically illustrate a data-driven business product transaction processing program.

Referring to FIG. 17, a customer transaction 708 may enter production system 700 through one of several business product transaction sources. Examples of sources include, but are not limited to, an FSO employee entering data such as loan applications on a workstation, batches of transactions being fed automatically into the production system, and a customer directly initiating a transaction at a workstation or via the internet. Transaction router 712 acquires incoming business product transactions and distributes the processing of the business product transactions among the processing tasks included in the copies of the business product transaction processing program.

Transaction router 712 may begin the processing of a business product transaction by sending the business product transaction to a first processing task in business product transaction processing program 714. When the first processing task completes, it may notify transaction router 712 that it has finished. The first processing task may also notify transaction router 712 of the next processing task for the business product transaction. Transaction router 712 may then send the business product transaction to the next processing task. Processing tasks may send feedback on the processing of the business product transaction to a client workstation that was the business product transaction source 710. An FSO employee may enter additional information in response to the feedback. Processing tasks may request and receive data from one or more of the FSO's databases external to the production system through external interfaces 722. Processing tasks may also request and receive data from one or more sources external to the FSO through external interfaces 722. Examples of external data sources include, but are not limited to, credit bureaus and other FSOs. Processing tasks may also send correspondence documents to one or more external entities 726 through external interfaces 722. An example may be sending a letter to the customer associated with the business product transaction. Some processing tasks may be configured to delay the processing of the business product transaction for a length of time. An example may be delaying 30 days after sending a notice of delinquency before starting a next funds collections task.

The processing of the business product transaction continues until the transaction comes to a final resolution. If a business product transaction is successfully resolved automatically by the distributed transaction processing system 702, the results of the resolution may be reported back to the client workstation that was the business product transaction source 710. Documents associated with the business product transaction may be sent to FSO databases 724 through external interfaces 722. If a business product transaction cannot be successfully resolved automatically by the distributed transaction processing system 702, the transaction may be sent to a manual transaction processing queue 716 for manual processing by an FSO employee 720 working at manual transaction processing client workstation 718. Customer documents may be sent to an external entity if the business product transaction was not successfully resolved automatically. An example may be reporting a customer to an external collections agency for funds collection if the FSO's internal collections strategy did not succeed with the customer. After resolution of a transaction, FSO databases 724 may be updated with documents associated with the business product transaction through external interfaces 722.

FIGS. 18a and 18b—One Embodiment of a Data-Driven Business Product Transaction Processing Program

FIGS. 18a and 18b illustrate one embodiment of a data-driven transaction processing program. FIG. 18a shows business product transaction processing program 750 including four tasks, task A 752, task B 754, task C 756, and decision task D 758. Tasks A through C are processing tasks and include one input for a business product transaction and one output for the business product transaction. Task D is a decision processing task and includes one input for a business product transaction and two or more outputs for the business product transaction. Tasks A through D may not be logically connected in the source code or compiled machine code of program 750. Program 750 may be defined as including a library of independent processing tasks.

Turning to FIG. 18b, at runtime business product transaction processing program 760 may access production system database 704 to determine transaction processing flow. When a transaction 762 enters program 760, a transaction type may be determined for the transaction by examining attributes of the transaction included in the transaction data. The transaction type may then be compared with records in database 704 to determine a first processing task for this transaction type. For example, a transaction may be an application for a credit card type X and may have been entered at branch office A. A first processing task for a credit card type X at branch office A may be the first task defined in the branch office's master assignment map for credit card type X.

In this example, task A 752 may be the first task. Processing task A 752 may access database 704 during execution of processing steps to read data values, data formats, or other data as required. When processing task A 752 completes its processing steps, it may access database 704 to determine the next processing task for this transaction type. In this example, decision task D 758 may be the next processing task. When decision task D completes, it may access database 704 to determine a next processing task, and may use transaction data along with the transaction type to choose among multiple possible next processing tasks for this transaction type. For example, a decision task may compare a customer's age to a customer age limit stored in database 704, send the transaction to task B 754 if the customer is under 30, or send the transaction to task C 756 if the customer is 30 or above.

FIG. 19—An Illustration of One Embodiment of a Flow Designer Window

FIG. 19 illustrates one embodiment of a flow designer window that may be displayed on a computer screen to provide an interface to an executing flow designer program as described in the flowcharts of FIG. 2b and FIG. 2c. In this embodiment, the flow designer window may include a palette 900, a task toolbar 902, and an edit toolbar 904. A palette, as used herein, is a blank portion of a computer display screen on which process maps may be created; for example, a process map may be created by placing icons which represent business objects such as task objects onto a palette, and joining the icons to build an assignment or strategy process flow. Task toolbar 902 may include one or more task icons representing the types of task objects available for this flow design process. In one embodiment, a different set of types of task object icons may be displayed in toolbar 902 for designing assignment maps than for designing strategy maps. Task object icons 908, 910, 912, and 914 represent examples of task object icons of different types that may appear in task toolbar 902.

Palette 900 may be used to display and edit assignment and strategy maps. Task object icons may be selected from task toolbar 902 and added to palette 900. A task object icon may be resolved by selecting the task object icon and opening the property sheet for the task object. Added task object icons may include one or more arrows or output links 916 for connecting one task object icon to another task object icon. The connection of task object icons in this manner defines the processing flow in assignment and strategy maps. In this illustration, one copy of each task object type 908, 910, 912, and 914 have been added and linked. Task object icon 908 illustrates a task object type with one output link, such as a calculation task object. Task object 910 illustrates a task object type with more than one output link, such as decision task objects. Task object 922 illustrates another task object type with one output link, but where the output link is not yet connected to another task object. Task objects 924 and 926 illustrate task object types with no output links, such as completion task objects. Task objects 924 and 926 are also used to illustrate that more than one object of a particular type may be added to a map.

In one embodiment, circular links among objects may not be allowed. For example, in FIG. 19, task object 922 may not be linked to task object 918. In one embodiment, task objects may linked to only one output link from another task object. For example, in FIG. 19, the output link of task object 922 may not be connected to task object 924, since an output link from task object 920 is already connected to task object 924.

Edit toolbar 904 may include one or more edit tool icons 906. Different edit tools may be selected to perform editing tasks on the map currently displayed in template 900. Examples of edit tools include, but are not limited to: a delete tool for deleting one or more selected task objects on a map, a clear links tool to remove the links from one or more selected task objects on a map, grid and alignment tools for aligning task objects on a map, and a validate tool for validating the map. Validating a map may include verifying that all output links are attached to a task object, that all task objects are linked to at least one other task object, and that the properties of all task objects have been resolved.

Various embodiments further include receiving or storing instructions and/or data implemented in accordance with the foregoing description upon a carrier medium. Suitable carrier media include memory media or storage media such as magnetic or optical media, e.g., disk or CD-ROM, as well as signals such as electrical, electromagnetic, or digital signals, conveyed via a communication medium such as networks and/or a wireless link.

Although the system and method of the present invention have been described in connection with several embodiments, the invention is not intended to be limited to the specific forms 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

1. A method for defining a process map for processing a financial service organization business product transaction, the method comprising:

displaying a plurality of task objects on a computer display screen;

displaying a process map design palette on the computer display screen;

selecting a first task object from the displayed plurality of task objects;

adding the first task object to the process map design palette; and

storing the process map in a business model database;

wherein the process map stored in the business model database is configured for translation into a financial service organization production system database,

wherein the financial service organization production system database is configured for use in the financial service organization production system, and

wherein the financial service organization production system is configured to process business product transactions between a financial service organization and a financial service organization customer.

2. The method of claim 1, wherein selecting the first task object comprises moving a cursor over the first task object.

3. The method of claim 2, wherein adding the first task object to the process map design palette comprises moving the selected first task object onto the process map design palette.

4. The method of claim 1, further comprising:

selecting a second task object from the displayed plurality of task objects; and

adding the second task object to the process map design palette.

5. The method of claim 4, wherein the method further comprises

defining a processing path between the first task object and the second task object,

wherein the processing path describes a path for business product transactions to be passed from the first processing task to the second processing task in the financial service organization production system.

6. The method of claim 5, wherein the first task object comprises

one or more output links, and

wherein defining the processing path between the first task object and the second task object comprises connecting a first output link of the first task object to the second task object.

7. The method of claim 6, further comprising:

selecting a third task object from the displayed plurality of task objects;

adding the third task object to the process map design palette; and

defining a processing path between the first task object and the third task object;

wherein defining the processing path between the first task object and the third task object comprises disconnecting the first output link of the first task object from the second task object and connecting the first output link of the first task object to the third task object.

8. The method of claim 5, further comprising:

selecting a third task object from the displayed plurality of task objects;

adding the third task object to the process map design palette; and

defining a processing path between the first task object and the third task object;

wherein the first task object is a decision task object configured to pass a business product transaction to one of the first and second tasks objects as a function of data relating to the financial service organization customer associated with the business product transaction.

9. The method of claim 1, wherein the first task is an invoke external interface task, wherein the invoke external interface task launches an external interface that transfers information between the financial service organization production system and outside sources.

10. A system for processing fso transactions, the system comprising:

a computer program;

a computer system;

wherein the computer program is executable on the computer system to execute the method of:

displaying a plurality of task objects on a computer display screen;

displaying a process map design palette on the computer display screen;

selecting a first task object from the displayed plurality of task objects;

adding the first task object to the process map design palette; and

storing the process map in a business model database;

wherein the process map stored in the business model database is configured for translation into a financial service organization production system database,

wherein the financial service organization production system database is configured for use in the financial service organization production system, and

wherein the financial service organization production system is configured to process business product transactions between a financial service organization and a financial service organization customer.

11. The system of claim 10, wherein selecting the first task object comprises moving a cursor over the first task object.

12. The system of claim 11, wherein adding the first task object to the process map design palette comprises moving the selected first task object onto the process map design palette.

13. The system of claim 10, further comprising:

selecting a second task object from the displayed plurality of task objects; and

adding the second task object to the process map design palette.

14. The system of claim 13, wherein the method further comprises

defining a processing path between the first task object and the second task object,

wherein the processing path describes a path for business product transactions to be passed from the first processing task to the second processing task in the financial service organization production system.

15. The system of claim 14, wherein the first task object comprises

one or more output links, and

wherein defining the processing path between the first task object and the second task object comprises connecting a first output link of the first task object to the second task object.

16. The system of claim 15, further comprising:

selecting a third task object from the displayed plurality of task objects;

adding the third task object to the process map design palette; and

defining a processing path between the first task object and the third task object;

wherein defining the processing path between the first task object and the third task object comprises disconnecting the first output link of the first task object from the second task object and connecting the first output link of the first task object to the third task object.

17. The system of claim 14, further comprising:

selecting a third task object from the displayed plurality of task objects;

adding the third task object to the process map design palette; and

defining a processing path between the first task object and the third task object;

wherein the first task object is a decision task object configured to pass a business product transaction to one of the first and second tasks objects as a function of data relating to the financial service organization customer associated with the business product transaction.

18. The system of claim 10, wherein the first task is an invoke external interface task, wherein the invoke external interface task launches an external interface that transfers information between the financial service organization production system and outside sources.

19. The system of claim 10, wherein the computer system comprises a display device coupled to the computer system to display data.

20. The system of claim 19, wherein the display device is a display screen.

21. The system of claim 10, wherein the computer system comprises a user input device coupled to the computer system to enter data.

22. The system of claim 21, wherein the user input device is a mouse or a keyboard.

23. A carrier memory medium comprising program instructions, wherein the program instructions are executable having stored thereon, computer-executable instructions configured for execution by a computer system to implement the method of, to cause the computer system to perform acts comprising:

displaying a plurality of task objects on a computer display screen;

displaying a process map design palette on the computer display screen;

selecting a first task object from the displayed plurality of task objects;

adding the first task object to the process map design palette; and

storing the process map in a business model database;

wherein the process map stored in the business model database is configured for translation into a financial service organization production system database,

wherein the financial service organization production system database is configured for use in the financial service organization production system, and

wherein the financial service organization production system is configured to process business product transactions between a financial service organization and a financial service organization customer.

24. The carrier memory medium of claim 23, wherein selecting the first task object comprises moving a cursor over the first task object.

25. The carrier memory medium of claim 24, wherein adding the first task object to the process map design palette comprises moving the selected first task object onto the process map design palette.

26. The carrier memory medium of claim 23, wherein the acts further comprising comprise:

selecting a second task object from the displayed plurality of task objects; and

adding the second task object to the process map design palette.

27. The carrier memory medium of claim 26, wherein the method acts further comprises comprise:

defining a processing path between the first task object and the second task object,

wherein the processing path describes a path for business product transactions to be passed from the first processing task to the second processing task in the financial service organization production system.

28. The carrier memory medium of claim 27, wherein the first task object comprises one or more output links, and wherein defining the processing path between the first task object and the second task object comprises connecting a first output link of the first task object to the second task object.

29. The carrier memory medium of claim 28, wherein the acts further comprising comprise:

selecting a third task object from the displayed plurality of task objects;

adding the third task object to the process map design palette; and

defining a processing path between the first task object and the third task object;

wherein defining the processing path between the first task object and the third task object comprises disconnecting the first output link of the first task object from the second task object and connecting the first output link of the first task object to the third task object.

30. The carrier memory medium of claim 27, wherein the acts further comprising comprise:

selecting a third task object from the displayed plurality of task objects;

adding the third task object to the process map design palette; and

defining a processing path between the first task object and the third task object;

wherein the first task object is a decision task object configured to pass a business product transaction to one of the first and second tasks objects as a function of data relating to the financial service organization customer associated with the business product transaction.

31. The carrier memory medium of claim 23, wherein the first task is an invoke external interface task, wherein the invoke external interface task launches an external interface that transfers information between the financial service organization production system and outside sources.

32. The carrier medium of claim 23, wherein the carrier medium is a memory medium.