Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
· Home
· Content
· Feedback
· News
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account


The five ITIL books can be obtained directly from the publisher's website:

Or as downloadable PDFs: HERE

Current Membership

Latest: EloyStru
New Today: 32
New Yesterday: 33
Overall: 231680

People Online:
Visitors: 98
Members: 1
Total: 99 .



Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Related Resources

Service related resources
Service Level Agreement

How to set up
IT Change Management
Process Info-Graphic

NOTE: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


Select Interface Language:

Please contact us via the feedback page to discuss advertising rates.

The Itil Community Forum: Forums

ITIL :: View topic - Service Desk involvement in updating CIs...
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Service Desk involvement in updating CIs...
Goto page Previous  1, 2
Post new topic   Reply to topic    ITIL Forum Index -> Configuration Management
View previous topic :: View next topic  
Author Message
Senior Itiler

Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Sat Jan 13, 2007 1:21 pm    Post subject: Reply with quote

Hello Azard,

Please find my response, embedded below...

Azard wrote:
"...nothing wrong with giving them a role in correcting info on front end CI's ", "..if the Service Desk is identified as a sanctioned delegate for the Product Manager, there is no reason why they can't help update the CMDB. "
I disagree. If you have 10 people on the help desk, you can potentialy have 10 different methods of updating data. There is no standarization. The role of the Service Desk is to "restore service" not worry about correcting the data. Who says the information being conveyed to the SD analyst is correct?

Two things, here. First, you would need to teach all 10 of the service desk representatives how to work the same way. If you don't have them working the same way, you already have a problem that has nothing to do with updating the CMDB. They should be creating tickets the same way, handling them the same way, creating reports the same way, etc. Updating the CMDB the same way is just a natural progression to this.

Also, as far as the Service Desk representatives updating the CMDB, this already happens in many companies. Here are some examples of how.

  • The SD staff finds new assets that need to be accounted for in the CMDB (this happens all the time in large enterprises)
  • The SD has the ability to make sanctioned Changes to an end user's personal configuration (sanctioned meaning on behalf of and approved by the Product Manager and/or proper representatives of the Product Management team). As a result, the SD staff is required to update the CMDB to reflect these new changes.
  • The SD staff, as a result of working with end users, finds that there are issues with user facing and/or procedural documentation. The staff is granted rights to instantly update the documentation, so that all users see the updates immediately. A very specific example of this is "FAQs", where the SD staff is constantly answering questions all day long and documenting the questions and their answers as they "appear" for the first time. The generation of the FAQ, when done properly means that the answer might have detailed sequences/directions that require very specific updates to the end user documentation. It happens all the time.

And finally, the role of the Service Desk is "not" just to restore service. It is specifically Customer Satisfaction, as a formally delegated representative of the Product Management team(s). Restoring service is just a small subset of this responsibility. The Service Desk exists to field, trap, and address things (Incidents, Service Requests, Questions, etc.) "before they get back to the Product Management team(s)" These teams typically are represented by Research, Development, & Engineering. This is why the Service Desk is traditionally lower cost labor and more of a commodity service that gets outsourced in many companies. The Service Desk is the "front line", protecting the Product Management resources from having to get distracted by fires (Incidents) that really don't need the more advanced Product expertise Product Management resources.

"Centralized cmdb modification will give you control, but will not keep your cmdb up2date."
I disagree with this. If you arent't able to keep your centralized CMDB up to date, then why have a CMDB? How long before the data becomes stale and is not useable?

This was not my quote but someone elses. I do agree with your position on this.

THere is alot of work that needs to be defined within the Configuration Management process, roles, rights, authorative sources, etc. Those some of the steps that need to be undertaken when deciding others role in updating the CMDB.

