Tag: robotic process automation

Automation Bias | Sherpas in Blue Shirts

September 11, 2015

We’re at an inflection point in the ITO and BPO services world where we’re about to see a new level of technology: automation. On the whole, automation is a good thing. But there are some significant aspects we should be aware of. One is automation bias. And it’s dangerous.

When we move to automation, whether it’s cognitive computing or replacement of repetitive tasks, the people who are in the process become dependent on the automation. In fact, not only do they become dependent, they start to believe that whatever comes from the computer is truth. They take it for granted that the results are accurate. This is automation bias.

As a simple example, when you use a calculator, you quickly start to trust whatever the calculator results are. We have blind trust in automated tools.

Why is automation bias so dangerous?

A computer will slavishly do what it’s told to do or will run down the same cognitive analysis it has done in the past. When the world changes, the computer may not recognize that the world has changed. Change can come from one of the data sources having made a change. Or it could be an upstream or downstream change in a business process. Although people in the business process should recognize the change, automation bias may cause them not to recognize it because they believe that everything coming out of the computer is correct. This is a significant business risk.

The fact is automated tools are fallible. We all know that the world constantly changes, and automation bias presents the risk that the computer won’t recognize the change.

We’re on the verge of taking robotics and automation at a scale we have never done before. This will dramatically change how we perform business processes and how we run data centers. Organizations going down the automation path need to be aware of automation bias and build safeguards against it.

Photo credit: Flickr

How Are Automation Services like Christmas? | Sherpas in Blue Shirts

September 10, 2015

The industry is abuzz with enthusiastic discussions around the potential for robotics, cognitive computing, and robotic process automation (RPA). You can’t go to a conference – whether it’s IT, BPO, or shared services – without hearing a vigorous and spirited discussion around service delivery automation (SDA). Given the promise of SDA for people replacement, dramatic improvement to productivity, significant cost savings, and improvement of cycle time, why haven’t we seen more adoption?

The answer is awareness is still building. When we look at the actual adoption of SDA (which encompasses cognitive computing and RPA), we see this to be in a very early stage.

Large enterprises rarely adopt technologies without pilots, and results are coming in on a daily basis. The early adopters are just now finishing their early pilots. The services industry is grappling with how to industrialize the technology. From the results coming in on a daily basis, it’s very clear that the services industry will be greatly affected by SDA.

For those who are in disbelief, I advise further research.

For those of us who wonder why SDA is slow in coming, I caution you that it’s like Christmas – it will be here before you know it. I believe it is only a matter of time.

And just like Christmas, as SDA starts to take hold, it will feel like it comes with a rush. As any parent knows when dealing with their children before Christmas, it seems to be slow but then comes in an all-consuming giant rush. Look out – it will be overwhelming.

Photo credit: Flickr

Three Ways Services Customers Can Switch to as-a-Service Model | Sherpas in Blue Shirts

August 31, 2015

As the services industry begins moving into the as-a-service era customers look for providers that change their traditional services to make them elastic or consumption based. We at Everest Group have spent some time studying this, and we believe there are three key ways to change take-or-pay (fixed costs oriented) services and make them elastic (pay as used). One or even a combination of all three ways are present in the services model that customers now demand.

1. Multitenant sharing

Customers benefit from a provider sharing its capacity among multiple clients. AWS and Salesforce are classic examples of this elastic type of service. They redeploy servers or capacity when not in use to other customers and therefore achieve an extremely high utilization rate. In fact, arguably, AWS has over 100 percent utilization rate because it can charge customers for capacity when they’re not using it, yet can use that capacity for other clients. The model is much like an airline selling more seats than its actual capacity.

2. Automation

Repeatable process automation (RPA) or robotics spins up a virtual robot to do the work and then shut it down again. This fundamentally aligns a customer’s costs with usage and thus makes the service elastic.

3. Change purchasing method

The third way customers can have elastic services is to change their purchasing so that they only buy services as they use them. An example of this would be changing the way a customer acquires software, switching from enterprise licenses to consumption-based licenses where the customer pays for the software only as they use it. A note of caution here for customers: Although this makes the service elastic to you, there may be a stranded cost to your provider, and that cost may be embedded at a higher cost to you in your cost structure. So be careful about overly using the purchasing mechanism to make a component of your IT service stack be elastic.

Although customers can use these three methods separately, it is also beneficial to look for service providers that use a combination of all three methods to make a material difference to an entire service line to make the service far more flexible and consumption based to meet your needs.

