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.

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 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.

• SAP S/4HANA Cloud Edition – https://api.sap.com/package/SAPS4HANACloud/all
• SAP SuccessFactors – https://api.sap.com/products/SAPSuccessFactors/apis/all

Option	Description	Pros	Challenges
Cloud ETL Tool	There are various cloud-based integration tools such as Informatica/ Anaplan HyperConnect, Dell Boomi, Snap Logic and Mulesoft.	Standard connectors for Anaplan available with some tools On a case-by-case basis those tools may have standard connectors with the SAP SaaS product in question as well Sophisticated process orchestration/ scheduling	Cloud ETL tools represent an additional cost, both in terms of the licence/ subscription, but also in terms of the additional skill set needed to implement and support integration solutions on an ongoing basis
SAP CPI	SAP CPI is SAP’s cloud based ETL tool	Being an SAP tool, SAP CPI has excellent connectivity with many SAP products making extracting data from SAP relatively straightforward. Sophisticated process orchestration/ scheduling	No standard Anaplan connector so calls to the Anaplan API must be configured.  This is complex technically, leading to high implementation and ongoing support costs
Hyperscaler + Anaplan Cloudworks	Cloudworks provides native integration with AWS S3, GCP Big Query and Azure Blob file storage.  Files can be imported or exported from Anaplan.	Integration between the hyperscaler platform and Anaplan is simple to set up and maintain. If the organisation has a datalake strategy based on a hyperscaler platform and already has their SAP data stored there, this solution can leverage that data strategy	Whilst moving data between Anaplan and the hyperscaler cloud storage is simple, getting data from the SaaS SAP solution into those storage destinations is less straightforward.  In some cases, the hyperscaler may provide native connections to the products in question (e.g., Azure Data Factory provides connectors to several SAP products) Scheduling in Cloudworks is simple to set up but not able to control up- or down-stream processes in the hyperscaler platform.  This means that scheduling/ orchestration typically needs to be controlled in the hyperscaler platform which can be technically complex
Code-based solution	Most programming languages (e.g., Python, Java) can support the consumption of APIs.  A programmatic approach involves calling SAP APIs to export data and calling the Anaplan APIs to import that data, and vice versa.	This approach provides the most control over the way that the integration works. This approach is most suitable for companies who are already using this approach to other integrations and already have a team of skilled engineers who are proficient in the development of API-based integrations	This approach is the most labour- and skills-intensive approach.  The cost of implementation and ongoing support is likely to be highest when taking this approach. The code needs to be hosted somewhere, typically on a server

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.

‍