Actually, we've implemented Configuration Management, successfully, many times. It's not as hard as you're making it out to be. If you think it's as difficult as you say, you may have some underlying issues in your enterprise that have to do with the way work is performed. Here are some basic ways to updated the CMDB:

  • When infrastructure Assets are built, deployed, modified, and/or decommissioned by Engineering and/or Support teams (manual and through the use of tools that scan the infrastructure for actual state to compare against expected state)
  • When SW CIs are Checked In (automated)
  • When SW build configurations are created, edited, or deleted (manual)
  • When SW is built (automated) (Build includes things like linking and packaging, too)
  • When SW deployment configurations are created, edited, or deleted (manual)
  • When SW is deployed (automated)
  • When SW Initialization & Instantiation configurations are created, edited, or deleted (manual)
  • When SW instances are Instantiated & Initialized (automated)
  • When SW Execution configurations are created, edited, or deleted (manual)
  • When SW instances are taken down (automated)
  • When SW initialization and execution parameters are changes (automated)
  • When SW instances are rolled back (automated)
  • When SW is decommissioned (manual)
  • When new facilities are added, deleted, modified (manual)
  • When new organizations are added, deleted, modified (manual)
  • When New Resources join the organization (manual)
  • When Resource Information changes in the enterprise (manual)
  • When Resources are terminated from the enterprise (manual)
  • When documentation is created, deployed, edited (manual)
  • When End User configurations change (manual) Example: someone gets a new Printer in their office or their office moves from one location to another.
  • Etc... the list is huge but very simple and straightforward.

Anyhow, I hope this information helps you.

Best Regards,

