By Nikolai Iakunin, SAP Consultant, Enterprise Information Systems Implementation Specialist
The completion of an ERP system implementation project marks the transition to the stage of industrial operation, at which an increase in the number of users, the volume of operations, and the diversity of business scenarios reveals problems that were not detected at the implementation stage. Organisations face a constant flow of support requests, from standard user questions to critical incidents affecting business processes.
A common approach is to route all requests directly to the consultants who participated in the system’s implementation. While such a model can be effective in small environments, as the scale of operation grows it becomes inefficient, increasing the burden on consultants and slowing down the resolution of critical incidents.
This article is based on practical experience in supporting a large SAP-based ERP system and is devoted to L3-level support, interaction with the ABAP development team, technical analysis of incidents, and mentoring of junior L1/L2-level consultants. The article examines a structured multi-level support model aimed at improving the efficiency of incident resolution and the development of specialists.
Theoretical Foundations: Multi-Level Support Models
Multi-level support models are widely used in IT service management and are formalised in approaches such as ITIL [3]. Their basic principle consists in distributing requests depending on complexity: the L1 level handles standard questions, the L2 level resolves functional problems requiring deeper system knowledge, and the L3 level deals with incidents requiring technical analysis, code changes, or interaction with the software vendor.
Effective multi-level support requires formalised escalation criteria and service level agreements (SLA) defining response and resolution time standards depending on the criticality of the incident. Knowledge management supports the “shift-left” approach by transferring solutions to typical recurring problems from higher support levels to lower ones and developing the competencies of junior specialists.
In the SAP ERP environment, the support model requires not only an organisational division of levels of responsibility, but also standardised technical diagnostics. Incidents may be related to data, system settings, authorisations, integrations, or custom ABAP developments; therefore, analysis at the L3 level must combine functional investigation of the problem with technical data in order to determine the source of the error and ensure effective escalation.
Initial State Of The Support Model
Before the implementation of the new support model, all requests were processed through a single queue without classification by level of complexity. Functional consultants who had participated in the ERP system implementation spent a significant amount of time resolving standard questions, which reduced their availability for the analysis of critical incidents.
The initial assessment revealed several limitations of the existing model: resolution of Severity 1-level incidents took an average of 14.2 hours, and only 28% of requests were handled at the L1 level without involving higher-level specialists. There was no formalised knowledge base, recurring problems were solved anew each time, junior consultants required on average 11 months before being able to work independently with critical incidents, and annual staff turnover among junior specialists reached 40%.
Another limitation was the absence of a standardised approach to technical diagnostics during escalation. Requests were often passed on to the L3 level or to the ABAP development team without sufficient technical information, which increased resolution time due to the need for additional data collection and clarification of problem details.
Stages Of Building The Multi-Level Support Model
The implementation of the multi-level support model was carried out in six stages over 18 months.
- Stage 1 – Analysis and classification of requests (months 1–2). A retrospective analysis of support requests over 12 months showed that 47% of incidents belonged to 15 recurring categories, for which ready-made solutions existed and did not require the involvement of functional consultants
- Stage 2 – Defining routing and escalation criteria (months 2–3). Formal rules were introduced for distributing requests among the L1, L2, and L3 levels. Escalation conditions included exceeding the established resolution time, the presence of system problems, the need for technical analysis, and possible errors in custom code
- Stage 3 – Defining SLAs by criticality category (month 4). Four incident criticality categories were introduced. For Severity 1-level incidents, a response time standard of 30 minutes was established, along with a resolution or escalation standard within two hours
- Stage 4 – Development of the knowledge base (months 4–7). Solutions to recurring problems were documented in a structured knowledge base. A total of 86 articles were created, each reviewed and validated by L2/L3-level specialists
- Stage 5 – Mentoring program (months 5–12). Junior L1/L2 consultants were assigned mentors from among L3-level specialists. The program included incident review, knowledge transfer, and a gradual expansion of the scope of independent responsibility
- Stage 6 – Stabilisation and measurement of results (months 13–18). Key support performance indicators were continuously measured in order to assess the effectiveness of the model and adjust routing rules
From Reactive Troubleshooting To Managed Escalation
The three-level support model changed the role of L3 consultants: instead of handling a large volume of heterogeneous requests, they focused on complex incidents requiring technical analysis, interaction with developers, and architectural decision-making.
Formalised escalation rules made support processes more predictable: L1 specialists handled standard questions, L2 resolved functional tasks, and L3 dealt with problems requiring in-depth technical analysis. The improvement in escalation quality made it possible to reduce the time needed to reproduce incidents and identify their root causes.
Technical Analysis Of Incidents At The L3 Level: ST22, SM21, SM37, SLG1, And The ABAP Debugger
Within the framework of L3-level support, critical incidents required not only functional analysis but also technical investigation at the SAP system level. To analyse business process failures, integration problems, background processing errors, and custom ABAP developments, a standardised diagnostic approach was implemented using ST22, SM21, SM37, SLG1, and the ABAP Debugger.
The ST22 transaction was used to analyse ABAP short dumps, including the location of the error in the program and the execution context. This made it possible to determine whether incidents were related to data problems, authorisation errors, configuration deficiencies, or custom code errors.
SM21 was used for system-level analysis and the identification of technical events, connection problems, locks, and infrastructure errors. SM37 was used to analyse background job failures by checking job status, logs, and execution parameters, which made it possible to identify problems related to run variants, data, programs, or integrations.
SLG1 provided analysis at the application log level in cases where errors were recorded in business logs rather than as short dumps, particularly in integration scenarios and custom developments. When standard diagnostic tools were insufficient, the ABAP Debugger was used to reproduce errors and analyse program execution logic.
This approach improved the quality of escalation by providing ABAP developers with structured technical information, reproduction conditions, and preliminary root-cause analysis instead of a general problem description. The standardised diagnostic package reduced investigation time and improved interaction between functional consultants, administrators, and development teams.
Impact Of The Model On The Development Of Junior Consultants
The structured mentoring program and knowledge base accelerated the development of junior support specialists. Before the model was implemented, new employees mainly learned through informal observation of more experienced colleagues. The new model introduced clear stages of development: from independently handling certain categories of L1 requests to participating in L3 incident analysis under a mentor’s guidance.
Training in technical diagnostics became an important part of this process. Junior consultants learned to independently prepare initial diagnostic information before escalation, which improved the quality of incident handoff and accelerated professional development.
After 18 months of the program’s operation, the following results were obtained:
- The average resolution time for Severity 1-level incidents decreased from 14.2 to 3.8 hours.
- The share of requests resolved at the L1 level increased from 28% to 61%.
- The time required for junior consultants to work independently with critical incidents decreased from 11 to 5 months.
- Staff turnover among junior consultants decreased from 40% to 12%.
- The number of repeat requests for already-documented problems decreased from 31% to 7%.
Practical Principles for Building a Multi-Level Support Model
Based on the experience of building and developing the three-tier support model, the following practical principles can be formulated, applicable to organizations supporting large ERP landscapes.
| Principle | Practical Content |
| Data-driven classification
|
Decisions on the structure of support levels should be based on the analysis of actual requests rather than assumptions about typical problems. |
| Formalised escalation criteria
|
Clear, measurable conditions for transferring a request between support levels eliminate subjectivity and reduce the idle time incidents spend awaiting an escalation decision. |
| Criticality-based SLA
|
A single response time standard applied to all types of requests leads either to excessive expenditure of effort on simple questions or to insufficient attention to critical incidents. |
| Knowledge base as a continuously evolving tool
|
Documenting solutions validated by higher-level specialists provides a “shift-left” mechanism and reduces the number of repeat escalations |
| Mentoring as part of the process
|
Assigning L3 mentors to junior consultants with clear development milestones accelerates the transition to independent work and reduces staff turnover. |
| Diagnostic package for escalation
|
set of data provided together with the escalated request reduces the time required for L3 specialists to reproduce the problem. |
| Technical diagnostic package for L3
|
When escalating a complex incident, it is necessary to provide not only a description of the user’s problem but also technical data: the ST22 short dump, the SM21 system log, the SM37 background job log, the SLG1 application log, the affected documents, reproduction steps, and the results of preliminary analysis in the ABAP Debugger. This reduces analysis time and improves the quality of interaction with the ABAP development team. |
| Continuous measurement and adjustment of the model
|
Regular review of routing criteria based on actual escalation data makes it possible to adapt the model as the structure of requests changes over time. |
The experience of implementing a three-level support model for a large ERP system shows that operational stability depends not only on the quality of the initial implementation, but also on the maturity of support processes.
Formalised escalation criteria, differentiated SLAs, knowledge management, and a structured mentoring program made it possible to reduce the resolution time for Severity 1-level incidents from 14.2 to 3.8 hours, increase the share of requests resolved at the L1 level from 28% to 61%, accelerate the development of junior consultants from 11 to 5 months, and reduce staff turnover.
The standardised approach to diagnosing L3-level incidents using ST22, SM21, SM37, SLG1, and the ABAP Debugger improved the quality of problem analysis and interaction between support and development teams. Support ceased to be purely reactive request handling and became a managed process for ensuring the stability of the ERP system.
The principles proposed here can be applied by organisations interested in building scalable support models that combine operational efficiency with the development of in-house specialist competencies.
