RPA is NOT about the robot.
Ian Barkin
Entrepreneur, Investor, LinkedIn Learning Instructor, 4x Founder, and Advocate of the 'worker of the future'.
I’ve been in the automation trenches for over five years. If I can impart one piece of wisdom above all others, it is simply this…
RPA is NOT about the robot.
I have watched in somewhat quizzical amusement as enterprises have followed in an all-too predictable series of adoption phases. And, almost without fail, the natural inclination of teams looking to understand and adopt RPA in their operations is usually always wrong.
A strong statement, I know. But worth repeating. Enterprises are adopting RPA wrong. All wrong.
It doesn’t seem to be confined to one industry, one region, or even one process area within an organization. They just all seem to be consistently, predictably, amazingly prone to head down the same (wrong) path in the early days of adoption. And, this wrong direction isn’t just wrong to me – a service provider keen on selling services. It appears to be wrong in general. Wrong for the well-being of the enterprise. Wrong for the stability of the adoption. Wrong for the careers of those choosing to spearhead the adoption of RPA within their organizations.
So, with all that said, I wanted to share the misconceptions I’ve witnessed while on this journey over the last five years:
Must…demo…software!!
There appears to be an innate need to demo software. Like moths to a flame, people can't help themselves. If you just learned about RPA, or your boss told you to figure it out and use it (now!), you can bet you're ringing up the Googled top 3 and asking them for demos.
It will be weeks, maybe months, before you realize that the software isn't the central actor in this play. By then, you may have also realized that the vendors have all told you they’re the best, and you probably don't have the frame of reference or context with which to assess or test these claims. But, one thing I can guarantee – by the time you're talking to me (or any other service provider), you'll have already seen demos. And, all that means (most likely) is that you've found a hammer you've decided you like. I'll then ask you if the opportunities in your organization are all nails. And that’s where the first awkward silence occurs.
It sounds so good, it must be true!
There's no such thing as a free lunch. Or magic (sorry, Harry Potter fans). There's also no such thing as software that 'automagically' learns. And, just because we're calling them 'cognitive' these days doesn't mean that IVR and OCR are all of a sudden 100% accurate. Your organization didn’t become simple overnight. Your data didn't either. We're still solving complex and nuanced process-oriented challenges, in diverse and unique enterprise environments. This was hard before, and it still is. Yet, the fantastic promise of AI, cognitive and learning have made even the best of us find a belief in the promise of easy answers.
Speed is the absolute measure of success.
Fast doesn't mean good. Fast just means fast. Don't pick tools based on speed – at least not on speed alone. Often those tools that make automation so simple as to be fast, don't have the ability to handle the more complex rules, exceptions and intricacies that you definitely have lurking in your landscape.
It’s so easy, we should absolutely do this ourselves.
Put this belief to bed now. The software vendors propagated this story a few years ago in hopes of selling more licenses faster. The reputable vendors now realize, this is not easy – and they’ve stopped saying “this is so easy a business analyst can do it”.
Doing RPA right (like doing any significant project right) requires rigor, training, methodology, and careful management. It's why so many are pushing training, certifications, partner accreditations, and more. This is complex because your business is complex. You may have the ability to do it yourself. But, it's only because you respect the challenges of the ascent, and you hire, train and equip your team to make the climb the right way. But, as I mentioned in my last blog, if 2018 is to be the 'Year of the Robot' – you don’t have time to DIY this.
So, with that all said, my strong and passionate advice is this…RPA is NOT about the robot.
So, then, what is it about?
RPA is about change management. RPA is about proper governance. It’s about communications, change control, stakeholder management and getting back to the fundamentals. RPA is about the data. And, RPA is about being given a renewed opportunity to kick-off a transformation campaign – this time with a supercharged ability to truly create impact and unleash value.
So, go back to basics, respect the science of complex change, and remember – in 2018, the Year of the Robot, it’s not about the robot.
Senior Program Manager ? Not all of us can save the world. Some of us must make it worth saving. ?
6 年I prefer to say "We don't work at Hogwarts" when people assume magic is available to solve a problem, but point well made!?
Architect Practice Manager & Leader (EMEA) - Industry Solutions @Microsoft
6 年I worry about the word, ‘process’ in the RPA acronym. There is a clear distinction between sequential activities and decisions that being made within those activities. We have seen a number of banks make this clear distinction and therefore able to model and encapsulate decisions for reuse in any process. This is where I believe a significant amount of governance and change management actually lies. This article makes procedural (process) and declarative (decision) work clear - https://www.dhirubhai.net/pulse/what-decision-aware-business-process-how-design-one-jaydeep-dhar This link: https://m.youtube.com/watch?v=mM4EXgOMBCE -describes the approach to modelling a decision (based on a maths equation and the deterministic type we identify as RPA ‘potential’). We should not mix up modelling a process versus modelling a decision. In implementing RPA as part of an automation solution, it is important to decide what the role of RPA is for procedural or declarative work plus the consideration of reuse with other solutions such as APIs. I think this video is one of the best resources I could find with a good metaphor to drive the point I am trying to make. We would have this requirement for many different scenarios e.g. person travelling on business to airport or regular trip to work or to the shop etc. Process may be different however the mathematical formula supporting the decision in terms of how long a trip to/from a destination will have common factors and local factors.We want to roll out the mathematical problem consistently - RPA is ‘fit for rule based processes’ yet is not the right tool to deliver consistent decisions. We need a different business solution for that.
Solution Delivery Lead / Developer / Business Analyst - Robotic Process Automation (RPA) in Budapest, Hungary
6 年Well, RPA certificates are not indicating, if a developer can put together high complexity solutions. Those certificates are just indicating that they can "press the buttons" along the UI. I agree, the tools have different capabilities that should be considered before any development is done. For example, I'd never ever use anything other than Blue Prism for a process with a Medium or Above complexity. Most of the tools' UI just simply can't handle logic complexity well. Be careful! If you want to mow the lawn, use a lawnmower, not a hammer!
Partner, Co-Founder, Reimagining Customer Service, CAI, GenAI, Customer Service Channel Strategy
6 年Well said, Ian.