Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member

[Edit May 1st, 2015: I included here answers to very interesting questions from the comments]

I was lucky to be able to attend both BI / HANA and Financials conferences offered by SAP Insider in April 2015. In both cases, Simple Finance was covered in details and customer questions were frequently related to specific situations for which most answer had to start with : "well, it depends".

I am also taking this opportunity to follow-up on my article on Implementing SAP Simple Finance that generated lots of very interesting questions in the comments section or by email. If you missed it, I suggest you read it first.

It's not a Solution, it's a Deployment Option

To paraphrase TruQua's davidcdixon: "Central Journal is not a solution, but a deployment option for Simple Finance". And not a recent one. As early as 1998, several of our large customers have chosen to use several ERP systems, for reasons related history / growth (mergers or acquisitions), sizing / performance optimization (separate finance from logistics from purchasing, etc.) or legal / regulatory considerations (separate different GAAPS). SAP used to support and promote hybrid implementations in its battle to outpace best-of-breed solutions like JD Edwards or Siebel.

Source: David Dixon, TruQua Enterprises

What is wrong with today's way?

If you have multiple ERP systems, you have to consolidate the financials just to meet regulatory reporting requirements. Today, most companies are consolidating several ERP and/or non-ERP systems into a business warehouse like SAP BW and may use reporting tools from the Business Objects tool set.

(c) Julien Delvat, Alta Via: Consolidation through SAP BW

There are however several limitations here:

  • Data import from ERP systems into BW is batch driven, mostly overnight. Not real-time,
  • Data is aggregated in BW. Access to line item can be achieved through report-report interface, but makes it hard to find and correct line-item mistakes.

  

This last point is critical. To the point that several large organizations have chosen a slightly different architecture, in which all financial information is consolidated into a central ERP system where only the Finance (FI) and Controlling (CO) modules are active. Doesn't it look like a Central Journal already?

(c) Julien Delvat, Alta Via: Consolidation through standard SAP FI/CO

Why not merge into a single instance?

"Since Simple Finance would solve performance issues, why not simply migrate all my systems to a single instance?" I received this question quite a bit by email, so let's tackle it.

Advantages of a single instance with Simple Finance:

  • No need for reconciliation
  • Single set of master data
  • Lower TCO
  • Increased performance
  • New user experience with Fiori
  • Can be implemented on premise or in the cloud

  

On paper, this looks great, but the problem lies in the migration project, especially the merger of all master data, including accounts in the general ledger, customer references, material master, vendors, etc.

An automotive supplier company in Europe is currently consolidating 8 ERP systems into one. After 3 years, they still have 5 systems to go. A global pharmaceutical company currently merging 50 systems into 40 also pointed that even if this would only take 1 year, they would have acquired another 3-5 companies in the meantime.

There are also situations where a system cannot be integrated into a single instance. Maybe that particular business unit is on Classic G/L and doesn't want to upgrade to New G/L. Maybe your small subsidiary's ERP is not on SAP and it would be too costly for them (believe it or not, SAP may not always be the best option).

To sum it up, merging your ERP systems into a single instance may not be feasible or the migration project could be too expensive to justify the return. In such cases, using Simple Finance as a Central Journal may be a better option. For your particular case? Well, it depends!

Deployment Scenarios

Let's assume you are considering using Simple Finance as a Central Journal. What are your options? As you probably guessed: well, it depends ;o)

Option 1: elevate one of your systems to become the Central Journal

(c) Julien Delvat, Alta Via: Consolidation through upgrading to Simple Finance

The requirements for a system to take full advantage of Simple Finance are:

  • ECC 6 with EhP7
  • Unicode data types
  • New G/L
  • SAP HANA database
  • Financial Add-On
  • SAP Fiori User Interface


Should any of these components is missing, you may be able to leverage Rapid Deployment Solutions offered by SAP or consulting partners like Alta Via Consulting (Rapid-deployment Solutions | SAP).

Option 2: you install a side-car Simple Finance system.

(c) Julien Delvat, Alta Via: Consolidation through side-car Simple Finance

If any of these requirements prevents your system from being upgraded, then you may consider a new instance, on premise or in the cloud.

Which one do you recommend?

We usually recommend this second option over the first one for several reasons:

  • It's faster (no migration),
  • The master data of the "main" ERP may not be as clean as expected,
  • It's an opportunity to clean master data and apply master data governance,
  • The Central Journal can be wiped out and reinitialized if master data rules need to change

In the future, the first option may become prevalent as the upgraded system will not only benefit from Simple Finance, but also from the expected future Simple Applications like Simple Logistics (due 2015), Simple CRM, Simple SRM, etc.

[Edit May 1st, 2015]

mark.chalfen: What if you need to update the source systems from the central journal S/4HANA system?

Work is still required here by SAP, or there might be scenarios the customer needs to build.


I believe there would be 3 main types of updates that need to happen: integration, master data, or transactional data.

If the problem is related to the integration, like a new material or customer reference is created but not picked up correctly by SLT, then it should be fairly easy to identify (Totals from all systems and Central Journal wouldn't match). Next, the mapping integration would need to be updated and transactions would have to be reimported. The good news is that since the Central Journal system would consist of a replica of the other ERP systems, you could erase as much data as you want before re-running the import.


In the other cases, master data and transactional data, an error is identified in the Central Journal system, but the root cause is in the source system. For instance, a wrong date on an shipping document, incorrect amount on an invoice, typo in customer number, etc.


I don't think it would be a technical challenge, as opposed to a process one. The clerk / analyst who did the error in the first place should know about it and correct it himself. You are right that there is currently no automated way to correct it in the source system. Something to recommend to our friends in the SAP development group :wink:


patrick.brandicourt: You  refer to the migration project challenge in  the single instance scenario, have you not the same underlying data challenge for any of the explained scenario ?


Yes, we would have similar, but not identical master data governance challenges. If a customer is identified as ABC in system 1, DEF in system 2, and GHI in system 3, the mapping could be tedious. This is especially true with material master data that have auto-generated numbers as opposed to a naming logic. Here, you would highly benefit from having setup an SAP Master Data Management (MDM) system.


Anyways, the difference here between the consolidation of multiple systems and a Central Journal approach is that the operational systems wouldn't be touched. You don't need to convert all your invoicing and accounting documents for the last 3 or 4 years with the risk that not everything has been taken into account. Since the Central Journal is a separate copy of all the source systems, the mapping could be done "on-the-fly". As explained in the previous question, if after the integration you were to identify a material or vendor that was forgotten or incorrectly mapped, you could always drop transactions from the database and rerun the integration.


I believe this is a much better solution. What do you think?


[/Edit]

Conclusion

As stated by carsten.hilker, SAP Solution Owner of Simple Finance: "With a Central Journal, customers can get a consolidated financial and management reporting, a central process execution like intercompany or cash management, and integrated transaction processing and planning, consolidation, and reporting."

In the past, companies used SAP BW or a standard ERP system, with limitations due to aggregation, performance or TCO. This familiar deployment option called Central Journal can be reproduced with greater benefits with SAP Simple Finance. It is better, faster, with more features and more affordable than merging several ERP systems into one.

Central Journal with Simple Finance can be deployment either by upgrading an existing ERP system or by installing a side-car system, on premise or in the cloud.

I hope this article helped you. Do not hesitate to ask questions in the comments sections below or by email. Especially, don't forget to share some details because, you know, it depends!

20 Comments
Labels in this area