Robotic Process Automation within your Organization

Rate this:
Total votes: 0

Whether you are into BPM on a full-time basis or a general technologist, it is hard to not be seriously considering RPA or RDA (Robotic Desktop Automation) in the mix of any business solution you are working on lately. For Pegasystems specialist, you may have been introduced to RPA by their fairly recent acquisition of OpenSpan (now Pega Robotics). Pegasystems is rapidly assimilating the RPA into their BPM platform (PRPC 7.4).  Although, integration with BPM is a good feature, in the industry RPA is platform agnostic and considered a platform in and of itself. 

I have seen some organizations establish entire reporting units dedicated to RPA, even with a well-established BPM practice already in place. In discussions with technology leads, some seem to have a hard time enunciating how RPA fits into the overall architecture, this will be mitigated once there are enough RPA implementations and associated case studies disseminated.  

IMHO, I see RPA as a feature that gets invoked when BPM or server-side technology is incapable of automating the use case, such as, 

  • data integration with a legacy system using a user interface or batch process, because backend integration is deemed to be unworkable and not open 
  • automating the reading or writing of data from or to a legacy system or form 
  • further automating a business process that may be assisted by robotics, possibly in conjunction with AI   

I do not look at it as a platform in and of itself. I am sure a pure RPA technologist may take issue with relegating RPA to such a minor role in the architecture. I also need to point out that some RPA platforms have the same core features as a BPM, Web service integration, correspondence through email, workflow and case management, etc. Nevertheless, with RPA now being unleashed and available to large organizations, as well as, smaller corporate markets, the technology leaders need to rapidly define its role in their corporate landscape. 

RPA’s Role in the Org

Most organizations that have been viable for a length of time require some form of RPA solution, as an alternative to or in conjunction with BPM, ETL or SOA in order to enhance legacy operational functionality. In some cases, client-side/desktop integration, as opposed to server-side integration, is a more optimum solution. Server-side automation can be more complicated, expensive and possibly even unachievable, because legacy systems may not be open or interoperable. Nevertheless, RPA and BPM should be viewed as complementary, not competing technologies.

Important to the success of an RPA or BPM project an implementation advisor team that understands RPA and BPM needs to create a preliminary strategy to identify what process improvements are appropriate for RPA, as oppose to BPM automation and visa-a-versa. I was recently consulting within an organization that had recently purchased BPM and RPA solutions. These technologies were being managed and implemented by two very separate teams. Having formulated my own opinion of RPA usage I found this organizational structure to be very interested and totally counter to how I would manage and implement the technologies.

In initial meetings with the RPA director, I questioned how they are not automating the same business process as the BPM team. The RPA “projects” appeared to be very short term and tactical; whereas, the BPM projects were multi-phased/multi-year projects. My initial reaction was the RPA projects were happening too quickly; whereas, the BPM projects were too protracted with neither being very realistic. I have to believe that this type of corporate behavior has to do with technologies that the organization has not met their stride with yet. 

This was a financial organization where everything was ROI based, not necessarily very strategic. A more balanced approach of getting things done and having clear strategic objectives may be the only way to guarantee that process automation(s) will increase productivity within a reasonable ROI. Companies who do not address process automation from a holistic perspective can actually experience RPA as a negative value proposition. 

Fitting into the Org

Once RPA processes are, in place, it is important for the organization to establish strong operational oversight. The fact is, should any internal or external aspect of a business process change, the RPA will likely fail to perform. In order to avoid automation failures, changes or alterations will have to be planned, communicated, tested, and executed. Governance and oversight are key to an implementations long-term success.

RPA automation is hard work that requires painstaking attention to process details by both business analysts and technologist. In many cases, there are often missing rules in a process simply because those rules may reside only in the operator’s mind. Considerable time will be required to identify and document the rules they follow possibly without consciously thinking about them. 

With the introduction of any new software, “process”, as well as, roles change within the organization. For RPA, new team leads will be required to manage the output of robots, rather than FTEs. As is the case with any new technology, it takes some time before an organization understands its role in the enterprise architecture.

Premature Automation Planning

Most discussions around adoption of new technology tend to focus on slow acceptors, and how business and IT resources hold to old ways of doing business; however, with RPA software the opposite is probably true. Advantages can be far-reaching and the transition to automated processes takes place without clearly thinking through the process. Process automation should be part of an overall process optimization strategy consisting of many elements and components. 

Before any process is automated, all processes should be considered from a standardization and optimization standpoint. Obvious automation opportunities should not be delayed, but the standardization and optimization should take place first. “Obvious” RPA savings may end up funding subsequent efforts. But automation needs to be directed only at relevant and well-qualified business processes. More scientific organizations may want to consider using something like a short subscription to Pegasystems Workforce Intelligence cloud to determine where RPA is most needed in the organization. 

Operational Oversight/Governance 

One of the strengths of RPA is accuracy and that once configured software never deviates from its algorithms. Albeit, should any internal or external part of a business process change, the software will possibly fail to perform. To avoid automation failures, changes to process automations should to be planned and communicated by a dedicated governance team. This due diligence process will be a challenge for most organizations, because most business processes in many organizations are undocumented and revisions occur less formally.  RPA requires a strong change and release control process, including new SOPs to succeed. 

