IT Service: a badly shared notion (Part 4)

By Laurent Duenas, January 12th 2013 

 

 Consequences of this badly shared vision?

 

IT strategy is the result of the fusion of several strategies led separately, whose consolidation does not guarantee an alignment on all the objectives expected by businesses. 

Whatever may be said, very often, an IT strategy is the result of the consolidation of several strategies, each one specific to an area of concern: business roadmap, infrastructure roadmap, Information Security expectations, green IT level of compliance, etc… Even if the momentum of IT strategies comes from the directives from General Management and business expectations, reflections are led in each area of specialization and then assembled to give the best aligned global vision possible. But without any vision of what IT Service is, it is difficult to assert that the whole set of strategic choices made individually contribute to this alignment in a coherent way.

If you take the example of strategies around datacenters, more particularly infrastructure choices, those are based on different logics: consolidation, geographical location, financial optimization, that may prevail at some service levels. In fact, impacts are often indirect. Business requirements such as capacity, storage capacity, capacity to evolve, etc., are processed in a consolidated way, but this global and a little simplistic approach leaves behind the concern to contribute to the most critical business processes in a relevant way. Example: the choice of a server and storage architecture shared between a private and a public Cloud seems to be the perfect solution to meet requirements concerning capacity development, at the lowest cost. Yet, at this stage, this choice does not guarantee the ability of technologies or suppliers to meet reactivity requirements linked to business seasonality, supply constraints, change implementation or concentration of simultaneous requests. To be clear, will reality match theory? Bearing this in mind, strategies led irrespective of a vision of IT Service and expected guarantees, do not leave other choices to business but to adapt to the new constraints inherent to choices. As for Service Management, it pursues a totally opposite goal.

The danger stemming from businesses is significant too. They make choices about market software which have equally delicate consequences. Businesses and the IT departments supporting them (consulting experts, project managers, business IT departments), turn towards functional choices, irrespective of an end to end vision of the IT Service, which leads to unkept promises (response time, mobility, recovery time after incident) because standards and infrastructure architectures do not allow it. Let's take the example of a document digitization project supposed to bring a large business activity: the IT Design department had committed itself to respond within a defined time, based on technical information given by manufacturers, without really involving Production teams in the evaluation process. Once in Live operation, response times were not kept. New significant investments have had to be added, significantly impacting the project profitability.

 

IT Department is nothing else but an aircraft manufacturer coupled with an airline company operating the products it manufactures

You also have to put yourself in the place of IT department managers: an IT department gathers technical specialties which naturally constitute silos, because different areas have very specific competences and objectives. Moreover, these last years, IT departments have reinforced their structuring by introducing specialization. With the emergence of business IT departments, shared Service Centers, Skill centers, etc…, there are increasing tendencies to centralize and consolidate, making the adequacy between technical, financial and business alignment objectives more difficult.
Maybe totally distributed environments would make a specific approach for each IT Service easier.

But today, industrial logics do not leave any other choice but centralization. « Service Strategy » (ies), as ITIL calls it, totally focused on the notion of IT Service, is an opportunity to preserve harmonization between transverse optimizations and service requirements specific to IT Service, through a declination of the latter at each level of specialization, particularly through the notion of « service models ». Just like an aircraft manufacturer who must coordinate its various trades (fuselage, electronic motorization, electric flows, internal comfort management, security, video flows, etc.), it sets up a common vision of the final deliverable, rigourous planning and standards, to deliver operational and flawless planes. IT Department is nothing else but a plane manufacturer coupled with an airline company operating the products it manufactures.

 

The lack of end-to-end vision of IT Service inevitably impacts the image IT Department gives its customers and consequently, the trust it builds

As mentioned above, going through the Service Catalogs of companies, you will find a mix of several notions, revealing poor knowledge of the final deliverable. As reminder, the Service Catalog is supposed to represent the IT department offer towards its customers (offer which is the result of service strategy). Now, this is seldom the case. You find service deliveries (examples: installation of workstation, request for a phone, installation of an application, etc), technical services (example: hosting, storage, connection, print services, etc.), and sometimes applicative systems (example: accountancy, sales, invoicing, etc).

This mix may be perceived as somehow useful. It may be confusing because its content addresses several interlocutors. Above all, it does not give enough confidence to real customers (those who buy IT Service) about the IT department ability to understand their real expectations. As content is too disparate, it gives customers the feeling that they have to rebuild the Service end to end themselves and that the language in which service levels are addressed does not allow them to be aligned on their own objectives.

 

Better understand what is sold, give meaning to daily operations, this is the best way of understanding why you have to be excellent

On the side of IT teams, the other consequence of a Service Catalog failing to integrate an end to end vision of the IT Service is the failure to develop a customer culture. Even if the Service Catalog is not meant for them, its goal is also to give everybody a vision of what is sold to IT Department customers, of criticality levels and commitments offered. Better understanding what is sold is a good way of better understanding the expected level of excellence and its purpose. Unless they have a coherent vision of the final deliverable, it is difficult for them to share this essential culture in the world of Service.

The major input linked to the notion of IT Service is to give sense to the various operations carried out in all IT activities. The following examples (voluntarily picked up because of their link with ITSM process activities) enable us to measure the usefulness of the notion of IT Service in the daily lives of IT stakeholders:

 

Set up incident priority :

►   Unless you know which IT Service was impacted and how critical the impact was, how can you be sure about what priority to give to an incident? Does the affected component determine it (as often observed within organizations)? Depending on components use, criticality changes. That of the IT Service is directly linked to business and does not change.

 

Evaluate a change business impact :

►   Unless you know the technical and functional contributions of the component (s) subject to change, how can you make sure that precautions are taken to control change impact? Knowledge of IT Service gives all hints about which configurations contribute to its implementation and on precautions to take (through change models).

 

Anticipate capacity requirements according to business volumes :

►   Unless you know IT Service, how can you translate business volume into IT Service consumption units and then, how can you translate the latter into technical resources units consumed? Knowledge of IT Service gives all information on configurations and resources with finished capacities. That is what we call Service Capacity Management.

 

Align IT availability on business challenges:

►   How to make sure that infrastructures and applications availability is actually aligned on business expectations, unless you are able to identify precisely who contributes to what and when? Knowledge of configurations included in IT Service allows to identify vulnerability points and improvements to make.

 

Monitor IT resources based on business views?

►   How to make a business-oriented supervision unless you have a knowledge of the business deliverables to which IT resources contribute? Today, « business views » are rather an IT department approximate and internal visions. Identifying IT Service enlightens about the real contributions and the constitution of these views.

 

Calculate an IT Service TCO and measure its profitability?

►   How can you consolidate IT costs with an IT approach unless you previously identified them? Knowledge of the configurations included in IT Service brings this aptitude to consolidate costs and also to identify IT Service financial optimization areas.

Although limited, these examples show to which point operations in all areas, whether operational, tactical or strategic, are led without any end-to-end vision, far from customer vision. This implicitly leads to operations segmented by area of expertise, specific to each silo. So, each silo develops his own approach to carry out its operations, its own maturity level, without any coherence or alignment on the final result.

 

Business Units witness daily a lack of alignment between the various departments (or silos) and this affects the IT Department which fails to be recognized as a strategic partner able to accompany businesses in their future evolutions.

 

(end of the article)

 

 

Copyright © 2013 - PRACT Publishing