When to build by RPA, and when to build by Pega 7
Hi,
Now we have two offering; BPM and RPA in our Pega products lineup. I know RPA can supplement what BPM can't (i.e. integration with legacy system that does not have API). Other than that, some functionalities are provided by both BPM and RPA (for example, e-mail notification or conditioning can be built by two of these). Is there any good way to separate these two? If we need to build a system that uses both, how do people decide what to build in RPA and what to build in BPM. Any priority?
Thanks,
Pegasystems Inc.
US
Hi, CloeW938 - while the ultimate design decision is certainly specific to a use case, there are guidelines for consideration:
1) PRPC and Robotics are NOT mutually exclusive. In fact, even for standalone RPAs that handle large volumes you will at the minimum need Pega Robot Manager application to manage deployments and most likely also manage RPA work (depending on how you build the RPA).
2) If a process that is a subject to digital transformation requires multiple handovers between multiple types of actors, such as human users, customers, and bots, then you will achieve results much quicker when the process is orchestrated on Pega 7 with just simple tasks farmed out to RPAs as part of the case flow. Specifically, user interfaces would be very laborsome to build into an RPA (or provide workarounds, like passing emails or Excel files between the users - yikes!) while they are readily available when provided through a Pega application.
3) If a process requires variable and frequently changing decision logic, then you will also absolutely need Pega 7 to be the "brains" to drive RPA because Pega platform has native decisioning features that you would otherwise have to code by hand into an RPA.
Hi, CloeW938 - while the ultimate design decision is certainly specific to a use case, there are guidelines for consideration:
1) PRPC and Robotics are NOT mutually exclusive. In fact, even for standalone RPAs that handle large volumes you will at the minimum need Pega Robot Manager application to manage deployments and most likely also manage RPA work (depending on how you build the RPA).
2) If a process that is a subject to digital transformation requires multiple handovers between multiple types of actors, such as human users, customers, and bots, then you will achieve results much quicker when the process is orchestrated on Pega 7 with just simple tasks farmed out to RPAs as part of the case flow. Specifically, user interfaces would be very laborsome to build into an RPA (or provide workarounds, like passing emails or Excel files between the users - yikes!) while they are readily available when provided through a Pega application.
3) If a process requires variable and frequently changing decision logic, then you will also absolutely need Pega 7 to be the "brains" to drive RPA because Pega platform has native decisioning features that you would otherwise have to code by hand into an RPA.
4) If a process requires any features that are already part of Pega platform (like email listener, email notifications, UIs, mashup, APIs, etc), then the pecking order is to utilize the capability of the platform out of the box rather than bolting something onto the RPA.
Overall, the best practice we use at Pega Consulting is that EVERY RPA is built utilizing Pega platform to whatever extent it can be leveraged to digitally transform the process, but at the minimum for deployment and work routing between the bots. The best practice RPA design is to construct RPAs as very simple automations with inputs and outputs that are managed by a Pega case flow.