US20140372386A1

Movatterモバイル変換

Info

Publication number: US20140372386A1
Application number: US14/470,140
Authority: US
Inventors: Vikram Duvvoori; Satish Venkatesan Srinivasan; Prasad A. Chodavarapu; Ravindra S. Gajulapalli; Rajesh Ramesh Agrawal
Original assignee: HCL America Inc
Current assignee: HCL America Inc
Priority date: 2011-06-10
Filing date: 2014-08-27
Publication date: 2014-12-18
Also published as: US20120317081A1; US8825609B2

Abstract

A method and system comprising a duplication identifier module to analyze data input information to automatically identify duplicate expected inputs associated with a process are shown. The system includes logical process model information defining a logically structured series of process activities and data input information representing a plurality of expected inputs associated with respective process activities, with each expected input being indicative of expected collection of a corresponding data element during execution of the associated process activity. Each duplicate expected input comprises one of the plurality of expected inputs for which there is at least one other expected input with respect to a common corresponding data element.

Description

CROSS-REFERENCE TO RELATED APPLICATION

This patent application is a continuation of U.S. patent application Ser. No. 13/158,038, filed Jun. 10, 2011, the specification of which is incorporated herein by reference.

TECHNICAL FIELD

The present application relates generally to the technical field of methods and systems for modeling, analyzing and managing processes. An example embodiment relates to methods and systems to perform computer-assisted process modeling.

BACKGROUND

Process modeling in systems engineering and software engineering relates generally to modeling or mapping a process or a number of processes in an enterprise. Such process modeling may facilitate analysis and improvement of the process (for example, serving to facilitate the analysis of a manufacturing process, a business process, or the like).

Process modeling may therefore be useful for process management. A process model may comprise structured information not only about the sequence and relationship of respective activities constituting a process or processes, but may also define relationships of process activities to other process elements or components, such as information technology (IT) systems, human resources, and the like. In certain embodiments, a business process model may therefore be part of a larger encompassing enterprise model. The latter may facilitate enterprise resource and/or business process analysis and management.

A process model may also be used to generate a graphical representation of process information. Visual modeling languages used to represent processes include Business Process Modeling Notation (BPMN) and the Event-driven Process Chain (EPC).

BRIEF DESCRIPTION OF THE DRAWINGS

Some embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings in which:

FIG. 1 is a schematic block diagram of a process modeling system in the example form of an enterprise model system interfaced with an enterprise system, in accordance with an example embodiment.

FIG. 2 is a schematic block diagram of process model application(s) forming part of the example process analysis system.

FIG. 3 is a schematic diagram of a data structure of process model information, according to an example embodiment

FIG. 4 is a high-level schematic diagram of an example system for detecting wasteful data collection in a process.

FIG. 5 is a high-level view of a value chain forming part of an enterprise model, according to an example embodiment.

FIG. 6 is a lower-level view of the example enterprise model ofFIG. 5, diagrammatically showing functional decomposition of one of the elements of the value chain.

FIG. 7 is another lower-level view of the enterprise model ofFIG. 5, diagrammatically illustrating the key processes in one of the functions ofFIG. 6.

FIG. 8 is diagrammatic view of an example of a process model, showing a series of expected inputs associated with respective process activities.

FIG. 9 is a high-level flow chart of an example method of detecting wasteful data collection in a modeled process.

FIG. 10 is a schematic flow chart illustrating a method of detecting wasteful data collection, in accordance with an example embodiment.

FIG. 11 is a schematic flow chart illustrating a method of analyzing process model information, in accordance with an example embodiment.

FIG. 12 is a diagrammatic representation of a machine in the example form of a computer system within which a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein may be executed.

DETAILED DESCRIPTION

Example methods and systems to generate a process model or enterprise model and to perform automated analysis of the process model are described. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of example embodiments. It will be evident, however, to one skilled in the art that other embodiments may be practiced without these specific details.

According to an example embodiment, there is provided a system and method to generate a process model that includes logical process model information and associated data input information with respect to expected inputs associated with respective process activities of a process. There is also provided a system and method to perform analysis, using one or more processors, of process model information to process data collection efficiency of a process represented by the process model.

The process model information may comprise, at least: a logical process model defining a plurality of activities forming part of the process, with the logical process model specifying relationships between the respective activities; and data input information regarding expected inputs associated with process activities. The process model information may further comprise: IT system dependency information indicative of dependency of respective activities on associated IT system elements, with the IT system dependency information including datastore dependency information indicative of one or more datastores which may be accessed in execution of respective activities; and data dependency information indicative of the dependency of process activities on data in the one or more datastores which may be accessed in execution of respective activities.

The term “process” as used herein comprises a series of activities to produce a product or perform a service, and is to be interpreted broadly as including a process group, a sub-process, or any collection of processes. Therefore, the totality of activities and/or processes which may be performed in an enterprise may also be referred to as a process. In instances where the process model information is therefore with respect to an enterprise, such as a business enterprise, the process model information may thus be in the form of an enterprise model.

The term “data” as used herein refers to any information items that a process may depend upon or utilize and is to be interpreted broadly as including master data, reference data, transaction data, event data, analytical data, meta-data, text or binary content, and the like.

Differently defined, the process model information may be in the form of the logical process model together with operationalization data regarding various components utilized for operationalization of the process and on which process activities may be dependent. The logical process model may include a sequence in which activities of the process are performed; rules determining subsequent activities to be performed; service-level agreements (SLAs); key performance indicators (KPIs); and the like. The operationalization data may include human resource roles for performing respective activities; IT systems supporting respective activities; data dependency information regarding respective activities; data input information indicating expected inputs, which may be associated with particular process activities and/or process participants; physical infrastructure associated with respective activities, such as vehicles, machinery, and the like; and other elements associated with the process. In instances where the process model is in respect to a business enterprise, the resultant enterprise model may therefore depict, specify, or map the workings and interrelationships of all elements that make up an enterprise. Enterprise elements or process elements modeled in such an enterprise model may include a value chain, business domains/sub-domains, business functions/sub-functions, processes, activities, information/data, IT applications, IT hardware, human resources, physical assets, and any other elements relevant to the enterprise.

It is to be appreciated that the term “logical process model” refers to the depiction, specification, or mapping of a series of activities of an associated process, excluding process operationalization elements (e.g., IT system components, human resource information, and data input information).

“Process element” means any element of the process model, including IT hardware, IT applications, human resource components, datastores, physical elements, events, and the like.

