Will it go through Change Management?

[swashbuckler]

Greetings,

Please consider the below scenario and let me know what would be appropriate as per ITIL?

There is a Sev 1 issue in which a hardware replacement is required, ( Lets say motherboard ) and as we fix the issue by replacing the part the incident is resolved & services are back up but does this solution needs to go through change management as there has been a hardware replacement?

Thanks,
Swash

[Diarmid]

I'm not sure how to manage a change that has already taken place.

Every decision and control point in the process of making the change (such as identifying the correct component, confirming that the replacement had been tested, deciding to make the replacement, identifying the qualified and authorised person who would apply the change, along with all appropriate approvals, consents etc.) were aspects of managing the change at the time.

So the issue really is: was the change managed appropriately, conforming to your change management policy and procedures?

You can, of course, conduct a change review to ascertain these things and that is (presumably) part of your change management process anyway.
_________________
"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

[UKIT]

Swash
In my opinion, based on your scenario this indicates that a loss of service has been experienced (Incident ) as a result of a server mother board failing being the root cause.(Problem)
The incident management process should commence with immediate effect, with the goal to restore IT service as soon as possible.
The Incident Manager will take command of the incident ensuring that the correct operational teams have been assigned to the task and keeping the client up to date as to the progress being made to restore IT services.
Change management is not involved.
_________________
Change Management
"Bringing order to chaos"

[Diarmid]

UKIT,

failed motherboard is not the root cause. You need to know something about why it failed to have root cause. Yes that is a task for problem management.

More importantly, how can you possibly replace the motherboard without managing the change?

Change Management is absolutely involved.
_________________
"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

[UKIT]

Further investigation could be carried out by the manufacturer in order to establish the exact component that has failed,if problem management wished to drill down to such a level.
With a typical server comprising of power supplies,processors,motherboard/system board,drive array controllers,network cards etc, from a high level point of view the motherboard/system board within the server has failed resulting in the loss of service.
This is not a change, this is an incident in which a new motherboard requires to be replaced as a matter of urgency in order to restore IT services asap.
What do you want change management to do?

[Diarmid]

On the other hand, if the "root cause" is the failed motherboard and you have already replaced it, you don't have much of a problem. It's been resolved before you had time to raise it formally!

------------------

Now about replacing a component not being a change? :-

-who authorises the action?
-is the replacement board properly identified?
-is the replacement board a controlled item of known quality?
-is the spares stock level maintained?
-does the person doing it know what they are doing?
-is the CMDB updated?
-what do you do about the risk?
-what is your contingency?

etc. etc. This is all part of managing the change.

You always need actions to be controlled
If you are well set up and have procedures in place, well controlled stock of spares and skilled experienced technicians, you can achieve it fairly quickly because you will be managing the change. Even then Change Management (in capitals to denote the overseeing function) will get directly involved because the "urgent" change will have to be reviewed formally.

To sum up: the failure was an incident the resolution was a change.
_________________
"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

[BorisBear]

To the OP........I would raise a change.

Everyone knows that the following statement is true in ITIL

"An incident ay result in a change"


Just sounds like it needs expedited management

[24sa]

In my opinion, a change would be raised as Emergancy Change, which need to be carried out for restoring the services ASAP. Afterall, the replacement actvity is going to impact the CI status and attribute so it must be recorded as change.

[TomC]

This would absolutely go through Change Management in my company, regardless of emergency or not. The paper trail should be consistent for future auditing and analysis purposes.