Do we need an RFC to resolve a break-fix incident

By ITIL® from Experience ©

Every time Change Management is implemented, someone asks if an RFC is needed for a break-fix1 . In our context, a break-fix is defined as the replacement of a failed component like switching a defective router for an identical model or hot-swapping parts like drives, fan, power supply (see Who should log the RFC).

First, let's start with the ITIL® definition of a change:

"The addition, modification or removal of anything that could have a direct or indirect effect on services."

Therefore, a change is any activity that can impact the availability of service including changing a component or rebooting a server (See Is a server reboot a change). Moreover, all changes require a Request For Change record (RFC)3 .

For technical people this is fine from an academic ITIL® textbook perspective, but it is unacceptable to operations as it does not reflect the reality of the real-world. The three typical arguments are:

Replacing a component to resolve a break-fix incident is not a change since they are only returning the Configuration Item to its functioning state.
Logging an RFC increases the incident resolution time.
An RFC is not required because the work was documented in the incident record. Moreover, it is unnecessary to duplicate work and they are too busy for that (See How to get people to log tickets)

The following has been used to address these concerns.

According to the ITIL® definition of a change, substituting an identical piece of equipment with the same configuration, even if the Configuration Item (CI) attributes have not changed is a change.

That being said, the majority of break-fix should be a standard change 4 5 6 . Therefore, the technical specialist can implement the standard change without CAB approval (see Do we need to log an RFC for a Standard Change).

Moreover, to truly address these concerns the following business rule should be considered to ensure that the incident resolution time is not unnecessarily increased:

To resolve an outage, or a severe service degradation impacting clients, a change can be logged and approved after it has been implemented.

Of course for ITIL® purists, doing the work before logging the RFC and getting approval is sacrilege. However, this business rule is a compromise and puts the business needs first.

Raising the RFC after the fact allows for a quick resolution and enables the "fix" to be evaluated to ensure that it is the correct long term solution. It gives the opportunity to approve the temporary measure used to quickly resolve the incident and if required to replace it with a more appropriate permanent one. Moreover, it makes sure that the architecture standards are met and that the CMDB is updated (see Why is the CMDB inaccurate).

The reason an RFC must be logged, is that when troubleshooting, one of the first questions asked is: "what changed?" If the break-fix is only documented in the incident record, people will likely miss the fact that a component was changed. Thus, it is in the best interest of the technical specialist to log RFCs as it can save them time when they need to resolve an incident in the middle of the night so that they can go back to bed. Thankfully, many ITSM tools enables users to log an RFC from an existing incident or a service request with a few clicks.

Lastly, logging RFCs for pro-actively replaced components on the verge of failure enables operations to report on the success of their event management work before an incident is detected or called into the Service Desk by a user (see What is another term for User).

Last updated: 2020-03-02
Published: 2020-02-28

A Standard Change that cannot be implemented using its approved procedure and implementation window is no longer a standard change.

More Quotes

Related: