Service Matters! ITSM & IT Management: June 2007 Archives

« May 2007 | Main | July 2007 »

June 26, 2007

V3 Out of the Box

It's been nearly a month now since the new ITIL V3 books were published and shipped to near and distant shores. So have you had a chance to read these up? Not yet? Well, if you pick up these books, one of the first things that will put a smile on your face is the structured and lean approach to detailing each process. Apart from that, one aspect that I found particularly interesting is the inclusion of IT Service Management Technology Considerations.

Long due and much awaited, the three-four page treatment might still appear high-level and possibly a disappointment to some. What strategy does one adopt to implement an IT Service Management (ITSM) tool? Are there standard approaches? How about investments in existing tools? Any way of maximizing these? How does one manage Organizational Change Management (OCM) during roll outs? Is an out of the box (OOTB) implementation preferable to customization? How much customization? And many more such questions come to mind ... But then, there is only so much that can be covered before everyone starts complaining about the thickness of the books.

A while back, I was involved in a Proof Of Concept (POC) deployment of ITIL Change Management process and the associated out of the box ITSM tool implementation. While there wasn't an initial ITIL assessment carried out in this case, an out of the box POC was the preferred route. Why? An urgent need to ensure safe changes, reduce availability impacts, standardize processes, get rid of home-grown ITSM tools / bespoke applications and so on ... sounds familiar?!

Here are some insights that we re-discovered on our way that I thought might interest you. If you are planning to implement or refresh your ITSM processes and tools, some of these might help you better understand what you are going to be up against. If you are looking for quick answers, tread with caution! This probably will raise more questions …

For starters, a quick question - is it really possible to implement an ITSM tool (and associated processes) out of the box? Why not? After all, you have pre-defined process flows, a defined scope of service / business lines, defined timelines, established business drivers ... sounds relatively straightforward? Hmmm ... think about it. There are some tight and rather intriguing constraints right behind these that you would want to keep in mind when you go OOTB.

What You (Don't?) See Is What You Get: Keep a tab on your requirements
Until the tool is really deployed into the environment, very few actually realize what the tool really looks like. Demos and walk-throughs are good, but only go so far. Net net this means - most stakeholders really don't know what they are up against while specifying what they want the tool to achieve. And to add to this, most requirements end up becoming "must-haves". Even at the fag end of the deployment, you could just about find yourself going back to rewording and reworking your requirements.

Hammering in the processes: Training and all that ...
Several organizations prefer to go OOTB so that it can be replicated as a "hub" and deployed on a larger scale. And of course it also means support costs are potentially lower. Given that a POC comes with tight timeline and the need to deliver demonstrable deliverables, does that leave you with enough time to get your processes hammered in right? Training and communication are key. But they take time. More importantly, do you have sufficient time to drive behaviour change? Or would you rather go for customization now and revert back to out of the box practices somewhere down the line? And what does that really mean to revert?

Mapping the Reporting Beast
Associated with Organizational Change (OCM) comes reporting. Several of you might wonder how reporting is linked with OCM. But will you continue to report the same metrics or has your senior leadership bought into the new processes enough to agree to more suitable metrics? And will you end up creating a little old-world reporting monster in your new ITSM tool? Beware …

Who will do what: Future roles and responsibilities
How do roles defined in the out of the box tools map to the roles defined as per your processes? They should map 100%. But do they? Really? And in turn how do these roles map to your organization? Constructing a simple matrix to map “organizational roles” to “process roles” to “tool roles” can be a simple but powerful start. For example, an organization may have a role called Change Originator, if it feels most employees are comfortable with that term. This in turn may map to two “process roles”:

Change Requestor or the individual(s) asking for the change to be raised, such as a business partner
Change Initiator or the operator who actually logs the RFC into the tool

Per your ITSM tool, this may map to a set of privileges and rights such as "Raise Change Record", "Edit Change Record" and so on that need to be tightly linked back. Fairly common sense, but truly worth a relook to make sure they are in place!

Phew ... and all that while you align with Best Practices.

So, have you an interesting out of the box tool / process deployment story to tell? And did you stay out of the box?

Posted by Arvind Raman at 9:39 AM | Permalink | Comments (1) | TrackBacks (0)

June 7, 2007

For the sake of Valuations

Traditionally our notion around Valuable Assets has been to lock them up or store them in a bank’s locker. These could be monetary in nature, cash, jewels, any other important product/ document that we perceive as valuable to us.

This primarily means a) Getting a fix around the notion of "what value", which is commonly understood and agreed to.

