19th Century French Philosophy, SkyNet, and the 4 realities of RPA

Organizations on the digital transformation journey should take the counterintuitive approach of embracing both change and the status quo.

Any cocktail party conversation about AI in Silicon Valley inevitably comes around to the topic of SkyNet and the subsequent post apocalyptic, dystopian future that will inevitably befall us as AI becomes more powerful. While the Terminator series does paint a bleak future for humanity, the focus on SkyNet distracts from another central theme, that AI (cleverly disguised as Arnold Schwarzenegger) working with mankind is the best hope for a prosperous future. However, having experienced multiple organizations struggle with automation, the idea of AI/human integration, while great in theory, is challenging in practice.

‘Plus ça change, plus c’est la même chose.’

Organizations on the transformation journey should take the counterintuitive approach of embracing both change and the status quo. This idea is embodied by French philosopher Jean-Baptiste Alphonse Karr’s “plus ça change, plus c’est la même chose” literally translated “The more things change, the more they stay the same.” The notion that automation must work together with humans within many of the existing constructs of an organization, lays the groundwork for a successful strategy. This strategy must integrate the four realities of RPA, which will impact the majority of your enterprise processes.

Reality #1 – Your Processes Aren’t Going Away

Anyone that has worked with current RPA tools will tell you that they can be severely lacking, and their chances of automating one hundred percent of a process, is between slim and none. A recent study by McKinsey echoes this, finding that on average about thirty percent of a process can be automated using today’s technologies. Even as this percentage creeps higher we have to deal with the fact that the activities automated are often not continuous, human judgement must often be interjected, and exceptions happen. All of this means, todays automation technologies can’t support a fundamental rewrite of your processes, yet.

Reality #2 – Your IT Systems Aren’t Going Away

One the strengths of RPA is its ability to work with legacy systems, allowing organizations to get more miles out of their existing technology. It’s not just the systems here that matter, though. The overall enterprise IT architecture supporting the application of identity, change management, security, integrations, and infrastructure all are going to be around for a very long time.

Reality #3 – Your People Aren’t Going Away

If your processes aren’t going away, and your systems aren’t going away, your people can’t go away. While the actual number of people executing activities may drop, the groups involved in the process execution will like increase. IT, Security, Risk, and Compliance will be more involved in the day to day operations, now that RPA is embedded in a process.

Reality #4 – Your Organization’s Structure Isn’t Going Away

If people, process and systems aren’t going away, neither are the organizations that support them. While we can all agree that no organization is perfect, there are often time decades of best practices embedded in their policies and procedures. Every component of an organization has often evolved with a specific purpose, the purpose while maybe not obvious, will most likely need to be addressed in the context of RPA.

When constructing our go to market strategies, we look at how can we lower the “switching costs” of our solution. A high switching cost means, higher risks, higher expenses (impacting ROI), and usually a built in constituency that doesn’t look at change favorably. The same is true about an automation program. Every time the people, process, systems or org need to change, the switching costs are increasing. The key to the speed, and success of an RPA program lies in figuring out how to leverage components of the existing, while delivering change. It will at times be necessary to make large, transformational changes, but a land and expand strategy, while delivering value, presents the highest likelihood of success.

 

Source: fortressiq.com-19th Century French Philosophy, SkyNet, and the 4 realities of RPA

Why hyperconvergence and robots are the CIO’s innovation starting blocks

Automation and hyperconvergence go hand in hand

The majority of business leaders and CIOs are so consumed by day to day activities, there is little time to think strategically about their future direction. With technology continuing to move at a rapid pace, today’s innovations might be yesterday’s news by the time many CIOs get round to implementing them.

The demands of the business will continue to drive the need to optimise and reduce costs, but CIOs need also to adopt technologies such as the Internet of Things (IoT), Artificial Intelligence (AI), and Robotics.

However, embracing this kind of innovation is often easier than done. Through a combination of hyperconvergence, autonomics and robotic process automation (RPA), businesses can simplify their IT applications and infrastructure to reduce the costs of operations – allowing them to innovate while supporting day to day running of the business.

How to make IoT work for you

Over 50 billion devices are expected to be connected to the Internet by 2020, and analysts estimate that a $7.1 trillion dollar industry will be created. The IoT will be a catalyst for transforming virtually every industry from healthcare to insurance to financial services to retail to transportation and logistics.

Through IoT, many business processes can be empowered, and therefore, various industries can reimagine their business models and redesign their processes to take advantage of it. The IoT also unleashes the power of the connected world.

Product manufacturers recognise that by simply connecting their products to the Internet, beginning to collect data, and providing the right blend of analytics, they can unleash new revenue streams.

As an organisation it is critical that CIOs begin to embrace, experiment and deploy products and services based on IoT related technologies.

Conventional wisdom is no longer prevailing where the growth of the IoT will only be driven by large enterprises. There are over 3,100 startups in IoT spanning both products and industries, and according to Gartner, ‘by 2017, 50% of IoT solutions will originate in startups that less than three years old’.

Companies must therefore transform their company culture to make the most of the IoT, which demands new ways of developing and integrating applications. Infrastructure and computing power are no longer competitive weapons – two guys in Starbucks can have the same computing power as a Fortune 500 company.

Businesses must reassess what is core and what should be ‘rented’ or ‘leased’ in an as-a-service model. Becoming highly proficient in cloud, data and analytics is critical for launching IoT products and services; and applying cognitive analytics and AI techniques can create digital experiences that customers will love.

Using the power of hyperconvergence

Hyperconverged, web-scale infrastructure has quickly become one of the hottest trends in IT today. There are dozens of companies, from startups to established vendors, now integrating compute, storage, virtualisation resources, networking and other software components into a single appliance-like platform.

These hyperconverged systems are a natural progression from traditional IT infrastructure, which are commonly silos of systems and operations. Web-scale IT will be present in more than 50% of the world’s enterprises within five years.

Hyperconvergence helps CIOs scale, reduce costs, better align resources, and increase resiliency. Impactful use cases for hyperconvergence exist across traditional infrastructure, OpenStack architectures, as well as DevOps.

Hyperconvergence is a scalable building-block approach that allows IT to expand by adding units, just like in a LEGO set. Granular scalability is one of the hallmarks of this infrastructure, with automation a key component that goes hand in hand with hyperconvergence.

With all resources truly combined with centralised management tools are in place, administrative functionality becomes very easy to automate.

Trust the robots to help

Not too long ago, Robotic Process Automation (RPA) was a total mystery to most organisations, but its potential is now grabbing the attention of IT consulting and advisory firms, outsourcing providers, and enterprises alike. Mckinsey predicts that ‘110-140 million FTE’s could be replaced by automation tools and software by 2020’.

At its core, RPA is ‘robotic’ software that aims to reduce costs, and improve efficiency and productivity by removing repetitive and manually intensive tasks.

RPA consists of advanced software and algorithms that are deployed to complete routine tasks and processes previously performed by humans. RPA delivers accuracy and agility in response to new markets and regulatory demands, helping companies all over the world become more efficient and responsive.

Further, applying autonomics to infrastructure management is driving self-management (self-diagnosis, self-configuring, self-healing, self-optimising, self-protection etc.).

According to the Institute of Robotics Process Automation (IRPA), many IT infrastructure support jobs will be eliminated over the next three years such as automated patch downloads, automated ticket generation, automated account creation for a new application user etc. – allowing resources to be dedicated to truly innovative strategies.

Many companies like to call themselves innovative without really acting it. Keeping up with the pace of technology is certainty difficult, with new technologies emerging all the time.

But despite this difficulty, it’s critical that CIOs find a way to really be innovative, and not just in name only. By starting with hyperconvergence and the benefits of robotics, CIOs can smooth the adoption of new technologies, create happy customers and deliver an IT infrastructure that meets the needs of the business.

Source: information-age.comWhy hyperconvergence and robots are the CIO’s innovation starting blocks

Automation technology to the rescue

Over half of public sector senior managers have said their organisations explored utilising automation technology in the past year

Automation has been widely embraced in the private sector

The intention to integrate robotic process automation (RPA) software into governmental organisations has risen.

53% of public sector senior managers say their organisations have explored the use of automation technology.

Adopting RPA is a move that will combat increasing workloads and tightening budgets.

The research, conducted by iGov Survey on behalf of business outsourcing partner Arvato – of 134 decision makers across 118 public sector organisations – revealed that 21% of respondents expect automation technology to be trialed within their department or authority over the next 12 months.

Work volumes have increased, and staff levels have fallen. Indeed, 73% have seen work volumes rise in the past year, while 68% have experienced a reduction in available resource as a result of staff cuts over the same period, according to the survey.

57% report that more than a tenth of their department’s staff are spending the majority of their time on these administrative tasks.

RPA software is the perfect filler for the mundane and repetitive tasks that these employees find themselves doing.

Debra Maxwell, CEO of CRM Solutions, UK & Ireland, Arvato, commented: “Automation has been widely embraced in the private sector and it’s encouraging to see that government bodies are becoming more receptive to this technology as a way to improve services for citizens and increase efficiencies.”

“Fundamentally, it’s about enabling public sector employees to focus on what’s really important, and redirect resource away from mundane, repetitive tasks.”

Implementing RPA has been proven to improve business operational efficiency, and in governmental operations its use will improve citizen services.

This is the driver for automation. RPA provides a way of harmonising increased workloads, and depleting resources.

“At Sefton Council, one of the first local authorities to implement the technology, our RPA project has delivered impressive results, including reducing input times for Council Tax direct debit payments by 80%, with 100% accuracy,” said Maxwell.

There is little doubt that integrating RPA into governmental operations will have the desired result of improving operational efficiency. The desire, and results are there.

However, an attitude and policy change must be adopted by those who make the decisions.

This will ease RPA’s transition into conventional use.

Source: information-age.com-Automation technology to the rescue

7 Unknown Truths: Debunking Common Misconceptions about RPA and IT Jobs

Over the past few years, a robotic process automation has emerged as a new trend – an innovative and disruptive technology that companies can leverage to save time, money and resources through the automation of back office processes, as well as repetitive tasks.

Business investment in robotic process automation will make a leap from a $216 million market in 2017 to an $870 million one by 2020. And RPA is now being used or investigated by 6 out of 10 Australian and New Zealand organizations surveyed in the Telsyte ANZ Robotic Process Automation Study 2017, according to Gizmodo.

As every new trend, however, it also brings forth uncertainty about how its implementation will affect companies’ operational platform and their employees. UiPath talks extensively about the most common RPA myths on their blog, and going forward we will unmask 7 misconceptions about RPA and IT jobs.

Some IT professionals may consider RPA a threat to their jobs, but software robots are a powerful asset that can free them from menial tasks. Let’s take a look at some unknown truths that debunk the most common RPA misconceptions, and explain how RPA is different from other BPM tools and why 38% of organizations with more than 500 employees from Australia and New Zealand already have an RPA program underway.

1. RPA is easy to configure without having programming skills

The truth is that robotic process automation interfaces rely on the drag and drop principle to link steps in a process. As users do this, the code is generated automatically. Which means that business people with no coding skills can be trained to automate processes. Take a look at the development environment from UiPath. At CiGen, we work with UiPath and below you can take a look at a screenshot of the development environment.

1. RPA does not disturb underlying computer systems

According to “The Coming of Lightweight IT” by Bendik Bygstad, “lightweight IT” is a term used to describe front-end, commercially available software that supports processes and is typically adopted outside the control of the IT department. RPA is exactly that, meaning that it sits on top of existing systems. Unlike other BPM tools, it accesses data from the presentation layer using an ID and a password and does not store any of it.

1. Robotic process automation is non-invasive

One of the most common RPA misconceptions is the idea that it builds software robots that interact in new ways with IT systems. On the contrary, the robot software is configured to learn specific rules and then press keys. There are what we call “back office” robots that work unattended, and “front office” robots that work hand in hand with customer-centered staff.

Companies are still in the process of shifting their perspective about robotic process automation as a key tool for digital transformation. UiPath’s Lead Evangelist, Guy Kirkwood, says that “RPA will become the standard way that organizations run their operations.”

1. An RPA ‘developer’ configures RPA software whereas an IT ‘developer’ writes code

The same IT terms of ‘developer’ and ‘designer’ are also used in RPA, but they refer to different roles and skill sets. This is definitely a great example of misperception coming from RPA using a language which is considered normally pertinent to an IT delivery function.

This confusion leads some companies to believe that they can implement RPA in-house. According to a 2015 interview with their Head of Business Support, this happened to Leeds Building Society – who ended up wasting a lot of time and resources.

1. RPA eases IT workloads and delivers high-quality results quickly and inexpensively

Robotic process automation significantly eases the workload of the IT department, even being applied within IT function work itself.

It is less costly than other BPM solutions, it can relieve pressure on the IT backlog and can be introduced quickly, with no major effort. RPA is a real asset for companies because it can be extended to many pressing business conundrums.

1. RPA benefits from business-IT cooperation

A research into 26 IT-enabled innovation cases called “The IT Function and Robotic Process Automation” revealed that RPA implementation was more successful when it was business/user-led, rather than by the IT department.

In these cases, RPA was initiated outside the IT department, then eventually operated at a low scale, carefully supervised by the IT function. Only once this department became involved at a higher level, and satisfied, RPA use escalated and an enterprise RPA capability was built, supported by both the IT and business unit, according to Professors Leslie Willcocks and Mary Lacity.

1. RPA governance fits within existing IT governance or may evolve to a Center of Excellence

When it comes to RPA governance, various approaches were found, depending on the history of the IT department in the organization. The question is whether existing governance structures could continue to integrate robotic process automation decisions and management within them, as well as the understanding and maturity of RPA in the business at any time.

Most of those in favor of RPA manage to fit this concept within their current governance structure, then develop it as RPA expands into new business-related processes and, of course, across the business units.

Conclusion

RPA can actually represent a big opportunity for IT departments from companies all over the world to raise their profiles, according to CIO. They can help the company identify the enterprise tasks that can be automated, but also develop interfaces across systems and applications to integrate and expand automation.

Source: thefutureofthings.com-7 Unknown Truths: Debunking Common Misconceptions about RPA and IT Jobs

A Practitioner’s Guide To Artificial Intelligence

Artificial intelligence (AI) is delivering new insights − previously hidden in vast pools ofdata − to add intelligence to many products and services that ultimately transform the way organizations and machines interact. While human-like intelligence will remain the stuff of fantasy novels and movies for the near future, most organizations should explore incorporating AI into their business, products, and IT projects. Our firm’s research concludes that AI can improve productivity of internal applications, increase revenue, reduce costs, and improve products and services with added functionality or communication modes.

You can download the paper here.

 

Mashreq Bank Selects Blue Prism to Drive Innovation Across All Banking Functions

UAE’s leading bank adopts Blue Prism’s Digital Workforce to transform business operations while increasing customer satisfaction

LONDON, AUSTIN and DUBAI — Feb. 14, 2018 — In its efforts to continue pioneering innovative banking solutions, UAE’s leading financial institution, Mashreq, announced that it is working with Blue Prism (AIM: PRSM) to increase productivity, improve customer experiences and deliver new services.

Mashreq selected Blue Prism’s secure, scalable and easy-to-use Digital Workforce to deliver greater operational efficiencies, higher accuracy and a massive reduction in processing time for new and existing customer services. The bank is using Blue Prism to integrate artificial intelligence (AI) and automate dozens of mission-critical processes across multiple business functions, including banking operations, compliance, customer care and their technology help desk.

“We are harnessing the power of Robotic Process Automation (RPA) to create customer-centric solutions that can help us deliver on the promise we have made to our customers—to enrich their banking and financial experiences through innovation,” said Mr. Sandeep Chouhan, Group Head of Operations & Technology at Mashreq Bank. “The efficiencies and improvements enabled by Blue Prism’s Digital Workforce Operating System cut across numerous departments and enable us to be more responsive and agile as an organization. After evaluating several RPA offerings, we selected Blue Prism because it was the most scalable, secure and compliant solution available.”

