By: Paul Chapman, VMware Vice President Global Infrastructure and Cloud Operations
In this series of posts, I’m offering a VMware Corporate IT perspective on the journey to IT as a Service, looking at how we made the change ourselves, sharing some of the many benefits that ITaaS is bringing us, and offering some insights on how – if you’re considering taking the plunge – you might successfully make the transition yourself.
I started out by offering my take on the journey to IT as a Service. Then I shared the story of how our applications operations group transformed its operations by shifting to the Software Defined Data Center. This time, I’ll explain how we think of agility at VMware.
If I had to pick just two reasons why we decided to transition to IT as a Service (ITaaS) at VMware, it was that:
a) It would let IT deliver at the speed of business,
and
b) It would make IT a game changer – by providing business transformation through IT transformation, we’d be helping the business scale and grow.
But, if our vision embraced getting IT to run at the speed of business, delighting our users every day, and turning IT into an innovation center and not a roadblock, agility, efficiency, and an ITaaS mindset were the engines that would get us there.
Importantly, though, we put agility first. Many IT businesses think of IT as a cost center and put efficiency and cost first. While the “cut ‘till it hurts” approach can drive down costs and make efficiency metrics looks better, it can also leave IT hamstrung and unable to innovate and support changing business needs. Our big insight was that investments that significantly improved agility ALSO resulted in higher efficiency and service quality gains. By leading with agility, we could achieve both.
How We Think of Agility
When we think about agility, it’s on three levels. We’re aiming for:
- Zero demand. Every time anyone has to make an IT request, that’s a potential point of friction. They’ve had to stop what they’re doing and ask for something to be done, and then wait even longer for a response before they can move on. So our goal has been to completely remove their need to ask in the first place. You’d be surprised how much low hanging fruit there is here. There are lots of diamonds in the backend data, as long as IT studies it with the mindset of elimination vs. just resolution speed and SLA improvements.
- More self-service. Self-service is another key component to agility and ITaaS. The alternative is that our customers have to go to a help desk, the last place they should go, and wait for someone to get back to them through some kind of queued ticketing system. Taking IT out of the equation and giving users the ability to self-serve significantly increases speed-to-solution and user satisfaction.
- The ability to serve complex requests. If you have made progress on the first two, the calls and tickets you do get will by default feature more complex or lower volume requests. So what’s the best way to respond to them? Here’s how we do it: We’ll see, for example, that on average it’s taking n days to deliver or solve service request x. Then we ask (if we cannot eliminate or provide self-service) how can we slice up these requests, automate workflow and individual tasks, and reduce handoffs as much as possible? It’s not a one-time deal, it’s a process and an incrementally ongoing quest to reduce the time-to-deliver on the demand that comes to IT. Hiring or moving people to focus on this vs. volume-based hiring to solve requests is far more likely to have a transformative impact on IT and its agility in serving customer needs.
Measuring Agility
The shorter we can make the delivery time for any service, even the most complex, the better off our customers are in terms of being able to get what they need to do their job. So how do we measure our responsiveness?
Our goals here are very aggressive. We’re looking to reduce the time it takes to deliver a particular service from months, days, and weeks, to hours, minutes, and seconds, and in some cases eliminate the need altogether.
Specific examples of metrics I like to use to gauge my organizing’s agility include:
- The number of service requests that have been completely eliminated either through resolving at root the need in the first-place and or through fully automating solutions
- The number of service requests that are self-served
- If no automation or elimination is possible, then the cost- and speed-to-deliver of the solution from time of user creation
- The services offered through the ‘outside-in’ IT Service Catalogue
I am not a fan of time-based SLAs because I think it promotes the wrong behavior – customer satisfaction, elimination, automation, and self service are far more meaningful than time-based SLAs.
More fundamentally, IT should always be trying for an outside-in view and not an inside-out view. All too often, Service Catalogues are based on IT defining its services and how a customer can “order them” vs. offering the services the “customer needs and wants.”
Predicting Demand in a Ticketless World
Done right, agility means offering services on-demand before the customer even makes a request. It’s a nice idea, but how does IT predict what issues might come up so that it can preemptively have solutions ready before they’re needed?
At VMware, one approach has been to significantly increase focus and investment on having the right forensics in place. This lets us go from reactive, to proactive, to predictive, and to be very aware of everything that is going on in the environment.
In addition, we monitor internal social communications for sentiment and issues that might be brewing. Today we see a lot of activity on our internal Socialcast collaboration site, which is helping us get ahead of issues as well as have a more intimate relationship with our users.
Then we add transparency. Internally, we have a portal that shares the quality of service delivery at any given point. So if we’re seeing degradation in a network connection, for example, or a quality of service issue with a particular application, anybody in the company can see what we know, what we’re looking at, and what we’re communicating about the issue.
Key Takeaways:
- Agility, efficiency, and organizational mindset are at the heart of solving the movement to ITaaS.
- Agility inevitably drives increased efficiency, but efficiency alone won’t lead to meaningful agility gains.
- At VMware, we think of agility in terms of customer-centric, zero demand, automation, and self-service.
- We measure agility in terms of speed and cost.
- Forensics and transparency are key to predicting demand, and identifying and communicating issues.
- Without true agility, it is very painful and costly for organizations to scale and to remain nimble at the same time.
- The power of automation plus the power of a self-service mindset lets IT organizations help scale the business in a customer centric, cost-effective way.
You can find parts 1 and 2 of this series here and here. Next time, I’ll explain what it took to stand up and run our own internal private cloud with ~50k VM’s.
Follow @VMwareCloudOps and @PaulChapmanVM on Twitter for future updates, and join the conversation by using the #CloudOps and #SDDC hashtags on Twitter.
