S/4HANA

SAP Central Finance: a non-disruptive step towards system consolidation

Operating across a distributed environment has become a way of life for a large percentage of businesses today, even smaller ones. In fact 80% of all survey participants in the 2015 Mint Jutras Enterprise Solution Study had more than one operating location served by ERP (Figure 1). Even small companies (those with annual revenues lower than $25 million) average 2.87 operating locations, and that number grows steadily as revenues grow.

Figure 1: Environments Are More Distributed and Remote

Fig 1 SAPSource: Mint Jutras 2015 Enterprise Solution Study

This proliferation of operating locations often results in a proliferation of enterprise applications in general and ERP solutions in particular. In days gone by, these different operating sites were often left on their own to select the enterprise applications that would help them run their individual businesses. Yes there was a corporate accounting system, and financials needed to be rolled up. But those corporate financials were overkill at the divisional level, and often didn’t have all the functionality needed to manage operations, particularly in manufacturing sites.

As long as these different operating sites operated quite independently, this proliferation wasn’t too much of a problem. But today the likelihood of divisions operating completely autonomously has dramatically shrunk. Whether you are a services organization working on projects that span the globe or a manufacturer striving to manufacture closer to your customer, leaving each operating location to do their own thing just doesn’t cut it anymore. Standardized processes and corporate standards for the enterprise applications that support those processes have become the norm.

The majority (87%) of multi-location companies today have created standards that govern which enterprise applications are used across the enterprise (Figure 2). However, a fair number (14%) are still in the process of migrating to these standards, which means they are faced with the challenge of rationalizing existing solutions that are functioning today. Typically this means a long process of ripping and replacing solutions and many years before they see the benefits.

Figure 2: Have you established corporate standards for enterprise applications?

Fig 2 SAPSource: Mint Jutras 2015 Enterprise Solution Study

For SAP customers, SAP Central Finance might just be a shortcut to some of those benefits. It provides more than just the typical kind of consolidated reporting that is done at the aggregate level. Central Finance taps into the power of SAP HANA and replicates all journal entries in a Universal Ledger, while preserving the source of those entries, whether the source is an SAP ERP solution or not. Of course it takes a bit more effort to map the data from nonSAP solutions, but SAP has tools to help and it is quite do-able.

What this accomplishes immediately: Centralized reporting across the organization, beyond the typical financial reporting, and also the potential for more informed centralized strategic decision-making.

  • Reporting based on harmonized master data
  • Central journal for balance sheet and P&L reports
  • Central profitability analysis
  • Overarching views on customer and vendor accounts
  • Liquidity forecasts based on payables and receivables
  • Central overhead analysis
  • Reports for selected cost object categories

… All this without ripping or replacing anything. Of course, some might stop here, centralizing finance and leaving disparate ERP solutions in place, while others might move on to rationalize solutions. … or some combination of the two. Mint Jutras finds there are several different flavors of corporate standards (Figure 3).

Figure 3: Is this a single or multi-tier standard?

Fig 3 SAPSource: Mint Jutras 2015 Enterprise Solution Study

Although those all running a single ERP solution won’t need to rationalize solutions, they are still likely to need to consolidate financials, especially those that are multi-national. Central Finance could also be used to absorb a new acquisition, incorporating the new entity into corporate financials. Today Central Finance can be used for corporate reporting and planning, but as SAP continues executing on its planned roadmap, in the future, customers will be able to use it for central operational processing

To sum up both approaches….

Central Finance as a corporate reporting and planning platform:

  • Establishes central financial system as a single source of truth
  • Across entities and units
  • With harmonized master data
  • Using the flexible data model of Simple Finance (now called SAP S/4HANA Finance), with the possibility of adding new dimensions for reporting that might not even be available in source systems
  • With new reporting tools
  • And the speed of HAHA
  • Cross-entity insight with limitless detail. You can even click on a document ID in Central Finance to navigate back to the source system (think traceability). This is done automatically when the source system is an SAP product. Doing the same for nonSAP systems requires additional effort.

