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: 
LeonardoAraujo
Active Contributor

Over the past little while many customers have been approaching me with a simple question:

"Should I run ERP on HANA?"

While building the business case for transitioning to ERP on HANA is not a trivial thing for existing customers, for new customers it is a natural choice. This mainly based on 2 very important reasons:


  1. Business Suite Roadmap;
  2. Custom Development;

Business Suite Roadmap

SAP ERP (not on HANA) will continue to be supported and will even also continue to evolve. But it is clear that more and more of new SAP functionality will be built to leverage the new platform. This is a cross-roads moment in the lifecycle of SAP ERP that leads to the introduction of a new product. S/4HANA is born. This new product is ERP with more and more new functionality. Major changes in the data model and its applications will make ERP as we know very different in the years to come. Here are some examples of these innovations:

Simple Finance Add-on 1.0

SAP introduced a new data model for financials delivered as an Add-on, removing unnecessary duplication and aggregation of data in different tables. Before, Financial applications would perform up to 15 insert/updates in Financial tables. With Simple Financials V 1.0, these updates were reduced from 15 to 4 (from 10 tables involved to now only 2). This means above all a much simpler solution to support. Can you imagine how much cheaper it is to develop a report or an additional transaction in this new data model?

Simple Finance Add-on 2.0

The new version of the Simple Financials Add-on brings further optimization to the data model. This time around, a new table is introduced to replace all ledgers. This is what SAP calls the "New principle of ONE". The Universal Journal Entries table ACDOCA replaces the following data models:

  • General Ledger
  • Profitability
  • Management Accounting
  • Asset Accounting
  • Material Ledger

Fiori Apps

Fiori Apps are delivered by SAP to address specific scenarios in ERP. The first "batch" of these applications was composed of 25 apps, all connected to the ERP backend and all for functionality available in the Classical ERP (non HANA). But now there are almost 500 apps available and most are leveraging the new Database option of HANA. Apps that incorporate analytics are only possible with HANA. An example is the Material Shortage app that performs some MRP simulations. Other is customer factsheet.

It is clear by looking at the pace of innovation and the mix of new apps, that a lot more apps are going to be developed for ERP on HANA than the traditional ERP.

Simple Logistics ( COMING UP )

SAP is expected to release at the end of the year, the simple Logistics Add-on. This will an equivalent datamodel simplification performed for Simple Financials, but now in the context of the Logistics data model. According to some SAP notes, this simplification may be actually even greater than the one achieved by Simple Financials. It seems one of the core modifications will be in the Material views.

Merge of SCM, CRM and ERP ( COMING UP )

We still don't talk much about this as it is quite early, but one of the most profound transformations coming to the business suite is actually the merge into an unified product sharing the same data model. I am not talking about running SCM or CRM functionality within ERP as a co-deployment option. The business suite has been built as a portfolio of separate and interfaced systems mainly due to performance constraints and nature of applications. A transactional system (ERP) and a planning system (SCM) would not belong together. The HANA Platform dramatically changes this. SAP has already pointed out the eventual merge of CRM ERP and SCM. It won't be tomorrow as this is a huge undertake, but the TCO of running the business suite will reduce dramatically. This will lead to an increase in adoption as more sophisticated functionality like Global ATP and CRM will be available simpler, at a lower cost, to existing ERP customers.

Custom Development

This is for me the most important reason to jump directly to ERP on HANA. ABAP solutions are designed and coded differently when running on HANA. Starting on a classic non-hana DB means that a large number of applications will be built using an old development approach. With time, the total number of existing solutions will only grow. The longer customers take to transition to ERP on HANA, greater will be the number of solutions to be adjusted (to correctly run on HANA) or even redesigned to leverage the new programming paradigm. This is a future waste of IT dollars.

As we all know, the greater the number of custom solutions in place, the more difficult it is to justify the transition. Why digging yourself in a hole?

Conclusion

Not minimizing the additional software and hardware costs, I strongly believe that, based on the 2 main reasons documented above, adopting today "Classic" (non HANA) ERP is a strategical error. The immediate cost savings from this decision is very easily offset by the cost of adopting it later. There will be an upgrade/DBMigration/Adjustment in addition to the adjustment of custom code. All this not including the wasted effort to build solutions to problems that only belong to the non-HANA world (performance improvement of reporting, heavy Application logic not passed to the DB, etc).

P.S. This BLOG has also been posted on LinkedIn HERE.

6 Comments
Labels in this area