Tag: consumption-based

Slack and the Future of Enterprise IT | Sherpas in Blue Shirts

Unless you’ve been living under a rock, you would have heard of Slack. It is not another enterprise collaboration application. It merely aims to redefine how organizational communication takes place and upstage this little thing called email. As far as start-ups go, the company has witnessed a meteoric rise. In its most recent round of funding in April 2016, it raised US$200 million at a post-money valuation of US$3.8 billion (with an annual recurring revenue of US$64 million last year), which is all the more impressive when you consider that it launched just three years ago and has raised almost US$540 million. An incredible amount of money at a time when VCs are supposedly tightening the screws and we are witnessing a ‘correction’ in the investment climate. To Slack’s credit, it has built an incredibly popular platform. In May, it reached a significant milestone when it announced three million Daily Active Users (DAUs; a much revered metric of app usage vs just installs) and two million connected users. It has grown at breakneck speed – less than a year ago, it had one million DAUs, and in October 2015, one million connected users.

The changing face of enterprise IT

Slack is built on the premise of seamless communication in an increasingly complex enterprise world across platforms, teams, and applications. It has 430 employees and counts NASA, CNN, LinkedIn, Harvard, McKesson, Ogilvy, and Spotify as enterprise customers. Slack represents the true vision of what is often referred to as “consumerization of IT”. It refers to the confluence of consumer imperatives such as seamless user experience (UX), BYOD/CYOD convenience, and boundaryless communication within an enterprise IT framework. Digital technologies are reshaping the workplace of the future while enterprise applications tend to be stuck in a bygone era. Slack, and its ilk, aim to redefine this paradigm. Slack, in particular, aims to make messaging the primary form of communication among co-workers. As an illustration, they can place documents saved in Dropbox into their chat streams, collaborate on revisions and assign tasks without leaving Slack, and search previous conversations and files. It also has fully native apps on iOS and Android with syncing across devices.

This is a far cry from current legacy enterprise collaboration applications, which have seen their fair share of experiments. The most high-profile one was probably Yammer, which was sold to Microsoft in 2012 for US$1.2 billion. One primary reason why Yammer has not scaled as hoped is that it still operates as a separate tool from the rest of the enterprise workflow, much like the IM tools that came before it, which also fall short of meeting the requirements of digital enterprises. Microsoft has tried to salvage its Skype bet with the integration of Lync (now Skype for Business), but the jury is still out on it.

Peers of Slack (Campfire, HipChat, Skype) can copy its core features, but the implications of its network effect and ecosystem of integrated apps/chatbots are quite profound. It meaningfully differentiates on the basis of its pricing models as well. While other SaaS providers typically charge on a per-user basis (regardless of how many users actively use the software), Slack tweaks this to activity-linked pricing. For example, with other applications, if you buy 1,000 seats but only use 100, you still get charged for 1,000. Slack, on the other hand, will charge on the basis of how much it is actually used (say number of messages exchanged).

Challenges and the road ahead

That’s not to say Slack is not facing intrinsic issues. The enterprise version of the software was initially delayed and there are reports that ride-hailing company Uber dropped Slack because it couldn’t handle the number of communications it required. Scaling from micro-teams to coordinate multiple Slacks in a large organization has been a problem. As Slack aims to replace email as the standard of organizational communication, there is a very likely danger that it might end up having the same problems that have made modern-day communications so tedious and sub-optimal. Execution will be a key area of scrutiny. There are very few industries where companies experience this type of hyper growth, especially on the enterprise IT space, so managing the pitfalls become all the more tough.

