How HANA Helps Your Company Strategy

First some common sense observations. Company strategy determines what the organisation wants to do.  Requirements are driven by strategy, and the satisfaction of those requirements helps the strategy. Requirements should serve pieces of the strategy year by year. Put it another way, if we are working on requirements that do not help the company strategy there is something wrong. Satisfying requirements provides benefits, we mainly think of these as monetary benefits, extra revenue earned or cost saved, but they can also be other strategic benefits like increase in market share, improved customer loyalty, improved staff retention etc.

Most of the time we expect strategy and requirements to be explicit, written down and planned. But they can also be less formal than that and be implicit in the company ethos and culture ‘the way we do things round here’. We define strategy because we expect it to benefit the company. The strategy requires us to do things and in meeting the requirements, we get the benefits that each requirement delivers.

Every requirement has two key metrics, whether these are explicitly defined or not; 1) The amount of effort we expect to expend on it, and 2) The amount of benefit we expect to achieve. The easier it is to meet those requirements, the more requirements we can meet, and the more benefits we reap which leads to a much better support of our company strategy. If this all sounds obvious and just common sense then that’s because it is. We usually prioritize the requirements according to how much benefit they will deliver compared to their cost.

Where the SAP HANA Platform helps is in its simplicity, speed and in the breadth of different features that embedded in the platform, are available at your fingertips, and which can be mixed and matched very easily.

HANA is a general purpose device, it implements a wide range of modern processing types. It supports both analytical and operational processing, including full transactional support, and mixes of these types of work so it can meet a very wide range of requirements.

It also provides performance that can be hundreds or thousands of times faster than traditional systems so developers get fast feedback and can work at a faster pace staying ‘in the flow’.

One of the main ways it uses this huge performance advantage is to remove the need for pre-aggregated and indexed data objects, and their maintenance, which can be 60-95% or more of system complexity. This provides simplicity to the design, development and maintenance, and in turn makes the platform radically more productive and much more agile, it is a simpler, quicker and fundamentally better way of doing things. A good rule of thumb based on customer feedback is that productivity increases by having to significantly expend less effort, and allowing us to meet more requirements. In the diagram above we see, in the first column under ‘platform’,  the capabilities of HANA, the wide array of processing types, the ability to do analytical and operational work (and a mix of them) plus superior agility and productivity due to fast turnarounds and the simplicity of design.

We then see, in the middle column under ‘requirements’ a list of requirements, each with an estimate of effort and of expected benefits, and also an indication of how analytical (green) and how operational (red) it is. Increasingly requirements can be mixes of analytical and operational – e.g. mobile apps, sensor based apps, real time offer management etc.

HANA lets you do more requirements because:

It is more agile and productive, because of its simplicity. You can do more requirements in a given period of times, and …

It handles all types of requirements, operational and analytical so we don’t need to waste time and effort integrating multiple platforms and working out what gets done where

In this simple diagram we see 16 requirements with total benefit of €26m and 150 person/weeks of effort needed to do them all. Lets suppose we have 50 person/weeks available, HANA is 3x more productive, that is, it can do what would have taken 150 weeks using the 50 we have available. So can do all the requirements whether they are analytic, operational or a mix.

The other platforms can’t do the operational requirements, so we would have to do them somewhere else.  And because it takes 3x longer to develop them we cannot even do all of the analytic requirements with our 50 weeks available.

This has an impact on overall strategy. Requirements don’t come out of nowhere, they are usually driven by strategy. If there are requirements we cannot do then, as shown on the right, our strategy has ‘holes’ in it.

If we need five requirements to be met to implement a strategy and can only do three we don’t get to execute the strategy.  At best it takes us longer to execute because we need to integrate other platforms, in order to fill in the gaps, this adds time, complexity and expense. Requirements are increasingly a mix of operational and analytical. Strategies also require the company to ‘flex’ in their business processes, the faster and easier we can do this, together with the information systems that support them, the more responsive we can be to the market.

Therefore HANA has a direct effect on maximizing benefits and successfully executing strategy.

This should not be a surprise. HANA was specifically designed to support modern business with a radically simpler approach to enterprise systems, and with a comprehensive platform containing everything that’s needed at your fingertips for faster and simpler implementation. We’d expect this to pop out in the numbers somewhere, and we’d expect it to be easier, and for us to be more sure footed in implementing strategy.

Thus, there is a simple chain of commonsense logic connecting the platform capabilities of HANA with realization of business strategy.