We have not uncovered other mechanisms to make a provider’s service line elastic, but we are very interested to know if you have discovered another way to achieve elastic services. Please post your comment and share your experience.

Photo credit: Flickr

The Rough and the Smooth of Business Process Automation Technologies: Initial Insights of Our Deep Dive | Sherpas in Blue Shirts

July 20, 2015

We have been taking a deep look at the newer types of Service Delivery Automation (SDA) technologies for business process services (BPS). These include robotic, cognitive and plug-in architecture tools. Our interim findings show a lot of similarities and many differences.

BPS automations can be successfully achieved by all the tools, albeit, in different ways and for different types of processes. Some offer richer and more rounded features that make the software more user and enterprise friendly. The features include but are not limited to visual tools, automation control and management features, and process analytics.

Some are more advanced in their utility pricing and cloud deployment options than others that, for now at least, are sticking to older styles of licensing.

Some have other advantages such as being well supported by partners and resellers while others are behind on this.

We have been surprised by some of the findings too – for example, a technology vendor seemed to underestimate the potential of its software, which we thought could tap into new opportunities if wrapped in a control and management layer. Another surprise was a vendor that turned out to be more technology-focused than we had expected. Its well-practiced demo was impressive but showed a high focus on technology versus other considerations, such as a methodology, to get clients started.

This is a dynamic and changing landscape. And the technology providers are working to enhance their offerings, for example, the software itself or the partnership relationships.

The future outlook is a mix of product and eco-sphere developments:

  • Some vendors are starting to combine robotic and cognitive or AI capabilities while others are focusing on other aspects of intelligent automations
  • On the eco-sphere front we expect to see automation communities springing up supported by the technology vendors. These will share automation know how, best practice and, in time, portable and reusable automations
  • We will also see increased emphasis on resellers and implementation partners.

Another development is large system integrators building automation centres of excellence. The technology vendors will be competing to get into these centres.

Many service providers are also developing their own automation technologies. These will have to offer a more compelling outsourcing proposition to clients than in-sourced processes that are automated in-house, using the independent technology vendors’ automation software and supported by system integrators.

Keep an eye out for Everest Group’s in-depth report on SDA technologies and their assessment, which will be released soon. Our currently available SDA reports include:

Reports:

Free SDA content:

Software Eats Everything | Sherpas in Blue Shirts

June 25, 2015

A widely quoted phrase these days is “software eats everything.” It refers to the great value that software delivers. I believe it also applies to the profound impact it’s making in the services world. Software is disintermediating the industrialized labor arbitrage model and also infrastructure services. Let’s look at the huge implications for the services industry.

How is software eating services? It’s happening in a number of important ways and areas.

Software eating BPO

First, software enables automation and RPA to replace much of what the current industrialized arbitrage model does. Much of this work is repetitive and screams for a more automated approach. BPO work, for instance, bridges the gap between the labor that interfaces between records and the system of records. As I’ve blogged before, software is about to eat BPO labor.

DevOps and software eating infrastructure services

The DevOps revolution’s impact on infrastructure services is another example of software eating everything. A fully integrated DevOps platform allows defining code for infrastructure hardware at the same time as defining code for functionality. Increasingly in a software-defined infrastructure, companies can build an integrated DevOps platform that enables simultaneously configuring the entire supply chain from functionality all the way down to the number of cores it requires to run and test it.

Prior to the DevOps movement, all these steps were labor based, and much of this work migrated into the industrialized arbitrage model. They now become largely automated and software controlled.

Software and virtual services eating infrastructure services

Another example within infrastructure is the infrastructure itself. Five years ago, companies operated in a world where they were trying to move from 20 servers per FTE to 50. Most of the infrastructure service providers succeeded based upon their ability to make that shift.

Today, the services industry tries to get up to somewhere in the range of 200 to 500 FTEs per server. But the highly automated world in Silicon Valley has over 100,000 virtual servers per person. They’ve completely severed the link between people and servers. Again, a dramatic example of software eating everything.

SaaS, BPaaS impact

Another dramatic example of software eating everything is the Software-as-a-Service (SaaS) and Business Process as a Service (BPaaS) offerings. These software-based services offerings completely automate and configure the software, hardware, and business process experience for customers. SaaS and BPaaS completely upend the classic functional model previously used to deliver these functions.

Implications for the service industry

Software eating everything is a relentless focus on different ways to sever the traditional link of labor (FTEs) to service. The dislocation to labor-based businesses will be immense over the next few years as this journey to a software-defined world continues and existing business models struggle to adapt.

