Service Matters! ITSM & IT Management

When should I raise a Change Request?

That's an innocent enough question. So what's your answer -

1. When Business states its requirements
2. When Business commits its requirements to a schedule / calendar
3. Or perhaps it's when the corresponding IT development project is identified and resources planned?
4. Well, how about when an IT Operational Change is expected?
5. No, none of these. I don't raise a Change Request, I just sneak them in when no one's looking - way too painful and bureaucratic otherwise. Hey, but don't tell anyone!

Engaging Change

Unless you picked the last option, you are in the middle of the age-old debate cutting across Business, IT Development and IT Operations. The key to answering that question is - another question - what's your vision for Change Management?

Is it to gain better control over the production environment? Or do you want to go beyond that definition and use this as a mechanism to better integrate IT with Business?

If you picked option 4, you have plenty of company.

Most IT organizations I have seen, aspire towards the 3rd and eventually the 2nd option and thereby moving closer to Business. At bare minimum, this translates to capturing original business requirement / project associated with the IT Change. Which is not a bad idea at all. For instance that helps -

• Report how many operational changes failed against that particular project, apart from the regular Change metrics
• Discuss all 'project related' changes together in the CAB to better understand impacts and dependencies

So, what stops them? In this instance, unfortunately it's the existing technology. Most ITSM Change Management tools available in the market today are geared heavily towards only IT Change, with very limited capability of linking dynamically to Business. The Business Change Management remains a beast tackled by another completely different set of tools - which as you guessed - have trouble integrating with the ITSM tools.

Business-IT Integration

A while back, there was this interesting article from Aidan Lawes, former CEO of itSMF on ITIL V3 and the movement towards integration of Business and IT as against alignment. Neat concept. And one that summarizes our present Business / IT Change turmoil.

Business-IT Unified Change and beyond ITIL V3

How quickly will we get there? My guess is this is still a few years away from wide-spread adoption - depending on how soon and how hard process-mature client organizations push their ITSM tool vendors. Given the present chaos within Change Management across most organizations, I would have loved to see ITIL V3 go further out-of-the-(V2-)box and take a fresh approach in this area.

Sigh ... I guess one of my few disappointments with the new books.

And oh, by the way, if you picked the last option - despair not. You have plenty of company across the world

Posted by Arvind Raman at 10:58 AM | Permalink | Comments (0) | TrackBacks (0)

So to get onto this path, one must understand the organization's ability to rationally quantify the amount of controls. How many controls does a Fortune sized organization need? - Lets elaborate this a bit.

a) Have controls been classified into Information domains- eg Access Management controls versus Customer information protection based controls

b)Is there a suitable control range ?

c)Does one information domain need more controls than the other, due to its size/ complexity / native weakness?

d) Are there seasonal controls? - eg additional approvals for system changes during approaching holiday cycles?

e) What looks good and what looks like an overkill?

f) What drivers enabled this control domain to evolve over a period of time?

Very interesting questions! And no unique answers yet!

Due to Sarbanes Oxley and other regulations, some companies have been quick to put in tremendous effort at defining /documenting controls in virtually every facet of their organization. For example does each phase of a Software Development lifecycle become a control?. Probably yes, to some - then again others would argue that only the design and testing phases are true controls.

Also what about the opportunities in reducing the repeated effort and cost that go in year on year in validating certain controls?

So what does one do about all this? These days there are efforts within the industry around "controls consolidation initiatives".

This may be a solution to the above issues; however it is a path that can also end up in having thin controls in some areas versus others. Defining a consolidation/ selection criteria and understanding the true needs per information domain will definitely help. Undertaking a formal assessment around the scope, context and objectives of this exercise will additionally help.

Ultimately it is all about having a trade-off between getting an IRM initiative done lightly and quickly versus having a comprehensive process that takes much longer. Striking the balance between the two is dependent on the amount and quality of the available pre-audit controls.

And something to think about further!

Posted by Ramshankar Ramdattan at 06:50 PM | Permalink | Comments (2) | TrackBacks (0)

    As most managers involved in the journey towards ITIL and BSM implementations would agree, the toughest hurdle to cross is an enterprise-wide CMDB implementation. An effective and functioning Configuration Management Database (CMDB) or in ITIL V3 terms, a Service and Asset Configuration management Information system (CMIS), is particularly challenging for several reasons including:

• plethora in variety and complexity of data items to record and support and the challenge in creating a comprehensive data model for the CMDB
• Challenges in maintaining the accuracy of data in the CMDB and maintaing appropriate ownership and access levels
• and most importantly, in ensuring multiple IT management systems talk to each other and exchange data

     It is in this context, the recent announcement by the CMDB federation (www.cmdbf.org) around the release of the draft industry CMDB standards for a CDMB is particularly welcome. Several product vendors such as IBM, BMC software, HP, CA and Fujitsu ltd have provided their support for the draft framework. (See http://www.marketwire.com/mw/release_html_b1?release_id=122436 press release for details)

     Most organizations today, use a multitude of IT Service management tools to support their developing BSM frameworks. Given legacy reasons and the product development histories, customers tend to use components from the product families such as BMC Remedy, CA Unicenter, HP OpenView, IBM Maximo, IBM Tivoli etc on a "best-of-breed" basis. This leads to a spiraling of IT spends in terms of writing integration adapters such that data/events/alerts from one tool can be exchanged with another.

    In case the CMDB federation draft standards are approved and adopted industry-wide in the days to come, this would mean a substantial impovement in organizations' ability to continue with a federated approach to a CMDB implementation. Several organizations have balked at moving forward with a federated approach (centralized approach being severely limited in scope) owing to apprehensiveness about costs escalation unknowns around integration.

    Federated CMDB models and architecture such as a sample representation below would become the preferred architecture within organizations.

     Another additional development that also comes in time is the development of the Distributed Management Task Force standards (DMTF) (http://www.dmtf.org/). These standards enable interoperability between multiple infrastructure devices and their management platforms. Several successive versions of the CIM (Common Information Model) schemas have been released and these standards are increasingly being adopted by most leading industry vendors.

     While DMTF standards precede the development of the standards set by the CMDB federation, the verdict is still awaited around how these standards work together and in practice.

     It also remains to be seen on how soon the IT hardware and IT management software industry set aside their proprietary frameworks and adopt such frameworks. The faster the adoption, the sooner we will see real BSM in practice

Posted by Madhukar I B at 10:13 AM | Permalink | Comments (1) | TrackBacks (0)

In my last post Process drives the Tool, I shared some of my experiences around process-tool interaction in ITIL process implementations. After years of preaching from the practitioners and the experts like the one here , there is a good understanding that tool follows in the guidelines set by the process. In practice since the teams that are responsible for process definition are usually different from those that develop and customize the tool, the realization of process definition into the tool implementation becomes a bit more challenging.

Two areas that organizations need to be really careful about are - Requirements gathering and Detailed Process design.  It has been my observation that many process teams get too gung-ho and collect detailed requirements and design process as per their interpretation of Best Practices. While ITIL and other Best Practices are very useful in the initial stages or the High-Level Process definition, it is a poor decision to collect detailed requirements or define procedures in isolation of the tool. In one place, we spent months putting detailed requirements, processes and workflows without any idea on how those requirements or processes will be implemented. Having learnt from experience, I now advise my clients not to get in too much of details without giving due consideration on these will be implemented; otherwise there is a risk that several less than ideal situations may result:

· The requirements may be vague and may need back and forth between the parties to bring it to required level of details and clarity.
· The requirements list gets too long and may need another round of prioritization and elimination.
· There is a risk of  mismatch between the requirements and the finished product. Remember the telephone game!
· Detailed Process definition does not match with the tool workflow leaving the users confused.

Any kind of detailed Requirements Gathering or Process definition activity should be done with the tool in the close proximity. In fact it is highly recommended that you start with a comprehensive walk through of the Out of the Box Tool capabilities and then gather detailed requirements or get into detailed process design. And keep referring back to the tool capabilities in your discussions. This results in a better appreciation of the tool capabilities that result in:

· People providing the requirements are able to provide much more specific requirements.
· A part of requirements are eliminated because they are not business-critical and can’t be supported by the tool ‘Out of the Box’.
· There are fewer gaps between requirements / procedures definition and the tool capabilities resulting in fewer surprises when the end results come out.

These simple steps are amongst the other practical advice that will increase your chance of a successful and best practices compliant implementation. And one that meets the objectives of Process, Technical and Finance team alike!

Posted by Adarsh Kumar at 12:45 AM | Permalink | Comments (0) | TrackBacks (0)

  It was not long ago, i remember, when the discussions around ITIL i would have with customers would be around where to draw the process boundaries. For e.g. where does change end and release begin? how do you distinguish the differences between the role of the release manager and the configuration manager for deployment of large IT rollouts and so on? One was always left with a very uneasy sense of enveloping process bureaucracy at the end of such discussions. The business requirements seemed to be somewhere lost under such weighty discussions.

     The most creditable aspect of ITIL v3 seems to have been to bring out the forefront a new services focus. Emphasis has been made on the fact that strategy, definition and design of services are as important as the definition of the processes in a service management program.

     The trend in terms of closer alignment with the business now seems to have moved from the department/empire focus of the 1990's to the process focus of the 200x's and is now moving to the services-era with an increased adoption into V3. One of my favoured representations of the shift below

   That gets us to the centrality question. First there was the technology-centric implementation. Then came the process-centric operations. Moving into an services-centric framework, one cant help but wonder when are we going to get to the business-centric IT days. Or perhaps that is the topic of ITIL V4 :-)

Posted by Madhukar I B at 02:45 PM | Permalink | Comments (0) | TrackBacks (0)