Sign In to Follow Application
View All Documents & Correspondence

Impact Assesement In Business Processes

Abstract: A method for accessing impact of an incident is disclosed. The incident occurs while executing one or more business processes (BPs). The method includes identifying the BPs corresponding to the incident, and identifying parameters affected by the incident. A relative importance of each parameter affected by the incident is then determined. Finally, the impact of the incident on each parameter is calculated. The impact calculation is based on the relative importance of each parameter.

Get Free WhatsApp Updates!
Notices, Deadlines & Correspondence

Patent Information

Application #
Filing Date
05 April 2007
Publication Number
48/2008
Publication Type
INA
Invention Field
GENERAL ENGINEERING
Status
Email
Parent Application

Applicants

INFOSYS TECHNOLOGIES LIMITED
PLOT NO. 44, ELECTRONICS CITY, HOSUR ROAD BANGALORE, KARNATAKA-560 100(IN)

Inventors

1. REDDY, UDHAI KAKANI
NO. 150 14TH MAIN, 3RD CROSS, 4TH BLOCK, KORAMANGALA, BANGALORE - 560034(IN)

Specification

BACKGROUND
The present invention relates generally to impact assessment, and more particularly to identifying impact of system incidents.
Prioritization of system incidents is required by organizations that have Service Level Agreements (SLA) with priority levels in Information Technology service management. Prioritization of system incidents requires assessment of impact of the incidents on the system.
There are several approaches for assessing the impact of an incident. In one of the approaches, the impact is assumed or calculated and the SLA for the application is defined on parameters such as availability. The impact of the application that is not available is taken as a constant. This type of SLA works well for systems such as websites that have a constant high volume of traffic, and there is little to no difference in importance of one user or one instance of the process with another.
In another approach, broad guidelines are defined based on certain strategic objectives, for example "customer first", and support resources are expected to use knowledge gained from experience or do a detailed analysis to assess the impact of the incident. However, this approach is knowledge-intensive and requires manual effort to assess the impact of the incident.
In yet another approach, the SLA definition is in terms of acceptable impact on strategic organizational goals like loss of revenue and impact on customer satisfaction due to system or application related issues. Strategic measures like customer satisfaction may also be broken into process goals such as time taken for fulfilling an order. This approach requires determining the impact of any system or application on the defined goals before prioritizing the same.
Therefore, there is a need for a better impact assessment method that is not knowledge-intensive and requires less effort.

BRIEF DESCRIPTION
In accordance with an embodiment of the present invention, a method for accessing impact of an incident is provided. The incident occurs while executing at least one business process (BP). The method includes identifying the at least one BP corresponding to the incident, identifying parameters affected by the incident, determining a relative importance of each parameter affected by the incident, and calculating the impact of the incident on each parameter. The calculation is based on the relative importance of each parameter.
DRAWINGS
These and other features, aspects, and advantages of the present invention will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:
FIG. 1 is a flowchart depicting a method for accessing impact of an incident that occurs while executing one or more business processes, in accordance with an aspect of the present technique;
FIG. 2 illustrates an example process model for handling Caller Line Initiation (CLI) requests, in accordance with an aspect of the present technique; and
FIG. 3 depicts a flowchart for identifying business processes, in accordance with an aspect of the present technique.
DETAILED DESCRIPTION
The following description is full and informative description of the best method and system presently contemplated for carrying out the present invention which is known to the inventors at the time of filing the patent application. Of course, many modifications and adaptations will be apparent to those skilled in the relevant arts in view of the following description in view of the accompanying drawings and

the appended claims. While the system and method described herein are provided with a certain degree of specificity, the present technique may be implemented with either greater or lesser specificity, depending on the needs of the user. Further, some of the features of the present technique may be used to advantage without the corresponding use of other features described in the following paragraphs. As such, the present description should be considered as merely illustrative of the principles of the present technique and not in limitation thereof, since the present technique is defined solely by the claims.
The present invention relates to a method for accessing impact of an 'incident5 that occurs while executing Business Processes (BPs) that make use of software applications. The term incident refers to a problem that is reported in a software application, for example, system outage and data or logic problems that can occur while running a software application. The method includes identifying at least one BP corresponding to the incident, identifying parameters affected by the incident, identifying a relative importance of each parameter affected by the incident, and calculating the impact of the incident.
FIG. 1 is a flowchart depicting the method for accessing the impact of the incident that occurs while executing one or more BPs. The term impact refers to identifying a value for the incident along various identified parameters or business measures, such as customers, participants, or processes. The incident can occur either at a system such as an order management system, or software application level. At step 102, the BPs corresponding to the incident are identified. At step 104, the parameters affected by the incident are identified. At step 106, a relative importance of each parameter is determined. Finally, at step 108, the impact of the incident is calculated.
For identifying the BP corresponding to the incident, a part of the BP or process activities that are linked the incident is identified. For the purpose of identifying the BP, a process catalog, one or more process models, and system documentation is used. The process catalog refers to a catalog of the BPs that exist in an organization, which makes use of the BPs. In an aspect of the present technique,

