RPA – Robotics Process Automation – is the new new thing. The subject, application areas, and service offers are abuzz with plentiful promises and venture funding to boot. Both, robots and process automation – are not new; robotic welding automated assembly lines were introduced in the 1908’s and PLC based process automation even earlier, especially in high speed production lines, for example, in parts inspection. RPA application now is primarily concentrated around automating repetitive manual tasks, such as, data entry, invoice processing, etc. Such unit RPA modules are being actively marketed as integrated solutions.
Before deciding to jump into RPA, carefully consider the following.
- The objective and measures of success: Why do you want to automate, what do you want to automate, where and why? That is, what is the driving business reason? Is it to reduce waste, reduce inefficiency, elevate competitive capability, improve customer service, cut costs, all, others? What is your measure of success – how do you know what to measure and when, as indicators to calibrate against the objective? This will require a baseline business case for the product or service type and process coverage for which RPA is considered.
- Where to focus: If you are clear on the objective/s and have created an admissible business case, then you need to delve deeply into the product or service types and characteristics. For example, for a specific product/service type, are you initially going to target an unit process, such as, manufacturing spec entry, demographics data entry, or ticket comment entry? Or are you considering a sub-process consisting of an aggregate of unit process, or a complete process. The RPA complexity increases with the process coverage; therefore, objectives, measure of success and baselines will be different.
- Process dependencies: It is highly likely that even unit processes will have dependencies on other unit or sub-processes. For example, in automating a data entry unit process, the data sources, transformation, outcome, and destination are all interlinked. Thus, additional considerations are to be given for “balancing” the input/transformation/output – more on this later. The process dependency also should consider system, application, and data interfaces and standards. Now data quality is equally important – garbage in, garbage out – with data quality checks prior to automated entry. Usually, during manual entry, these checks are provided by processors or in-built as a quality check process.
- Capacity analysis: it is very important to size capacity before and after. There is often a misleading notion that the process throughput will be significantly improved after RPA, with a decrease in cycle time. This may not always be true; because of imbalances in the process one may find significant increases in inventory in downstream processes and process bottlenecks. Also,if errors are allowed to propagate, downstream processes will be badly impacted. Just think about a high speed production line passing defective products which accumulate once the defect is identified, or hundreds of claims flagged for correction. Thus, process input, transformation, and output should be considered and carefully reviewed against requirements.
- Technology considerations: What will be the operating model – in-premise, cloud, or hybrid? What are the critical security factors? What other system, application, or data exchange considerations are important? For example, is this to be interfaced with an ERP system, or a Healthcare data exchange hub? How is the technology delivery to be parsed? How much does a vendor do and when?
- Skill considerations: What is the baseline skill needed to migrate to an RPA environment? What is the current gap? What is upskilling plan and by when? What is the resource re-purpose plan?
These factors are some important initial considerations, but the devil is in the details. What do you think?
Originally posted on Linkedin