by Les Viszlai
I’m surprised by how often I come across IT organizations that still aren’t fully persuaded of the value of using service catalogs. There is a lot of conversation around the value to the Business but I would like to jump in and outline the advantages of service catalogs from an IT Organization’s perspective.
First and foremost, service catalogs defend IT spending and budgets.
Without a service catalog, IT owns the generic technology line items that keep other parts of the business running. It’s not unusual for the software, hardware, and external IT services used by finance, marketing, sales and everyone else to get lumped together and tracked within IT’s budget. This bundling makes the IT Department’s spend look like a massive cost center compared to other departments within the business. This then suggests that IT is overspending and ripe for an across-the-board cuts.
Under the generic model, finance teams looking to cut business costs by a target amount across the board start with IT. To add insult to injury, I have found that IT departments are normally understaffed compared to other departments within the business and often underpaid based on industry benchmarks.
Moving to a full services catalog model changes that game. A successful service catalog defines all of the various offerings individually provided by IT to the business and aligns the software, hardware, and external IT services components needed to provide each of these offerings. The services catalog should also clearly communicate the costs and service-level agreements associated with each service, giving IT the ability to show-back or charge-back the other departments. This isn’t as monolithic a task as it may sound.
How does a service catalog make life better for IT?
Let me give you an example of how this changes behavior. A company I was involved with in the past was running a number of different CRM products as a result of company acquisitions over time. We kicked off a project that justifies the consolidation of the various CRM tools for both cost and efficiency (see my blog on ROI for tips on building such a business case).
Consolidation projects usually transition various users off of the legacy CRM tool onto the new consolidated centralized tool. Inadvertently a core group of users (usually tied to the original acquisition) resist the migration for some good and some bad reasons. The net result is that our IT team is stuck supporting two tools. The difference now with a defined Service Catalog is that IT can clearly charge the hold outs for both CRM product services. The corporate sanctioned CRM tool and the legacy CRM tool can be clearly tied to the holdout business unit. In addition, IT is now in a position to defend the costs related to this and any additional Service Catalog items now tied to the end user or department that uses the service.
Now, let’s fast forward to budget time. The CFO asks IT to reduce costs by 15%. Where before the dialog might be framed around reducing head count on the networking team, it can now be about which services in the service catalog the company wants to go without.
From a purely selfish point of view, that insulates IT from demands that are all-but impossible to satisfy. It gives the organization the ability to clearly signal when proposed cuts will damage the business. Additionally, the business also benefits, because they have now a less opaque window into their IT spending and its impact on, and interconnection with, their business functions.
Benefits for both IT and the Business
When we look at the broader case for service catalogs from the business perspective, that interconnection goes deeper.
On-Demand Access and Reliability
Service catalogs, of course, allow us to move to a model where end users click on a service they need and then just click once more whenever they need it again. Even at the end of the quarter, or when there’s some looming deadline, those end users always have the extra resources they need available without having to wait. So they’re gaining reliability, especially during times when IT resources traditionally got bottlenecked.
Speed
This model also opens the window for IT to add additional automation to any service. Say your SLA for providing an FTP-based service for file uploads and downloads is three days. With automation in place, you may be able to speed that up to hours, if not minutes. What’s more, you can offer this service as soon as the initial automation is complete and then keep fine tuning it by adding new tools, capabilities, and resources as they’re developed.
Efficiency
Standardizing clients, logging, auditing, and security, and adding system-relevant restrictions based on user profiles, restricts on-demand access so you only get service requests from people with a valid reason to ask for them. This saves IT money and time.
More Growth Potential
That automation and simplification story hints at the other major win for IT here. With a much more streamlined process enabled by its service catalog, IT has more resources available to manage growth more efficiently than it would have been able to under the old model.
Improving Business and IT Alignment
At the core, what both IT and the business are gaining when they adopt a service catalog is better alignment to needs.
When you have a common language and supporting data to communicate with the business the conversations around budgets fundamentally change. Whereas before IT might have just presented a shopping list for approval, they can now say to the business, for example: “We’re creating ten times more FTP sites than we anticipated and they have to stay around three times longer. We’re out of storage, though. So, we need storage for the FTP site service.”
Similarly, the business can explain to IT that it needs IT’s four day process for creating an FTP site to be reduced to four hours. And because IT thinks in terms of services, it can easily budget out the resources it will take to make that happen.
Both conversations are now about the substance of the services that IT offers. Framed that way, they’re likely to be much more productive for each side – helping IT make good decisions about where to place its resources and allowing the business to understand how they can positively impact the services they are getting from IT.
Breaking Down Silos
When IT sets out to deliver a new service, like the simple FTP examples above, it’s very likely to involve people from a number of areas – in this case, networking, storage, and servers. In the past, everything and everyone was siloed. The network guy would work on the job then hand it over the hill to the server gal, who would hand it over the hill to the storage guy. With the new model, that behavior is broken down, because the network, storage, and server people are collaborating and sharing IP, all aligned to this one service, not their own specific technology silo.
Furthermore, by moving to a services model, IT is now aligning those various siloed resources in a way that enables knowledge transfer and increases overall efficiency and speed of delivery, and very likely lowers costs too.
Overall, the services model offers a route for IT to give business what it needs, but on terms that don’t compromise performance. Supported by the productive dialogue with IT that the model enables, the business can stay agile and scale up to meet demand, all while getting the most bang from its IT buck. That leads to growth, which IT, under this model, will be ready to support. Which of course is a good thing for everyone.
=======
Les Viszlai is a strategist with VMware Advisory Services and is based in Atlanta.
