Skip to Content

The first in this series of blogs talked about why increasing BI productivity (i.e. cutting the time and cost of developing projects) – is so important, and gave some examples of customers who had already achieved this. The second part of the series looked at how to cut the requirements gathering, scoping and design phases of the BI project.

We saw in the second part that a typical BI development project plan might look like the following:

  • Requirements gathering / scoping = 20-30%
  • Design & development = 40-50%
  • Testing = 20-40%

… and then there’s a cost of about 30% change management every year. So how do customers cut development time, testing, documentation, implementation and rework?


  • The shift to Self Service: Traditionally, most analytics/BI teams report a balance of 80% reporting / 20% analytics; we often see a shift to 20% reporting / 80% analytics with HANA clients.

    BIcombined.png 
    Assuming that the glossary and semantic layers have already been developed, the additional development effort for self-service analytics is minimal, and the turn-around almost instantaneous.

  • The significantly simpler data model that is usually implemented with HANA also leads to simpler and faster development. – no physical instantiations of aggregates, rollups, summaries.
  • Multiple engines in a single platform: The ability for a single platform to handle different analysis types, including text, spatial, graph etc. results in eliminated steps in managing the movement of data to specialised engines, and gathering and harmonising multiple result sets from different systems for a single complex query. Data quality also becomes more assured, as all systems are working from the same atomic dataset, without differences due to time-lags in loading / refreshing.
  • Elimination of multiple staging areas: The ability to handle both OLTP and OLAP within the same platform allows data to be read and written at the same time without any impact on performance to end user. This means there is no need to create duplicate staging areas to support different time-zones or different scheduling priorities.
  • Development with full data sets: Typically, design and development are carried out with small subsets of data to ensure good performance and quick iterations. The outcomes of this development are presented to users, who conduct a first User Acceptance Testing (UAT) cycle. Changes based on this feedback are incorporated, after which the development environment is back-loaded with large data-sets. Further development is carried out, including additional development for performance-tuning, after which additional UAT is carried out. Given the performance of HANA, development can be done directly on full data-sets, and only one iteration of the testing cycle is needed.
  • Reduce testing time: The removal of performance optimisation components of the model results in less layers, less objects to test and less time to load, resulting in quicker testing cycles. Changes to the model are easier to implement due to their simplified structures and reduced / eliminated ETL processing. All this results in faster testing cycles, faster iterations, quicker changes as well as the ability to perform multiple test scenarios in shorter periods, thereby mitigating UAT effort and time to delivery.
  • Reduced documentation efforts: The reduced complexity of the system landscape with less servers, less software, less storage, simpler data models and eliminated physical instantiations translates into significantly simpler and less time-consuming documentation.
  • Reduced change management costs: All the reasons that requirements gathering, scoping, design, development and testing with HANA lead to shorter development time also lead to significantly lower change management costs. Over a 5 year period, organisations will typically spend 1.5x the original development costs on change management, so improving the effectiveness and productivity in this area has a huge payback when viewed over a 5 year period. If you can reduce the change management cost by just 30%, you will typically save an amount equivalent to half the total original development costs.


With all the time savings that can be achieved throughout the BI project cycle, from design to documentation and the on-going change management, it is easy to see why this is such a compelling reason to look at HANA not just in terms of its ability to transform business processes, but also consider HANA’s ability to change the way that BI is delivered in organizations. Think through the implications to your business if you could deliver twice as many BI projects with the same team, or you could deliver them 50% ahead of schedule. If you’re unsure about whether this is real, have a look at some of the customers who are already seeing these benefits :

Lexmark – http://scn.sap.com/community/business-trends/blog/2013/05/15/lexmark-cio-sap-hana-gave-us-the-ability-to-respond-much-more-quickly-to-business-requirements


My suggestions for you:

  1. Benchmark your BI process. What is the time needed to build and delivering a BI project? How does this compare to your peers? (SAP Benchmarking can help) – specifically, I would suggest theBusiness Intelligence and High Performance analytics surveys
  2. Look at a recent BI project plan. Which workstreams could be eliminated or accelerated with HANA?
  3. Look for an upcoming project that would benefit from the speed and agility that SAP HANA can offer.
To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply