Executive decision
The question is not whether production support can keep responding to tickets. The question is whether the operating model can reduce demand, protect roadmap capacity, and keep accountability clear as the ERP environment ages.
Most breakdowns are not caused by bad people or bad software. They happen when every issue has a different intake path, priorities are negotiated in Slack, and no one owns the recurring patterns that keep creating demand.
Operating symptoms
ERP support starts to drift when intake becomes informal. A finance lead emails one analyst, a plant manager messages a developer, a batch issue goes straight to the only person who knows the workaround, and urgent work starts bypassing the queue.
Once that pattern becomes normal, the team loses the ability to distinguish new demand from repeat demand. The queue becomes a negotiation system instead of an operating system.
Structural issue
The visible issue is ticket volume. The structural issue is that the same people who understand the ERP environment are being asked to run it, improve it, document it, and modernize it at the same time.
Support coverage is not the same as operating capacity.
This is why adding another ticket queue rarely solves the problem. The work needs ownership, measurement, and a clean separation between run-state operations and build work.
Decision framework
A better production support model is not louder. It is clearer. Intake is controlled, ownership is named, recurring patterns are measured, and the build team is protected from avoidable run-state demand.
Next action
The fix starts with measurement. Before adding tools, vendors, or more meetings, establish where support demand is coming from and which work is recurring.