Central Finance for operational processing

  • Simplify and standardize processes
  • By centralizing financial processes
  • By standardizing, harmonizing processes across units
  • Move processes to central execution models while streamlining processes based on harmonized data
  • Possibly simplify work in shared service centers
  • Simplify your IT landscape

Whether you need to consolidate financials only, or entire ERP systems, if you are an SAP customer, you owe it to yourself to investigate how Central Finance could make your life easier.

Tagged , , , , , , , , ,

SAP S/4HANA: Simple, Fast, Different

What Does it Mean to the Business?

On February 3, 2015, SAP announced what it called its biggest product launch in the history of the company: SAP Business Suite 4 SAP HANA, or (thankfully) SAP S/4HANA for short, was touted as “the next-generation business suite to help customers run simple.” Indeed, “S” stands for simple; “4” is for 4th generation and in Information Technology (IT) circles, HANA speaks for itself. To interpret for those outside the world of IT, HANA is an advanced in-memory platform that is able to crunch through enormous volumes of data incredibly fast.

In combination these three factors hold enormous potential to change the way businesses are run. While the potential impact might seem intuitive to technologists, it is far less obvious to the typical business executive. And yet, in a world where the terms innovative, disruptive and transformative are all too often over-used and mis-used, SAP S/4HANA is disruptive innovation that can be used to simplify and transform your business. If you are interested in learning how, read on…

What is it?

SAP S/4HANA is a new product, which, like its predecessor (the SAP Business Suite) will include enterprise resource planning (ERP) and other complementary functions including:

  • Customer relationship management (CRM)
  • Supplier relationship management (SRM)
  • Supply chain management (SCM)
  • Product lifecycle management (PLM)
  • cloud functions such as SAP SuccessFactors (HCM) and its Ariba Network

Like the SAP Business Suite, it is designed for the large enterprise, and eventually will satisfy the requirements of the same 26 industries SAP has spent decades building out. This is a big and bold move for SAP. Given these similarities, some immediate questions come to mind. First of all, why develop a new product? After all, the SAP Business Suite could already run on SAP HANA. Secondly, is it really possible to replace over 400 million lines of code quickly enough or will a complete solution be decades in the making? To answer these questions we need to look at both the differences and the similarities.

At first glance, the differences that appear most obvious to the typical business user lay in the user experience and deployment models offered. Beyond the obvious is the new code line with a new and simplified data model, but more on that (and what it means to the user) later.

Choice of Deployment Models

The existing product was essentially an on-premise solution, although SAP has recently offered a cloud-based managed services option. The SAP HANA Enterprise Cloud (HEC) is a service that allows organizations to move existing (or new) implementations of the SAP Business Suite off their own servers and into SAP’s massive data centers where SAP would manage it as a single tenant solution in a private cloud. But this doesn’t carry the same benefits of lower cost and faster innovation possible with a multi-tenant software as a service (SaaS) solution.

With SAP S/4HANA comes a choice of deployment options. The On Premise Edition is available today while the Public Cloud Edition (multi-tenant SaaS) will be available soon (the first quarter of 2015), followed by the Managed Cloud Edition in Q2.

New and Improved User Experience

The user interface of the SAP Business Suite has long been a weak point, and also one of the hardest to “fix.” SAP is not alone in this dilemma. Many enterprise application solution providers struggle with this as expectations change over time, especially with the influence of consumer mobile devices. Users become dissatisfied with existing user interfaces but often getting them to change is like pulling teeth, for fear of the need to retrain users and because people (those actually using the software) get used to it and resist change.

SAP has actually been working on fixing this problem for more than two years. In the spring of 2013 it introduced SAP Fiori, a collection of 25 apps (initially) that surrounded the Business Suite, providing a new user experience for the most commonly used business functions of ERP. While useful in pleasing existing users and perhaps even attracting new users within the enterprise, SAP Fiori had limited impact for two related reasons. First, the initial set of apps just changed the user interface (UI) and did not add any significant new functionality. And yet, they weren’t free. Customers balked at paying a fee for innovation they expected SAP to deliver as part of maintenance.

