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. Here’s another example of a customer who is seeing huge productivity improvements and increasing business user satisfaction:


kennametal.PNG

In this blog, we’ll take a look at how customers are achieving these productivity gains:

A typical BI development project plan might look like the following:

  • Requirements gathering / scoping = 20-30%
  • Blueprinting / Design = 25-35%
  • Development = 20-30%
  • Testing / rework / implementation = 15-20%


… and then there’s a cost of about 30% change management every year Although requirements gathering and scoping + design represents 45-60% of the effort, it usually represents more 70% of the project in terms of elapsed time, just because of the difficulty of getting the right people in the room, capturing their needs and building a data model and structure that delivers against all the requirements. Anything that can help us streamline these two processes will have a significant impact on project delivery time and cost.


What are the big problems with this approach?

  • The requirements gathering and scoping requires a lot of investment from the business; the process is iterative and time-consuming.
  • The first time the business user sees anything is usually 15-20 weeks into a 6-month process. This is perceived as unresponsive (even if IT has been working flat-out).
  • By this time, some of the requirements have changed, and there is a further iteration, or even multiple iterations to catch up to new user requests. Some projects are obsolete before the user has even seen the first iteration.
  • The data models that power our BI systems are inflexible, and expensive to maintain and change.

What do the requirements gathering and design processes look like today?

This usually starts with a series of interviews between developers and business analysts or business users, and is one of the most time-consuming parts of the process. Business users are asked what datasets they would like to analyse. That’s the easy bit. Now, the business-person is asked for all the questions that they are ever likely to ask of that data. This is hard, especially as the businessperson doesn’t know what questions they will ask in future. This is especially true now, as business conditions and market dynamics change quickly and constantly.

These interviews are conducted with a number of different stakeholders, captured in word, printed out, piled up in stacks that cluster requirements. A huge, perfect (?) data model is built that will handle all the requirements. The modelling takes into account not just the requirements, but also all the artefacts needed to deliver acceptable performance, including indexes, aggregates, summaries.

What changes when you move to BI project build based on HANA?

Analytics vs Reporting: One of the first fundamental shifts is the balance between analytics and reporting. Traditionally, most analytics/BI teams report a balance of 80% reporting / 20% analytics. The combination of very high query performance against granular data without IT tuning (e.g. no index constraints), full data access (subject to permissions) and modern, easy to use analytics software shifts this to 20% reporting / 80% analytics. Assuming that the glossary and semantic layer have already been developed, the effort for self-service analytics is minimal, and the turn-around almost instantaneous.

Remaining projects easier and faster to scope: With HANA, data only needs to be physically stored at an atomic level, resulting in a very simple physical data model. All modelling on top of this data is logical, and all aggregates / roll-ups are calculated on demand. This means that you don’t need to know all of the requests of data up front; you can deliver against a small set of requirements quickly, deliver to the business and then iterate with the next set of requirements.

Does HANA impact Design, Development, Testing and Change Management?

HANA significantly accelerates these stages of the BI development process, and that will be the topic of the next blog in this series…



Many thanks to Henry Cook and Wilson Kurian for their contributions. This blog was originally posted in saphana.com

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