I don't know folks...I'm still not seeing it.  Again, I understand the
theory, but in the REAL WORLD I don't much practicality in it.

 

You made a great point-if I want to link incident to asset, I could pull
from the auto-discovery inventory...not pull from redundant data in the
Remedy server.

 

That alone presents issues-how, exactly, do you identify the true user
of a workstation? Here in our environment we have thousands of machines
that are logged onto by multiple users.  Who's the owner? One day a
fighter pilot logs onto machine A to check his email.  The
auto-discovery runs and "identifies" the pilot as the "owner" of machine
A.  The next day, the navigator logs onto machine A and gets an error
when he tries to open email.  So he calls the Help Desk.

 

The Help Desk analyst says, "Hey...let's use this newfangled ringy-dingy
ITSM thing to figure out what machine he's working on..." but lo and
behold the thing does not show that the navigator is using machine A,
because as far as it knows, machine A is owned by the fighter pilot...

 

So then you say, "Oh, no, no, no, Norm! You don't set the owner
relationship from a last logon value!" OK, fine...where does it come
from, then?

 

My point-data does not "magically" appear in the CMDB.  It gets there
via two different methods-some automated pull or by hand-jam.  But the
automated pull runs on some delayed schedule from another data source
that, in turn, may run on an automated schedule.  Thus, the data is
STALE.

 

In order to realize the benefits a lot of folks are touting, DATA MUST
BE REAL-TIME or darned-near close to it.

 

________________________________

From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of David Sanders
Sent: Thursday, June 28, 2007 10:40 AM
To: [email protected]
Subject: Re: Real-World Value of SMS & CMDB

 

Hi Norm

 

Well, look at it from another angle.  Does a CMDB add value at the
center of your service desk operations when all break/fix incidents and
planned change requests are linked to the relevant CI records?

 

For Incidents, you build up a picture not only of frequent Requesters
(training issues highlighted?), but also of problem hardware types or
patterns of issues that can then be addressed separately (as Problem
tickets?).

 

For change requests, the ONLY way you stand a chance of managing changes
is if you have clearly identified what assets or other CIs are being
changed, evaluate and authorize the changes, and than afterwards review
what has been done.  Discovery tools may give you an asset inventory to
do part of this, and may discover some physical topology (this database
runs on this virtual server, on this hardware; it uses this
switch/router etc.).  What auto-discovery can't give you is how this
fits into business processes, like this database is used for payroll,
which is part of HR systems, and who the dba is, who the Payroll and HR
business owners are, etc.  If changes are planned to this database, the
owner of the HR processes may need to be informed and to approve the
change and the schedule. The change may need to be assigned to the
correct dba.

 

The Incident linking part you can probably do with just auto-discovered
asset inventory, but the change stuff really needs the business context
information to be useful.  A decent CMDB will provide the business
context around the asset inventory, and will include people and process
links.  It will allow you to assess risk, business disruption and costs,
and plan changes properly. There is value there, but I'm not sure if
that value justifies the cost and effort involved in acquiring and
maintaining Atrium and SIM for your organization. Only you can answer
that question.

 

Regards

 

David Sanders

Remedy Solution Architect

Enterprise Service Suite @ Work

==========================

ARS List Award Winner 2005

Best 3rd party Remedy Application

 

See the ESS Concepts Guide
<http://www.westoverconsulting.co.uk/downloads/ESS_Concepts_Guide.pdf> 

 

tel +44 1494 468980

mobile +44 7710 377761

email [EMAIL PROTECTED]

 

web http://www.westoverconsulting.co.uk
<http://www.westoverconsulting.co.uk/> 

 

________________________________

From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Kaiser Norm E CIV USAF 96
CS/SCCE
Sent: Thursday, June 28, 2007 2:40 PM
To: [email protected]
Subject: Re: Real-World Value of SMS & CMDB

 

I think we're coming at this from two different perspectives.
Agreed--the CMDB might be somewhat useful if you are in an environment
where NO OTHER AUTOMATION TOOLS EXIST.  But I was coming at this from
the perspective that certain "standard" network monitoring/management
tools are already in place--HPOV, AD, SMS, SNMP, etc.

For the sake of keeping a fruitful discussion alive, allow me to
counter:

__20060125_______________________This posting was submitted with HTML in
it___

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the 
Answers Are"

Reply via email to