As a result of automating many internal tasks and processes, Mashreq Bank has seen more than 150,000 secure and error free transactions executed daily. Mashreq’s deployment of Blue Prism has delivered a better issue TAT (Turn Around Time) by 65 percent on manual processes, and reduced customer complaints by 90 percent. In addition, individual branch productivity is up by 60 percent while human worker costs are down by almost 87 percent due to the bolstering of human workers with RPA tools that boost productivity.

“Industries like banking, insurance and financial services are ripe for the disruption and digital transformation that RPA brings,” said Dr. Jing Bing Zhang, Research Director and lead analyst, Worldwide Robotics and Asia Pacific Manufacturing Insights, IDC Asia Pacific. “The level of automation goes beyond streamlining administrative and transactional tasks. Service quality and time to service – how fast you can deliver service to customers – are the dominant drivers in intelligent automation, especially the adoption of RPA technologies.”

“We’re seeing expanding implementations of our Digital Workforce solution in the financial services sector from organizations looking to disrupt and drive more meaningful customer interactions,” said Alastair Bathgate, CEO, Blue Prism. “More companies are harnessing the power of automation to facilitate secure and compliant transactions while also freeing up human capital that can focus on delivering innovative, new services and improving the overall customer experience. We are excited to see a top bank in the UAE embrace RPA and achieve such impressive results with our Digital Workforce Operating System.”

In 2017, Blue Prism was named one of MIT Tech Review’s 50 Smartest Companies and recognized as the winner of the 2017 UK Tech awards. Over the past year, the company added several established brands to its roster of clients including AIG, Alberta Treasury Bureau, Allstate Insurance, Bechtel, Boeing, DeNA, DTE Energy, Dun & Bradstreet, Ericsson, Fannie Mae, GIC, Honda Motor Company, Kaiser Permanente, KBL Bank, Maybank, National Grid, Schroders, Sony Pictures, United Utilities and Walgreens. Blue Prism also attained the highest customer satisfaction rating of 96 percent in an independent customer survey by Knowledge Capital Partners (click here to download report). The survey of global Blue Prism customers highlighted satisfaction for platform adaptability, scalability, security and employee satisfaction.

About Mashreq
Established in 1967, Mashreq is the oldest Bank in the UAE with award winning financial solutions and services. Throughout its 50 years’ history, Mashreq has differentiated itself through innovative financial solutions, making it possible for its customers to achieve their aspirations. Today, Mashreq has a significant presence in 11 countries outside the UAE with 21 overseas branches and offices across Europe, USA, Asia and Africa.

Mashreq launched its new Vision and Mission recently, outlining its commitment towards its clients, colleagues and the community. In line with its new Vision to be the region’s most progressive bank, Mashreq leverages its leadership position in the banking industry to enable innovative possibilities and solutions for its customers across Corporate, Retail, International, Treasury and Islamic Banking. Mashreq is proud to be the first financial institution in the UAE to be awarded the Gallup Great Workplace Award for four consecutive years from 2014-2017. Mashreq also continues to invest in recruiting, training and developing future generations of UAE National bankers.

About Blue Prism
As the pioneer, innovator and market leader in Robotic Process Automation (RPA), Blue Prism delivers the world’s most successful Digital Workforce. The company’s software robots automate repetitive administrative tasks while meeting the requirements of the most demanding IT environments, where security, compliance and scalability are paramount.

Source: Blueprism-Mashreq Bank Selects Blue Prism to Drive Innovation Across All Banking Functions 

7 Essential Tasks Prior to Any RPA Implementation

With every new software release from RPA sector leaders, there is always much to be excited about as vendors continue to push the technological boundaries of workplace automation. Whether those new capabilities focus on cognition, or security, or scalability, the technology available to us continues to be a source of inspiration and innovative thinking in how those new capabilities can be applied.

But success in an RPA deployment is not entirely dependent just on the technology involved. In fact, the implementation design framework for RPA is often just as important – if not more so – in determining whether a deployment is successful. Install the most cutting-edge platform available into a subpar implementation design framework, and no amount of technological innovation can overcome that hindrance.

With this in mind, here are seven tasks that should be part of any RPA implementation plan before organizations put pen to paper to sign up with an RPA platform vendor.

Create a cohesive vision of what automation will achieve

Automation is the ultimate strict interpretation code: it does precisely as it’s told, at speed, and in volume. But it must be pointed at the right corporate challenges, with a long-term vision for what it is (and is not) expected to do in order to be successful in that mission. That process involves asking some broad-ranging questions up-front:

• What stakeholders are involved – internally and externally – in the automation initiative?
• What are our organization’s expectations of the initiative?
• How will we know if we succeeded or fail?
• What metrics will drive those assessments?
• Where will this initiative go next within our organization?
• Will we involve our supply chain partners or technology allies in this process?

Ensure a staff model that can scale at the speed of enterprise automation

We tend to spend so much time talking about FTE reduction in the automation sector that we overlook the very real issue of FTE sourcing (in volume!) in relation to the implementation of automation at enterprise scale. Automation needs designers, coders, project managers, and support personnel, all familiar with the platform and able to contribute new code and thoughtware assets at speed.

