Tag: service delivery automation

Pervasive Artificial Intelligence in Software: Trends & Impact on Outsourcing | Sherpas in Blue Shirts

September 30, 2015

One prediction I have made about the future of service delivery automation (SDA) is that increasingly enterprise software will have the technology embedded. This is particularly true of intelligent and cognitive type of tools. I expect these to become a common feature of enterprise software in the next 5-7 years.

We saw this kind of trend in the earlier days of business intelligence and reporting. The popularity of third-party tools saw the functionality built into enterprise software. As well as reports on activities, dashboards started to feature in applications giving instant views of what was going on in the enterprise. We do not have to look far to find such software today, for example, Blue Prism, includes analytics that report on operations and performance of its robots.

A current example of a more intelligent enterprise software is Oracle Policy Automation Cloud Service. This reads policies written in natural language. Then based on business rules and the policy, it decides what questions to ask the customer, performs eligibility checks, and produces a decision report.

Another example is HighSpot, an enterprise search tool that uses natural language processing for searches and machine learning for finding the most relevant information and ranking the results.

The availability of open source machine learning software libraries, such as Apache Mahout, and software tools from industry giants, such as Microsoft (Machine Learning Service on Azure), will accelerate the next generation of smarter enterprise software.

Some would say that intelligent enterprise software would be function-specific, but I believe some varieties will be able to do more than one thing within large software applications. The need for standardization of interfaces to these tools and the ability to interact with other intelligent applications will grow over time too. We could even see more automations crossing paths across workflows leading to more complex machine-based decision making.

The question is what impact will pervasive intelligence have on the outsourcing industry:

  • On the one hand, intelligent software will shrink the size of the workforce that is needed to fulfill many services and thus reducing the need for outsourcing
  • On the other, intelligent software will open up opportunities for outsourcing processes that have not been outsourced before:
    • These could be heavily document-centric processes, such as anything involving the administration and management of searching large volumes of content, for example, for legal discovery
    • The processes could also be the evolution of other processes. For example, in hospitals we might see the patient “meet-and-greet” services outsourced to service providers who can also run basic health checks supported by AI engines to produce first-pass health assessments, before the patient is ushered to see a doctor
  • Another outcome will be higher expectations of artificially intelligent outsourcing services; upping the ante for smarter outsourced processes – this is inevitable as those on the buy-side of the market become more and more accustomed to intelligent software.

Intelligent enterprise software is here. And we are on the brink of it becoming pervasive and commonplace. As it does, I’ll continue to share my insights on its evolution.

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

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

Avoid the “Gotchas” in Purchasing Next-Gen Tech Services | Sherpas in Blue Shirts

June 10, 2015

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

Changing technologies

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.

Photo credit: Flickr

The Dullest Business Process Could be a Winner in the Automation Contest | Sherpas in Blue Shirts

June 1, 2015

In my last post “The Automation Technology Starter Question,” I provided some guidelines on where to start on selecting business process automation technologies. In this post I cover the topic of what business process to automate when starting out on a Proof of Concept (PoC). This question is easier to answer for organizations that have specific requirements or pain points. Other organizations aiming to simply increase operational efficiency would have many more candidate processes. Whether your organization is in the first or the second group, the dullest of your dreariest business processes could be the winner of the automation contest. The difference between the two groups is the range of processes to choose from. The first group of organizations would have to find the process from among the known problem areas while the second group would need to do the same form a larger portfolio.

Definition of Dull

A dull process is highly repetitive – the sort that drives staff into a zombie state of mind on a daily basis leading to high attrition rates. This could include:

  • Simple but large data entry workloads such as order processing
  • More complex and still repetitive tasks such as those that involve checking a number of systems and updating the same pieces of data and status information in all of them, e.g. ,notifications of customer change of circumstance

The swivel chair is another good indicator for a process needing automation (if not deeper system integration) – when a crick in the neck from turning from one screen to another comes as part of the job.

Dull process examples

Most organizations have these, and I have no doubt that they will all be automated in the next few years. Examples include:

  • Processing of insurance information such as premium advice notes
  • Changing customers from one mobile/cell phone plan to another
  • Entering orders placed on the web into an order processing system.

Getting staff on-board

While the threat of job losses as a result of automation is real, there continues to be a shortage of skills and experience in many parts of the world. In many organizations, automation can enable staff to move upward or across to other and more interesting processes. Identifying opportunities for staff early will help to successfully implement change. Some of the most successful deployments include those that had their staff on-board from the beginning. These have seen automations become part of the team.

Again, when it comes to an automation PoC, let process dullness be your guide.

The Automation Technology Starter Question | Sherpas in Blue Shirts

May 13, 2015

A question that we are often asked about service delivery automation (SDA) is “What technology should we use to automate our business processes?” The answer to this, of course, depends on the organizations requirements and existing capabilities, but there are some basic and general rules that can help organizations get started on their automation journey.

Before that journey begins, to facilitate internal communication, it is very important for organizations to develop a common vocabulary for automation. For example, not every type of automation is robotic and not every robotic automation does screen scraping!

