Setting up a complete stand-alone treasury function from scratch is one of the most comprehensive activities for any Treasurer. Having to do this as part of a transaction where part of an existing business is being sold adds a major challenging element: time.
Time pressure together with the uncertainty of who will be the ultimate buyer (Financial Investor vs. Strategic Investor with an existing treasury function) requires many key decisions to be made under uncertainty. One of these key decisions is the one about the Treasury Management System (TMS) and the corresponding functionalities that have to be available on the closing day of the transaction. This decision has two components: costs and time to go-live.
Technical developments in recent years have led to a situation where basic functionalities can be provided in-time by deploying a standard TMS at a cost not higher than any individual spreadsheet-based solution provided by consultants. Therefore, it has become a standard that an integrated TMS is a must-have for Day-1. It provides cash visibility and forecasting, captures both internal and external financial transactions and valuates them for period-end closing, therefore a TMS is the main Treasury Enabler.
With the time remaining until closing usually being quite short (often not more than 3-6 months) the question regarding the long-term strategic fit however has been one of minor relevance. This was and still is the case when the ERP-System is SAP-based. Until now, SAP treasury and risk management and cash and liquidity management components have not been part of the shortlist for transaction related TMS requirements. Three major (valid) arguments have been the reason for this:
But every major technical development requires us to question existing narratives and ask whether certain arguments are still valid.
Making the Right Strategic Choice
Usually, SAP has been dropped from the discussion when an implementation time constraint of between 3-6 months exists. The same applies if the future ERP landscape hasn’t been decided upon. This uncertainty often leads to the decision to opt against SAP. Let’s start with this element. A feasible solution to overcome this uncertainty is that of a Treasury Sidecar, i.e., implement a separate SAP instance with the SAP Treasury components. This allows connection to the existing (SAP) landscape, as well as providing the option of a future migration into a single S/4HANA environment and mapping treasury to the new General Ledger. This means that there should be no strategic or technical reason not to consider SAP.
We also looked at the latest SAP Treasury developments regarding the cloud-based SAP S/4HANA Treasury components from a time perspective. We specifically looked at the Private and Public Cloud Solutions from two angles: What is the minimum implementation time considering that SAP Best Practices are applied and secondly what are the consequences when looking at the integration into either an existing SAP ERP Central Component (SAP ECC) environment or a future S/4HANA platform? What our evaluation revealed is quite astonishing.
Public or Private Cloud?
When looking at the tight timeline argument against SAP we should examine the two main alternatives: the public cloud solution and the private cloud alternative. The private cloud can be considered similar to an on-premise installation, with the main difference being that the private cloud solution can be hosted by SAP or built within in your own data center. A private cloud could also use one of the Infrastructure-as-a-Service (IaaS) providers, such as AWS, Azure, GCP, or Alibaba Cloud.
These alternatives have the advantage of a fixed timeline (3-6 Months) for their implementation based on SAP’s Best Practices approach, together with SAP’s Activate. A requirements gathering is still the starting point to call out what is included in the first phase during its 3 months of implementation. This phase delivers a comfortable solution based on an 80/20 approach and covers what is usually required on Day-1.
Pros & Cons of the Cloud Options
A typical question is: what can’t we do if we opt for either the public or the private cloud? The answer is quite simple: The public cloud is a common environment with restrictions on building what is not already there – i.e. a gap identified is a real gap (and remains so). The private cloud is much like an on-premise solution with certain variations – like the SAP hosted option – where additional restrictions apply in terms of how far you can go about extending functionality.
Building a treasury side car and applying SAP Best Practice and the SAP Activate methodology, and following them closely, leads to similar implementation times for both public and private cloud (or on-premise) options, given that the same functionalities are to be implemented. This means, that implementation duration is not a major decision point. This leaves one key decision element: the question is, what type of flexibility & functional requirements – beyond what’s available in the public cloud solution – are required in the future?
The answer to this may lead to adopting an implementation approach very much like public cloud but in a private cloud (or on-premise) environment in order to get the flexibility needed to extend and expand for the future.
So yes, there is a new kid on the block, and it has to be taken seriously.
Managed by Sluijmer Multimedia and hosted by True.