SAP Analytics Cloud: Story vs. Application

Decision support on when to use which solution

The SAP Analytics Cloud (SAC) is SAP's strategic data analysis tool that combines business intelligence, dashboarding, visualisation, planning and predictive functionalities in one solution. To analyse or plan the data, SAP now offers two approaches - the Story or the Analytic Application.

Introduction

The self-service approach under Data Discovery (suggesting stories) makes it possible to involve business departments themselves in the data visualisation process. Through artificial intelligence and machine learning, SAC already suggests stories that provide useful insights without much further effort. However, there is another way in which data can be visualised, namely with analytical applications. According to SAP, these are supposed to be much more flexible than stories and can thus better meet customer requirements. This flexibility is made possible by scripting in the Application Designer, which differs significantly from the working environment of Stories. This comes at the price of a higher creation effort.

This blog entry shows the difference between Stories and Analytic Applications. When it might make sense to use a story or an analytic application. It also addresses the question of whether the business department can profitably use and build analytical applications without IT support. There is already a blog that shows the advantages of an analytic application, but not yet a direct comparison in the German-speaking world (see link below).

In general

Both stories and analytic applications serve to present and visualise the processed data in a comprehensible way. Only through a target group-defined, clear and understandable data visualisation can the full potential of the data be exploited. Tables, graphs, diagrams and other visualisation elements can be used here. With the help of these elements, a deep insight into the business and the organisation is made possible.

Story

The Story is characterised by a clear and simple concept that can be set up without much effort. The visualisation of simple scenarios and questions are in the foreground, as is detached planning. For more complex questions or a comprehensive integrated planning process, the Story quickly reaches its limits.

The creation and editing of stories can be learned quickly, which is why it is ideal for self-services and does not require extensive know-how. This is reinforced by a dialogue-guided condition that is easy to use by both the creator and the user.

When creating a story, it is only necessary to decide once which basic layout should be chosen. After deciding, for example, on a responsive layout, no thought needs to be wasted on the scalability of the story on mobile devices such as tablets or mobile phones. This is guaranteed automatically.

Analytic Application

Analytic applications are suitable for mapping complex requirements. These requirements can be expressed by scenario, question, functionalities, representations and/or user guidance. A concept should be created based on a variety of goals, whereby the expectations and functionalities should be clearly worked out. Personalised user guidance, scripting logics and drill-downs can quickly lead to a loss of clarity without a sensible concept. With a sophisticated concept, complex correlations in reporting or in comprehensive planning can be implemented and user guidance can be made much more personalised.

The creation is much more complex and requires more technical know-how and basic understanding, as the graphic elements can be influenced and changed with the help of scripting. Scripting is therefore required to ensure smooth use of the analytic application. Additional functions are, besides the modification of almost every visual element, working with buttons, pop ups, scripting and the Odata Services. Those who know Lumira will find their way around more quickly and know where the pitfalls lurk, but also what potential is possible. In addition, the aspect of maintainability must be taken into account, as adjustments also require more effort than with Stories.

Feature comparison

The following table gives an overview of the most important features and where they are available. This list makes no claim to completeness and does not intend to describe the details, as the blog is only a decision-making aid and does not analyse the technical differences in depth.

Data action triggers differ in their use. In the story, a data action can only be triggered via the standard button. In the analytic application, it can be triggered via various other user interactions. The Data Analyzer cannot be called from a story. Without creating a story, it can be called via a custom URL. In an analytic application, however, it is possible with a command without any problems.

Conclusion

I do not recommend checking first whether an analytic application makes sense, but whether it is possible to implement your requirements with a story. This can save effort and you will not be tempted to make your requirements more complex than they actually are. Only if it is not possible to implement your requirements should you turn to analytic applications.

When working with analytic applications, it is important to communicate clear requirements and expectations and to define them rather than making frequent adjustments. This is one of the most common reasons why projects in this area run out of budget.

Furthermore, it can be stated that a certain IT affinity is required for the analytic application and that a specialist department that has no programming or scripting knowledge will not get on very quickly here.

Conclusion of the differen criteria (German):