DESC:FIELD OF INVENTION
[001] The present invention relates generally to a method of performing risk analysis of data processes against data changes in an enterprise planning system. Specifically, the invention relates to a method of performing predictive and definitive risk analysis of data processes against data changes transported through a Transport Request (TR) in the enterprise planning system.

BACKGROUND OF THE INVENTION
[002] In any data system, code or configuration changes are transferred across systems through a transport request mechanism. A Transport Request (TR) comprises a container of changes (code or configuration or both) used to carry and implement changes in a target system, which is usually the production system.
[003] The introduction of changes to a data system results in the risk of business process failures or breakages in the system. Conventional methods perform various types of testing like unit testing, integration testing, regression testing, etc, to eliminate such risks. The disadvantage of the conventional methods is that their scope of such testing is limited as it is practically very difficult to cover all possible scenarios whenever changes are introduced. Another considerable challenge in the conventional methods is precisely identifying and associating processes and scenarios impacted through a given set of changes, and testing the associated processes and scenarios to eliminate the risk of failures.
[004] Due to these limitations, data and business processes break or fail in a production system after changes are introduced. This results in organizations spending considerable resources for taking reactive measures to minimize the impact of the changes and restore the data or business processes.
[005] Other conventional methods and tools available in market today to test business processes in an SAP-ERP (Systems, Applications and Products – enterprise resource planning) system use screen-based recordings of SAP transaction codes or other well-known tools like eCATT, BDC etc. The underlying principal is to execute a business process by using relevant transaction codes by running recorded scripts. In this case, the processes are executed and fulfil the criteria of being tested. However, a major flaw is that processes are not executed in an “identical” manner, and are executed only in a real-life (production) scenario. Therefore, the conventional systems are unable to capture errors or bugs fails during the process execution.
[006] Another flaw in such tools is that they use a limited set of data to be used in process execution or testing. There remains significant data, which is either not used during testing or not identical with real-life scenario. Subsequently, this gives rise to potential errors or bugs which remain undiscovered.
[007] Hence, to overcome the above-mentioned problems, there is utmost need for a method that predicts risk of failures before testing, and which provides accurate and reliable data through which potential process or scenario failures can be prevented from occurring in a live production system. The present invention accomplishes the said objective.

OBJECT OF THE INVENTION
[008] The principle object of the invention is to provide a method of providing pre-test risk analysis in business and data processes against a set of configuration data changes carried through a transport request.
[009] It is still another object of the present invention, to provide predictive and definitive risk analysis.
[0010] It is yet another object of the invention, to provide risk analysis that is carried out by testing only the data/business processes and scenarios which are linked or associated with the changed configuration objects and their respective values in a given transport request.
[0011] Yet another object of the invention is to provide linking of transport request objects and values with business processes and scenarios.
[0012] Yet another object of the present invention is to prepare a historical data that continuously collects information about all the transport requests.
[0013] It is yet another object of the invention, to provide a method of executing business processes in a manner identical to real-life data or production processes.
[0014] It is still another object of the invention, to provide identical execution of business processes for testing, review, optimization, analysis or any other purposes.
[0015] It is still another object of the present invention, to provide real-life end-to-end process maps and other process details in a business function as an input in the mirroring process.
[0016] It is yet another object of the present invention, to provide real-life data of business scenarios or test cases at each stage of the processes as another input in the mirroring process.
[0017] Yet another object of the present invention is to provide real-life processing programs, functions, interfaces, transaction codes etc. at each stage of the processes as further input in the mirroring process.
[0018] It is still another object of the present invention, to provide each stages of a process to get executed using identical processing methods and identical scenario data for obtaining mirrored process execution.

BRIEF DESCRIPTION OF DRAWINGS
[0019] This invention is illustrated in the accompanying drawings, throughout which, like reference letters indicate corresponding parts in various figures.
[0020] The embodiments herein will be better understood from the following description with reference to the drawings, in which:
[0021] Fig. 1 is a perspective view of the invention, illustrating an enterprise planning system landscape, and transporting and deploying a transport request.
[0022] Fig. 2 illustrates a sample transport request and linking data objects and corresponding object values with scenarios.
[0023] Fig. 3 illustrates an example of generating historical data over a period of time.
[0024] Fig. 4 depicts a diagram illustrating an example of lifecycle of a transport request from development system to production system in a system landscape.
[0025] Fig 5 depicts a processing method for executing a mirrored process using three inputs.
[0026] Fig 6 depicts a diagram illustrating a sample process in a sales function, to explain the mirroring method.

