I was reading an article recently about how consultancies that implement RPA don’t even use it. Of course I began to fall out of my chair, as it reminded me of the Zig Ziglar story about selling pots and pans. How can you be any good at it if you don’t have a pair of pots or pans that you’re selling, if you don’t believe in your product? I found this so fascinating, I decided to ponder why it could be, and why is my company different from the norm (yes, we use RPA quite a bit).
It starts with process, and what things do the consultancies have they could automate. If they are small companies, perhaps they don’t have the time to sit and think about these things. But let that sink in, if you are hiring someone to implement RPA, shouldn’t they do it themselves? Shouldn’t you ask your RPA implementation group how they are using RPA themselves? But I digress. I’m here to tell you our Journey as an implementer of RPA, not as a company who does it for others, but as a company who does it for themselves.
The most important thing for us (and for you) was to begin with the end in mind. A clear direction in the beginning will keep you from making mistakes that will be costly down the road. Things like compartmentalizing your automations so that they are reusable in many applications is important. We wanted to analyze our opportunities and make good choices. Just because something can be automated doesn’t mean that it should be automated. Also, we must evaluate the process and optimize it prior to automation because you do not want to automate poor processes.
So here is how we went about creating our own RPA processes. We created an end state vision as I stated above, much like we suggest for customers, on how we would integrate this into our every day business and customer applications. Once this was done, we decided on three different applications of RPA and processes to test bed on. Two of them were current project front facing for our existing customers, and one was internal. Our first process, internally, was to review our existing staff and understand where they are from a project perspective so that we would have visibility into people who were coming onto the bench, if they needed training or vacation, and if they could be reallocated to a new project. The frequency of this report is weekly and it consolidates three systems, as it shows us resource profitability. The next application was to be used in creating environments for SAP projects by which our customers are actively loading nightly data. The last was for onboarding and dissemination of letters to new customers for one of our clients.
A benefit of this process evaluation and automation is the documentation. In order to automate a process you need to document the process using a process design document (PDD). As you document new processes you also need to optimize them. There are several methods for evaluating this optimization. Having a LEAN, Six Sigma expert is a great help with this. Once a process is optimized then the PDD serves as a roadmap for automation and a by product is that we have the document available for training, detailed job descriptions, performance evaluations, etc. And unlike normal documents of this sort, RPA requires that they be updated and maintained so they won’t sit on a shelf collecting dust but become an integral part of our business activities.
The success of these programs gave way to new programs and enthusiasm in our existing projects to leverage RPA. Our latest example is utilizing RPA to download scoring details for our recent job applicants.