SAP systems need ongoing technical support, development, and optimization as business requirements change. At Oblytech, we work on SAP Technical Services, helping enterprises improve their SAP environments through custom developments, integrations, and performance improvements.
Our SAP technical team builds solutions for specific requirements, from SAP ABAP programming to cloud migrations, with the aim of keeping your business operating efficiently and securely.
Technical SAP work comes in a few recognizable shapes, and most buyers already have one of them on a list: a custom report nobody can maintain, an interface that fails overnight, a Fiori app users have asked for, a database that slows every month-end, or a move of workloads to a cloud platform. The reader is usually the SAP lead or IT director, and the question is which technical capability to commission and how to make sure the result can be maintained. This page sets out how to frame those items so a provider can price and staff them sensibly, without assuming one technical team is equally strong at all of them.
| Backlog item | Work involved | What the buyer must hand over | What to verify at acceptance |
|---|---|---|---|
| Custom report or program that is slow or unmaintained | Analysis of existing code, redesign, performance check | Current code, the users who rely on it and sample outputs | Output matches the old report for agreed test data |
| Interface that fails or needs a new partner system | Mapping, error handling, monitoring setup | Interface specification from the partner and a named error owner | Failure and retry paths tested with a real error |
| Fiori or UI5 application | Design, build, authorization setup | User tasks, roles and the data each role needs | Role-based access tested with a user from each role |
| Performance problem in a process | Trace analysis, index or code tuning | Timings before and after, and the workload profile | The same workload runs faster in the test system |
| Workload move to a cloud platform | Sizing, migration runbook, cutover rehearsal | Inventory of systems and the owner of each | A rehearsed cutover with a tested return path |
The table is useful because it shows what each item asks of the buyer. A provider that cannot describe the handover artifacts for a given item has not yet understood the work.
Custom development is easy to start and expensive to own. The first release of a custom program or extension is rarely the costly part. The cost arrives in later years, when a business rule changes, an upgrade removes a function the code depended on, or the original developer is no longer available. Good practice is to document the purpose of each object, keep it inside a version-controlled transport route, review changes before they move, and prefer standard extension points over modifications of standard code. Where a custom object supports a process that will change, the design should keep the change local rather than spread it through the system.
Enhancements built on documented extension points generally survive upgrades more easily than modifications, though each still needs testing against a new release. A buyer should ask how the provider decides between the two, and what evidence it will provide for the choice.
An interface is a contract between two systems, and many interface failures happen because one side changed without telling the other. The technical service should define the message format, frequency, error handling and owner on each side before build starts. Where the interface runs through a middleware layer, that layer’s monitoring belongs in the handover, so an operations team can see a failed message without opening a developer tool.
Data movement is a related but separate item. Migrating or synchronizing data needs its own validation, reconciliation and rollback steps, and should not be bundled into an interface build without a separate test plan.
Basis administration covers the platforms the SAP applications run on: database maintenance, memory and performance monitoring, backup and restore, user and authorization administration and the transport system. It is continuous work. A buyer should separate one-off tasks, such as an installation or a kernel update, from the routine tasks that keep the system stable. Routine tasks belong in a checklist with a frequency and an owner. One-off tasks belong in a project with a plan.
Performance tuning sits between basis and development. A slow process may be caused by the database, by a custom program or by a configuration choice. The first job is to find which one using trace data, rather than changing code and hoping.
Name the internal owner for each custom object and each interface before work begins. If no internal owner is available, the engagement should include a training step, not only a handover document.
Ask which environment will be used, how test data is prepared and whether it is refreshed from production under the agreed data rules.
Ask whether the provider keeps a record made at the time of the change, and whether that record is reviewed afterwards. The answer tells you more than a description of the route.
Many providers can. The arrangement works best when internal developers review the code and the provider documents its decisions in a form they can read.
A good deal of the damage done to custom code can happen in transport, not in development. A correction moved straight into production, a transport that carries an unreviewed object, or a production fix that is never copied back to the development system all create a gap between what the team believes is running and what is actually running. The discipline that prevents this is simple to state and tedious to keep: every change follows the same route, every route leaves a record, and every production move carries an approval naming the person who accepted the risk.
Release pipelines help once the team is large enough to need them. Source control for custom objects, automated checks before a transport is released and a consistent naming convention for transports all reduce the manual steps that can go wrong. The DevOps automation page lists CI/CD pipelines among its services, and the same release automation principles apply to SAP transports as much as to other code. Where the size of the team does not justify a pipeline, a documented manual process with a checklist is still better than an informal one.
Emergency fixes need a route of their own. A rule that no change reaches production without a test is sound until a payment run fails at the end of the afternoon. An emergency route should define who may authorize the change, how it is tested as far as time allows, how it is recorded at the time, and how the fix is carried back into the normal development line so the next transport does not undo it. The review after an emergency change is where the team learns whether the route worked.
List your open technical items in the form the table above uses: what the work is, which system it touches and what you will hand over. That list lets a provider scope the work honestly. Discuss your SAP technical backlog with the Oblytech team.
At Oblytech, we deliver SAP technical solutions for smoother operations and better integrations. Whether you need custom SAP development, system integration, or performance optimization, our team can take on the work.
SAP technical services cover the work that changes or keeps running the code, interfaces, data movement and platform beneath an SAP system. Functional work changes how a business process is set up, such as which values a company code uses or how an approval route is defined. If a process owner can meet the request by adjusting settings the functional team already controls, it is functional. If it needs new code, a new connection to another system, a different way of loading data, or work on the platform itself, it is technical.
A quick test is to ask what would have to change if the business rule changed. A new approval step that standard workflow tools can express is a configuration change. A pricing rule the standard system cannot represent needs a program, and that program becomes technical work with its own testing and transport route.
| Request | Usually functional | Usually technical |
|---|---|---|
| A new approval step | Standard workflow set up in configuration | A custom workflow that calls logic the standard cannot reach |
| A report users want | Standard report with a different selection or layout | A new program that reads data the report cannot access |
| Data from another system | A mapping decision made by the process owner | An interface, its error handling and its monitoring |
Two mistakes show up often. The first is commissioning custom code for something a configuration change would solve, which then has to survive every future upgrade. The second is the reverse: a team configures around a missing capability for years until users keep their own spreadsheets. In most implementations, a short functional review before any build asks which standard option was tried, why it did not fit, and who will own the result after go-live. If the review points to configuration, the ongoing SAP support and optimization route is usually where the change belongs.
Custom code written against an older release is the part that tends to need attention during an upgrade, so a technical request meant to last should be checked against the SAP upgrade planning work before it is built. Requests that sit inside a specialised module are covered on the niche SAP modules page.
When the answer is technical, bring three things to the first conversation: the business rule in plain words, the systems involved, and a sample of the input with the output you expect. A provider that asks for these first is showing how it will staff the work.
Guides from the Oblytech ServiceNow library that explain the practice behind this page.