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

Current Membership

Latest: PSchoonov
New Today: 62
New Yesterday: 55
Overall: 139875

People Online:
Visitors: 74
Members: 0
Total: 74

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

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.


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 1, 2  Next
 
Post new topic   Reply to topic    ITIL Forum Index -> Configuration Management
View previous topic :: View next topic  
Author Message
quickbasset
Newbie
Newbie


Joined: Dec 19, 2006
Posts: 2

PostPosted: Wed Dec 20, 2006 4:42 am    Post subject: Service Desk involvement in updating CIs... Reply with quote

I am the team lead for the Service Desk at Company X. We are the hosting supplier for Company Y. We are planning our Configuration Management processes, and I have a question concerning the Service Desk's involvement with updating CIs in Company Y's CMDB. For example, it has been discovered during incident resolution activities that a Company Y-CMDB CI is not accurate. What is the process for correcting the identified inaccuracy (when Company X, the hosting company, identifies the error in Company Y's CMDB)?

Should a low severity incident record be opened and sent to Company Y (both are using the same incident management tool)? If so, is that a role of the Service Desk?

Should a RFC be opened to correct the CI?

I'm new to ITIL, but it seems these activities are outside the scope of most Service Desks. Any opinions would be much appreciated.
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3292
Location: London, UK

PostPosted: Wed Dec 20, 2006 5:48 am    Post subject: Reply with quote

It is the role of Configuration Management to ensure that all of the CIs are accurate.

Is the SD part of X or Y ?

Who is responsible for ensuring the CI data is accurate ?

A Change Record would be needed to correct a CI.

Usually a Change Record like this would be based on the incident which discovered the error - no additional Incident or Service Request needs to be raised.

There needs to be Configuration, Change and Incident management processes and procedures which should be covering this
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
quickbasset
Newbie
Newbie


Joined: Dec 19, 2006
Posts: 2

PostPosted: Wed Dec 20, 2006 6:07 am    Post subject: Reply with quote

Thanks for the reply. The Service Desk is part of Company X. Currently, Company X has a "temporary" person filling the role of the configuration manager, until they get things up and running. So this person is responsible for ensuring the CI data is accurate. It makes sense that the Change Record would be based on the incident which discovered the error, and there is no need for an additional incident record. But what if the CI inaccuracy wasn't found during incident investigation? For example, if a DBA with Company X finds a problem with a CI in Company Y's CMDB. The DBA wants to notify the customer of this inaccuracy. Not necessarily an outage per se, just something in their app that needs tweaked. How should the DBA get the ball rolling? Through the SD? The DBA discovered it poking around let's say, not because of an already existing incident.
Back to top
View user's profile
m_croon
Senior Itiler


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

PostPosted: Wed Dec 20, 2006 7:25 am    Post subject: Reply with quote

Hi Quickbasset

First of all, part of your config. proces should describe how any cmdb within it's responsibility is frequently audited for consistency, completeness and being up to date. Your DBA "poking around" seems to be doing just that, although possibly in an unofficial / incomplete / not structured manner. Why not combine it? Talk to the DBA and see if he/she wants to do a regular check, where you agree about the way it is checked. That way, you can put it down in a procedure.

I am not entirely sure what you mean with "the customer's CMDB". What about cmdb-ownership and maintaining it? Is this a cmdb which contains the CI's regarding the service to company Y, the cmdb being maintained by your company X? Is this a cmdb which is owned and maintained by company Y? I used to work for a company where all techies had limited rights in certain CI-fields. This way, they could indicate within the CI that it was not registered right, without giving them the opportunity to actually alter fields such as CI status. The CI's with a "fault" indication where simply checked at the end of the week by a central CMDB-responsible person who did the actual changing of CI's. Of course, if your cmdb is actually managed by company Y, this would not be possible. Also, it is tool-dependant.

Hope this helps,

Michiel
Back to top
View user's profile Visit poster's website
Azard
Senior Itiler


Joined: Apr 26, 2005
Posts: 56

PostPosted: Fri Dec 22, 2006 11:53 pm    Post subject: Reply with quote

Hi, my stance is a a little firm on this. Smile

Under no circumstance should the SD update any CI information. All modification to CI information needs to be accurate. This should be done through the change management process. The only process that can update the CMDB is Configuration Management. If you allow multiple sources to update, how effective is your verification and audit process?

There may be something in place you could do to help ease the types of changes as you don't want to burden the change management process, but you still want to track these modifications, to find out why and who are making these changes. There may be something going on that needs to be looked into.

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


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

PostPosted: Sun Dec 24, 2006 11:10 am    Post subject: Reply with quote

Hello Azard,

Actually, in your recommendation, the CfM group becomes a bottleneck and will not scale in large enterprises. It is not possible for one group to handle all updates to the CMDB. The information within it can be immense.

A more realistic scenario is that the CfM group simply has the responsibility of ensuring that the CMDB is being updated and/or has been updated properly, along with the responsibility for ensuring that the processes for updating the CMDB have been defined, communicated, and followed.

Also, in a highly advanced enterprise, the CMDB is updated at the time that the Asset is built, by the engineer or developer. Also, a good CfM group ensures that many different types of Configurations are in place:

  • Design Configurations
  • Build/Implementation/Packaging Configurations
  • Deployment/Distribution Configurations
  • Installation Configurations
  • Instantiation & Initialization Configurations
  • Execution Configurations
  • Rollback Configurations
  • Failover Configurations
  • Backup Configurations
  • Etc. (NOTE: There is also a "verification" permutation for each of the above line items.)

A good deal of the above is created by different groups and/or stakeholders at different times in the Product Management process. The CfM team cannot possibly be involved in this. It is, therefore, more realistic to ensure that the appropriate Configurations are being planned for, created, stored, and managed properly than it is to be involved in the registration of "all" of this information. Therefore, I highly recommend that the CfM group "not" be the group that updates the CMDB, since experience tells me that each specific type of Configuration is the responsibility of the group that defines and creates it. (e.g. A Design team is accountable for Design Configurations; an Implementation team is responsible for Implementation Configurations, etc.)

Anyhow, I hope this helps.

Best Regards,

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


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

PostPosted: Tue Dec 26, 2006 10:13 am    Post subject: Reply with quote

I agree with Frank here:

First of all, the service desk is usually an active part of the change management process, be it only/mostly as a registration party. There is nothing wrong with giving them a role in correcting info on front end CI's (service desk is active in >1 process, as most departments are).

Also: tracking modifications should be provided by a proper config tool, no matter who does the modifying (service desk or other).

Proper config. management includes making a very important choice: where do you want the balance of keeping control versus keeping up to date to be? Centralized cmdb modification will give you control, but will not keep your cmdb up2date. Decentralized modification works the other way around. I've worked in IT organisations from 10+ to over a 1000 employees, and especially in the larger organisations, a config "team" should get in control of the process instead of the quality of the cmdb (which is then more of a decentralized responsibility).

Cheers,

Michiel

Azard wrote:

Under no circumstance should the SD update any CI information. All modification to CI information needs to be accurate. This should be done through the change management process. The only process that can update the CMDB is Configuration Management. If you allow multiple sources to update, how effective is your verification and audit process?

There may be something in place you could do to help ease the types of changes as you don't want to burden the change management process, but you still want to track these modifications, to find out why and who are making these changes. There may be something going on that needs to be looked into.

cheers,
Back to top
View user's profile Visit poster's website
Guerino1
Senior Itiler


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

PostPosted: Wed Dec 27, 2006 1:36 am    Post subject: Reply with quote

Good Day All,

I believe it's important to note that the "Configuration" for a Product ultimately belongs to the "Product Owner" and that there are so many different types of Configurations that get created and need to be managed, as part of the Product Management process, that it becomes imperative to understand that the stakeholders and organizations that record and manage appropriate Configurations are doing so:

1) As a acknowledged delegate of the Product Manager, and
2) On behalf and for the Product Manager

