Patent Application
20070179833
The technical field relates to business process exceptions. More particularly, the field relates to management of exceptions encountered by business processes.
Businesses have adopted Information Technology (IT) for automation from the early ages of computing. Starting with information storage in the 1950s, enterprises have adopted data processing, decision support systems, and automation packages like Enterprise Resource Planning (ERP) and Internet-delivered services. This has helped in improving the efficiency of the business and contributed to faster cycle times and other improvements.
In some industries, automation levels are high but, when exceptions (e.g., error conditions that can change the normal flow of a business process) occur, the handling is manual. A typical business process is a set of activities performed to achieve certain business objectives. When a business process exception occurs, expert human intervention is usually needed to resolve the exception. Most exception management systems are workflow systems that help in managing exceptions by assigning exceptions to experts but do not remove dependency on humans. These experts spend a significant amount of time to investigate and resolve a given exception and must refer to their prior knowledge of the business enterprise to do so.
Thus, there exists a need for assisted management of exceptions encountered by a business process.
Described herein are various methods and tools for the assisted management of business process exceptions.
In one aspect, a computer-implemented method of handling exceptions in a business process comprises several steps, such as identifying an exception in a business process, classifying the exception as being of a particular exception type, allocating the exception to a user or group of users, investigating the exception, and resolving the exception.
In other aspects, a business process exception management system comprises several components, such as an information store that contains the domain ontology, several different types of rules relating to exception identification, exception classification, and exception allocation, exception investigation and resolution process models, an exception monitor, a rule engine, and a process engine. In another aspect, the system also comprises an ontology modeler to construct the domain ontology, a rule builder to construct the different types of rules, and a process modeler to construct the process models.
In yet another aspect, a computer-implemented method of handling a business process exception comprises establishing a business domain ontology, creating exception handling rules/processes based on the business domain ontology, and implementing the exception handling rules/processes in a business process exception management system.
Additional features and advantages will become apparent from the following detailed description of illustrated embodiments, which proceeds with reference to accompanying drawings.
A business process is usually defined as a sequence of activities performed by roles in the business, resulting in an end-deliverable for customers of the business. Business processes enable the organization to successfully deliver its products and services. Each business process has inputs, methods and outputs. A business process can be part of a larger, encompassing process and can comprise other business processes that have to be included in its methods and can cut across organizational units.
Business processes form the core differentiation for organizations, because the sequence of activities is typically unique to every organization. Repeatable and well-engineered business processes lead to operational excellence in an organization. Optimization of business processes is hence gaining importance in the industry.
Certain categories of business processes are not very well-structured. These are usually executed by people who need to be knowledgeable in the domain. These processes usually get overlooked in process re-design and improvement programs.
Knowledge-intensive processes typically rely on specialized professional expertise, continuous learning, and transformation of information. They are usually performed by knowledge workers with a high degree of expertise and experience. Knowledge workers usually enjoy a high degree of empowerment in making decisions on how they perform their activities and to develop new ways of performing their activities as their process knowledge increases. They typically perform these activities in a fluid, unconscious manner, rather than discrete steps. It is difficult to describe and document them in process terms. Knowledge-intensive business processes may have some of the following exemplary characteristics:
The following exemplary attributes are some of the possible attributes for describing knowledge intensiveness and complexity of business processes:
On classifying business process along the dimensions of knowledge intensiveness and complexity, processes falling under the categories of weak knowledge intensity and low process complexity like order entry and fulfillment can be handled by conventional process design and IT automation techniques. However, processes with strong knowledge intensiveness such as insurance policy underwriting and exception handling often need a different approach.
Systems intended to handle knowledge-intensive business processes can often be designed using a common design approach, such as implementing the exemplary knowledge-intensive business process system 100 shown in
An exemplary IT system to address at least some of the above requirements can involve the following:
In knowledge enactment, activities involving retrieval of information from existing systems or decisions that are well-defined can be assigned to systems for processing. Activities involving human intervention and decisions which are complex can be assigned to experts. The system can recommend decisions based on the knowledge base and capture the decisions and continuously learn in the form of an information assistant which observes the workflow and information retrieval.
A business process exception is generally defined as a transaction that falls outside the range of transactions that are handled by an organization's business processes. An exception is a condition or event that triggers the need for investigation and possible resolution. For example, an error or inconsistency in values is discovered. As another example, a threshold value is met (e.g., a maximum dollar amount or a maximum transaction frequency for a given transaction).
In this example, an exemplary exception management system implemented in a financial securities domain is illustrated. Those skilled in the art will appreciate, however, that the exemplary architecture is generic and can be used to implement any similar process. The need for an exception management system 200 will be understood with reference to
The types of exceptions that need to be handled depend on the business of the enterprise and the execution of the various steps in the life-cycle of each exception type involves knowledge that is very specific to the enterprise.
Exception management is usually enterprise-specific and highly dependent on an expert's knowledge of the domain, including processes and systems involved. Thus, exception management is usually classified as being knowledge-intensive.
At 302, exceptions are identified. Exception identification typically involves identifying those transactions that need to be flagged as being exceptions. The basis for the identification of exceptions is usually very specific to an enterprise. A transaction that needs to be flagged as an exception by an enterprise might not be an exception for another enterprise.
At 304, the identified exceptions are desirably classified based on a set of classification rules. Exception classification is typically the process of tagging an exception with a particular type. The type determination is usually done based on the values of certain fields in the exception transaction.
At 306, the classified exceptions are desirably allocated. Ownership of the classified exceptions is assigned to users or groups of users based on a set of allocation rules. Exception allocation, for investigation and resolution, is typically based on the organization structure. Exceptions of a particular type or those originating from a particular system or belonging to a specific region of a company's business might need to be assigned to specific individuals or operational teams.
At 308, the assigned exceptions are desirably investigated and resolved. Exception investigation and resolution can comprise the process of having experts identify a root cause of an exception and take the necessary steps to resolve the exception. Alternatively, a set of computer processes or some combination of user interaction and computer processes can perform the investigating and/or resolving of an exception.
Steps involved in exception investigation and resolution may differ based on the exception type. An expert or computer process responsible for executing a particular step often looks at data present in various systems within the enterprise and data from partners and/or customers. The set of systems which provide this data usually differ based on the type of exception. Enterprises often have a myriad of systems implementing business processes and, thus, experts who handle exceptions use their knowledge of systems relevant to each exception type to process the exception.
The architecture of an exemplary system implementing a knowledge-intensive business process (e.g., an exception management process) desirably makes provisions for capturing knowledge that is specific to the business process. Such a system also desirably provides for implementing applications that make use of this knowledge. For purposes of illustration, consider examples from the financial securities domain. The financial securities domain usually involves various business processes such as trading, accounting, settlement, etc. Also, there are typically various entities involved (e.g., Asset Managers, Custodians, Sub-Custodians, and Brokers/Dealers) in these financial securities processes. There are often various systems (e.g., trading systems, ledger systems, settlement systems, and/or reconciliation systems) that participate in the fulfillment of these business processes. One such system is a computer-implemented reconciliation system that is responsible for reconciliation of transactions and positions related to stocks and transactions and balances related to cash coming in from an external source, such as a computer-implemented trading system and a computer-implemented balance system, with data obtained from a computer-implemented internal ledger system.
Reconciliation is typically done by the various parties involved in a given trade. Exceptions can occur when there is a mismatch between data (e.g., transactions, positions, and balances) recorded in the ledger system and that received from the trading system. These exceptions desirably are investigated and resolved to ensure that processing proceeds to the next stage in the order fulfillment process. An effective exception management architecture desirably captures knowledge to be used in investigating and resolving an exception in a knowledge base and implements application components that use the knowledge base to investigate and resolve exceptions.
At 502, exceptions from systems arrive into an exception monitor (e.g., the exemplary exception monitor 422). The exceptions might be sent from system agents (e.g., the exemplary system agents 430).
At 504, the incoming exceptions recognized by the exception monitor result in triggering a rule engine (e.g., the exemplary rule engine Error! Reference source not found.24), such as in a computer processor for processing the rules, that desirably classifies the exceptions and allocates them to specific owners (e.g., to individuals or teams). The rule engine may query a domain ontology (e.g., the exemplary domain ontology 412) for information during the classification, and allocation of the exceptions.
At 506, a process engine (e.g., the exemplary process engine 426) executes tasks that are required for investigating and resolving the exceptions based at least in part on previously-created process models (e.g., the exemplary process models 416). The process engine may query the domain ontology for information during execution of the tasks.
An ontology is generally a working model of entities and interactions between the entities either generically or in some particular domain of knowledge or practice. An ontology may take a variety of forms, but it will usually include a vocabulary of terms and some specification of their meaning. This typically includes definitions and an indication of how concepts are inter-related, which collectively impose a structure on the domain and constrain the possible interpretations of terms. One definition of an ontology is the specification of conceptualizations, used to help programs and humans share knowledge, where a conceptualization is the couching of knowledge about the world in terms of entities (e.g., things, the relationships they hold, and the constraints between them), and a specification is the representation of such a conceptualization in a concrete form. One step in such a specification is the encoding of a conceptualization in a knowledge representation language. A desirable goal is to create an agreed-upon vocabulary and semantic structure for exchanging information about the domain. The main components of an ontology are usually concepts, relations, instances and axioms. A concept typically represents a set or class of entities or “things” within a domain. Relations usually describe the interactions between concepts or a concept's properties. Instances are generally the “things” represented by a concept. Finally, axioms are usually used to constrain values for classes or instances.
The exemplary knowledge base 410 of
The set of concepts and relationships between concepts in the business domain along with specific instances of concepts and relationships constitute the domain ontology 412 of
Once the ontology definition is complete, the instance information for some of the concepts can be captured. For example, instances of systems and user groups captured in the ontology can be used by runtime components to identify the specific system (and associated attributes, such as version, IP address, and operating platform) that an exception originates from, the process it corresponds to, and other related attributes that are required for processing the exception.
The identification, classification, and allocation of exceptions can be based on certain rules, such as the set of rules 414 in
When an exception management system receives exceptions generated by various systems, the exceptions are desirably classified. The classification of exceptions often involves electronically tagging or identifying each exception based on certain rules. Once the domain ontology has been modeled, such exception classification rules can be expressed formally using elements of the domain ontology. A sample classification rule that can be expressed in the C Language Integrated Production System (CLIPS) is shown below in Table 1. The CLIPS example is shown because of its support for frame-based knowledge bases with COOL (CLIPS Object-Oriented Language). However, the rule can be expressed in other languages as well.
In the example, the classification rule checks for an occurrence of a “Ledger Transaction Not Found” string in the reason description. If the reason description matches the string, the exception type is classified as Missing Ledger Stock Transaction.
The classified exception is desirably allocated to users or user groups responsible for resolving exceptions. Allocation rules, such as the sample allocation rule shown below in Table 2, are desirably electronically captured in the knowledge base 410. The user or user group to whom the exception is allocated usually owns (e.g., is responsible for) the exception and is thus responsible for resolving the exception. An enterprise may have a specific organizational structure for dealing with exceptions of various types. For example, Stock Transaction Reconciliation Exceptions of type “Missing Ledger Stock Transaction” belonging to a particular region may need to be allocated to the person or team responsible for addressing such exceptions for the region. Such policies can be expressed formally using rules such as the sample allocation rule in Table 2.
In the example, the allocation rule checks for the type and region name of the exception. If the exception is of the type Missing Ledger Stock Transaction and the region in which the exception has occurred is Asia Pacific, the exception is allocated to STOCK_APAC_DESK1, which is an instance of the concept ExceptionOwner in the domain ontology. The interrelationship of the exception, product, market, and region concepts captured in the domain ontology enables easy editing of allocation and classification rules.
Once an exception has been assigned to an owner, the exception is usually subjected to a sequence of steps to be investigated and resolved. The sequence of steps can be captured as a sequence of tasks using a process model. A task may be manual (e.g., a person performs some actions) or automated (e.g., a software agent looks up some information in a system). Based on the outcome of each task, the next task to be executed can be determined. Irrespective of whether a particular task is manual or automated, the business domain ontology can be used as an effective aid for capturing information that is needed for the execution of tasks.
BPMI.org has defined the Business Process Modeling Language (BPML) standard for modeling and defining processes. Process models can be captured using BPML. Use of BPML allows for the modeling of both manual and automated tasks in a process. When a process is modeled, each task can be associated with the software function that performs the task. For example, a manual task can be associated with a user interface and an automated task can be associated with a system agent. When a process engine orchestrates such a process, it can invoke the software function that is associated with the current task. When a manual task is encountered, the user interface can be displayed to the concerned user, such that the user can input the necessary information after performing the manual task. Similarly, when an automated task is encountered, the corresponding system agent can be invoked so that it can fetch the relevant data from a system. The use of a domain ontology can help in formally defining the information to be displayed to a user for performing a manual task and the information required by a software agent for performing an automated task. When the process executes, instances of the domain ontology concepts can be used as actual values for the manual or automated tasks.
A domain ontology can be used to express the information required for executing the conditions/tasks. For example, the condition 702 labeled as “Trade Ref No. Present?” can be represented formally using an expression referring to ontology elements such as “StockTransactionReconciliationException.tradeRefNum=NULL?” Similarly, the task 704 labeled “Check Ledger System” can be mapped to a software agent that accepts as inputs “StockTransactionReconciliationException.sourceSystem.ledgerSystem,” “StockTransactionReconciliationException.tradeRefNum,” etc. When a process engine (e.g., exemplary process engine 426 in
Exemplary runtime components 420 in
The exception monitor 422 of the exemplary exception management system architecture 400 of
The rule engine 424 of the exemplary exception management system architecture 400 of
Rules composed using an ontology usually need to be executed in a rule engine. That the rule engine 424 supports a frame-based knowledge base is typically preferred.
The process engine 426 of the exemplary exception management system architecture 400 of
The activities involved in a process should be orchestrated based on the exception that needs to be investigated and resolved. A process engine that provides support for execution of manual/system activities can help. For example, a Business Process Modeling (BPM) or Workflow product can serve as a process engine. The tasks that use ontology descriptions can be translated to the Business Process Modeling Language (BPML). An ontology access Application Programming Interface (API) to allow for a process engine to execute tasks based on the ontology specification can be helpful.
Exemplary System Agents
The system agents 430 of the exemplary exception management system architecture 400 of
A frame-based ontology representation language can provide a way of modeling a business domain ontology. An editor such as Protege (an open source ontology/knowledge-based editor) that provides functionality for visual modeling of frame-based ontology can be used for modeling an ontology. Such an editor can provide an intuitive and powerful way of modeling concepts and inter-relationships between the concepts.
Once a business ontology has been modeled using frame-based ontology representation techniques, it can be serialized for aiding in machine interpretation. Use of the Extensible Markup Language (XML) represents a standards-based serialization technique. The World Wide Web Consortium (W3C) has recently developed standards such as Resource Description Framework (RDF) and Web Ontology Language (OWL) for representing an ontology in XML format. An ontology, once converted to such machine-interpretable standard formats, can be used by other components of an exception management system.
Ontology and knowledge (e.g., instances) should be stored. For some systems (e.g., an exception management system), persistence of ontology/knowledge in a relational database can provides its own advantages. An ontology middleware such as Sesame can be used for persisting/querying ontology/knowledge present in a relational database.
Exemplary Business Domain Ontology to System Meta-Data Map
Data corresponding to the instances of the business domain ontology concepts may be present in systems spread across the enterprise. Such systems have their own meta-data for representing/storing data. If a system uses a relational database for data persistence, the database scheme defines the system meta-data. The business domain ontology forms a common conceptual model of data spread across the organization. Hence, this needs to be mapped to the system meta-data so that data in heterogeneous systems can be easily referred/extracted using a common conceptual model.
Exemplary Ontology-Based Rule Builder
A business domain ontology can serve as the basis for the composition of various kinds of rules (e.g., exception identification, classification, and allocation rules). This can be achieved if a computer-implemented interface for ontology-based rule building is provided. For example, a computer-implemented ontology-based rule-building layer can be built on top of existing computer-implemented rule engines.
A business domain ontology can serve as a foundation for modeling processes (e.g., exception investigation and resolution processes). A computer-implemented layer can be built on top of existing computer-implemented process modelers to enable the writing of task executions using the computer-implemented domain ontology.
With reference to
A computing environment may have additional features. For example, the computing environment 900 includes storage 940, one or more input devices 950, one or more output devices 960, and one or more communication connections 970. An interconnection mechanism (not shown) such as a bus, controller, or network interconnects the components of the computing environment 900. Typically, operating system software (not shown) provides an operating environment for other software executing in the computing environment 900, and coordinates activities of the components of the computing environment 900.
The storage 940 may be removable or non-removable, and can include magnetic disks, magnetic tapes or cassettes, CD-ROMs, CD-RWs, DVDs, or any other medium which can be used to store information and which can be accessed within the computing environment 900. The storage 940 stores instructions for the software 980 implementing methods of automated relationship traceability between software design artifacts.
The input device(s) 950 may be a touch input device such as a keyboard, mouse, pen, or trackball, a voice input device, a scanning device, or another device that provides input to the computing environment 900. For audio, the input device(s) 950 may be a sound card or similar device that accepts audio input in analog or digital form, or a CD-ROM reader that provides audio samples to the computing environment. The output device(s) 960 may be a display, printer, speaker, CD-writer, or another device that provides output from the computing environment 900.
The communication connection(s) 970 enable communication over a communication medium to another computing entity. The communication medium conveys information such as computer-executable instructions, compressed graphics information, or other data in a modulated data signal.
Computer-readable storage media are any available tangible media that can be accessed within a computing environment. By way of example, and not limitation, with the computing environment 900, computer-readable media includes memory 920, storage 940, or some combination thereof.
The various tools and systems such as, but not limited to, a rule engine (e.g., the exemplary rule engine 424 of
Having described and illustrated the principles of the disclosed technology with reference to the illustrated embodiments, it will be recognized that the illustrated embodiments can be modified in arrangement and detail without departing from such principles. Elements of the illustrated embodiment shown in software may be implemented in hardware and vice versa. Also, the technologies from any example can be combined with the technologies described in any one or more of the other examples. In view of the many possible embodiments to which the principles of the disclosed technology may be applied, it should be recognized that the illustrated embodiments are examples and should not be taken as a limitation on the scope of the disclosed technology. For instance, various components of systems and tools described herein may be combined in function and use. We therefore claim as our invention all subject matter that comes within the scope and spirit of the following claims.
