Efficient SAP systems are critical for modern enterprises to operate at peak performance. However, maintaining optimal SAP functionality requires expert support, continuous monitoring, and strategic optimizations.
At Oblytech, we offer comprehensive SAP Support & Optimization services to help your SAP ecosystem stay efficient, secure, and aligned with evolving business needs. Whether you require ongoing system support, performance tuning, upgrades, or process enhancements, our team works with your business to get more from your SAP investment.
Ongoing SAP support is a decision about who answers when something breaks, who changes a configuration, and who decides which improvements are worth making. The reader is usually the IT operations manager or the SAP application owner, and the decision often follows a bad period: a month-end that failed, a patch that broke an interface, or an engineer who left and took the knowledge with them. The three realistic options are to run everything internally, to hand all run activity to an external provider, or to split it, with internal staff owning business decisions and an external team handling technical incidents and routine maintenance. The split is a common arrangement and one that needs careful definition.
A support agreement is only as useful as its list of covered items. The boundary should state which systems, interfaces, batch jobs and reports are in scope, which custom objects are supported, and which requests count as small changes rather than projects. It should also state what the provider does not do, such as changing the chart of accounts or approving a new process. Ambiguity here produces the familiar argument over whether a request is an incident, a change or new development, and that argument is usually won by whoever holds the stronger contract text.
| Type of request | Usually belongs to | Needs agreement in writing before work starts |
|---|---|---|
| Failed job, interface error or user access problem | Incident handling | Severity definitions and who may raise each one |
| Configuration change to an existing process | Change control | Approval owner and a test step before transport |
| New report or new interface | Development or project | Estimate, owner and acceptance criteria |
| Patch or support package application | Planned maintenance | Test window, rollback step and business sign-off |
| Process redesign | Business decision, possibly with consulting support | Not a support item; scoped separately |
The table shows where a request normally sits. An agreement should map each category to a response process, and it should say that a request falling between two rows is decided by a named person, not by whoever answers the phone first.
Incident handling is the part of support that buyers notice most, and it is the part most often described in vague terms. A workable structure defines severity levels by business impact, so that a stopped payment run is clearly treated differently from a slow report. It defines who can raise each severity, how the incident is logged and how status is shared. It also sets expectations for first response and for progress updates, written as commitments the provider has accepted rather than general aims. Where out-of-hours cover is needed, the agreement should name the hours, the people and the escalation route. Any service level stated in an agreement should be checked against the people who will actually deliver it.
After an incident closes, the useful work is root cause analysis. A short written review that names the cause, the fix and any preventive step turns a recurring problem into a closed item, and it gives the internal team something to learn from.
Run support keeps a system working. Optimization makes it work better, and the two need separate budgets and separate governance. A typical optimization backlog includes slow transactions, reports that users export into spreadsheets, approval routes with too many steps and batch windows that collide. Each item should have a measured problem, an owner and an estimate. Without a measure, optimization effort drifts toward whatever the most senior person happened to mention last.
Performance work should follow evidence. Usage and workload data show where the time goes, and a tuning change should be tested against the same workload before it reaches production. Changes made on instinct are the ones that surface as incidents weeks later.
An external support arrangement can become a dependency if the internal team never learns to run the routine tasks. The agreement should include a plan for shadowing, for runbooks that internal staff write or review, and for a gradual transfer of routine changes. The offshore transition and knowledge transfer plan page covers knowledge transfer, documentation and handoffs, which are the same concerns this plan has to address.
Application management is a related route. Where the SAP estate is one of several applications run by the same team, application management is a related page to read.
Ask which test environments will be used, who signs off the test result and how transports are controlled. An answer that rests on the provider’s judgment alone is not a control.
The answer should point to documentation, runbooks and a second person trained on each critical routine. An engineer’s memory is not a control.
Expect a patch calendar that avoids closing periods, a rollback plan and a business sign-off step. Be cautious of a provider that applies patches on its own schedule.
Incidents take precedence, but optimization items should have agreed capacity of their own so they are not postponed indefinitely.
A support arrangement that is never reviewed drifts. Incidents get closed without their causes recorded, optimization items age without an owner, and the service boundary quietly stretches as requests are accepted informally. A monthly service review is the simplest counter to that drift. It needs a fixed agenda, a short pack prepared by the provider and a named business attendee who can decide priorities.
The pack should show incidents by severity and by system, response and resolution times measured against the agreed definitions, and the changes made during the period with their test evidence. It should list every recurring incident and the status of its root cause analysis. It should show open optimization items with their owners and their measured problem, so that the discussion rests on evidence rather than memory. Where a figure cannot be reproduced from the source logs, the review should say so, because a number nobody can check is not a service measure.
The review is also the place to test the service boundary. Requests handled informally during the month should be examined. If they were small and reasonable, the boundary can be widened in writing. If they were a project in disguise, they should move to the development or project process.
Start by listing the last six months of incidents, changes and requests and sorting them into the categories in the table above. That exercise shows where the current model fails and what a new agreement must cover. The service boundary, cover hours and commercial terms are the points to have written down before any agreement is discussed.
At Oblytech, we provide businesses with comprehensive SAP support services that aim for optimal performance, security, and efficiency. Whether you need ongoing support, performance tuning, compliance management, or system upgrades, we are here to help.
SAP optimisation services cut the time and cost the system spends on each piece of work, and they usually do it by fixing a short list of measured hotspots rather than tuning everything at once. A useful first engagement starts with a baseline and a ranked list of problems.
The term covers four kinds of work: the database and application layer, batch scheduling, custom code, and the business process that generates the load. Each has a different owner and a different test. An agreement that says only “optimisation” tends to leave the most expensive item without an owner, so sort the work by measured cost before anyone proposes a fix.
Start with the workload data the system already keeps. The workload monitor (ST03N) shows where response time goes by transaction type, the job overview (SM37) shows which batch runs overlap or overrun, and an SQL trace on the slowest transactions shows which statements read far more rows than they return. Findings at database or basis level go to SAP technical services, so the ranked list should name an owner for each item.
| Finding | Usual cause | Typical fix |
|---|---|---|
| Batch job overlapping a busy period | Schedule built around convenience, not load | Move the start time or split the job into smaller runs |
| Report reading far more rows than it returns | Missing index or an unbounded selection | Add or adjust the index, or narrow the selection criteria |
| Custom loop making one database call per record | Code written for small volumes | Rewrite as a set-based read and update, then retest with production-sized data |
Measuring once and declaring success is the usual failure. A fix that is fast on a test copy can still be slow at the first real month-end, because the volumes differ. Keep the before figures and test data with the change record.
Sometimes tuning is not enough. If the release is too old to receive the fixes the affected modules need, the honest recommendation is an upgrade, planned through SAP upgrade services rather than another support ticket. Once the first fixes are done, the work turns routine: monitoring, the next hotspot and regression checks on each release. That is usually run as application management support on a monthly rhythm.
A slow SAP system usually needs one of three fixes: tuning the code and database access, moving work to a different time, or adding capacity. The pattern of when the slowness appears tells you which one to choose before any money is spent.
Start with timing. If one transaction is slow at all hours, whatever the number of users, the cause most likely sits inside the transaction. Typical culprits are a missing index, an unbounded selection or a loop that reads the database once per record. That is a tuning problem. If the same transaction is fine on quiet days and slow only during month-end or the payroll run, the cause is more often contention: heavy batch jobs and online users can compete for database and application server resources. The usual fix is to move a batch window or split a job.
A slowdown that begins on a specific date points elsewhere. Ask what changed that day. A transport, a patch, a new interface or a jump in data volume is the usual answer, and the change record often names the cause.
Sizing is usually the right answer when the workload is correct and the system is consistently busy at its normal peak. Before paying for more hardware or memory, confirm that the most expensive statements are tuned and that batch jobs no longer overlap. Otherwise extra capacity tends to make the same inefficiency more expensive to run.
Compare timing data with the business calendar rather than with the complaint log, because complaints cluster around the users who notice first. If the cause is how the landscape is designed rather than how one program is written, a review of the SAP solution architecture is the next step. A common mistake is adding capacity while the three most expensive statements remain untouched.
Guides from the Oblytech ServiceNow library that explain the practice behind this page.