Seeking Thoughts on This

[valawman]

My organization will be rolling out a new service management product late this summer. It is part of a project that includes the implementation of a CMDB and, while much progress has been made in work on that area, there is a concern that not all CI's will be discovered or instrumented by the product in time for the launch date. That being the case, my organization is attempting to determine and agree on the best way to categorize CI's and services not yet discovered or instrumented by the new tool, this in order to categorize incidents properly but with enough flexibility to grow and accomodate services and CI's as the tool matures. We're not looking for a silver bullet to resolve this but are wondering if others had to face a similar issue and what approach was taken to address it.

[UKVIKING]

It is rather easy

P I C S V

1 - ignore the tool / auto discovery
2 - use the service desk to find out what services are being provided
3 - Identify the components of each service, server etc
4 - use the SD and DC staff to find out where they are, what they are etc
5 - populate the CMDB
6 - give the CMDB to the SD to use - it is for them to do first

Autodiscovery does not find the CIs....it finds interfaces or connections that meet the criteria - set the criteria too weak and get too much crap

set it to tight and get nothing

You have to use the Autodiscovery as a tool to verify certain informaiton and that is it, It does not replace staff crawling on the floor in the DC nor techs updating visio, excel or word documents about things.
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[valawman]

UKVIKING...appreciate the response.

I agree that planning is the key element in all this. Ideally, every service and associated CI's should be defined. What of the instance where this has not been completed for every CI, or there is a CI that is part of a service that has yet to be defined? In some ways it would seem to be similar to what we saw with the CTI structure in Remedy in that it was recommended to include an Item called "Miscellaneous" for those unanticipated issues.

We have been defining services and CI's as part of this project, but we're getting close to deadlines and implementation dates. Another question is at what point do you feel comfortable with what has been defined to where you can move forward? I'm betting that the answer is "it depends."

[UKVIKING]

there are two answers

1 - it depends

2 - Config mgmt is like the movie the never ending tale

once you have gone through and made all the CIs for your services, you have to go back and periodically verify, add, change subtract

It is NOT static
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[StanleyLuces]

CI's not being discovered during the intial roll out is NOT and should not be a concern in my opinion... I believe service management should adapt to the company's changing requirements.. no matter how dynamic it is.

I remember a case study during my OSA wherein a company started out with just Request fullfillment and nothing else.. then grew to inlcude all process and functions as time goes on..

Simply put.. with just your current CI's and categories, roll it out.. then when something new gets discovered - new CI's, new categoreis etc .. then just add it.

I seem to always hear this kind of concern during initial roll out of service management systems and what it does is uneccessarily prolong the roll out date.. dont worry.. no one says you cannot improve on it later on.. ITIL doesnt - "Continual Service Improvement" ryt? =)

[UKVIKING]

All

The initial definition of a service may be fit for purpose when you roll out the tool. For ex

you identified -

EMAIL as a service
You create /allocate servers as CIs.
you create / allocate applications as CIs
you create / allocate system services as CIs

Then after several tickets were raised on the email service as identifed, you realize that EMAIL as a service is actualy multiple services that make up the service called EMAIL

You have a blackberry service
you have executive staff email
you have the normal staff email
you have email filtering (message labs)
you have etc

You now need to adjust / update the CMDB by continually going through the verification and status accounting piece on a periodic basis.

You have identified 10 servers as the server farm for the mail service - however, it turns out that 6 of them are for zzzz and 3 are for xxxx and 1 is for xxx. Are they all production - or test or development servers.

All need to be in the CMDB for the IT SM tool.

The Confug mgmt role does not end merely because you filled in the blanks on the CIs for the servers.

All the fungible - data that expires - data needs to be verified periodically and regularly.

I would be ready to move forward with the CMDB once I have the policy, process and the procedures in place and when the initial set of data is entered and verified as well as defined what is in scope for the initial deployment
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[valawman]

The key issue here is that it is not static. I think a lot of people feel more comfortable if it were, but that is not the case...nor could it be the case. It then becomes incumbent on the organization to decide how to best handle newly identified/newly realized services and their CI's.

I do appreciate the feedback!

[UKVIKING]

valawman

The policy / process documents should define how to identify any new service terminate old services etc

the policy provides the guidance
the process defines what is to be done when
the procedures the step by step
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter