Overall Satisfaction with Pega RPA
Pega RPA has been used for a few years and the response is positive, it was started from one department and later on, it has been used in different verticals. It is very good in RDA(robot desktop automation) as well as RPA (robotics process automation), As of now, all the carried projects are related to manual processes automation which reduced man-hours and operation costs.
- Pega RPA has translators for specific platforms which makes it easy to integrate and automate. For example, .Net translators helps to interrogate applications based on .Net platform.
- "Wait for Create" feature is not available in any other RPA tool, which is handy during RPA workflows.
- Pega RPA has special features for Pega application which makes it a preferred RPA tool for them.
- Pega RPA doesn't have centralized control room which is available in other RPA tools. It should be there for the centralized control of bots.
- Pega RPA should have better help documents and tutorials. Help.Openspan.com doesn't contain enough examples to understand the product. This will ease the lives of developers.
- It should have better recording and data scrapping features which are present in other RPA tools like UIPath, AA, and Blueprism.
- Once bots are deployed they carry out work 24*7*365, which resulted in saving several work hours.
- The support team has to monitor regularly. If there is no change in target applications or bots are running fine. This is a bit of negative impact from RPA side.
- Overall, the organizations are benefited from bots as they save operation cost and work hours.
Pega RPA and UIPath both are tools for Robotic process automation. In our projects we were dealing with Pega applications which are easily coupled with Pega RPA. It is better in a multi-threading environment as separate features are provided in Pega RPA. In UIPath, one needs to know VB.NET in order to write custom code which is not a popular programming language. And in Pega RPA, it is a C# and .Net application which is famous among programmers.
It is not suited for centralized bot deployments. If several bots need to be deployed, then it will be difficult to manage and control. Programmers have to create custom code components to collect log files, health files, etc. On the other hand, it is best suited for an application which takes a random time to load, works in Windows MDI, or in parallel programming.