Controller system for interfacing with a work flow management system6725224Abstract A work flow system (15) comprises a controller (20) and a work flow processor (40). An indexing user interface (21) and a work flow processing user interface (22) interact with work flow processor interface components (23). An administration setup user interface (25) and an integration setup user interface (26) are linked to setup components (27) which generate and access a reference database (28) and a transaction database (29). The reference database (28) stores an organization model and a process model and an interface (23) controls the work flow processor (4) according to these models. Claims What is claimed is: Description FIELD OF THE INVENTION
Scanning/ A scanning interface, an image processor, and an image
capturing 2: database which are all part of the block 41.
Batch Indexing components 23 receiving user instructions
indexing 3: from the UI 21 and controlling indexing resources in the
block 41.
Item The indexing components 23 referred to above. They
indexing 4: split a batch into items which are transferred to the block
42 under control of the dispatcher 24.
Work item Work item components receiving user instructions from
processing 5: the UI 22 and controlling the block 42.
User valid- User validation components 23 which are activated by
ation 6: all UIs 21, 22, 25, and 26.
Browse/ Browse/fetch components 23 interfacing with the UI 22
fetch 7: and using the databases 28 and 29.
Find/view 8: Browse/fetch components 23 which are configured to
perform find and view operations only according to the
organisation model in the reference database 28. These
components access only the transaction database 29 for
data, not the work flow processor 40.
Completed A background completion process in the block 42 calls a
Work Item: completion component 23.
MIS 10: Database procedures in the reference database 28 and in
the transaction database 29.
The block 23 comprises a JAVA.TM. environment of packages which are used by the user interfaces 21, 22, 25, 26. The user interfaces call different views of the JAVA.TM. environment using polymorphic objects which facilities re-use of code within the environment. The databases 28 and 29 have a structure which is mapped to the JAVA.TM. object environment. For example, for each work item object there is a row in a work item table. The components 23 present themselves to the user interface environment through platform-dependent component wrappers. There is a different set of component wrappers for interfacing with the work flow process 40. The components 27 are developed in VBTM and the following is an example of code for a component which "clones" a path and a process. VB Code (ClonePath and CloneProcess)
Public Sub ClonePath()
Dim objPath As Path
Dim lClonePathID As Long
On Error GoTo errHandler:
FunctionCode = "107"
Screen.MousePointer = vbHourglass
'// Set up control for new path
mPurpose = ucNEWPATH
'// OK button
Call mOKButton
'// Get the parent process from the database
Set mobjProcess = mcolProcesses(tvProcesses.SelectedItem.Parent.Key)
lClonePathID = Val(Mid$(tvProcesses.SelectedItem.Key, 4))
Set mobjPath = mobjProcessFactory.GetPath(lClonePathID)
mLoadControl mobjProcess
mConfigurePath
txtProcessName.Text = ""
Screen.MousePointer = vbDefault
Exit Sub
errHandler:
RaiseEvent ErrorOccurred(Err.Number, "",
sPassOnErrorDescription(ComponentCode, FunctionCode, StepCode,
Err.Description))
End Sub
Public Sub CloneProcess()
Dim lProcessID As Long
On Error GoTo errHandler:
FunctionCode = "102"
Screen.MousePointer = vbHourglass
'// Set up control for clone process
mPurpose = ucCLONEPROCESS
'// OK button
Call mOKButton
'// Get the collection key
lProcessID = Val(Mid$(tvProcesses.SelectedItem.Key, 4))
'// Get a copy of the clone process from the database
Set mobjProcess = mobjProcessFactory.GetProcess(lProcessID)
mLoadControl mobjProcess
txtProcessName.Text = ""
Screen.MousePointer = vbDefault
Exit Sub
errHandler:
RaiseEvent ErrorOccurred(Err.Number, "",
sPassOnErrorDescription(ComponentCode, FunctionCode, StepCode,
Err.Description))
End Sub
The components 23, under user instructions from the user interface 22 maintain the transaction database 29. This is a simple set of tables, initialised to hold data relating to such things as audit trails and comments. In more detail, the transaction database 29 stores data in relational table structures. The data includes the following: Indexing fields used to route a work item to a correct address initially. Audit history of all past transactions for each work item. Comments linked with the audit data, as inputted by the users. Process status information setting out the current process step for the work items. The transaction database 29 therefore includes all data which is required for a find/view operation 8. The components 8 only need to access the transaction database 29 for such an operation. The transaction database 29 includes a database procedure which autonomously performs MIS operations. The reference database 28 has a relational table structure. This structure defines organization and process models which are created by the set-up components 27 and are subsequently maintained by these components to cater for business organization changes. The organization and process models are used by the components 23 to interface with the work flow processor 40. The structure of the reference database 28 is very important. It defines the manner in which the work flow is controlled for the particular business organization. The set-up components 27 under instructions via the administration user interface 25 set up the organization model. This comprises relational tables for each of: organization members, member types, accountability, and accountability types. There is a one-to-many relationship between records in each of the member and accountability type tables and records in the member and accountability tables respectively. The organization model also includes "tray" tables defining "trays" which link members to work flow processing generally. The tray is analagous to a manual or physical member work in-tray. The tray table is in turn related to a filter table. Referring to FIG. 3 the organization model links each member 50 with a set of associates trays 51. Also, each tray 51 is associated with a work item queue 52. Each queue 52 contains work items 53. The tables defining the queues 52 and the work items 53 are a bridge between the organization and process models. The tables include expressions for phenomena and phenomenon types. For examples the following is a simple expression: Region=West (N, S, E, W) In this expression, "Region" is a phenomenon type and "West" is a phenomenon. Expressions and phenomena are used to define the organization. In the sample above, for example, the expression is used to define a geographical organization structure. The structure is completed by relationships between the member and accountability tables and phenomena and expression tables. These relationships are established in a simple and user-friendly manner using the administration user interface 25. Referring again to FIG. 3, the process model comprises process step data tables 54 and process definition tables 55. The process definition tables 55 include process and process path tables. The step data tables 54 include step type, transition and transition type tables. The process model tables are generated via the integration user interface 26. This user interface allows a user to integrate process definitions to the organization model generated by the administration user interface 25. This is achieved by linking the process model tables 54 and 55 to the "bridging" tables 52 and 53. Integration is completed, as shown in FIG. 3, by relating the transaction database tables 29 with the work item tables 53. Referring now to FIG. 4, the components 23 use the databases 28 and 29 to interface with the work flow processor 40 according to business requirements. In the illustration of FIG. 4, a process 60 comprises a series of steps A, B, C, and D. The relationship between a particular process step and queues 61 is often complex and is defined by the reduction of a set of filter definitions by a queue name, by the dispatcher/distributor 24. In the organization model (indicated by the numeral 63) a member 64 is associated with a set of trays 65. For a browse/fetch operation 7 a member selects one of his or her trays using the work flow processing interface 22. This interface under the control of the JAVA.TM. components 23, restricts the member access to only the associated set of trays 65. The selected tray is associated in the references database 28 with a dedicated filter 66 and this filter is identified by the relevant JAVA.TM. component 23. The filter 65 provides a restricted view on the queue so that only particular work items may be accessed. The nature of the access is set by the administration user interface 25 when generating the organization model. In operation, the work flow processor 40 controls image document management and queuing functions under control of the controller 20. Some of the operations require little input from the controller, such as automatic capture of image, fax, e-mail, voice and telephone message/document objects. The indexing user interface 21 of the controller controls indexing by setting values for indexing types. These are relevant to the structure of the organization. The JAVA.TM. components 23 control work distribution under instructions received from the user interface 22 and using the databases 28 and 29. In most applications, work is usually created either by a telephone call or as a result of incoming correspondence by post, fax, or email. Incoming correspondence is scanned in batches into the work flow processor 40. Documents are routed for either partial or full indexing. This indexing task can be performed either within the scan area or within the appropriate business department (or both). The documents are indexed by key criteria such as policy number and document type. Those documents that cannot be identified are marked as "Unidentified" and routed to an "Unidentified Post" queue. Work distribution components 23 process all indexed documents via work items, un-pend any existing work-items in the diary, and distribute the work-item to the appropriate user or team by referencing the alignment rules. These rules have been set up by the business manager and can be changed at any time using the user interface 25 or 26. An example of use of the user interface 25 is shown in the display screen of FIG. 5 named, "IDT Administrator". Also, the sample screen of FIG. 6 "IDT Client O'Brien, Caroline" illustrates the relationship between the database tables 52, 53, 54 and 55. The user can select work-items by task/work type (queue). Users may have access to browse the contents of queues, so that they can select work for processing or they may only be able to fetch the next highest priority work-item within the system. The table of FIG. 7 of the same name shows a display drawn from the member, queue, and tray tables. When a work item has been retrieved from a work queue and its associated data and document images displayed. In many instances this requires the user to process a transaction. A work item, once fetched, can be routed for further processing in a number of ways. It can be re-routed to other user or teams for further processing or passed to a next step within the process. Alternatively, the work item can be placed in an electronic diary, perhaps after a letter has been sent. When a work-item has been placed into a diary, it is allocated a diary period specified by the user, during which time the work item is not available for processing. Pended work items are not reactivated unless either specifically requested or an incoming item of correspondence triggers re-activation of the work item. In this event, if the diary date expires or an item of correspondence re-activated the work item, the work item is returned to the originating queue prior to the work item being diarised. Users are able to add a permanent note to a policy folder using a File Note component 23. When selected, this function will present the user with a form into which the user can key comments relating to the open work item. This form is stored permanently on file in the image document management system 41. An additional facility also exists for the user to add temporary comments, which are available for viewing only whilst the work item is "live" in the transaction database 29. Users can Create work from the desktop. This functionality is typically required when work is requested via a telephone call as opposed to mail. The user enters key information associated with the new work item, the work item is created and automatically routed for processing. For each of the above actions, an audit trail entry is automatically generated to provide tracking information for subsequent reporting purposes. All users are able to view the audit history of a work-item from the desktop. The transaction database 29 is used by components 8 for satisfying all find/view requests. It also provides the Audit trail and tracking data. There is generally no need for the components 23 to access the reference database 28 for find/view operations, only browse/fetch operations. The combination of the organization and process models provides a structure such as that below which defines user (member) roles. Process Model
Team A - NAC Pensions
Aligned - Northern Region Team C - Generalist
Product Process Task Product Process Task
IPP New Initial Check FB New Business Initial
Business Initial UW (without Life Check
(A) U/W Cover) Quality
Quality Check Check
Rewrite Cancellation
Initial Check
Quality Check
PTP New Initial Check
Business TV Validation
Quality Check
Organisation Model
Users Users
Name Role Step Name Role Step
Paula Team Leader ALL Richard Team Leader ALL
Brenda Case Manager Initial UW Rob Case Manager Initial
U/W Check
Quality Quality
Check Check
Steven Case Manager Initial Philip Case Manager Initial
Check Check
Quality
Check
The member work item links defined by the reference database 28 are referred to as alignment rules. These rules define how work is distributed across members, such as according to region channel customer type etc. Also, each process step or task has a set of properties defined in its table and related tables. The step properties may, for example, include step SLA, and whether case ownership is required. Case ownership determines when the same user who initiates the processing must process a work item through a certain set of steps. Also, the user interfaces 25 and 26 provide a set of control fields that enables customers to define their own additional specific task properties e.g. target task duration. These properties can be used for reporting purposes, i.e. to generate a report outlining the percentage of work completed within its target duration. The controller 20 also allows a Manager or Team Leader to mark a user as absent. The manager can assign all of the user's work to another user or to the team. Once the absent user returns the Manager can mark him/her as "present" and work is routed to the user as before. Other components 23 provide Team Leaders with an easy way of controlling the distribution of work within their team. The component displays the volume of work-items within each task/work-type queue, allowing bottlenecks to be quickly identified. Using a grid interface it shows which tasks each user is currently assigned. The team leader can balance work by assigning additional users to those tasks that have high volumes of work awaiting processing. This system 15 also supports the concept of users in training. It allows the Team Leader to indicate when a user is being trained on a specific task and what percentage of their work should be checked by a more highly skilled user. The invention is not limited to the embodiments described but may be varied in construction and detail within the scope of the claims.
|
Same subclass Same class Consider this |
||||||||||