When it comes to planning applications, I am often approached with questions regarding decision criteria for using the Analytics Designer in SAP Analytics Cloud.
While there is no standard answer to this, as this is greatly dependent on the process itself and the available capacity in each company for the app maintenance, there are certain use cases in which an Analytics Designer app can make your life a lot easier. I have put together a list of my personal decision criteria:
#1: Your planners are overwhelmed by the data action triggers
We all know the following challenges for planners when they are working with data action triggers:
- They forget to trigger them
- They trigger them in the wrong order
- If working with multiple triggers, they need to click through them one by one
- If each of those triggers requires prompted entries, they will have to make repeated entries of the same context for each trigger
These have been the typical issues calling for the deployment of an Analytics Designer app. Using customize popups, it has been hitherto possible to enforce the execution of the triggers and its correct order. But what’s more now: With the latest release of Data Action APIs – a game changer – not only the first two, but ALL the challenges listed above are a thing of the past. It is possible now to execute a data action via scripting, triggering it upon initial app load or table result change, check its status, or even pass filter context to it. Hence it generally means that if an app developer wishes, he could banish the data action trigger to the backend, leaving the UI clean and the planner unaware of its presence. The triggering of a data copy and subsequent publish could now, for example, come right after a submission step in the planner’s workflow, automated and hidden, enabling a true one-click-submission. Another good use would also be the automatic execution of a calculation right after data entry to get at the results immediately.
You can see how elegant the solution is in this blog post containing code snippets and examples.
#2: You want planners to plan for previously non-existing elements and fill in attribute values
In this case the Analytic Designer clearly shines with its golden duo: createMembers() and updateMembers() API. They allow your planners to add a new member to an existing dimension directly from the app and define its attributes simultaneously – all via a customized UI. This is particularly useful when you need end users to plan for a completely new hire, investment, project or activity, in which descriptions such as start/end dates, person responsible, contract type etc should be entered as accompanying info to be stored in the model. I have shown an example in a previous blog post.
#3: You have a process of volatile nature and need control
Some planning processes, such as ad hoc budget submission and approval, are more volatile in nature and are hence greatly dependent on the planner’s ability to update the attributes for both new and existing planning elements.
Here, the updateMembers() API could be used alone to overwrite existing attribute values, which is incredibly helpful when you have attributes requiring constant updates, such as the priority of a project or its approval status. This full control over the member attributes also lends you the power to build complex processes in which you can use the attributes, data actions and account formulas together to control data flow, security and visibility.
And what’s more: Being able to overwrite existing attributes also provides a more forgiving UI, allowing for corrections of erroneous entries.
#4: You want to reduce the number of widgets and empower your planners to slice and dice
Sometimes you want to enable planners who are not simple input providers but decision makers who need to look at the available plan data in different aspects before giving their approval. Or your data context is defined by a high number of dimensions and it is hard to predict which breakdown you should offer as visual aids to provide most value for your planners (e.g. in HR cases: should you offer a FTE breakdown along job grade, job family, contract type, department, division, or position? Or completely something else?) In such cases, trying to offer different widgets in hope to cater to at least one need or another, is rather a hit-and-miss approach which increases the number of widgets unnecessarily. With the Analytic Designer, however, it is possible to utilize the DataExplorerConfiguration component, allowing your planners to slice and dice AND pin the result back to the app using the appyToWidget() method, hence continuing to use this as a visual aid for the rest of his planning. This is really helpful when you have limited screen real estate or have planners who would otherwise need to navigate out of your planning solution to gain the required insights.
#5: You need to multiply your screen real estate
One major advantage of the Analytics Designer, though often overlooked, is the ability to build collapsible/expandable components onscreen, multiplying hence the available screen real estate, allowing a progressive disclosure of info simultaneously. This is particularly useful when you want to give your planners some sort of visual assistance to help him understand the impact of his numbers on a higher level/broader context, but he may not need it the entire time while planning on a finer granularity. An example here could be investment planning, where it might be useful for the planner at some point to know how his plan impacts the cash flow (CF), but he wouldn’t want to be looking at the CF breakdown the entire time while planning. Here an app developer could create a panel with the CF info, which expands on demand if needed, but could also be collapsed to make way for the planning table and other widgets. The key here is to not overdo – the temptation is great to pack in more and more charts and other widgets here. But the key is to present the essential widgets in a way that enables the most efficient workflow, rather than to build hidden information floods that drown planners when triggered.
#6: Your planning process is not linear, but cross-linked, and you want a website-like navigation reflecting that
Closely linked to #5, the ability to expand/collapse or hide components in Analytics Designer means you are able to create a navigation bar/panel with interaction similar to those commonly used in websites, where sub-navigations remain hidden until triggered. Cross-linked scenarios are hence visually depicted in an easily consumable manner, and there is less clutter on your UI.
#7: You need to control the responsive behavior of your application
With the Analytics Designer it is possible to define the width and height of widgets in percent – an invaluable feature for those wanting to control the responsiveness of their applications. And with the release of the flow panel, you can easily define breakpoints in browser width and add rules to them, detailing how each widget should be scaled. This comes in really handy for cases in which you want to prevent unwanted scrolling in your widgets by exercising control over their width and height across different devices. But the greater advantage of this feature is the ability to adapt the layout of your app to fit the use case of each device. Let’s say if you have different target groups coming into your app: one who is mostly on the go and more interested in the KPIs, and another who is more desktop-bound and needs to interact with the table, you can adjust the size of each widget to arrive at layouts catering to the needs of each group/device.
#8: You want pixel perfect design for your application
The Analytics Designer is currently the component in SAP Analytics Cloud offering the most flexibility and control in design, as it allows the placement of widgets down to pixel granularity, and the ability to customize the popups and set up css styling means you could create an entire design cosmos within the app. If it is the fusion of flair and data that you are aiming for, or you need a highly customized planning application that could match other sophistically design digital touch points of the company, then Analytics Designer should be your choice.
Do check out Jie Deng’s great blog post for examples.
When you look at the use cases above you will see that it all boils down to the control you would like to have over the end user workflow/interaction, ad hoc data maintenance/flow, and the appearance of your solution across devices. If any one of those is crucial for your process, it would be recommended to give Analytics Designer a try.
As new features will change this list along time, do stay tuned. Feel free to follow me in Linkedin where I will be posting news on updates. Meanwhile, do also follow the Analytic Designer blogs to catch the latest features coming, which will also definitely help in your decision.