Now, it is important to understand that there are many different types of Products that are constantly being worried about, in an enterprise. For example, a software system that gets deployed to your production environment might be on. Also, the Production Data Center, itself, might be a Product that is also being managed by its own Product Manager. It is in the case of managing individual and separate Configurations that the bigger picture starts to show itself, as each Configuration is a small piece to a large puzzle, which is the Configuration of the enterprise. Each and every individual Configuration has information that intersects with information in many other Configurations. It is this common or intersecting information that allows you to generate super Configurations, which take into account bigger picture views.

Ultimately, 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. It would simply need to be a controlled and fully audited process, just like any other critical process you maintain in your enterprise. This, for example, would allow you to see who updated the CMDB, when they updated it, why, how, etc. As long as you have a process to check & audit your Configurations on a regular basis, "who" updates the CMDB shouldn't be a real issue.

Anyhow, I hope this helps.

Best Regards,

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


Joined: Sep 27, 2005
Posts: 207

PostPosted: Fri Dec 29, 2006 5:06 pm    Post subject: Reply with quote

Azard wrote:
Under no circumstance should the SD update any CI information. [...]This should be done through the change management process.


I understand where you're coming from, but in principle there is nothing that prevents someone on the SD to be part of the Change Management and Configuration Management processes at some point and under certain circumstances. It would seem rather efficient, depending on the exact nature of the change, to define standard changes that would allow Service Desk operators to record and execute a change to the CMDB as they find inconsistencies. After all, they are the ones with their fingers in it all day...