Everest Group’s first principles of SDA and definitions can help organization develop a unified vocabulary for automation:

  • SDA is utilization of technology to replace a series of human actions
  • Much automation is already embedded in software systems (e.g., linking customer information across finance and procurement functions), but since it is part of the normal feature-functionality of a system, it is generally not considered as automation, but rather simply a more powerful system(s)
  • SDA can refer to automation in IT infrastructure and application management services as well as business processes.

The focus of this post is SDA in business processes. A simple way of grouping automation tools for business processes is by the type of data or information that they can handle:

  • A subset of SDA is Robotic Process Automation (RPA). This refers to a group of tools that interact with computer-centric processes, typically, through the user interface and so can do away with the need for other types of integration with the underlying system:
    • RPA handles structured data, for example, taking data from electronic forms and entering them into databases. RPA software vendors include Automation Anywhere, Blue Prism and UiPath. The graphic below provides Everest Group’s definition for RPA.

KeyDefinition-RPA_amr

  • Another subset of SDA is a group of tools that we refer to as cognitive. These are intelligent tools that use machine learning to build a process-related knowledge-base to automate processes:
    • Cognitive tools typically handle unstructured data – Examples include Celaton’s inSTREAM and iPSoft’s Amelia.

If your organization is looking to automate traditional data entry processes, such as order processing, then a starting point is to look at RPA tools. If on the other hand, the process has to handle non-voice customer interactions such as emails, documents and multi-media and web content, then cognitive tools could provide the answer to your requirements. Examples include:

  • A telco that uses RPA for high volume transactions such as SIM swaps
  • A financial services company that uses RPA for processing of redemptions and asset migrations
  • An insurance loss adjuster that uses a cognitive tool for automating processing of in-coming customer documents including evidence for insurance claims.

Other aspects of automation technology to consider include but are not limited to:

  • Depth and breadth of functionality – for example a feature-rich automation development and testing environment
  • Integration capabilities – as well as integrating with departmental software such as finance, the tools may need to interact with enterprise software (e.g. Microsoft Exchange), business process management software (e.g. Appian, PegaSystems, Tibco) or document management software (e.g. IBM FileNet or OpenText)
  • Scalability and performance – ability to grow volumes of transactions as the need grows
  • Support for virtualization – for example in the user environment via Citrix
  • Deployment options – such as on premise or hosted by the vendor
  • Commercials – licensing models and prices
  • Support and maintenance options in your geography
  • Customer references and proven business cases.

Vendors are always happy to arrange demonstrations of their software. You could give them a test scenario to set up for and demonstrate. Some organizations have gone a step further and have run different proofs of concept in parallel to find the best solution for their requirements.

It is important to note that you are not limited to one type of automation:

  • Service delivery automation can be accomplished by combining multiple technologies. For example, traditional Business Process Management (BPM), workflow and document management technologies can be combined with newer UI/robotic process tools
  • Cognitive tools can be combined with RPA tools, which in turn can orchestrate tasks back and forth between workflow tools and people
  • The output of one process can also act as an automatic trigger for the next to start.
  • The entire process need not be fully automated – partial automation is also highly valuable and the most common approach.

In my next post, I will look at the types of processes that make good starting points for automation.

Everest Group publications on SDA include:

Photo credit: Flickr

Why Hasn’t Automation Made Much Progress in Services? | Sherpas in Blue Shirts

April 13, 2015

I hear people in the services industry asking why automation hasn’t taken off yet. Actually, as long as I’ve been in the industry since the 1980s, we’ve been working on automation. Back in 1983 we were talking about automating business processes and the elimination of most of the people in the services value chain. So why hasn’t it made an impact yet?

I think there are three primary reasons for this phenomenon.

First of all, we actually have made incremental steady progress in automation. It’s just that the number of processes turned over to third-party providers has grown exponentially at the same time. In this much larger set of services, it’s easy to miss the progress made in automation.

Second, when labor arbitrage came into the market, it was so much simpler and quicker to get a payback using that strategy. So it delayed progress in automation.

Third, the automation journey is really hard work because we’ve moved to a point where pockets of labor are connective tissue. And process components continually change (such as IT infrastructure or the F&A process). This rate of change overwhelms automated models. These changes require rethinking automation.

Moreover, the cost of automation is high.

The good news is we’re entering a new phase of automation that I believe will make significant progress. So what’s different now that will enable automation to move forward?

First, the time is right. The labor arbitrage model is mature and the industry is turning to new sources of value. So we’re going back to automation as a source of value.

Second, today’s tools are much easier to use and quicker to implement. Thus, the cost of automation is dropping very precipitously.

Finally, providers are starting to merge services with integrated platforms and put artificial intelligence into automated or robotic tools. This enables adapting to change much more rapidly and facilitates machines learning in a similar way as employees learn.

The net result? Although we are early in this next phase of automation, I believe we have hope of going further than before. The desire is strong, tools are better, and companies’ ability to adapt to change is much stronger than it was. This should allow us to dramatically raise the level of automation that services clients value.

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*