ERP OperationsFree templatePDF, Excel, Word exportDiscrete Manufacturing

Plant IT Change Advisory Board (CAB) RFC Template

A change advisory board only works if every request arrives with the same facts: what is changing, who is affected, how it is tested and how to undo it. This template gives plant IT teams a consistent RFC that fits on two pages.

Fill in

RFC number

Requested by

Submission date

Change type

Affected system

Planned window

Change description

Business reason

Production impact

Risk level

Rollback plan

Test evidence

Live preview

Download:

Plant IT Change Advisory Board RFC Template

Request for Change RFC-2026-0147

Requested by: Priya Nair, Infrastructure Engineer Submitted: 2026-10-20 Change type: Normal Risk level: Medium

Scope

Affected system: ERP database server ERPDB01 (SQL Server) and application tier Planned window: Sunday 2026-11-01, 02:00 to 06:00 local, no shifts running

Apply the latest cumulative update to the SQL Server instance hosting the ERP database and restart the application services afterward.

Business Reason

Closes a vendor-published security fix and a known memory leak that caused two unplanned restarts last quarter.

Production Impact

ERP unavailable for about 90 minutes. Shop floor terminals fall back to paper travelers; no machine control is affected.

Test Evidence

Applied to the test ERP environment on 2026-10-14. Month-end close job and 12 key shop floor transactions passed.

Rollback Plan

Restore the pre-change VM snapshot and the full database backup taken at 01:30. Decision point: if validation is not complete by 05:00, roll back.

Implementation Steps

Step	Action	Owner	Planned time	Done
1	Notify plant manager and shift leads
2	Take backup and VM snapshot
3	Apply change
4	Validate with smoke test list
5	Release to users and close RFC

CAB Approvals

Requester / Date

IT manager / Date

Plant operations representative / Date

Security officer / Date

Starting point for your own change process. Align the change types with your ITIL or internal definitions, and keep emergency changes retroactively reviewed. Not legal or audit advice.

Automate change checks from your ERP data

Optional: talk to us about validating ERP jobs and integrations automatically after each change.

Optional. The tool and every export work without this. No spam.

How to use the RFC template

Fill the fields at the top, review the generated document, then export it to PDF or Word and attach it to your ticket or CAB agenda. Write the production impact in shop floor terms: which lines, which shifts and which fallback exists. A change that looks small to infrastructure can stop a work cell if the ERP or MES is unavailable.

Name the exact systems and servers, not just the application
State the window against the shift calendar
Define the rollback decision time up front
Attach test evidence from a non-production system

Standard, normal and emergency changes

Most frameworks, including ITIL, split changes into three types. Standard changes are pre-approved, repeatable and low risk, such as a monthly patch with a proven runbook. Normal changes go through CAB review. Emergency changes bypass the usual schedule to fix an outage or active threat, but should still be documented and reviewed after the fact. Pick the type honestly: overusing emergency undermines the whole process.

Risk and rollback in a plant

Risk in a plant is about time-to-recover during production, not only technical difficulty. Rate a change higher when it touches shared services such as authentication, DNS, the ERP database or the OT firewall. A rollback plan should name the snapshot or backup, who triggers it and the clock time at which you give up. Untested rollbacks are a common failure: confirm that restoring actually works.

Common mistakes

Teams often write vague scopes such as 'server maintenance', skip the plant operations signature, or schedule changes during a quarter-end close. Another frequent gap is forgetting dependent systems: label printers, barcode scanners, EDI gateways and integrations that fail quietly after a restart. List them in the impact field so someone checks them in the validation step.

Frequently Asked Questions

Do I need a CAB for every change?

No. Pre-approve repeatable low risk work as standard changes with a documented procedure, and keep CAB time for normal changes with real production impact. A small plant may use a short weekly call with IT, operations and security rather than a formal board.

Who should sign an RFC in a plant?

At minimum the requester, an IT approver and someone from plant operations who understands shift impact. Add security for network, identity or remote access changes. The signature lines in the template can be renamed to match your roles.

How far ahead should an RFC be submitted?

Many teams ask for three to five working days for normal changes so operations can plan around production. Emergency changes are exempt but need review afterward. Set the lead time in your own policy and apply it consistently.

Can I reuse the form for ERP application changes?

Yes. The structure works for infrastructure, ERP patches, configuration changes and integrations. For customization-specific fields such as objects and transports, add them in the description or use an ERP-specific change request form.

If you want ERP change requests, test runs and post-change checks tied to your ERP data, Netray can discuss automating parts of this inside your environment.

Talk to an Expert Explore More Free Tools

Related Tools

ERP Operations

More ERP Operations tools

See all

Back to All Tools