RPA in the Real World – Computer Measurement Group

RPA in the Real World

YES! Mainframe jobs just for YOU!
November 21, 2019
5 Ways AI Assists Project Managers
5 Ways AI Assists Project Managers
December 6, 2019

RPA in the Real World

RPA in the Real World


Today we are going to explore a real-world journey into RPA (Robotic Process Automation).  This particular journey was taken with Mize Houser & Company, an accounting firm that services multiple lines of business including franchise owners.

As many others have done, I researched RPA online and was left with more questions than answers.



As a service oriented company, we are continuing to explore ways to:

  • Provide better service to our clients
  • Increase Productivity
  • Decrease Cost

As many of you know, RPA will fit the first two items well but what about the third?  Does it really “Decrease Cost”?  The answer in my experience is Yes and No.  In the long term you should see cost savings but do not go into RPA expecting immediate savings to your bottom line.  What you want to do is look at RPA as growing your top line and/or increasing your service to clients while maintaining your existing cost. This is the model we will be focusing on in this article.



During the RPA research process, I received an email from a colleague who is now working with an IT consultancy, who hosts a summit on automation.  The decision was made to attend and this was the real kickoff for the journey.  Not knowing what to expect I went into the first day of the summit with reservations, I was hoping for real information and was pleasantly surprised when that was what I received.  Yes the sponsors did have sessions on why their tool was the best but that is to be expected.  However, the panel sessions were fascinating to me.  Real companies that had real needs in open discussion on RPA solutions.

As the conference went on and I had the opportunity to speak with individuals that had been down this path with their organizations I became more and more interested in RPA.  But still many questions remained.

  • How does it fit our processes?
  • Which software is the best?
  • What will the ROI look like?
  • How do I choose a vendor?
  • What training is available?
  • What is the licensing model?
  • How is the logic coded?
  • How is it managed?
  • What skill level is needed?
  • Will this work for our company?



A large number of attendees at the Summit were in the same place as we were.  During the panel discussions questions being asked resonated though the audience.  The biggest question being “where do we begin?”.  The answer was not as simple as we had hoped.  We all need to begin by understanding where we wish to be.  This was different for each of us as we represented many different types of business.  However it was good to hear from those that were in same or similar types of industry and it slowly became clear to all of us that we had already started the RPA journey.  Research, discussions, asking questions is where we start this process.  A path began to appear for next steps.  Realization was setting in that this was a new way of thinking about automation.



Throughout the summit we began to understand the value of the process and the questions surrounding it.

  • Is the existing process a good process?
  • Do you automate a bad process?
  • Do you change the process?
  • How do you make these determinations?

Our journey may not be like others as we have legacy systems that we control and can modify to streamline the automation.  When dealing with vendors this may or may not be an option.

In the end, having full control of systems utilized in the automation process gave us a measure of control over the changes we needed to implement during the process.

Although I am not a fan of changing a process during implementation.  We did combine an existing manual process with a existing and proven back end load process to achieve our automation goals.



Returning from the Summit I was determined to put the newfound knowledge to work.  The company was behind the initiative and willing to allocate resources and funding to proceed.   Our first task was to meet with the business and come up with case studies where we thought RPA would benefit us the most.  I had my ideas but, in the end, the best-case study was one I had not even considered.  As an IT Leader it is sometimes hard to take that step back and not insert your preconceived notions, but with RPA I think it is a must.  The business knows the processes, how they are run, how much it cost, and how they are going to change.  The last part (how they are going to change) was the determining factor in choosing our case study.  The process was in place and working on a monthly basis but unknown to us in IT the business had been struggling on how to make this a weekly process.

To explain the users process

  • Go to a Website
  • Download and Invoice
  • Process the Invoice
  • Load the data into AP system

This process takes an Accounting Services Representative approximately 4 (four) minutes to complete for each franchise location.  Our goals from the automation are to change process timing from monthly to weekly while increasing our customer service representatives billable hour availability.



Here comes the sell.  Our feedback to the business is not only can we get your process moved from monthly to weekly, but we can also free up the monthly hours you are currently spending on this process.

The Business reaction:  Sounds great but you know the old saying anything that sounds too good to be true usually is.

It was time to look for help.  We went back to an IT consultancy for a POC (Proof of Concept).  During this POC the IT consultancy team met with the business, created the documentation and developed a solution (on a limited basis).  It worked and we now had the attention of the business.  The leadership was behind us and we had a green light.  What we did not have was software, hardware, developers and support staff.  This is where it gets real.

How do we:

  • Select RPA software provider
  • Fit hardware in our current environment
  • Hire or free up resources
  • Determine true cost of implementation
  • Determine true cost of support
  • Determine true saving



Next logical step was to select a RPA software vendor.  All of the vendors are capable of doing the job and producing a solution that would satisfy our needs.   Many factors went into making our selection but in the end for our team, with our style, with our process we selected the best fit.  This is a must in your selection process.  You must determine what is the best fit for your team and environment.  I will add that I stay in contact with the other vendors and as we move forward, we may have more than one RPA software in use depending on the process and how it fits with the licensing models.   Now that the vendor is selected we can start putting cost to the project.  For ease of projections of cost and internal resource constraints we also decided to outsource the projects development to an IT consultancy.  This allowed us to have set cost for licensing, hardware, and development.  The variable was support.  With a lot of research and the help of the IT consultancy we had a proposal and an ROI.  It was time to move forward with development.



With all the pre-work done we began documenting the process.  The PDD (Process Design Document) was new to our organization.  We spent time with the users and even filmed them doing the process.  This helped us ask questions and helped the user see what they automatically do and may forget to include.

Moving on to the SDD (Solutions Design Document) we created the steps that would be included and selected our automation vendor to complete the process.  The actual coding time was not that long (a few weeks) but success would not have as easily been achieved without taking the time to document and understand the process.

After coding and testing the BOT went into production.  We still had some concerns regarding load balancing and moved work to the BOT slowly, making adjustments along the way.  Today I am happy to say that the BOT is running unattended 7 (seven) days a week and we have moved from a monthly to a weekly process increasing the value to our clients.

Was everything easy? No

Did we have issues? Yes

But with understanding the process steps, understanding how to monitor, adjust and maintain the BOT we made it.

Our current problem is success.  As other departments have learned of the BOTs success and employees have spread the word of having the mundane work removed, every department now wants a BOT.  So, we are deeply immersed in the RPA expansion world and how do we succeed with ever increasing demands.  Stay tuned for further updates on this wild ride we call RPA.


By Steven McDonald

Steve McDonald is a Senior IT leader with extensive experience in Robotic Process Automation, including leading the selection and implementation of RPA at Mize Houser & Company. He also has experience working with business units in evaluating evolving business requirements and making recommendations/decisions based on detailed evaluation of compliance, cost, return, expectations, exceptions and feasibility. Steve holds Lean DFSS and Six Sigma certifications.

Our Partners

Data Core

Upcoming Events