To Slack’s credit it has not displayed a lack of ambition when it comes to pivoting its future, which clearly needs to be a platform-based play for any meaningful and scalable business model to emerge. The goal now will be to turn its software into a platform that integrates with other software so that a user can accomplish all enterprise objectives inside the ecosystem and thereby create stickiness. To further this ambition, Slack announced an US$80 million investment fund in December for developers to build apps that integrate with the platform. Right now, the Slack Platform consists of a new Slack App Directory (with ~160 apps), a Slack Fund (to invest in new apps), and Botkit (a new framework to easily build new apps). As Slack scales up its aim to be a ubiquitous SaaS ecosystem, it can unlock a significant opportunity by becoming the identity layer of the enterprise. This is similar to the intent Microsoft is driving toward with the US$26.2 billion acquisition of LinkedIn. Ultimately, if Slack’s platform picks up, it can drive other services such as single login and identity access, effectively serving as the singular identity provider for an employee across the enterprise ecosystem. Slack has the momentum and intent on its side to redefine the enterprise application paradigm, and it’s hard to see anyone else (apart from Microsoft) having a bigger opportunity to succeed.

Automated Services Need a New Licensing Structure | Sherpas in Blue Shirts

Service Delivery Automation (SDA) encompasses cognitive computing as well as RPA (robotic process automation). Software providers that provide SDA come to market with an enterprise licensing structure that basically requires the customer to license a number of agents for a specific length of time. But in using this licensing model, service providers unintentionally constrain adoption and open the door for competitors’ differentiation.

The problem is that many of the uses for SDA are cases where companies need variable amounts of agents and computers. For example, the client may have a million transactions to process. So it could buy a license for one agent to run through those transactions in a week; but to reduce cycle time requires buying the license for 10,000 virtual agents for one hour. At Everest Group, we clearly see clients becoming frustrated with this lack of licensing flexibility.

This situation calls for a consumption-based approach to SDA in which the customer pays the software provider handsomely, but the provider doesn’t constrain or force unnatural motions on its customers and doesn’t create unnecessary cycle-time issues.

This blog is a call to service providers to come up with a consumption-based pricing model for SDA services. I’m not advocating that providers give away their software or take less money for it. I am saying that the current pricing structure inhibits adoption and is a constraint on the growth of the industry. Employing a consumption-based pricing model doesn’t mean that the client won’t pay a fair compensation or that the provider won’t be profitable. To achieve this, providers need to create some kind of metering vehicle in which time or activities are metered and they need to link their pricing to this meter.


Photo credit: Flickr

Demand Management Is Made Possible through as-a-Service Model | Sherpas in Blue Shirts

Demand management has been the unicorn of enterprise IT – something frequently talked about but rarely seen and never captured. Every centralized IT organization would love the ability to accurately manage user demand. It would provide tremendous return if it were possible; but to date it has been largely or completely thwarted in large enterprise IT organizations. But there’s good news, thanks to the as-a-service model.

The reason demand management has been thwarted is that IT is organized on a functional basis; the data center, servers, network, purchasing, and security app development and maintenance are all defined functionally. IT leaders are held responsible for driving out cost and building capability that is shared by multiple departments. The problem is there is no relationship between demand and supply capability because business users don’t understand how to measure their usage/demand.

When IT asks business users how many servers they you use, their response is often “How many did we use last time?” Or when IT asks how many programmers will you use and why, business user typically respond with “We need 10 percent more than we had last time.” There is no relationship between actual demand and the actual demand drivers and the estimates they must provide to IT. This is a hopeless and fruitless exercise. It’s like a broken clock that is right only twice a day. This demand estimate is doomed to be wrong every day.

So what’s the answer? We need a service construct where IT is organized into service models. This construct gives business users a way to understand their usage or demand. For example, a healthcare payer understands how many people it expects to enroll. This is a metric the business can use to predict usage and the time frame in which they will need the service. IT can then manage the demand for the service it provides to the payer based on the number of enrollments.

When companies organize IT along service lines, they can translate business activities into technical consumption. The as-a-service construct attempts to make as much of its service chain or supply chain as elastic as possible. It adjusts each part of the supply chain to the usage demand. So unlike the traditional functional IT structure, business users only pay for what they use.

There are three mechanisms to make a technology or service elastic:

  • Share it (such as AWS); when you’re not using it, someone else is
  • Automate it; spin it up, do the work, and shut it down
  • Buy it on a consumption basis

Typically, as-a-service providers use all three of these techniques to allow them to use their full service stack with the business metrics that the technique serves.