Changed or New Roles in the Org

Robotic process automation efforts, process changes and resource turnover within an organization are essentially tactics to achieve an outcome, that being accuracy, efficiency and reducing costs, respectively. However, this implies or exacts a certain amount of new roles or changes to existing roles. For example, managers and team leads will now be required to manage the output of robots rather than FTEs. These individuals will: 

  • maintain and improve SLAs for the human interventions needed for process exception-handling
  • be the liaison with IT and handle turnover management
  • need to be vigilant about reconfiguring robotic software in coordination with changes in process activities and rules
  • implement the RPA rollout across other business unit. 

Confidence in DevOps Ability vis-a-vis Overselling Ease of Use

Deploying robotic software entails risk and requires an investment, the companies who undertake the effort stand to experience attractive benefits. A part of the strategic plan should question whether automation should be done in-house or by a BPO provider. Remember that RPA is for the most part new technology, even for integrators. The roadmap for RPA deployment should reflect conservative optimism with respect to effort and achievement. Despite the hype about the ease of implementation, the truth is RPA software is not that user-friendly and easy to configure.  This is compounded by the fact that business processes are often missing rules or require decisions-making with the human operator. It will take time for current process employees to identify and document the innate rules they follow without consciously thinking about them. Additionally, when you try to add in AI and “Next Best” product and service strategies the automation implementation quickly becomes complex. One way or another you need experts at the ready. 

Still On the Fence with RPA

While automation projects can be successful, using only RPA as the enabling technologies, an overall business process view is key. The solution may not necessarily need to be technical, but a process change. Alternatively, RPA may or not be the best technical solution. While RPA experts may take umbrage to this point, I still see RPA as part of an overall BPM project. So, the ultimate solution may be RPA in conjunction with a BPM application.  

That does not mean that every BPM provider needs to have an RPA solution in their product line or create tight integration between their BPM and RPA systems, as is the case with Pegasystems. For example, the Pega BPM Flow Action or Flow (see Diagram 1 and 2 below) can invoke a RPA process. However, I do not see any lock in with respect to RPA enablement here; I have consulted with one customer who is using UiPath for RPA in conjunction with Pega BPM and believe this is an effective interoperable solution.

That said, when faced with a task in a workflow that can be achieved through operator-less processing using RPA/RDA (Remote Desktop Automation) can represent a powerful technique. The industry experts seem to have drawn a clear difference between RPA and RDA in that the RDA is an automation solution that assists the agent in handling simple repetitive tasks; whereas, RPA is a headless operation in comparison. In RDA, the agent plays a role in facilitating when the automation is triggered and stopped depending on their workflow. This definition still seems ambiguous and somewhat austere.  In Diagram 1, if the fork (Enter CC Info) routes the case to the Robot Queue, as opposed to the agent making the decision, is this then RPA not RDA. Not sure this attempt at defining process helps or adds confusion to the discussion. Although I agree that there is an assisted versus unassisted mode for robots.   

Albeit, I believe it is a better to characterize robots as attended or unattended. Attended robots “assist” workers with business tasks and processes where a certain amount of human intervention is required, speeding up repetitive front-office tasks. They reside on a user’s workstation and are can assist with service desk, helpdesk and call center activities, for example. These attended bots process in the background, while a user can continue with other tasks, in order to provide higher productivity and lower handling times. 

Unattended robots are essentially totally operator-less and can be provisioned from orchestrators and management consoles to run either in physical or virtual environments. They can be scheduled to self-start, stop and run on an organization’s official working days. These types of bots can be dynamically scaled based on usage.

Diagram1:Robot Queue Shape for Workflow Automation

Diagram2:Handling Robot Queue Workflow Automation Failure

Forrester recently identified 12 “significant” RPA providers. This is not necessarily a new market, but lately has become more popular, and it is not clear who will be the leaders. UiPath seems to be a solid platform, and I believe it is not as complex as Blue Prism, Automation Anywhere or Pegasystems Robotics. Although, UiPath’s no code environment may not be as flexible for enterprise-wide solutions but may be popular in corporate markets where IT budgets are leaner (and process models are possibly simpler).

Nevertheless, most RPA tools can interoperate or coexist with any BPM; they are complimentary and somewhat mutually exclusive technologies. Although, alliances seem to be gathering between BPM and RPA venders, to my point, they exist in the same computing space.  

Comments

Join the Discussion

Shopping cart

There are no products in your shopping cart.

0 Items

Editorial DIrectors


Gregg V. Rock
Editor & Founder

Tom Dwyer
Editorial Director

Related training courses

BPMInstitute.org provides training courses online and in person for individuals and groups. View courses related to the material you are reading on this page. 

BPM 101Methodologies and Approaches for BPMDecision Management and Business Rules 101Agile Business Analysis 101Advanced Facilitation SkillsView the Learning Path for more courses »