STATEMENT OF THE INVENTION
[0028] The present invention discloses a method of performing predictive and definitive risk analysis for changes contained in a transport request in data processes, where a method of analysing risk in an enterprise planning system is carried out by linking each object of the transport request with one or more of the data processes and corresponding data process variations or scenarios by matching one or more field data values. In a typical SAP-ERP (Systems, Applications and Products – enterprise resource planning) landscape, there are three systems. The first system is a development system where changes are made in a transport request. The second system is a test or quality system in which various tests are performed to validate the changes. The third system is a production system comprising a live system for real-life business transactions and a final target system or destination for any changes to be deployed through the transport request. When a transport request is generated and released for movement in the development system, various configuration data objects in the transport request are linked or associated with existing business processes and respective scenarios. The linkage helps in identifying only relevant scenarios and processes to be tested in a test system when such a transport request is going to be deployed in the production system. Subsequently, the identified relevant process and scenarios are sent for testing. The test result is used to analyze potential risk associated with a given transport request and its potential impact on existing business processes and scenarios. Definitive risk analysis and predictive risk analysis work together to protect the production system from process failures and ensure business continuity. Predictive risk index acts as an early-warning system whereas definitive risk index identifies the occurrence of precise point-of-failures when the transport request is deployed in the production system. The identified risk is tested using a method in which business processes are executed in an identical manner with respect to real-life or production processes. Real-life (production) end to end business processes, real-life scenarios/test cases and real-life processing programs are provided as input to mirror said business processes.
DETAILED DESCRIPTION OF INVENTION
[0029] The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and/or detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.
[0030] The present application is a combination/cognate of two Indian provisional applications. Furthermore, the present application claims priority from Indian provisional application number 201741044807 and Indian provisional application number 201741044800.
[0031] The embodiments below provide a method of testing changes in an SAP-ERP (Systems, Applications and Products – enterprise resource planning) system. Any changes in an SAP (Systems, Applications and Products) system are contained in a transport request, and the risk associated with the changes in business/data processes are determined by linking each object of the transport request with one or more of the data processes and corresponding data process variations or scenarios by matching one or more field data values. Subsequently, the business/data processes and scenarios are tested using a method in which business processes are executed in an identical manner with respect to real-life or production processes. The method provides a predictive risk index which acts as an early-warning system. The method also provides a definitive risk index which identifies precise point-of-failures that occurs when the transport request is deployed in the production system.
[0032] The method also discloses executing business/data processes in a manner identical to real-life processes, which employs three inputs. A first input are real-life end-to-end process maps and other process details in a business function. Real-life data of business scenarios or test cases at each stage of the processes are another input, while real-life processing programs, functions, interfaces, transaction codes, etc. at each stage of the processes are the third input in the execution process. Each stage of the process is executed using identical processing methods and identical scenario data for obtaining mirrored process execution. The mirroring process ensures accurate and precise comparison between real-life process and mirrored process.
[0033] In the present disclosure, changes to be moved across an enterprise resource planning system may be contained in a transport request.
[0034] In the present disclosure, elements of a transport request may be referred to as data objects.
[0035] In the present disclosure, a data object may comprise multiple object values.
[0036] In the present disclosure, the changes may comprise a code or configuration or both.
[0037] In the present disclosure, development system may comprise a system where changes are initiated.
[0038] In the present disclosure, a test or quality system may comprise a system where testing is performed for the changes.
[0039] In the present disclosure, a production system may be a live system for real-life business transactions and a final target system where changes are deployed.
[0040] In the present disclosure, a definitive risk index may comprise certain categories of outcome in a testing process.
[0041] In the present disclosure, a predictive risk index may be defined as a certain category of outcome in a testing process with respect to historical data created through continuous definitive risk index method.
[0042] In the present disclosure, historical data may refer to data prepared when definitive risk index is active, wherein the data includes continuously collecting information regarding all transport requests that are deployed to a production system, respective objects in the transport requests, test results, definitive risk index, certain category of outcome pertaining to said transport requests and respective objects in a process scenario testing.
[0043] In the present disclosure, process mirroring may refer to executing business processes in an “identical” manner with respect to real-life or production processes.
[0044] In the present disclosure, real-life scenario data may refer to data from a reference or production system.
[0045] Referring now to the drawings, where similar reference characters denote corresponding features consistently throughout the figures, there are shown in preferred embodiments.
[0046] Fig. 1 illustrates a typical enterprise planning system. The enterprise planning system comprises a transport request 110 which is raised at a development system 120, moved for testing at a test or quality system 130, and subsequently reaches a production system 140.
[0047] In an embodiment, the transport request 110 comprises multiple objects, which may be code objects or configuration data objects. One or more specific data objects and corresponding object values of the configuration data objects are included in the transport request 110, which is subsequently transported across the enterprise planning system for deploying one or more changes in the business/data processes of the enterprise planning system.
[0048] In one embodiment, data objects (not shown in Fig.1) are the elements of the transport request 110. The transport request 110 comprises either data or code or changes related to both. The changes can comprise creation, modification or deletion. The data object is related to either data or code and data objects carry their corresponding object values.
[0049] In one embodiment, after the transport request 110 has been generated and released from the development system 120, various configuration data objects are linked or associated with existing business/data processes and respective scenarios.
[0050] Fig. 2 depicts the transport request 110 comprising data objects 210/1 and 210/2, which may be referred to as data objects 210 or data object 210. The data objects 210 comprise object values 220 linked with respective scenarios 230, which are further linked to business/data processes 240. Consider object value 1 of data object 210/1. The object value 1 at 220 is linked with scenario 1, which belongs to process 1. The object value 1 at 220 is also linked with scenario 5, which belonging to process 2. Other objects 210 and corresponding object values 220 are also linked in the same manner with respective scenarios 230 that belong to processes 240. The linkage or association helps in identifying only relevant scenarios and processes to be tested in the test system 130, when the transport request 110 is to be deployed in the production system 140.
[0051] An advantage of the disclosed method is that all irrelevant processes and scenarios, regardless of their criticality are not tested unless necessary. Hence, the method provides better efficiency as unnecessary testing is avoided.
[0052] Subsequently, the relevant scenarios and processes are tested in the test system 130. The result of the testing provides a number of failed processes and respective scenarios, and any other data discrepancies between real-life and tested processes. The failures or discrepancies are precisely attributed to the transport request 110 that comprises changes belonging to given objects and corresponding values.
[0053] In one embodiment, a potential risk associated with the transport request 110 and its potential impact on existing business processes and scenarios are analyzed. The analysis is performed using the results obtained from testing relevant list of process-scenarios. The testing can result in three categories of outcomes.

