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.

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.

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.

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.

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.)

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.

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.

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

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.

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

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

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.

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.

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

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.