Norm,
I hear you, and in some cases I have to agree with you. However I
think we will agree that because an implementation fails it does not
mean that the plan was flawed. Sometimes the failure is due to actions
taken, or not taken, by those that actually did the work. Which is
why ITIL is just a plan. It is not a step by step "follow the bouncing
ball" list of work breakdown. The overall plan is to measure what is
important and track the details so that the important stuff is well
understood at the needed points in time.
But just to point out a few ideas.....
You said:
"
- My account is locked out.
- I can't get to XYZ website.
- How do I set up an email profile on my new computer?
- I need a new network password.
- How do I access the terminal server from home?
- How do I change this outline format in Word?
- My printer needs toner.
- I need my voicemail set up on my phone.
In each of these cases, does the data in a CMDB help me? HECK NO!
"
And I have to disagree, and below is why I disagree in detail. I will
take each of the above and point at CMDB data that could be useful to
the issue at hand. IF your CMDB has the data in question. If the data
is not in the CMDB, then it can not be used to help the customer. :)
And if you just do not have the data anywhere... then your Service
Desk is just shooting in the dark.
- My account is locked out.
The CMDB could hold account data. This can be helpful for
"decommissioning" when the user leaves the company. (retire, quit, get
fired type conditions) Having the basic account data can also work as
a seed so that the SD (Service Desk) can "launch", or in CMDB terms
federate, into the system(s) that have been locked to determine why it
was locked and possibly to "unlock" the other system from inside ARS.
(We do 99+% of password resets for our Kerberos system from inside
ARS. Our Service Desk does not leave a Remedy screen to check the
status of an account or to change a password.
No we do not have a CMDB, but we do have all of the account data
in ARS in a custom application already. And we have does this for
about 9 or 10 years. We have our own "form of a CMDB" for account
data, people data, and some other IT
components(servers/desktops/etc..). The thing is that they are not in
a fully integrated approach with full relationships between them. We
do not currently have an easy way to pull "one string" of the data and
see all of the other stuff that is above or below that one data point.
We hope and expect that the CMDB will help us get to that
functionality too.) From where we are to what the CMDB could give us
it is a logical step to go from here to there. (Or we will end up
building it ourselves.)
- I can't get to XYZ website.
This one is easy. Where is the user coming from? Where are they
going? Is the network components between the two points up? All of
that could be in your CMDB. (And likely should be in your CMDB.)
- How do I set up an email profile on my new computer?
Again, an account question if I have ever heard one. What
"server", client, settings should person "X" be using? Well the
Service and account data that should be in the CMDB and related to
"person X" should tell you all of that. (With maybe a link to a KB
article for step by step instructions for each client that is
supported.)
- I need a new network password.
If you buy into the idea of "Self Service is best" then the
application that lets a user activate there account should use CMDB
"people" data to decide if the person is eligible for a new account.
(Maybe they already have one, maybe they are not a "known person",
etc..) And ... When the account is created... it should land in the
CMDB. (See above for reasons for that.)
- How do I access the terminal server from home?
Again... Is the service something that "person X" is authorized
to use? Do they need an account first? Is the service in a maintenance
or outage window? (CMDB data baby!)
- How do I change this outline format in Word?
Ok... Fair enough.. That is just a KB article. Well... unless you
start with the question of "Do we care to even talk to the caller?" If
you need to first identify your caller so that you know you want to
spend any time helping them... then you should loop back to your CMDB
for people information. :)
- My printer needs toner.
Yea... not sure that really should be handled by the service
desk. Routed by the service desk to your purchasing process, sure. But
I really doubt that the SD should be doing anything other than
pointing the user in the right direction.
- I need my voicemail set up on my phone.
Again... do they have a phone assigned to them that the service
desk can help with? Does there phone already have voicemail setup on
it and the user really just does not know the password? (CMDB data.)
So I think your idea of what CI (Configuration Items) should be in the
CMDB is quite a bit more limited than what I think should be in the
CMDB. And it might be that we are both right. :) My company might need
more CI's because we are more "security minded" and require more
"authorization" than your company. (or more likely the other way
around. :)
For me... most of the ITIL concepts are really stuff that we are
already trying (and have been slowing moving toward) to do. The only
real value is that it allows us to "follow the flag" instead of trying
to convince others in our company that "we know what were doing wrong
and we need to do "x" to fix it.". We can simply point at a "standard"
and then workout the implementation details from there. If your
company wants to do "OOB" then they likely want to do "ITIL" for the
same reasons. They get "buy in" by saying "best practice" or
"standard" and get to move on to the "Now how do we do that?"
discussion faster.
JMHO.
--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)
Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap.... Pick two.
On 6/27/07, Kaiser Norm E CIV USAF 96 CS/SCCE <[EMAIL PROTECTED]> wrote:
Matt:
Thanks for your well thought out input. The issue, though, is I'm
curious about REAL WORLD usage and success. I've already heard all the
sales pitch, the promises, and the campaign spiels. I've heard all the,
"With ITSM/CMDB you WILL be able to do this...you CAN do that."
I want to hear, "We ARE doing this...we ARE doing that and our
business/organization is X percent better!"
Theories and ideas are great, but I've learned from many, many, many
real world experiences that often when you attempt to put the theory
into effect (i.e., actually USE the thing), it doesn't pan out. The
data collected is not good, or worthless, or too voluminous. Or the
system "cries wolf" too often. Or the benefits don't outweigh the
overhead (administration, process, bureaucracy) needed to make it go.
Etcetera.
I'd really be curious to watch a service desk analyst--someone wearing a
headset and fielding calls in a very busy call center--consume any data
provided by a CMDB.
Granted, environments are different, but in my experience the bulk of
the calls fielded by the Help Desks (ahem..SERVICE Desks) I've been
around (and trust me--I've been around a lot of them) are for problems
like...
- My account is locked out.
- I can't get to XYZ website.
- How do I set up an email profile on my new computer?
- I need a new network password.
- How do I access the terminal server from home?
- How do I change this outline format in Word?
- My printer needs toner.
- I need my voicemail set up on my phone.
In each of these cases, does the data in a CMDB help me? HECK NO! If I'm
working the Help Desk and a customer calls and asks me to help her set
up an email profile, do I care how fast her processor is? How much
memory is in her workstation? What type of video card is in her
workstation? What make/model her workstation is? HECK NO!
Now for those of you who argue that the CMDB helps you track
changes--especially unauthorized changes--that's true, but I say there
are other common auto-discovery tools on the market that do that...and
do it better.
Norm
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers
Are"