b) Taking ownership of the risk around these valuable assets falling into the wrong hands/ misusedOR c) Transferring the risk to a trusted third party entity with whom we have a business relationship.

In the connected world that we now live in, the focus of information risk is around these information assets, how we consume and benefit these particular assets.

An example of this is the way we get authenticated by our banks when we call them for doing business. Who we are (name - first/last), our account number, last 4 digits of the SSN, date of birth etc. Fundamentally, these information asset sets' are responsible for conveying the information of who we are to the agent at the other end of the line. Any compromise to this information either due to information corruption, application availability or misuse has serious implications to the business transaction.

So the question that came to mind isa) Can you value Information Assets in monetary terms?

b) Are these valuations clearly understood and accepted by a wide audience?

Clearly our ability to value information assets will influence the way in which information risks are being understood and taken care of.

Have yet to come across a methodology or organization that can do this convincingly. Maybe what we need is a new global standard for information asset valuation!

So when looking at the first basic tenet ie scope, - what those information assets are and how important they may be (value to the organization), are often more important, than say where they are located, how are they managed and who manages them.

This brings us to the question of how these information assets can be accessed. Identity and Access Management (IAM) is an essential capability and a key IT Service to contain Information Risk. Looking forward to early next week where I will be talking about IAM and interacting with other like minded participants at the CSI Net Sec conference.

Yet another facet of Information Risk and more from the conference proceedings next week.

Posted by Ramshankar Ramdattan at 11:53 PM | Permalink | Comments (0) | TrackBacks (0)

June 6, 2007

ITIL V3 – Readiness Assessment

The "Are you ready for V3" Email

Quick question - over the last week or so, how many emails or articles did you come across that were titled "Are you ready for V3" or something to that effect? Quite a few, I bet! And how many of these did you find useful?? Hmmm ... alright - we won't get into that part

With the release of the core ITIL V3 texts on 30th May, there has been a good amount of buzz in the industry. But how long it will be before organizations start embracing V3 remains debatable. Ken Turbitt from BMC says in his blog that it will be between 18 months to 3 years before adoption of V3 goes mainstream. While that may eventually turn out to be true, it has definitely not stopped several organizations from already starting to think and plan out their V3 journeys.

Earlier this week, I was speaking with one of our clients here in the UK. With an ISO20K certification and a relatively mature Service Management program under their belt, one of the burning questions facing them has been how V3 will impact them. Here are some quick points from my discussion that I thought you might find interesting if you have also been thinking about starting on V3. So, is this an exhaustive list? By no means - these are some broad initial directions that can guide you as and when you plan for V3.

So, where do you begin?

Which service lifecycle stage should you start with? All of them, did you say?!
An iterative approach to developing Service Management capabilities has worked well for several organizations in the V2 world. A financial services organization where I was at, a while back, successfully adopted such an iterative approach to develop its ITSM program and significantly improved its availability measures. Will such an approach continue to work? I see no reason why not. Having said that, how do you decide which lifecycle stage to begin with? Well, for starters, look at the key business drivers. For the health care industry as an example, this would be the ability to ensure a hospital can continue to serve its patients at all times. Focusing on "Service Operations" could be a good starting point. Sounds too simple did you say? Well, we all know the old saying of keeping it simple!

Assess Service Maturity Or Process Maturity?
Well, why not look at both? Some organizations such as this client I was discussing with wish to be able to see one single holistic view of all their services broken out by lifecycle stage and processes within these. And there are still others who prefer to just continue building out specific processes and decide subsequently to move towards an integrated service outlook. Is that a problem? Surely not. What benefits do you want to see and by when – let these drive your decision.

Maturity or Compliance?
ITIL purists would shudder to hear the words "ITIL" and "compliance" mentioned in the same breath :-) But if you have a relatively "mature" Service Management program, ask yourself if you really want to reassess your entire program. Perhaps, you might be happy to use V3 to make sure your existing processes are really "complying" with what you have out there, while stitching in new threads that have been called out in V3. Take the case of Incident Management for example, which in the V3 world is now Event Management, Incident Management and Request Fulfillment, the last two supported by Self-Help. While most organizations today, in some form, do carry out Event Management and Request Fulfillment, calling these out has ensured that they are formally benchmarked and assessed against theV3 best practices, instead of being hidden somewhere in the garb of Incident Management. Simultaneously, for the core Incident Management process, ensuring that the process complies with what it has been designed for will ensure renewed focus on best practices.

Are these also the directions in which you are thinking about V3? Let me know our thoughts.

Posted by Arvind Raman at 10:22 PM | Permalink | Comments (1) | TrackBacks (0)

June 5, 2007

Discover the language of “Information Risk"

"Business -IT alignment"(BIA) is a term used to mean different things to different people. What is particularly interesting is how this is viewed in different contexts and scenarios. The expectation of Business from IT in a product centric industry such as Retail versus a technology centric business such as a wireless Carrier is dramatically different. And does IT have any requirements from the Business? Absolutely! So the "alignment" term is something that really needs to be explored in more detail.

And what are those alignment magic words- ? - performance, cutting edge capability, efficiency, reuse, key projects, resource skillets, ROI. And the list goes on.

In the compliance and Security Services domain, BIA takes up an altogether different meaning. The ability of Security leadership to communicate the value that the function provides to the business in real terms, is often lost in the noise of breaches, regulations, control programs and of course those lost laptops!

The fundamental question therefore is “how does the business and IT communicate when it comes to Information Security Services? "

The answer may lie in taking an altogether different view at Information Risk and the management of the same. In the connected world that we live in today, the Confidentiality, Integrity and Availability (CIA) of information and information assets is the key essence for a successful business. The ability of the organization to truly recognize this vital facet, will pave the way to a new beginning in BIA. The language of Information Risk will serve as the backbone for this kind of an engagement

So how can one do this? Look at the 8 basic tenets of
1) Scope - what assets must we cover
2) Domains- which information zones are relevant
3) Regulations - what are those hot regulations we need to take on
4) Periodicity - how frequent should be the assessment
5) Ownership - who will participate
6) Methodology - how will we do an Information Risk Assessment
7) Management - from a longer term how can we mange this for sustainability
8) Business Value - minus the regulatory driver, what should be done to add business value?

Recently we did a workshop with the Chief Risk Officer of a leading West Coast Retail company. When we passed through the physical security folks in the building, the guard at the front desk handed out some dummy badges and actually mentioned to us that the "system was down" and hence could not assign numbers on the badges. So any badge was ok! As I walked to the elevator, I recalled that this was the exact state around a month back during my last visit. And why should the guard even be talking about something like that to strangers like me?

Now let’s look at the definition of Information Risk Management (IRM) as we within Infosys see this and come back to the above in a moment.
“Information Risk Management (IRM) is a holistic approach, within specific information management domains, to effectively understand, analyze, report and remediate controls' based risks to facilitate organizational compliance and overall business confidence”

Heading back to the above scenario and applying both the definitions and the 8 tenets we have
1)      Scope – Controls around visitor entry
2)      Domains- information around visitors entering the business premises
3)      Regulations – Access Control requirements from Sarbanes Oxley
4)      Periodicity- Controls review every quarter / month
5)      Ownership- Physical Security, IT and Facilities
6)      Methodology – An automated / self assessment based approach
7)      Management – Security awareness training, centralized repository of controls, graphical reports
8)      Business Value – Absolutely ! – Keep track of every visitor in the premises at all times. Who came in, why did they come, whom did they meet, when did they come in and when did they leave.
Do you see the language of Information Risk that the business and IT can communicate in? Do you feel this is relevant in your own organization? How will you begin to address the vital nuances of this language?