Norm, You said: " 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. "
I want to make sure that you understand that I think all of your stated concerns, and opinions are well thought out and well formed. I would even go so far as to say that if your company has the time and resources to train all users on all applications, and the users are capable of keeping all of that straight then a "specific tool for the specific job" approach does make sense. And that the CMDB (or any specific ITIL process for that matter) will likely not replace any of those "specific tools". However... One of the values/benefits of ITIL is that is that is it unifying the terms and approaches that are used to deal with IT. I believe that this should include the UI layer too. Maybe ITIL does not speak to this(user UI), but I think one the effects of having a CMDB is to unify the data source behind the UI. And as a likely effect is to unify the UI. After you consider federation of the data from the CMDB out to other "specific tools" I think you will start to see why the CMDB is the key part to ITIL. The point of the CMDB is to put the map together with. So that you can attack the data from any "business" or IT angle that you want to start from. Then walk the rest of the related data back to the more technical or the more business ends. Each of the examples you listed start in different places for the diagnostics. Part of the ITIL Service Desk(SD) process is to unify the diagnostic process. This allows the caller to "start anywhere" and the SD can walk through the business and technical details as needed. All of the "are you someone that we want to help" questions are answered as well as the pointers out to remote control tools, or real time network monitoring tools, etc... too. But it starts from a SD screen. Through the CI's and out to the "specific tools". That generalized process should solve all the issues you listed. (given that some of the "specific tools" could include knowledge bases. Word could be an installed software on a desktop that tells you you can support word for that user. Some users might not "have support" for MS Word, and others might.) And just to pick on the new scenario a bit too... You said: "That alone presents issues—how, exactly, do you identify the true user of a workstation?" I think the answer is that there is not only one person in that list. :) The asset is owned by a part of your company. (There is at least one group/person.) That asset could be used primarily by one user, but that is really momentary. (And in some orgs it is as dependent on the physical location as the logical org.) And that data could most accurately come from things like actual logs of who used the asset. (login time logs for a workstation, or a checkout sheet for a video camera or overhead projector. :) And what business functions are effected by that asset being "down" (or "lost",etc..) can be determined if you can know what it is used for, and by whom and when those things matter. Most of that is not "discoverable", but needed to be entered manually and kept up to date. The point of the discovery tool is to do the data entry that can be done automatically. The point of the reconciliation engine is to keep matching that raw data back to the "better" and more business centric data that is added/wrapped around the discovery data. The point of the CMDB is to store all of that in a uniformed/searchable/standard way. The point of what you push into your CMDB is anything that you think is needed to be accessible by any of the ITIL processes. You can search and walk it in one way, with one tool, and then "jump out"(federate) to more specific details/tools when needed. And that the amount of details that should be in the CMDB very as much as "what things" should be in the CMDB. It is about how big your ITIL sphere is in your company, and what tasks you want your CMDB to be able to do for you. And at the end of the day..... If your company is already "doing ITIL" but not calling it "ITIL" then there really are no changes to be made. ( Except the words you use to describe it. ) If however, you find that the process flow is not "ITIL" then your company should decide if there is any value in changing how your processes work. They may find that there is to much cost for the change (right now) and that they should not change anything. They also could find that there are some of the steps that could be simplified/consolidated if they shift how they report (monitoring) outages and changes to the SD before they happen. IMO, most of the value of ITIL will be hard to measure from a budget perspective because most of the savings are the phone calls that you will not get because a more holistic approach to IT has been achieved. (Again, if your not already doing that. :) ) And that can be a hard sell to the bean counters. However, most IT shops are not holistic in their approaches, and that concept is generally a no brainier to an IT person who has been effected by someone else "change" that "should not affect anyone else" and did. Maybe part of the "different perspectives" that we are approaching ITIL from has more to do with the realities of our IT orgs than the things that we find important or useful to manage IT type issues. :) -- 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/28/07, Kaiser Norm E CIV USAF 96 CS/SCCE <[EMAIL PROTECTED]> wrote:
** 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.
<snip>
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.
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
