In previous posts related to Fighting the War on Two Fronts, we've talked about whether consolidation drove simplification, how a service catalog can help you address specific customer requirements and how cloud-delivered services might be a realistic alternative to purchasing new management tools.
Each of these topics has pointed to the need for IT shops to move from a technology-centric model to a service-centric model. The traditional technology-centric model is driven by internal needs to continually upgrade infrastructure and partners strategically with manufacturers. The risks of this model include IT shops that focus more on manufacturer features than internal customer needs and internal customers who consistently ask for the best/most expensive infrastructure without regard to cost or risk.
The service-centric model, embodied by what we refer to as the 'Service Provider Model,' partners strategically with internal customers and focuses on aligning infrastructure to business needs in a way that drives more rational behavior. This model formalizes the 'Run IT like a business' concept in specific ways.
The key elements of a Service Provider Model include:
A Service Catalog - Described in an earlier post as a method for rationalizing user requirements to standard infrastructure services and driving business and cost benefits in the process
Service Level Management and Service Costing - In the post on tools we learned that in order to provide options to users we had to have a method for delivering, costing and measuring the 'good/better/best' levels of service.
Application/Infrastructure Alignment - By aligning the infrastructure offerings to specific user needs-rather than the other way around-IT investments can be optimized while delivering the highest combination of cost savings and agility to the business.
Provisioning Process Management - Once all the elements of the structure are in place, IT needs to be able to deliver to the specific offerings and tiers that are in the Service Catalog.
Why would an IT shop want to do the work necessary to move to a Service Provider Model?
Better Service Levels - Users who really need the higher levels of service can get them, and those who need more affordable levels of service can get them. In the Service Provider Model, cost goes up with the service level, creating real incentive for business units to work with standard offerings and the lowest acceptable service level.
Business Agility/Risk Mitigation - The Service Catalog creates proven building blocks that can be used to quickly build complex infrastructures. Using these 'service objects' allows every step from estimating through project planning and deployment through management to be done more quickly and with less risk to the business.
Visibility-Both supplier and user are now working with data and facts-service delivery levels, costs and quality are shown along with trending. Issues related to satisfaction can easily be analyzed-was it the wrong level of service selected, or did the delivery fail?
The Service Provider Model has significant benefits for enterprises, but mid-tier enterprises can often get as much or more benefit from this since they need to provide top-tier results with constrained budgets.
What are the ramifications of not moving to the Service Provider Model? One need only look at the current areas of friction IT has with its internal customers to get an idea:
Projects suffering from inadequate requirements gathering - IT finds itself in a hole when it delivers exactly what the internal customer asked for, but the customer then discovers it didn't have its requirements defined properly and the solution won't work.
High levels of customization vs. standardization drive higher costs and risk-By not having a set of standard service offerings, every project becomes a one-off that is less likely to tap into existing resources and skillsets. Businesses recommend wildly exotic solutions that they firmly believe are the only solution for their needs, and IT has little choice but to accept them.
Low business alignment - Users who don't have direct cost recovery implications and don't have 'good/better/best' options from which to select don't have incentive to choose the right service for the business requirement.
Lower customer satisfaction - Without defined offers, delivery promises can be vague and risky. Instead of being measured against a reasonable date based on well-defined needs and service offerings, IT's success is measured on 'intangibles.'
As with the Service Catalog, the benefits are valuable but don't come easily. Those organizations that have the in-house expertise and capacity may be enjoying the benefits of the Service Provider Model. For those who don't, we strongly recommend that they look to external suppliers for help. Some may use ITSM consultants who can help them organize a strategy for deployment of the model, and can help them actually roll it out. These shops will need to accept the responsibility for sustaining the model with their in-house teams after the consultants have gone.
Another approach is to use managed service providers to fill in some or all of the services you'll be delivering. This approach uses proven service provider processes, services and techniques, reducing risk and getting to benefit more quickly. In this model, in-house employees can be redeployed to more business-specific roles, ensuring a deep understanding of business needs while the external provider handles the complications of infrastructure management.
While businesses can debate the internal vs. external approaches, the one common theme is that doing nothing is the riskiest choice of all. The Service Provider Model will be demanded by the business and IT shops that don't pursue it on their own terms will find themselves playing catch-up in the future.