Requirements in Process Automation

“Your house is only as strong as your foundation” – is the right phrase to say that most of the Bot’s developed don’t meet the end customer need when deployed first time in production.

Some of the basic question in IPA world are:

• Is IPA requirement same as that of any other project/product requirement?
• Can we apply same techniques of requirement analysis i.e. top down approach in terms of sitting with customer and hearing the story?
• How many times does a medium complex process to complex process failed to deliver based on ROI?
• Percentage of data automated (planned Vs actual) has been in the range of say 30% to 80%.

Are developers, Process consultant, Business SME responsible for not meeting business expectation? Answer is NO, neither of them is solely responsible for the failure. They all would have played their role as expected and delivered to the best but then also we see that BOT is not really working as it was supposed to be performing in production. So, where is the gap?

Being part of IPA from last 3 years and involve in multiple deliveries, I have observed the key gap is in the process/ methodology that we have adopted in IPA industry.

It is clearly understood that IPA is not like any other development project, it has got its own complexity and it require mindset , organization allignment to drive the same , someone who has really understand all ingredients will be able to successfully deliver.

One of the key Aspect to make the project successful is its requirement. We have to bring a drastic change in the way process automation requirement is carried out. For the same, it requires training and confirmation from Business as well and also people who are involved in the requirement phase.

Key people required for requirement phase are: Data scientist, Process consultant, Business SME

Key support required from business: Production data access to Data scientist for last 1 to 6 months.

Process to be followed for requirement gathering should be as below:

*Do note that the timeline depicted is considering a medium process.

Step-1: Data scientist to be given access to all prod data which has been processed in last 1 month

Step 2: Classification:  Data scientist to work with SME to categorize the data into three sections:

·        Input value (These are input data from either of the sources)

·        Static value (These are the system/application data)

·        Output value (Expected behavior of the process)

Step 3: Clustering – Data scientist to do clustering of input data and similarly for output data

Step 4: Fragmentation -Data scientist to apply techniques to group the data in such a pattern that one group of input data when worked with static data in the system gives a series of one group of output value.

A+B+C+D+E+F+G = 100%

Step 5: Requirement Definition: Data scientist along with Process Consultant meet Business SME to go through each clusters that’s prepared to see the fragmented flow for the specific set of data how it is processed and what rules get triggered to get the output.

Step 6: Documentation: Process consultant document the requirement and clearly state the volume percentage that particular requirement meets

Step 7: Consolidation: Process consultant merge the requirements which follow the same business logic to follow the different fragmented data to created same output.

Step 8: Testing: Test the requirements

a.      Data scientist to Use the current production data to fragment the data

b.      Identify 1 scenario for each fragmentation as per the step-3

c.      Data scientist and Process consultant to run the data as per the document requirement in the system to process the transaction

d.      Business SME to validate the processed data and confirm if the requirement captured and data processed is done correctly or not.

e.      If any of the transactions is not processed correctly, all three Business SME, Data analyst and Process consultant to re-group and validate the requirement and fix the details.

f.       Above process to be followed unless all ambiguity in requirements are fixed.

Please note the above process only helps to determine the Business rules and coverage of the data but it doesn’t talk about capturing all the system and business exceptions. Those has to be carried by Process SME while they are documenting the business rules.

If the above process is diligently followed, then at any point of time during development we would know what percentage of data is automated and also this can be used to do an agile development with guaranteed percentage automated and savings been calculated.

Some of the concerns may come as Requirement seems to be lengthier phase and in the process automation we don’t have that much time to do the documentation. But as you would have learned so far in the process automation if the process automated is not giving the right benefit then the complete delivery cycle becomes longer and you tend to spend more time and effort to gain the right benefit. So instead of fixing the problem later, why don’t we do apply the right approach at the project initiation itself.

 Advantage of the process:

·        Automation % is computed clearly and benefit realization doesn’t change over the course of period

·        If process is complex, Agile principles can be applied on the development and benefits realization can be known for development progress

·        Helps in terms of prioritizing the requirements to be automated

·        Test data requirement – gets defined for data creation

·        Rigorous testing can be done to avoid surprises in the production