My 2 cents...
_________________
BR,
Fabien Papleux

Accenture
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
Azard
Senior Itiler


Joined: Apr 26, 2005
Posts: 56

PostPosted: Fri Jan 12, 2007 11:49 pm    Post subject: Reply with quote

Hi, while you have all raised some good points, I have also consulted at some very larger orgainizations more recently including the NYSE, where the environement is very dynamic and managing configuration items become critical and have some experience on this subject. Smile

"the CfM group becomes a bottleneck and will not scale in large enterprises."
I disagree. Correct me if I am wrong, but I get the impression that many people have taken my comments "The only process that can update the CMDB is Configuration Management". To represent a single Role. That is not the case, as I state it is the Configuration Management process, not a single role.

"It is not possible for one group to handle all updates to the CMDB.".
I fully agree with this, and we have done just that, giving control to the groups who own and are familar with the products. Again we are talking about a roles.


"...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?


"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?

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.

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


Joined: Sep 27, 2005
Posts: 207

PostPosted: Sat Jan 13, 2007 12:05 am    Post subject: Reply with quote

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?

Nobody does. Who says the information being conveyed to someone beyond the SD is correct? If the information was not right coming in, anyone is weak link Azard. The SD is not a role or a process, it is a function as you know. It would be a mistake to disregard SD operators in your configuration management process design as they often have a role to play in it. And it would be a mistake to communicate here to people seeking answers that it should not be done/evaluated/investigated or even implemented.
_________________
BR,
Fabien Papleux

Accenture
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
dboylan
Senior Itiler


Joined: Jan 03, 2007
Posts: 189
Location: Redmond, WA

PostPosted: Sat Jan 13, 2007 12:08 am    Post subject: Reply with quote

I would have to argue that the Role of Updating CIs is very likely a distributed one in a large organization. This is because large organizations are going to have a distributed Change Management structure. Remember that all updates to a CI should be traceable to a RFC. This may be a Standard Change that doesn't have to go through the overhead of a Change Control Board, but still there should be a RFC for every CI update.

In large organizations, the Change Management process is usually a hierarchical structure based on region or the organization's divisions. This means that many different people might be authorized to open Standard Changes. Since Standard Changes are pre-authorized for the individual opening the RFC, the subsequent update of the CI is in effect also pre-authorized.

This means that the Service Desk personnel might, in fact, be authorized to update a CI. But, that level of authority is actually controlled via Change Management's delegation of opening Standard Changes.

