What is your first thought when you hear RPA? Do you think about machines taking our jobs? Or maybe dream how much nicer your life could be if you did not have to do dull and repetitive tasks?
I must admit that not so long ago I thought that RPA is just another hype. But then I decided to learn more about it from the experts and today I am pretty excited about it.
I am happy to share with you guide that will help you successfully implement Robotic Process Automation thanks to the tips from over 30 experts sharing their DO's and DONT's.
In a hurry? Get the RPA guide as a convenient, downloadable PDF.
Below you can find the answers. You can either read everything or use the navigation below.
Now, let's dive into the answers.
Stefan Andreasen is a passionate entrepreneur, innovator and net-worker with solid background in both technology and business. He spent five years in Boston as head of R&D with Advanced Visual Systems, working on cutting-edge Computer Graphics and Visual Programming products. In 1998 he started Kapow as the largest European marketplace for cars, real estate and boats for sale. The items for sale was collected from thousands of dealer websites and made searchable on the www.kapow.net marketplace which had more than one million registered users. In 2001 the marketplace was sold to the largest bank in Denmark and Kapow became a pure-play software company – Kapow Software. As CEO of Kapow Software, Stefan Andreasen relocated the company headquarter to Silicon Valley where he grew the business to over $15million in yearly revenue until 2013 where Kapow was acquired by Kofax.
Today Stefan is back in Denmark where he serves as investor, adviser and board member for a number of technology startups while looking for the next big thing.
What would you suggest to a company that wants to start using Robotic Process Automation?
Be sure to get an RPA platform which supports both front-office (employee invoked) and back-office (taken from a queue or on schedule) automation.
At first focus on automating the simplest processes with the highest value of automation. Later more complex processes can be automated.
Be sure to set up governance rules and build framework/reusable components before starting to build RPA scripts.
Have experienced IT staff involved in setting up the right architecture, security rules and logic for audit trails before starting.
What are the most common errors you see in implementing RPA?
Not involving IT staff and security staff. This will almost for sure create RPA scripts which are not build on a solid framework for the figure.
Starting with automating complex processes, instead of simple ones.
Not getting an RPA platform which can serve both back-off and front-office needs.
David Brain is a process and automation expert who has gained recognition as the preeminent expert in Robotic Process Automation, recently being named 'Consultant of the Year 2016' by the Global Outsourcing Association for his work in transforming international organizations through deploying Future of Work technologies and methodologies. As COO, David has built, and now continues to lead, the global consulting, implementation and managed services teams within Symphony Ventures, ensuring flawless solution design and execution on every engagement.
Over the last couple of years, we have been approached by numerous organisations, the world over, to advise on taking the right first few steps on their RPA journey.
Many come with a pre-conception that the first necessary step is to perform a Proof of Concept (PoC). This is an exercise where we install the RPA software and perform some basic tasks, connecting to the line of business applications.
Usually these projects are delayed because of access to systems, InfoSec reviews, procurement, and legal discussions. The end-point is always the same: if the client sticks with the PoC and doesn't let the inertia win then the PoC is successful, the RPA software works but the sponsor, usually junior in the organisation, is left drained by a simple exercise made difficult by internal bureaucracy.
At the end, all that is proven is what the industry already knew. Yes, you can connect to the application and yes, you can perform a few tasks far simpler than you would see in any real deployment project. After all what would make that business that different to the hundreds or thousands that have gone before; with the same ERP, the same mainframes, legacy applications, SAAS apps, and custom apps developed in the same programming languages?
What is missed is the 'so what', that excites the board, the Proof of Value (PoV), the proof of what this can do for your business, the business impact RPA can have, and the problems RPA can solve for you.
Most commonly, issues come about from not understanding the business processes in enough detail, and therefore not catering for every eventuality. We typically approach implementations with a third of the time spent on capture and design, a third on implementation, and a third on testing.
Two thirds of the project is therefore focused on ensuring the business process and business rules are truly understood and the solution is fit for purpose. We often find that clients are surprised at just how complex 'simple' processes can be.
The other common challenge is in resourcing a project. The ideal RPA consultant is someone with a very logical mindset, programming experience, and an interest in solving business challenges. It is not a developer, nor is it an experienced member of the operations team, although the insight from your process subject matter expertise is essential in any project. Whilst developers do have the right skills, they often find the simplification of the configuration of RPA tools less interesting than building code from scratch, so retention of these resources is a challenge.
My advice to any organization embarking on RPA is to consider engaging with a specialist firm to leverage their experience, even if that engagement is to train up your team to be more effective.
As the Head of Product Marketing for the Pega 7 Platform, Ying Chen leads the strategy, positioning, and go to market for Pega's industry recognized platform for digital transformation. Ying comes to Pega with more than 10 years of software product management experience leading Fortune 1000 organizations and VC-backed startups with varying software development methodologies to deliver award winning product solutions and enabling enterprises to make the leap from water fall to Agile. Ying holds an MBA from Boston University Graduate School of Management and a Bachelor of Science from Carnegie Mellon University.
The challenge today is that many organizations still approach their automation efforts in a siloed fashion – they start by looking at specific tasks and or processes within departments or functional areas, rather than getting aligned around the outcome for the enterprise. Additionally, the market isn't helping either with so many RPA only tools vendors out there focusing on the core use cases of robotic automation in one concentrated area of on-shoring/staff replacement. Not surprisingly, many early adopters of RPA find themselves with multiple RPA vendors yet getting less than 10% of the intended ROI as an enterprise.
a. What is the enterprise outcome you are driving towards? Rather than a functional or department specific goal on productivity or cost savings, an outcome could be simplification of experience for employees and customers. This allows organizations to use a blended approach on robotics (attended and unattended) that not only maximizes cost savings/productivity but also delivers great customer experience.
b. Look for opportunities for automation that has the broadest reach and meaningful impact. For example: if you are looking to improve your NPS score, target areas that will help improve employee productivity rather than back office rote work. Projects such as shifting the manual copy and pasting of customer information by your highly-valued knowledge worker to robots during the customer onboarding process would be a great place to start.
c. Make sure your technology supports your use cases now and beyond. You might already be thinking about the role of RPA bots for the back office or perhaps quick wins via RPA assistant bots to support your knowledge workers – make sure the RPA technology you choose is flexible to support attended and unattended use cases. Additionally, for the enterprise, you'll need to think beyond RPA as the only arsenal available for automation. If your processes and applications are redundant, throwing RPA alone at the problem won't get you to the outcome you need – neither is applying AI at the RPA bot level. You need to partner with a vendor that provides choice in Enterprise Automation capabilities that include RPA, Intelligence that can be applied at the outcome and at the work level, and BPM/Case Management to orchestrate work and keep context – so that as the nature of your transformation evolves, you have choice of how and when to pull in the various pieces that is needed.
b. Starting too big rather than MVP – example: automate 100% of the work of a small group of people rather than increments of work across a large group of people. We observed how this "pivot" accelerates RPA success recently with a retail bank fraud team during an onsite assessment. The fraud team was divided into three departments (200 FTEs): Fraud Contact Center, Deposit Fraud, and Wire Fraud. Each team played a very different investigative role in their respective fraud transaction but all were focused on a common outcome, minimizing fraud exposure for the bank and their customers. The assessment team focused on identifying a single task that is performed most frequently across all three departments and focused on that one task as the starting point and was able demonstrate the value and the impact across the departments in less than 8 weeks.
c. When companies approach RPA as a stand-alone tool instead of a key capability part of supporting a broader Enterprise Automation framework. It is no wonder that we hear many stories of enterprises cycling through various RPA vendors and ultimately, end up with multiple vendors but still have achieved less than 10% in ROI. This Franken-stack approach has rapidly created the new shadow IT and makes it even more challenging for those who are accountable for technology to ensure governance and support.
When should you use BPM and when RPA software?
For a while, the market has approached BPM and RPA in a binary fashion – BPM or RPA. You'll hear from vendors that RPA should be used for rote work and quick starts while BPM is for digital transformation, process re-engineering, and/or places where there are no underlying applications to run the robots on top of. While all those benefits are true, what is missing from this binary approach is what Enterprises really need out of an Enterprise Automation framework that supports outcomes and agility. Where RPA, like BPM/Case Management, are one of multiple capabilities required in the enterprise automation tool box rather than the only tool.
Therefore, we see organizations that continue to hold this binary view end up with a Franken-stack of technologies that makes it a challenge to achieve continuous quick wins that scale and get to transformation.
The answer is not RPA vs. BPM but Enterprise Automation. Enterprise Automation with capabilities in: BPM and Case Management that allows you to define the "actor", "work unit", and "systems" required to achieve the outcome and the ability to orchestrate the work while keeping context. Intelligence that can be applied at the work level – not just at the bot – to guide the actor(s) working independently as well as together, and more importantly, get to your outcomes such as customer engagement and productivity. Lastly choice and flexibility to pull in these capabilities as your organization evolves across your transformation journey so that you can deliver rapid value along the way.
Pierre is engineer in computer science and applied mathematics from l'ENSEEIHT, specialized in Artificial Intelligence.
Contextor's advice are based on our 15 years' experience, with about 100,000 robots deployed in various industries. We firmly believe that RPA is complementary to BPM, to whom it provides agility, helping enterprise to engage its digital transformation.
We are convinced that it is paramount to exhaustively look all business processes to clearly identify where the most repetitive tasks are happening, even if they are simple tasks covering a small part of a global process. By starting there with attended RPA, you will succeed in quick wins by increasing employees comfort at work with more guidance, guaranteeing compliance to company policy or regulatory rules and bringing more agility to the IS. It will take a few weeks from the proof of concept to the running robots, and attended RPA will gain adhesion from clients and employees and provide fast ROI. After that, the work done with RPA could be reintegrated into the BPM.
One of the most common error is to see too big: if you were a mason, would you start your career by building a cathedral? Certainly not. Then do not start your RPA journey with a strategic and complicated process you would like to automatize from end to end. It would be the shortest path to disappointment, if not failure.
Another common error is to consider RPA as a technology more than a business tool: your RPA projects have to be pragmatically driven by a very small team combining operation managers and IS specialists. From the operations point of view, it is crucial to know how the employees are working with the processes, sometimes adapting them, and to un-zoom to detect from which processes automation will provide the more benefits. From the IS point of view, it is important to know the capabilities, and the limitations, of RPA tools towards the specificities of enterprise IS, especially regarding legacy applications.
Kevin Culliton is OpenConnect's Vice President of Product Management and Services. He's responsible for developing products and capabilities that solve targeted market problems for global enterprises. Culliton has over 30 years of experience in the technology sector and over 20 years of experience providing enterprise software solutions to Fortune 500 companies. He works with many of America's largest health insurance companies (one of OpenConnect's key markets), and is an expert in the areas of automation and process analysis for the purpose of automating. Culliton oversees both OpenConnect's premier mainframe robotic process automation (RPA) solution — which complies with strict industry standards and is used to automate complex processes — and OpenConnect's operational analytics solutions. He is currently working with current and future OpenConnect customers to provide the next generation of analytics and automation solutions for back-office operations.
First, make sure you understand the problems you're trying to solve. Are you cutting head count? Are you trying to increase productivity by simplifying your processes? The answers to those kinds of questions will help you figure out what exactly it is you're trying to automate in the first place.
Then, determine whether the processes you want to automate are complex – that is, something that a human might take some time to master — or simple. For example, the processing of insurance claims involves more complexity than most RPA tools can handle. So, if you want to automate complex tasks, this will help you considerably narrow down the choices of RPA tools and providers.
By far, the most common is the failure to have, and stick to, an automation strategy from the beginning. (By the way, a currently popular term for an automation strategy is "center of excellence," but I'll stick with the term "automation strategy" here because CoE can be used for a number of other purposes, while I'm referring to just automation.) Lots of companies are eager to jump right into RPA and start reaping its benefits, but they'll have only limited success if they don't have an automation strategy before they even start talking to vendors, much less actually buying and deploying RPA software. Simply put, an automation strategy is planning and management of the company's automation initiative. I wrote a blog post (http://blog.openconnect.com/robotic-process-automation-part-two/) which goes into some detail on the importance of an automation strategy and what it includes.
Beyond that error – and it covers a lot of ground – companies also run into the trap of what a former U.S. president might call "fuzzy math." One of the biggest problems organizations have is when their business units overestimate cost savings from RPA just to get their pet projects moved to the top of the list of what will get automated and when. If people can't show their math, the automation team can't take their estimates seriously when it's time to decide the next set of processes to automate.
Adam leads market development, product and brand marketing, and strategic partnerships. He began his career in management consulting in the Financial Institutions Group at BearingPoint and has spent the past 14 years in tech product marketing and advertising. He was most recently director of strategy at 360i.
Adam holds a bachelor degree from the University of Vermont.
Before selecting an RPA product, first determine what exactly you want to accomplish. Do you want to simply automate the operation of a legacy system (e.g., SAP, Oracle) to cut cost, or do you want to automate a more robust business process, like customer onboarding or claims handling? There are many products on the market at this point, and they have different capabilities.
RPA endeavors are often like the story of the Three Little Pigs. The first wave of RPA users built their houses of sticks, and now they're paying the price for not using brick. RPA alone (if-then-else programmable bots) is like building a house of sticks, in that it delivers quick wins. However, RPA alone creates exceptions and ignores the simple judgment work that weighs down an operation and can be automated with machine learning powered cognitive automation. Businesses looking for both quick wins and long-term value select products that combine both RPA and cognitive.
David Eddy VP & Director of Content Marketing: roles include: expanding Federal Gov't RPA opportunities; developing content marketing for customers and partners; building thought leadership for emerging RPA services and technology.
Prior to UiPath: Vice President, Global Outsourcing Services at CGI Group and Senior Manager of Strategic Global Sourcing at Infosys.
Three key beginning steps are: appointing a visible, senior champion; selecting an evangelist with good operational and relationship skills; choosing IT representative.
The champion is essential for enterprise-wide visibility, credibility, and funding; the operational evangelist is needed to fill a beginning pipeline and create a team with the technology and methodology to automate the qualified opportunities; IT must made aware of the technology and how it will be used.
The technology of a few RPA vendors has advanced dramatically – but many customers fall into the trap of viewing all robotic solutions as the being essentially the same. By not selecting the best technology, their implementations are crippled by issues with product usability; extensibility, scalability and virtual environments.
Another error is rushing past the building blocks of governance and methodology to show a quick success – typically on a very simple process. Which makes sense to a degree, but then RPA stumbles when the more difficult processes in the pipeline are automated, creating an environment for pushback and discouragement.
Bill Galusha is a Senior Product Marketing Manager at Kofax. He is responsible for worldwide marketing of the Kofax Kapow robotic process automation software platform. He has fifteen years product marketing and product management experience managing various software products and solutions. Prior to joining Kofax, he spent seven years at EMC as a product marketing manager for the EMC capture, BPM, and case management products and solutions.
Take the time to look at the big picture business challenges you are trying to solve, so that you fully understand how best to solve, and the benefits that can be achieved. Robotic Process Automation (RPA) is a great fit for automating a lot of different tasks or activities within a business process where gaps exist and work is still done manually. RPA has the potential to address many of the long-tail use cases that have been left to humans to do manually. By looking at a specific area of a business you may find that the problem is much larger than what you had first imagined and while robots can play a role there may be other key technologies required to solve.
Kofax and its global partners can help guide organizations through this process starting with an assessment and suitability analysis, and thus help establish a roadmap and prioritization for what processes to focus on first. From there organizations will have a solid RPA strategy and foundation to build from that can be sustained over the long haul where robotic automation becomes a part of the organizational culture.
The biggest mistakes we see is organizations focus just on the technology and not enough time understanding the business needs. We also see organizations trying to tackle the most complex process first rather than focusing on the "low hanging fruit" automation opportunities. For example some organizations have tried to approach situations like AP automation and apply robotic automation to solve an entire end-to-end accounts payable process. It's important for organizations to explore other vendor software solutions in this case where RPA used in combination with another solution (e.g. Accounts Payable) will avoid having to capture and rethink process rules that already exist in a proven solution.
President, Hasan Consulting Partners, Inc.
As a strategic and results-focused professional commanding more than 25 years of cross-functional marketing, sales and product management success on a global scale, Raheem Hasan has proven himself a versatile professional committed to excellence. Raheem has developed vast expertise in balancing strategy and pragmatic "hands-on" go-to-market program execution across product management, portfolio marketing, planning and program management. He has served in progressive positions for a number of large global organizations as well as start-up ventures.
As a Strategic Advisor and former President and Co-Founder of the Institute for Robotic Process Automation(IRPA), Raheem helped launch one of the most compelling independent professional associations and knowledge forums for the buyers, sellers, influencers and analysts of robotic process automation and artificial intelligence.
* Well defined benefits/ROI: While the RPA software provider's marketing material talks about 45% labor savings that will most likely NOT be the case for most buyers. Many of the RPA solutions are great at task compression, reducing those rote/repetitive tasks, but that may not result in big reduction in resources (based on the overall process workflow). While quite often cost reduction is the primary driver in the business case, there are also other secondary and tertiary benefits that should be considered, such as , error reduction, regulatory compliance, reduced cycle times, etc.
* Establish a Center of Value: Whether you call at a Center of Excellence or a RPA Shared Service Center it is important to have a focal point, a governance structure that provides a framework for how the organization evaluates potential RPA projects, evaluates tools, technology, deploys resources (internal or external) and most importantly, monitors impact/success.
* Not re-engineering processes and operations to take full advantage of RPA/automation: Automating a broken process is not going to deliver maximum value to the buyer.
Barbara Hodge is SSON's Global Editor, and has been with the organization since 2000, having joined to launch Shared Services News. She is now responsible for SSON's online portal content, including industry reports, case studies, surveys, interviews, etc. – as well as everything else that makes SSON the most trusted space for practitioners from around the world.
Barbara uses her extensive industry knowledge and connections to provide a unique perspective on the latest trends and developments across the SS&O landscape. She is the voice of ssonetwork.com, SSON's online content portal, and she regularly conducts interviews with key industry figures to ensure SSON is a one-stop shop for shared services and outsourcing resources.
Prior to joining SSON, Barbara was Editorial Director at Armstrong Information, a London-based specialist publishing firm, with responsibility for launch and editorial content management for a number of management journals, including corporate communication, change management and business process reengineering. She started her career with Deutsche Bank Capital Markets in London.
The most important aspect of implementing RPA, in terms of what I have seen and heard, is knowing what you want to get out of it. A lot of companies that have achieved amazing results have been smart from the outset in terms of clearly defining what represents an opportunity, communicating the targeted output or result, and then following a robust roadmap to get there. If you're not clear on what this means or how to get started then connect with one of the many RPA consultants [perhaps consultants rather than vendors, initially] to help you. Money spent up front on consultants may well be less than the cost of any delays or mistakes you might incur by tapping around in the dark.
The other comment I would have is that the best results come by tackling the big, simple, large-scale activities. The more complex the process, the more it might best be left for later. Initially, at least, you want to show that your project is successful and those results will be best measured in scale.
Picking off the complicated, fragmented, headache-types of processes to begin with. It's a learning curve and perhaps a steep one, as most change management initiatives are, especially where you are throwing a digital workforce into the mix. One practitioner who had achieved pretty fantastic results explained that his team treated automation as a valued guest, giving it all the best pieces. "The broken, complex parts we kept for ourselves" he explained.
Karen Inbar is a Solution Marketer for NICE Real-Time Solutions.
Karen brings over 15 years of experience in marketing strategy and product marketing, acquired while working for leading global high-tech companies.
We suggest that companies hire a consulting firm or the consulting services of a leading vendor in the field, like NICE. This would help them assess and analyze existing processes and whether they're a good fit for automation. It would also help them assess the potential ROI and savings of RPA to the business in various areas (as typically RPA starts in the contact center/back office/ shared services functions etc). Some processes would need to be optimized before they are assigned automation business rules. Another important assessment to make is whether a process is best automated end-to-end on a backend server (unattended automation), or whether it is better to automate parts of the process on the employee's desktop (attended automation).
a. Starting too big: Starting from the complex processes and automating a large process in one chunk instead of breaking it into small mini-processes. It is recommended to start from smaller processes where robots will not take more than 1-2 minutes to run. More complex processes will take more time to design, implement and test, meaning a longer time until you start seeing the ROI. Our recommendation – start small, see the benefits and grow from there to the more complex processes.
b. False expectation following wrong focus in the Proof of Concept (POC) – Conducting a POC before defining the automation path (which vendor to choose and how to approach the project) is a good practice. However, a common error here is to focus only on the development time for one simple flow. As part of the POC, companies need to understand how automations are maintained, how a team could effectively work together building enterprise scale automations, how common flows can be shared and re-used, and how to manage the automation life cycle with a focus on how to adjust to underlying applications being changed.
c. 'Happy path' process design – When building automation processes in a "POC" mode, the automation should remain robust and versatile. If the automation process is built without thinking about outlier circumstances or rare events that could happen, it will break often and lead to a poor customer experience. The control center needs to verify with the field how the process is executed, since oftentimes what appears to be a 'text book' automation process in the training room ends up being incompatible with how the process is actually executed.
Cristian Ivanus is a BPM Managing Consultant and Robotic Process Automation Lead at Capgemini Services Romania SRL.
Cristian is also managing the Romanian ABPMP Chapter.
In order to start any RPA initiative, I would suggest to conduct a process maturity assessment to understand whether the organization is capable to understand and if it oriented toward a process management approach.
Another point that should be taken into consideration by the organization is the stability of the processes subject to RPA. Should worth also to mention that RPA is applicable on standardized, highly repetitive and human work intensive processes. To reach the above condition, it is mandatory to run an specific RPA assessment framework in order to establish and prioritize the processes that can be robotized.
– implement RPA on AS-IS processes without a pre-assessment to evaluate the potential of the process to be robotized.
– process is not optimized/standardized.
– all exceptions that may occur are not taken into consideration.
– architecture of the solution is not always optimized.
The worse thing that may happen after the implementation of an RPA solution, without a complete assessment, is the fact that the process indicators may encounter a degradation of the performance instead of an improvement.
Emiel has been working as a trainer and consultant for vendors of software like BPM tooling, since 1999. He also started his own initiative, Procesje.nl, a valuable source of practical and common sense information about Business Process Management and how to avoid blindly following the trends.
Emiel is known from his practical and unorthodox approach to BPM.
He is also a contributor to bpm.com where he is a very active participant of discussion forums. You can also find lots of his both informative and entertaining tweets on Twitter.
Answer the question, like with anything you buy, what problem does it solve?
To be honest, I only know a few RPA products and the main thing they do is find, format and transfer data. From one place to another place. By software robots.
Most RPA marketers focus on organizations where that is still done manually. And yes, as a process owner I would love to automate manual work. Saves time, money and errors. Improves my profit!
But (sorry for that), I am an old school process improver that doesn't want to automate crap. I always start with making clear that the process itself is useful. Cheap useless processes are still useless.
And then I go deeper; do we still need all that data to execute or manage the process? Why don't we have one source of data? You are probably familiar with those kind of process analysis questions.
And I know, that also costs time and money. But to me it wouldn't make sense replacing your chainsaw by a feller buncher if you don't need the wood of the trees you're cutting down.
In general; not answering the questions above.
But as a human, the social consequences worry me the most. As told, as a process owner, I would love to execute my processes cheaper. Unfortunately that often mean people lose their job. And these days many people still have those administrative data processing types of jobs. I hope companies will take that into consideration.
On the other side; the cool thing is (in my opinion) that administrative jobs will become less popular in the future. This hopefully leads to the fact that kids learn a real craft again. Jobs where they make things. Maybe digital things like robots or AI algorithms, but also real stuff.
Sandy is a "technology catalyst" with a 20-year history of software design and systems architecture in several technology areas, combined with a deep understanding of business environments and how technology can impact them.
She has also founded and run three companies – a systems integration services company, a software product company, and current consulting company – with responsibility for corporate and financial governance, strategic direction, team hiring and management, and day-to-day technical contributions.
What are the best ways for an organization to use BPM and RPA to get the results?
Robotic Process Automation (RPA) and Business Process Management (BPM) have a long history together as complementary technologies. In the 1980s and 1990s, it was common to use "screen scraping" — a primitive precursor to RPA — to automate interactions with text-based mainframe applications running in a terminal emulator. This was necessary because the mainframe applications typically did not have APIs or any other callable interfaces, so the only way to interact with them was to emulate a user by sending keystrokes and reading the results from the terminal window. This type of integration could be used to hide the text screens from the user and replace them with more functional user interfaces, and to automate actions on the text screens by sending keystrokes to the screen in order to assist the user in their tasks. In many cases, a workflow system was integrated "at the glass" with the mainframe applications via the replacement UI to provide a consolidated view for the user in receiving and completing their work so that they did not have to flip between screens in order to get things done.
Eventually, screen-scraping made way for RPA, and workflow evolved into BPM, with opportunities for these technologies to be used together effectively.
RPA is a fast way to automate user tasks with a minimum of effort and disruption for both the users and IT. The users don't have to learn a new line-of-business application, and may just see the RPA functions as "helper" capabilities that take actions such as logging them into multiple systems simultaneously each morning, or performing a financial reconciliation between multiple systems. The existing applications don't need to change, and the changes to the users' desktop environment is minimal.
RPA can also gather information about what users are doing with their desktop applications in conjunction with this automation, effectively gathering information about what the users are really doing and how much time they're spending on tasks that could be automated.
Some of the tasks automated using RPA will stay in RPA: where the applications being integrated can't be changed out, or for "long tail" situations that benefit only a small number of users. However, the automation and analytics provided by RPA can also be used as a discovery tool for BPM implementation: the RPA automation provides a sort of prototype for what could be done with a more comprehensive BPM automation, and the analytics provides insights into how tasks are completed and where efforts are wasted on tasks that could be easily automated. When the time comes to do a complete redevelopment of the users' desktop applications and semi-manual processes on a BPM platform, the lessons learned during the use of RPA can be used to determine the best approach in the BPM application development.
My advice: just get started with RPA. There's a very low barrier to entry, and it can be used almost immediately to shave minutes off repeatable user tasks, or even fully automate some activities. In the meantime, you're introducing process automation concepts to your users and gathering information on how they are getting things done, both of which will be invaluable when — or if — you decide to redevelop your applications on a BPM platform.
Neil Kinson currently holds the role of Redwood's Chief of Staff where he is tasked with leading a number of the company's global strategic initiatives, as well as the European business. Calling on more than 25 years' of experience building partnerships with clients to accomplish complex business and IT goals, it's a role he is fulfilling with great aplomb.
British Broadcasting Company (BBC) and Barclays in the United Kingdom.
And if all of that wasn't impressive enough, Kinson has also worked closely with The European Aeronautic Defence and Space Company N.V. (EADS), Alcatel Lucent, Telefónica and the Saudi Basic Industries Corporation (SABIC) on high-profile projects.
The RPA market is full of overblown vendor claims, and lots of hype about cognitive and artificial intelligence. Cut through that and ask to see and speak to references who have deployed this at industrial scale, or who can confirm that they got what the vendor promised, and as a result are pushing on from the initial pilot. In my experience that first "toe in the water" rarely results in the "Swim across the channel", and often not even a 25m length of the pool. Ask to look at the total cost of ownership, not the acquisition cost of the robot which can be as low as free. As in most aspects of life, there is no such thing as a free lunch.
The most common mistake is simply making the robot emulate tasks that a human would do, and investing time money and energy and refining that emulation with diminishing returns in productivity. The reality is with that approach you end up with a tipping point when the effort to manage the robots outweighs the benefit in productivity. You end up replacing low cost effort, with expensive robot supervisors that are never called out in the business case or by the vendors. What you really want is your people available to do the things that they are good at and that add value, rather than having them in place to catch the things the robot is bad at. You can only achieve that if you look at the process and the desired outcomes, not the individual tasks themselves.
Dr. Harald Kühn is a member of the management board of the BOC AG. He is responsible for the product management and the related strategic aspects of BOC's product portfolio. Dr. Harald Kühn works in the areas of metamodelling, BPM, EA and the usage of cloud technologies in these domains.
He is an author of over 20 publications about various aspects of BPM.
As with every other technology which should be introduced in an organisation, select 1-2 pilot processes to apply RPA technology. These pilot processes should be of reasonable size (not to small, not to large) and should allow to test the potential of RPA. As RPA is about automating tasks of human-machine interaction, the as-is process analysis should be mapped down to task level, not only subprocess level. The tasks should be categorised based on their IT coverage, i.e. at least be categorised into "pure human", "human-machine" or "automated". The "human-machine" tasks are then the candidates to be considered in the RPA pilot project. Besides gathering experiences using RPA technology itself, also HR-relasted aspects should be covered in the pilot project to prepare for process-related as well as people-related changes.
One of the most common errors we see in the context of RPA is to start with too complex pilot processes and based on this, to have problems to deliver tangible results within a reasonable time. Another problem we identified is not representing both business and IT within the RPA pilot project in a balanced way. RPA advocates that it is for business, but IT should be involved as well with a special focus on governance topics.
John Mancini is an author and speaker on technology and digital transformation trends and a respected leader in the content and information management community. He believes that in the next 5 years, a wave Digital Transformation will sweep through businesses and organizations, and organizations now face a fundamental choice between Information Opportunity and Information Chaos.
As a frequent keynote speaker, John offers his expertise on Digital Transformation and the struggle to overcome Information Chaos. He blogs under the title Digital Landfill, has almost 10,000 Twitter followers and a Klout score in the 60s. He has published seven e-book titles including "Information Chaos v. Information Opportunity: The Business Challenge for the Next Decade" (http://www.aiim.org/infochaos), "#OccupyIT — A Technology Manifesto for Cloud, Mobile and Social Era" and the popular "8 Things You Need to Know About" e-book series.
Looking back, this created two sets of problems. First, it created the implication that there was some sort of magic software solution you could buy, plug into the network, and voila, you had "ECM." Secondly, as a variety of very different kinds of solutions began to hang their hat on the "ECM" term, it came to mean very different things depending on the ear of the listener. For me, I always thought of "ECM" as a fairly broad term that not only included traditional transactionally-centric content management, but also web content management and collaborative software and content analytics and …. But not everyone shared this expansive definition.
So… "ROBOTIC Process Automation?" If what we're talking about is "the application of technology that allows employees in a company to configure computer software or a robot to capture and interpret existing applications for processing a transaction, manipulating data, triggering responses and communicating with other digital systems (http://irpaai.com/what-is-robotic-process-automation/) " I think "process automation" is perfectly sufficient. Adding a "robot" to the challenge of process automation conjures up images that make process automation more difficult to explain and sell to an end user organization.
The early days of process automation were all about getting core processes to scale. ECM and BPM solutions focused on creating new efficiencies by automating high-value, mission-critical, and document-intensive processes. The focus was on a small number of direct process-stakeholders and users. Solutions were expensive and custom and took a long time to implement. In a relatively stable business environment, the problems with traditional BPM/ECM solutions didn't matter because the eventual cost-reduction pay-offs were so significant.
But in an era of technology disruption, efficiency is a necessary but not sufficient condition for success. Success requires agility as well as efficiency. Being an agile enterprise means that process change must occur dynamically and in small increments. It means that accountability and responsibility for process innovation must be decentralized and driven as close to the customer as possible. It means that the tools and platforms upon which process innovation occurs must be accessible to the business and easily usable by the business with a minimum of IT intervention. It means we need to empower a new generation of "citizen developers" in the business. Being an agile enterprise means that the era of complex BPM customizations must end and transition to low-code and no-code platforms.
Asheesh is an outsourcing veteran with over 20 years of cross-industry experience. His wide range of expertise has been recognized by The Shared Services & Outsourcing Network (SSON) as they award him 'People's Choice for Personal Contribution to Industry – APAC' in 2011 and 'Thought Leader of the Year – Asia' in 2010 – making him the most suitable Chief Everything Officer.
He served as the vice president of Infosys BPO – Asia Pacific, Japan, and the Middle East. Under his tutelage, Infosys BPO grew its business through both organic and acquisitive routes and managed the region with two delivery centres in the Philippines and three in China. Asheesh has worked with large ITES organizations such as Mphasis, TCS, and WNS in various leadership roles. His wide range of expertise has been recognized by The Shared Services & Outsourcing Network (SSON) as they award him 'People's Choice for Personal Contribution to Industry – APAC' in 2011 and 'Thought Leader of the Year – Asia' in 2010.
Sebastien Meunier is an expert in Innovation in Finance, with 15 years of experience in managing business and technology transformations in Financial Services, and among the top 10 Fintech influencers on social media.
He is the Head of Digital for North America at the consulting firm Chappuis Halder & Co.
I would advise them to spend time upfront to really understand what is RPA compared to other automation techniques, organizing awareness sessions and workshops to identify relevant use-cases before jumping into experimentation.
Then I would recommend to go step by step: from one proof of concept to extension and full deployment; from "pure" rule-based RPA first, to smart automation with unstructured data and machine learning in a second phase.
And always keep a business perspective: the choice of the tool is secondary, technology is only an enabler to a business objective.
Derek Miers focuses on the methods, approaches, frameworks, techniques, and technologies around BPM and business transformation programmes—workflow, case management, robotic process automation, decision management; alongside the methods associated with business architecture, and target operating models.
b. Explore the mandate … and anchor it in the organization at a business level … treat it as an enterprise level capability that needs understanding and developing … it's an enabler of digital transformation (allowing people to bypass the long time required to put an automation layer over existing applications and legacy systems).
With nearly 20 years' experience in technology innovation, Gabby is the driving force behind Ayehu. His multidisciplinary background in product engineering, sales and professional services brings together key elements necessary to deliver the company's IT process automation solution that has proven to be a force multiplier for businesses facing operational IT and cyber security challenges. Since co-founding the company, Gabby has advanced his thought leadership in IT automation and been dedicated to setting the company on a path to strong growth and validation. The Ayehu platform continues to earn accolades from customers, partners and industry experts including Gartner, Red Herring and Deloitte. Prior to founding Ayehu, Gabby held various operational and management positions at successful Israeli technology enterprises including Infogate Online Ltd, Webmaster and Walla Communications Ltd.
* Integration with other software – The driving force behind a successful RPA solution is its ability to integrate with other platforms. Integration creates a more robust and highly functional platform that effectively carries out workflows.
* User-friendliness – If creating a new workflow involves a significant amount of time and effort, the value of the orchestration tool is naturally diminished. Likewise, if the tool cannot be rolled out broadly to the entire organization due to the need for extensive training and in-depth knowledge, the overall benefits will no longer outweigh the time, money and efforts invested in the process.
* Workflow creation with reusable components – For a workflow to be effective, it must be robust, flexible and scalable. The goal should be, over time, to be able to reuse certain parts of existing workflows to facilitate faster, easier and more efficient creation of new workflows.
* Enhanced reporting functionality – Internally, reports can be used to identify what users need to do their jobs more efficiently and to pinpoint areas where problems exist. Outside IT, reports are also essential as they demonstrate the overall value of the work being done.
* Lack of a mature strategy – Understanding the need for and benefits of automation aren't enough to successfully implement a tool like RPA. If you are considering adopting RPA, it's critical that a detailed strategy is developed well in advance of doing so.
* Lack of adequate governance- One of the greatest things about RPA is that it never deviates from its course, which is why RPA is credited with lowering and eliminating error rates. However, problems can arise when and if any part of a particular process is changed. If a process change is not properly communicated, documented and applied, the RPA will inevitably fail.
* Overly optimistic approach – While the newer RPA products are certainly being designed to be as user-friendly as possible, it's important to remember that there will still be a learning curve and that software is innately inhuman. That means that unless it is properly programmed, it will not necessarily work without issue right out of the gate.
* Not defining new roles – As tasks and workflows are transitioned to automation, the roles of employees will inevitably change as well. Remember, RPA isn't meant to replace human workers, but make their jobs easier. Still, many of the duties that were once handled by people will no longer exist as part of the day to day activities. As this shift occurs, be prepared to adapt and transition employees into new roles within the company.
Rated as the #1 Most Influential Thought Leader in Business Process Management (BPM) by independent research, Nathaniel Palmer is recognized as one of the early originators of BPM, and has led the design for some of the industry's largest-scale and most complex projects involving investments of $200 Million or more. Today he is the Editor-in-Chief of BPM.com, as well as the Executive Director of the Workflow Management Coalition, as well as VP and CTO of BPM, Inc. Previously he had been the BPM Practice Director of SRA International, and prior to that Director, Business Consulting for Perot Systems Corp, as well as spent over a decade with Delphi Group serving as VP and CTO.
He frequently tops the lists of the most recognized names in his field, and was the first individual named as Laureate in Workflow. Nathaniel has authored or co-authored a dozen books on process innovation and business transformation, including "Intelligent BPM" (2013), "How Knowledge Workers Get Things Done" (2012), "Social BPM" (2011), "Mastering the Unpredictable" (2008) which reached #2 on the Amazon.com Best Seller's List, "Excellence in Practice" (2007), "Encyclopedia of Database Systems" (2007) and "The X-Economy" (2001). He has been featured in numerous media ranging from Fortune to The New York Times to National Public Radio. Nathaniel holds a DISCO Secret Clearance as well as a Position of Trust with in the U.S. federal government.
Start with repetitive human tasks, where users are bogged down performing tedious work, repetitive steps, or otherwise without requiring any meaningful analysis. Also look for where users are shifting back and forth between different application interfaces as part of the task or process step. These scenarios are where the low hanging fruit will be found and offer the logical starting point for RPA. Yet plans shouldn't be left there, and indeed your strategy should lay the groundwork for horizontal scale, tying together discrete moments of automation within a more comprehensive, end-to-end process.
To support this, have clear model for the separation of concern between BPM and RPA. Understand that BPM was never designed to fully replace the work done by human beings, but rather to facilitate that work by assigning tasks, sequencing steps, enforcing rules, and other means of work management. In contrast, RPA in fact is purpose-built specifically to replace work otherwise less efficient and effective when performed by humans. Combined the two offer a potent combination, enabling the Holy Grail of "Intelligent Automation" with far more efficient and effect coordination of both knowledge work and automated tasks.
While the synergy RPA and BPM offers great potential, realizing this value does not happen by default. There is not today an established standard or methodology which prescribes the ideal interplay between BPM and RPA, and indeed some of the greatest pitfalls lay in the poorly defined separation of concern between the two. For example, one of the common mistakes is to create too complex of rules, and miss the opportunity for separately managing decision logic (business policies and rules) separate from the procedural rules necessary to the automated task. No RPA platform is designed for decision management, yet a well-architected approach can and should leverage best of breed capabilities.
Lastly, perhaps the most common mistake is aiming too low and underestimating the potential of RPA. This is every bit as powerful, with an equivalent potential for disruption, as adding physical robots into the enterprise workforce. "But it's just screen-scraping on steroids!" No. It is far more powerful than that. Don't waste any time with such nattering nabobs of negativism. RPA is something entirely new, and as part of a broader BPM strategy enables levels of efficiency and digitalization previously out of reach.
Gabriel Pana has been working for the past 5 years in IT and Operations with a high knowledge of processes, business analysis and improvement.
He joined UiPath in 2016 to work and grow the business in all areas with a main focus on channels, alliances and the manufacturing vertical.
We would suggest to look at all internal and outsourced processes and decide on some that can be automated into a pilot. By involving all departments you are to achieve a better ROI within the company and so you will be able to transform your full business. While the pilot focuses on showing the capabilities, the initial assessment of all Company groups and department will allow a fast scale up and growth.
One of the most common error in implementing RPA is not having IT on board. Although we all pride that RPA is a business solution, IT should always be involved from the start – to help with the development, implementation, infrastructure and architecture. This will allow, eventually, a higher ROI and a fast deployment – with less bottlenecks.
Bart Peluso III is the Global Head of Product Marketing for Blue Prism, the company that invented Robotic Process Automation (RPA). He manages product marketing strategy, competitive intelligence, technical alliance marketing and the customer advisory group. Prior to Blue Prism, Bart led Product Marketing for disruptive new technologies at Cisco, CA, Dell and the revolutionary start-up Mesh Networks. Bart enjoys boating, hiking and music with his family in Austin, Texas.
There are several critical considerations for organizations deploying RPA. First, they have to define their automation strategy, begin building a robust operating model and ensure cultural adoption from the business and employees. RPA should be easily applied to automate repetitive processes of administrative work without interfering with work ethic or moral. A good RPA deployment enables employees to make higher value contributions to the business by automating the repetitive tasks. Human and robot need to work together in harmony.
Next, organizations should ensure that their RPA solution is built, managed and owned by an accredited operational team or Center of Excellence spanning operations and technology. This ensures not only the highest quality, but also compliance by having the robotic process adhere to all IT policies and regulatory governance.
Overall, the RPA platform must have the functionality to meet the strictest standards of security, control, data integrity, change management and scalability. The new Digital Workforce provided by RPA should dramatically improve a BPM organization's operational governance, integrity and work moral without introducing operational risks.
Some people confuse Robotic Desktop Automation (RDA) with RPA – this is a common mistake. They deploy an RDA solution across disparate desktops throughout a business unit without consulting IT which has several negative implications. First, since it is not centrally managed, there is susceptibility to fraud as one individual controls the robot and whatever process it runs, such as financial account management. Second, RDA will not comply with mandatory governance such as Sarbanes Oxley, HIPPA or whatever governing body regulates the business. Finally, because RDA solutions do not involve "reusable objects" (the individual commands of a robotic process), the robot will cease if one item – say a web UI – changes. There are some use cases with small business and outsourcers that are ideal for RDA. But BPM organizations need to be wary of vendors claiming RPA when they really offer a desktop solution.
Another mistake we see is the other extreme, that is when IT tries to build the Robotic Processes from the ground up with a vendor. While this also is good for very select use cases, such as an isolated process in a homogenous environment, it's too confined, time-consuming and expensive for most Enterprises and BPM organizations.
We encourage organizations to go with an RPA solution that is controlled by the business, but governed by IT.
Thierry is specialized in setting up, incubating and growing successful projects for customer service organizations by creating an ecosystem of People, Processes and Technology.
His tour of duty includes working for some of the largest system integrators, 2 of the Big 5 Customer Service Providers, and setting up customer service operations for large accounts in Banking, Telecom, and Automotive sectors.
Second: RPA is only making processes faster and with no data error, but it does not make them efficient. So every Automation project should have an initial phase of Lean process analysis.
The major error is to not do a real benchmark on solutions, via a POC or a Pilot.
And second, not implying business and compliance into the selection and the design.
An IIT graduate from Chennai, and the youngest professor to be invited to IMT Ghaziabad, Ravi Ramamurthy's achievements are varied. He is a member of the executive committee of Science Olympiad Foundation, the largest Olympiad in the world. He is the CEO and Founder of a software product company called Epiance, which has clients all over the world, clients who vouch for the product line which he created. He has 30 years of experience in the corporate arena. R. Ravi has been a pioneer of knowledge management and business process modeling. He was one of the founders and early evangelizers of Electronic Performance Support. The innovative process capture technology that he conceptualized and developed was instrumental in creating the rapidly growing performance support industry that is the foundation of today's business process mapping, knowledge management, real-time e-Learning and performance improvement enterprises.
R Ravi was one the of the early creators of the foundations for automation. In fact the first automation product that he created in 2003 was well ahead of its time. Many of the these ideas form the basis for the Robotic Automation product that is becoming very popular today. R. Ravi is responsible for a host of software, technology and product innovations including the development of modeling and charting software and the creation of original multithreading concepts found in today's relational databases. He has multiple patents (patent pending) to his name. Ravi's success as an entrepreneur and a business leader lies in his ability to transform these innovations into pioneering and successful products that are globally sought after and used by the world's best performing companies.
1. Understand the internal dynamics. Are the key stakeholders supportive? Is the operational leadership willing to embrace this technology? Much of the operational leadership is still steeped in the mindset of more people, more power. One does not want to be the harbinger of massive downsizing in one's team. The resistance to change can therefore be intense. This is a key component that needs to be considered.
2. Instead of delving directly into automation and getting carried away by the hype of RPA- go deeper. The key aspect that organization really want to focus on is improvement in performance or improving productivity. Automation is just one piece of the puzzle. There are many other complementary technologies which along with automation can yield dramatic benefits. Therefore keep a cool head, don't get carried away by RPA, and look at what needs to be done to improve performance of people- Is it a competency issue, can performance support help, can superior and advanced training methodologies help, can process tweaking yield benefits. How can onecCombine this with automation and arrive at a holistic approach. If you are a part of the executive leadership shield your team from excessive pressure to deliver results quickly. Excessive speed makes a system commit more errors.
3. Theoretical understanding or feedback from analysts can only go so far. There is nothing to substitute for actual field experience to understand the impact and dos and don'ts of automation. I would definitely recommend organizations to do 2-3 live implementations of Performance improvement in diverse processes. Based on the actual experience strategize the organizational approach. Answer questions such as what kind of processes should I automate? High visibility can increase speed , but can also create unnecessary resistance to future projects if some hitches develop. Take all softer aspects, humane aspects, technology aspects, political dynamics, customer expectations before crafting a strategy for improvement.
1. Diving immediately into RPA without any experience. Aiming for complete automation at the first go. Being disappointed with small productivity gains. Incremental approach is the best when it comes to any new technology.
2. IN a large organization , increasing visibility to the project. This sometime backfires because the project is over managed and small mistakes are amplified. Implementation managers spend most of their time with unnecessary escalations. Sometimes it might be advisable to underplay the project and gradually increase visibility to various stakeholders. The approach will vary based on an individual organizational dynamics.
3. Losing track of the objective of performance improvement and focusing narrowly on just automation.
4. Ignoring technology aspects or political aspects of implementation.
5. Failure to build internal champions. Relying too much on analyst and theoretical knowledge.
6. Being driven by multiple stakeholders. It is always advisable for a single individual to drive the pace and strategy of automation.
7. Not following one's instincts but being carried away by external pressures. Managing external pressures is critical. It cannot affect the core aspects of RPA implementation strategy.
8. Not shielding the team from external pressures. Giving them enough space to implement.
9. Picking up the moist challenging , toughest and most aggressive processes. Ignoring the low hanging fruits.
10. Ignoring alternatives to RPA. Sometimes implementing a new technology may be a superior solution. One has to remember that RPA is a patchwork solution and is not necessarily the most elegant one. The appeal of RPA is because of rapidity, low dependence on IT and quick response to change. However there have been cases where a grounds up development could be superior to RPA.
Adrian Reed is a true advocate of the analysis profession. In his day job, he acts as Principal Consultant and Director at Blackmetric Business Solutions where he provides business analysis consultancy and training solutions to a range of clients in varying industries. Adrian is Immediate Past President of the UK chapter of the IIBA and he speaks internationally on topics relating to business analysis and business change. You can read Adrian's blog at http://www.adrianreed.co.uk and follow him on Twitter at http://twitter.com/UKAdrianReed.
As a BA, I'd (rather predictably) say start with why. It's important to know what you're looking to achieve, and also to establish that RPA is the solution that is best suited to deliver that. It might be that an organisation is looking to reduce cost, reduce backlogs, increase speed–but knowing this in advance will help shape and frame the initiative.
I'd also say that it's crucial to understand and 'clean up' the processes first. I am a great advocate in the mantra of 'simplification before automation'. If we automate a bad process, we can end up with more waste and failure demand! So understanding the work, and the end-to-end process (and how it impacts the customer and other stakeholders) is crucial.
I think it's important to start small–with repetitive and predictable tasks, rather than starting with the biggest, messiest process.
Being provocative, I think there's (sometimes) an underlying business or technology issue that RPA isn't directly addressing. If you are using RPA to (for example) to transpose data from one system to another, it's important to ask the question should we be managing our master data better? Or should we have a 'single source of the truth'. This is just one specific example, of course–and I am certainly not arguing against RPA when used in the appropriate contexts!
Finally, I think buy-in is important. We need to accept that (as with any change) the concept of automating work may be disruptive and even scary to some. Appreciating that this is not just a technology and process change, but also a people and human change is crucial. We must engage, and engage with empathy.
Intelligent Automation in general and RPA are in the eye of the beholder as the market lacks a common understanding or even robust definitions. This stems both from the nascent phase of market development as well as from the reluctance of the large service providers to educate the market. While nothing is defined in the context of automation, the common denominator in all the approaches is decoupling routine service delivery from labor arbitrage.
Against this background, buyers need to be clear that RPA is about service delivery, but not about individual tools or technologies. Therefore, buyers should invest significant time in evaluating the appropriate processes for RPA. The most important question is, what form of enterprise transformation you are trying to enable and achieve? Everything else will follow from there. Thus, buyers should avoid short-term focused, tool centric approach. Don't think "your mess for automated less". Think about service orchestration. Governance, security and testing should be central considerations not afterthoughts.
Last but not least think about the implications on talent. The talent understanding not only those innovative technologies but their impact on process chains and workflows is scarce. Consider leveraging the insights of pure play consultancies such Symphony Ventures, GenFour, VirtualOperations, Mindfields or RPA Implementation. They are the key educators in the market. Much information is on their websites, but we can also do introductions. But also consider the impact on your own workforce. Change management is the crucial conduit for successful deployments.
Most mistakes and consequently failed projects result from ignoring the points we have raised above. Many look for the next short cut or silver bullet to achieve cost savings. Yet, most of these savings are on sub-process levels and deployments are not scalable. Thus, for many RPA is like drug to satisfy those desires for guaranteed cost take out.
As automation and RPA should be about service delivery, buyers need to think about end-to-end processes and transformation. Notions of data curation should be a starting but not a by-product. What we are seeing is that buyers, often confused by the marketing of a market that is not defined, are jumping onto projects without co-ordination or change management. Within larger organizations we are seeing multiple RPA projects often without the knowledge of the process owner. Similarly, IT is often not part of the decision-making process, yet critical to success of the deployments.
And lastly, buyers are confused what RPA really is as the use of the moniker across the industry is inflationary. The difference of RPA vs. RDA, the implications on front and back-office, the need to integrate broader automation capabilities all too often gets lost not least as the large service providers are shying away from educating market.
Pedro Robledo is Editor-in-Chief, Publisher and BPM Marketing Advisor and trusted Networker at BPMteca.com, who publishes unique books on business process management and the e-magazine "World BPM Magazine"; it provides services of translation of BPM documents from English to Spanish, and it provides marketing services oriented to lead generation for BPM providers and trusted Networking for all people who is interested on BPM.
Pedro has more than 24 years of professional experience in Enterprise Software Market with a complete background and skills in sales, marketing and business development, focused on the company strategy, lead generation and oriented to objectives with the commitment and consecution to results. He is one of the most influential Spanish thought leader in BPM, as for 10 years has been dedicated to promote industry awareness of Business Process Management in Spain and Latin America – also as a Professor.
Since 2013 he is Judge of WfMC Awards for Excellence in BPM and Workflow.
Firstly, it is important to differentiate between RPA (Robotic Process Automation) and BPM (Business Process Management), because both disciplines look for the automation of processes, but they are complementary. RPA technology plays and will play an important role in BPM, from the automation of repetitive human tasks that can be replaced by a robot (either software, hardware or both). RPA is based on notions of software robots that replicate the actions of a human interacting with a user interface with a computer, which can benefit BPM when optimizing a transversal process of the organization, taking the orchestration of all Robots involved in a process.
The analyst Grand View Research, Inc. says that the global RPA market is expected to reach USD 8.75 billion by 2024 and RPA is emerging as a disrupting technology with capabilities of providing benefits such as enhanced accuracy, compliance, cost saving and scalability, so the companies who wants to start using RPA can be sure that organizations are increasingly implementing these solutions. And another important driver is that it is estimated that RPA is expected to cost as one-third of the least expensive offshore labor.
When any company model a process using Business Process Analysis can identify processes or sub-processes with high daily volumes of repetitive tasks and low added value that are performed by employees, as these tasks should be replaced by the execution of RPA technology, to get security and responsiveness, to reduce errors, and to save time and money. And now the use of Artificial Intelligence (machine learning) in RPA allows you to adapt to different circumstances and make decisions on the automated process allowing more adaptability.
Many of the problems in implementing BPM are common in implementing RPA, but RPA has many problems when the implementation does not follow a continuous improvement cycle, as it is required to control the impacts of any change in a process, and even any change in the strategy of the company that it requires a modification of processes, systems, applications… that it could be controlled by Enterprise Architecture tools.
In the implementation of RPA, there are important dependencies between systems, data and applications, so we should be sure that any change in one system, on data table or the release of any application can create a problem in the automated process.
The phase of creation is very critical, and it requires to make enough tests with all possible scenarios to check that the automated process works fine, because if the process itself is flawed the RPA does is formalize the flaws. Please, run a pilot project first and clearly demonstrate the right execution and right performance (it is important to control metrics before the automation and after).
Another common error is about documentation (similar problem than application programming), if the RPA is not well documented with all process definition and mapping in detail it will be difficult to make changes and to ask how it works. So all have to be rigidly documented and recorded (requirements, process definition, change requests, metrics, bugs, releases, exceptions…).
Michal Rosik is responsible for building and scaling process mining tool Minit.io.
He also develops relations with the process mining academic community and evangelizes process mining benefits to enterprises worldwide.
* Identify core processes, which are at the heart of their business strategy.
I would also suggest not to leave out post implementation evaluation.
* Measure the results by comparing the robotized process to the original one.
* Monitor the performance of robots and the impact of robotic automation on the IT infrastructure and environment.
Addressing these points early and based on data is a key to successful RPA. Minit as an analytical tool working on the principles of process mining offers technological support for making the right and data-based decisions.
A) Is it possible to quantify the benefits of RPA optimized process to the original?
* on the IT infrastructure and information systems as such as the speed of robotic work might cause higher workload and performance peaks.
When deployed, robots of most vendors are precisely logging all the activities performed, thus offering a data source for post-implementation evaluation of process performance. Minit can use that information to carry out a regular process analysis and based on it, compare the processes among themselves. This approach helps to quantify the added value of RPA and identify further potential problems, leading the enterprise on the path to continuous improvement.
* Starting with a plain canvas – using the classical methods process analysis based on interviewing of process owners or people involved in process execution and manual modeling of those processes. This approach is time and resource consuming and often related to potential issues of subjectivity, limitation of view and exception related problems.
* Design by doing – approach based on work recording technologies, where IS interaction is tracked for selected individuals and processes are modeled based on their actions. The disadvantage of this method might occur in cases where information systems and lack of regulations or rules let employees perform tasks in various order. In such as cases, identifying the right individual is mostly based on feeling or approximation. Typically resulting in the same issues as mentioned before – subjectivity, limitation of view and exception related problems.
Process mining is modeling and analyzing processes based strictly on event-based data (process traces), logged by information systems/devices/modules. The process discovery is automated and eliminates the subjectivity and view limitations at the same time it includes all the exceptions no matter how often they occur. Minit then allows the analyst to simplify the process, keeping the process backbone intact, lets him/her view all the statistics and metrics and even see the dynamics of the process by animating it above the discovered process map. There are multiple possibilities to filter the process data based on various criteria – timeframe, metrics, variants, attributes of process instances and cut the process model by different dimensions, hence drilling down into those parts of the process that are of the interest to the customer.
The RPA related decisions are thus data centric and objective, the canvas is filled with the reality based process model, and bottlenecks and inefficiency points are easily spotted. Using the interaction recording allows the analyst to monitor work of all individuals performing the analyzed tasks and combining them to a single process map automatically. The analyst can then drill down into single process variants, explore different behavioral patterns and quickly pick the right person to base the RPA project on.
Mathias is the technical Founder of a9t9 and Kantu. Fascinated with robots and artificial intelligence from early on, the idea and goal behind Kantu's robotic process automation technology is that the next generation of automation solutions should be smarter, faster and work just like a human being. He is also the original author of iMacros, a popular web automation software with hundreds of thousands of users.
out methods to make his remote controlled Quadcopter fly by itself.
Alexander Samarin is an architect for achieving the synergy between strategy, good business practices and disruptive digital technologies in various digital systems: e-government, healthcare, smart homes, smart cities and IoT.
– Externalisation of events from existing applications and then those events may be used to initiate some processes.
– Implementation of automation scripts as robots. Because those robots are, actually, programmable containerised microservices then application architecture enables agility and reliability. Instead of "programmable monolith" archicture (typical BPM-suite tool) which is very difficult to maintain, enterprises get modern microservice architecture.
– GUI-to-API conversion to simplify the integration with existing applications (e.g. http://www.flynetviewer.com/product/flynet-viewer-studio-web-services).
Synergy between RPA and BPM will be achieved by the following techniques.
1) Externalise various events to employ OODA and CESAR patterns (see http://improving-bpm-systems.blogspot.ch/2016/12/enterprise-patterns-cesar-entarch.html).
2) Build your processes as a mixture of human activities and automated scripts which helps each other: scripts can automatize some routine work for humans and humans can recover scripts from failures (see http://improving-bpm-systems.blogspot.ch/2014/08/bpm-for-digital-age-shifting.html).
3) Control your application architecture by explicit usage of events, microservices and API (see http://improving-bpm-systems.blogspot.ch/search/label/%23apparch).
And, beware of automation pitfalls (see http://improving-bpm-systems.blogspot.ch/2011/01/automation-and-intelligent-systems.html).
Over the last 14 years, Mohit has acquired strong experience in managing and leading process improvement, strategic change management, transformation (shared services, onshore and offshore) and risk management projects within large diversified Australian and global financial services companies.
He has been providing consulting and strategies frameworks on M&A deals (pre and post), deal structures (including carve out), transformation and outsourcing (ITO/BPO/KPO-both onshore and offshore) to diverse industries ranging from Financial services to mining.
Mohit also specializes in providing Business Process Re-engineering/Optimisation/Efficiency services to the clients.
We have been part of the biggest deployment of Robotic workforce in the world. We advice and educate through workshop with Senior and operational management on What, Why and How of RPA. For starters It is very important to understand standard definition of RPA from end user perspective. Currently, they are advise by consultants or RPA software providers. Most of them they modify the definition of RPA to match to their service offerings. If new starters understand the standard definition of RPA then Why (business case) and How (which RPA tool to use) becomes clearer and easier. They can view our Independent and comprehensive report (http://www.mindfields.net.au/rpa/premium-report). They need to create and develop internal capabilities for RPA in medium and long term. We are training clients to do automation by themselves. First phase should cover maximum 10 process with not expensive tool with no frill consulting firm. Automate them with trial versions…experience the difference before selection. Train your own resources and do not have high expectations in first phase.
RPA should be led by enterprise wide strategy. Business and IT both should be key stakeholders for RPA initiatives. Clients need to identify and segment their drivers for automation into 3 buckets i.e. FTE reduction, Increase in Efficiency and Reduction in error. We as consulting firm focus on "gain areas" whereas clients want to automate "pain areas". New starters need to be lean and learn from mistakes from other organisations who have already in mature stage of their RPA journey. They should not have high expectations in the initial phase . Automation should be treated as first step of the journey not a destination.
Mihir is a visionary in the automation space, having helped define a new, 3 billion dollar market category for business process automation (BPA). With the aim of constantly producing and innovating on automation software that is easy to use, and utilizes enterprise social collaboration and mobility platforms, Mihir leads the charge in driving billions of dollars in savings to millions of businesses, transforming the way they operate. An engineer at heart, Mihir focuses Automation Anywhere as a whole on creating groundbreaking technology that changes the way businesses think about automation. His previous experience includes leadership roles in internet, e-commerce, and wireless market leaders at the forefront of innovation like E2Open, Kiva, ISN, Netscape, Infoseek, and Omnisky.
Get started now. There is nothing holding you back. We have more bots deployed than anyone else in the world because we've made creating and deploying bots easy. We provide both speed and scale. These are some of the reasons companies both large and small are deploying anywhere from 50 bots to thousands of bots. This is not a trend. It is a dramatic shift in the way people and machines will work together. After you've begun, scale quickly. Once you have automated a few processes which can be automated, you will find hundreds more which must be automated. Then, admire the business transformation you've started.
People will sometimes imagine that RPA is not only difficult to adopt but that it will somehow be rejected by employees. In truth, employees embrace the promise of RPA taking the mundane things off their plates, liberating them to do the things human beings prefer to do. No one, at any job level, wants to do a repetitive task again and again. RPA solves this. It automates routine, repetitive tasks instantly. It frees human workers to use their brains, their talent and their imaginations. What bigger mistake could there be than suppressing the real potential of human workers?
Jim Sinur joined Aragon Research in 2016 as a Vice President and Research Fellow. As a distinguished Thought Leader, he covers Digital Transformation, the Digital Business Platform (DBP), the Internet of Things (IoT), Cognitive Delivery, and the Intelligent Workplace.
Prior to joining Aragon, Mr. Sinur spent 20 years at Gartner, where he was critical in creating the first Hype Cycle and Maturity Model, which have become a hallmark of Gartner analysis, along with the Magic Quadrant. Prior to Gartner, Mr. Sinur was a Director of World Wide Technologies at American Express.
Jim is also one of the authors of BPM: The Next Wave. His latest book is Digital Transformation. Innovate or Die Slowly.
Organizations that are racing to digital often have to leverage existing applications, application components and process snippets. Robotic Process Automation (RPA) in the most common definition of linking together old functionality, hopefully in an API like fashion, is crucial for leveraging key business and technical function in new and helpful ways. BPM can easily leverage RPA generated components and sequence of components in new digital contexts in both flow directed and goal directed processes and cases. I've included some blogs that may help explain some of the reasons for RPA in digital efforts.
Marios is a software engineer and technology entrepreneur, motivated by creating innovative products that solve real business needs. He has been devoted to high tech for more than 20 years now, with his latest initiative being enterprise robotic process automation. Having a vast experience in software robotics, Marios and his team today is researching the field of cognitive automation and AI.
If I were to give just one piece of advice for companies that are now starting to look for an RPA solution, I would point out that this is a new, technology, not mature yet, there is a lot of buzz around it, and a lot of fluff is being said, but there is one thing that can be done to separate the hype from the myth and that is a proof of concept. So, no matter what you hear, I would advise that you took this first step of doing a POC in order to make sure that you choose the right solution for your needs, that this will actually do work with your systems, and that there will not be any unpleasant surprises along the way.
1. Do not forget to involve your IT team in the early stages of the Robotic Process Automation discussions.
2. It is worth it to find time to optimize your processes upfront, before automating them.
3. Make sure you test the technical capabilities of the software vendor you are partnering with, by doing a Proof of Concept.
Christopher Surdak is an industry-recognized expert in Collaboration and Content Management, Big Data, Information Security, Regulatory Compliance, and Cloud Computing with over 20 years of professional experience.
Currently, he is the Founder and President of Surdak & Co., a business consulting firm empowering their clients to be disruptive leaders of industry.
He is also a Co-Founder of Quantiqs, a private start-up in Southern California as well as Ouray Mills Publishing, a new digital book publishing venture.
Mr. Surdak has held similar roles with other leading companies such as Accenture, Siemens, Dell and Citibank. Mr. Surdak began his career with Lockheed Martin Astrospace, where he was a spacecraft systems engineer and rocket scientist.
Mr. Surdak holds a Juris Doctor from Taft University, an Executive Masters In Technology Management and a Moore Fellowship from the University of Pennsylvania, a Master's Certificate in Information Security from Villanova University and a BS in Mechanical Engineering from Pennsylvania State University.
Mr. Surdak is author of 2016's "Jerk: Twelve Steps to Rule the World", and "Data Crush: How the Information Tidal Wave is Driving New Business Opportunities", recipient of GetAbstract's International Book of the Year Award, 2014.
Mr. Surdak recipient of the Wharton Alumni Association's Benjamin Franklin Innovator's Award for 2015.
He is also contributing editor and columnist for European Business Review, China Business Review and HP Matter magazines and Dataconomy.com.
Mr. Surdak provides talks, guidance and advice to global leaders on a range of technology, policy and business topics.
First, steel yourself to the fact that this is the hottest market in technology in the last 25 years. If you reach out to a vendor for guidance, you won't get much more than a bill for their software. If you reach out to a consultancy for guidance, you better have a million dollar budget or they'll likely ignore you. There is very little expertise out there, and finding people with actual, hand-on experience is exceedingly difficult.
Second, pick a tool, pilot it, and prove to yourself that it works. Once that's done, steel yourself again for a complex process of scaling up or scaling out. If your company is more than 20 years old your manual processes have evaded automation for decades. They are still manual due to cost, complexity or compliance, and these factors will rear their heads again when you try to grow past an RPA pilot.
Third, look past simple dollars-and-cents ROIs when you work to justify expanding the use of RPA. There will be direct cost benefits, but the greater benefits come in terms of better quality, faster processing and the ability to repurpose people to more value-added tasks.
Everyone seems to succeed at pilots. Nearly everyone seems to get stuck at growing past their pilots. These technologies work and they work well, so the technical risks are small.
Where most organizations seem to fail is they do not anticipate the potential opposition, concerns or hidden costs associated with the widespread deployment of RPA. If you're going to replace ninety percent of the people performing a given task, what will those people do post-deployment? Are you removing them or repurposing them? If you keep ten percent of these people, which ten percent should you keep? What skills will be valuable post-RPA? For people who are repurposed, what will it cost to retrain them and who will do that training? These issues can stop an RPA initiative dead in its tracks if they are not addressed early in the process.
Also, many companies find that when they remove a process bottleneck with robots the bottleneck may not disappear, it instead shifts to another part of the process. Without a solid systems engineering approach to using RPA companies may find themselves playing a game of bottleneck whack-a-mole, which further complicates calculations of ROI and can lead to disillusionment with this disruptive technology.
Harel Tayeb is an Entrepreneur, CEO, and Investor. He has extensive knowledge and hands-on experience in the fields of strategic planning, corporate development and successful group leadership.
Harel is passionate about taking dreams and make them true, build growing companies through identifying, investing in and creating new business and product lines.
Making the leap to digital transformation and the implementation of robotic process automation is a decisive point for any company. The adoption and implementation of disruptive technology, can be disruptive. While the primary purpose of Robotic Process Automation (RPA) technology is to empower businesses to reach optimal levels of operational efficiency and productivity, striving for this type of excellence is often easier said than done. Creating an RPA Center of Excellence (CoE) can significantly enhance the ability of an organization to meet its automation goals, draw out the full value the solution has to offer, and maximize on ROI.
As with the deployment of any new technology in the enterprise, buyers often start by focusing on the solution selection. However, An RPA deployment's ultimate success, especially if it is enterprise-wide or global, requires the full cooperation and support of top level staff and management. Because changes that accompany implementation of a new technology can be stressful for employees as they might experience shifts in their responsibilities, eyes will turn to leadership for strength, support, and direction. perhaps the hardest aspect of RPA is choosing which process to start with. Secondly, every RPA journey begins with a compelling strategy and strong roadmap regarding the technical aspects and expected business outcomes, but a formal case for change is just as invaluable. Finally, building an RPA Center of Excellence provides a better way of gathering, assessing, and managing the necessary knowledge and capabilities of the RPA solution, as well as ensuring that the scope, direction, and outcomes are in line with the company's needs and expectations on both an organizational and employee level.
* What are your processes? Do you have a clear idea and understanding of at least the top three levels of your process hierarchy? No process operates in isolation; we must understand the ecosystem.
* Are you measuring process performance? If you are not measuring, you aren't managing, and you can't know if there has been an improvement.
* Which process problem are you trying to fix? The problem needs to be objectively and quantitatively defined, and it must be a business problem worth solving. No organization has a problem called "we don't have enough RPA".
* How will you know when the problem is fixed? Need clear understanding of the expected impact of any process improvement initiative.
These questions look like quite basic, surely any organization would address them thoroughly? In many examples of business process improvement (automation, transformation, innovation etc.) the emphasis is too often on the process and not enough on the business, and these fundamental questions about "what problem are we trying to solve and why?" are overlooked.
The same errors common to many initiatives aimed at process improvement, i.e. failure to have solid, agreed, documented answers to the questions posed above. The gravitational pull of exciting new technology can be very strong.
Terry Walby is Founder and Chief Executive of Thoughtonomy, an automation technology company whose global software as a service (SaaS) platform combines the principles of Robotic Automation (RPA), Artificial Intelligence (AI) and Cloud Computing to provide a highly secure and infinitely scalable Virtual Workforce. Virtual Workers are capable of emulating the structured activities undertaken by people using business systems, the decisions they make and the processes they follow, to automate a variety of operational and support activities.
Terry has spent a career in leadership of technology and IT services businesses including senior roles with IBM and GE Capital, as a Director at European outsourcer Computacenter, where he built their consulting and technology businesses, and as Managing Director of automation specialist IPsoft, successfully building a new business in the UK.
Terry has a depth of experience in developing and scaling businesses, and in delivering innovation and optimisation both into end user organisations in the public and private sectors, and to the service provider and outsourcer community who serve them. These experiences, and a passionate belief in the power of technology to improve the world of work, led to the creation of Thoughtonomy to deliver an innovative and disruptive automation solution to a growing global market.
Firstly – get going. This technology is mature, proven and referenceable. You don't need to prove the concept. Define some need, run a controlled pilot on some real use cases which have business value and show a rapid ROI and will ensure widespread report for an ongoing automation initiative, and then continue your journey into scale production deployment. RPA is best viewed iteratively, as a program of automation which begins with the easier and high value processes, and then moves across the business as new use cases are identified.
Secondly – don't "silo" your RPA deployment by use case, process or department. Think of your robots as a Virtual Workforce – they should be able to run any process in any department or geography at any time. That way you will ensure maximum productivity and optimal business value – and avoid replicating the inefficiencies of human workforces with their robotic equivalents.
Finally – RPA is part of the solution, and great at addressing highly structured repetitive use cases. But not all work fits that description. Invest in technology that can also, if required, include human intervention during an automated process – to manage Front as well as Back Office processes; and that will offer value into the future, incorporating emerging technology such as machine learning, AI, and cognitive elements to address a broader scope of work.
One of the benefits of RPA is the ability to very quickly take a current process and deliver an automate it – without change, integration or disruption to the current systems and platforms in use. One of the errors we see in deployment is when organisations fall into the trap of process redesign alongside process automation. This can undermine the benefit of RPA, but also tends to complicate and extend delivery timelines. The best deployments automate "as-is" processes, don't expect 100% automation but handle exceptions through a controlled mechanism which can also be used to identify areas for later improvement.
Another common error is not to consider architecture. It's easy to deploy some RPA products by installing on local desktop or laptop devices – but that is not suitable for an Enterprise class , robust or secure deployment. It's much better to tackle the topics of architecture, resilience and security early and configure the software as an enterprise class application from the start – even for a pilot. That way it can scale without needing redesign. Of course best of all is to consume as-a-service, using SaaS capability to consume a scalable but resilient and secure RPA Virtual Workforce from the first robot to the thousandth and beyond.
Neil Ward-Dutton is MWD Advisors' co-founder and Research Director, and is one of Europe's most experienced and high-profile strategic business-technology advisors and industry analysts. His areas of expertise include digital transformation, business process management (BPM), enterprise architecture (EA) and IT strategy.
Neil acts as an advisor to large European organizations across industries and sectors as diverse as financial services, retail, utilities and government – as well as providing advice to a number of leading technology vendors.
WWW: Free report: Robotic Automation: What is it and why should I care?
There's a lot of confusion about how BPM and RPA 'fit'. Part of this is because RPA vendors have spent a long time selling to business process outsourcing (BPO) providers, and in that context, RPA can be more of a 'complete solution' than it often is in an enterprise context. For enterprises, in the context of a business process digitisation initiative the main opportunity, of course, is in using RPA to drive sophisticated integration with legacy systems – encapsulating those systems' UIs and creating clean integration interfaces. Some of the confusion is see comes from the fact that there will in many cases be a degree of orchestration and coordination that a robot will need to enact in order to complete its work, especially where multiple systems need to be interrogated or updated. Maybe this means RPA can do more; or maybe that BPM should be doing more? But the key is that from a business process perspective, any particular 'robot work' you define is going to be contained within the scope of one atomic process activity.
This is part of a wider truth that enterprises need to seek when looking at how new automation techniques and technologies play alongside established ones: the unit of analysis needs to be the task or activity, not the business process or indeed the job role.
Professor Willcocks has a worldwide reputation for his research and advisory work on IT and business process outsourcing, together with his work on organisational change, management, and global strategy. As well as being a professor in the Information Systems and Innovation Faculty Group, he is a Fellow of the British Computer Society.
For the last 21 years he has been Editor-in-Chief of the Journal of Information Technology. He is co-author of 33 books, including most recently The Outsourcing Enterprise: From Cost Management To Collaborative Innovation (Palgrave 2011), China's Emerging Outsourcing Capabilities (Palgrave, 2010), and The Practice of Outsourcing: From Information Systems to BPO and Offshoring, (Palgrave, 2009) He has published over 190 papers in journals such as Harvard Business Review, Sloan Management Review, California Management Review, MIS Quarterly, MISQ Executive and Journal of Management Studies.
In February 2001 he won the PriceWaterhouseCoopers/Michael Corbett Associates World Outsourcing Achievement Award for his contribution to this field. He is a regular keynote speaker at international practitioner and academic conferences, such as World Outsourcing Summit, European Outsourcing Summit, ICIS and PACIS and is regularly retained as adviser by major corporations and government institutions. Selected clients for executive education programmes include: Standard Chartered Bank, Logica, Stater, ABNAmro Bank, Royal Sun Alliance, Singtel, Commonwealth Bank, Accenture, IBM, Rotterdam Port Harbour Authority, WH Smith, Eli Lilley, and several government institutions in the UK, USA and Australia. He has served as expert witness on congressional committees and senate inquiries on outsourcing in Australia and USA and provided evidence to a number of UK government reports on major public sector IT projects.
Our research, published in Service Automation Robots and The Future of Work suggests 25 action principles for companies starting their RPA journeys. The key to not missing value is to have a strategic agenda for a triple win for shareholders, customers and employees from the start. THink long term service automation strategy and how it supports business competitiveness over the next five years. Then pick the right processes and tools – not all RPA tools are the same. Launch in areas where the company is feeling pain, and where impact can be high. Carefully plan and staff launch, including involving IT early, messaging open communication and full details about how work and jobs are going to be effected, and the future scenario. Change management is a key capability. Do not get buried in the technical issues. Always be looking to build a mature automation capability that leads from scaling RPA to adopting cognitive automation but ensure the business imperatives for automation are always at the forefront.
In Robotic Process Automation and Risk Mitigation: The Definitive Guide (April 2017) we point to 40 risks that materialise during the RPA and cognitive automation journeys we have studied so far. Not being strategic enough, poor tool selection, the wrong sourcing model (in-house, pure play, general BPO supplier etc) for what you want to achieve, not getting stakeholder buy-in, neglect of change management issues, poor project management and staffing on launch, various emerging operational risks that are not dealt with, e.g impact of scaling on IT requirements, and sequencing actions in a way that delivers quick fix solutions to immediate problems but that does not build a mature automation capability for the enterprise over three years.
Get the RPA guide as a convenient, downloadable PDF.
I would like to thank you for this fantastic read!
Very good article and provide good reference to implementation and management of RPA. I was curious is there a reason you did not include insights from Automation Anywhere given they are a global leader in development of RPA software ?