Some processes are complex to begin with and others get there with time. All processes go through a series of evolution. Some of these evolutions, as we discussed last time, are aided by tools. While others are part of the natural process lifecycle – like changes in the underlying business models, external market or regulatory forces, etc. It is rarely the case where a process actually simplifies as it changes; mostly it’s the other way round. Typically, a process will add on a few extra steps, get fragmented and take a new route within a workflow or need a new set of data as inputs. In all of these cases, it progressively becomes more complex and consequently more co-dependent on human interactions.
When we analyze a process for automation there are several steps that we have to go through. A high-level view of a process can easily hide some of these nuances that make it complex. As far as we humans go, we are not very good at assessing the complexity of a process. Consider someone doing something for many years – they will find it easy and obvious and may even perform certain steps subconsciously. When such a person is asked about the process they will tend to document it as such. When the same process is performed by someone new on the job the assessment is completely different. So an essential part of analyzing a process for automation is to remove this human judgment factor and accurately document the steps involved in the process.
Typically, when an external consultant is doing this analysis, a certain rigor and thoroughness is warranted. There are several ingredients that go into this exercise, for example, it is always a good idea to start with a template or questionnaire which has been customized for the particular type of business function that the process belongs to, say finance or operations, etc. Others include a detailed walkthrough of the process by the owner, a time-and-motion study and a well-written SOP document is always welcome.
By now it should start to become evident to you as to why any automation journey that hasn’t started with a rigorous process assessment can go awry even before it starts to give any tangible benefits. Trying to fit an RPA tool into a process that has not been thoroughly evaluated will often lead to problems during the execution phase. These will manifest in the form of additional effort to create workarounds, may result in only partial automation or in certain cases the process may have to be de-scoped altogether.
Now, do you still blame the RPA tool? Unless you know, exactly, what your processes entail, how do you even begin your RPA journey? And if you already did then be prepared for some disappointments and serious course corrections.