Integrating Anaplan and SAP

April 2023
Written by
Tristan Colgate
minute read

Integrating Anaplan and SAP

If you are reading this blog, the chances are that your organisation uses SAP and either already uses Anaplan or is evaluating Anaplan and you want to know how to integrate the two platforms.

SAP quite rightly claim that the “best run companies run SAP”.  I would suggest that even better run companies use Anaplan to plan, track and analyse their business performance, and use SAP to execute those plans.  To achieve that requires the two platforms to be tightly coupled and the good news is that this is a well-trodden path with some good options for achieving integration.

This blog focuses on how to achieve the technical implementation between SAP and Anaplan. In doing so, this leaves the other important aspects of integration –how to ensure the two systems work together to support a coherent business process in a seamless way, and how to ensure that data is governed properly across the enterprise landscape.


What do we mean when we say “SAP”?

Typically, when people refer to SAP, they are referring to SAP’s Enterprise Resource Planning software, used by companies to manage their business operations, including Sales, Supply Chain, Finance and Human Resources.  SAP was founded in 1972 and its SAP R/1 (then R/2) ERP solution was ground-breaking in its ability to provide a joined-up solution across all business lines of a company.  As the solution evolved to a client-server model it was renamed SAP R/3 (sometimes referred to as SAP ECC).  With the advent of SAP’s home-built SAP HANA in-memory database, the solution evolved to become SAP S/4HANA.  At this point in time, most organisations using SAP have either migrated to SAP S/4HANA or have plans to do so as the older versions cease to be supported.

Until the advent of SAP S/4HANA, SAP’s ERP solutions (with some small exceptions) were all on-premise systems.  These were either installed on the customer’s own physical hardware, hosted by a support partner, hosted in a hyperscaler, or hosted in SAP’s own SAP HANA Enterprise Cloud (SAP HEC) platform.  Even when hosted, the customer had their own installation and a large degree of control over what happened to that installation.

SAP S/4 HANA, however, is available both as an on-premise solution or as a multi-tenant SaaS solution, called SAP S/4HANA Cloud Edition.  The SaaS solution acts like any other SaaS solution – options are available to configure the solution, but these are more restricted than the on-premise version, and there is less access to the underlying architecture.  The approaches for integrating the on-premise and multi-tenant SaaS versions of SAP’s ERP solutions are very different and it is important to establish from the outset which version you are dealing with.

SAP technical architecture

On the architecture of all SAP ERP solutions, this is based on SAP’s NetWeaver architecture, in which there are three tiers:

  1. The operating system – the SAP NetWeaver architecture can be installed on numerous operating systems including Linux, Windows and Unix.
  2. The database tier – the SAP NetWeaver architecture can sit atop numerous databases including Oracle, DB2 and SAP’s own SAP HANA database.  Note that SAPS/4HANA assumes a SAP HANA database.
  3. The application tier – application functionality is developed in SAP’s ABAP/4 programming language.  As well as the core ERP business functionality, this supports administrative and connectivity functionality.

Of course, it is important to understand this architecture if your organisation uses the on-premise version of SAP.  If you have the multi-tenant SaaS version of SAP, then the architecture is not something you need to concern yourself with as SAP handle this for you (but it is there in the background).

SAP is not just ERP

Having been around for over forty years, SAP have increased the breadth of their offering in pursuit of their goal of providing a single platform upon which a business can run their operations.  This has been through a mixture of organic product development and over seventy acquisitions.

As a result some of SAP’s non-ERP offerings sit on the NetWeaver platform.  For example:

  • SAP Business Warehouse – this is SAP’s home-built datawarehouse
  • SAP Business Planning and Consolidation – this is SAP’s EPM tool
  • SAP Customer Relationship Management – SAP’s CRM tool

Some of the offerings sit on their own platform, for example:

  • SAP Financial Consolidation
  • SAP Profitability and Cost Management

And, some are SaaS cloud tools:

  • SAP SuccessFactors – SAP’s Human Resource Management solution
  • SAP Concur – an expenses management solution
  • SAP Ariba – a procurement platform    

Suffice it to say that understanding precisely which SAP tool you are integrating with is crucial to developing an integration strategy, given the difference in underlying technical platforms.

Integrating Anaplan with NetWeaver based SAP solutions

NetWeaver is installed on a server – either on an organisation’s own hardware or hardware hosted by a supplier, or hardware hosted through a Hyperscaler like GCP, AWS or Azure.  Regardless of where NetWeaver is hosted it is almost always protected by a firewall. This is an important consideration when choosing an integration approach as typically organisations require safeguards around external networks and/ or software accessing data in SAP.

Whilst NetWeaver always stores data within a database, it is not best practice to access the underlying database directly.  Rather, the best practice approach is to access SAP data through the NetWeaver application layer, via RFCs (Remote Function Calls) or BAPIs (Business Application Programming Interfaces).

Figure 1 - options for integrating Anaplan with on-premise NetWeaver based SAP solutions

Integrating Anaplan with SaaS SAP solutions

Depending on the particular SAP SaaS product in question, it may be possible to integrate with Anaplan using a publicly availably API.  The table below shows SAP products that have well documented APIs that can be used by third party applications.

Figure 2 - options for integrating Anaplan with SAP's SaaS products

Key questions

In summary. there are numerous ways of integrating SAP and Anaplan, and it is important to ask a number of key questions before deciding upon an approach:

  • What SAP product(s) do you want to integrate with Anaplan?
  • What is the underlying architecture of the SAP product and where/ how is it hosted?
  • What is your overall enterprise data strategy?  Do you have a datalake strategy and an existing Hyperscaler platform where your data resides?
  • Do you already use any Cloud-based ETL tools for other SAP integrations?
  • Do you already use SAP CPI?
  • As well as SAP, what other software products will you integrate with Anaplan?
  • What are your requirements regarding data latency across the integration?  In other words, how frequently should the integration run?
  • Related to data latency, what are the expected data volumes and what is your approach in terms of managing that volume with, for example, delta extraction?
  • How do your data security policies impact the way the integration needs to work?

Beyond technical integration

This blog has focused heavily on how SAP and Anaplan can be integrated at a technical level.  There are of course two other factors to consider:

  1. The integration will be supporting the integrity of the end-to-end business process that is being supported.  For example, if Anaplan is being used to manage the creation and approval of new marketing budgets, the integration to SAP may be required in order to create the corresponding Projects/ WBS Element(s) in SAP Controlling for approved projects, with the appropriate budget from the data in Anaplan.  Actual spend against that Project/ WBS Element(s) captured in SAP Controlling may then be brought back into Anaplan for tracking, forecasting and reporting of spend on that project.
  2. The integration will support the integrity of data across SAP and Anaplan (and potentially other systems).  In the example above, it is important to strictly define and control where and how new Projects/ WBS Elements are created in order to ensure there is ‘one source of the truth’ and to preserve financial controls and auditability.

These parts are arguably harder to get right than the technical integration.  Key to success here is ensuring you have architects on the team who understand both SAP and Anaplan, from a process, data and technology perspective.  These people have the skills to define a coherent data and integration strategy to ensure a successful outcome.

Share this insight:

Related insights