The data input information may comprise information regarding the collection of data during performance of the process. The data input information may therefore include a plurality of expected inputs, each expected input being associated with one of the process activities. Each expected input may indicate a particular data element or data item which is to be inputted or collected during performance of an associated process activity. The data input information may further include a source type identifier associated with each expected input, to identify a type of source from which the relevant data element is received. The data input information may yet further include, with reference to each expected input, a duplication acceptance indicator to indicate whether or not a process designer or editor accepted duplication of inputs with respect to the associated data element, and/or a duplication reason indicator to indicate a reason provided by the process designer or editor for input duplication. The terms “duplicate expected input” or “repetitive expected input” as used herein refers to an expected input for which there is at least one other expected input with respect to a common corresponding data element within a particular process or part thereof. The data input information may include forms for collecting a plurality of data elements, the forms optionally being linked to or associated with respective process activities.

The system may further include data state information indicative of the quality and/or availability of data in one or more datastores, which may be accessed in execution of respective activities. The data state information may include data quality information indicative of the data quality of data in at least one datastore forming part of the process system. The data quality information may include data aging information, data validity, data accuracy, data completeness, data consistency, data integrity information, or the like.

It is to be appreciated that the data input information is distinct and separate from, on the one hand, data dependency information, and, on the other hand, data state information. The data state information is with respect to the state and/or quality of data in the process during operation, while the data dependency information is with respect to the dependency of process activities on particular data elements and/or data stores for performance of those process activities. In contrast, the data input information provides a design-time indication of the collection of particular data elements by respective process elements/participants.

The system may include a duplication identifier module to automatically identify duplicated expected inputs and an alert generator to generate a duplication alert in response to identification of expected input duplication. The system may further include an efficiency calculation module to calculate a data collection efficiency value based at least in part on the identified duplicate expected inputs.

Another aspect provides a method comprising:

associating a plurality of expected inputs with respective process activities of a logical process model comprising a logically structured series of process activities in a process, each expected input being indicative of collection of a corresponding data element during execution of the associated process activity; and

using one or more processors, analyzing the plurality of expected inputs to calculate a data collection efficiency value with respect to the logical process model, the data collection efficiency value being calculated based at least in part on the identification of repetitive expected inputs with respect to at least one data element

Yet another aspect may provide another method comprising:

storing in at least one database a plurality of expected input entries indicative of respective data elements to be inputted into a process system in the execution of a process;

storing in association with each expected input entry information illustrating one or more of a plurality of process activities during which the corresponding data element is to be inputted; and

storing in association with at least one of the plurality of expected input entries a duplication reason indicator to indicate that repetitive expected input entries with respect to the corresponding data element is intentional.

Architecture

