Reengineering strives to break away from old rules about how we organize and conduct business, it involves recognizing and rejecting some of them and then finding imaginative new ways to accomplish the work.
Enterprise Application Automation -- This is Bigger Than Just RPA
Frank Teti, Solution Architect, Digital Customer Experience (DCX) | Capgemini
When it comes to enterprise-wide application automation, I still believe that,
“It is time to stop paving the cow paths, instead of embedding outdated processes in silicon and software, we should obliterate them and start over.”
Michael Hammer stated that in his now legendary Reengineering Work: Don't Automate Obliterate, Harvard Business Review, July 1990. He further comments that we should reengineer our businesses: use the power of modern information technology to radically redesign our business processes in order to achieve dramatic improvements in their performance.
Reengineering strives to break away from old rules about how we organize and conduct business, it involves recognizing and rejecting some of them and then finding imaginative new ways to accomplish the work.
Yet another Silver Bullet
While the above statements are axiomatic, I still see organizations preferring to rely on silver bullets whether it be AI, RPA, BPM, etc. in order to improve their inept or inefficient business processes. For example, I was recently consulting with an insurance company that wanted to use a combination of RPA and AI technologies to automate a customer service business process that included a UI for OnBase that was designed for power user to administer the ECM and other satellite applications, such as, Microsoft Access, Outlook, etc. that were needed to support the enterprise-wide claims system applications. This project clearly started to feel like not only paving the cow paths, but possibly adding to the process inefficiencies by potentially automating a very weak processing environment. Intelligent process automation (IPA), which is increasingly seen as a complement to robotic process automation by extending the scope of robotic process automation with AI technologies, would be an alternative; however, the existing underlying technologies would probably still have to be replaced and/or API mechanisms, if available, would need to be considered.
RPA vs. BPM
In BPM projects you typically extract business rules and processes and orchestrate the new process using the BPM’s inherent UI/Process functionality in conjunction with existing process applications, if possible. In RPA projects, the objective is to leave the existing technologies intact and find a creative way to further automate the process. For this reason, organizations are so keen on RPA, they believe they can achieve process improvement with their cobbled together legacy environment.
Facing a complex workflow, if reengineering or migrating (applications that need to be further automated) is not achievable, the next best solution is not RPA, but considering a BPM in conjunction with an RPA tool. Additionally, other IPA tools, such as, process mining, smart intake tools, machine learning, AI and operational analytics (i.e. BAM) should also be evaluated.
Appian bundles Blue Prism and partners with UiPath and Automation Anywhere to provide integrated RPA support; whereas, Pegasystems has an RPA in their product line.
Finding the Root Cause Issue with the Process(es)
In most business scenarios, the underlying process issue may not be resolved by just further automation. The optimum solution may require:
- An overhaul of the current state business process model,
- Significant application modifications and enhancements to user interfaces,
- Implementing case management in order to bridge and tie-together disparate applications,
- Process automation and optimization using an RPA tool.
This is an IT and consulting practitioner perspective and is not necessarily in alignment with the current thinking regarding process automation, which seems to promote IPA as being capable of resolving all process automation scenarios.
The RPA Wave
Gartner estimates that RPA is the fastest-growing software subsegment officially tracked, with year over-year growth in 2018 at 63%. In my mind’s eye, this growth is not all about superior technology, RPA has effectively bypassed the traditional IT buyer by appealing directly to business users, with its emphasis on resource reduction, easy efficiency and accessibility of the scripting environments.
In the case of UiPath, they have not only bypassed traditional IT, but created an alternative, light-weight RPA IDE called StudioX. StudioX is the tool that enables “every” business user to automate their tasks. The resulting automation projects can then be sent to Robots for execution. This is beyond the realm of Shadow IT and is characterized as “democratizing” process automation and data integration. RPA is considered another area where business users find it difficult to understand why they need to wait for IT to integrate their existing technology.
Scope of RPA
For those of us who have focused on BPM over the past decade, a number of RPA projects have been implemented in conjunction with BPM projects. So, RPA is, essentially, an advanced feature of BPM.
Another avenue that has provided insight into the use of RPA is by being a member of a “Group” that considers itself a “platform for professional learning” that connects people trying to solve problems to experts that can solve them. (I do not want to promote or disparage these types of organizations, they simply exist.) For me, this is a bilateral relationship that while I may help to solve problems or decisions regarding RPA, I also am educated on the potential needs and issues people are grappling with in their pursuit of modernization and optimization, or, in some financial-oriented conversations, how much demand there is for RPA technologies in the marketplace.
In the not too distant past, I found myself educating and informing business, as well as, IT people on the role and purpose of a BPM in an organization. Lately, this has shifted to RPA, not that the role of BPM is now completely understood, but, my take, is that organizations now see RPA as the path to automation. In other words, the ends justify the means, if your objective is to automate a business processing environment, the tool is not necessarily relevant. RPA vs. BPM technologies are competing and interchangeable goods.
However, I don’t see RPA products as a substitute good for BPM products. Economic theory states that a substitute good is a good that can be used in place of another. In consumer theory, substitute goods or substitutes are goods that a consumer perceives as similar or comparable, so that having more of one good, causes the consumer to desire less of the other good.
.png)
Nevertheless, I believe that this is the way the technology market appears to be behaving. In the graph, QXj (RPA) can be substituted by QXi (BPM) and visa-versa.
RPA -- the New Excel?
In many ways, the inherent capability of a BPM product is quite different, than an RPA product. In the world of BPM, there is a significant amount of methodology, notation and standards, such as, BPMN, DM, CM, etc. Process optimization is tied to best practices around process improvement and modeling, decision support and case management.
RPA implementation approaches do not include any of those types of constructs or concepts. This may be the attraction to this approach to automation. In a world where Agile and Agile approaches are used even for scope and requirements phases of a project, limited methodology is considered benign.
Gartner tells me that RPA is a digital enablement technology that predominantly leverages a combination of user interface and surface-level features to create scripts that automate routine, predictable data transcription work. This is very accurate and terse description and assessment of RPA. The problem in the industry is that potential customers and users tend to overestimate its capabilities. That is why most popular RPA vendors have over 100 partners in order to deliver the higher expectations of what the customers expect from their automation platforms.
RPA projects seek to optimize an application or set of applications by further automating the existing process. In many instances, this approach can lead to a successful implementation. You don’t need case standards, process models, etc. just an understanding of the current process. I have even started to change my own opinion of RPA that these types of tactical automations can enhance and extend the useful life of a set of application in a process mix. Where RPA projects fail are situations where the existing process has multiple issues, such as, inadequate user interfaces, lack of clear processing paths, a need for process auditing, too many applications in the process mix, etc. However, for RPA vendors, they appear to believe that it should be as ubiquitous as Excel.
IT Governance and Automation Patterns
With quasi-technical, citizen developers being encouraged to implement RPA solutions the only realistic way to manage the IT business processing environments is to establish well-defined patterns.
Pattern 1 depicts a set of related workflows that may be automated in one BOT or several. This may require user interaction, that is, when one BOT completes in order to start the next BOT the user may need to review the output and trigger the next BOT or the first BOT may invoke the second BOT on completion. This type of automation or other permutations and combinations of processes similar to this one, may be achievable with success by a technical business user.
However, for a set of BOTs that need to be possibly distributed to a group or even work on a single users desktop for any length of time the BOTs need to include fuzzy logic and Regular Expressions in order to be dynamic as page configuration changes over time. This type of behavior cannot be accomplished by just using a recorder. You can prototype a BOT using a recorder, but you can’t realistically expect it to interrogate a page successfully over time.
Pattern 2 depicts a workflow that is managed by a BPM. In the process, the workflow invokes the BOT. This would be considered an unattended BOT and would probably not make sense for a technical business user to configure. However, they should be involved in the design session and there understanding of basic BOT behavior and the applications will be an advantage to the design team.
A example of this capability, would be the inherent ability for a Pega workflow to call a BOT, possibly based on decisions made within its adaptive/predictive Decision Hub.
Pattern 3 depicts a BOT that reads email and parses the subject line and unstructured message to,
-
get information about the nature and details of the correspondence
-
code chunk the body of the email and invoke an NPL server, such as, Stanford’s CoreNLP to perform Sentiment Analysis and Named-Entity Recognition.
CoreNPL server analyzes a specified text by using the Stanford CoreNLP Natural Language Annotation Technology.
Based on the parsed message details, as well as, sentiment, tone, verbiage, etc. ratings and data from the CoreNPL a recommended action or decision is made using an internal Knowledge Base and the appropriate transaction can be created.
Future of BOTs
With BOTs being created by users, we might be in the midst of a paradigm shift. In the long run, the end result of having tech savvy users, substantively contribute to the automation of the organization will make organizations more highly fluid and efficient.
Nevertheless, whether you call it IT governance or good management an organization that allows for this type of workforce, needs to also provide a certain amount of guidance, direction and standards. Patterns are not only useful as reference architectures for your automations, but also to determine if a current process that is scheduled for automation can be achieved by a tech savvy user, as opposed to an automation technologist.
Frank Teti is a Solution Architect, Digital Customer Experience (DCX) in Capgemini’s Digital Platforms Practice. He was a Senior BPM Architect with Pegasystems and a Technical Manager/Architect at Oracle specializing in SOA and BPM. He can be reached at frank.teti@capgemini.com
If you like this article you may like "Is Software the Future of Robotics?"
The content & opinions in this article are the author’s and do not necessarily represent the views of RoboticsTomorrow
Comments (1)
Featured Product