The second round of Fiori apps however began to add in new capabilities, but in spite of that, SAP responded to customer complaints and made them free (with maintenance). And today there are over 500 of them available.

The intended new user experience delivered with SAP S/4HANA is based entirely on SAP Fiori and SAP expects that over time more and more transactions will come from mobile devices, a very viable option with Fiori. New customers will engage with SAP S/4HANA through these apps right from the beginning. Those SAP Business Suite customers that migrate to SAP S/4HANA will have the option of continuing to use the traditional user interface, but of course Fiori apps won’t shore up this weakness unless they are really used. Hopefully, with the mindset of running a new product, customers will expect to engage differently and therefore take better advantage of the new experience and the new functions delivered through Fiori.

Beyond the Obvious

While either or both of these differences might be compelling, even together they don’t justify the time and effort involved in replacing 400 million lines of code to produce a new product. The real game changer here is the underlying technology that allowed SAP to reduce the data footprint by a factor of 10, increase throughput by a factor of 7 and make analytics and reporting orders of magnitude faster (SAP claims 1800 times faster). SAP’s goal was to achieve a zero response time.

However, many business executives running SAP solutions, as well as those of other vendors, might not perceive themselves as having a problem with response time and the size of their data footprint is hardly something that keeps them up at night. If you consider yourself in this category, what’s in it for you? The short answer is

  • Speed in getting at data and answering questions
  • The power of iterative questions, including immediate answers to new ones you didn’t even know you had until you started looking
  • The ability to base all decisions (strategic and operational) on as much detail, in as fine a level of granularity as you can imagine

Perhaps you don’t think you have a problem because you have adapted to the limitations of existing systems. Or you don’t know response time is slow because you never put your hands directly on the system. You might be accustomed to making decisions from data that is frozen in time (a snapshot) because it is not updated and available in real time. You may have waited so long for new queries and reporting that perhaps you stopped asking for them. You probably forecast sales at a summary level by region, assuming you can’t possibly analyze and predict sales at an individual customer level, by product and region, by sales rep. What if SAP S/4HANA could change all this?

Speed is obviously a key factor, but why should you care about reducing the data footprint? The answer lies in understanding why that footprint got so bloated in the first place. As your solution footprint has grown through the years, there is a very good chance you have introduced redundant data. If you started with ERP, then added CRM, both need customer data and product data. This redundant data needs to be synchronized. SAP estimates that 40% of the data load is the exchange of data between solutions.

In addition all enterprise solutions have traditionally accumulated all sorts of totals. Some are for periodic reporting (monthly, quarterly, annually, etc.), while other aggregates are used to gain insight into different parts of the organizational structure. This aggregation enables reporting without having to sort and calculate totals across a potentially large volume of transactions. While the process is simple and effective (because you can gain access to these totals through a simple query), there were some drawbacks.

Not only is there more embedded code to maintain these totals, there is more contention within the data files. Let’s say a large enterprise has people all over the world entering sales orders. If totals are updated in real time, even though it might appear that all transactions are accessing and updating records in the files simultaneously, in reality, these updates happen one at a time. Before a transaction can update a record, it has to check to make sure no other transaction is trying to do the same. If the record is being accessed or updated by another transaction, it must wait for the record to be freed up. Of course it might take only seconds, but those seconds add up and response time slows.

This is also why sometimes these totals are not updated in real-time, and instead are calculated with batch runs. That means you are looking at a snapshot in time and not the “real” number.

And finally, keeping these totals up to date, whether in real-time or through batch runs, means you have to anticipate how and what you want to include in the totals. What happens when you want to change the organizational structure and report in a new way? Those pre-calculated totals are now meaningless. If you can instantly slice and dice and calculate on the fly using any criteria, you don’t have to do any of this aggregation and you get complete flexibility.

