UNCLASSIFIED

Not yet using CMDB.  

We are using the IUID in Asset Management.  Gov't purchasing requires
that companies we purchase from provide it and we use a barcode scanner
to bring in new data.  The IUID is actually a construct; routinely make,
model, serial number. 

Dell, for one, will provide a terrific data file for the equipment
purchased, identifying items by the IUID.  On receipt of the data file,
usually a week or two after equipment delivery, we know just what should
have been received. And from the scan at the warehouse, we know what was
actually received.  The scan imports directly to the Asset record and I
have a form to which I import the data file.  An Escalation synchs the
new data with the Asset Record, matching by IUID and Serial number.
After synching, the Status of a Validate record is changed to
"Completed".  Records that didn't synch we know by Status and know what
doesn't match between the files.

For the CMDB, my plan is to use a Discovery tool. BeLarc System
Management Discovery tool is one product that will pull the IUID from
the BIOS.  YOU set up when to scan, when to synch data.

Sandra Hennigan

Enterprise Remedy Administrator
Office # 703-602-2525 x251
CACI - Ever Vigilant

Apparently, there is nothing that cannot happen today.  Mark Twain

-----Original Message-----
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 1:42 PM
To: arslist@ARSLIST.ORG
Subject: Re: Real-World Value of SMS & CMDB (U)


You're putting this information in your CMDB through some automated
process? How often does it run?

-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Hennigan, Sandra H CTR OSD-CIO
Sent: Thursday, June 28, 2007 11:55 AM
To: arslist@ARSLIST.ORG
Subject: Re: Real-World Value of SMS & CMDB (U)

UNCLASSIFIED

*****You don't set the owner relationship from a last logon value!" OK,
fine...where does it come from, then?**** Using the Item Unique
Identification (IUID) label, read from the system BIOS (Label is also
affixed to machine) is one method to determine "the" machine.

Sandra Hennigan

Enterprise Remedy Administrator
Office # 703-602-2525 x251
CACI - Ever Vigilant

Apparently, there is nothing that cannot happen today.  Mark Twain

-----Original Message-----
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 12:09 PM
To: arslist@ARSLIST.ORG
Subject: Re: Real-World Value of SMS & CMDB


** 

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: arslist@ARSLIST.ORG
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: arslist@ARSLIST.ORG
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___ __20060125_______________________This posting was submitted with
HTML in it___

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

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

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

Reply via email to