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.
We are starting to put together a new CM. One of the issues we are struggling with is the definition of change - we have helpdesk, desktop applications, unix, network, wintel and database represented.
Everyone seems to have a different idea of what change is. Any suggestions - we seem to be leaning to having change and the rules defined the by the groups - this seems wrong and should we should a definitative definition for change.
Joined: Feb 28, 2006 Posts: 411 Location: Coventry, England
Posted: Sat Apr 29, 2006 12:14 am Post subject:
From the book
Definition of a Change
The authorized addition, modification, or removal of approved, supported or base lined: hardware, network, software, environment, system, desktop build, or associated documentation
Joined: Mar 12, 2005 Posts: 255 Location: Melbourne, Australia
Posted: Sat Apr 29, 2006 3:32 am Post subject:
jccoder,
have varient definitions of changes based on you groups is probably not good. On the other hand there is not one 'definitive' model for all changes. The Change Management chapter discusses the need for different change 'models' in some length. These would be based on impact, ugency, risk, number of CIs affected, and so on.
Not as you seem to be implying on 'what is changing' - in which case you will have different 'builds', but change management doesn't build changes.
Joined: Mar 12, 2005 Posts: 255 Location: Melbourne, Australia
Posted: Sun Apr 30, 2006 2:49 pm Post subject:
Mmm,
well it would be intereting to see what the BIA would look like, and the backout plan and uers acceptance testing for that type of chnage
Still, personnel records can be considered CI's and people are defintely production factors of services - particualrly professional services.
It's an odd one to be sure, IT service management processes are not designed to be HR management processes. Could we raise an 'incident' against a personnel CI when a staff member is off sick? And rasing an RFC on a collegue who unexpectedly died - would just be tacky. (When workplace/business culture gets to that point, I'm off to the tropics to live in a hut and collect sea shells )
Generally I think integration of HR and line management practices would go only as far as keeping appropriate information on the relationship between HR inputs and service delivery and support .
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Mon May 01, 2006 2:57 am Post subject:
ikanaj wrote:
Hi,
I am new to ITIL framework. Would it right to consider hiring a new employee as a change ??? Its not anCI that can be baselined though???
Hello Ikana,
If we are speaking strictly ITIL, then the answer is no. But if you're speaking in terms of controlling and improving the greater organization than the answer is "yes". Remember, ITIL is a set of "guidelines" that only deal with IT Service Management, with respect to technology in the "production" environment. It, therefore, has huge gaps when you apply it to the greater organization and other parts of IT Operations, such as Envisioning/Inception, Planning, Implementation, Construction, Deployment/Distribution, Testing & Verification, etc. It also does not cover the "human resource" aspect of an organization, such as you pointed out with your question.
If you're looking to implement ITIL and nothing but ITIL, then stick with a Change only being IT related. If you're trying to improve your entire enterprise, as a whole, then think bigger picture and take on the view that your CIO/CTO/COO/CEO would take on.
Many organizations are very advanced and "do" cover the management of humans as "CIs", whether they know it or not. My recommendation is that you consider the bigger picture of the definition of "Change" and not limit yourself to the ITIL definition. However, reality dictates that most groups can only work in small, manageable, steps. Therefore, if your scope is limited due to limited resources, do the best you can, within the domain you're trying to solve, keeping in mind the greater picture as a set of requirements for future expansion.
I hope this helps.
Regards, _________________ [Edited by Admin to remove link]
This question actually came up in my ITIL foundation class. The instructor basically said the same thing as Guerino1.
If you have configuration items to the employee level, then yes it would be considered a change.
But in reality, most companies would not have CI's at that level.
The company I work with has a pretty good chagne management process in place, but there is sometimes still a bit of a strugle in determining what really needs to go through the formal change process.
As a rule of thumb, I use that any change to a CI, as well as the introduction or removal of a CI, and any of its fields, is subject to the Change Management process. It is to me the only way to introduce a CMDB and make sure it will always be up-to-date.
So, to me, defining what a change is needs to be done at the same time the scope of the CMDB is defined. If a CI is worth tracking, then any change to it is worth managing...
What do you guys think? _________________ BR,
Fabien Papleux
Accenture
Technology Consulting | Service Excellence
Red Badge Certified
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
(When workplace/business culture gets to that point, I'm off to the tropics to live in a hut and collect sea shells 