Some vendors are addressing this issue head-on with initiatives like Automation Anywhere University, UiPath Academy, and Blue Prism Learning and Accreditation, and others have similar initiatives in the works. It is also important that organizational HR professionals be briefed on the specific skillsets necessary for automation-related hires; this is a relatively new field, and partnering up-front on talent acquisition can yield meaningful benefits down the road.

Plan in detail for a labor outage

The RPA sector is rife with reassurances about digital workers: they never go on strike; they don’t sleep or require breaks; they don’t call in sick. But things do go wrong. And while the RPA vendors offer impressive SLAs with respect to getting clients back online quickly, sometimes it’s necessary to handle hours, or even days, of automated work manually. Having mature high-availability and disaster recovery capability built into the platform – as Automation Anywhere included in Enterprise Release 11 – mitigates these concerns to a specific degree, but planning for the worst means just that.

Connect with the press and the labor community

Don’t skip this section because it sounds like organized labor management only, although that’s a factor too. Automation stories get out, and local and national press alike are eager to cover RPA initiatives at large organizations. It’s a hot-button topic and an easily accessible story.

Unfortunately, it’s also all too easy to take an automation story and run with the sensationalist aspects of FTE displacement and cost reduction. By interacting with journalist and labor leaders in advance of launching an automation initiative, you’re owning the story before it can be owned elsewhere in the content chain.

Have a retraining and upskilling initiative parallel to your automation COE

Automation can quickly reduce the number of humans necessary in a work area by half or even more. What is your organization’s plan for redeployment of that human capital to other, higher-value tasks? Who occupies those task chairs now – and what will they be doing?

Once the task of automation deployment is complete, there is still process work to be done in finding value-added work for humans who have a reduced workload due to automation. Some organizations are finding and unlocking new sources of enterprise value in doing so – for example, front-line workers who have their workloads reduced through automation can often ‘see the forest’ better and can advise their superiors on ways to streamline and improve processes.

Similarly, automation can bring together working groups on tasks that have connected automations between departments, allowing for new conversations, strategies, and processes to take shape.

Have an articulation plan for RPA and other advanced technologies

RPA and cognitive automation do more than improve the quality and consistency of work – they also improve the quality and consistency of task-related data. That is an invaluable characteristic of RPA from the organizational data and analytics perspective, and one that is often overlooked in the planning process.

While it might take days for a service center to spot a trend in common product complaints, RPA platforms could see the same trend in hours, combine that data in an organizational data discovery environment with IoT data from the production line, and identify a product fault faster and more efficiently than a traditional workforce might. When designing an automation initiative, it is vital to take these opportunities into account and plan for them.

Create a roadmap to cognitive automation and beyond

RPA is no more a destination than business rules engines were, or CRM, or ERP. These were all enabling technologies that oriented and guided organizations towards greater levels of agility, awareness and capability. Similarly, deploying RPA provides organizations with insight into the complexity, structure and dependencies of specific tasks. Working towards task automation yields real clarity, on a workflow-by-workflow basis, of what level of cognition will be necessary to achieve meaningful automation levels.

While many tasks can be achieved by current levels of vendor RPA capability, others will require more evolved cognitive automation, and some will be reserved for the future, when new AI capabilities become available. By designating relevant work processes to their automation ‘containers’, an enterprise roadmap to cognitive automation and AI begins to take shape.

Source: research.nelson-hall.com-7 Essential Tasks Prior to Any RPA Implementation

New Independent Study Reveals Why Not All Software Robots Are Created Equally

By Leslie Willcocks

Robotic Process Automation (RPA) continues to be a growing success story. In 2016, RPA alone experienced a 68 percent growth rate in the global market, with 2017 maintaining this momentum. Some reports have even predicted a US$ 8.75 billion market by 2024. However, merely investing in RPA is not an instant recipe for growth.

In “Service Automation Robots and The Future of Work” (2016), my colleague Mary Lacity and I highlighted successful RPA deployments and how organizations were achieving triple wins for their shareholders, customers, and employees alike. We continued tracking these developments in 2017 and also noticed something different — many less successful journeys. In practice, it appears that automation success is far from guaranteed. Wider reports provide anecdotal evidence of between 30 to 50 percent of initial projects stalling, failing to scale, being abandoned or moving to other solutions. Our most recent research has examined in detail both successful and more challenged automation deployments. It turns out that service automation — like all organizational initiatives that try to scale — can be fraught with risk. We’re seeing 41 specific risks that need to be managed in eight areas: strategy, sourcing, tool selection, stakeholder buy-in, project execution, change management, business maturity and an automation center of excellence.

One of the key risk areas is tool/platform selection. Because of the hype and confusion in the RPA marketplace, clients risk choosing the wrong tool(s), too many tools, or bad tool(s). By early 2018, over 45 tools or platforms were being sold as “RPA” and over 120 tools were being sold as some form of cognitive automation. Because the space is relatively new to many clients, it’s difficult to assess the actual capabilities and suitability of these tools. Clients must be wary of hype and “RPA washing”.

In our new report on Benchmarking the Client Experience, we extensively polled clients at Blue Prism on the results they’ve been getting by integrating RPA into existing business processes. In order to get the most valuable feedback, we set the bar high in requesting client assessments of the Blue Prism RPA platform on the following criteria: scalability, adaptability, security, service quality, employee satisfaction, ease of learning, deployment speed and overall satisfaction. From our qualitative research into process automation, these emerged as the most critical and essential characteristics and requirements for a successful enterprise-grade RPA implementation.