A software-defined marketplace will dramatically change the current services market. It will create opportunities for new industries to emerge and force tremendous tension on the incumbent service providers to survive by embracing the change and cannibalizing their existing work.

Photo credit: Flickr

Wipro Commits to Service Delivery Automation | Sherpas in Blue Shirts

June 18, 2015

I recently spent a very productive day with Wipro as they showed examples of their commitment to service delivery automation – a commitment I observed as more than in any other service provider. HOLMES, their recently unveiled artificial intelligence platform is just the beginning of this serious commitment. Here are three very important aspects of this commitment.

Step one: IP and funding

Some time ago Wipro recognized that the service industry is changing very profoundly, and a significant secular driver of the change is new automation technologies that allow customers to automate a dramatically higher number of services than has been automated in the past. They took concrete steps to address this change.

They recognized not only the customer impact of implement automation in their workflow but also the impact to the service provider. Over time, the value will be captured by the automation owner, not by the service provider. Therefore, Wipro decided to invest in owning its automation IP – and that involves not just funding the initial build but also ongoing investments.

That’s not to say that when Wipro deploys automation in their accounts they will employ exclusively their own IP, but they recognize the need for a significant portion being their own IP.

Step two: stepping up the pace

Wipro allocated a large, dedicated team into building its automation platform, which they named HOLMES. But unlike some other providers, they extensively used open source software to get a head start and then layered in their own development on top of the open source component. This allowed them to move quickly in bringing compelling functionality to the marketplace.

Step three: executive preparation for internal disruption 

The third aspect of Wipro’s automation strategy is their commitment from CEO TK Kurien on down through the leadership ranks to bring this to the marketplace. TK and senior leadership are committed to take this service delivery capability into their existing client base as well as use the automation platform as a challenger to gain new share in the market.

I believe bringing automation into their existing client base will be the most challenging endeavor, and they acknowledge that it will be disruptive and may be cannibalistic to their revenue flows.

We await to see how they handle such disruption. The details revealed to me were somewhat vague as to how they will realign their incentives to allow their account teams to do this. But certainly the executive commitment is such that it’s possible they will take the necessary steps to make incentive changes.

They are preparing for the inevitable disruption that will accompany the drive to become a leader in automated service delivery.

RPA Breaks Link between FTEs and Service Transactions | Sherpas in Blue Shirts

June 17, 2015

Robotic Process Automation (RPA) is becoming a big deal in the services industry. For the last 10 years, the Indian IT industry attempted to affect pricing by breaking the link between FTEs and the services they provide. They tried outcome-based or transaction-based pricing. As I have blogged in the past, although this is interesting and has some utility; but it has both positive and negative consequences. And it’s an incomplete answer to severing the link; it prices the services differently, but it still maintains the link between the services and the people who do the work. But software accomplishes the goal with RPA. Here’s why it’s a big deal.

At Everest Group we’ve studied the impact of RPA’s disruption on BPO services. Automation and RPA break the link by replacing people with a piece of software sitting on a virtual server, which can be spun up at any time and then shut down when the work is done.

Great efficiencies come from RPA breaking the link between FTEs and services. Another significant benefit is that it enables delivering services in a consumption-based pricing model. Providers can match their costs against consumption. In the traditional FTE model, the people continue to be an inflexible cost over time, even after the provider switches them to work on another task or another client’s work. And reassigning them to other work draws out inherent friction and the problems of a learning curve.

In Silicon Valley, software firms used RPA to move from having 30 to 50 virtual servers per person five year ago to now having over 100,000 (and climbing) virtual servers per person. I believe the same potential lies in the services industry through leveraging RPA.

Photo credit: Flickr

EG with tagline Neg
Linkedin-in Facebook-f Play Instagram
Better Decisions Powered by Tenacious Research    

Contact Us

Who We Are

About Us

Newsroom

Office Locations

Partners & Affiliations

What We Offer

Memberships

Custom Decision Support

Published Research

Careers

Why Everest Group

Explore Openings

Equal Opportunity Employer

Resources

Access Reports

Citation Policy

Everest Group Market Intelligence (EGMI)

Legal

Using the Reports Portal

©2023 Everest Global, Inc.         Privacy Notice          Terms of Use        Do Not Sell My Information

How can we engage?

Please let us know how we can help you on your journey.

Contact Us

"*" indicates required fields

Please review our Privacy Notice and check the box below to consent to the use of Personal Data that you provide.
Consent*