The as-a-service model achieves one of the Holy Grails of centralized IT – it provides a realistic demand management vehicle where the business can make accurate estimates. It also provides paying for the services only when they are used; this is the consumption-based model that the services industry is moving to.

Demand management to date has been completely illusive to centralized IT because of the take-or-pay nature of IT. This method for building capability – and business users sharing the cost to be able to use it – has no connection to business metrics that the business can control and understand how to estimate their technology capacity/demand. But the good news is the as-a-service model puts a rope around the unicorn. It creates the ultimate answer to demand management.

Health Net – Centene Merger Leaves a (Slightly) Bitter Pill for Cognizant | Sherpas in Blue Shirts

On July 2, managed healthcare companies Centene and Health Net announced a merger in a cash-and-stock deal valued at US$6.8 billion, becoming the latest deal in an intensifying wave of consolidation in healthcare. The agreement has been approved by both companies’ Board of Directors and is expected to close in early 2016. The deal combines the two companies, with the joint entity having more than 10 million members and an estimated US$37 billion in revenue this year. The large-scale reform of US healthcare (instigated by the Affordable Care Act) was never expected to be a smooth and genteel affair. One of the immediate impacts was provider consolidation as health systems (which had endemic cost and profitability issues) looked for scale, efficiency, and lean cost structures. A similar trend was also expected in the payer space, but the rollout of the Health Insurance Exchanges (HIX), which operationalized last year, delayed the eventual M&A frenzy. Last month, America’s numero uno insurer, UnitedHealth Group (UHG), approached the number three, Aetna. The latter responded by buying number four, Humana, for $37 billion on July 3, capping a seminal week for mega mergers in health insurance. Humana was earlier reported to be close to a similar deal with Cigna. The second largest, Anthem, is in the midst of a messy takeover attempt as it relentlessly pursues the number five, Cigna (which rejected an initial US$47.5 billion bid). We covered the potential impact of the potential UHG-Aetna and Anthem-Cigna deals on IT services in a blog soon after the first rumors started floating.

Collateral damage – the Cognizant story

The announcement comes at an extremely inopportune time for Cognizant. The company had announced (with much fanfare) a marquee seven-year US$2.7 billion deal with Health Net last August. The engagement was unique in multiple ways. Along with Accenture’s Rio Tinto deal, it is the flag bearer of a bold new deal construct, which epitomizes the fundamental tenets of the As-a-Service economy and widely expected to herald the era of a consumption-based IT services model. Under the terms of the seven-year master services agreement (MSA), Cognizant was to provide a wide gamut of services to Health Net across consulting, technology, and administrative areas spanning claims management, membership and benefits configuration, customer contact center services, information technology, QA, appeals & grievances, and medical management support. Cognizant was to be held responsible for meeting specific SLA targets for improving the quality, effectiveness, and efficiency of multiple operating metrics. These included claims processing and routing times, customer contact center response times, and contact center customer satisfaction targets. In effect, a fairly wide ranging set of services with ambitious KPIs for accountability and governance.

The planned implementation was scheduled to begin in mid-2015. Given the Centene-Health Net deal, the implementation is being deferred, while the deal is completed pending the merger review and approval process. As a result, Cognizant does not expect any contribution (previously pegged at about US$100 million in H2 CY2015) from the deal, which the company can easily absorb without tempering its ambitious revenue guidance for the current financial year. Additionally, it also foresees that if the merger is completed, the existing MSA is not likely to be implemented, which (if it materializes) will be a major setback. Cognizant will still remain a strategic technology/operations partner to Health Net (under a prior contract) through 2020 with a total contract value (TCV) of about US$520 million. Cognizant has also negotiated the right to license certain Health Net IP for use in its solutions and “As-a-Service”platforms, which is not expected to be impacted by the proposed merger.

Looking ahead, despite the short-term loss of US$100 million incremental revenue, Cognizant’s CFO Karen McLoughlin has reaffirmed 2015 guidance as strength in other areas of the business are expected to offset the lost revenue. 2015 revenue is expected to be at least US$12.24 billion with non-GAAP EPS at least US$2.93. Overall, the contract was expected to be margin dilutive in the early years and in generally only “margin neutral over the long run.

