Initiate a request for change (RFC)

Key questions:

• What kind of information is to be included in the change description? For example, the service that will be affected, the business benefit, and the exact description of the configuration items to be changed.
• Who can initiate a change? Can anyone in the organization initiate a change?
• How will the RFC be categorized and tracked?
• Does each service maintain its own set of RFCs?
• How are RFCs interlinked and cross-referenced?
• Is there a specific RFC for common or standard changes?

Inputs:

• Request for a change
• Description of the change

Output:

• New RFC

Best practices:

• Keep RFC forms as simple as possible while capturing sufficient information to manage risk.
• The RFC should be continually updated throughout the process; it can be initiated without a thorough analysis or detailed information about the change and then updated later. It is important to have easy access to the RFC so that additions to it can be made. Additionally, organizations can use role authentication to ensure that read and write access is applied at the right time during the process. Determine who should have permission to read or change the RFC in each process.
• The organization can streamline the RFC process by using pre-populated fields and drop-down lists for information such as the type of change, the service affected by the change, and the applicable technology.
• There should be a point of contact for each change request. This can be the Change Manager or the change initiator. The point of contact should have access to the most recent history, understand the technical and resource implications, and appreciate how this change will affect other planned changes and the day-to-day work of the business.  
• Do not confuse the RFC process with a Service Desk request. The latter is a request for such things as existing services or questions about existing services, and is handled through the Customer Service SMF. An RFC is completed by the IT group to ensure that changes to the production environment are well thought out and planned.
• Ensure that the RFC form is self-explanatory and that it is clear how to seek assistance, if needed, for completing the form.

Check the business process and application configuration

Key questions:

• What business processes are potentially affected by this proposed change?
• What will need to change to accommodate this RFC?
• What applications will be affected by this RFC?
• Which users and business groups need to know about this change?

Best practices:

• Dependencies on business processes and functionality must be identified. If you change the workflow or how the application is used, the business must be involved to identify impacts.
• Consider services, process, and impacted applications when considering what communications are required.