The overall level of satisfaction with the Blue Prism platform was extremely high in our survey. Respondents reported a 96 percent overall satisfaction rate, with 79 percent of respondents ranking Blue Prism’s platform a six or seven on a seven-point Likert Scale. Based on our 25-year research history into process improvement initiatives (BPM, shared services, outsourcing, six sigma, etc.), these are extremely high RPA satisfaction levels. Our research into IT and Business Services outsourcing finds only 20 percent of vendors getting “world class” performance, 25 percent getting good performance, 40 percent “doing OK”, while 15 percent experience poor outcomes. The record on IT projects also continues to frustrate. The most recent (2017) Standish Group CHAOS report found only a third of IT projects were successfully completed on time and on budget over the past year – the worst failure rate the Standish Group has recorded.

What, then, accounts for the impressive 96 percent overall satisfaction rate with Blue Prism?

Our observation is that not all RPA offerings are the same. The capability of RPA software depends greatly on the origins and orientations of the supplier. If designed as a desktop assistant, many RPA tools experience problems with scaling, security and integration with other information systems. Other RPA vendors offer RPA which is effectively a disguised form of what we have described as a “software-development kit,” needing a lot more IT development by the in-house team or the RPA vendor than first imagined, and incurring unanticipated expense, time and resources. True enterprise RPA, however, is designed from the start with a platform approach, to fit with wider enterprise systems. This might make it more expensive initially, and require more attention in the first few months of trial, but true enterprise RPA platforms have proven to be an investment in success later in the deployment cycle, when compared to other RPA software that tends to run into real problems.

Our qualitative research also suggests that some RPA tools are not easily scalable, especially those based on a recording capability, or requiring a lot of IT development. This occurs because some RPA tools are not designed as configurable service delivery platforms that can be integrated with other existing systems. These also need a lot more management involvement than clients and their vendors often expect. Many clients, moreover, do not put in place the necessary IT, project and program governance (rules and constitution, who does what, roles and responsibilities), and often do not use built-in tools that contain technical governance.

This, of course, is not the whole story. An RPA and cognitive skills shortage is already upon us. This means that retained capability and in-house teams are sometimes not strong enough – a situation not helped by sometimes skeptical senior management under-resourcing automation initiatives and not taking a strategic approach. Consultants are also hit by skills shortages and cannot always provide the support necessary — this is also true with business services outsourcing providers. We are also finding that clients often do not give enough attention to stakeholder buy-in and change management. Given these emerging challenges, the Blue Prism client satisfaction level are very notable indeed.

To download the report, click here.

Leslie Willcocks is Professor in the Department of Management at the London School of Economics, and co-author, with Mary Lacity, John Hindle and Shaji Khan, of the Robotic Process Automation: Benchmarking The Client Experience (Knowledge Capital Partners, London).

Source: blog.blueprism.com-New Independent Study Reveals Why Not All Software Robots Are Created Equally

Robotics Process Automation: 5 Lessons Learned on How to Get Started

I suspect that a high percentage of people reading this article are already familiar with the basics of Robotics Process Automation (RPA), and the significant cost savings and efficiencies that RPA can bring to your organization by automating high volume, transactional processes in multiple functions including Finance, HR and IT.

Now that it’s clear that you need to start evaluating RPA and how to implement it in your organization, I’m sure there’re many open questions about how to get started. The purpose of this article is to briefly point out five key lessons learned on how to jump start a Robotics Journey, based on our experience as both an advisor and a managed services operator of RPA:

1. Don’t drink the vendor “Kool-Aid”

As Gartner cited in a recent RPA study, “The expectations of robotic process automation (RPA) are as significant as the confusion about the technical capabilities of the RPA tools themselves.”

Many RPA software vendors will try to convince you that almost anything can be automated and tend to oversimplify the actual deployment process. While the power of their tools can’t be denied, programming a dysfunctional process wastes time and effort, and is less stable upon deployment. In our experience, processes will often require some degree of standardization or redesign during the automation journey.

Plus, RPA vendors often talk about processes that require dozens of robots and hundreds of workers. While these processes and operations clearly exist (e.g. Financial Services), and the benefits can be significant, they are not the “norm” for most businesses. Most companies we have spoken with are looking to leverage RPA for back office processes that often utilize dozens of employees, not hundreds. In these scenarios, the investment in RPA may not yield the ROI that the vendors are touting, and a more practical implementation approach is required.

Deep business process expertise and knowledge of your back office environment is equally as important as selecting the right RPA tool. Process expertise and knowledge of your back office do not come from the RPA software provider. And their business case methodology needs to be adapted to a much smaller footprint for most businesses.

2. Partner with an RPA expert

This second lesson learned goes hand in hand with the first. Many organizations try to implement robotics by themselves, with no internal or external RPA expertise. Companies often do not realize this can cause their RPA initiatives to go off track, take longer and cost more money.

We’ve seen how some companies have chosen the wrong RPA tool because they didn’t get the right advice. They just selected a solution based on price or market presence, and then realized it had many limitations, was not scalable, or simply did not deliver the expected (and needed) ROI.

Another common mistake is for companies to task one of its employees to lead the RPA initiative, but the person is so embedded in the day-to-day operation, and the way processes currently operate, that they lack the necessary objectivity, and fresh eyes to identify how activities can be changed and adapted to RPA.

