Skip to Content

Finding the right SAP HANA scenario for your business

I’ve just come out of a session with SAP and a customer where we talking about HANA use cases, and it got me thinking. I mean, SAP HANA is supposed to be a serious innovating product for SAP, and for customers it will mean serious investment. You need to be spend fairly serious money: including the appliance, licensing and services cost of installation, you will be spending a 7 digit sum – and that’s for the smallest appliance.

This isn’t a criticism of SAP or the hardware vendors – the performance of SAP HANA in the right scenario presents an excellent value case, but it does mean that you need to apply caution when looking at it from a technology investment perspective. One SAP customer put together the bones of a HANA POC, but found that in the end, the value case did not stack up.

And this is to say, just because making stuff go fast might be useful, it doesn’t mean that there’s a ROI.

Building the case for Value

So if you’re looking at SAP HANA, take the time to turn it back around. Try asking yourself the following questions – taking into account all information in your organization and not just that within SAP systems:

1) What are the key metrics that our organization cares about? Is it Sales Revenue? Operating Costs?

2) How do we currently measure those metrics? What are the feeding data elements into those metrics, and how are those measured?

3) By measuring any of these things faster, can we drive change in those metrics? For example, perhaps by measuring stock levels in real time you can reduce time to fill stock in stores and therefore increase sales.

4) Can you measure what this benefit would bring, from a cash perspective?

If you can answer these questions you are well on the way to building a business case. By the way, SAP have a Value Engineering (VE) team that may well help you with this if you ask your account team. They have a neat toolset which makes this stuff quite easy.

Let’s take it a step further.

Moving from Analytics to Action

If you’re reading this you probably already know what SAP HANA is, but where it will be tomorrow will be key to your overall value case. Here are a few things to think about:

1) Fast analytics. HANA 1.0 SP02 is all about fast analytics. You’ve already taken a look at this in the last section, but this can be the catalyst to process change. For example where you can measure stock levels faster, you can manage depletions faster and keep stock higher. It’s not just about measuring – it’s about action.

2) Real-time Loads. Your current Data Warehouse probably has a load system – Extract Transform and Load, or ETL. HANA allows this too, but it also allows two different types of real-time replication – either at the database level or at the application level. Does having information replicated and measurable in real-time provide additional business benefit?

3) Event-driven Data. Let’s take it a step further again. What if your sales terminals drove events into the data warehouse at the Point of Sale? Using SAP Event Insight you can do just this, and turn HANA into a repository for real-time transactions.

4) Any time, any place, any where. And once you have this information, what if you made it available on any device? Taking the retail example – what if you could send out sales people with this information available to do retail execution? They could see the effects of a product not being in stock and take action there and then, thereby increase revenue.

5) Tieing back into the process. Once you’re this far – it makes sense to tie it back into regular business process. So you could make it reorder product, if it is out of stock – or penalise the retailer in our example for not making promotions. SAP HANA then becomes the centre of a real-time decision engine.

By the way, I’m not suggesting that you go about entirely changing and building your business around SAP HANA – it is afterall a 1.0 product and should be treated as such – but what you can do is to consider how SAP HANA 1.0 today can become part of your IT landscape tomorrow.

Moving to a Proof of Concept

Now you know what your proof points are and how to build a roadmap around it, you need to consider the data to see if it is suitable.

First take a look at where the data exists within the organization for your key metrics. Map out those metrics and see where the data resides. SAP HANA is vendor-agnostic – it doesn’t care where the data resides in source. You can replicate real-time from Oracle, DB2, MSSQL and any SAP source system – and for anything else you can use SAP BusinessObjects Data Services, which supports just about any data source.

Be much more mindful if you need to bring information from multiple locations and combine it. Data Services provides you an ideal mechanism by which you can transform it before it gets into SAP HANA.

Most of all make sure that the data model you end up with in SAP HANA will be a simple one. Try to build out a simple star scheme data mart – don’t be clever, combining lots of data within complex query structures in SAP HANA – it won’t perform as well as you hope. Remember that doing complex computations in-memory is still time consuming!

If your model works out well then I highly reccommend you do a Proof of Concept. The hardware will cost you ($100k+, typically) but it can be reused if you don’t use it for SAP HANA later on. Here you can define your proof points – try to make them around performance and process change and not about integration, because integration proof points, particularly around real-time, are hard.


In-Memory technologies are here to stay, and they will mature well as time progresses. However they are expensive and require an excellent business case to progress. Spend this time up front, as well as defining your proof points for a PoC and your decision making criteria in advance.

If you combine this with setting sensible technical proof points and ensuring that SAP HANA is the right technology for your needs, as well as the information being available in the business for reporting, then you have a great chance of success. Good luck!

You must be Logged on to comment or reply to a post.
  • Hello John,

    This was a very clear analysis of HANA from a honest (non-hype) business value perspective.
    Agreed, first you have to get our analytics right and be able to see your process weaknesses. Later on if making things faster will bring ROI, then HANA 1.0 might be able to help you.

    While the transformations on the core platform to use the In-Memory Engine are in the future, this should be a relevant sales approach to SAP's customers.

    Best Regards,
    Marlo Simon.

    • Hi Marlo,

      Thanks, I'm glad you liked it. I believe that most people who have been around the Enterprise IT block know the difference between hype and reality so honesty is the best policy.

      I agree with your analytics point and there is an additional dimension, which is that you don't want a 1.0 product to be at the core of your business process. HANA isn't ready for that yet.

      By the way this isn't so different to what SAP's sales process for HANA is, at least in theory. Their Value Engineering is quite selective of what POCs they take on - to avoid tyre kickers and try to help the customers deliver value fast.


        • Oh wow sorry I thought that was clear. Guess I was soft on that area in this blog.

          HANA still lacks proper management tools, HA, DR and other things required for mission critical apps. I don't want to be too critical to SAP though on this because it's a 1.0 product and that stuff will come and is in the roadmap. They are aware of it all and developing product.

          In the meantime let's see what it can do as an analytics appliance - not trying to run before we can walk.

  • Hi John,

    Thanks for your thoughts. Like wise, one of our customers asked about the possibility of real-time analytics using HANA by loading data from multiple ERP systems into IMDB. It is important to manage expectations after all the hype. You have to ask customers to step back and re-think the problem they are trying to address rather than jumping to the solution. For example, if the customer is aiming for real-time visibility into data from multiple systems, data federation rather than consolidation could be more appropriate, unless data consolidation adds any real value.

    So I totally agree with your points. The most important challenge today is identifying the right use cases for HANA. There are things it can do today. And then there are things it is supposed to do in future. The key is to keep the distinction between the two and give customers a clear roadmap.

    As it stands today, SAP HANA offers the ability to create an operational data mart on top of ERP. You can also load data into it through ETL or replication. But you can't replicate 10 different sources into HANA in real-time. If customers wanted to use HANA for cross-system analytics, they will end up with ETL type process which they would typically carry out with reference to a BW system. So the use cases for HANA are really very specific where the current system, and probably one more, hold the right data to use HANA for real-time analytics.

    There could be value in moving data from multiple data sources into HANA if you could follow principles like extract once-use many times. If it is likely that you'd use the same data inside BW or other systems for reporting and analysis, good architectural practices would dictate the use of a staging area. This evantually means you'll end up developing a DW like architecture on top of HANA, something you are not supposed to do as yet, but seems inevitable.

    You highlighted Fast Analytics as a use case. Measuring the impact of change in stock levels would certainly be useful in areas like demand planning. Again, this does require having the right information inside the SCM system, and probably one more, to be able to work in real-time.

    Other use cases could include Consensus Forecasting which requires consolidating the inputs of marketing intelligence, promotions, and management adjustments to the statistical forecast. Similarly, CO-PA and TPM are good use cases which SAP intends to offer through HANA. These are fairly intensive processes and require some heavy lifting in BW servers. HANA could add value here. But it can't happen in real-time as you can only have one source replicated in real-time. Moreover, if the data is coming from a third party data provider, you can't ask them to support your real-time analytics requirements unless you are willing to invest some reasonable money. Consequently, real-time reporting can only be as real-time as the slowest data source in your landscape. Only after you have acquired data, HANA can speed things up.