Sorting through the RPA Hype – What IS the Role of the Business User in this RPA World?

Sorting through the RPA Hype – What IS the Role of the Business User in this RPA World?

So where do business users fit in this RPA space? Business users have a role to play – and it’s a very integrated role but it is not in developing the automations no matter how good a vendors’ “automation recorder” may be. The business should be the ones identifying the opportunities, documenting the opportunities and be an integral process in the agile process contributing to ongoing process improvement, testing, adoption, etc. That’s the beauty of agile delivery…collaboration between business and IT quick and iterative development, not letting fear of failure delay progress, if at first you fail… try try again. Wasn’t this the root cause we were trying to solve for? in the first place.

It’s no surprise that best in class RPA success is delivered via Agile teams. These agile teams are supported by classic developers with experience in Java / .Net (who build with low code /no code RPA platforms), business analysts who are intimate with the business processes to be automated and are often from the department or area of focus and/or from your continuous improvement, and a program manager / scrum master to help manage the projects. ***NOTE: Where this team resides (reporting relationship) could be up through the business or IT but when it comes to physical location… nothing better than putting teams closer to where the work is being done…the business.


For RPA to truly scale throughout the enterprise, a more disciplined and realistic view of the people, process and technology that support it is required or else we will all be sitting here in a year or two asking the same questions When it comes to the People question, the answer should not continue to be business user built. Ease of use is absolutely the right path, but the development and management of those platforms should be IT. When it comes to process, invest in Agile or “Agile’like” system development life cycle (SDLC) methodologies which promotes speed and most importantly, collaboration between business and IT. Only then can we look to repurpose this IT wedge and turn it into a much-needed bridge within our organizations. If we do that right with RPA and subsequent disrupting technology introductions, we create a win-win-win scenario for our space.

So, let’s recap:

  • RPA for business users, no!
  • Who builds the automation – associates with an IT background in development
  • Can a business user download and use one of these tools to build a simple automation? – sure but that’s as far as they should take it. Simple automations don’t drive 20-30% automation rates in your business. Let the business focus on identifying the problems and move your organization to an agile RPA methodology which facilitates IT / business collaboration, speed, iterative development… all in an effort to remove the IT / Business wedge.
  • Can the RPA agile team / org sit physically with and/or roll up to the business, absolutely.

To fix this RPA scale problem, let’s finally take some time as a vendor and customer community to address the cause and not the symptom here. IT and business NEED to work together for any technology to scale, especially when it comes to RPA. Change management, process identification are two critical factors to enterprise scalability for any automation program and without a collaborative effort by both teams, supported by an agile team and delivery methodology, you may build a bot or 10 but you will not digitally transform your enterprise.

What if RPA was demo’d and described as a no code, collaborative automation development environment for IT and the business. Where… if used in conjunction with modernized SDLC methodologies (people and process), only then can we really begin to transform the organization into a more collaborative and agile environment where our initial business goal of delivery faster, cheaper and more flexible technology capabilities (RPA bots in this case) at speed can be realized. Thereby working to remove the IT / Business wedge, one iterative pull at a time.


This is quite a bold claim one might say, so where does it come from and what facts do you have to back that up. Well, outside my previous RPA experience, several customer surveys

The Signs are everywhere:

About the author Scott Merritt is a passionate advocate of “Responsible RPA” having spent the last 15 years embedded in the process optimization and RPA space performing over 100 process automation assessments and supporting over 50 RPA implementations. As Global Head of Automation for Uniphore, Scott leads the go-to-market strategy for their automation portfolio and works as a trusted advisor for customers and prospects actively pursuing a digital transformation strategy. Scott has 20+ years’ experience in enterprise technology, serving in consulting, sales and sales leadership roles and carries with him a Lean Six Sigma Black Belt which he acquired earlier in his career during his tenure at Cardinal Health.

Table of Contents