Hardware Refresh and Software Upgrade

If there is one thing that distinguishes IT infrastructure services from the general IT services pool in terms of structuring the deal and the impact on (accounting) books, it is the way IT infrastructure space impacts capex decisions of CIOs. While "running the operations" draw opex budget for software services and infrastructure services, the need to refresh hardware (network gear, desktop, servers and other related gear) and upgrade software (to keep pace with OEM support or hardware compatibility) brings in the capex element which makes most long term deals interesting.

When outsourcing for infrastructure services, value being sought is not just in improving service quality, operating efficiency, running cost optimization but also to reduce and smoothen the traditional clunky outflow on account of such refresh and upgrade requirements which are mostly inevitable and a necessity in large enterprises running mission critical environments.

As different service providers come with up different models for addressing these customer imperatives, there are different approaches each provider takes. Some have their in-house financial companies which finance/lease hardware ( these service providers also want to keep such activities on a different accounting book and not let it pull down its operating margins and numbers). There are some others who do not have such options and take this as a "core value prop" pitching it as an advantage of not having any bias to any technology OEM. However with time, since the business of business is business, CIOs may like pure-play show but finally it is where the dollars are saved that they mostly end up going with as finally that's how they get their bonus worked out!

If the enterprise does not own the existing equipment, this becomes a big factor in large deals as they then do not find it attractive to add equipment to their books in the current situation. If they have the equipment on their books, already this gives them a great opportunity to build a business case to use the opportunity to outsource or change their service provider and sell their assets to the new provider.

Asset Takeover - Why Doesn't It Fly With Offshore Based IT Infrastructure Service Providers

There are many differences in approach and delivery model of the traditional IT Infrastructure outsourcing firms (like IBM, CSC, EDS etc.) and the relatively newer kids on the block - the offshore based IT Infrastructure Service providers. While that can be a topic for a full book, one of the key differentiators is that most (and probably all) offshore based IT Infrastructure Service Providers do not get into taking over assets of customers' IT environment. These typically are the servers, desktops etc. The traditional biggies in fact have had this as a core streak in their proposition. How they handled it can be differentiated into two parts - those who were hardware vendors and also had a hardware agenda and those who were pure play services companies. Whatever be the way it was dealt it was always a financial engineering subject. It gave a flash on the topline but the bottomline took a hit.

The offshored based IT Infrastructure Service Providers have traditionally evolved as application service providers and never had assets in their deals. The inclusion of such deals causes a lot of concerns, some of which include:

• Impact on the bottomline which would make it into single digits which they are not used to and do not consider core to their growth strategy
• Lack of a hardware business does not get the extra dollars to offset this "hit" with revenues in some other businesses
• Lack of critical mass and economies of scale (across multiple customers) which the biggies have
• No related business model like hosting services or data centers with leased servers where the residual equipment can be gainfully deployed
• Need for enhanced stickiness as such deals then require a much longer and deeper relationship which the relatively new offshore based IT Infrastructure Service companies have not seen (since they are still new and have not spent as much time in the marketplace)

Now these are the most common but relevant reasons aggregated across various companies. Specifics may vary with companies.

Analysts talking of the emergence of new non-asset linked services and its benefits (which cannot be denied) to the client are only making the market place an exciting place with different players having their own value prop stories.

ITIL v3 : First Impressions

I did my ITIL v2 Foundation certification last year. It was actually the fag end of last year and I initially enrolled to take the test for ITIL v3. It was too late by the time I realized my mistake since I had already entered my credit card information on the test scheduling site. Luckily there was some error in entering the card number and the transaction was nullified and I re-scheduled for v2 for which I had been preparing.

Now few months down the line, I got a chance to overview and skim through ITIL v3. I am still browsing but first impressions:

• Has a major thrust on alignment with business in line with the trend where the CIO increasingly is reporting to the CEO or COO and not to CFO or some VP - Admin (!! .. yeah)
• Is more cognizant of the use of ITIL in outsourced scenarios. In fact it even recognizes that services will be delivered from offshore
• Focus is now on "Service" than elements that form the basis of service. So there are things like Service Strategy, Service Design, Service Transition and Service Operation. Also there are elements like Service Design Package (SDP) and Service Level Package (SLP) and a CMDB like Service Knowledge Management System (SKMS).
• Has a more marketing oriented feel and approach - be it the alignment to business or the abundant use of terms "strategy" and "value". It even has its four "Ps" !
• It is understands that there are service providers who are increasingly providing such infrastructure support services. It even takes into account the competitive environment for these service providers

Like everything that tries to be current and keeps evolving ITIL v3 is a step to keep the ITIL context relevant and appealing to most decision makers. It continues to be a guiding framework and not prescriptive for specific environments.

Importance Of Service Transition

The importance of a good transition when outsourcing IT infrastructure services cannot be emphasised enough. A poor transition can even disrupt the outsourcing program and cause a lot of business unrest.

Why is service transition so critical?:

• Change of personnel -- either the incumbent provider walks off or an insourced team is displaced (unless most of the existing team is re-badged) -- takes away the operating knowledge which would have built over the years with the incumbent team. Further, the new team will face even more disruptions as they transition and will be more ill-equipped than the incumbent, presenting a double whammy
• Change of environment - servers changing to a new provider or moving to a new hosting facility are bound to throw numerous situations ( often some of the servers would have not been shut-down for years and no one would know for sure how they will behave once re-started after the move). More importantly how to fix the issues that may surface when a server misbehaves
• Tools/Automation Impact : Most often either the tools change and so will require few weeks at minimum (for mid to large enterprises) to bring some sanity in monitoring and escalation. Most tools for monitoring also have a learning curve (self attained or crafted) which build over time. So, in all this chaos, the tools are not there to monitor the crucial times when business is most likely to get impacted
• Differing levels of interest by the stakeholders : While business may be fuming at the decision of IT to change the provider, the outgoing team will (let's say, for lack of better terms) not be interested in a good transition since they are anyway getting impacted professionally and some times personally if they are losing their employment

This is no means an exhaustive list but surely the top ones. Essentially there are too many moving targets and moving guns that come to play. One way to mitigate or minimize the risk is to stagger the transition based on some considerations. If not all targets are moving or if the guns are not moving, it becomes easier. Possible modes could be:

• Stagger across regions/geographies
• Stagger across service streams (say, Data Center Ops goes first, and then End User Computing and then Service Desk)
• Stagger activities (say, the tools will continue from the incumbent till the services are taken over by the new provider's team)
• Stagger across different user groups ( say IT goes first and then HR and then ... finally .. yeah you got it - the Finance team!)

There is no silver bullet but what is important is that sufficient thought is spent on this and mid-course mitigation strategies drawn.