Lessons for the services world 

As overall macroeconomic confidence is on the upswing and various industry drivers come into play, the M&A activity is only bound to intensify. This has a profound implication for service providers who are deeply entrenched in such large enterprises and need to be prepared to come out on top of any eventuality. One potential impact of such M&A is the tendency for the combined entity to rationalize its vendor portfolio – choosing to stick to a short list of key strategic vendors by trimming the sourcing pie. The selection criteria for vendors then boils down to specific value-differentiators, maturity of service portfolio, senior management relationships, competitive positioning, and account-level exposure. Technology/operations budgets also tend to shrink as enterprises leverage economy of scale and target operational efficiency.

The following image illustrates the current exposure of key service providers across UHG, Aetna, Anthem, and Cigna. As is evident, these mergers tend to benefit larger service providers that are typically well entrenched across the combining firms. However, a few, may find their portfolios at-risk given competitive underpinnings, sourcing maturity, and enterprise penetration.

Account-level exposure of key service providers

Net-net, we don’t expect Cognizant to be unduly impacted by the proposed merger given the current state of affairs and its leading position in the healthcare and life sciences landscape (poised to reach US$4 billion in annual revenue in the next 18 months). The opportunity at hand is not under threat but there will be significant shifts and redistribution between vendors. The healthcare market is poised to witness increased turbulence (we believe this is just a teaser of things to come) and service providers need to realign and reposition themselves to utilize this opportunity. Let the games begin!

Groundbreaking Rio Tinto and Accenture As-a-Service IT Deal | Sherpas in Blue Shirts

Rio Tinto, a global diversified mining company, recently announced a groundbreaking initiative they are undertaking with Accenture. This can best be described as moving Rio Tinto’s enterprise IT function into an as-a-service model. Game-changing benefits permeate this deal, and it’s an eye-opener for enterprises in all industries.

Let’s look at what Rio Tinto gains by pulling the as-a-service lever to achieve greater value in its IT services.

First, it changes the relationship between the business and IT. It breaks down the functional silos of a traditional centralized IT organization and aligns each service. In doing so, it creates an end-to-end relationship in each service, whether it be SAP, collaboration or any other functional services.

Second, this initiative moves Rio Tinto’s entire IT supply chain to a consumption-based model. This is incredibly important for a cyclical commodity industry, where revenues are subject to the world commodity markets. Rio Tinto’s core product, iron ore, is a commodity that can result in revenues slashed in half in the course of a year, leading to the need for cost reduction initiatives. Correspondingly, in boom times, commodities can double and triple in price, resulting in frenetic energy to expand production. The as-a-service model ends this commodity whiplash impact. It gives Rio Tinto a powerful ability to match costs to their variable consumption patterns.

This move will change the pace of innovation within Rio Tinto, allowing it to future proof its investments in IT. As many enterprises discover, multi-year IT projects often end up being out of date by the time they are implemented. Rio Tinto sought to shorten the IT cycle time so it can take full advantage of innovations the market generates. In the as-a-service model, it can pull those innovations through to the business quickly – which is a struggle for traditional siloed centralized IT functions.

These are game-changing benefits. It’s important to recognize that the journey to capture these benefits required a complete rethinking of how Rio Tinto’s IT (applications and infrastructure) is conceived, planned, delivered, and maintained. Moving from a siloed take-or-pay model to an integrated consumption-based model required wide-ranging re-envisioning and reshaping the ecosystem for deploying its technology; it touched IT talent, philosophies, processes, policies, vendors, and partners.

Clearly this journey will be well worth the effort given the substantial game-changing benefits. Challenging times call for breakthrough answers. The cost benefits alone are significant; but even more important is the ability of this approach to accelerate the transformation of the company into a more digital business. Rio Tinto chose to partner with Accenture to move its organization to this fundamentally different action plan for delivering and consuming IT and meeting the rapidly evolving needs of the business.


Photo credit: Rio Tinto

Have a question?

Please let us know how we can help you.

Contact us

Email us

How can we engage?

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