Robotic Process Automation (RPA) Forum
Dec 11 2019
Hi everyone, Are there any RPA products in the market that Bots can run without the centralized control module? Thank you for your assistance, Josh
AnimeshJainRPA can be configured to run in a standalone mode. Depending on the product, different capabilities are available. To illustrate, bots developed in UiPath can be deployed on a "Robot" without any connectivity to "Orchestrator". This is completely product dependent as the same cannot be done in other tools such as Automation Anywhere. We utilize this pattern when the bot deployment is on a local desktop (attended or unattended) instead of a server-based deployment as a risk associated with the bot (due to lack of code management) is localized.
Adrian Cathcart-JamesYes there are, however one key concepts to a a successful RPA project is the ability to see how the bots are performing and typically that is done through a console. Exactly the same way you would monitor a person's performance. Hope that helps. Adrian
Birinder SinghAll RPA products have the ability to run bots without centralized control modules. UiPath, for example, has 2 types of bots - Attended and Unattended. The Unattended bots will need a centralized control module - in this case an Orchestrator. The Attended bots, however, can be run without the Orchestrator. Although it is recommended that bots must be centrally monitored and managed for more control, running them without a central module is also possible.
Oct 10 2019
When evaluating Robotic Process Automation, what aspect do you think is the most important to look for?
Let the community know what you think. Share your opinions now!
Diana RichardsonDepends where you want the Centre of Excellence to sit - with IT or with the business. If it's with the business, it should be easy to build the process flows without extensive coding knowledge
reviewer11135731. It's important to understand the architecture of the RPA 2. It's critical to evaluate its suitability with respect to the operational or business processes of your organization. 3. It's important to have visibility of implementation beyond POC use cases. 4. It's critical to examine the licensing policies of the tool especially if you are considering its implementation enterprise-wide. 5. Cost of Licencing and the benefit it provides should be analyzed. In short, ROI should be taken into consideration. 6. The requirement of the infrastructure for the tool should be taken into consideration. 7. Availability of initial training on the functionalities as well as possible use cases should be ensured. 8. POC need to be conducted with multiple and dissimilar use cases prior to initiating the buying process. 9. Complete understanding about the support during the initial period as well as post that should be ascertained including the cost of support 10. Evaluate flexibility regarding licensing, upgrades, add-on costs, etc.
seniorap1018023While evaluating a process to be automated, it is important to check does the process involves any human intervention like human decision making step which would be a hurdle for RPA bot as today.
Sep 25 2019
How has (or will) robotic process automation revolutionized the banking industry? What processes are already being put to good use? What's in the pipeline?
Andrew_WrightIn the healthcare insurance industry it has been successfully deployed in managing specific claims payments, onboarding of new clients and underwriting the benefits. Pipeline opportunities include scaling the existing process automation across the enterprise and all business units, plus expanding the use of RPA to automate the authorisation of benefits for hospital and specialised care.
SwethaTHello, 1. What are the potential uses for RPA bots in the financial industry? Here are a few of the most widely adopted RPA use cases in Banking: Customer Service Banks deal with multiple queries every day ranging from account information to application status to balance information. It becomes difficult for banks to respond to queries with low turnaround time. RPA can automate such rule-based processes to respond to queries in real-time and reduce turnaround time to seconds, freeing up human resources for more critical tasks. KYC Compliance Process RPA increases productivity with 24/7 availability and highest accuracy improving the quality of compliance process. Know Your Customer (KYC) is a mandatory process for banks for every customer. This process includes conducting manual background checks on the customers. Banks have started using RPA to validate customer data. With RPA the process can be completed with minimal errors and staff and with increased accuracy and reduced costs. Credit Card Processing Traditional credit card application processing used to take weeks to validate the customer information and approve credit card. With the help of RPA, banks now can process the application within hours. RPA can talk to multiple systems simultaneously to validate the information like required documents, background checks, credit checks and take the decision of the basis of rules to approve or disapprove the application. Mortgage Loan Processing On average it takes approximately 50 to 53 days to process a mortgage loan. The Process of approving mortgage loan goes through various checks like credit checks, repayment history, employment verification, and inspection. A minor error can slow down the process. As the process is based on a specific set of rules and checks, RPA can accelerate the process and clear the bottleneck to reduce the processing time to minutes from days. Fraud Detection It is difficult for banks to track all the transactions to flag the possible fraud transaction. Whereas RPA can track the transactions and raise the flag for possible fraud transaction pattern in real-time reducing the delay in response. In certain cases, RPA can prevent fraud by blocking accounts and stopping transactions. 2. How has (or will) robotic process automation revolutionized the banking industry? RPA has and will continue to help banking institutions reduce or eliminate reliance on inefficient, error-prone and expensive manual processes. RPA is already being used to optimize services that are used in Banking on daily basis including, generating financial statements, reconciliation of account balances, loan application processing (Credit cards, Installment loans, Mortgages) and other aspects of credit management like underwriting. RPA can minimize financial cyber threats by automating a broad spectrum of fraud prevention processes, like blocking or reissuing breached accounts, changing the account restriction criteria and automatically scanning negative files for the latest updates. 3. What processes are already being put to good use? What's in the pipeline? RPA is already being used today to automate the processes listed in Q1. The future pipeline will include further integration of RPA with cognitive intelligence technologies such as machine learning and natural language processing (NLP) to enable more process automation and transformation. In addition, new RPA attended automation capabilities will enable customer service representatives to access data and collaborate with coworkers in real-time while on the phone or text chatting with customers.
Sep 25 2019
What processes can't be automated just yet? What improvements to those limitations can we expect in the next 5-10 years?
Infrastr17d7From Saibal response I would challenge question #1 bulletpoint #2: i think that you can find intelligent solutions to deal with unstructured data. Do not limit to just structured data. I would also challenge question #2 bullet point #1: Why seasonal? I would say any manual and repetitive process regardless if it is seasonal or not. And question #2 bullet point #2; why just limited volume? actually the more volume the more ROI. because once the automation is implemented the costs are fixed.
Reddy SubramanyamIt is these benefits that are generating the boom in RPA interest – and a good measure of hype. However, every technology has its limitations, and RPA is best viewed as an additional cost reduction lever and a foundational technology rather than an operational panacea. Limitations of RPA include: First, RPA cannot read any data that is non-electronic with unstructured inputs. An example would be inbound correspondence such as paper customer letters. When a customer sends their energy company or bank a letter is it generally paper-based and unstructured. A company would then receive, scan and reallocate this letter to the correct department for processing. In this case, RPA will only work with a collection of other implemented technologies (such as OCR) required to make it digital and structured. This can become a costly hurdle before RPA can be applied, and companies may want to consider other solutions such as straight-through processing, digital capture, process optimization or other intelligent automation technologies. Second, companies need to be aware of diverse inputs coming from multiple sources. For example, in a procurement function, supplier invoices may be received in different formats, with fields placed in different areas. For a ‘Bot’ to be able to read an invoice, all supplier invoices must be received in the same format with the same fields. Although robots can be trained by exception to read different fields, they cannot read multiple different formats – unless these are all digital and configured separately. In practical terms, there will always be a volume and cost threshold below which RPA is not an economic solution, and companies should focus first on high volume/high-cost processes for maximum benefit. Third, RPA is not a cognitive computing solution. It cannot learn from experience and therefore has a ‘shelf life’. As processes evolve – for example, through the introduction and use of other technologies — they may become redundant and require changes. It is therefore wise for a company to examine the process prior to building a ‘Bot’. Typically, at our clients, we see a Bot shelf life to be anywhere from three to five years after implementation. Applied to a process that is inefficient and/or on the way out, that shelf life may be reduced to just a year. The business case may then not stack up. Finally, applying RPA to a broken and inefficient process will not fix it. RPA is not a Business Process Management solution and does not bring an end-to-end process view from approaches such as Lean Six Sigma. The same goes for out of date infrastructure – RPA will only mask the underlying issues. This can counteract any sustainable long-term savings by adding complexity which must be addressed down the line. Companies should focus first on addressing the root causes of their process or technology inefficiencies and then apply RPA to maximize the benefits
Saibal GoswamiThe processes having following characteristics are not suitable for RPA: 1. Any process that need human judgement to process 2. Any process which has data which is unstructured 3. Any process which has non-digital input source The processes having the below characteristics can be automated, however the ROI may not be encouraging: 1. Processes which are seasonal 2. Processes which has limited volume 3. Processes which are broken
Sep 19 2019
When implementing an RPA solution within your organization, what did you find to be the easiest process to automate, and why? Were you expecting the process to be easy? If not, what made it easy? Do you think the process would have been easy with any vendor or only the vendor who you implemented with?
Yaniv StrausThe easiest to automate was to download a report from one system and upload it to another. It was easy since both systems are simple and stable. I was not expecting it to be that easy, however both systems have great performance and they react to the default speed of our Kryon solution without the need to fine-tune it.
reviewer1031013-Easy to data entry process web scraper -Reading pdf -String manipulation -Mail reading -Excel process -Use cases in websites.
Director02e8We have implemented unattended robotic process automation. We found the following factors affecting the automation complexity: 1. Number of operational systems involved in the process 2. Number of required transactions 3. Number of stages in the flow 4. The number of branches in the process – conditions that cause the flow to split. 5. The complexity of exceptions handling. 6. Quality of cooperation with the involved business partners.
Aug 01 2019
Many members of our community are looking to understand how to calculate the ROI of an RPA deployment. Is it based on cost reduction, revenue impact, compliance, experience enhancement for employees and/or customers, or something else? What's the best way to measure the success of RPA?
Scott FrancisI'd advise a different approach, outlined in this blog post: "How to turn ROI into ROMG with RPA" - https://www.bp-3.com/blog/roi-into-romg-with-rpa/ 1. Look for areas of friction in collecting, receiving, or recognizing revenue! 2. Look for areas where your clients experience friction working with you! 3. Combine RPA with process, decisioning, and AI to fully capture value opportunities to generate that OMG reaction.
Amol GajbhiyeROI calculation based on the below parameters: 1. The total budget for development and implementation of RPA 2. Percentage of automation of the process 3. Expected effort savings based on point 2 4. Actual effort savings post implementation These are very standard parameters to come up with ROI but there are other factors that depend on actual process and environment which help to come up with actual ROI.
reviewer949524I had the opportunity to speak at an RPA vendor event and this is what I said: Each RPA processes may have these quantitative effects: - Reduction of manhours (obvious!) - Reduction of Total Throughput Time - Increase of frequency - Increase in volume - Avoidance of license cost (if legally possible) - Reduction of outsourcing/transfer to insourcing And also these qualitative (or maybe quantifiable but costly to measure) effects: - Customer satisfaction - Data quality - Reduction of human errors - Reduction of off-office hour task - Service quality - Trigger for Business Process Re-engineering (BPR) Furthermore, once you have a substantial number of processes automated, as an aggregated effect: - Reduction of overtime work (quantitative) - Transition to more value-added work (qualitative) - More reduction of outsourcing/transfer to insourcing - More Business Process Re-engineering (BPR)
Is it required in your company to conduct a security review before purchasing robotic process automation software? What are the common materials you use in the review? Do you have any tips or advice for the community? Any pitfalls to watch out for?
Birinder SinghSee here http://bit.ly/2WCIR53 Recognize the potential security risks associated with the Robotic Process Automation in an organization. Understand what features are available out of the box from the solution being deployed. For instance, if a solution being deployed is architecturally security supportive then we can make use of it to its best. Apply best practices while implementing and deploying an organization-wide RPA solution. The key to avoid security breaches is to first identify various potential security risks associated with an RPA project. The risks that a company must consider may include one or all of the following: - RPA robots may have access to the credentials that are normally possessed and used by a human worker. - Robots may have access to company privileged information. This information can be anything from personal staff data to financial data. -There is also a risk of unauthorized modification of automation workflows or their run time parameters in the production environment. -The modifications of automation workflows can also happen during development for which measures should be taken beforehand.
Vickram NehraVarious factors contribute towards our assessment of fitment and security of a tool for our development and production environment. These include the tool features and how the end product is likely to compromise my production environment. We need to ensure that our production environment is itself not vulnerable, the tool or a technology may just get exploited. We do look for how secure a tool or technology is before making a decision to use it. You should ask for the vulnerability assessment report and best practices from the vendor. Then it is generally a good practice to perform a threat modeling with the vendor to ensure all basis are covered.
Sukrutha KiniIn my view, we should ask the vendor of the tool to do the security review and share the report and certificate. I am sure they do a periodical review of their tools.
We all know it's important to conduct a trial or do a proof of concept as part of the buying process for robotic process automation. Do you have any advice for our community about the best way to conduct a trial or PoC? How would you conduct a trial effectively? Are there any mistakes which should be avoided?
Kal RabbA few simple rules - Pick a 'real' process to automate - Make it complex enough (but not too complex) so people don't say "I could write a macro in excel in a couple of days …" - If integrating with systems, make sure you can get access to them (i.e. IT won't shutdown access if a 'bot starts using them) - Make sure you are using real data - Keep the project small (you want to see output in 2-4 weeks) - Make sure the people who would benefit from, or be affected by (the automation) are involved Well, maybe that is more than a 'few'. But, it's a good question, and when my clients often stumble.
Michelle Mesina• Pick the high-volume processes and ideally with multiple interfaces to see the capability of the solution you are testing. • The complexity of the processes also helps; however, this will also determine the time it takes for the POC to be completed. If you have the time, choose a complex process that’s repetitive and high volume. You will get most of the benefits here. • Critical items during the POC creation: o Real data in a test/dev environment o How the automation will be triggered aka trigger point (is it attended or unattended – what is your priority? what are the advantages and disadvantages) o Be clear on your nonnegotiable o Process map of the current process with real timing immediately determines the effectiveness of the POC (Bot) o Determine success measures at the on-set (TAT, Customer experience, potential soft and hard savings) o Clear timelines of the POC creation o Integration capabilities and flexibility of the bot to adjust when there are system upgrades and changes otherwise having a bot can be more expensive • Overall there’s no perfect solution as each system will have pros and cons. However, it will always depend on your company’s objective and investment capacity.
MBFolgerThere is significant work involved before the trial or PoC begins. RPA is not a one-and-done quick fix. It's a company-wide initiative that requires stakeholder buy-in, clear understanding of objectives and expected returns, expertise to design/build/monitor/maintain/change workflows as they evolve over time. There are infrastructure considerations. Governance and steering to ensure you're building for now and the future. Look for these aspects in the processes you want to include in your pilot: rules-based and repetitive, accesses structured data, is high-volume, is stable, is performed by more than 1 FTE. For each workflow you select, it's essential to build the business case around it. ROI is different for every process. Labor savings is an obvious one, especially if you have numerous FTEs dedicated to performing those tasks. We also encourage clients to consider: 1) optimized operational costs 2) Reduced cycle time 3) Increased quality of work (eliminate rework, errors, variance) 4) Flexibility (timeliness, scalability, seasonality) 5) Reduced penalties 6) Greater compliance 7) Better insights 8) Improved customer experience. As for vendor selection, be sure to read the fine print and get a firm understanding of the total cost of ownership. Many vendors price out their various modules to design, build, or deploy robots. Licensing can be applied per user, per bot, per user/per module and carry minimums as well. Infrastructure requirements differ depending on the vendor and the type of work you're automating. Some vendors require you to keep trained staff on-hand to develop beyond their basic functionality. Some vendors charge for training. Of course, if you would rather have experts handle all of this for you, let me know.