This is a guest post from Prasad Krishna from HTC Global Services. Prasad is a passionate RPA developer with 4+ years of development experience using Automation Anywhere. In his free time, he enjoys playing music, watching cricket, documentaries, and action-thriller movies. When he’s not building bots, you can find Prasad on Linkedin.
Author and speaker Tony Robbins was once quoted as saying "Success Leaves Clues".
While Robbins was primarily referring to the study of successful and happy individuals that we may come across in our personal and professional lives to understand their habits and techniques, his statement is also applicable to the development and implementation of automation solutions.
What do successful intelligent document processing (IDP) implementations have in common? How can you take the most optimal path to recognizing our target ROI by learning from the lessons, challenges, and mistakes of others?
In this blog post, I want to dive into some of the key things to "know" for finding success in your IQ Bot implementation. By leveraging some of these lessons learned/gotchas, hopefully, other Automation Anywhere customers and partners can work as efficiently as possible at realizing their RPA and IQ Bot goals.
Know your Process
It's critically important - as you dive into your intelligent document processing journey - that you know exactly what you want to solve for. Familiarize yourself with not only the documents that are being targeted for processing but also the business process that surrounds those documents.
"Once a human has received this form (invoice/PO/insurance claim, etc), what happens next in the process? What data do they care about? Where does the image need to be stored".
The more you can ask questions to understand and document the process, the more effective you can be at creating automations to meet the needs of your organization.
A successful IQ Bot implementation isn't just effectively performing an optical character recognition (OCR) on a form, it often includes the acquisition of documents, processing of documents, storage of documents, validation of extracted data, and typically the processing of transactions that the received documents were intended to trigger (payment, account rollover, completion of an outstanding business process, etc).
Know your Documents
Given that the topic of this blog post is all about IDP, it should be obvious that you'll need a good amount of sample documents for the training and subsequent validation of your IQ Bot learning instance(s).
For the training itself, review the documents targeted to select images that appear to be most representative of the document type as a whole. For example, if you're creating a learning instance to process invoices - identify the most common invoices that are received - and specifically note the channels of which they are most likely to arrive. (where channel is defined as email, fax, paper mail that is scanned, etc). This is critically important as the training of an IQ Bot learning instance should take place against the image types/qualities that the learning instance is most likely to see in production. Initially, this will likely mean starting with the 2-3 document types that are MOST commonly seen document types and can expand from there as the documents are thoroughly tested and moved into production.
Testing is another huge point not to be missed here. Once learning instances have been created - test, test, and test some more with REAL images which are representative of the document type in question. Don't just fake images and assume that this will work perfectly fine. Use as many real production images for your training, validation, and testing as possible. In this way, your Automation 360 bot can be as prepared as possible for the image/document types that it should see in real production scenarios.
Know What Can Be Reused
Bill Gates once said, "I always choose a lazy person to do a difficult job because a lazy person will find an easy way to do it." Part of being a good developer is knowing how to work smarter, not harder. That's especially true when it comes to developing automations. Identify the components within your process that may have re-use in other similar processes or even for other groups pursuing automation opportunities within the organization.
For bots, that may mean creating reusable subtasks that can be called by other parent bots...or it may mean the creation of custom packages using the Automation 360 Package SDK. For IQ Bot, that may mean creating reusable Python scripts that can be re-used across groups and imported as needed as opposed to writing custom validations for each group as you begin working on it.
Know When to Say No
In my experience, the most successful RPA/IQ Bot implementations have all started with a limited initial scope and have all phased their approach for expanding the initiatives from there. In RPA, this means not taking the automation opportunity that has the super high ROI but is an overly complex process as the first automation project for a new team.
In IQ Bot, this means recognizing that certain documents/document types will not be included in the very first IQ Bot project release, but that additional form/document types can be added later as the project continues. As developers, we're all too aware of how excited business leaders can get about the possibilities for task and process automation - especially when that automation can include the automated processing of documents. It's critically important for the success of your RPA program to build momentum by automating processes/documents that are more common/straightforward first before moving on to more complex use cases. T
he reasoning is twofold:
- Building momentum with early program successes can get other functional teams within the organization excited about the opportunities available to them with automation.
- This helps the program as a whole grow in a more organic and sustainable way.
- The development team implementing these solutions (especially if they are new to RPA) - will need time to develop what their best practices, reusable components, and documentation standards should look like going forward.
- They obviously don't have time for that if they are all pulling their hair out trying to automate very complex use cases right out of the gate.
- For more details on the considerations for best practices, see the CoE learning journey available on the Automation Anywhere Developer Portal
Conclusion
As a final "know", I would say know the capabilities you have at your disposal. Unlike traditional enterprise document scanning applications, IQ Bot is deeply integrated into Automation 360 - enabling users to not only process document-based transactions but also follow through with the subsequent tasks required to complete the end-to-end business process. T
he more that you (as a developer) understand the capabilities of Automation 360, the use of different packages that are available to you (including Bot Store packages), and the more that you understand how to use and customize your IQ Bot learning instance - the more equipped you will be to take on different automation challenges.
So from the perspective of an individual developer - the call to action is to learn and master the tools available to you. From the perspective of an organization, the call to action is slightly different. In most organizations, the most manual task in a process typically determines the performance of that process. If a business process includes paper/form-based transactions, it's typically these manual, form-based steps that slow down the end-to-end processing of transactions as a whole. From an organizational call to action, consider how you can start looking at the automation of end-to-end processes as opposed to singular tasks. In this way, your organization can start to see a meaningful lift in your SLAs and a considerably improved customer experience.