This article first appeared on OneStreamsoftware.com by Nicholas Cox
Having worked in the Finance/Software business for more than 25 years, I regularly get asked which should be implemented first – EPM or ERP, such as SAP S/4 HANA. I always say EPM! Why? Well, the EPM solution is a management layer above all transaction systems. EPM software provides a level of agility and visibility, one that’s now critical for any organisation seeking to successfully handle the complexities of growth, change and disruption. With this effective management layer in place, organisations can easily upgrade or replace underlying ERP/GL systems as and when required – without disrupting the flow of critical management processes.
I would say the same exact thing to someone considering SAP S/4 HANA.
And as far as software goes, OneStream fits the bill perfectly because it’s completely agnostic to ERP strategy. Why does this feature matter? Well, it’s simple: Unlike SAP’s EPM strategy, OneStream doesn’t require (though works with) S/4 HANA and therefore offers a much faster time to value than SAP’s long-term strategy. Rather than relying on a central ERP strategy, OneStream seamlessly integrates data from multiple sources – such as ERP, CRM, HCM and data warehouses – to create a single, powerful and governed version of the truth. And that’s exactly why I advise to implement OneStream before S/4 HANA.
S/4 HANA doesn’t come cheap and can take time to implement, to say the least. But that just makes it even more important to focus on time to value and how to maximise the return on investment.
5 Key Reasons to Implement OneStream before SAP S/4 HANA
The following key points explain why implementing OneStream prior to having the S/4 HANA instance up and running offers so many benefits:
1. Inter- & Intra-Company Differences – Depending on how the S/4 HANA implementation is being done, OneStream can help with both inter- and intra-company differences. Some organisations move over to S/4 HANA in stages (instead of the big-bang shift) and even break up the entity and move by segment. When this segmentation happens, it can ultimately create an issue. How? Well, part of the data is in S/4 HANA and part of the data is in the legacy system. Users are then often forced to copy or move transactions between the two systems. And that approach can cause timing issues and differences in the balances.
Having a holistic view in OneStream by those related accounts can help users identify any issues/differences. By bringing together the old and new systems, OneStream not only ensures that any un-booked or missing transactions are identified, but also validates that the correct feeds of data are being included.
Transaction matching can be used within OneStream (See Figure 1) to get visibility of transactions across both S/4 HANA and the legacy system. This visibility delivers the end-state view to users in a robust future state system – and does so in a faster timeframe than waiting for the S/4 HANA implementation to be completed.
Figure 1 – Transaction Matching in OneStream
2. GL Account Harmonisation – This task is critical for any S/4 implementation and can be very difficult to manage with multiple systems. Users find it difficult to get any kind of trend analysis, and Excel is often used just to maintain a view of what’s happening. Over a typical S/4 HANA implementation period of 2-3 years, this disparate system can be a significant headache for the team.
If OneStream is implemented prior to SAP S4 HANA, however, the end-state accounting structures are available for reference and ensure the correct alignment of the new system. Data can be loaded from the GL level into the detail of a cube. Doing so ensures everyone has insight into where the data is coming from in the new system. And that visibility gives people time to switch and adopt the new accounts, entities, structures, etc., while also understanding how the legacy data maps into or utilises the new S/4 HANA structure. Users can drill down from balances in OneStream to the transactional-level data – regardless of whether it’s been loaded from legacy systems or the new S/4 HANA. Importantly, this process isn’t ‘throwaway work’ and ensures the correct alignment of the OneStream and S/4 HANA systems right from the start.
3. Cashflow Accounting – Cashflow statements are not only notoriously difficult to set up but also continue to be an area of concern for many organisations. In any S/4 HANA implementation, delivering cashflow statements can take a considerable amount of time due to the process involved in rolling out the system to all entities.
The best option is to implement the cashflow statement first in OneStream and continue to use it going forward. The cashflow statement/calculation setup in OneStream will provide a reference for the future state of setting up cash flow accounts in the S/4 HANA system. This reference ensures a fast, reliable delivery of the full cashflow to users – without any disruption or delay during the transition from legacy to S/4 HANA. A lot of costly reworking would be required after S/4 HANA implementation if the cashflow setup was delayed until then.
4. User-Defined Dimensions – When it comes to currency translation and allocations, they don’t always get carried forward in any transition from legacy to S/4 HANA. Some of the detail can get lost via summarisation/aggregation, which then makes it very difficult for users to get back to the detail and explain any differences.
If user-defined dimensions are set up for the required level of detail in OneStream (e.g., Customer/Product), however, the S/4 HANA implementation can ensure the new system is set up to provide the same level of granularity. At any point in time, users can view balances and drill down to the transactional-level detail for a fast analysis and explanation.
5. Sunset Legacy – In any move to a new system, concerns about the historical data often persist. Users must be able to access this detail and use it to compare or explain balances in the future. Keeping a legacy application alive, though, can result in significant ongoing costs (e.g., support fees and hardware maintenance).
OneStream can be set up so that the legacy systems can feed historical data into a dedicated cube. In other words, the legacy systems are no longer required. They can instead be ‘sunset’ whilst retaining the ability to view the history. This functionality saves the costs and time which would otherwise be involved when accessing the legacy system and extracting information.
Conclusion
Implementing OneStream before SAP S/4 HANA provides organisations with the end-state view of reporting in a robust EPM platform – one that helps organisations save valuable time and avoid added costs. Taking this approach significantly increases user adoption because OneStream helps users quickly get a consolidated view of the various systems in the new format. As a result, users get valuable insights faster than with OneStream implemented after S/4 HANA and can drill down to see which legacy accounts or dimensions comprise the numbers at any given time.
With OneStream in place as the EPM management layer, organisations can move forward with confidence. Any unexpected delays in the move to S/4 HANA won’t impact the robustness of process and reporting. In addition, any new organisational events (e.g., acquisitions) can rapidly be integrated into OneStream for immediate reporting. And if there’s a subsequent shift from the acquisition’s legacy ERP system to S/4 HANA, that shift won’t have any impact on the reporting in OneStream – which comes with a host of benefits.
Learn More
Ready to join the organisations that have taken the step to implement OneStream before SAP S/4 HANA? Click here to download our free white paper titled ‘SAP ERP and OneStream – The Path to Modern Finance’.
