The bottom line
ERP production support breaks when ownership, intake, prioritization, and escalation paths are unclear.
The 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.
The CIO takeaway: this is a capacity and ownership problem before it is a ticketing problem.
What breaks down
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.
- Unclear ownership Every issue needs a meeting before work can begin.
- Messy intake Demand arrives through email, Slack, tickets, calls, and side channels.
- Recurring incidents The same failures return because root causes are never retired.
- Escalation noise Senior people become the routing layer for ordinary work.
What leaders miss
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.
The operating model
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.
| Failure pattern | What it looks like | What to change |
|---|---|---|
| Unclear ownership | Every issue needs a meeting. | Assign named operational owners. |
| Messy intake | Requests arrive through multiple side channels. | Move demand into one controlled intake path. |
| Recurring incidents | The same issues return every month. | Track root causes and eliminate repeat demand. |
| Build/run collapse | Roadmap people keep getting pulled into tickets. | Separate run-state support from build work. |
What to do next
The fix starts with measurement. Before adding tools, vendors, or more meetings, establish where support demand is coming from and which work is recurring.
- Measure where production support demand is coming from.
- Identify which issues are recurring versus truly new.
- Assign ownership for intake, escalation, and root-cause elimination.
- Separate run-state work from roadmap and build work.
- Review queue aging and escalation patterns every week.
Frequently asked questions
Why does ERP production support break down?
It usually breaks down because of operating-model failures, not technical ones. Unclear ownership per module, informal intake through Slack and email, hidden recurring demand, mid-sprint priority negotiation, and tribal knowledge concentrated in one or two engineers are the dominant drivers. The software and the people are rarely the root cause.
What are the early signals that support is failing?
Tickets reassigned more than twice before resolution, more than 25% of work entering through informal channels, the same five issue types dominating quarter after quarter, sprint scope changing mid-sprint based on stakeholder pressure, and one engineer being named in every escalation.
Will hiring more support engineers fix the problem?
Almost never. Adding headcount to a broken intake doubles the cost of the same chaos. Intake and ownership have to be fixed before headcount can be added against a measured baseline.
What is the single most important operating-model change?
One intake path. Every support request — from anyone, including the CIO — enters one queue. Without a single intake, there is no baseline of demand and prioritization is negotiated rather than decided.
How much capacity should be reserved for permanent fixes?
15% to 20% of weekly capacity should be reserved for converting recurring incidents into runbooks, automations, or permanent fixes. Without reserved capacity, the recurring list grows forever.