the process catalog includes a list of BPs, corresponding process descriptions and process owners. A process model includes the process activities that are carried out to execute the BP. A process activity may be unique to the BP or part of different BPs. The process model includes linkage to system components, for example, an Electronic Data Interchange (EDI) interface. The system components can be hardware, software, or network components of the system. In an aspect of the present technique, the linkage is made available through Business Process Management (BPM) technology. In an aspect of the present technique, the linkage is created. The linkage is created by inserting program codes within the process model that link to the system components. Further, the systems components in the component catalogue are linked to either the process or an activity within the process.
The system documentation includes information pertaining to system components. Therefore, the process model is used to identify the process activities that are linked to the system or application component. FIG. 2 illustrates an example process model for handling Caller Line Initiation (CLI) requests. At step 202, a CLI request is received. At step 204, it is checked whether the CLI request is valid. If the CLI request is not valid, it is marked as 'invalid' at step 214. However if the CLI request is valid, the CLI request is sent to a switch interface at step 206. At step 208, the CLI request is processed and at step 210, response to the CLI request is received. At step 212, the status of the CLI request is updated. The steps 202, 204, 206, 210, 212, and 214 are carried out at an Order Handling and Provisioning (OHP) layer of the corresponding system while the step 208 is carried out at the switch or Service Activation Layer (SAL).
FIG. 3 depicts a flowchart for identifying the BPs. At step 302, one or more process activities corresponding to the incident are identified. At step 304, the process activities are linked to the participant, customer, or both the participant or customer involved in corresponding process activities. At step 306, the information generated at steps 302 and 304 are made available to users when they report the incident. In this way, incidents are reported against a particular BP, process activity, system or system component. In an aspect of the present technique, if the incident is raised against the BP, the BP is identified as affected. However, if the incident is

raised against the process activity, then the BPs in which the process activity exists are identified to be affected. Further, if the incident is reported against the system, then the BPs that are linked to the system directly or through the process activity are identified as affected.
On identifying the BPs corresponding to the incident, the parameters affected by the incident are identified. This step includes identifying the participants, customers, and process parameters affected by the incident. For identifying the parameters affected by the incident, process execution information for the incident is obtained. The process execution information is linked to the process model. In an aspect of the present technique, the process execution information is retrieved from a process warehouse. The term process warehouse is herein incorporated by reference from the non-patent publication titled, "Process Warehouse: The Missing Link in Business Performance Management", authored by "Nari Kannan", and published in the "DM Direct Newsletter, March 11, 2005". The process execution information includes process state, performance against process parameters such as time, participants in process instances, customers in the process instances and financial values such as of the type revenue, purchase, and the like. For the process parameter 'time', delay between an expected time and an actual time is calculated for each process as well as process instance. This delay is referred to as time impact.
Once the parameters affected by the incident are identified, the relative importance of each parameter is determined. Determining the relative importance of the parameter includes retrieving a static rating of the parameter. In one aspect of the present technique, the static rating is allocated to each parameter. An example static rating is on a scale of one to 10 with 10 being the most important and one being the least important, for example, the static rating of 10 is allocated to the participant such as Chief Executive Officer (CEO) of the organization. In another aspect of the present technique, the static rating is made available through a data warehouse. In such a case, a rating of the parameter is retrieved from the data warehouse and normalized to the static rating. This is achieved by using, for example, the formula:

