Hana Road-Mapping: The Data Pitfall
Hana Road-Mapping: The Data Pitfall
Blog Hana

Hana Road-Mapping: The Data Pitfall

Unstructured data, the Internet of Things, machine learning and decision-making - for many customers, 5, 10 or even 15 years will pass before the full functional spectrum of SAP Hana is in everyday use.

Nevertheless, if you are not thinking about your longer-term requirements now, you might find that you lack the data you need, when you most need it.

Software, hardware and the right kind of employees, are not the only essential success factors if you want to enter the beautiful new world of digitisation and big data. Another very important one are the Data themselves.By collecting non-aggregated data within the Universal Journal, Central Finance and the One Exposure from Operations hub, SAP are currently preparing the way for the analysis of large data volumes. For many customers, however, the content going into these containers will be of no use whatsoever for statistical analyses.

Why is this? Well firstly, existing business processes are not aligned with this vision, and secondly, the power of practically all statistical algorithms depends on sample size and quality. You need the correct data and lots of it, of as high a quality as possible. Or to put it another way – if you aren’t including digitisation in your longer-term vision right now, you may be left empty handed in 10 years time as far as the required data are concerned. For most customers, this transition will happen in a couple of phases shown in the diagram below.


1: Migration

For SAP customers, entry into digital business management begins with the migration from a classical database such as Oracle or MaxDB to SAP HANA. Such a plain vanilla migration makes reports and selected functions (such as transformations or activations in BW) significantly faster. Additionally, new interfaces (for example, to event processing solutions and Hadoop) are becoming available. In the absence of new business processes, however, these interfaces will initially lie idle. A return on investment from a database migration is only achieved if you derive some benefits from just having software functions running more quickly.

If, for instance, data load processes in BW run 50% or 75% faster due to speedier activation and the elimination of individual processing steps (deletion and re-creation of indexes, database statistics and rollup, as examples) this can have two benefits. Bottlenecks in batch processing evaporate into thin air and decision-relevant data are available to the business early in the morning rather than later in the afternoon. The former might help avoid investments in new hardware, and the latter might lead to better decision-making.

2: New Functions

Once the database migration is complete, the new “Simple” solutions from SAP can be easily activated using the Switch Framework (SFW5). This results in even more business processes running faster, due to leaner table structures and code push-down. Furthermore, entirely new functions become available (such as the new Bank Account Management in Cash Management).

Following migration, the time is also ripe for making customer-specific solutions fit for Hana. Logically, in the first instance, the focus will be on speed-critical business processes.

3: New Methods

As a platform and hub for data provisioning, Hana opens the door to using event processing (keywords: ESP plug-in for SAP Hana Studio) and weakly structured/unstructured data (for example HDFS/MapReduce or NoSQL). Classic ERP business processes have no use for data of this type, which is why additional value potentials can only be achieved by restructuring existing processes or implementing new ones.

It would now, for example, become feasible to use data from social networks for fraud prevention and to help highlight questionable payment proposals for further analysis.

To achieve this, however, new applications need to be set up (SAP Fraud Management, Business Rules Framework), and existing ones might have to be extended (in our example, the F110 payment program). This is a bigger challenge than just “tuning” reports or loading processes.

4: New Algorithms

The performance improvements achievable using SAP Hana make it possible to both use familiar algorithms in different ways, and to deploy new performance-intensive algorithms for the first time.

Example: A segmentation of customers based upon price sensitivity can now be performed not just once a month, but almost on a continuous basis. Instead of pricing basic and premium brands differently based upon different target groups, these products/brands can now also be offered at different prices dependent upon the time of day. The increasingly common introduction of digital, real-time price marking in high street retail stores – following in the footsteps of web shops – establishes the technical prerequisite for such a time-orientated customer segmentation.

5: New Strategies

Sensory data, as collected via SAP ESP (see section 3), provide large volumes of partially erroneous or deficient data. This alone represents a major challenge to classic IT organisations, who will also have to deal with the problem that, from a data governance perspective, the Internet of Things has the unpleasant habit of continuously changing it’s structure.

A mid-range car can currently deliver data from around 100-150 sensors. With every change in model, new ones are added and older ones are dropped or see their technical characteristics altered. Things are no different with the measurement modules contained in a smartphone or a pump housing. Data flows and functions based on the assumption of stable input data are often already obsolete even before their go-live date.

To be able to cope within an unstable framework, new architectural models are required within IT. At this stage, at the very latest, a fundamental redesign of data architecture and data flow is essential.

6: New Paradigms

With the steps outlined in sections 4 and 5, closed feedback loops – long since the norm in process control systems – now suddenly find their way into business processes. However, whereas a shop floor full of machines offers a relatively stable framework for the definition of rules, decisions in business processes are made in an environment fundamentally shifting by the hour or even by the minute. The attempt to model the rules of this game using rigid rules (and customizing settings) is doomed to failure.

Sooner or later, organisations will be forced to delegate decisions to self-adapting (auto-adaptive) algorithms. This may sound unusual or even terrifying, but maybe unwittingly, we have long since left everyday decisions to algorithms that we don’t fully understand. Hardly anybody checks every instruction from their navigation system against a map, extremely few material planners would know how demand planning in SAP ERP works, and very few air passengers have any concerns about boarding a plane that will be landed by computer, rather than the crew.

Data as a Critical Success Factor

It is not realistic to expect business processes to rely on pattern recognition and automatic decision-making, using present-day data. Pattern-matching algorithms for fraud prevention, for example, require clean and granular data that have been gathered from many hundreds or even thousands of clearly documented cases.

If you are to have such a wealth of data at your disposal in one, two or even three decades, architectural design and data collection must start today. Internet giants such as Amazon or Google have long since understood this. The pioneers of big data are primarily concerned with collecting the largest volume of data possible and managing it in a flexible manner.

What these data might eventually be good for is a question that can be addressed in ten years time. The reasons for Google’s entry into the car industry, robotics and the field of home technology have to be judged with this in mind. In all three cases, it’s not primarily to sell hardware, but rather for the ownership of data produced by that hardware.


Someone building a house doesn’t start planning the project when laying the roof tiles. The architecture and design of the structure are defined long before the first excavator arrives at the site. Perhaps the vision itself arises even before purchase of the actual plot. Of course, there will be adjustments made during the building process. The building site itself may hold in store the odd surprise, or a window may need to be shifted just a few centimetres to gain a better view.

Just like a building plan, a data architecture must not be carved in stone by default. Now is the time to start laying the foundations for what you might want to be doing in 10 years time. Start early, plan ahead, and leave time for things to mature. Take the time now to prepare better and earlier than your current and newly emerging competitors.

Horváth & Partners and E-3 Magazine (German) November 2015

About the author

Michael Mattern, Horváth & Partners

Michael Mattern is Principal Enterprise Architect and coach (ERP, BW and S/4). He works as a senior expert for Horváth & Partners, an international management consultancy specialising in business management and performance optimisation.

Add Comment

Click here to post a comment

Social Media

Sign up for e3zine´s biweekly newsbites

Please do not use administrative mail adresses like "noreply@..", "admin@.." or similar as these may get blocked for security reasons.

We use rapidmail for dispatching our newsletter. By signing up, you agree that the data you have entered will be transmitted to rapidmail. Please take note of their terms and conditions and privacy policy. terms and conditions .

Our Authors