Removing these totals means no updates and no more contention. Dozens or even hundreds or thousands of transactions can be entered and stored, at the same time (literally, not just seemingly). This is what the technologists mean when they refer to “massively parallel processing (MPP).”

So SAP got rid of these totals and also the database indices. Database indices allow you to do key lookups. You can easily look up a customer or a product by customer number or part number because those numbers are keys, allowing the software to go (more) directly to a record without having to search through the entire file. But these indices are no longer required if you can search through even massive files and still get sub-second response.

In the end, SAP S/4HANA reduced the number of data tables from 110 to less than 10. And it also segregated out historical data from current data. By its very definition, historical data can’t be changed any more. That makes it easier to handle. So SAP segregated it and made it read-only, making it even easier to deal with the current data.

This flexibility and speed is the real value HANA brings to the business, along with improved, faster decision-making. However, to take full advantage of HANA, SAP S/4HANA must only run on HANA. Of course, this means customers will not have a choice of databases. Some industry observers are criticizing SAP for removing this as a choice. However, preserving that choice of database means SAP S/4HANA would be restricted to the least common denominator of functionality.

If SAP does not take full advantage of the benefits HANA brings, why create a new product? The SAP Business Suite already provides this freedom of choice, including the Business Suite on HANA. And SAP has promised to continue to develop and support the SAP Business Suite through 2025.

Some customers will be reluctant to spend the money on a new platform. Some will cite the skill levels of their current staffs. If customers want to remain on traditional databases, they should just stay on the SAP Business Suite, at least for now. If IT staffs have not upgraded their skill levels by 2025, they will have more problems to contend with than just limitations in response times. So maybe it is time for some “disruption.”

Disruptive Innovation

While technology industry observers love to talk about “disruptive technology,” many business executives think of disruption as a bad thing. Yet while certain types of disruption can indeed be bad, other types can also be good. Disruption that prevents you from delivering a product or service is obviously bad. Disruption that forces you to do things in a different, but better way can be very good.

Wikipedia defines disruptive innovation as “an innovation that helps create a new market and value network, and eventually disrupts an existing market and value network (over a few years or decades), displacing an earlier technology. The term is used in business and technology literature to describe innovations that improve a product or service in ways that the market does not expect…”

SAP S/4HANA is indeed disruptive innovation, but in the good sense. It is a bold move for SAP. Obviously its customers cannot transform themselves overnight, but they don’t need to. SAP S/4HANA was designed to allow existing SAP Business Suite customers to migrate without the bad kind of disruption. And of course SAP can’t transform millions of lines of code overnight either.

While the SAP Business Suite was just that – a suite of products, eventually all this functionality will be embedded and delivered as a single product. SAP started with ERP, but will eventually add in functionality from CRM, SRM, SCM and PLM. It will start with those industries most likely to see the cloud as the next stop in their extended ERP journey, and then continue to broaden its industry reach. Of course for any company taking this big next step, as always, the devil is in the details. How will companies (both new customers and existing SAP customers) make the transition while SAP itself is still in transition? Will they be able to embrace the good kind of disruption while keeping the bad kind at bay?

Conclusion

The short answer is yes, but that too will be a journey. It will not happen overnight. The key to success is in allowing all the current and new solutions to coexist. While SAP S/4HANA only has 10 or so tables, those applications like CRM, SRM and SCM are expecting to find their share of the full-blown 110 tables. That’s okay.

SAP has also defined a virtual data model that can do a translation of sorts, mapping the old tables to the new data model. This is a key factor in facilitating the migration from SAP Business Suite to SAP S/4HANA without disruption. It not only allows these (currently additional) applications to interoperate with SAP S/4HANA, but also allows customers to continue running current reports that might rely on those old totals. So current and new customers both can ease into taking full advantage of the new capabilities. This is good since it will take companies awhile to realize they can now solve problems that are currently viewed as unsolvable.

Tagged , , , , , , , , , , ,