In a manufacturing plant every IT change carries a potential downtime risk - and that is exactly why Change Management exists. It is an ITSM process with a single goal: to introduce changes to IT systems in a controlled way, minimizing the risk of failure and maximizing the chance of success. But Change Management is not bureaucracy - it is a tool that protects your production. In this article I explain how an RFC (Request for Change) works, who the CAB (Change Advisory Board) is, what the 3 change types are, and how to prepare a rollback plan that actually works.
Why is change management critical in manufacturing?
Picture this scenario: an IT technician decides to "quickly" update the ERP system, because "it will take 15 minutes". They do not prepare a backup, do not inform anyone, and start. Something goes wrong. The line is down. All production orders are blocked. Logistics does not know what to ship. The customer gets an email about a delivery delay. The cost of such a "quick update" - measured in lost production and damaged customer trust - is often disproportionate to the supposed time savings.
This is exactly why Change Management exists. The Change Management process in manufacturing:
- Forces planning - no change happens ad-hoc, there is always a plan.
- Spreads risk - the CAB assesses production impact beforehand, not after the fact.
- Documents everything - a year from now you will know what changed and why the line stopped that day.
- Enables rollback - if something goes wrong, you have an undo plan instead of panic.
- Protects the IT team - when something goes wrong and the change was approved by the CAB, accountability is shared, not dumped on the technician.
3 change types: standard, normal, emergency
Not all changes should be treated the same. ITIL defines 3 categories of changes, each with a different approval timeline and risk profile.
Standard Changes
- Routine, low risk
- Previously tested, proven playbook
- Approval <24h or pre-approved
- Examples: patch, backup, password reset, server reboot
- Deployment time: 30 min - 2h
Normal Changes
- Medium risk, planned
- New or rarely performed
- Approval 3-7 days (CAB review)
- Examples: OS upgrade, firewall change, database migration
- Deployment time: 2h - 2 days
Emergency Changes
- High risk, immediate
- In response to an incident
- Hot approval (CAB call), <1h
- Examples: bug hot fix, emergency security patch
- Deployment time: 15 min - 1h
Change Advisory Board (CAB)
- Approves Normal and Emergency Changes
- Standard Changes can be a pre-approved batch
- Composition: IT Manager, Senior Tech, Architect, Prod Manager
- CAB evaluates: impact, risk, rollback plan, timing
- Meetings: weekly (Normal), ad-hoc (Emergency)
The RFC process - from request to deployment
The RFC is a form on which the requester (technician, manager, another department) describes the change and everything related to it. The RFC is the core of Change Management - without an RFC there is no control, only chaos.
What does an RFC contain?
- Header: RFC number, date, requester, priority (Standard/Normal/Emergency)
- Change description: what is changing specifically (e.g. "Upgrade ServiceDesk Plus from v12 to v13")
- Reason: why we are doing it (e.g. "Security patch CVE-XXXX, new API feature")
- Affected systems: which IT systems will be modified (e.g. ServiceDesk Plus server, database, AD integration)
- Estimated impact: how many users / hours of downtime / financial loss if something goes wrong
- Deployment plan: step by step what will be done (backup, stop services, upgrade, test, restart)
- Rollback plan: how to undo the change if things go wrong
- Deployment time: when (date, time, window)
- Tester: who will test the change after deployment
- CAB approval: date and signature(s) of CAB members
RFC workflow in ServiceDesk Plus: the RFC enters the approval queue → the CAB reviews it within 3-7 days (for Normal Changes) → the CAB approves or requests revisions → the change moves to "Approved" status → the technician performs the change in the planned window → the RFC is closed with a note about the outcome.
CAB in the plant - who approves changes?
The CAB (Change Advisory Board) is a monthly or weekly meeting of experts who review RFCs and decide whether a change should be deployed. CAB composition should include representatives of all areas a change might affect:
| CAB role | Responsibility | Decision |
|---|---|---|
| IT Manager / CTO | Technical assessment, resources, capacity | Approve / Reject |
| Senior Architect | Impact on architecture, integrations, security | Recommendation, can block |
| Senior Technician | Feasibility, technical risk, rollback | Recommendation, can block |
| Production Manager | Production impact, timing, SLA | Can veto if conflicts with production |
| Service Manager | Documentation, communication, support planning | Recommendation |
When the change affects the production line: the Production Manager has veto power - if the change is planned during peak demand, the Manager can push the change to another day. In 24/7 production the CAB should know the schedule of all three shifts (night, day, weekend) and pick the lowest-load window.
Rollback plan - how to undo a change when something goes wrong?
The rollback plan is the most important part of the RFC. The rollback plan says: if something goes wrong, how will we walk back in X minutes, without panic, without chaos. Without a rollback plan, a change should never be approved.
Rollback plan structure:
-
1. Rollback trigger
When do we decide to roll back? Examples: (a) the application upgrade causes 50%+ of tickets to fail to open, (b) performance drops >20% below baseline, (c) critical errors in logs every 10 seconds. The trigger should not be "if something looks weird" - it must be concrete and measurable.
-
2. Step-by-step rollback instructions
E.g. "Restore v12": (a) stop the ServiceDesk Plus service, (b) restore the database from the 10:00 backup (pre-upgrade), (c) restart the ServiceDesk Plus service, (d) test the portal - can users log in, do tickets open. Each step must be executable without mistakes even under stress.
-
3. Estimated rollback time
How long will undoing the change take? For an application upgrade - 10 min. For a database migration - 30 min. For a complex reconfiguration - 1h. Rollback time should always be shorter than deployment time + diagnostics.
-
4. Communication while rollback is happening
Who is informed? Production Manager, Shift Lead, possibly Plant Director. Message: "Change X failed, we are rolling back, expected recovery time: 20 minutes." The worst thing is silence - the production team must know what is going on.
-
5. Post-rollback follow-up
After a rollback the change is NOT closed. The RFC moves to "Rolled Back / Investigating" and the technician analyzes what went wrong. Root cause analysis, lessons learned, and the RFC can be re-prepared with a better plan.
The most common rollback plan mistakes (to avoid)
- No pre-change backup. Always restore from a backup - never without it.
- Rollback drags past 1h. If rollback takes >1h, the change is too risky for production. Move it to dev/test.
- Rollback plan exists only in the expert's head. It must be written down (or in ServiceDesk Plus), tested at least once.
- Ignoring partial rollback. Sometimes you do not have to undo the whole change - you can revert only the part that failed.
- No rollback test. If possible, test the rollback in dev/test beforehand.
FAQ - Change Management in manufacturing
What is an RFC and why do we create it?
An RFC (Request for Change) is the form by which you raise a need for a change in IT systems (e.g. update, reconfiguration, database change). The RFC includes: change description, reason, expected impact, rollback plan, date and time of deployment. The RFC goes to the CAB (Change Advisory Board) for approval. Thanks to the RFC every change is recorded and you can later analyze the trend of changes vs incidents.
What is a CAB and who should set it up?
A CAB is a Change Advisory Board - the body that approves changes. Composition: IT Manager, Senior Technician, Architect, Production Manager, Service Manager. The CAB evaluates RFCs against risk, production impact and feasibility. P1 changes (high risk) must be approved by the CAB on the day of execution. Standard (routine) changes can be approved more quickly or even by a single person.
What are the 3 change types and how do they differ in approval time?
Standard Changes - routine, low risk (Patch Tuesday, backup config), approval <24h. Normal Changes - medium risk, planned (OS upgrade, firewall reconfiguration), approval 3-7 days. Emergency Changes - high risk, immediate (hot fix for a critical bug), CAB hot approval within an hour. In manufacturing Emergency Changes are rare - it is better to avoid them through good testing and planning.
What should a rollback plan contain?
A rollback plan is the precise scenario for undoing the change if something goes wrong. It covers: (1) rollback trigger (e.g. performance drops >10%, or critical log error), (2) step-by-step undo instructions (restore backup, reload config, restart services), (3) estimated rollback time (15-60 min), (4) user communication. A good rollback can be executed in 30 minutes without additional decisions or improvisation.
Do all changes need to be approved by the CAB?
In practice: Standard Changes (routine, low-risk) can run under a pre-approved process - sometimes the IT Manager approves them in a weekly batch. Normal Changes always go through the CAB. Emergency Changes go through the lead engineer + IT Manager on a hot call. In a 24/7 factory you should have an emergency process on standby - even if you rarely use it, the team must know it.
Related articles
SLA for a manufacturing plant - how to set IT response times? CMDB for a manufacturing plant - managing IT and OT assets IT help desk KPIs - 12 metrics every IT manager must track ITSM for manufacturing - solutions for factoriesWant to deploy Change Management in your factory?
Rotech Group will help you build an RFC and CAB process tailored to your structure. We will set up Change Management in ManageEngine ServiceDesk Plus and train the team.
Book a consultation →