Relative Importance =
xlO ...(1)
rating of the customer A
^ (total number of customers +1) j
For example, the most important customer in the organization that has 100 customers has a relative importance of 9.9. The relative importance is retrieved for the customers and participants that are affected by the incident. Static ratings of relative importance are also allocated to each BP on a scale of one to 10. This information is also retrieved for each affected BP. In this way, each parameter is rated or ranked.
Once the parameters are rated, impact of the incident on each parameter, namely participant, customer and process is calculated. The calculation is based on the relative importance of each parameter. For example, for the system, impact of the incident on the participants is given by the total relative importance of all affected participants. The impact of the incident on the customers is the total relative importance for all the affected customers. The impact of the incident on financial values is the total financial value across all affected processes instances. The impact of the incident on time is given by the sum of the time impact across all process instances. For the affected BPs, the impact is given by:
(relative importance of Pi x npi) .. .(2)
where Pj is an ith BP of the organization, and nPii is the number of instances of Pj.
For example, if BPs A and B are affected due to incidents X and Y respectively, BP B is rated as being 1.5 times important than A, and there are two instances of A and one instance of B being executed, then:
Impact of incident Y on BP B =
„. ., „ ^^ k relative importance of BP B ,_
Impact of incident X on BP A x - = ...(3)
number of instances of BP A
3
— times the impact of incident X on BP A
In this way, the impact of the incident with respect to each parameter is determined.

Once the impact is calculated, the priority of the incident is calculated based on the impact. Priority refers to the weighted sum of the impact along each of the identified parameters.
Priority of incident = (Wj * Ij) ... (4)
where Wj is the impact weight of the jth parameter. Therefore, the priority is calculated based on impact weights of each parameter and the corresponding impacts.
In one aspect of the present technique, impact weights are allocated by participants of the organization by measuring the relation of each parameter against organizational objectives. This approach is based on experience of the participants and need to be reviewed when there is a change in the organizational objectives.
The method described above has the advantage that it creates a model for automated calculation of the business impact and priorities of incidents in Information Technology (IT) service management. The method eliminates the need for knowledge resources in prioritization of incidents and increases the accuracy of prioritization by basing the same on the calculation of the impact instead of assuming an impact. The method uses the process models and process execution information to determine the impact of any system or application incident on various business measures and uses this impact to determine the relative priority of the incident.
As will be appreciated by those ordinary skilled in the art, the foregoing example, demonstrations, and method steps may be implemented by suitable code on a processor base system, such as general purpose or special purpose computer. It should also be noted that different implementations of the present technique may perform some or all the steps described herein in different orders or substantially concurrently, that is, in parallel. Furthermore, the functions may be implemented in a variety of programming languages. Such code, as will be appreciated by those of ordinary skilled in the art, may be stored or adapted for storage in one or more tangible machine readable media, such as on memory chips, local or remote hard disks, optical disks or other media, which may be accessed by a processor based system to execute the stored code. Note that the tangible media may comprise paper

or another suitable medium upon which the instructions are printed. For instance, the instructions may be electronically captured via optical scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a suitable manner if necessary, and then stored in a computer memory.
The sequence of instructions as explained in the method steps may include but not limited to program code adapted for identifying the at least one BP corresponding to the incident and program code adapted for identifying parameters affected by the incident. The method may also include program code adapted for determining a relative importance of each parameter affected by the incident and program code adapted for calculating the impact of the incident on each parameter based on the relative importance of each parameter.
While the following description is presented to enable a person of ordinary skill in the art to make and use the invention, and is provided in the context of the requirement for a obtaining a patent. The present description is the best presently-contemplated method for carrying out the present invention. Various modifications to the preferred embodiment will be readily apparent to those skilled in the art and the generic principles of the present invention may be applied to other embodiments, and some features of the present invention may be used without the corresponding use of other features. Accordingly, the present invention is not intended to be limited to the embodiment shown but is to be accorded the widest cope consistent with the principles and features described herein.
Many modifications of the present invention will be apparent to those skilled in the arts to which the present invention applies. Further, it may be desirable to use some of the features of the present invention without the corresponding use of other features.
Accordingly, the foregoing description of the present invention should be considered as merely illustrative of the principles of the present invention and not in limitation thereof.

We Claim:
1. A method for accessing impact of an incident, wherein the incident
occurs while executing at least one business process (BP), the method comprising:
identifying the at least one BP corresponding to the incident;
identifying a plurality of parameters affected by the incident;
determining a relative importance of each of the plurality of parameters affected by the incident; and
calculating the impact of the incident on each of the plurality of parameters based on the relative importance of each of the plurality of parameters.
2. The method of claim 1, further comprising calculating priority of the incident based on the impact of the incident on each of the plurality of parameters.
3. The method of claim 1, wherein identifying the at least one BP comprising using at least one of a process catalog or one or more process models or system documentation or combinations thereof.
4. The method of claim 3, wherein the one or more process models comprising linkage to system components.
5. The method of claim 4, wherein the one or more process models use business process management(BPM) technology to provide linkage to system components.
6. The method of claim 5, wherein the linkage to system components is created within the one or more process models.

7. The method of claim 1, wherein identifying the at least one BP
comprising:
identifying one or more process activities of the at least one BP that is linked to the incident;
linking the one or more process activities to the plurality of parameters corresponding to the one or more process activities; and
providing information to at least one user for reporting the incident, wherein the information is based on identifying the one or more process activities and linking the one or more process activities to the plurality of parameters corresponding to the one or more process activities.
8. The method of claim 1, wherein identifying the plurality of parameters affected by the incident comprisingat least one of identifying participants or customers or process parameters affected by the incident or combinations thereof.
9. The method of claim 8, wherein identifying the plurality of parameters affected by the incident comprising at least one of obtaining a process execution information, wherein the process execution information is linked to the one or more process models.
10. The method of claim 9, wherein the process execution information is retrieved from a process warehouse.

11. The method of claim 9, wherein the process execution information includes information for at least one of a process state or performance against process parameters or participants in process instances or customers in the process instances orfinancial values or combinations thereof.
12. The method of claim 1, wherein determining the relative importance of each parameter comprising retrieving a static rating of each parameter.
13. The method of claim 12, wherein retrieving the static rating of each parameter comprising allocating the the static rating to each of the plurality of parameters.
14. The method of claim 13, wherein retrieving the static rating of each of the plurality of parameters comprising normalizing a rating, wherein the rating is retrieved from at least one of a data warehouse and at least one business intelligence system.
15. A computer program product tangibly embodying a plurality of instructions for accessing impact of an incident, wherein the incident occurs while executing at least one business process (BP) and wherein the computer program product comprising computer-readable media having computer-readable code, the computer program product comprising the following computer-readable program code for effecting actions in a computing platform, the method comprising:
program code adapted for identifying the at least one BP corresponding to the incident;
program code adapted for identifying a plurality of parameters affected by the incident;

program code adapted for determining a relative importance of each of the plurality of parameters affected by the incident; and
program code adapted for calculating the impact of the incident on each of the plurality of parameters based on the relative importance of each of the plurality of parameters.
16. The computer program method of claim 15, wherein identifying the at least one BP comprising:
program code adapted for identifying one or more process activities of the at least one BP that is linked to the incident;
program code adapted for linking the one or more process activities to each of the plurality of parameters corresponding to the one or more process activities; and
program code adapted for providing information to at least one user for reporting the incident, wherein the information is based on identifying the one or more process activities, and linking the one or more process activities to the plurality of parameters corresponding to the one or more process activities.

Documents

Application Documents

# Name Date
1 0719-che-2007-abstract.pdf 2011-09-03
1 719-CHE-2007 FORM-13 12-01-2011.pdf 2011-01-12
2 719-CHE-2007 POWER OF ATTORNEY 12-01-2011.pdf 2011-01-12
2 0719-che-2007-claims.pdf 2011-09-03
3 719-CHE-2007 FORM-13 12-01-2011.pdf 2011-01-12
3 0719-che-2007-correspondnece-others.pdf 2011-09-03
4 719-che-2007 form-1 12-01-2011.pdf 2011-01-12
4 0719-che-2007-description(complete).pdf 2011-09-03
5 0719-che-2007-drawings.pdf 2011-09-03
5 0719-che-2007-form 5.pdf 2011-09-03
6 0719-che-2007-form 1.pdf 2011-09-03
6 0719-che-2007-form 3.pdf 2011-09-03
7 0719-che-2007-form 1.pdf 2011-09-03
7 0719-che-2007-form 3.pdf 2011-09-03
8 0719-che-2007-drawings.pdf 2011-09-03
8 0719-che-2007-form 5.pdf 2011-09-03
9 0719-che-2007-description(complete).pdf 2011-09-03
9 719-che-2007 form-1 12-01-2011.pdf 2011-01-12
10 719-CHE-2007 FORM-13 12-01-2011.pdf 2011-01-12
10 0719-che-2007-correspondnece-others.pdf 2011-09-03
11 719-CHE-2007 POWER OF ATTORNEY 12-01-2011.pdf 2011-01-12
11 0719-che-2007-claims.pdf 2011-09-03
12 719-CHE-2007 FORM-13 12-01-2011.pdf 2011-01-12
12 0719-che-2007-abstract.pdf 2011-09-03