Tag: robotics

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 Future of IBM’s Watson and Cognitive Computing | Sherpas in Blue Shirts

June 2, 2015

I had the privilege of being at IBM and seeing first hand Watson working on powerful use cases. I must say, even now after a few days of reflecting on it, I think I’m even more impressed with its power and capability than when I was at IBM and saw Watson in use. If, like me, you spend two hours with Watson, you will get a glimpse at our future. It’s highly likely that within five to 10 years all of us will use some kind of cognitive computing to assist us in our daily lives. But I believe there is a major challenge.

Just a quick refresh: Watson is cognitive computing, a form of artificial intelligence. Previously I did not understand the way it will be deployed; it will augment human decision making, not replace people. That’s not to say that an individual assisted by Watson won’t be able to do the work of many more individuals. At least at this stage of development cognitive computing makes humans more capable and smarter.

For example, I saw Watson working as a companion to an oncology doctor, helping him perform more thorough diagnostics. In the situation I observed, the oncologist was able to cut the diagnosis and testing process from six days down to two hours. That doctor was far more effective because Watson can explore many more options and present hypotheses and data to the doctor and medical team than they could have explored on their own (plus it would have taken far more time for them to do it). In addition, it’s not hard to believe that the team would be more likely to do a better diagnostic with Watson as companion than they could achieve through traditional techniques.

With all that being said, I think Big Blue faces a major challenge with Watson at the moment: Watson is a solution looking for a problem.

As I understand it, IBM invested over a billion dollars in Watson’s development. On TV we saw Watson defeat a chess Grandmaster and then win on “Jeopardy.” However, now Watson needs to make the journey to operate in the real world of business problems.

These use cases and applications are still undefined and will emerge over time. It is, in fact, the challenge of problem definition and incremental adoption that stands in the way of progress. It’s easy to imagine that there are limitless applications for Watson; but for Watson to take off quickly, we need to identify big issues with large payoffs. Without these game-changing applications we will wait for several years for cogitative computing to make the contribution that it is clearly capable of.

To recover its billion-dollar investment and create a market for cognitive computing, IBM has every incentive to hasten the adoption. However, it has yet to identify the break-through problems that will drive rapid adoption. It is all very well to believe that the power of the technology will inevitably drive adoption; but if cognitive computing is like other disruptive technologies, it will come slowly and in spurts.

Where does cognitive computing fit?

To hasten adoption, my best – and unsolicited – advice to IBM is to identify big business problems where Watson can make a structural change and drive massive benefits. Clearly, working as a companion to oncologists is such an area. And given that healthcare is 20 percent of the U.S. GDP that alone may be worth the journey.

But for enterprises beyond healthcare, I feel challenged as to what other big structural changes Watson and cognitive computing could provide.

I strongly suggest that you find a way to experience Watson’s power. It’s is so powerful that I, like IBM, am struggling with where we should take it.

As I’ve pondered its possibilities, I think underwriting and the claims process in the insurance sector holds tremendous opportunities. And within IT, I think the service desk and problem solving that IT departments contend with could be dramatically enhanced with this technology. With a cognitive computing tool as their companion, they could deliver a higher quality of service and greatly improve productivity. Clearly the area of security would benefit substantially as we find ways to keep the black hats out of our data.

I’m very interested in other points of view as to where we can put cognitive computing to work, so please add your comment below.

Photo credit: Wikipedia

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.

Quick Takes on Robotic Automation | Sherpas in Blue Shirts

April 7, 2015

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

Infosys’ New Strategy Connects all the Dots | Sherpas in Blue Shirts

March 31, 2015

I recently had a chance to sit down with Infosys’ CEO and his team, and they shared with me their new/renew strategy. From what I understand, it resonates with where the market is heading. This is remarkable as it addresses the vexing problems and risks service providers now face in trying to change their business to address new models, new technologies and new customer expectations. It is always easy to drink the Kool-Aid, and I am definitely experiencing a sugar high. However, the Infosys strategy is one to watch as it appears to connect all the dots in a quickly evolving marketplace.

