Many of you in the Enterprise Performance Management (EPM) space immediately recognize the name Cartesis, regardless of whether you’re an actual customer. Before I dive into the nitty gritty about the positives and negatives of Cartesis, though, I’ll dive into a little of the history for those of you unfamiliar with the name.
A French company, Cartesis developed a product eventually renamed from Magnitude to Cartesis Finance. Cartesis Finance, the company’s flagship offering, was at the time (and using the company’s words) “the only fully integrated, web-based solution for enterprise performance management.”
Cartesis’ unique integrated data model supported the key financial management activities – planning, budgeting, forecasting, statutory consolidation, management reporting and performance management (see Figure). While the Cartesis Finance product was sold widely, including in the UK and US, with around 700-800 customers, a large percentage of customers were in France.
Cast your minds back to 2007. At the time, significant “consolidation” occurred among EPM vendors. Oracle acquired Hyperion early in the year. Business Objects announced the acquisition of Cartesis the following month, and then SAP rushed to acquire OutlookSoft.
SAP went a step further in late 2007 and acquired Business Objects. This acquisition resulted in SAP owning multiple EPM solutions. While Cartesis Finance became SAP Business Objects Financial Close (BOFC), it was later renamed simply to SAP BFC.
Now that you know the history, I’ll dive into the positives and negatives of Cartesis/SAP BFC.
Cartesis Finance (previously Magnitude) was designed in France, a country known for having the most complex accounting and reporting rules in the world. Cartesis began as an internal project in the global French company Vivendi and was subsequently spun out into an independent company. The team therefore focused on the complexity of both global companies and the French accounting rules, targeting primarily the largest French companies and those in the CAC-40, France’s principal stock market index. The resulting solution was technically strong and could handle almost any challenge.
In Cartesis’ words, “Our powerful technology handles the complex but essential task of unifying information, people and processes in a single data model that can be applied easily and consistently across your company’s business.”
Below are the sweet spots for Cartesis’ product:
Cartesis/SAP BFC also natively supported the elimination of inter-segment trading within a single legal entity with multiple business segments. Again, this feature intentionally supported only the largest, most complex consolidations.
In Cartesis/SAP BFC, all journal entry data was analyzed by a specific dimension dedicated to tracking journals, called “journal entry number.” Consequently, reports could be built that retrieved the detail of a specific amount based on the journal entry header. This type of report was extremely useful in determining how an amount is built up from the input level to the consolidated position – especially if multiple manual journal entries had been posted to the same account.
In sum, Cartesis/SAP BFC was much more capable than peer platforms at supporting several reporting cycles with differing analyses. The solution evolved to support the complex statutory consolidation requirements in the business models of the largest organizations. This evolution, however, was to the detriment of other requirements (e.g., budgeting, forecasting and cost & profitability requirements) – and the negatives of Cartesis didn’t end there.
As alluded above, the evolution of Cartesis/SAP BFC continued a complex statutory consolidation trajectory. This trajectory eventually contributed to some challenges when other more comprehensive EPM technology suites appeared on the market that offered planning & budgeting capabilities or more advanced analytics.
Another major issue was the technical architecture of Cartesis/SAP BFC. The relational database design was complex, and SAP would eventually choose not to make the application available on HANA, creating an uncertain future where the product would only be supported for a set number of years.
Despite being a popular application, Cartesis/SAP BFC has the following recognized limitations:
In the positives, I mentioned the tight control over the data collection/entry environment. Many users, however, found this control to be a negative over time. Why? Well, for data entry in Cartesis/SAP BFC, each specific data entry point had to be explicitly opened during the development phase. By default, all intersecting data points were blocked for data entry or importation. During implementation, the development team must then open each individual data point or ranges of data points. As you can imagine, this process caused delays and frustrations when new intersections needed to be opened.
The intuitive workflows that many users today are familiar with were not a feature of Cartesis/SAP BFC. Data submitted to Cartesis/SAP BFC had to follow a pre-defined process of being entered into a data entry environment known as the “package layer.” Once submitted to a package, data had to be validated, published and integrated. Publishing a package was the equivalent of stating the data within the package was available for review. Any amount not integrated (data would physically be copied to a pre-consolidated level) would not be selected by the consolidation. No deviation from this cumbersome submission process was allowed, which frustrated many users.
Finally, intercompany reconciliation/matching at balance and transaction was only available with a separate web-based tool called “Intercompany Server from Cartesis,” since re-branded to SAP Intercompany. Using the tool required manual data transfers to and from the actual data source.
Many organizations are facing the end of support for their Cartesis/SAP BFC application, announced for 2027. Many customers will be forced to implement SAP S/4 HANA. Both those customers and those using other SAP Legacy EPM Systems for Consolidation and/or FP&A face high risks in following the SAP Strategy with Group Reporting and Analytics.
SAP’s vision for EPM is based on a combination of the new Group Reporting product for consolidations and SAP Analytics Cloud (SAC) for planning and budgeting. SAP Group Reporting and Analytics Cloud for Planning requires that customers move to S/4 HANA Cloud for their ERP.
To give customers enough time to transition to SAP S/4HANA for group reporting, SAP decided the following:
Those decisions leave customers at risk. So if your organization uses Cartesis/SAP BFC, you have three choices:
To learn about those alternate strategies, make sure to tune in for our next blog in this series, in which we’ll examine the choices in more detail.
Ready to join the organizations that have taken the step from Cartesis/SAP BFC to OneStream? Check out our video here, and be sure to visit our website.
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.
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.
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.
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’.
As we discussed in Part 1 of this series, Finance teams running legacy SAP solutions are being put in an uncomfortable position. How? Well, despite billions of investment dollars across thousands of customers, SAP is pushing all long-term Finance Transformation through its SAP HANA platform. And with support ending for legacy EPM (and widely used) products such as BPC beginning in 2024, Finance organizations have an important question to answer.
How can Finance organizations drive innovation forward with speed and agility, without compromising critical requirements or getting sucked into a multi-year project?
If your organization uses SAP for EPM, you have three choices:
– Choice 1: Continue with legacy SAP EPM products until their end of life.
– Choice 2: Invest in SAP’s unproven next-generation products, such as Group Reporting, Analytics Cloud (SAC), and maybe Central Finance or some variant hybrid strategy. Note that this strategy requires at least one S/4 HANA Finance instance to support Group Reporting.
– Choice 3: Take control of your Finance Transformation by evaluating alternate EPM strategies with a solution such as OneStream.
Where to begin? No matter where your organization is on its Finance Transformation journey, getting “under the hood” with a thorough due diligence process is critical to understanding how different technologies can impact your Finance team’s user experience. And that is exactly why we’re focusing this post, Part 2 of our blog series on demystifying S/4 HANA and SAP EPM, on key evaluation factors to help you assess how SAP’s transformation strategy might impact your organization.
Key Evaluation Factors
Here are the four common evaluation factors we outlined in our first post:
For those of you evaluating an alternative EPM strategy, we’ll also share some of the feedback from our 130+ SAP ERP customers. Many of them have already replaced SAP BPC, BFC and other legacy products as well.
Let’s dig into each of the key evaluation factors.
Evaluation Factor 1: Complexity
As part of any Finance Transformation, organizations must conquer the complexity inherent within their internal systems to simplify the administration and maintenance of critical processes. Figure 1 illustrates SAP’s multi-product strategy. Each product requires its own resources, skill sets and coordination between respective implementations.
As illustrated in Figure 2, the SAP EPM solution is fractured into multiple products. Each arrow you see is an integration point that must be created and maintained. SAP Analytics Cloud (SAC) is the only native cloud solution – the other solutions were not designed specifically for the cloud.
Thus, a mixture of platforms – which adds risk, cost and complexity – could be needed. Lastly, since each product requires its own skill set, administrators are specific to each product and are not leveraged across solution areas.
In comparison, OneStream (see Figure 3) is a unified corporate performance management (CPM) solution on a single platform. There’s only one integration between your source systems and OneStream, regardless of which EPM processes (e.g., planning, financial close, accounting reconciliations) are part of your solution. Plus, since OneStream is a single product, experienced administrators’ skills can be leveraged across solution domains.
Evaluation Factor 2: Change Management
Change Management (see Figure 4) is another key evaluation factor. Why? Because SAP is asking its customers to commit to a Finance Transformation project that will require significant management resources and oversight over several years across the ERP and EPM technology stack.
By contrast, with OneStream, a project requires only updating your CPM management layer. This step will enable your organization to focus exclusively on innovating and fulfilling the needs of the financial management team and senior executives.
Evaluation Factor 3: Timing
Project timing and time to value are also key evaluation considerations (see Figure 5), especially when evaluating an “ERP first” strategy. Why? Well, right from Day 1, organizations will feel the immediate impacts of cash outflows and mass activity across the entire Finance, Supply Chain and other key functions involved in requirement gathering and project planning.
Impact of ERP Before EPM Investment Strategy
The SAP EPM architecture requires organizations to implement at least one S4/HANA instance before any other work can be done (see Figure 6). In addition, the structures for statutory and management reporting must be built in the S/4 HANA environment as the efficiency of Group Reporting and Central Finance are dependent on S/4 HANA structures. Thus, the initial design portion of the project is lengthened to ensure all EPM and ERP requirements are included in the Global Design.
Why does this matter? Well, those requirements mean you’re looking at a minimum 18-month ERP implementation before work can even begin on the EPM solutions. And if you’re part of a large, global and complex organization, your organization could be looking at a 3- to 4-year ERP implementation before that work can begin.
Comparatively, the OneStream architecture allows you to implement your CPM solution first (see Figure 7). By devoting your efforts to the CPM solution, you will generally see benefits within 6-12 months of starting the project.
And by focusing on the decision-making layer of Finance Transformation, you will address the critical management needs first. This strategy will also provide another benefit: the new chart of accounts would be initially implemented and controlled in OneStream. Once solidified, this structure would then simplify and reduce the design effort of any new ERP system – which will shorten the ERP implementation cycle.
The structure also provides the benefit of extending the timeframe for you to decide on the fate of your current ERP, providing additional runway for you to undertake a more complete analysis of your ERP needs and perform the proper due diligence for that project.
Evaluation Factor 4: Investment
With any project, the actual investment (see Figure 8) should always be a significant consideration. The dollar value of the investment, if great enough, can impact other corporate priorities. Also, as the saying goes, “the larger the investment, the greater the risk.”
Conclusion
Modernizing aging transactional ERP systems and EPM solutions are important and strategic projects that can support finance transformation. And there’s no question that a substantial investment of time and resources is required to upgrade to SAP S/4 for Finance Transformation.
So which do you invest in first – the ERP systems that run the business, or the EPM solutions that help you manage the business?
If you’re a Finance team with immediate needs to drive agility across planning, financial close and other key processes, you must consider the business value of accelerating the Finance Transformation by conquering the complexity of your EPM processes before you embark on an ERP upgrade. You may even find that the value you create will fund your ERP transformation when the time is right.
Learn More
To learn more about why SAP customers are moving to OneStream, read our whitepaper here.
Over my 20+ year career within the corporate performance management (CPM) industry, I’ve talked to hundreds of SAP customers about their Finance Transformations. And most Finance users reported facing a pretty common challenge: How can Finance leaders drive performance if they’re consumed with the complexities of managing multiple applications in the SAP enterprise performance management (EPM) ecosystem?
Here’s my take. Fragmented EPM solutions add risk, cost and complexity to financial processes (e.g., financial consolidation, planning, analytics and financial data quality). And if the purpose of Finance Transformation is to help organizations modernize and simplify processes, technology should reduce risk, not add more. In fact, I often suggest Finance leaders start their evaluations by asking a simple question – how can your organization take steps to reduce complexity?
Is your organization feeling “stuck” with a legacy CPM application that’s not seeing any innovation and is planned for retirement in the next few years? Reliance on legacy corporate performance management (CPM) products that are going off support often create an opportunity for Finance teams to consider alternatives to their legacy vendor and create new opportunities for Finance transformation.
Modernizing finance across a global organization requires a high amount of focus on unifying the data. To create the most effective financial consolidation and reporting process, you must bridge the gap between ERPs, various operational systems, and corporate performance management (CPM) software. Increasingly more organizations with fragmented ERP systems are taking the leap from fragmented spreadsheets and legacy CPM products to a unified CPM platform that supports faster, more informed decision-making. Read on to discover how a global supplier of chemical and water treatments discovered the path to modern finance with OneStream Cloud.
As global enterprises grow and evolve, their financial reporting and planning requirements become more advanced and they often outgrow their legacy corporate performance management (CPM) applications. Integrating data from multiple GL/ERP systems, managing complex intercompany relationships, and reporting results to stakeholders often requires manual workarounds and reliance on Excel spreadsheets to fill gaps in the CPM applications.
Having worked with finance executives for over 20 years now on software selections, its clear that they prefer to select platforms that can provide them a rapid payback and strong ROI. They typically also prefer software that provides a stable, consistent environment on which to support their finance processes for 5 – 10 years, and sometimes even longer. What finance executives don’t appreciate is having the rug pulled out from under them as a vendor announces the end of support for a platform they are relying on, forcing a major upgrade or re-implementation.
Legacy ERP, data warehouse and fragmented corporate performance management (CPM) applications can hinder the effectiveness of finance teams. Instead of focusing on the business – many finance staff spend nights and weekends managing multiple systems, moving and reconciling data, and trying to create meaningful management reports.
As the corporate performance management (CPM) market grows and evolves, there is growing recognition in the market of the role and value CPM solutions play versus ERP systems in today’s enterprise. ERP and CPM (a.k.a. EPM) systems are related, and need to work together – but they are focused on different purposes.
Transforming finance processes and modernizing finance systems are key initiatives for many organizations. These initiatives should include operational systems – such as ERP, CRM, HCM and Supply Chain – to support operational excellence. They should also include corporate performance management (CPM) applications that enable better, faster management decision-making.