Most RPA advisors or managed services providers can quickly assess your organization, identify the key automation opportunities and provide a realistic implementation timeline based on having delivered these initiatives multiple times. This initial assessment will provide you with a good estimate of the savings and efficiency opportunity before you decide to embark on this journey.

3. Understand your deployment model options

RPA can be deployed in a model where it is managed internally or through an outsourced Managed Service model. An organization will need to determine which RPA deployment model fits its “DNA.” Many midsize firms do not internally possess the process excellence, technical expertise, and change management skill set to manage the deployment internally successfully.

If built internally, the firm will need to document processes, train the robot (through development and configuration) to perform the process, and build an ongoing support function to monitor the robots and continually reconfigure the robot as systems and process evolve. Their IT departments may be too overloaded managing their existing systems and other priorities and do not have time or resources needed to support the RPA software and ongoing environment adequately. It is often less costly for these firms to turn to an Outsourced BPO Provider to build these capabilities as part of their scope of services.

4. Embrace your workforce

It’s not a secret that the impact of RPA on your workforce is huge (according to ISG Insights the rate of RPA/AI adoption is set to double by 2019). But this doesn’t mean your employees should feel disengaged with the initiative.

Whether they want it or not, automation is going to come sooner or later, and the sooner they get involved with it, the bigger competitive advantage they will have if they want to make a career within the back office and process optimization. If not, they better look at shifting their career path.

RPA requires a new set of skills and capabilities that will need to be learned and performed by someone, ideally by those “operators” currently executing the tasks manually. In the end, the tasks to be automated are those that most employees would gladly relinquish. Educating employees on how RPA will allow them to focus their time on higher value-added activities will help get them on board. It is not uncommon for your highly engaged best performers to embrace the change and jump at the opportunity to perform higher value work, while less engaged bottom performers resist change and look for an exit.

5. Start small

It is important to realize that RPA should be viewed as an integral component of your back office operation going forward, and not as a “project.” The key to success is to start small, prioritize initiatives and build momentum towards full deployment over time. An initial “Fit Analysis” can quickly identify & prioritize processes that deliver the most benefit with the least amount of complexity.

A typical best practice is to perform an initial Proof of Concept by automating a small number or processes with limited investment. If successful, the Proof of Concept confirms the value of Automation while also delivering savings to fund additional deployment. Additionally, success will build organizational and executive buy in. Any major change initiative needs quick wins to build and sustain the momentum needed to push through an organization’s inherent discomfort with change. It also creates an opportunity to reflect on lessons learned and adjust the implementation strategy based on the initial experience.

After a successful pilot, you are now ready for a broader deployment across the organization. This phase of the RPA journey involves an iterative process of business analysis, BOT development, and configuration, training, and testing. Incorporating the lessons learned from the pilot. During this time you should also be building a support structure for ongoing operations and management. The BOTS are now part of your ongoing operation and like other aspects of your business require continuous monitoring, support, and tweaking. The benefits of RPA can be significant for an organization, but like anything else, it requires commitment, investment, and planning.

Our experience has shown that the mistakes that companies make in implementing RPA are from under-estimating the effort and knowledge needed to implement it. Having realistic expectations, and good guidance and support, coupled with a well-thought out implementation strategy and a rigorous deployment methodology, will help to ensure RPA success.

Watch this quick demo for a real-world example of RPA in action.

Ready to start your RPA journey?

Source: auxis.com-Robotics Process Automation: 5 Lessons Learned on How to Get Started

Building An RPA Project Specification Document

Most successful RPA projects emanate from a good design. Regardless of one’s preferred method for arriving at that design (e.g. Agile, Waterfall, etc.), the process should include the development of a formalized specification document (spec), that details the road ahead and builds project team consensus. While this might seem obvious to the experienced developer, RPA’s new-found celebrity has attracted a lot of new and eager practitioners whose enthusiastic desire to produce quick wins might also encourage some short-cutting. The purpose of this article is to articulate some the best practices our professional services team has identified over the years when it comes to building an RPA specification document.

Just the facts. The most important aspect of constructing the spec document is that it precisely captures just the process being automated. While “color commentary” can be helpful to the PD (Process Designer), when trying to understand the process and assessing potential improvements, such commentary should not be included in the spec. The goal of the document is to focus the AA (Automation Architect), only on the aspects of the process that are required to complete the transaction. All information beyond what is needed to complete the process is often considered noise. In other words, the AA cares about the: “who, what, which and where”, and not much about the “why”. While the spec must contain as many details as possible regarding the transaction, the details should focus on:

1. Where to start?
2. Which screens to navigate?
3. Which user interface controls to manipulate?
4. What data should be extracted and/or pasted?
5. How should data be manipulated?
6. What application and screen states to look for?
7. How to handle error conditions and exceptions?
8. What state to leave the application in when the transaction completes?
9. How should logging be performed?

Minimize jargon. The AA is usually not intimately familiar with the user’s business nor conversant in the specific language of the business. Therefore, keeping jargon down to a minimum is important. The best method is to try to relate jargon to standardized business terms most AAs do understand such as: invoices, purchase orders, inventory item, price, etc. If it is required to include jargon to help the customer team understand the spec, make sure you include a glossary of terms early in the spec.

