Support, AMS, and Living With an ERP
Most ERP developers spend most of their careers in support, not implementation. It’s steadier, it pays well, and it’s where you learn the system deeply.
The support model
L1 Service desk Password resets, "how do I…", triage and routing
L2 Functional support Config questions, master data, process issues
L3 Technical support Custom code defects, performance, interfaces
L4 Vendor Product defects, escalated via a support ticket
Most tickets stop at L1 or L2. The distribution in a stable ERP is roughly:
35% "How do I…" → training gap
20% Authorisation missing → role design gap
15% Master data wrong → data governance gap
15% Process/config question → documentation gap
10% Genuine defect
5% Performance / technical
Only 10% are actual defects. That’s why good documentation, quick-reference guides, and a searchable knowledge base reduce ticket volume more than bug fixing does.
Ticket priorities and SLAs
P1 Business stopped Response 15 min Resolution 4h 24/7
P2 Major process impaired Response 1h Resolution 1 day Business hours+
P3 Workaround exists Response 4h Resolution 5 days Business hours
P4 Minor / enhancement Response 1 day Next release Business hours
Period-end is different. Most support contracts have an elevated SLA and extended coverage during the close window (typically the last 2 and first 5 working days of each month). Your on-call rota is built around this.
Define P1 precisely, in advance. “Business stopped” means: cannot ship, cannot invoice, cannot pay, cannot receive, cannot pay employees, or cannot close. Everything else, however loudly reported, is not P1. Without a written definition, everything becomes P1 and the priority system stops working.
The support calendar
Month:
Day 1–5 MONTH-END CLOSE — peak load, elevated SLA, all hands
Day 6–20 Normal operations, enhancement work
Day 21–25 Preparation for close, pre-close checks
Day 26–end Approaching close, change freeze
Year:
Fiscal year end The biggest event — carryforward, asset year change,
number ranges, statutory reporting
Quarter ends Elevated
Peak season Industry-specific (retail Q4, agriculture harvest,
apparel shipping seasons)
Payroll dates Immovable deadlines every month
Know your customer’s calendar. Scheduling a release for close week is how support engineers lose credibility.
What you’ll actually do
Investigating “the system is wrong”
The standard sequence:
1. Reproduce it. Get the exact document number, user, date, and steps
2. Check the data — is master data correct as of the relevant date?
3. Check the configuration — what does the determination table say?
4. Check the authorisation — is the user seeing a filtered view?
5. Check the period and dates — posting date, document date, validity dates
6. Check the change log — what changed, and when?
7. Only then look at the code
Most “system is wrong” tickets resolve at step 2 or 3. Going straight to the code is the beginner’s mistake and wastes hours.
The questions that solve most tickets
- “What document number?” (specifics, not descriptions)
- “When did this last work?” (bounds the change)
- “Does it happen for other users?” (authorisation)
- “Does it happen for other materials/customers?” (master data)
- “What did you expect, and why?” (often reveals a misunderstanding, not a defect)
- “Show me.” (screen share beats twenty messages)
Performance investigations
1. Is it one report, one user, or everything?
2. When did it start? What changed around then?
3. Check the slow query log and execution plans
4. Check for missing/unused indexes
5. Check data volume growth — has a table crossed a threshold?
6. Check for lock waits and blocking
7. Check batch jobs overlapping with interactive use
8. Check the selection criteria — is the user selecting "all dates"?
That last one resolves a startling proportion of “the system is slow” tickets.
Knowledge management
The highest-leverage thing a support team can build:
| Artefact | Value |
|---|---|
| Known error database | Symptom → cause → resolution. Cuts repeat investigation to minutes |
| Runbooks | Step-by-step for recurring operational tasks |
| Quick reference guides | One page per process, with screenshots. Kills “how do I” tickets |
| Configuration rationale | Why is it set this way? Answers the recurring “can we change this?” |
| Custom object inventory | What exists, why, who owns it |
| Interface catalogue | What talks to what, with contacts on both sides |
| Data dictionary | What every custom field means |
Write the knowledge article when you solve the ticket, not later. Later never comes, and the same ticket arrives next quarter.
Monitoring — what a healthy ERP looks like
Build a daily health dashboard:
□ All scheduled jobs completed successfully
□ Interface error queues empty (or explained)
□ Dead letter queues empty
□ No documents stuck in incomplete/blocked status beyond threshold
□ GR/IR and clearing accounts near zero, no aged items
□ Subledger to GL reconciliations clean
□ Exchange rates loaded for today
□ No unposted parked documents older than N days
□ Number ranges below 80% consumption
□ Database growth within trend
□ Response times within SLA
□ Failed authorisation attempts within normal range
□ Batch job runtimes within normal range
Publishing this dashboard daily is one of the highest-value small builds a support developer can deliver. It converts reactive firefighting into proactive detection.
The enhancement backlog
Post-go-live, requests never stop. Manage them:
Request raised → triaged (defect vs enhancement) → estimated →
prioritised by the business → scheduled into a release → built → tested → released
The business prioritises, not IT. Give them a fixed capacity (“we can deliver 20 days of enhancement per month”) and let them rank within it. This converts an argument about importance into a straightforward trade-off conversation, and it ends the “everything is urgent” dynamic.
Continuous improvement
An ERP that isn’t improving is decaying. Regular activities:
| Activity | Cadence |
|---|---|
| Data quality review | Monthly — duplicates, incomplete master data, blocked records with stock |
| Unused custom object review | Annually — usage logs reveal 20–40% of custom code is never executed. Delete it |
| Authorisation review | Quarterly — SoD conflicts, orphan accounts, excessive access |
| Performance trend review | Monthly — batch runtimes, report durations, table growth |
| Open item cleanup | Monthly — aged GR/IR, stale POs, uncleared items |
| Configuration drift check | Per release — do QAS and PRD still match? |
| Process metrics review | Quarterly — cycle times, straight-through rates, manual journal count |
| Release notes review | Per vendor release |
Deleting unused custom code directly reduces your upgrade cost. It’s one of the few maintenance activities with an unambiguous, measurable return.
Working with the vendor
- Log tickets with detail: version, exact steps, document numbers, screenshots, system logs. Vague tickets get vague answers slowly.
- Search the vendor’s knowledge base first. Most issues are known.
- Understand the escalation path and use it when SLAs are missed.
- Track vendor notes/patches relevant to your version.
- Test vendor patches before applying to production — they can introduce regressions.
Career notes on support work
Support has a reputation as the less glamorous side. In practice:
Advantages:
- You learn the system far more deeply than an implementer does
- You see how it actually behaves in production, at volume, with real data
- Stable hours (excluding close weeks), no travel, no go-live crunch
- Strong job security — companies cannot switch off their ERP
- Domain knowledge compounds
Disadvantages:
- Repetitive periods
- Interrupt-driven
- On-call rotations
- Less visible than project work
The best move: alternate. A few years of support builds depth; a project builds breadth and visibility. Doing both makes you a far better architect than doing either alone — implementers who’ve never supported their own designs build systems that are painful to run.