In a perfect world (ITILTopia), the actual updating of the Status or Attribute of a CI would be updated auto-magically upon the submission of the Standard change.
Back to top
View user's profile
Azard
Senior Itiler


Joined: Apr 26, 2005
Posts: 56

PostPosted: Sat Jan 13, 2007 4:49 am    Post subject: Reply with quote

hi, I totally agree with you that the SD should be involved in the Configuration design, but that is a different discussion, which is very different from "SD involvement in updating CI information".

One thing I found through consulting and teaching is many people confuse roles with people within their organization. Just to clarify, my context is around roles, not people.

As for:

"Who says the information being conveyed to someone beyond the SD is correct?"

if you a have properly defined configuration management process which identifies what the authorative source(s) of data is, then you do you know what information is correct. If the SD desk is an authorative input source (which in my opinion it never should), and as long as you have proper verification and audit activities (Configuration Management process) in place, then what you have done is elected to have the SD also do:
- Change Management - create a change record with the updated information.
- Configuration Mgmt process - modify the CI information

Some one still needs to validate that the CI information is correct. Who does this? This falls under the control of the Configuration Management verfication and audit activities.

The SD are users of the configuration management information to help them restore service as quickly as possible. They do not manage the infrastructure, network and hardware components etc. Other groups do that, unless you have a very small shop, then you may have one person or several people performing different roles.

What do you do with autodiscovered information? Does the SD have the ability to overwrite this information as well? What happens if it gets replaced with the next occurrence of the discovered information? What about if you have integrated data feeds from other sources? Which information is deemed correct? These are all points to consider during the design phase. There should be representatives from the SD and others service management areas involved as they will be using the information provided to them by Configuration Management.

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


Joined: Sep 27, 2005
Posts: 207

PostPosted: Sat Jan 13, 2007 5:06 am    Post subject: Reply with quote

Azard, I just think you are being too restrictive in your interpretation. Most of your questions are valid and need to be taken into consideration. But on the same token, what makes the 'auto-discovered' information more accurate? For all you know, an auto-discovered update may happen following to an unauthorized change. You can't just assimilate the new information without your audit/verification process, either way you look at it. But your SD is a source of information, and a source of potential workload relief for common, controlled and defined changes and CMDB updates.

Let's take a simple example. I call my ISP because my DSL has problems connecting to the Internet. They're going to ask me to power cycle the modem, blabla... then they are going to verify my box configuration and, if something is different than the standard they have defined, they will change it to what it should be. right? Thus they applied a change to my config and they will record the information themselves. They matter-of-factly updated the CMDB... and maybe this is a bit of a stretch.

Let's take another basic example. I call my ISP because I am changing phone number. I connect using cable so my phone line has nothing to do with the service itself. They will take my phone number down, update my record (thus update their CMDB) and hang up.

I think you're looking at a whole lot of other things. I am interested in understanding more of where you're coming from on this. Can you give me examples?
_________________
BR,
Fabien Papleux

Accenture
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
dboylan
Senior Itiler


Joined: Jan 03, 2007
Posts: 189
Location: Redmond, WA

PostPosted: Sat Jan 13, 2007 6:52 am    Post subject: Reply with quote

Azard wrote:
The SD are users of the configuration management information to help them restore service as quickly as possible. They do not manage the infrastructure, network and hardware components etc. Other groups do that, unless you have a very small shop, then you may have one person or several people performing different roles.


I will have to disagree with this statement. A Service Desk that does nothing but Incident Management is not a Service Desk. That is the definition of a Help Desk. A Service Desk is a Help Desk that also supports IT in delivering and supporting IT processes outside the Incident Management process. A true Service Desk performs the activities of Change Management, Release Management, Configuration Management, and potentially even Problem Management.

If all you have experienced are un-empowered Help Desks, then you might have concerns about giving them greater roles in the other processes. I would argue that a truly empowered Expert Service Desk is well positioned to perform many of the actives of all the operational processes, regardless of the size of the organization.
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Configuration Management All times are GMT + 10 Hours
Goto page 1, 2  Next
Page 1 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 http://www.nukecops.com

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.