Fully successful process-scenario – Green
Successful process-scenario -Yellow
Failed process-scenarios -Red
All documents in a process are generated identically to the real-life or production counterpart of the process, with no data discrepancies. This process is regarded as a green case. All documents in a process are generated but any one document has data discrepancies as compared to the real-life or production counterpart of the process. This process is regarded as a yellow case. Any one of the documents in the given process fails to get generated. This process is regarded as a red case.

[0054] In an embodiment, considering an example in a Sales function’s Order-to-Cash process, documents related to sales order, delivery and billing are generated in the production system 140.
[0055] In the test or quality system 130, if any of the above documents are not generated during testing, the category of outcome is considered as a failed process scenario, and is considered to be a RED case.
[0056] In a successful process scenario, it is first confirmed whether all documents are generated in the test or quality system 130. Subsequently, field data of each of the documents is compared with their counterpart document-fields in the real-life process of the production system 140. The comparison is made to determine any discrepancies in the values. In case any discrepancy is found with any document field, the category of outcome is considered as a successful process scenario, and is considered to be a YELLOW case.
[0057] A fully successful process-scenario occurs during identical generation of all documents in both the test or quality system 130 and its corresponding real-life or production system 140, with no data discrepancies. This is considered to be a GREEN case.
[0058] RED, YELLOW and GREEN cases are determined by analyzing each document generated at each stage of a business/data process. The results of a specific process-scenario of an object of the transport request are precisely identified. Considering a particular document, document fields are analyzed, and respective values of the document fields enable users to identify the presence or absence of data discrepancies along with details of said discrepancies. The advantage of this method is that end-users can precisely determine which process or scenario is successful or failing due to a particular object in a particular Transport request 110.
[0059] In one embodiment, the definitive risk analysis is performed with respect to three categories of outcomes of the testing process in the test or quality system 130. The “Definitive Risk Index” or “DRI” of the transport request 110 comprises a number that represents the number of RED and/or YELLOW process-scenarios against the total number of process-scenarios being tested (RED+YELLOW+GREEN). Consequently, in case there is a higher DRI number, there are higher chances of processes or scenarios being adversely impacted by the transport request 110.
[0060] The definitive risk index represents the likelihood of the process-scenarios being impacted when the transport request 110 is deployed in the production system 140. The testing performed in test or quality system 130 with same process-scenarios (identical) which exist in production or reference system 140 determines the mentioned likelihood. The definitive risk index of the transport request 110 is calculated using a relevant mathematical formula like weighted-average etc. Further considerations can be included in the formulae in case a user or an organization wants to ignore all YELLOW cases and use only RED cases for DRI calculation. Alternatively, the user or organization may prefer giving equal weightage to both RED and YELLOW cases. Thus, customizations in the formulae may be made as per the need of the user or the organization.
[0061] In an embodiment, a threshold limit is set based on the definitive risk index number. In case the transport request 110 scores beyond the definitive risk index number, the transport request 110 may be held or sent for review to a predefined set of approvers. As an example, for setting rules with a threshold limit, the user or the organization may set thresholds wherein on an occurrence of one or more RED case and more than ten YELLOW cases, certain actions may be taken. Thus, one or more threshold limits and rules can be customized based on an organization’s needs.
[0062] In one embodiment, predictive risk analysis is performed by considering an example where definitive risk index method is active for a given period of time. Historical data can be prepared by continuously collecting information of one or more of transport requests 110 which are deployed to the production system 140, respective objects 210 in the transport requests 110, results from test or quality system 130, definitive risk index, RED, YELLOW and GREEN cases corresponding to the transport requests 110, and respective objects 210, among others. The historical data is used to predict a possibility of adverse impact of the objects 210 on the processes of the production system 140 in case the transport request 110 is deployed. The predictive analysis may be done at the beginning of the change or origin of the transport request 110, which may typically the development system 120.
[0063] In an embodiment, the “Predictive Risk Index” or “PRI” of the transport request 110 may comprise a number that represents the number of RED and/or YELLOW process-scenarios against the total number of process-scenarios (RED+YELLOW+GREEN), which are sourced from the historical data created by the continuous definitive risk index method. Consequently, in case the predictive risk index is high, there are higher chances of the process-scenarios being adversely impacted by the transport request 110. Various ways to calculate the predictive risk index and resultant actions to be taken can be derived in a similar way as mentioned for the definitive risk index.
[0064] In an embodiment, the predictive risk index is calculated before the testing is performed in the test or quality system 130. The predictive risk index provides a visualization of risk as a prediction, where the accuracy of the prediction depends on the historical data and the time period during which the historical data is collected. The predictive risk index provides an indication of the risks of the changes carried by the transport request 110 at the time of origin, when the transport request 110 is in the development system 120, and before the transport request 110 is tested in the test or quality system 130. Time-to-act information is obtained from the predictive risk index by identifying possibilities of failures at the time of performing changes in the development system 120.
[0065] In one embodiment, the definitive risk index and predictive risk index work together to protect the production system 140 from process failures and ensure business continuity. The definitive risk index is derived after deploying the transport request 110 and performing test execution in the Test or Quality system 130. The definitive risk index provides continuous inputs to the historical data 310 which in turn derives the predictive risk index while the transport request 110 is in the development system 120. Another advantage of the method is that the predictive risk index acts as an early-warning system, whereas the definitive risk index identifies precise point-of-failures that occurs on deploying the transport request 110 in the production system 140.
[0066] Fig.3 illustrates a generation of historical data 310 over a period of time. Multiple transport requests 110 (transport request 1, 2, 3….n) are created in the development system 120, moved for testing in the test or quality system 130 and deployed in the production system 140. Each transport request 110 comprises various objects 210 for which definitive risk index is determined to identify RED, YELLOW & GREEN cases. The generated data is collected in a separate system that classifies the generated data based on the objects 210. Object – ABC in transport request-1 and transport request-2 is communicated with the historical data 310 while definitive risk index is determined. Other objects such as object – ABC, object – BCD, object DEF, and object XYZ etc. of other transport requests 1, 2, 3…n iscommunicated to the historical data 310.
[0067] In an embodiment, the RED, YELLOW & GREEN cases against each object 210 are obtained by analyzing the historical data 310. The historical object data is linked with objects 210 of the transport request 110 and deployed in the development system 120 to calculate the predictive risk index for the transport request 110. Table 320 shows the historical data 310 comprising various objects 210 corresponding to RED, YELLOW & GREEN cases.
[0068] Fig. 4 depicts an example of lifecycle of the transport request 110 from the development system 120 to the production system 140 in an enterprise planning system landscape. The predictive risk index 420 is calculated based on inputs from the historical data 310 and the transport request 110, when the transport request 110 is in the development system 120. The transport request 110 is moved and deployed in the test or quality system 130 based on the value of predictive risk index 420. Meanwhile, in the test or quality system 130, testing is performed to derive the definitive risk index 440 without considering the predictive risk index 420. The transport request 110 is moved and deployed in the production system 140 based on the value of the definitive risk index 440. Subsequently, data related to the definitive risk index 440 is then sent to the historical data 310 to update object specific data 320. The object specific data in table 320 forms the basis of the calculation for the predictive risk index 420.
[0069] Referring to Fig. 5, a processing method to obtain a mirrored process execution from three inputs is illustrated. The processing method 520 receives the input 510 comprising:
[0070] a) real-life end-to-end process maps and other process details like document properties and metadata etc. in a business function;
[0071] b) real-life data of business scenarios or test cases at each stage of the processes; and c) real-life processing programs, functions, interfaces, transaction codes etc. at each stage of the processes, to obtain an identical execution of data processes.
[0072] In one embodiment, the data processes differ from function to function. For example, in case of a function comprising sales or order-to-cash function, a typical process involves sales order ?delivery ?billing. In case of a function comprising procurement or procure-to-pay function, a typical process may involve Purchase Requisition ? Purchase Order ? Goods Receipt ? Invoice Verification. Similarly, various business processes and functions are performed in finance, production, human resources etc.
[0073] Fig.6 illustrates a sample process in a sales function, to explain the method for identical execution. A sales or order-to-cash function is considered to explain the mirroring method. In a real-life process execution, an incoming ALE-IDOC 660 (Application Link Enabling – Intermediate Document) is created through a custom BAPI 620 a) (Business Application Programming Interface) or a FM (function module). The intermediate document 660 creates a sales order 650 through the SAP standard BAPI namely BAPI_SALESORDER_CREATEFROMDAT2 620 b). A delivery document 640 is further created with reference to the sales order 650 using the SAP (systems, applications and products) standard TCODE (transaction code) VL10A 620 c). Later, goods issue 670 is posted manually through the transaction code VL02N 620 d). After the goods issue 670 is posted manually through the transaction code VL02N, billing document 630 is generated using the SAP (systems, applications and products) standard program SDBILLDL 620 e) through batch processing. The same real-life programs or transactions codes are used to mirror the process execution instead of standard transaction recording of the process. At each stage, real-life data 610 of Business Scenarios are used as data input. Processing Programs or Transaction Codes at respective stages of a given process are given at 620. For example, selling company, destination country, customer, material, pricing components and all other data inputs are identical to the real-life process execution. A scenario`s data is fetched through a real-life process that is represented through any of the document, which is part of the process being mirrored and the fetched data is linked with rest of the documents in the process. Fig. 6 presented a billing document that is used to fetch the real-life scenario data from reference or production system.
[0074] In one embodiment, a sample process consisting of n-number of stages with respective processing types (BAPI or FM or Executable Program or a TCODE) is explained.
Process stages Processed through Technical Method Data Input
Stage -1 Custom BAPI/FM Call function
Pass parameters
through fields/ tables
Stage – 2 Standard BAPI/FM Call function
Stage – 3 Standard TCODE Call transaction
Stage – 4 Custom TCODE Call transaction
….. ….. ….. …..
Stage – n Standard executable Submit report Pass parameters
through fields/ tables
[0075] The process is performed in iterations based on number of stages, using respective processing types and input data which are identical to real-life processing. For example:
a) Iteration-1 & 2: Stages -1 & 2 use BAPI/FM, and a “Call Function” method is invoked to execute the iteration by providing scenario data through Field or Table parameters as input data.
b) Iteration-3 & 4: Stage-3 & 4 use SAP TCODE for which respective TCODEs are invoked through “Call Transaction” by providing scenario data through Field or Table parameters as input data.
c) Iteration-n: for nth stage, a standard SAP executable program is invoked through “Submit Report” by providing scenario data through Field or Table parameters as input data. This way, each stage of a process is executed using identical processing methods and identical scenario data to generate the identical process execution.
[0076] Each stage of the process is executed as such in aforementioned manner using identical processing methods and identical scenario data to obtain a mirrored process execution.
[0077] The above-mentioned method is used in any industry or business organization to prevent business process or scenario failures and to ensure Business Continuity in a live SAP-ERP (Systems, Applications and Products – enterprise resource planning) Production system by making use of identical or mirrored process execution. The method is used for testing, comparison, review, analysis or any other purposes to ensure accurate and precise comparison between real-life (production) and identical (tested) processes. The method provides reliable and accurate data to identify and assess risks associated with a set of configuration data changes, thereby preventing business process or scenario failures in a live production system. The method also has advantages over conventional method as there is least or negligible errors or bugs remain undiscovered.
[0078] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the embodiments as described herein. ,CLAIMS:CLAIMS
1. A method for risk analysis of data processes against data changes in an enterprise resource planning system, said method comprising:
receiving a transport request (110) comprising at least one object (210) comprising configuration data changes;
linking each object (210) with one or more of the data processes (240) and corresponding data process variations or scenarios by matching one or more field data values;
testing one or more subsets of linked processes and scenarios through identical execution by mirroring one or more of real-life data, data processes and processing programs;
analysing one or more test results by comparing the field data value of one or more documents with field data value of one or more test documents to derive a status for each process; and
generating historical data of all test results for performing pre-test analysis.
2. The method as claimed in claim 1, wherein said objects (210) comprise multiple object values (220) including one or more code objects or configuration data objects.
3. The method as claimed in claim 1, wherein the resource planning system comprises:
a development system (120) for generating changes carried in the transport request;
a test or quality system (130) in which one or more tests are performed to validate the changes; and
a production system (140) comprising a live system for real-life transactions and
a final target system or destination for changes to be deployed through the transport request.
4. The method as claimed in claim 3, wherein the method comprises identifying one or more relevant scenarios and processes to be tested by the test or quality system, in case the transport request (110) is to be deployed in the production system 140.
5. The method as claimed in claim 1, wherein the method comprises testing the processes and scenarios to generate one or more of failed processes, respective scenarios, and data discrepancies between real-life and tested processes.
6. The method as claimed in claim 1, wherein the method comprises labelling the processes and scenarios as a green case in case all documents in the process or scenario are generated identically to a real-life or production counterpart of the process with no data discrepancies, wherein the method comprises labelling the processes and scenarios as a yellow case in case all documents in a process are generated but at least one document has data discrepancies as compared to the real-life or production counterpart of the process, and wherein the method comprises labelling the processes and scenarios as a red case in case at least one of the documents in the given process fails to be generated.
7. The method as claimed in claim 1, wherein the method comprises determining a definitive risk index based on a number of red or yellow processes or scenarios against a total number of process-scenarios being tested, wherein the method comprises determining a predictive risk analysis based on a number of red or yellow processes or scenarios against a total number of process-scenarios being tested, wherein determining the predictive risk analysis is based on analyzing historical data to predict a possibility of adverse impact of the objects in case the transport request is deployed.
8. The method as claimed in claim 7, wherein the method comprises setting a threshold limit based on the definitive risk index number, wherein the transport request is held or sent for review to a predefined set of approvers in case the definitive risk index exceeds the threshold limit.
9. The method as claimed in claim 7, wherein the predictive analysis is a function of the definitive analysis.
10. The method as claimed in claim 1, wherein the mirroring comprises:
using identical data of processes or scenarios as data input;
fetching identical scenario data through a real-life process; and
executing stages of the real-life process using identical processing methods and identical scenario data.