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
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.
Posted: Thu Nov 27, 2008 1:36 am Post subject: CI Owner responsibility
Hi,
I am a little bit confused about the concept of CI owner, and I wonder if you guys could help me in clarifying it.
1) Is the CI owner who actually updates his own CI information in the CMDB? Isn't it a cfg manager task? Or does the CI owner do this on behalf of the cfg manager?
2) Who should be the owner of CIs. For example, we have about 300 desktops. Who should be their owner? One guy from the service desk? And what about software? Who owns Office, for example?
Joined: Sep 16, 2006 Posts: 3115 Location: London, UK
Posted: Thu Nov 27, 2008 3:02 am Post subject:
ChasingSleep
Obviouslly you need to catch sleep first (grin)
Owner: Owner
Who bought the hardware ?
Who bought the software ?
Who bought the licenses for the software products ?
That is one kind of owner
Owner: Management Owner
Who manages the said device in the environment ?
Who provides sys admin duties on the device ?
Owner: Service Owner
what services are provided by the device ?
Who owns that service / Provides that service defines that service /restricts or allows that service ?
owner: user
Who uses the device
Who physically has the device under their personal control
Now
who is the CI Owner: It depends. This is the default answer or answear (grin)
Desktops, laptops, etc - have a user owner and an mgmt owner (IT Dept)
servers have a mgmt owner (Wintel team, Unix team), a service owner (the finance dept as the server provide finance apps or PR, Communication and marketing if it is a official web site server)
network gear would have a mgmt owner
and all of them would have an OWNER owner: the company that is pissing their money away on useless and useful things like PCs, servers, network gear and staff.
As far as licenses are concerned, you also have owners and interested parties... but that is a nother thread _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
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...
Joined: Sep 16, 2006 Posts: 3115 Location: London, UK
Posted: Thu Nov 27, 2008 5:24 pm Post subject:
CS
You are not getting the point
YOUR DECISION IN YOUR CONFIGURATION MANAGEMENT POLICY AND PROCESS AS TO WHO SHOULD UPDATE OR PROVIDE THE INITIAL INFORMATION
Let me tell what was done for me in one company
A team worked to define the fields needed to populate the cmdb
hostname
ip address
device type details - router , server, dell, cisco
serial number - company asset tag, vendor s/n
physical location
power source - a or b as we have ups
the data centre staff did a mark 1 eyeball through the datacentre
the system - network, wintel, unix - teams gather their information
the config team had a db person, excel expert etc
they made input sheets
lo and behold
the information got to get filled
on a periodic basis, the config manger sent the appropriate team a validation sheet to check that the info is the same
if there was a change request for the device to make changes, the implement team would get and update form as well to update the details
....
hey this is a config mgmt policy process and procedure _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Joined: Mar 04, 2008 Posts: 1883 Location: Newcastle-under-Lyme
Posted: Thu Nov 27, 2008 10:08 pm Post subject:
Chasing,
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
Joined: Mar 04, 2008 Posts: 1883 Location: Newcastle-under-Lyme
Posted: Fri Nov 28, 2008 3:39 am Post subject:
UKVIKING wrote:
Dont follow the books too closely
Especially the 6th book, chapter 7
Chipmunks as NOC staff
John,
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
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
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
