Moving To A Consumption-Based Model Is Essential To Deliver On The ITaaS Promise

**This is the first part of a three-part series about labor sourcing in the ITaaS business model**

You might wonder what moving our labor to a consumption-based model has to do with IT as a Service (ITaaS). The fact is a significant amount of our IT spend is made up of labor and these costs are then passed on to our business units in the form of invoices. Sourcing and contract strategies are essential to establishing our ability to effectively roll those costs into services and then back to the business units in the ITaaS business model.

Let me start by describing EMC IT’s effort to restructure its sourcing strategy. We wanted to move beyond “name-based” or “capacity-based” supply side sourcing, and move towards “unit based” supply side sourcing. In other words, rather than setting aside a specific IT employee or contractor to deliver services to a specific business group, we wanted to designate labor resources based on specific service requirements that can be leveraged for multiple business group needs.  The idea was to pool like skills that would allow us to scale and be more efficient.  Oh yeah, and we needed to do it cheaper while meeting and improving existing service levels.

When EMC IT committed to ITaaS, a key (and critical) objective was to improve the business relationship between IT and EMC business teams, by being able to communicate in terms of outcomes and not focus on regularly having to answer the labor allocation question, “what was John working on?” Our decision to further develop the ITaaS business model was also motivated by an underlying belief that there are always opportunities to improve efficiency.

In order to accomplish the objectives of better alignment with the business and driving efficiencies, we needed to think deeply and differently about the work that we do and how we measure labor sources.

The initial steps were daunting; how could we achieve better business relationships, and preserve quality outcomes, while driving cost improvements? We already had more than 60 percent of our workforce in low cost regions. What else could we do? Move more work off shore? Not likely.

We first had to start by analyzing the work that we were delivering. In a measured and consistent way, we needed to clearly define the types of work that were being provided and then normalize the effort into; what is a “unit of work?”

The two general types of work being delivered by IT today are referred to as Production Support (PS) and Continuous Improvements (CI). PS occurs when there is an issue with an IT asset that needs to be resolved by the technical staff within Service Delivery Group (SDG) soon to be the Service Operations Group. CI occurs when a business unit has approved incremental development work to be performed on their behalf on an IT asset that supports their business.


Today, we measure these types of IT work through units of work. We measure PS using “tickets,” requests logged by the business to address IT issues. We measure CI using a Weighted Work Request (WWR). A WWR is a normalized unit of measure on the level of effort required to perform a set of development activities. Here is a chart that might help you to better understand the WWR model.

Work Requests will be categorized based on the estimated effort , as per the following table:

Click to Enlarge
Click to Enlarge

By establishing a per unit way to measure work (i.e. ticket or WWR), we could then established unit pricing for IT support services—the goal now being to share back with the business their consumption of units of service tied to unit pricing. This helps to move the conversation away from “what’s Anne working on” to “what is the quality of service we’re receiving”, turning the dial up or down on consumption, etc.

All of these benefits support our mission to transform the IT Business model to an ITaaS Model in which consumers of IT have greater transparency and choice of the services they consume from IT.

In my next blog, I will describe how we gained workforce efficiencies by pooling together technical professionals with similar skills and in a future blog I’ll review actual benefits that we are seeing as a result of these changes, as well as some challenges we are facing.

About the Author: Neil Thibodeau