Tag: SDA

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

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:

Wipro Commits to Service Delivery Automation | Sherpas in Blue Shirts

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

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

The Automation Technology Starter Question | Sherpas in Blue Shirts

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

Quick Takes on Robotic Automation | Sherpas in Blue Shirts

Since the start of 2015, we have had the opportunity to speak with a wide range of old friends, new acquaintances, and industry contacts – and spanning across enterprises, services providers, technology providers, academics, and consultants. Almost without fail, the topic of robot process automation (RPA) comes up. Most of the discussion aligns with the thinking in our report from last October (Service Delivery Automation (SDA) Market in 2014 – Moving Business Process Services Beyond Labor Arbitrage), but some goes deeper and adds fresh new colors.

In this blog we offer a quick summary of recent observations from these dialogues. Although these points are an amalgamation of many conversations, a few bear mentioning specifically. Mihir Shukla (CEO of Automation Anywhere), Lee Coulter (CEO of Ascension Health Shared Services), and Gianni Giacomelli (SVP Product Innovation/CMO at Genpact) debated the trends in disruptive technologies, particularly automation, at a recent SSOW event in Orlando. Additionally, Matt Smith and Dan Hudson – formerly leading Virtual Operations North America, now in Cognizant’s RPA group – spent some time explaining how their views have evolved as they have gone from advising service providers to actually working for a provider. We also spent time speaking with a number of enterprises with process improvement programs that are utilizing robotic process automation, plus conducted a recent webinar with Telefónica about automation.

Viability of RPA

  • RPA is a “no regrets” move that essentially guarantees results. Beyond the somewhat obvious fact that it can generally deliver savings quickly, it is also flexible. Unlike many decisions in global services, the approach, priorities, and tactics can all evolve fairly rapidly without having to take major steps back because the automation routines are not fixed and are designed to be changed. In this way, it is closer to how small applications outsourcing projects are simple compared to large infrastructure agreements with multi-year terms, which are complex and hard to reverse transitions, etc.
  • For automation-friendly processes of 8 or more FTEs, 40% savings is a reasonable expectation. Sometimes it is less but can also often be more. As a result, ROIs of new initiatives are measured in quarters, not years.
  • Although the cost savings is nice, the predictability and rigor from automating complex, but rules-based processes can add tremendous value. It makes knowing that operations are under control much easier. Plus, the benefits of reduced errors and delays can be a huge positive–truly value beyond cost savings.

Rate of adoption of RPA

  • Although initial processes can be implemented in several months or quarters, it requires two to three years to implement and reach significant penetration of processes across an organization.
  • There is a surprising degree of organizational inertia to not look seriously at RPA or go slowly. As a result, our view is that it will take five years to penetrate most of the market – despite being a fairly simple, almost no-brainer approach.
  • As an illustration of the pace of adoption, consider the exhibit below from our recent webinar on service delivery automation. RPA is making inroads into FAO renewals and new deals. However, notice that only 12-28% of recent deals are including RPA. Given that most of those are 4-5 year terms plus others immediately preceding them had even lower rates of RPA inclusion, this means that 3-5 years from now deals signed without RPA will be coming up for renewal…and it will still be the majority of the deals hitting the market without RPA. Once we see the deals per year with RPA cross 50%, the rate of change in the market will be noticeably faster. The wildcard, of course, is how many of the deals being signed now without RPA will be restructured during the term of the deal to include it – this will happen, but the rate is not yet clear.

RPA adoption

Technology models for automation

  • No single tool can do everything and it is a matter of building the right portfolio of options. Further, even if a tool tried to do everything, the market would likely be reluctant to select it due to fear of lock-in.
  • Interestingly, we are seeing more proprietary tools by service providers coming into play. This is not to say that the commercially available tools aren’t effective – they are, but rather that providers are experimenting with making their own investments to avoid licenses fees and to create the operating model they desire. In fact, there is a general feeling that some of the proprietary tools have functionality not found in the commercials tools (and vice versa), such that we may be entering an arms-race for innovation in automation tools. Might this even lead to service providers being willing to license their proprietary tools without also providing accompanying services? Time will tell, but this would seem to be a compelling way to attract and retain clients with a differentiated offering while spreading investments across a larger base of users.
  • At this point, those organizations electing to utilize outsourcing appear largely comfortable allowing their service provider to select and provide the relevant tools (results-oriented mindset). Those enterprises wanting to select their own tools, tend to shy away from an outsourcing model anyway.

In case you missed it, we recently released some additional information on automation and technology in business process services:


Photo credit: Flickr

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.