Chasing, To me, 'owner' is a misnomer, even though ITIL uses that wording. Try 'responsible' as used in a RACI chart.

The Configuration Manager is accountable for the process of ensuring every CI in the CMDB is correct. Your owner, I think, is responsible for ensuring that the certain CIs are correct. If CI data is discovered to be incorrect, the Config Mgr verifies the discrepancy with the responsible party.

Who decides when the CPUs are turned over, when they’re upgraded to the next OS, when the next version of Office is installed? Answering those questions may help you determine the responsible person. BUT, if it makes sense for your organization to have the person who physically upgrades the desktops responsible for those CIs and their attributes, that’s fine, too.

If you have comprehensive ITSM tools, your change tool can automatically update some attributes of the CI. An autodiscovery tool can help flag differences in some attributes of the CI (comparing what the tool sees with what the CMDB says). That said, some attributes and relationships cannot be updated or discovered without manual intervention.

Who makes the actual update in your CMDB is a separate R activity in your RACI chart.

--rpmason
Take all this with a grain of salt. I'm not an IPRC. I’m using this question to practice “thinking through” for my Managers.

First of all, thank you very much for your assistance. Your answers did help me to clarify some concepts.

The problem, as mentioned by rpmanson, is that the word "owner" as used in ITIL leaves space for a lot of interpretation. As UK stated, there are a lot of owners, but ITIL states that "every CI must have one and no more then one owner". And it also says that the owner is the ultimate responsible for updating and controlling the CI in the CMDB.

If I got it right from your answers, from an IT management perspective, I could have the Help-Desk department owner of the desktops CIs. So, the HD guys would be responsible for updating and controlling these CIs. What actually makes sense to me, since it is them who install and support the desktops.

But this could potentially lead to accountability problems (e.g. who the hell did not update it?).

So I would rather have the HD manager as the owner of desktops CIs.

Following this reasoning, we would end up having department managers as the owners of CIs linked to their domain. For example, unix servers would be owned by the unix dept mgr, windows servers would be owned by the ms dept mgr, and so forth. HD mgr could also be the owner of all desktop sws.

The process can dictate that the actual action of updating a CI is done by them (or by the cfg mgr), but the cfg manager must be aware of this somewhere in the process. BTW, the idea of having several people updating their CIs frightens me.

Does this make sense to you? Am I seeing flying saucers? Anyway, that’s why I am chasing sleep...

creating and updating a CI is part of a process. Ownership of a CI is about authority. Authority can be delegated by or through a procedure.

In other words you can have a process in which, for example, an engineer upgrades an operating system over a series of machines; each time he completes an upgrade he records the new situation against the CI in the CMDB; he is authorised (and obliged) within the process which makes him answerable to the configuration Manager and to the CI owner for doing it correctly, timeously and accurately. This is a practical issue to be resolved according to your circumstances.

Issues of misuse are controlled firstly by procedural instruction, secondly by general instruction as to professional behaviour, and this can be reinforced by access authorities and by logging activities in your CMDB.

Ownership of CIs is a bit 'horses for courses', but is likely to be the person who is responsible for the continued existence or the continuing use of the entity that it identifies. So the desktop PC CIs might be owned by the desktop service manager for example. This is a practical issue to be resolved according to your circumstances._________________"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

honest; I wrote my bit under 'ITIL implementation' before I got to this thread.

ChasingSleep wrote:

I think the main problem is that we always tend to rely on what ITIL says, and when it does not say it (or says it incompletely) we get lost.

Chasing,

I know a brilliant consultant who can save you from getting lost for a very reasonable consideration._________________"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718