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.
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.
On the architecture of all SAP ERP solutions, this is based on SAP’s NetWeaver architecture, in which there are three tiers:
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).
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:
Some of the offerings sit on their own platform, for example:
And, some are SaaS cloud tools:
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.
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).
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.
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:
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:
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.
