What's the best way to trial RPA software?

There are a few tools that provide their powerful community editions to try and implement process automation as part of a PoC. UiPath is a software that provides its platform as a community edition to try and automate a business process in a similar fashion as a licensed version would work. The best way to conduct a trial or a PoC is to get a Business Analyst to analyze a business process that can be automated in a short time and you can sense how the automation works. A quick PoC is what you will need to make a decision rather than getting into a PoC for a long time. With UiPath, you can use their community edition for doing a PoC in-house or hire their Business Partners (like www.auxiliobits.com ) who can take the pain of identifying, structuring, and implementing the PoC. UiPath works on a model where their Business Partners are the designated ones who are the subject matter experts in the domain.

For other tools, you may request a company conducting a PoC which might be a little expensive and time consuming because of the unavailability of the community editions.

There 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.

• 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.

A 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.

Easy answer. The customer wants to see proof that RPA is easy to use, it is secure, and it does their work, not just any work.

They should want an RPA vendor to come to their location, load software on their development environment, and in two days or maybe three automate a task that once automated could start saving money, freeing a worker to do something else, clear backlog or just make work more efficient.

Show the client RPA works. That is what we do 100% of the time. Free of charge.

In addition to the points covered by fellow commentators:

You may follow the below:

1. Have a clear understanding of your objective
2. Invite bids with clear view on
Time to implement, ongoing execution and support
Cost for all of the above streams
Who's responsibility if the bot fails?
Domain understanding of the product / licensing team of the supplier (this becomes a serious bandwidth problem later on - when the buyer has to coach/train the supplier on process)

Start with this and see the response post that its the usual project & sourcing play.

Hidden costs include:
Infrastructure cost
Implementation and configuration (this typically works out to he more expensive then the license cost)
Support cost for any change in format and infrastructure (This is a killer cost and evetually makes the project cumbersome and non- viable)

Steer clear of per usage or per min models (unless you are crystal clear on usage)

Hope this helps.