Hi,
how would you define what kind of incidents should result in a service change and what kind should be solved within the Incident Management without any RFC submitted. I have one answer and correct me if I am wrong. Or please share any other point of view.
My theory: Each Service Change should cause a change in the status of a CI (Configuration Item) on which it is applied.
- If solving an incident on the CI is only retrieving its previous status - that is not a change. (e.g. someone deleted important file and solution is to restore that file)
- If solving the incident causes a new status of CI - that is a change and should be handled by Change Management. (the system crashes and the solution is to add a new memory)
Please help.
Thanks
Roman
Anonymous
(10/11/2011)
In my experience I've dealt with organizations that chose not to accept proven practices implemented in other companies and insist on making their own determination on what constitutes an action that requires formal change. The organization I'm working for now doesn't even have a CMDB. They've decided to arbitrarily assign pre-approvals to common operations tasks regardless whether they are infrastructure or end user related. Whenever they come across an activity that they feel can be pre-approved they put a first change through to prove that it is safe and at the next CAB session or post implementation review they approve on whether it can be a standard change.
Comments