Third blog in a three-part series on labor sourcing
In my previous two blogs about labor allocation, I talked about how EMC IT’s move to an IT as a Service business model required us to redefine our sourcing strategy. I described our transition to a variable consumption model, how we are gaining efficiencies from labor pooling and continuous improvement activities. In my final labor sourcing blog, I will explore how we applied this strategy to Production Support Services.
As noted in my second blog, using EMC IT’s new variable consumption-based labor model for Production Support Services (PS) is a bit trickier than for other types of service delivery in that it’s a non-discretionary spend and is usually a reaction to when something is broken. It does, however, still offer plenty of potential for increased efficiencies.
Production Support Services are measured by the number of “tickets” IT issues. Tickets are the means by which we track business unit requests to resolve issues with IT assets. Because they are logged with each problem that customers report and seek help on, tickets are completely variable. Since most tickets involve issues that need to be resolved in a specific amount of time (SLA), you could get into trouble in a pay-per-unit-of-work contract model. In other words, you will pay for all tickets generated for an application since it’s non-discretionary. Since the demand is not typically within the control of the customer, it puts a lot of pressure on IT to understand the drivers behind the ticket volumes.
Before establishing the variable consumption model for PS we had to establish a ticket baseline. Here’s where you really need to know your business and have good data to back your assumptions. If you are confident that you have good history to support a baseline—an average number of tickets by business unit over a six-month period—you can feel good that the costs will average out over the same period of time. This was important for EMC because the business units’ financial controllers had become accustomed to a somewhat fixed forecast for this type of service.
At EMC IT, we do track the number of tickets associated with each application. And soon we will share that level of detail with our users as part of their monthly invoices for IT services under our IT as a Service business model.
Now here‘s where the power comes in. Billing the business units per ticket for their Production Support Services will enable and motivate them to more closely review their ticket costs, keeping in mind that one of the objectives in sharing an invoice with the business units is to help them understand what levers they may have to reduce costs. While some ticket volume volatility is to be expected from month to month, this new invoicing system lets business units monitor and potentially act on significant variations. For example, if there was a spike in a given month and that translated into an additional expense of say $20,000 over the previous month, the business user would be aware of it and could pursue an explanation and maybe a remedy to prevent future spikes.
Let’s assume that the cause of the ticket growth in a given month was a new product release. History might show that this typically happens, but now there’s a “cost” associated with it. That makes people want to know more about it. Now I know that every group may operate a bit differently, but I’ve been here long enough to know that there is always more work to be done than one can usually manage. I’m not suggesting that people wouldn’t care that ticket volume might have shot up in a particular month because they would. They’d want to resolve all the issues and close them. But how many people go back and look at the true root cause for such a spike in tickets? Let’s be real. Most of us are off to the next release or the next problem to solve. We work on the things that we will be measured against.
To this end, EMC has recently created a group to do just this, Service Operations. Service Operations team members manage the “run” of all our solutions. As part of their responsibility they look at our production support processes and one focus area is on ticket reductions.
By implementing this model and associated costs to ticket volumes, folks will focus more on helping to control it better. Trust me, they’ll have to. The business will demand it.
This new level of control of PS costs—along with unit-based approach to labor allocation and the pooling of EMC technical professionals and contract professionals in Technical Competency Centers (TCCs) for more efficient labor allocation described in my previous two blogs—offers increased efficiency, flexibility and transparency across our consumption-based labor model.
So what is the down side to all of this? Well I have a couple of perspectives. From an operations standpoint, this new model requires us to manage our business and processes at a much more granular level. We need tighter controls and the associated good business intelligence. We need tools and process that provide that capability. We now have to measure all the ticket processing, who’s working them, who should be paid for closing them, tracking root-cause analysis, etc.
In the Continuous Improvement (CI) space (incremental development work performed on a user’s behalf on an IT asset that supports their business), it’s about being able to capture the Work Requests and all the details necessary for a provider to take on that work. Oh, by the way the provider can be a managed service provider or an EMC employee from one of the TCCs. We need to standardize the demand and supply processes.
A challenge we have is ensuring streamlined processes in the assignment of work. How do we automate all of this? We need to make sure we have a smooth invoicing process. How do we tie this new model into our Financial Transparency work? We’ve changed the model by no longer requiring our managed service providers in the “per drink” (pay for units consumed) model to enter time in PlanIT (EMC’s tool for capturing labor effort). Why should they? No value add. We’re paying for units of work not bodies. This will certainly improve our time tracking compliance J
Another area of impact has to do with plain old business change management. It is critical that we educate our other internal IT teams on how to operate in this new model. We also need to provide tools and talking points to our business-facing team to be able to communicate to the business how this model is changing and what the benefits will be. We all need to be marching down this path over the next few months. We’ve already begun to charge back costs to the businesses based upon the consumption of unit-based work (Tickets and CI) for the managed service teams.
I see this model evolving where our badged employees in the TCC can be measured the same way—namely a unit-based consumption model where we cross-charge the business for tickets and CIs. Wouldn’t it be nice not to have to figure out who’s in what cost center, charge-back or non-charge back? Wouldn’t that simplify things for everyone? Won’t it be nice that when a business case gets approved and the associated head count called out in the financial template no longer matters, because what we’ll do is forecast number of tickets and number of CIs that will be in the run? The work would then funnel to the appropriate supply (delivery) team. Done deal! Bill me!
We haven’t tackled the Project work type. I think we’ll continue to measure effort in “days” and focus on perfecting this model for PS and CI.