Make each step as atomic as reasonably possible. Each individual function the automation must perform is called a “step”. In the spec, each step is uniquely numbered so it can be cross-referenced and tested individually, and linked back to when viewing logs. For this reason, it is important to define each discrete function the automation performs, (e.g. the pasting of data to one field, or the clicking of a button), as its own step, and not lump multiple functions together. Break each process down to its most reasonable atomic function. When I say “reasonable”, I mean the step that represents a logical unit of work that you would want to link back to from a log. Let us review a couple of simple examples.

Example 1: If a step calls for pressing the key combination, “Alt+K”, this should be expressed as one step, not two.

Example 2: What about if you want select a sub navigation menu bar that requires two sets of key presses (e.g. “Alt+F” and “O” to pop a File Open dialog). Should this be represented as one step or two? In this case, it makes sense to combine the key presses into one step since the logical unit of work is the popping of the File Open dialog. However, it would not be wrong to break the process down into two steps. It ultimately comes down to style and it is probably more important to represent these steps consistently in one given spec than to definitively handle them one way or another.

Steps should be numbered and sub-numbered. Well-designed automations can cross reference their functions back to the steps defined in a spec when a user is viewing an action execution log. This allows the user to easily figure out, using the language of the user, what the action was supposed to be doing at a specific point during the execution. However, this cross-referencing can only happen if the steps defined in the spec are uniquely numbered.

A picture is worth a thousand words. While narrative descriptions are important, nothing informs the AA more about the task at hand than a picture (see Figure 1).

Figure 1

A spec should make heavy use of screen shots to communicate information such as:

• What should the state of the screen look like at this step?
• Via highlights, which user interface (UI), elements are the elements to be manipulated in this step(s).

Other points to consider when working with screen shots:

• Screen highlights should use colors that are not contained within the screen upon which they are overlaid and those colors should be used consistently throughout the spec.
• It is a common practice to include the step number in a screen shot highlight for each UI element highlighted.
• Screen shots usually embody references to multiple steps (i.e. multiple screen shots of the same screen should be avoided).

Spec the negative condition. Documenting a process where everything goes according to plan is easy. However, accounting for error or unexpected conditions can be more of a challenge. For example, a step that states; “4. Select part number from list.”. What should the automation do if the part number is not in the list? This is the kind of “negative” condition that should be accounted for in your spec. The more negative conditions you can capture in the spec (again, within reason), the less back and forth the AA will have with the user team for clarifications.

Seek out keyboard short cuts and mnemonics where possible. While most RPA tools support drag/drop and icon clicking, it is always faster and less subject to error when a keyboard shortcut or menu mnemonic is used in an automation. Although the AA will ultimately decide the best method for automating the user interface, calling out such shortcuts are always helpful.

Demarcate commentary via notes. Even though sticking to the facts is paramount when building a spec, there are times when some commentary is required (e.g. how something is calculated or the conditions under which certain states arise). In these cases, it is a best practice to not include the commentary in a step, but rather, break it out as its own “section note”.

Include an automation start state & preparation section if applicable (usually applicable to attended bot automations). If access to the development environment is proctored, then in most cases, the proctor should be able to navigate the AA to the application screens from which the automation is initiated. However, if access is not proctored, it is important to include in the spec (prior to the step definition), an automation start state section that includes the following:

• Application load methods.
• Login credentials for the applications.
• Navigation path to get to the automation start screen.
• Any data required to support the navigation path.

Include incomplete transaction rollback instructions. Some transactions commit data at specific steps prior to the completion of the process. If this is the case, the spec should include the process for rolling back the transaction to its pre-processing state. If the rollback conditions are only applicable to the testing of the action, it should be demarcated as a note. If the rollback must happen in production as well, it should be documented as its own set of steps.

Defines skills required to handle a prompt. This point applies exclusively to unattended bot projects. When an unattended bot encounters a processing condition that requires assistance from a human, it can raise a “prompt” and send a notification to one or more authorized users. When the prompt notification is received, the user can either provide the information requested by the prompt or click through the notification and take control of the unattended bot’s desktop. This is a powerful RPA feature that helps reduce job rejections and speeds up transaction processing. However, not all users may be able to handle all raised prompts. Most RPA tools that support prompting usually allow you to associate a “skill” with a prompt so that only users possessing that skill will be sent specific prompts. This being the case, it is important the spec define where and what specific skills are required to address any defined prompts.

Building and getting the spec approved is an iterative process. Though things seem clear upon the first pass of a design, there are always clarifications and modifications that take place as people give the process more scrutiny. All changes should be incorporated into a new version of the spec. The initial version of the spec draft should be versioned “v1.0”, with subsequent versions incrementing the sub number (e.g. v1.1, v1.2, v1.3, etc.), assuming the modifications and clarifications do not change the scope of the project. Most specs do not require the major number to be incremented, but it does happen. This is usually the case when a project has major functional changes added to it during the design phase.

Once the specification is approved by the user, that version is considered the “build draft”. I call it a build draft because, undoubtedly, the development process will uncover issues that were not captured properly in the original spec, thus requiring final modifications. This is normal part of the process.

Finally, one of the most important aspects of the spec document is that it be kept current during the development and testing phases. It is critical that any modifications made to the process to accommodate variances uncovered downstream of the build draft get incorporated back into the spec. Otherwise, the spec will have little use when users try to use it to understand exceptions or use it as the basis for a phase II project.

Source: Joe Labbe-Building An RPA Project Specification Document