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!