There are a number of things I find attractive about this new/renew strategy. First is the simplicity of its messaging. It’s easy to understand where they’re coming from and that they are focusing on their customers, not on Infosys like their past strategies. That in itself is powerful for customers’ understanding of what Infosys stands for and where they are heading. And it’s also powerful for the Infosys team to be able to understand what to focus on and what not to focus on. That resonates.

The new aspect

Second, I find the direction compelling. Clearly there is much in the market that is new. New technologies and new business models are driving the market and, when combined, are extremely powerful.

Digital changes how companies interact with their customers, and there’s nothing more powerful than that. Cloud changes the speed and agility and price at which companies can move. The consumption-based and as-a-service models allow companies to align services closely with business outcomes and only pay for services as they consume them. Taken together, these new technologies and business models are very relevant to where customers are headed with their business, and these new areas are capturing the growth in the services segment.

Infosys aligning itself with this direction makes perfect sense as they move to redesign their growth and maintain their leadership position in the services industry.

The renew aspect 

This aspect of Infy’s strategy is equally powerful. There is a second set of technologies that allows providers to change the way they deliver services. I’ve blogged often about four of these technologies: automation, analytics, robotics and artificial intelligence. Providers such as Infosys are looking to harness these technologies transform their environment, lowering costs and making their existing services far more responsive than they’ve been before.

Customers are more demanding

So Infosys is tapping into the big themes in the marketplace. They’re leveraging new technologies and new models to connect the dots to new opportunities for growth. And they’re renewing their existing business by harnessing new technologies and capabilities to optimize their service delivery.

Underpinning the strategy is a sea shift in customer expectations. Enterprises are increasingly more demanding of their existing services and at the same time impatient to take advantage of new technologies and business models.

I like Infy’s new/renew strategy because I believe it is directly in concert with where we at Everest Group see the market moving – taking advantage of new technologies and rethinking how to optimize existing services. And it embraces the “old wine in old wineskins” concept I recently blogged about.

I think this strategy will position Infosys well. A word of caution: as an often-quoted lines goes, “Execution eats strategy for breakfast.” So we look forward to seeing how they execute in this marketplace.

Photo credit: Flickr

Big Bad Wolf Coming to Huff and Puff and Blow Down Providers’ Houses | Sherpas in Blue Shirts

March 11, 2015

At Everest Group, we researched the potential effect of robotics and automation on the F&A services space. The outcome is almost as grim as the Grimm’s Fairy Tale of a fictional wolf huffing and blowing down the three little pigs’ houses. Where companies implement robotics into finance and accounting functions, we see a reduction of 25-40 percent of the FTEs by the time the implementation is complete.

Some service providers are scared – and rightfully so if our data holds – about the industry turning in a significant way to robotics and automation.

Like the big bad wolf blowing down the first pig’s straw house then moving to the next pig’s wood house, automation and its impact will come in waves. The first wave, as providers move away from an FTE-based model to a transaction-based model, will result in 25-40 percent FTE reduction, with the next two waves in increments of 10-15 percent each. Making the situation for providers even worse, clients will expect their providers to share the cost benefits of automation with clients, which will cause further revenue compression. For service providers, the shift to robotics and automation is a horror story right out of Grimm’s Fairy Tales.

But in the children’s tale, the third pig built a house of brick that the wolf couldn’t blow down. The good news is there is time for providers to build brick houses.

Here’s the blueprint for building a service provider brick house: Build a transaction-based model rather than an FTE-based model and use the savings from that to expand into new areas. This will create a growth engine that can offset the revenue decline in the shift from FTEs to automation.

It’s clear at this point in time that existing F&A clients aren’t lining up to drive automation schedules … but they will over time. The big bad wolf is coming, but providers have time to build a brick house, and they can use their existing client foundation to do that.

Just don’t wait and get caught in a straw house when the big bad wolf arrives.

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*