FIG. 1 is a network diagram depicting a client-server system100, within which one example embodiment may be deployed. A networkedenterprise model system102, in the example form of a dynamic process modeling system, provides server-side functionality, via a network104 (e.g., the Internet, a Wide Area Network (WAN), or a Local Area Network (LAN), to one or more clients.FIG. 1 illustrates, for example, a web client106 (e.g., a browser, such as the Internet Explorer browser developed by Microsoft Corporation of Redmond, Wash. State) and aprogrammatic client108 executing on

respective client machines

110 and112.

An Application Program Interface (API)server114 and aweb server116 are coupled to, and provide programmatic and web interfaces respectively to, one ormore application servers118. Theapplication servers118 host one or more process model applications120 (seeFIG. 2). The process model applications, in this example, are enterprise model applications. The application server(s)118 are, in turn, shown to be coupled to one or more databases server(s)124 that facilitate access to one or more database(s)126.

Thesystem102 is also in communication with a process system which supports a process that is to be modeled by the process model application(s)120 (e.g., business process models (BPM)). In the example embodiment, the process system is aclient enterprise system140, which supports a business enterprise. Thesystem102 of the example embodiment ofFIG. 1 is therefore an enterprise model system, while, in other embodiments, similar or analogous systems may be process model systems for processes such as manufacturing processes, distribution processes, or the like. The process model application(s)120 may be in communication with components of an IT system of the enterprise, in particular being in communication with a number of

process servers

142,144 forming part of the IT infrastructure of theclient enterprise system140. Each of the

process servers

142,144 supports one or

more process applications

146,148, with each

process application

146,148 providing functionalities employed in the performance of an associated activity or process supported by theenterprise system140. Each

process server

142,144 may be in communication with one or more associated database(s) or process datastore(s)150,152, to read and/or write associated process data to the respective process datastore(s)150,152.

For example,process application146 may be an accounting application, with the process data in the associated process datastore(s)150 comprising client account information, whileprocess server144 may be a case management application, with the process data in the associated process datastore(s)152 comprising records of respective cases processed by theenterprise system140. It will be appreciated that theenterprise system140 may typically comprise a greater number of

process servers

142,144 and

process datastores

150,152 than are shown inFIG. 1, but for ease of explanationFIG. 1 shows only two

such process servers

142,144. It is further to be appreciated that communication and interfacing between

respective process servers

142,144 may occur via thenetwork104, while some of the

process servers

142,144 may be in direct communication.

The process model application(s)120 may provide a number of functions and services to users that access the enterprise model system102 (for example, providing analytics, diagnostic, predictive and management functionality relating to system architecture, processes, and the activities of the enterprise supported by the enterprise system140). Respective modules for providing these functionalities are discussed in further detail with reference toFIG. 2 below. While all of the functional modules, and therefore all of the process model application(s)120, are shown inFIG. 1 to form part of theenterprise model system102, it will be appreciated that, in alternative embodiments, some of the functional modules or process model applications may form part of systems that are separate and distinct from theenterprise model system102.

Further, while thesystem100 shown inFIG. 1 employs a client-server architecture, the example embodiments are, of course, not limited to such an architecture, and could equally well find application in a distributed, or peer-to-peer, architecture system, for example. The process model application(s)120 could also be implemented as standalone software programs, which do not necessarily have networking capabilities.

Theweb client106 accesses the process model application(s)120 via the web interface supported by theweb server116. Similarly, theprogrammatic client108 accesses the various services and functions provided by the process model application(s)120 via the programmatic interface provided by theAPI server114.

Process Model Application(s)

FIG. 2 is a block diagram illustrating multiple functional modules of the process model application(s)120 ofenterprise model system102. Although the example modules are illustrated as forming part of a single application, it will be appreciated that the modules may be provided by a plurality of applications. The modules of the application(s)120 may be hosted on dedicated or shared server machines (not shown) that are communicatively coupled to enable communications between server machines. The modules themselves are communicatively coupled (e.g., via appropriate interfaces) to each other and to various data sources, to allow information to be passed between the modules or to allow the modules to share and access common data. The modules of the application(s)120 may furthermore access the one ormore databases126 via the database servers128.

The enterprise modelenterprise model system102 may therefore provide a number of modules whereby a user may build or define a process model(s) or enterprise model for theenterprise system140, monitor the execution of activities forming part of the process, and perform automated diagnostic or predictive analysis of the process model. To this end, the application(s)120 are shown to include at least one defaultprocess model module216 to provide default process models. In instances where the process model is in respect to a business enterprise, the defaultprocess model module216 may provide default BPMs, which are to serve as bases for a user to define a business process model specific to theenterprise system140. The default BPMs may be predefined by a supplier of the business process model application(s)120 and are in respect to generic business processes relating to a variety of types of businesses or types of business activities. A user may thus, as a starting point for defining an enterprise-specific BPM, select one or more default process models which most closely approximate the business processes performed by theenterprise system140. The defaultprocess model module216 may typically provide default logical process models indicating a series of activities, without specific operationalization information indicating particular process elements or support elements on which the activities are dependent.

A model building/editing module204 is provided to enable a user or administrator to define a specific process model, either by editing, adapting, or building on a selected default process model, or by building a process model from scratch. The terms administrator, user, designer, and editor are used interchangeably herein to indicate a person who performs design-time activities with respect to the process model. The model building/editing module204 also enables the editing of the process model in response to changes in theprocess system140 or the associated processes. As mentioned above, such a process model may represent sequences and relationships of business processes and business process activities, as well as the relationships of such business process activities to the IT infrastructure,

process applications

146,148, expected inputs, and process data. An example enterprise model is described in greater detail with reference toFIGS. 4-7 below.

As described above, theenterprise model system102 may include logical process model information together with data input information to indicate a plurality of expected data inputs. The logical process model information may define a plurality of activities forming part of the process and may define the relationship between activities, such as the sequence in which activities are performed, and/or rules determining choices between respective activities. Dependency information defines process elements which contribute to performance of respective process activities. The dependency information may include IT system dependency information, which defines IT system elements, such as software and hardware components, contributing to respective activities. The dependency information may further include human resource dependency information, which defines particular human resources, people, or personnel contributing to respective activities. The dependency information may also include, as part of the IT system dependency information, datastore dependency information that indicates the relationship between respective activities and associated datastores that are accessed during execution of the respective activities.

The process model application(s)120 further include a graphic user interface (GUI)module200 to generate and manage an interactive GUI to display various aspects of the process model and to permit user management of the process model. In instances where all the processes of theenterprise system140 are defined in a process model (e.g. instances where the process model is an enterprise model), it is typically not possible to display a representation of all of the processes and/or an entire business architecture in a single view, and the GUI will allow user selection of different levels or layers of the enterprise model for viewing. Such drill-down functionality is described in greater detail below with reference toFIGS. 4-7.

Adata input module214 provides functionality to permit the input of data for use in process model analysis. Information about scheduled downtime for the

process applications

146,148 and/or scheduled downtime for IT infrastructure elements may, for example, be input via thedata input module214. Similarly, in an example embodiment, human resource scheduling information, such as information about personnel availability (e.g., holiday calendars) may also be input into theenterprise model system102. Thedata input module214 may be configured for manual input of this information, and may instead or in addition provide for automatic integration of scheduling data from other databases. For example, personnel unavailability data may automatically be obtained from a Human Resources database (not shown) forming part of theenterprise system140.

Arules engine202 may be provided to permit the definition of metrics by which the performance of business processes is to be measured. A user may thus provide, via therules engine202, failure definitions that specify what constitutes failure of a particular business process. In an example embodiment, the business process model may include SLAs which specify, in measurable terms, contractual service commitments describing the minimum performance criteria an associated process is required to meet. Failure to comply with the requirements of an SLA may be specified as constituting failure of the associated process. Therules engine202 may further enable the definition of performance indicators, such as KPIs, in relation to respective processes or process activities. Such performance indicators serve to provide quantifiable performance measurement of an associated process or process activity.

The model building/editing module204 may include aninput association module240 to effect user provision of expected inputs. The provision of expected inputs may comprise the association of particular data elements with specified process activities. A user may thus specify that a particular data element is to be received by a particular process entity in an associated process activity. Theinput association module240 may also permit a user to input information regarding a type of source from which the expected input is to be received. The system may further include aduplication identifier module220 to identify duplicate expected inputs in a particular process or part thereof. Theduplication identifier module220 may therefore be configured to identify when more than one expected input with respect to a common data element is associated with the process activities of the logical process model.

The process model application(s)120 may further include analert generator242 to automatically generate a duplication alert in response to the identification of expected input duplication by theduplication identifier module220. Thealert generator242 may, for example, be configured to generate a duplication alert upon entry of an expected input by association of a particular data element with a process activity, if that particular data element already forms part of an expected input associated with another process activity. The alert generator may also be configured to prompt the user to accept or reject the identified duplicate expected input, and/or to provide a reason for the particular duplicate expected input.

Aforms module248 may provide form design functionality with respect to forms to be used in the process for data collection or input. Theforms module248 may therefore provide a user the functionality to design a form layout and to define one or more data elements which are to be collected by means of the form. Such a form may, in some embodiments, be presented in a GUI having one or more GUI elements, such as text boxes or the like, for receiving respective data inputs. Design of a form by way of theforms module248 may thus include the association of each GUI element with a respective data element. A form designed by means of theforms module248 may be associated with a particular process activity at the outset or after completion of designing the form. Theduplication identifier module220, as well as thealert generator242, may cooperate with theforms module248 to provide design-time duplication identification and duplication alerts. A user may thus be alerted to duplication of expected input upon the association of a particular data element with a form (if the form has already been associated with a particular process activity) or upon association of the form with one of the process activities.

Instead, or in addition, the process model application(s)120 may include a forms import/conversion module244 to facilitate design of forms in applications which may not be integrated with the process model and the subsequent importation of such forms into the process model. A user may, for example, wish to design forms in an application such as MS Visio™ or MS Excel™ and thereafter to associate these forms with respective process activities. The forms import/conversion module244 may serve to convert and import such forms, while facilitating expected input duplication identification by theduplication identifier module220 and the generation of a duplication alert by thealert generator242. Such form input/conversion may be performed in a batch process.

The process model application(s)120 may further include aquality analyzer module246 to analyze and/or enforce consistency in data element definition within the process model and its associated forms. Thequality analyzer module246 may, for example, compare a data element defined by a process designer or user in a form, or explicitly associated with a process activity, with a data enterprise model. The data enterprise model may comprise a list of data elements for use in the process model and may therefore effectively function as a dictionary for data element definitions in the process model. Thequality analyzer module246 may, in response to a failure to identify an exact match in the data enterprise model for a user-provided data element, identify alternative data elements based on semantic and/or phonetic similarities between the user-provided data element and the alternative data elements. Thequality analyzer module246 may then suggest the alternative data elements to the user.

The process model application(s)120 may further include adata gathering module224 to gather and collate, at runtime, information regarding the performance of respective processes and/or activities. To this end, thedata gathering module224 may cooperate with monitoring applications (not shown) installed in each of the

process servers

142,144 and/or client machines (not shown) forming part of theenterprise system140. Thesystem102 may thus gather and record information regarding activities performed by respective elements forming part of theenterprise system140. A data event, such as data synchronization, data collation, or data transfer between two data repositories, may be logged or recorded, to facilitate tracking or monitoring of performance of the associated business activities.

To this end, the application(s)120 may include aprocess monitoring module206 to monitor performance of the processes defined in the process model. Data gathered by thedata gathering module224 may thus automatically be compared to process activities which are scheduled according to the process model, thereby to identify process event failures. Theprocess monitoring module206 may further compile historical data regarding system failures. Such historical data may, in particular, include applications failure history, infrastructure failure history, physical infrastructure failure history, and the like. An application failure may, for example, include failure of a process application to execute, while an infrastructure failure may comprise unscheduled downtime of a server or unavailability of communication links between system components.

To facilitate process management, the process model application(s)120 may include aload projection module212 to calculate a projected load on particular processes and/or activities defined in the enterprise model. “Load” means the amount of work that is performed by a process at a particular point in time or over a particular period. The load on a particular process or process activity may, for example, be calculated as a number of cases scheduled to be processed. A “case” is an instance of a process. For example, in a process for generating invoices, a particular case may refer to a specific invoice generated for a particular customer. Load projection may be calculated with respect to a particular process step or activity, with respect to a specified process or sub-process, with respect to a process group, or with respect to the entirety of the enterprise model. Theload projection module212 may be configured to calculate the load projection based, in part, on current load information, which may be gathered by thedata gathering module224.

A processmodel analysis module208 may provide for automated or computer-assisted analysis of the process by analysis of the process model. Analysis functionality provided by the processmodel analysis module208 may include analysis of the data collection efficiency of the process. To this end, the processmodel analysis module208 may include anefficiency calculation module230 to calculate a data collection efficiency value based at least in part on duplicate expected inputs identified by theduplication identifier module220. The processmodel analysis module208 may also provide the functionality of comparing the data collection efficiency of an as-is process with that of a to-be process or comparing the data collection efficiency of separate processes.

Data Structures

FIG. 3 is an entity-relationship diagram, illustrating various memories, tables, data repositories, or databases that may be maintained within the database(s)126 (FIG. 1), and that may be utilized by the process model application(s)120. The database(s)126 may include logicalprocess model information310 representative of processes and activities performed by theenterprise system140. The logicalprocess model information310 includes alogical process model312 comprising structured data defining process activities included in the process and showing relationships between respective process activities. In the current example, thelogical process model312 may be a logical process model defining the sequence of process activities abstractly, without defining the relationships of the activities or processes to process elements associated with operationalization of the process, which may be provided by thedependency information302. Thelogical process model312

references failure definitions

314 which may includeSLAs316 andKPIs318. Thefailure definitions314,SLAs316, andKPIs318 may be user-specified via the rules engine202 (FIG. 2).

Thesystem102 may includedata input information350 regarding a plurality of expected inputs associated with respective process activities of thelogical process model312. Information regarding each expectedinput352 may comprise adata element identifier354, identifying a particular data element which is to be collected during performance of the process, together with aprocess activity identifier356, identifying an associated process activity of thelogical process model312 during which the particular data element is to be collected. It will be appreciated that although in the embodiment illustrated with reference toFIG. 3, thedata input information350 and the logicalprocess model information310 are shown to be stored separately, with each expectedinput352 being linked to a particular process activity of thelogical process model312 by its associatedprocess activity identifier356, different data structures may be employed in other embodiments, such as, for example, storingdata element identifiers354 in direct association with respective process activities in the logicalprocess model information310, so that thedata input information350 effectively forms part of the logicalprocess model information310.

Each expectedinput352 may have associated therewith asource type identifier360 to identify the particular type of source from which the associated expectedinput352 is to be collected during execution of the process. Thesource type identifier360 may identify one of a predetermined plurality of source types, for example, identifying a source type selected from the group comprising an external organization, an internal organization, and a computer application/system.

Thedata input information350 may further include aduplication acceptance indicator362 associated with each expectedinput352. Theduplication acceptance indicator362 may serve to indicate that a user has accepted that the expectedinput352 associated with theduplication acceptance indicator362 is a duplicate expectedinput352. As is explained in greater detail below, a user/designer may automatically be alerted, in response to generating an expectedinput352 by associating a data element with a process activity, to the fact that the newly generated expectedinput352 is a duplicate expected input, and may be prompted to indicate whether or not the duplicate expected input is to be accepted. In response to affirmative indication from the user/designer, aduplication acceptance indicator362 may be associated with the newly generated expectedinput352.

Thedata input information350 may further include aduplication reason indicator364 illustrating a reason for duplication of the associated expectedinput352. The information represented by theduplication reason indicator364 may again be gathered from a user/designer upon generation of the expectedinputs352. It will be appreciated that intentional input duplication may be included in a process for a variety of reasons. In one embodiment, a user may be prompted to select one of a predetermined list of duplication reasons, for example, from a drop down menu. In such a case, the predetermined list of duplication reasons may include a state change of data, validation from compliance/risk of correctness perspective, requirement from a tracking perspective, and an update on existing data. Thesource type identifiers360, theduplication acceptance indicators362, and theduplication reason indicators364 may form part ofmetadata358 associated with the respective expectedinputs352. In one embodiment, the entry of asource type identifier360 may be mandatory, in that the entry of asource type identifier360 is a prerequisite for creating an expected input.

Thedata input information350 may yet further include linkedforms366 comprising a plurality of forms that may be used during execution of the process to collect information or inputs. Each linkedform366 may comprise layout information indicating the visual layout of the form, together with information of the data elements that are to be collected by means of the form. In instances where the form is to be presented on a GUI of a terminal or a computer, the linkedform366 may define a plurality of user interface elements forming part of the form, and may associate particular data elements that are to be collected with particular user interface elements of the form. The data input information may additionally include information indicating particular process activities of thelogical process model312 with which respective linkedforms366 are associated. It will be appreciated that expectedinputs352 can thus be created by explicitly associating data elements ordata element identifiers354 with respective process activities, or, instead, a user/designer may create forms which include information indicating the data elements collected by the forms, and may thereafter associate such forms with respective process activities, thereby creating the linked forms366. Association of a linkedform366 with a particular process activity may automatically result in the creation of one or more expectedinputs352, with each data element to be collected by the form automatically being associated with the relevant process activity to which the form has been linked.

The process model application(s)120 may also access anenterprise data model370 that comprises a list of data elements in thesystem102. Theenterprise data model370 may therefore function effectively as a data element dictionary, to facilitate consistency in the use ofdata element identifiers354. As described in greater detail below, semantic and/or phonetic similarity searches may automatically be conducted upon the entry by the user of a data element identifier, and alternative data identifiers from theenterprise data model370 may be suggested to the user if no exact match to thedata element identifier354 entered by the user can be found in theenterprise data model370. Information in theenterprise data model370 may be arranged according to an entity to which respective data element identifiers pertain. For example, address information may be grouped together, so that data element identifiers for an address line, a city address, a state identifier, a zip code, and a zip extension code may be grouped together under an “address” group.

Thedatabases126 may further may includedependency information302 comprising structured information regarding dependencies of respective processes and/or process activities of the enterprise model. Thedependency information302 may include ITsystem dependency information304 that comprises information regarding process dependency on IT system elements of theenterprise system140. The ITsystem dependency information304 may thus include information regarding dependency of processes or activities on software such as

process applications

146,148, as well as dependency on IT infrastructure. The ITsystem dependency information304 also includes datastore dependency information indicative of relationships between respective activities and datastores that are accessed in performance of the respective activities. The ITsystem dependency information304 enables the generation of an interactive GUI displaying those process applications and process servers on which a selected process or process activity is dependent.

Thedependency information302 may further include humanresources dependency information306 in which is stored structured information regarding the dependency of respective processes or process activities on particular human resource components, such as people or personnel. TheHR dependency information306 may, for example, specify the job role or personnel department responsible for the performance of a particular process activity. Physicalinfrastructure dependency information307 may also be included in thedependency information302 to indicate the dependency of respective process activities on physical infrastructure components. Such physical infrastructure components may include, for example, vehicles, machinery, supply-chain elements, buildings, and the like.Data dependency information308 may illustrate the dependency of process activities on data in the one or more datastores which may be accessed in execution of respective activities.

Thesystem102 further compriseshistorical data320 indicative of past performance of processes defined in thelogical process model312, as well as being indicative of the latest state of process elements and data in respective datastores. Thehistorical data320 may preferably be gathered in real-time or near real-time, optionally being gathered upon performance of the respective processes or process activities. Instead, or in combination, thehistorical data320 may be gathered at predefined times or intervals.Historical data320 may includeapplications failure history322 indicative of failure of

process applications

146,148, as well as ITinfrastructure failure history324 indicative of past failures of IT infrastructure elements, such as

process servers

142,144. Thehistorical data320 may further include physicalinfrastructure failure history327 with respect to failure of physical infrastructure elements, such as vehicles, machinery, and the like. Humanresource performance history323 may also form part of thehistorical data320, to provide information regarding historical performance of particular human resource components such as personnel, personnel departments, operational units, and the like. Thehistorical data320 may further includedata state information326 indicative of the current or latest recorded state of data in respective datastores of theenterprise system140. In some embodiments, the generation and storage ofhistorical data320 may be omitted.

Scheduling information

340 may be provided to facilitate risk analysis or predictive analysis. The scheduling information may include:applications downtime schedules342 indicating scheduled unavailability or downtime of

process applications

146,148; ITinfrastructure downtime schedules344 indicating scheduled unavailability of IT infrastructure elements or components, such as

process servers

142,144;physical infrastructure schedules345 indicating scheduled availability of physical infrastructure elements; andhuman resource schedules346, which may include holiday calendars or personnel unavailability schedules, to indicate when personnel, people, or other human resource components supporting the process are scheduled for unavailability. In some embodiments, the generation and storing ofscheduling information340 may be omitted.

Thedatabases126 may furthermore includeload information370 regarding a current and a projected load on respective elements in the process. In particular, theload information370 may include information on applications load372 indicative of current and projected load on

process applications

146,148;IT infrastructure load374 indicative of current and projected loads on the IT infrastructure theenterprise system140;physical infrastructure load375 indicative of current and projected loads on physical infrastructure elements; and information regarding current and projected load onhuman resources376. Provision of theload information370 facilitates analysis of the business process model, and may be particularly useful in load balancing management analysis, but in some embodiments, the generation and storing ofload information370 may be omitted.

As illustrated inFIG. 3, the process model application(s)120 may access the logicalprocess model information310, thedata input information350, theenterprise data model370, thedependency information302, thehistorical data320, thescheduling information340, and theload information370 during process model creation/editing and/or during process analysis. In particular instances, theduplication identifier module220, forming part of the process model application(s)120, may access thedata input information350 and the logicalprocess model information310 to identify duplicate expectedinputs352.

FIG. 4 is a high-level entity relationship diagram of an example configuration of aprocess model system400. Thesystem400 may include acomputer402, which may include aduplication identifier module220 to perform analysis ondata input information350 with respect to logicalprocess model information310, to identify the duplicate expected inputs. Like numerals indicate like elements inFIG. 3 and inFIG. 4.

Thesystem400 includes a number of databases or memories to store the logicalprocess model information310 and thedata input information350. It is to be noted that these databases are illustrated as separate entities, but that process model information can instead be stored in a single database, or in a greater number of dispersed databases, while the process model information may be stored either internally in thecomputer402 or may be stored externally. In this context, the terms database and memory are to be understood as being equivalent.

GUIs

The concepts described above will now be further explained by way of example with reference to extracts from example GUIs that may be generated by theGUI module200, according to an example embodiment.FIG. 5 indicates an example graphical representation of a value chain diagram500 providing an overview of an example process defined by a process model, which may be an enterprise model. The value chain represents the chain of business activities that generate value for an enterprise. The example value chain diagram500 is with respect to a business that provides credit card services to customers. The value chain diagram500 represents the highest level of the enterprise model and comprises, at the highest level, a series of organizational units. In this example, the value chain diagram500 comprises the organizational units ofMarketing502; Customer Services, Operations and Finance/Accounting504; Credit andRisk Management506; andCollections508.

It is to be noted that, at the highest level of the value chain, different enterprises in a particular industry or field of business may be somewhat similar. For example, all computer chip manufacturing firms may have a similar sequence of elements, such as fabrication. However, the enterprise model includes further levels, which indicate the organization of the particular enterprise, and in such low levels there may be great differences between respective enterprises in the same field. The particular organization of an enterprise may be influenced by the scale of operations, the history of the enterprise, and a variety of other factors. For instance, two cable television (TV) companies operating in adjacent markets and offering near identical products may be completely different in their organization at lower levels. In other examples, the value chain diagram may decompose the enterprise process, at a high level, according to business domains. In this regard, “business domain” is understood as a particular line of business. For example, in a financial services organization, domains can include Deposits, Loans, Investments, and Insurance. Such domains can be further decomposed in sub-domains. A business domain of Loans can, for instance, be comprised of Corporate and Personal sub-domains.

As illustrated inFIG. 5, the value chain diagram500 specifies the functional decomposition of each of theorganizational units502 to508 in respective series of functions or processes. Thus, for example, the organizational unit of customer services, operations and finance/accounting504 is comprised of a series of functions or processes. A user can view further organizational details or functional decomposition of each of the functional processes constituting theorganizational unit504, by selecting the associated function or process in the GUI. Organizational units may thus be categorized by the function they perform. It is to be noted that functions may be specific to a business domain/sub-domain or may be shared across domains/sub-domains. For example, recruiting and other human resource functions may be shared functions, while, for instance, warehouse operations may be specific to a sales and distribution area of a large retailer.

FIG. 6 indicates a functional decomposition diagram600 of the function of Transaction Processing andManagement510, specifying a series of sub-functions which includesDispute Management610. The diagram600 ofFIG. 6 is thus a lower-level view of one of the functions forming part of the diagram500 ofFIG. 5, and it will be appreciated that each of the functions shown inFIG. 5 may similarly be viewed at a lower-level or in greater magnification.

Likewise, diagram700 inFIG. 7 shows yet further functional decomposition of the sub-function ofDispute Management610, which comprises a series of processes forming part of theDispute Management610 sub-function. One of these processes is Monthly Billing of Presentments andRe-Presentments710. A user can select any one of the processes ofFIG. 7 to view a process model specifying a series of activities comprising of the process, as well as dependency information of the process activities. It is to be appreciated that decomposition of a process into a series of process activities may be provided at the level of the enterprise model. In this example embodiment, aspects relating to the detection of wasteful data collection and the identification of duplicate expected inputs will be further described with reference to a customer on-boarding process520 referenced at a high level inFIG. 5.

FIG. 8 shows a suppliers, inputs, process, outputs, and customers (SIPOC) diagram800 representative of such an example process model for the process of customer on-boarding520 (FIG. 5. It is to be appreciated that the user may thus drill down to a specific process model, as exemplified by the various levels of the enterprise model illustrated inFIGS. 4-7. The number of levels of the enterprise model may vary depending on the complexity of the enterprise.

Theprocess800 may include a logical process model indicating a sequence of activities802-814. Entities responsible for performance of the respective process activities are indicated in the diagram ofFIG. 8 by location of blocks representing the activities802-814 in one of a number of bands or “swim lanes”830-842.

The customer on-boarding process is initiated by the provision ofbasic customer information850, atblock802, by a customer830. In the current example, thebasic information850 comprises the following data elements, with respectivedata element identifiers354 provided in parenthesis: a customer name (Cust_Name), an organization with which the customer is associated (Cust_Org), a customer e-mail address (Cust_Email), a customer telephone number (Cust_Phone), and a customer address (Cust_Address). Each of the data elements comprising thebasic customer information850 is associated with the operation of providing customer information, atblock802, and is therefore an expected input in theprocess800.

Thisbasic customer information850 is used by a customer relations management system (CRM)832 to update abilling system836, atoperation804. Such updating may comprise provision of thebasic customer information850 to thebilling system836 by theCRM system832. A customer service representative (CSR)838 may thereafter check, atoperation808, whether or not the customer is an existing customer. To this end, theCSR838 references an enterprise content management system (ECM)842. If, atdecision block810, it is determined that thebasic customer information850 is with respect to a new customer, then theCSR838 performs the operation, atblock812, of creating a new customer in anunderwriting system840. The new customer is therefore created with reference to thebasic customer information850, which is provided to theunderwriting system840 by theCSR838. If, however, it is determined, atdecision block810, that the information is with respect to an existing customer, as would be indicated by the existence of acustomer record854 for the particular customer in theECM842, then theCSR838 performs the operations, atblock814, of updating the customer record in theECM842.

The process may include the provision ofadditional customer information852 with respect to the customer830 by anagent834. In the present example embodiment, the data elements provided as part of theadditional customer information852 may comprise a customer telephone number (Cust_Phone), a customer e-mail (Cust_Email), an industry segment to which the customer is active (Cust_Segment), and a customer's estimated revenue (Cust_Revenue). As can be seen inFIG. 8, theadditional customer information852 provided by theagent834 is consumed by theCRM system832. After provision of theadditional customer information852, thecustomer service representative838 may again check, atblock808, whether or not the customer has a record in theECM842. If acustomer record854 has already been created, then theCSR838 may update thecustomer record854, atoperation814.

Flowcharts

FIG. 9 illustrates, at a high level, a flowchart for amethod900 of detecting wasteful data collection in a process. The method comprises associating expected inputs with respective process activities, atblock902, and thereafter automatically identifying duplicate expected inputs, at block904. By automatically identifying duplicate expected inputs and bringing such duplicate expected inputs in a defined process, such as that described with reference toFIG. 8, to the attention of a user who is designing the process, the process may be optimized to minimize wasteful data collection. Automatic identification of duplicate expected inputs may also be used to assess data collection efficiency of a particular process or part thereof.

A more detailed exemplary method will now be described with reference toFIG. 10, in which flowchart1000 illustrates a sequence of operations in the method. The example embodiment ofFIG. 10 will be described with reference to anenterprise model system102 ofFIGS. 1-3, and with reference to theexample process800 ofFIG. 8. First, a user (also referred to herein as a designer or administrator) may design or edit theprocess800, atblock1004, by use of the model building/editing module204.

The building or editing of the process may include associating data elements with respective process activities by use of theinput association module240, atblock1008, to create expected inputs. As used herein, an expected input means an indication of expected collection of a particular data element during execution of the associated process activity. In the present example embodiment, the user may provide a data element identifier354 (FIG. 3) associated with the respective process activity, for each expected input. For example, expected collection of a customer name (Cust_Name) during provision of customer information, at block802 (FIG. 8), represents a single expected input. Table 1 below illustrates a list of the expected inputs associated with theprocess800 ofFIG. 8.

Associating data elements with process activities may also include providing additional information regarding the type of source that provides each expected input. For example, the user may specify, with respect to each expected input, whether the expected input is to be provided by an external entity (identified by thesource type identifier360 “External”), by a person internal to an organization responsible for executing the process (“Internal”), or by a system, such as theECM842 or the CRM system832 (“System”). In the present embodiment, themethod1000 may enforce mandatory provision of a source type with respect to each expected input. To this end, the user may be prompted, atblock1010, to enter the source type of the relevant data element. The prompt generated atblock1010 may include a drop down list from which the user is to select an appropriate source type, in order to proceed.

TABLE 1

			Source Type
No	Process Activity	Data Element ID	ID

1	Provide Customer Info	Cust_Name	External
2	Provide Customer Info	Cust_Org	External
3	Provide Customer Info	Cust_Email	External
4	Provide Customer Info	Cust_Phone	External
5	Provide Customer Info	Cust_Address	External
6	Update BillingSystem	Cust_Name	System
7	Update Billing System	Cust_Org	System
8	Update Billing System	Cust_Email	System
9	Update Billing System	Cust_Phone	System
10	Update Billing System	Cust_Address	System
11	Provide Additional Customer Info	Cust_Phone	External
12	Provide Additional Customer Info	Cust_Email	External
13	Provide Additional Customer Info	Cust_Segment	External
14	Provide Additional Customer Info	Cust_Revenue	External
15	Create Customer in UW System	Cust_Segment	Internal
16	Create Customer in UW System	Cust_Name	Internal
17	Create Customer in UW System	Cust_Email	Internal
18	Create Customer in UW System	Cust_Phone	Internal
19	Create Customer in UW System	Cust_Address	Internal
20	Create Customer in UW System	Cust_Revenue	Internal
21	Update ECM System	Cust_Revenue	Internal

The identification of duplicate expected inputs, atblock1024, comprises determining whether or not thedata input information350 already includes an expectedinput352 with respect to the particulardata element identifier354. Thus, for example, if the user first enters the expected inputs with respect to the operation of providing customer information (represented byblock802 inFIG. 8), and thereafter associates the data element relating to a customer telephone number (Cust_Phone) with the operation of providing additional customer information (represented byblock806 inFIG. 8), theduplication identifier module220 will determine that the data element identifier “Cust_Phone” is already associated with another process activity, and that the expectedinput352 which the user is attempting to create is therefore a duplicate expected input. In other words, the dataduplication identifier module220 determines that there is at least one other expectedinput352 with respect to a common corresponding data element (Cust_Phone). In some embodiments, a duplicate expected input will only be identified if the respective expectedinputs352 relating to the common data element are associated with different process activities. In other embodiments, duplicate expected inputs may also be identified in instances where a particular data element is associated more than once with the same process activity.

In response to identification of a duplicate expectedinput352, atblock1024, thealert generator242 automatically raises a duplication alert, atblock1028. The user is prompted by the duplication alert to accept or reject the identified duplicate expected input, atblock1032. If the duplicate expected input is rejected, the user may edit or redesign the process, or may select a different data element for association with the relevant process activity, atblock1008. In theexample process800 ofFIG. 8, the collection of the data element Cust_Email in the provision of additional customer information, atblock806, may be omitted, for example by changing an associated form to remove collection of the customer e-mail therefrom.

If, however, the user accepts the identified duplicate expected input, the duplicate expected input is recorded as part of thedata input information350. However, a duplication acceptance indicator362 (FIG. 3) is stored in thedata input information350 in association with the duplicate expected input, indicating that the user/designer has accepted duplication of the particular expected input. The raising of duplication alerts, atblock1028, may in some embodiments be limited to identified duplicate expected inputs obtained from an external source.

The user may also be prompted, atblock1036, to provide a reason for duplication of an expected input. In a particular embodiment, the user may be presented in a GUI with a predetermined list of reasons for duplication of expected inputs. Such reasons may include to track changes in the state of data, to validate data from a compliance/risk perspective, that duplication is a requirement from a tracking perspective, and to update existing data. In response to provision of the reason for duplication, atblock1036, aduplication reason indicator364 reflecting the user input in this regard, together with theduplication acceptance indicator362 and asource type identifier360, may be associated, atblock1040, with the newly created expectedinput352 asmetadata358 in thedata input information350 of thesystem102. The operations represented byblocks1012 through1040 may be repeated for each data element associated by the user with a respective process activity.

Instead of, or in addition to, explicit association of individual data elements with respective process activities, atblock1008, the association of particular data elements with process activities, to reflect expected inputs, may be effected through the creation or editing of forms which are associated with process activities. To this end, theforms module248 provides a functionality whereby a form may be associated with a particular process activity, atblock1060, whereafter form layout and content may be defined, atblock1064, and data elements may be associated with the form, atblock1068. Theforms module248 may provide interactive functionality, so that upon association of a particular data element with the form, data quality analysis may be performed by thequality analyzer module246 and expected input duplication may be identified by theduplication identifier module220. The operations represented byblocks1012 through1040 inFIG. 10 may thus be repeated for each data element that is associated with one of the process activities, atblock1068.

A further alternative method of creating expected inputs may comprise the preparation of forms in a computer application which is not compliant with theduplication identifier module220. A user may thus generate forms, atblock1070, in an application such as MS Word™, MS Excel™, or MS Visio™, and may thereafter import such forms, atblock1074, by use of a forms import/conversion module244. In some embodiments, the forms import/conversion module244 is configured to permit batch import of a plurality of forms that may have been created in the noncompliant applications. When such a noncompliant form is imported by thesystem102 and is converted to be compliant with the logicalprocess model information310 anddata input information350,operations1012 through1040 may be performed with respect to each data element or data element identifier included by the user in the form.

InFIG. 11, aflowchart1100 is shown, representing an exemplary embodiment of a method for analyzing thedata input information350 to assess data collection efficiency of a process or part thereof. First, a user selects, atblock1104, a process or a part of a process for consideration, in order to calculate a data collection efficiency value for the selected process or part thereof. Thereafter, process analysis is performed, atblock1108, by the processmodel analysis module208.

The process analysis comprises, atblock1112, identifying duplicate expected inputs forming part of thedata input information350 associated with the selected process. The identification of duplicate expected inputs is effected by theduplication identifier module220 and is similar or analogous to the operation performed with reference to block1024 inFIG. 10, as described above. The identification of duplicate expected inputs, atblock1112, with reference to theexample process800 described with reference toFIG. 8 and Table 1, may return results of such as that contained in Table 2 below.

TABLE 2

Data		Data	Source
Element ID	Process Activity	Provider	Type	System

Cust_Email	Provide Customer Info	Customer	External	CRM
Cust_Phone	Provide Customer Info	Customer	External	CRM
Cust_Phone	Provide Additional	Agent	External	CRM
	Customer Info
Cust_Email	Provide Additional	Agent	External	CRM
	Customer Info
Cust_Revenue	Provide Additional	Agent	External	CRM
	Customer Info
Cust_Revenue	Update ECM System	CSR	Internal	ECM

Theprocess analysis1108 may further include, atblock1120, identifying a source type for each duplicate expected input, based, for example, on the associatedsource type identifiers360. Duplication weights may thereafter be allocated to each of the identified expected duplicate inputs, atblock1124. In an example embodiment, a relatively high duplication weight may be allocated to all duplicate expected inputs that are provided by entities external to theprocess system102. Duplicate inputs that are received from, for example, customers and external organizations may therefore be provided with a relatively high duplication weight. It will be appreciated in this regard that more severe data quality issues may be caused by inaccurate or inconsistent data input, and that the likelihood of such inaccurate or inconsistent data input being received from external entities is greater than the likelihood of inaccurate data inputs being provided by internal entities. Additionally, duplicate inputs required from external agents may be frustrating to such entities, and unnecessary input duplication may result in reduced custom or agent satisfaction and increased business impact. A medium weight may be applied to duplicate expected inputs, which are provided by an internal entity, such as employees or agents of a company or organization executing theprocess800. The internal entities to which a medium duplication weight may be applied are human actors or internal organizations, as opposed to computer systems or applications. Expected duplicate inputs that are provided by internal applications or computer systems may be provided a lowest duplication weight. In the present example embodiment, expected duplicate inputs from an external source maybe allocated a weight value of 3, while expected duplicate inputs from internal sources may be allocated a weight value of 2, and expected duplicate inputs from computer applications or systems may be allocated a weight value of 1. Table 3 shows application of the above-described weightage method to the example process ofFIG. 8.

Following the allocation of duplication weights, atblock1124, an efficiency value calculation may be performed, atblock1128. In the present example embodiment, the efficiency value calculation comprises division by the total number of data elements that are to be collected in the analyzedprocess800 of the cumulative duplication weight values for theprocessor800. In other words, the allocated duplication weights for the duplicate expected inputs are summed, and the cumulative value of duplication weights is thereafter divided by the count of data elements that are to be collected in theprocess800. With reference to Table 3, it will be seen in that the total of allocated duplication weight values for theprocess800 is 8, while the number of data elements to be collected in the process is 7 (as can be seen with reference to Table 1, which includes 7 unique data element identifiers). The efficiency value calculation, atblock1128, will therefore, with reference to the example process ofFIG. 8, return a data collection efficiency value of 1.14, which may be outputted on a graphical user interface, atblock1132. It will be appreciated that a higher data collection efficiency value indicates lower data collection efficiency or more wasteful data collection, while a data collection efficiency value of 0 would indicate no inefficiency in data collection.

TABLE 3

		Source	Duplicate	Weight/	Duplication
Data	Source	Type	Count	Duplicate	Weight

Cust_Phone	Agent	External	1	3	3
Cust_Email	Agent	External	1	3	3
Cust_Revenue	CSR	Internal	1	2	2
Total					8

The calculation of a data collection quality ratio or data collection efficiency value as described above may be used to provide an indication of the data collection efficiency of a process in isolation and/or may be used for comparing the data collection deficiencies of two or more processes. Theprocess analysis1108 may, for example, be used to compare the data collection efficiency of an as-is process with a to-be process, in order to assess the effect of possible changes to a process on the data collection efficiency of the process. A user may thus, atblock1140, generate a to-be process after having obtained a data collection efficiency value for a process in its current form. The generation of the to-be process may typically comprise the addition, operation, or deletion of process activities, a change in the sequence of process activities, and/or the combination of two or more existing processes. Data input conflicts in the to-be process may automatically be identified, atblock1142, and may be brought to the attention of the user by the raising of a conflict alert, atblock1146. The processmodel analysis module208 may thus, for example, identify when the original collection of a particular data element is omitted. Process redesign may, for example, inadvertently omit a process activity in which a particular data element is originally collected, which would negatively affect downstream processes that consume that particular data element. A user may, in response to such a conflict alert, reinstate the omitted process activity, or may include collection of the particular data element in another process activity.

In addition to automatic identification of data element conflicts, the processmodel analysis module208 may identify a list of data elements that may be affected by a particular change in the process or in a form associated with the process. The user may thus indicate a particular change and may request a list of data elements affected by the change. Such analysis may also be performed in order to identify a list of systems and databases utilizing potentially conflicting data, and may analyze the impact of a change to the process and/or forms in this regard. For example, if a user contemplates the removal from theprocess800 ofFIG. 8 of collection by theagent834 of the data element Cust_Email, then the processmodel analysis module208 may provide the user with a list of system elements and forms that use that data element.

The processmodel analysis module208 may also be utilized to facilitate process optimization, by analyzing and reporting to a user details regarding the use by the process and process elements of particular data elements. A user may, for example, select the data element or data field Cust_Email for analysis with respect to theprocessor800 ofFIG. 8. In response to such a request, the processmodel analysis module208 may provide the following information for the data field Cust_Email:

“Cust_Email”

1. Input into CRM system 1 time.

2. Output by CRM system 2 times.

3. Referenced by billing system 1 time.

4. Input by external user 2 times.

This information may be used to redesign or edit the process in order to improve data collection efficiency.

In another embodiment, thedata input information350 may be analyzed to determine a significant or critical source (or so-called golden source) for a particular data element, and a conflict alert may be raised if collection of a data element from its critical source is deleted or omitted in the to-be process. Instead, or in addition, the method may include analyzing thedata input information350 to assess or determine the importance of respective data elements that are to be collected in execution of the process. The importance of a particular data element may be determined based on the number of times the particular data element forms part of an expected input, based on the user-providing a reason for expected input duplication, and/or based on the source type of respective duplicate expected inputs with respect to the particular data element. In this regard, greater repetition of collection of a particular data element tends to indicate greater importance of that data element. A conflict alert may be raised, atblock1146, if a unique expected input from a particular source is, for example, deleted or removed in generation of the to-be process, atblock1140.

The above described method of detecting wasteful data collection may be of particular use in the combination of existing processes, for example in the instance of the merger of two corporate entities. In such cases, repetitive collection of data elements in extensive combined processes may be difficult to detect and/or streamline. The above-described example embodiment, however, facilitates efficient data collection in such processes initially by automatically detecting duplicate expected inputs during process design/editing, and secondly by providing the functionality for calculating a data collection efficiency value for one or more processes. A method is thereby provided to define the relationship of data elements with processes forming part of an enterprise process model, and may link the data elements to an enterprise data model, to facilitate the identification of wasteful data collection.

An enterprise data model may also automatically be generated in instances where an enterprise does not yet have an enterprise data model. In such cases, an enterprise data model may automatically be generated upon the association of data elements with respective process activities, whereafter consistency with the previously entered data elements may be enforced, as described above.

FIG. 12 shows a diagrammatic representation of machine in the example form of acomputer system1200 within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a server computer, a client computer, a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

Theexample computer system1200 includes a processor1202 (e.g., a central processing unit (CPU) a graphics processing unit (GPU) or both), amain memory1204 and astatic memory1206, which communicate with each other via abus1208. Thecomputer system1200 may further include a video display unit1210 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). Thecomputer system1200 also includes an alphanumeric input device1212 (e.g., a keyboard), a cursor control device1214 (e.g., a mouse), adisk drive unit1216, a signal generation device1218 (e.g., a speaker) and anetwork interface device1220.

Thedisk drive unit1216 includes a machine-readable medium1222 on which is stored one or more sets of instructions (e.g., software1224) embodying any one or more of the methodologies or functions described herein. Thesoftware1224 may also reside, completely or at least partially, within themain memory1204 and/or within theprocessor1202 during execution thereof by thecomputer system1200, themain memory1204 and theprocessor1202 also constituting machine-readable media.

Thesoftware1224 may further be transmitted or received over anetwork1226 via thenetwork interface device1220.

While the machine-readable medium1222 is shown in an example embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies described herein. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals.

Thus, a method and system to perform an analysis of a process supported by a process system have been described. Although the methods and systems described herein have been exemplified with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of method and/or system. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

The Abstract of the Disclosure is provided to comply with 37 C.F.R. §1.72(b), requiring an abstract that will allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.