When supply chain teams spend their days expediting orders and chasing exceptions, the cause is not understaffing or poor time management. It is a planning system producing output the business does not trust. Firefighting is the manual correction layer that fills the gap, and it grows until the underlying settings are addressed.
There is a version of this problem that gets solved with a productivity system, and a version that does not.
If a planner is disorganized, a better calendar helps. If a planner spends four hours a day working around a system that keeps proposing the wrong answer, no calendar in the world will touch it. The second version is far more common in SAP-run manufacturers, and it is routinely diagnosed as the first.
What does firefighting actually indicate?
It indicates that the gap between what the system proposes and what the business needs is being closed by people, one transaction at a time.
The Core Narrative of operational drift lists it plainly: teams work longer hours firefighting to stabilize operations. That is a symptom sitting downstream of several others. Processes have diverged from standard. Workarounds have multiplied. People have stopped trusting the system. Spreadsheets have returned.
Every expedite is a small, expensive act of manual repair. The organization is paying skilled people to compensate for settings that could be corrected once.
Why does adding people not fix it?
Because the volume of correction work scales with the size of the gap, not with the size of the team.
Hire two more planners and the exception queue gets worked faster. It does not get smaller. The parameters still generate the same exception messages next week, the same overdue elements, the same red lights. The team is now more expensive and equally reactive, and the new hires learn the workaround as the job, which makes the informal process harder to remove later.
This is why firefighting is so durable. It is self-reinforcing. The busier the team is correcting the output, the less capacity exists to fix what produces it.
What does the exception load look like when it is fixed?
The published numbers are unusually clear on this point, because exception volume is directly measurable.
Phillips 66, a Fortune 100 diversified energy manufacturer and one of the largest finished lubricants suppliers in the US, was running reactive firefighting and order expediting cycles with fragmented planning and minimal SAP utilization. Activating end-to-end planning inside SAP and realigning MRP strategies and master data ownership produced a 73% drop in SAP exception messages, a 98% reduction in overdue supply and demand elements, an 86% reduction in negative days of supply, and a $15 million reduction in average inventory.
Similarly, Delicato Family Wines, facing manual workarounds and frustrated users who had come to see SAP as a burden, recorded 53% fewer exception messages, a 96% reduction in overdue demand elements and a 90% reduction in potential service level disruptions.
A global wine producer reduced overdue MRP supply elements by 96.6% on raw materials and 98.4% on finished goods by addressing the root configuration and team education gaps that had existed since go-live.
Those are not productivity gains. That is work that stopped existing.
Where does the firefighting come from?
Three sources, in rough order of volume.
Exception messages nobody can act on. MRP generates them faithfully, every day. If the underlying data is wrong, most are noise, and a queue of mostly noise trains people to ignore the queue entirely. The few that matter get lost with the rest.
Promise dates set from assumption. When Available to Promise is not trusted, planners pad. Padding distorts the plan, which produces more exceptions, which justifies more padding. The aerospace manufacturer and MRO provider in Reveal's published work had exactly this loop running before ATP discipline was restored.
Master data that lies. A lead time, a lot size or a capacity figure that no longer matches reality generates a stream of wrong proposals. Every one of them has to be corrected by a person.
What a leader should measure instead of hours
If your team is stretched, the instinct is to look at workload. A better set of questions:
- How many exception messages does the system generate weekly, and what percentage does anyone act on?
- How many overdue supply and demand elements are open right now?
- What proportion of system-proposed orders are accepted without modification?
- When a planner overrides the system, how often is the override correct?
That last one is the diagnostic. If overrides are usually right, the system is being run on bad data and the planners are compensating. If they are usually wrong, the team has stopped trusting output that was fine. Both are fixable. They require different fixes, and neither is a staffing decision.
The part that matters for retention
Skilled supply chain people do not leave because the work is hard. They leave because it is repetitive, avoidable and visibly unnecessary. Firefighting is all three.
Removing it is not a wellbeing initiative. It returns capacity to a team that is already paid for, and gives them work that uses their judgment rather than their patience.
The 12-question self-assessment will give you a read on where your own exception load is coming from.
Give your team back the hours the system is taking. Request an executive conversation.
More Expert Insights & Exclusive SAP Secrets
For in-depth insights and SAP video education, visit Reveal TV to explore this topic further or sign up for exclusive content.
