Loading...
 

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."2

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:

  1. 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.
  2. Logging an RFC increases the incident resolution time.
  3. 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 change4 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:

More on Change Management


Category:
ITIL > Change Management
ITIL > Change Management > Standard Change
ITIL > Incident Management

3 ITIL® 2011, states that a “Requests for change are not required to implement a standard change, and they are logged and tracked using a different mechanism, such as a service request.” This approach was also alluded to in ITIL® v2 and appropriate for user-related changes (e.g. replacing a PC). However, it is not a common practice for infrastructure changes that may impact a service.
4

Definition of a Standard Change from ITIL® v2:
“A standard Change is a change to the infrastructure that follows an established path, is relatively common, and is the accepted solution to a specific requirement or set of requirements.” Source: ITIL® Service Support, 2000. page 173

5

Definition of a Standard Change from ITIL® v3:
(ITIL® Service Transition) A pre-authorized change that is low risk, relatively common and follows a procedure or work instruction – for example, a password reset or provision of standard equipment to a new employee. Requests for change are not required to implement a standard change, and they are logged and tracked using a different mechanism, such as a service request. ITIL® glossary and abbreviations, 2011 Source: https://www.axelos.com/Corporate/media/Files/Glossaries/ITIL_2011_Glossary_GB-v1-0.pdf

6

Definition of a Standard Change from ITIL® 4:
A low-risk, pre-authorized change that is well understood and fully documented, and which can be implemented without needing additional authorization Source: https://www.axelos.com/getmedia/5896d51f-ab6c-4843-992b-4f045eab0875/ITIL-4-Foundation-glossary_v0_22.aspx


Disclaimer


Copyright 2020 - ITIL® from Experience - Denis Matte



Copyright 2012-2020 - ITIL® from Experience - Denis Matte

ITIL® is a registered trade mark of AXELOS Limited