"SAP is difficult to use..." A solution to avoid the add-on hell: "SAP Offloading"

What is SAP Offroad?

"SAP offloading" is a design philosophy that focuses on utilizing standard SAP functions while allocating add-on functions to peripheral systems to mitigate complexity. Its strength lies in improving the balance between cost, operation, and flexibility. Let's look at a concrete example to get a better understanding.

Example 1: Master Update

Product masters and business process masters can be updated within SAP. However, building an approval flow involving multiple stakeholders requires many user accounts in SAP. So, how about offloading this to a separate SaaS? The approval flow can be run on the SaaS, and the approved data can be linked to SAP. Only the SaaS users are needed for approval, saving on the number of SAP users. With a SaaS specifically designed for approval flows, complex flows can often be implemented within the scope of standard features.

▼I want to know more about SaaS
⇒ SaaS (Software as a Service) | Glossary

Example 2: Forms

Report creation is possible within SAP using add-ons. However, if you need to flexibly reference data spanning multiple modules, creating it as an add-on makes modifications difficult and tends to depend on specific maintenance members. In contrast, the offload approach involves linking data to a BI tool and generating reports from there. This allows for the handling of data from sources other than SAP, and users can flexibly modify dashboards. In many cases, this can be achieved within the scope of standard functions in BI tools.

SAP offloading solves the challenges of implementing SAP alone, such as increasing complexity, reliance on specific individuals, and the costs and operational burden associated with growing user numbers. In addition, it offers flexibility benefits such as easier version upgrades and easier switching when the system no longer suits the operation (high reversibility).

Back to Top

Common questions about SAP offroading

We've looked at the good points of SAP offroading so far, but you might be wondering, "Is it really that good?" From here on, we'll address some common questions about SAP offroading.

Question 1: Won't SAP's reliance on individual expertise simply be replaced by the reliance on individual expertise in SaaS?

One of the advantages of SAP offloading is the elimination of "complexity and reliance on specific individuals due to an increase in add-ons." However, the question arises: if you develop peripheral systems, aren't the inherent risks the same as with SAP add-ons? Certainly, increasing the number of systems used requires securing personnel who understand each system, and one could argue that the complexity and reliance on specific individuals are simply dispersed from SAP.

Question 2: Won't off-road operation complicate data integration?

Offloading data from SAP to peripheral systems requires careful consideration of data exchanges that were previously confined to SAP. Since SAP and peripheral systems become separate systems, they need to be connected and their data synchronized. When utilizing multiple peripheral systems, data integration can occur not only one-to-one but also one-to-many and many-to-many. Does this complexity outweigh the benefits of "SAP offloading"?

▼I want to know more about data integration
⇒ data integration / data integration platform | Glossary

Back to Top

Design points for successful off-roading

Actually... your concerns are justified. If you proceed without careful consideration, those anxieties will become a reality. SAP offloading is merely a prescription, and there are specific techniques to use it effectively.

Tip #1: Make full use of the standard features.

Not customizing SAP doesn't mean you should instead customize the surrounding systems. That's because that "customization" is the real culprit behind complexity and reliance on specific individuals. To avoid creating operations that depend on specific people or products, let's avoid excessive customization of both SAP and surrounding systems, and make it a rule to utilize standard functions.

When implementing SaaS, you should choose a product that suits your business characteristics and primarily use its standard settings. Even SaaS products with the same purpose have different strengths. For example, Japanese-made SaaS often provides features tailored to Japanese business practices as standard, which can reduce the need for customization without changing your current operations.

Furthermore, when data integration, we recommend using SAP's standard API (OData) rather than building custom integration logic as an add-on. It would be counterproductive to offload the process to avoid custom development only to then have to create custom logic for data integration.

By using standard features, you can avoid complexity and reliance on individual expertise, and create a system configuration that is sustainable for your organization.

Tip #2: Design an architecture with the whole picture in mind.

When offloading tasks involving multiple systems, the key is not to focus on a single point, but to take a broad perspective and understand and manage the relationships between systems. Specifically, instead of viewing SAP and its surrounding systems as isolated "points," consider them as a broad "plane." Otherwise, "data integration," which is the pathway for data between systems, will be overlooked, and a complex network will extend outside of SAP.

When embarking on an off-road project, it usually starts with breaking down one task into its own. However, repeatedly optimizing each task individually in a stopgap manner can lead to a complex network of roads, much like an unplanned downtown area, with limited scalability.

Therefore, we recommend a loosely coupled configuration using data integration platform (iPaaS). By placing a data integration hub at the center, it becomes easier to expand to one-to-many and many-to-many networks. By utilizing iPaaS, instead of developing data integration from scratch each time to match the integration destination, the burden of construction can be greatly reduced by using modularized and standardized components. While leveraging data integration functions of SAP and surrounding systems, clarify the division of roles not only in SAP operations but also in data integration. This will minimize the operational burden and the scope of impact in the event of future changes.

▼I want to know more about loose coupling
⇒ Loose coupling | Glossary

Back to Top

summary

SAP offloading is a solution to the challenges inherent in overly complex SAP implementations. Key keywords include "design without over-engineering" and "appropriate division of labor."

One way to achieve this is through system integration utilizing iPaaS and OData connectors. By adopting a standard data integration method, a loosely coupled design that avoids complex customization is achieved, enabling highly reversible offloading.

Please consider this approach not to be used by SAP, but to fully utilize SAP. If you have any concerns about SAP offloading or data integration, please feel free to contact us.

Thank you for reading to the end!

Back to Top

The person who wrote the article

Affiliation: Development Division, Product Management Department, Planning

Chiho Suganuma

After joining Saison Technology, I spent five years working on projects related to accounting DX, including the implementation of financial closing SaaS such as Blackline and data integration with ERP systems. As a PL/PM, I managed implementation projects for approximately 20 companies. Currently, I am also challenging myself to create new businesses. My hobby is playing in an amateur orchestra.
(Affiliation is as of the time of publication)

Recommended Content

Related Content