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.
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.
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.
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:
As outsourcing markets mature, traditional cost levers become increasingly less effective, driving enterprises to seek alternative sources of cost savings. RPA is filling that void, promising a new wave of cost savings, particularly in FAO’s transactional and FTE-intensive processes.
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.
Increasing use of automation and digital channels across all banking lines of business reduces FTEs needed for transaction-based activities. Service providers are capitalizing on those opportunities to move up the value chain to deliver more complex services.
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.
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.
The new technologies sweeping the market hold great promise of competitive advantages. But there’s a disturbing trend occurring in the services sales process for these technologies that poses a risk for buyers. Look out for providers talking about cloud, mobility, big data, the Internet of Things, and social in the same breath as SaaS/BPaas, automation, robotics, and artificial intelligence. Providers that jumble these technologies together as though they are homogeneous really don’t understand the implications of what they’re trying to sell you. They’re basically throwing mud against your wall and seeing what sticks.
The possibilities with all of these technologies are exciting, but they have distinctly different impacts on the buyer’s business.
As illustrated in the diagram below, we can bucket one class of impacts as those that create new business opportunities. They provide new types of services that enterprises can use to change the composition of their customers or provide different kinds of services. For example, the Internet of Things holds enormous promise around allowing enterprises to provide a completely different class of services to their customers. In mobility and social technologies, the digital revolution holds the promise of changing the way businesses interact with their end customers.
Changing technology opens up new opportunities but also creates strategic challenges
The second class of new technologies (Saas/BPaaS, automation, robotics, and artificial intelligence) changes how services are delivered. For example, SaaS takes a functionality that was available but delivers it through a different mechanism. Automation and robotics changes the way service is provided by shifting from FTE-based models into an automated machine-based delivery vehicle.
The two buckets of technologies have different value propositions. The first class of technologies (cloud, mobility, big data, IoT, and social) are about getting new and different functionality. The impacts in the second class are lower costs and improved flexibility and agility. Each class of technologies has different objectives and value propositions and thus needs a different kind of business case. Buyers that mix these technologies together in a business case do themselves substantial disservice.
The way you need to evaluate the two distinct types of technologies (and providers offering them) is completely different. A provider that recognizes that automation, robotics, and SaaS are about changing the nature of delivery will have a much more thoughtful conversation with you and build its value proposition around flexibility, speed, and quality of service and cost.
A provider that recognizes the impact of mobility, cloud, big data, and the IoT technologies will talk to you about a value proposition around standing up exciting new capabilities, creating new offers and changing the conversation with your end customers.
So, buyer beware. If you’re talking with a provider that mixes these technologies’ distinct value propositions together, you’re dealing with a provider that really doesn’t understand what they’re offering.