[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
Senior Itiler

Joined: Apr 26, 2005
Posts: 57

PostPosted: Wed Jan 17, 2007 7:07 am    Post subject: Reply with quote

Hi, well it seems there are many thoughts about Configuration Management. But then again, I wouldn't expect anything less here. Smile

Again I want to reiterate the "role" aspect rather than the "person". When I teach ITIL specifically the Service Desk (SD) chapter, I start off by saying the SD wears many hats. I would like you to think for a moment about what process are you in when you write a Change ticket? Change Management? How about when you are finding root cause? Problem Management. I have not stated that these are not performed by those on the SD, but that these are not SD functions. An analyst on SD may in fact do these activities, but then they are not representing the SD, but rather switch their hats to one of the other processes. There are certain activities that need to be followed within each of those processes and the analyst should be following them. I hope this makes sense.

“..the Service Desk representatives updating the CMDB, this already happens in many companies.” I have been in many or spoken with many where this is not the case.

“SD staff finds new assets”. What types of assets are they finding? Why am I not using an auto-discovery tool? It begs the question, why are the Service Desk analyst looking for new assets? If they are finding new assets, this indicates to me, there is a condition that is being missed. Does asset management know about this? If not, why?

“SD has the ability to make sanctioned Changes…” Then they are wearing a Change Management hat.

“…finds that there are issues with user facing and/or procedural documentation.” Unauthorized or untested documentation or procedural changes can lead to serious issues within the infrastructure. Why would anyone other that those supporting be responsible for these changes? Changes to any document, even if it is an FAQ, should still go through “Change Management” (this does not discuss the degree of change management, before anyone says “This should go to a CAB review?”). But there still needs to be formal steps in place, so we can record changes. With high turnovers on a SD, who will be able to say why that change was made?

“…we've implemented Configuration Management, successfully, many times. It's not as hard as you're making it out to be.”. My hats goes out to you for implementing it. From your list, I know you said it wasn’t complete, but to me the most important component that distinguishes a CMDB from an Asset Management / Inventory database seems to be missing, relationships. Configuration Management is about relationships of CIs. If you don’t have relationships define amongst all of the CIs, then you do not have a CMDB. What one has is a well defined Asset / Inventory database.

Is this difficult, you bet it is. We talk about ITIL being about Service Management. How many IT shops have you been in that know what is going on, on the Business side of things? Do IT and the Business have the same view of what a service is? I have yet to see it. How about, what are all the components that make up a service? What level of detail do you get down to? How they all are related? How can I get my Event Management and Monitoring system to feed me events that are useable by the Service Desk? How can I then take this information and ensure Change Management co-ordinates with Release and Configuration to mimimize impact to the business? How do I get all my service targets measurements defined in Service Level Management from Incident Management? Where should all this information be kept? How does someone using a “desktop” support the business service? The list of questions go on.

“Let's take a simple example. I call my ISP because my DSL has problems connecting to the Internet.” Based on this, I am not sure what “ changes” are applied but if you are saying the modem is the CI, then, they would be using a tool to get this information and it would update its own Database. Should this information be part of the CMDB, that needs to be determined as changes to a CI require it to go through Change Management. Would you want a change record to be created every time something is changes? Depends on the business needs.

“Let's take another basic example. I call my ISP because I am changing phone number.” Are you saying that people records are CIs? That is another debate on itself. 
If it is phone number change, where did the original contact record come from? Did someone manually enter it? Does your ISP have 1-2 million customers like AOL? That is a lot of manual work. What if there was an address change taken over the phone. If this is not tied to billing, then I am not sure I would want the SD changing the information as I want to make sure the clients continue to pay their bill and are not just providing incorrect information.

“A true Service Desk performs the activities of Change Management, Release Management, Configuration Management, and potentially even Problem Management.”

Taken from the ITIL cds 4.5.1 copyright 2000. This is what I taught on.

“It not only handles Incidents, Problems and questions, but also provides an interface for other activities such as customer Change requests, maintenance contracts, software licences, Service Level Management, Configuration Management, Availability Management, Financial Management for IT Services, and IT Service Continuity Management” Key work here for me is “interface” Again I go back to my wearing many hats.

While I know there are many thoughts on Configuration Management, and there is the need to put “pie in the sky” theory into practice, I still come back to the basics and ask “What is Configuration Management about?” and work from there.

Azard Omardeen
ITIL Expert / Accredited Trainer / ITSM Consultant
Back to top
View user's profile Send e-mail
Senior Itiler

Joined: Aug 11, 2006
Posts: 262
Location: Netherlands

PostPosted: Wed Jan 17, 2007 10:31 pm    Post subject: Reply with quote

"Centralized cmdb modification will give you control, but will not keep your cmdb up2date."
I disagree with this. If you arent't able to keep your centralized CMDB up to date, then why have a CMDB? How long before the data becomes stale and is not useable?

This was not my quote but someone elses. I do agree with your position on this.


The quote was mine actually. It is only a relative comparison, not an exact statement. Let me explain:

When the execution of configuration management (i.e. the altering of CI's in the cmdb) is centralized in a larger organization, this creates more distance between the specialists who own and maintain the infrastructure (such as your product managers Frank), and those who maintain/adjust the cmdb. This centralization gives more control on the quality of the cmdb (e.g. you do not have to instruct 10 service desk employees and 10 techies from different departments how to work in the cmdb).

However, this distance is greater than in a decentralized config. mgt, where you let people in different departments work on the cmdb. Thus, in a comparison, the risk of your cmdb being not up2date is greater in the former situation. Of course, the problem with the latter situation is that you loose control of your process to some extend (relatively that is), as you have to manage more people who have an active role in config. management.
Back to top
View user's profile Visit poster's website
Senior Itiler

Joined: Sep 27, 2005
Posts: 207

PostPosted: Wed Jan 17, 2007 11:32 pm    Post subject: Reply with quote

With no intention to cultivate controversy, or to sell the merrits of a specific vendor, this is an important part of why HP made the $4.5Billion acquisition of Mercury last year: Federated CMDBs.

As you recognize the need to manage users as CIs, you need to evaluate who, in the organization, is in the best position to manage that information. In this case for instance, there are many examples where the HR department is going to be the source of information. In most companies, HR is already using a database to manage user information. Therefore, it becomes a matter of definining the conditions to use and maintain that source of information and to consolidate it with the CMDB by some process, either synchronization, replication, direct updates, etc.

Depending on your type of business, you will elect to track certain items and you may find that certain existing groups are in a better position than others to maintain the information.

I'm not sure whether centralized configuration management is better than distributed or vice versa. One of the strengths of ITIL is actually to recognize that. They both offer advantages and challenges. What matters is how it fits the organization.

But what I know is that we live in distributed environments, not just from an IT standpoint but from a business standpoint as well, and that it is not going away. What I know is that we seem to be constantly moving towards more complexity, not less, and that we are always seeking more versatility in our system, which adds to the volume of work in maintaining a CMDB.

To me, what is important is that the management and control over the process and audit be centralized to keep one point of accountability. I like to keep the rest dynamic enough to fit most organizations.
Fabien Papleux

Technology Consulting | Service Excellence
Red Badge Certified

Twitter @itilgeek
Back to top
View user's profile Send e-mail Visit poster's website MSN Messenger
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Configuration Management All times are GMT + 10 Hours
Goto page Previous  1, 2
Page 2 of 2

Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops © 2003

Forums ©


Logos/trademarks property of respective owner. Comments property of poster. Rest © 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.