ITIL deeds don't go unpunished

What's more interesting is that the concerns of attendees were hardly isolated voices in the wilderness. John Willis, who heads Zabovo, a third-party consulting firm specializing in IBM Tivoli tools, recently posted the responses from the Tivoli mailing list on the question of whether ITIL actually matters. He didn't get a shortage of answers. Not surprisingly, there were plenty of detractors. One respondent characterized ITIL as "merely chang[ing] the shape of the hoops I jump through, and not the fact that there are hoops..." Another termed it "$6 buzzword/ management fad," while another claimed that ITIL makes much ado over the obvious. "The Helpdesk is NOT an ITIL process, it is merely a function..."

But others stated that, despite the hassles, that the real problem is defining processes or criteria more realistically. "Even when I'm annoyed, I still believe ITIL or ITIL-like processes should be here to stay, but management should be more educated on what constitutes a serious change to the environment..." Others claimed that ITIL formalizes what should be your IT organization's best practices and doesn't really invent anything new. "Most shops already perform many of the processes and don't recognize how close they are to being ITIL compliant already. It is often a case of refining a few things."

Probably the comment that best summarized the problem is that many organizations, not surprisingly, are "forgetting that ITIL is not an end in and of itself. Rather, it is a means to an end," adding that this point is often "lost on both the critics and cheerleaders of Service Management."

We're not surprised that adopting of ITIL is striking nerves. It's redolent of the early battles surrounding those old MRP II, and later, ERP projects, that often degenerated into endless business process reengineering efforts for their own sake. Ironically, promoters of early Class A MRP II initiatives justified their efforts on the ideal that integration would enable everyone to read from the same sheet of music and therefore enable the organization to act in unison. In fact, many of those early implementations simply cemented the functional or organizational walls that they were supposed to tear down. And although, in the name of process reengineering, they were supposed to make the organizations more responsive, in fact, many of those implementations wound up enshrining many of the inflexible planning practices that drove operational cost structures through the roof.

The bottom line is that IT could use a dose of process, but not the arbitrary kind that looks good in management PowerPoints. The ITIL framework presents the opportunity to rationalize the best practices that are already are or should be in place. Ideally, it could provide the means for correlating aspects of service delivery, such maintaining uptime and availability, with metrics that actually reflect the business value of meeting those goals. For the software industry, ITIL provides a nice common target for developing packaged solutions, just as the APICS framework did for enterprise applications nearly 30 years ago. That's the upside.

The downside is that, like any technical profession, IT has historically operated in its own silo away from the business, where service requests were simply thrown over the wall with little or no context. As a result, the business has hardly understood what they are getting for their IT dollars, while IT has had little concept of the bigger picture on why they are doing their jobs, other than to keep the machines running. IT has good reason to fear process improvement exercises that don't appear grounded in reality.

ITIL is supposed to offer the first step - defining what IT does as a service, and the tasks or processes that are involved in delivering it. The cultural gap that separates IT from the business is both the best justification for adopting ITIL, and the greatest obstacle towards achieving its goals.

This article originally appeared in onStrategies.

Copyright © 2007, onStrategies.com

Tony Baer is the principal with analyst onStrategies. With 15 years in enterprise systems and manufacturing, Tony specialises in application development, data warehousing and business applications, and is the author of several books on Java and .NET.