Sure, Process Automation Life Cycle, i.e. PALC, is something I just made up, but why?

Coming form Software Development background, Not long time ago, we have always been talking about Software Development Life Cycle, SDLC, methods and best practices (and a lot of people still do). We did that, because as software development was maturing, we needed best practices and guidelines to ensure the success of the projects. Since then SDLC has come a long way and we have got a lot better in delivering software systems.

Now, I feel the Process Automation, you can also read it as Digital Transformation, is where Software Development was 20-30 years ago. It’s still new and there quite a few flavours of approaches and implementations for it. A lot of companies are still learning best practices and approaches, where to start and where to end. So, I was thinking, it would be just a matter of time before the same concept as SDLC starts emerging for Process Automation. I Googled it a bit but didn’t find anything, and then thought let’s use the power of internet, start something and get other subject matter experts thinking. Hence, came around PALC.

I have spent good chunk of the last 10 years of my careers implementing solutions which helps businesses automate their processes. During the journey I have seen quite a few Process Automation projects and learn from them. I have also been lucky enough to be able to work on one of the leading Process Automation platforms which enables users to automate their processes with no or code. This has helped me gain a good exposure to the Process Automation domain. Based on my experience, you can break down PLAC into three main phases:

1. Identification: Identifying the process across the business, centrally managing them and flagging the ones which are a good candidate for automation.
2. Automation: Automating the flagged processes with the tools available
3. Optimisation: Monitor, analyse performance of the processes, and optimise them accordingly.

 

I know it’s a bit strange at the first glance that Process Automation Life Cycle does not start or end with the Automation phase. I mean you could do that, but in most cases it would create a lot of silos and redundant works in companies. (which is totally against the merits of Process Automation)

Before I go into details about each phase, I’d like to call out that I assume you have your senior management buying in the whole Process Automation shift. PALC is only about the approach of implementing Process Automation.

Ok, let’s go a bit deeper in each phase:

Identification

As I mentioned above, PALC does not start with actually automating processes, but rather with identifying and creating a central repository of the processes in the company. This creates a holistic view of the processes in your company and I put my money down that you will be surprised to see how many processes are there which no one, except very few people, would know about, also, how many similar processes are there which can be merged. Most probably, you’ll find a few processes which were defined long time ago and never got changed, where they should have been. One more common scenario’s which companies face is that they find quite a few processes which can be potentially be merged into one and drive better results.

Once you have the central repository of your processes, there is some manual work required to review them and identify the ones which are prime candidate for automation. This, as we I call them the low hanging fruits or quick wins, are the smaller, less riskier processes with minimal dependencies on other organisations. There is both psychological and efficiency benefits to this approach. The low hanging processes normally are easier to automate, quicker to see the result and less riskier to changes. Hence, the learnings are going to be a lot more and the company sees progress and result a lot quicker.

Then move on the identify and flag the processes to be automated in the second, third, forth, etc. rounds

You can also identify and mark the processes you don’t want to automate because of any reason like compliance, regulation, effort required, risk etc. and I believe it’s ok. I personally rather be pragmatic than idealistic.

Automation

Next up, is moving on to automating the processes you have identified. There are quite a few tools out there, and more and more coming, which are designed to help companies automate their processes with minimal effort (low/no code) compared to writing a new software. Meaning, you normally don’t need to be a software developer to automate a process or you’d one for a short period of time. Depending on the type of process you may want to chose a tool with the specific capability.

Just remember, you’d want a tool which enables you to:

• Automate the identified process as soon as possible,
• Change them with minimal effort,
• Put them in action with minimal deployment hurdles .

You almost want a tool which lets you prototype automating your processes in quickly, and change that prototype to the real final solution with very minimal effort.

Optimisation

The world, the regulations, and the way businesses operate are constantly evolving, and so should your processes.

Also, when you define and implement a process, you probably wan to monitor how it’s performing and if it actually has been effective. Based on your monitoring results, you may want to go back and change or optimise the process. Up until recently, this stage had been the most difficult of all, just because it was very labor intensive and error prone. It would have required a lot of manual tasks, overhead in the process execution itself, and a lot to analysis based of papers. It was so difficult that people would start questioning the value of it and, unfortunately in majority of the time, it would not happen. (unless something breaks)

Now the good news is that, with automated processes most, if not all, of the data is digitised and a lot easier, quicker and reliable to work with. Digitised data gives you an unprecedented ability to monitor your processes and find the parts which need to change to get a better result. You can also use the data to see how people involved in the process are performing and route the future instances to the most optimal one, based on the historical performance. I guess what I am trying to say is that, the limit of what you can do with the digitised process data, is the sky.

 

Final Word

Now that we have had a quick look at the phases, I’d like to remind you that, this is an iterative process. Using the insight you gain from the Optimisation phase, add, edit or split your process into multiple ones and feed them back to the identification phase, so that, they can follow the same life cycle.

 

I will try to write a few more blog to go deeper in each phase. In the meantime, please leave your comments below and let me what you think about PALC.