Optimizing my dashboard: Creating a visual draft

Remember my last post about the Webi dashboard? As mentioned at the end of that post aimed to show a technical trick to put an interactive kind of a button onto a Webi report. Now this post is the first in a series of posts how to optimize the layout of the initial dashboard. Let’s start with creating a draft of our optimized dashboard layout. The advantage of such a draft is that it is not yet implemented with the actual BI tool but using either pen and pencil or a wireframing tool. I did the later and chose the cloud edition of Balsamiq. To get a quick start you can use a 30 days trial account.

Let me explain briefly how the tool works. After that I’ll explain some of my thoughts behind the chosen layout.
Within the editor you can drag and drop sketched objects like a window container, rectangles, text, buttons etc.


My dashboard in the Balsamiq editor

Looking at the available chart objects, I’m not really satisfied:


Default chart elements in Balsamiq

Therefore I added my own images representing typical IBCS chart types (IBCS stands for International Business Communication Standards. I wrote a short blog post about IBCS here.). The images are based on the graphomate add-on for SAP DesignStudio and BusinessObjects Dashboards.


Typical IBCS chart types (created with graphomate)

After all, my inital dashboard draft looks like this:


My dashboard draft (chart view 1)

At the top you can see some reserved space for an appropriate title. Providing this is a major requirement stated by IBCS as one of the top ten proposals:

I adapted this to a BI specific title concept where I distinguish between general title elements (like the organization or global query filters) and object specific titles, e.g. for the table or a chart. For the table I used the default element of Balsamiq, maybe I will update this later on with an IBCS optimized one. For now it is just a placeholder.

The charts in this first view will show current year values and previous year values (where as the current year will be indicated within the global filters area) for revenue and margin. To make the analysis of available data more straight forward, I decided to add two variance charts, one for absolute values and one with percentage values. Again, this is one of the top 10 elements in IBCS:

You might have discovered the symbolic button to switch the chart view. The second view looks like this:


My dashboard draft (chart view 2)

The header and table areas stay the same. In the lower area with charts I now show historical values for revenue with actual and plan values. Instead of putting everything into one big chart I decided to use small multiples for the top 5 product lines (based on total revenue over time) as well as one chart for all other product lines. Depending on how it will look like in Webi we might decide to show more product lines or add another topic to the dashboard (as we still have space left on the bottom right corner).

In this blog I showed how to create a simple dashboard draft using a wireframeing tool like Balsamiq. In addition I pointed out how to apply two of the top ten IBCS proposals in this conceptual phase.

A (Webi) dashboard built by a business (power) user

This blog post is inspired by a recent customer request to challenge their decision to use Design Studio for some “dashboard requirements”. Showing how you can create a dashboard in Webi doesn’t mean I told the customer not to use Design Studio. Much more it is to show that finally a dashboard as well as every other type of BI front end solution is made up of requirements and not primarily by the tool you build the solution. Please refer to my Generic Tool Selection Process for more details as well as my post regarding BI specific requirements engineering.

Having said this, let’s have a look at how we can use latest Webi 4.1 features to quickly build an interactive dashboard without the need of (much) scripting. First of all here is what the final result looks like:


You can select values from the left side bar (Product Lines), you can select States by directly clicking into the table and you can switch from the bar chart to a line chart. Here you see it in action:

The first step to achieve this, is to create the basic table and the two charts. Until the dynamic switch is implemented, I placed them side by side. Next add a simple input control in the left side bar:

02_SimpleInputControl 03_SimpleInputControlDepend

Next thing is to define the table as an additional input control – right click the table and choose “Linking” and “Add Element Link”,  choose the two chart objects as dependencies:

04_TableAsInputControl 05_TableAsInputControlDepend

Next we need to create the “switch” to toggle the two charts. As I would like to position this switch at the top right corner of the chart, I again use a table input control. To generate the two necessary table values (namely “Bar Chart” and “Line Chart”) I prepared a simple Excel spreadsheet:


In 4.1 you can now finally upload this sheet directly into the BO repository:


If you need to update the Excel sheet later on, this is now feasible as well:


Finally, in Webi add the Excel sheet as a second query:

10_ExcelQuery    10_ExcelQueryDetails

In the report we need now two tables: A visible one to represent the chart switch and a (hidden – see the “Hide always” option) dummy table to act as a dependency for the first:

13_HiddenDummyTable  12_HideDummyTable

The most tricky part is to create a variable to retrieve the selected value:


Here the formula for copy / paste:

=If( Pos(ReportFilterSummary(“Dashboard”);”Chart Type Equal “) > 0)
Then Substr(ReportFilterSummary(“Dashboard”);Pos(ReportFilterSummary(“Dashboard”);”Chart Type Equal “) + Length(“Chart Type Equal “);999)
Else “Bar Chart”

(The idea for this formula I grabed from David Lai’s Blog here)

Finally you need to configure the hide formula for both charts:


That’s it.


Positive: I’m not too technical anymore (I do more paperwork than I wish sometimes…). Therefore I don’t consider me a “developer” and I like solutions for the so called “business (power) user” more and more. Therefore I like Webi. It took me about 60 minutes to figure out how to create this kind of interactive dashboard. I didn’t need to install anything – I could do everything web based. Except for one single formula (which I didn’t need to write myself)  I could click together the above sample. And I dare to say it looks like some kind of a dashboard :-) In addition I have all the basic features of Webi like a broad range of data source support, plenty of export possibilities, Office integration and so on. Even integrating an Excel spreadsheet as a data source is now finally a no-brainer.

Negative: Clearly, Webi is not a “design tool”. For example I wasn’t able to show icons for my chart switch instead of the text lables. Putting a background image to the table doesn’t work well if the table is used as input control. When I discussed this prototype with the customer they also mentioned that there are still too many options end users might get confused with (e.g. that there is a “filter” section showing whether the Bar Chart or the Line Chart value is chosen). In Webi you can’t change that. Toolbars, tabs etc. are just there where they are. Live with it or choose a different tool.

Bottom line: Have a look at my Generic Tool Selection Process and the mentioned hands-on test. The above example is exactly what I mean with this: Create a functional prototype in one or two tools and then do a fact based decision depending on your requirements and end user expectations.

Important remark: This post focused on the technical aspect of the dashboard. The visual representation doesn’t yet fit to best practices mentioned in my earlier articels (e.g. about SUCCESS) In a next blog post I will outline how to optimize the existing dashboard in this regard.

Getting to Know the German Monster – The Importance of Proximity in a Globalized World

Just recently I published a blog about the following topic on sap.com

Thanks for reading!

IBCS – an emerging standard for business #dataviz

In my previous post I introduced the SUCCESS model of Rolf Hichert. In this post I’d like to introduce you to the subject of IBCS – the International Business Communication Standards. IBCS’ aim is to “foster the level of understanding in reports and presentations” (Source: IBCS). Currently, IBCS consists of two main parts:

Notation of meaning
The part “Notation of meaning” describes basically the semantics of a standardized business communication language. It covers all aspects of meaning in the context of business communication and suggests an appropriate notation.

Design of components
The part “Design of components” covers rather the syntactical aspects of a standardized business communication language. It describes the basic report elements and specific rules to use them for the design of objects such as tables and charts. Several objects and additional elements make up complete pages. Although this part should not consider aspects of meaning, but only define the “grammar” of a unified communication language, some overlap to the “Notation of meaning” (semantics) is inevitable. (Source: IBCS)

IBCS and SUCCESS are closely related, therefore I will start with some explenations about how the two topics are positioned against each other. First of all SUCCESS and IBCS can be looked at from a time perspective. Clearly, SUCCESS was developed first:


From this point of view IBCS  is a refinement of certain aspects of SUCCESS (namely the Unify part in SUCCESS). This refinement can be seen in the following perspective too:


SUCCESS provides only generic guidelines without concrete implementation details, e.g. the following one:


Souce & Copyright: HICHERT + PARTNER

This guideline just tells you: If you visualize this year’s revenue with blue in chart number 1, you should also use blue in chart number 2. But the guideline doesn’t tell you to always use blue. If you wish to take brown for current revenue, it’s OK. Just use brown whenever you visualize current revenue. This and many of the other guidelines (some of them are mentioned in my previous blog post) in SUCCESS I therefore attribute to what I call “common sense” or data visualization basic recommendations. Now IBCS comes into play. Whereas SUCCESS is rather generic IBCS defines the details and writes them down. As indicated above IBCS does this in mainly two parts:

- the notation of meaning clearly defines which elements have which meaning:


Source: IBCS

This way business communication should be simplified through standardization the same way as you are used to it with geographical maps for example. Blue always means water, north is always at the top of the map etc. This “semantic layer” is something which differentiates IBCS from other data visualization and information design concepts. Most if not all of them focus on generic recommendations only. In contrast, IBCS wants to harmonize the visualizations in a business context and make them therefore easier to understand.

- the second aspect of IBCS is the design of components

Let’s have a look at the SUCCESS guidline first, e.g. for chart design:

Source & Copyright: HICHERT + PARTNER

Source & Copyright: HICHERT + PARTNER

IBCS gives you much more information, e.g. regarding legends:


Source: IBCS

You can look at IBCS and SUCCESS from a third perspective too:


In this perspective IBCS is the solid base with all the detailed rules to consider for efficient data visualizations in business communications. Yet the IBCS rules are hard to digest (as every other industry standard…) SUCCESS can be seen as an implementation methodology of them (as IBCS and SUCCESS are mostly congurent to each other). SUCCESS is an acronym of seven verbs – if you act on them, you’ll see that implementing IBCS is pretty straight forward.

IBCS is work in progress and it is open-source (based on the Creative Commons BY-SA license). Its further development is orchestrated by the IBCS Association which again is run by HICHERT + PARTNER. Simply create a login on ibcs-a.org and start to add your own ideas to further refine and extend the standard.

If you want to learn more about IBCS, SUCCESS and how it can be implemented, join me during the BOAK conference this autumn. It takes place on Tuesday, September 16th in Zurich / Switzerland. In the data visualization track (sessions E1 to E4) you’ll find several sessions dedicated to IBCS. Jürgen Faisst, CEO of HICHERT + PARTNER will elaborate on the goals of IBCS. My friend Lars Schubert will demonstrate how you can apply IBCS using the IBCS certified software “graphomate” as part of SAP Design Studio or SAP BusinessObjects Dashboards. I myself will present together with a customer showing how we implemented an IBCS oriented design in Web Intelligence. The day after I will teach these best practices during a one day workshop. A sneak peek on the Webi reports you can find on my Hichert Certified Consultant page. Looking forward to seeing you during the BOAK conference!

What do you think about IBCS and the semantic layer? Do you think it is worth the effort to harmonize data visualizations in a business context? Just add a comment now!

Simple guidelines for more efficient report & dashboard design

It is already for more than three years that I’m engaged with the topic of business information design. It was during a regular Crystal Reports project. We were about to finalize the IT concept phase and the project was on track. Crystal Reports was already selected as the tool to go forward with. When suddenly something happened: The sponsor of the project, the company’s CFO, asked us if we can implement what he called a “Hichert chart”. I found that Hichert is a German business information design specialist and at first sight he had some weird ideas regarding chart design. So weird we couldn’t really implment them with Crystal Reports and – long story short – we couldn’t finish the project as the CFO’s requirement regarding Hichert charts was too strong. Not even other tools within the BusinessObjects portfolio were able to fullfil it. So the customer finally chose an Excel based solution…

Of course I was annoyed but at as well curious. How powerful this Hichert stuff must be in order to turn a project upside down? This was the start of my journey into business information design. According to Wikipedia this field is about the following:

“Information design is the practice of presenting information in a way that fosters efficient and effective understanding of it. The term has come to be used specifically for graphic design for displaying information effectively, rather than just attractively or for artistic expression.” (Source)

In this and future blog posts I’d like to illustrate how you can achieve this more efficient understanding of data and information in the context of Business Intelligence.

There is already a lot of helpful content available, let me name just a few sources I use in my daily work:

For this article I’d like to introduce the SUCCESS model of Hichert. SUCCESS is an acronym for the following verbs:

Say – Unify – Condense – Check – Enable – Simplify – Structure

Every verb corresponds to a collection or category of design guidelines. Most of these guidelines are commonly accepted best-practices – and you find them as recommendations not only with Hichert but with many of the above people. The only difference with SUCCESS is, that the recommendations are put into about 120 concrete, numbered and illustrated  guidelines of “Dos & Don’ts” regarding information design. This very structured approach makes it very easy to get started with the topic. You can find everything summarized on the SUCCESS poster:


SUCCESS Poster (Source & Copyright: HICHERT+PARTNER)

You can download your own copy here.

Let me briefly explain what each category is about:

Say: This is about having a message to tell or in general about meaningful content in your reports and dashboards. A good example is the following guideline:

Replace Traffic Lights

Replace Traffic Lights (Source & Copyright: HICHERT+PARTNER)

Another important, yet pretty easy to implment guideline tackles the matter of having a clear title concept which enables the reader to quicker grasp what he or she is looking at:

Title Concept (Source & Copyright: HICHERT+PARTNER)

Title Concept (Source & Copyright: HICHERT+PARTNER)

Unify: This category of guidelines is about the statement “what looks the same should mean the same” and the other way round. The following guideline shows suggestions how you might unify the look of tables and charts – for now the important part is not yet what the chart or table looks like but that charts and tables always follow the same design pattern.

Unify Tables & Charts (Source & Copyright: HICHERT+PARTNER)

Unify Tables & Charts (Source & Copyright: HICHERT+PARTNER)

Condense: Condense is about increasing the information density on a given report or dashboard page / screen. A few simple but powerful guidelines:

Use empty space (Source & Copyright: HICHERT+PARTNER)

Use empty space (Source & Copyright: HICHERT+PARTNER)

Use Small Multiples (Source & Copyright: HICHERT+PARTNER)

Use Small Multiples (Source & Copyright: HICHERT+PARTNER)

Check: This category is about ensuring quality. One topic for example is to choose an appropriate chart type and the usage of propre scales:

Choose appropriate chart type (Source & Copyright: HICHERT+PARTNER)

Choose appropriate chart type (Source & Copyright: HICHERT+PARTNER)

Don't cut axes (Source & Copyright: HICHERT+PARTNER)

Don’t cut axes (Source & Copyright: HICHERT+PARTNER)

Enable: The guidelines in the Enable category are not about information design itself but how to best introduce the guidelines of the other categories into an organization:

Present alternatives (Source & Copyright: HICHERT+PARTNER)

Present alternatives (Source & Copyright: HICHERT+PARTNER)

Create a Rollout Plan (Source & Copyright: HICHERT+PARTNER)

Create a Rollout Plan (Source & Copyright: HICHERT+PARTNER)

Simplify: This category brings together a lot of guidelines which are all about avoiding noise and other distracting elements in the report and dashboard design:

Avoid meaningless elements (Source & Copyright: HICHERT+PARTNER)

Avoid meaningless elements (Source & Copyright: HICHERT+PARTNER)

Avoid 3D charts (Source & Copyright: HICHERT+PARTNER)

Avoid 3D charts (Source & Copyright: HICHERT+PARTNER)

Omit Long Numbers (Source & Copyright: HICHERT+PARTNER)

Omit Long Numbers (Source & Copyright: HICHERT+PARTNER)

Structure: Similar to the Say category, Structure is more about the content itself than its visual representation. The guidelines here describe how to group data:

Exhaustive Structures (Source & Copyright: HICHERT+PARTNER)

Exhaustive Structures (Source & Copyright: HICHERT+PARTNER)

Mutually Exclusive Structures (Source & Copyright: HICHERT+PARTNER)

Mutually Exclusive Structures (Source & Copyright: HICHERT+PARTNER)


Show Structures (Source & Copyright: HICHERT+PARTNER)

Show Structures (Source & Copyright: HICHERT+PARTNER)

Most of the above shown guidelines can be implemented straight away with most BI tools including SAP’s Web Intelligence and Crystal Reports. During my upcoming blog posts I’d like to look more closesly at several further aspects both from technical as well as conceptual perspective. This will also answer the question why we had troubles implementing “Hichert charts” in the customer project mentioned at the beginning.
In the meanwhile I’m happy to get your feedback what you think about SUCCESS and to learn about your experience regarding information design in the context of Business Intelligence.

Wishlist for SAP BOBJ tool consolidation

Obviously the multitude of BOBJ client tools is still a hot topic – both for SAP as well as its customers. From SAP’s side we’re hearing now about their decision to consolidate BOBJ / BI client tools. There are a lot of rumours during the currently held SAPPHIRENOW conference like the following:

JayneTool roadmap

There was a Google hangout session last week with Steven Lucas, President of Platform Solutions at SAP. In this article I will summarize some key points from this talk and add my own thoughts.

Have a look at the video at about 23:00. Steven mentions that there are currently 21 BI client tools in the BOBJ/SAP portfolio. That’s why SAP already took  the decision: “We are going to consolidate our BI tools”. In addition Steven mentions that they won’t deprecate core technologies like Webi or Crystal, but maybe integrate niche solutions like Explorer into Lumira. I personally like the statement about “feature preservation, not tool preservation”.

Although there are good reasons why SAP should consolidate their BI client tool portfolio I’d like to point out where I see the root cause of the problem: Definitely the number of different tools is not the real issue. I often use the comparison with the automotive industry. Just have a look how many models certain car manufacturer have in their portfolio:


Different cars for different purposes. Different tools for different purposes. But what’s different between the shown car portfolio and SAP’s BI client portfolio? All the cars share some basic functionality like four wheels, a steering wheel, head lights etc. For the BI client portfolio we still lack some basic functionality to be included in every tool more or less in the same way: One main issue is the missing homogenity in terms of data access. For relational data the Universe might be seen as a common base. But not even 10 years after Crystal Reports was bought by BusinessObjects, and not even in the new Crystal Reports for Enterprise version which was built from scratch we see equality of how you can connect to datasource compared to e.g. Web Intelligence. The same with BW connectivity. When I was at the sapInsider conference BI2014 two weeks ago at Nice / France, I had to learn once again from Ingo Hilgefort that Web Intelligence lacks some basic functionality like Zero Suppression even now having BICS based direct connectivity to BW. The same with HANA connectivity where Crystal supports HANA connectivity using an OLAP connection but Webi doesn’t. The same with Web Services connectivity and I cut continue the list for a while. From an architectural perspective I just ask: Why?

Another commonly cited issue is the charting library. Still there is nothing like common charting capabilities, the different tools still differ quite heavily in terms of what they provide as chart types and options, not to talk about the missing option to plugin a custom charting extension to all BI tools but only specific ones.

To sum up this first part: SAP’s job isn’t done by simply reducing the number of tools. They need to make sure that the remaining tools share some commonly expected features. Don’t let data connectivity or charting options be the differentiator between the different client tools.

I already wrote certain blog posts about BOBJ tool selection. Whereas the later posts were tool agnostic, the first one was very concrete. In this article I outlined some major differences (especially short comings) between the tools. On this background let me formulate my personal wish list for the future BOBJ tool consolidation:

  • Merge Crystal Reports into Web Intelligence: I know, according to Steven’s statement above this won’t gonna happen as Crystal is considered a core technology. Still, give this thought a chance. There isn’t that much missing between Crystal Reports and Web Intelligence from a feature perspective. Conditional formatting, interactive alerts, some more export formats, hierarchical grouping for relational data and a more powerful formula language. Being a Crystal Reports consultant for more than 12 years I’m not really happy with this thought in a first instance as I really like the tool. But if imagine how I could leverage certain Crystal Reports features with the powerful capabilities of Webi, it sounds very promising to me.
  • Merge BO Dashboards / Xcelsius “visuals” and input controls into Web Intelligence, Design Studio and Lumira: Stop the thinking that “a dashboard” is a matter of the tool. From a business perspective a dashboard has more important elements than just to be fancy and highly interactive. Depending on the business requirements you can build a dashboard in many tools including Design Studio (more app style dashboards), Lumira (more the ad-hoc kind of dashboard) and Webi (if you want to have more sophisticated data  capabilities and the fully fletched platform support like scheduling / publishing, control user actions with rights etc.) So please share the visual components we find in BO Dashboards today to various tools like Webi, Design Studio and Lumira.
  • Merge Explorer and Lumira – and think about the “feature preservation”. Don’t forget to add the “Export to Webi” somehow to Lumira.
  • Merge LiveOffice into BO Analysis, Edition for Office. LiveOffice is still very powerful, but I think we don’t need two separate add-ons.
  • Merge Analysis OLAP into – I’m not sure, as I’m not very used to this tool. Regarding the BW connectivity issues I’d like to see the Analysis OLAP capabilities in Webi. And / or you can add an OLAP grid / control to Design Studio.
  • Merge the predictive tools like Infinite Insight and Predictive Analysis into one joint tool.

How do you rate my wishlist? How does your wish list looks like? I’m looking forward to reading your comments soon!

[Update June 12th 2014] The guys from EVTechnology wrote an excellent blog regarding their findings from SAPPHIRENOW. There you can find the following screenshot:


Not too far away from my wishlist though ;-)

In addition Tammy Powlas documented an interesting webcast regarding Crystal Reports for HANA. I just hope that at least the HANA direct connectivity will be added the same way to Web Intelligence…


The bug paradox: When fixing the bug leads to wrong reports

My workmate Christoph Gnodtke wrote an excellent blog about how to identify SAP BusinessObjects Web Intelligence reports which are impacted by various calculation changes in newer BO versions. What I would like to point out here is that not only BO 4.x migrations are concerend but also “simple” service / support package upgrades e.g. from XI 3.1 SP2 to SP6. In my current customer case we’ve found many many reports which obviously were created in a wrong way, namely that the table structure contains the merged dimension (e.g. [Merged Country]) where as the cells within the row use a variable containing e.g. a Where operator using the original dimension ([Query1].[Country]). In our case the business requirement would have been to use the merged dimension here as well. As outlined here, in former BO support package levels a bug resulted in the effect, that the just mentioned example still showed what the business expected. Now (e.g. in XI 3.1 SP6) that the bug is fixed, the reports start to show wrong values. Although the software 360Eyes doesn’t solve the problem, it at least helps to identify concerned reports. Unfortunately we still need to look into every single report and compare between the version running on the XI 3.1 SP2 environment and the SP6 environment. In order to speed up this process we use 360Cast. This software provides similar features like BO Publications e.g. for report scheduling and bursting. The main advantage namely in the case of report testing are two fold (compared to BO out of the box features):

  1. Report selection for a schedule job can be done using good old BO categories. That means you can assign e.g. a test category to all reports you want to test in one single run. In our customer case we use categories for each data mart. In 360Cast, instead of choosing every single report individually, we just choose to select all reports of this test category.
    In order to run all these reports with one single click there is just one thing missing: Providing all the necessary prompt values, often the same values for the same prompts (like Year) over many reports. This is where the second advantage comes into play:
  2. To provide prompt values 360Cast accepts both manual input values (where a value can be applied to a all prompts with the same name) but also values from an Excel sheet (or even from an SQL query). We usually use the Excel alternative. Based on this we can easily vary input parameters for different test purporses by simply using another Excel sheet. In addition we can specify the export format and the recipients, e.g. by providing an email address.
    (The values in the drop down menues correspond to the columns in the underlying Excel spreadsheet)

After all, also 360Cast doesn’t solve the initial problem. But at least we don’t need to run every report (identified by 360Eyes earlier) on its own but can automate the refresh process and we can easily rerun reports (e.g. with different prompts by simply modifying the values in the Excel list).

BI Picture Books (BI specific requirements engineering – part 2)

Part 1 of this article you’ll find here.

Illustrate available options using a BI Picture Book

A BI Picture Book is a structured collection of “pictures” aka screenshots of features illustrating one or multiple products. It describes and illustrates the available options in a compact and easy to handle manual. It should help the user to identify what options they have in a given BI front end application.
Referring to scenario A and B above, in an ideal world one would create a BI Picture Book during the initial tool selection process (scenario B). In this context, the BI Picture Book helps to illustrate the available features of the different tools under consideration. Some (or all) of these tools will become “strategic” and therefore the preferred tools to be used during subsequent BI projects. In the same way, the corresponding parts of the original BI Picture Book will also be included in the “daily business” BI Picture Book, which only contains the available options regarding the strategic tool set.
One main characteristic of a BI Picture Book is that we compare feature (or requirement) categories one after another and not a tool (with all its different features) after another tool. This helps to clarify specific differences between the tools for each category.


Based on the previously described structure, the BI Picture Book should contain notes which highlight unique features of one tool compared to the rest of available (or evaluated) tools, e.g. a specific chart type which is only available in one tool. On the other hand, one should highlight limitations regarding specific features that are initially “not obvious”, e.g. in cases where the color palette of charts cannot be customized. Another example is to specifically highlight a tool which does not contain an Excel export (because end users might assume that there is an Excel export for every imaginable BI tool, so that they think they do not have to specify this).

How to build a BI Picture Book

Building a BI Picture Book is primarily about taking screenshots and arranging them in a structured manner, e.g. following the seven feature categories introduced above. As with every other project, certain points need to be planned and clarified before you start:

  • What is the primary purpose of the BI Picture Book? This refers to either scenario A) requirements engineering or scenario B), creating a front end tool strategy.
  • Which BI tool vendors are to be taken into consideration? Which concrete tools of these vendors are to be integrated into the BI Picture Book? For scenario A) this is defined by the available strategically defined BI toolset. For scenario B) it depends on the procedure for evaluating and selecting tools for your front end tool strategy.
  • Once you know which tools you want to take screenshots of you need to define which software version to use. Depending on the release cycle of the BI vendor, the software version can make quite a difference regarding available features. Therefore a BI Picture Book is mostly specific to a certain version.
  • For cars, there are tuning shops which provide extra features not offered by the car manufacturer. Similarly, in the BI world, there are many add-on providers who extend the available features of BI products. If such add-ons are already in place, it is important to include their features in the BI Picture Book. Nevertheless, one shouldn’t forget to label features from add-on products specifically as they might be charged additionally.
  • Do not show options which are not applicable in practice, e.g. system wide customizations on a multi-tenant BI platform. An example is customizing the look and feel of the BI portal by modifying the portal’s CSS style sheet. Although, in theory, this option might exist, depending on your organizational and technical setup, to changing the style sheet might not be allowed because many other stakeholders would be affected.

After having answered these questions, you can start: Take whatever screen capture program you like and start taking the screenshots. Use either a tool like Microsoft Powerpoint or Word to collect and layout the screenshot in a meaningful way. Keep an eye on the point that the BI Picture Books’ main characteristic is about comparing a specific feature over multiple tools. Therefore, put the screenshots of a given feature for multiple tools side by side on the same page or slide.
The subsequent paragraphs will illustrate how a concrete BI Picture Book might look. Screenshots are taken from various SAP Business Intelligence front end tools.

1. Content Options

Content options are difficult to illustrate using screenshots regarding scenario A). For scenario B) we can, for example, compare the different available data connectivity options:


Connectivity Options in Crystal Reports


Connectivity Options in SAP Lumira

2. Navigation & Selection Options

For navigation options outside of information, products typically screenshots of a BI portal are to be taken. This can be either based on a vendor specific portal or your company’s intranet site (or both if end users have a choice and need to decide which one to use).


SAP BusinessObjects BI Launchpad

On the other hand, a tool provides navigation and selection features inside information products. We usually take screenshots for at least the following elements:

  • Parameter & Prompts
  • Input Controls
  • Groups / Hierarchy View and Navigation
  • Drill Down features
  • Tabs

Some of these elements are illustrated as follows:


Prompts in SAP BusinessObjects WebIntelligence


Selectors in SAP BusinessObjects Dashboards (aka Xcelsius)


Drill-Down in Web Intelligence


Drill-Down in Crystal Reports

The drill-down example, in particular, shows that it is not enough for an end user to simply specify “we need drill-down functionality” as a requirement. End users need to specify requirements in alignment with the different options of drill-down available.

3. Layout Options


Excerpt of Chart Picture Book for some SAP BusinessObjects front end tools

We suggest taking screenshots for the following elements:

  • Charts
  • Tables
  • Cross tables
  • Speedometers
  • Maps
  • Conditional formatting

Make sure you list all important features and highlight the unique ones as well as limitations that are not obvious. This helps end users to compare the different options. In some cases, it is important to shed more light on the settings of features such as charts. By way of example, specify if it is possible to change the colors of a pie chart?

4. Functional Options

Next up are functional options, for example export. It is quite simple to find the available options and therefore it is easy for end users to choose from the existing options. It is useless, for example, if you let someone define that he wants a PowerPoint export from a front end tool, if it does not exist. Of course this would be nice, but it is simply not part of the catalog.


Different export formats for different tools

Another category of functions is printing. Usually it is not precise enough if an end user specifies he needs to print a document. Giving them a picture book, they can easily find out the available printing options. The BI Picture Book should clarify points such as if you can mix landscape and portrait page mode or choose «Fit to page». Below is our list of typical functions which could be integrated into the BI Picture Book:

  • Export formats
  • Printing options
  • Alerts
  • MS Office Integration
  • Commentary features
  • Multi-language support
  • Search options


5. Delivery Options

An up-to-date topic which falls into the category of delivery options is mobile-device compatibility. This is becoming increasingly important at a time when all information should be available independent of the end users geographical location. Depending on the BI vendor and the BI tool itself, mobile devices support can differ considerably. Some serve the information products 1:1 to mobile devices. Others transform existing information products into specific mobile versions, which might have quite a different look and feel compared to the original information product.


Crystal Reports document being viewed on a desktop and on an iPad


Web Intelligence document being viewed on a desktop and on an iPad

6. Security Options


Different security options for Crystal Reports and Web Intelligence documents

As with content options, it is somehow difficult to visualize security options using screenshots in a meaningful way. Try to focus on the comparison aspect between different tools and highlight unique features and limitations that are not obvious. The following example illustrates the available access rights for two different tools. One tool can simply restrict the export functionality in general, whereas the other tool can control the different export formats.

7. Qualitative Options

It is hard to illustrate this category using screenshots. Yet, as indicated in a previous paragraph, you can try to find other illustrations to guide your end users in specifying qualitative requirements.

Final Words

As with my other blog posts this article doesn’t aim to be a complete list of something. A BI Picture Book is neither the only way to define BI specific requirements nor is it enought to define a complete BI front end tool strategy. It shows you a particular idea and it is up to you to apply it in your organization in combination with other appropriate methods.

Please share your experience – I’m looking forward to reading your comment just below!

BI specific requirements engineering – part 1

(Thanks to my co-author Alexander van’t Wout for supporting me writing this blog post!)

Collecting requirements for BI front end tools is often frustrating.

Imagine a sales conversation at your local car dealer. After some small talk you are going to tell the salesperson about your interest in buying a brand new car. Nothing easier than this you might think. But suddenly you are confused. The friendly salesperson asks you if you would please write down exactly what you want and draw a sketch of what you have in mind. As if this was not funny enough he hands a sketch board over to you with a blank sheet of paper on it.

This is how many Business Intelligence (BI) experts deal with their customers today. End users are often left alone to «design» their requirements. A car is a «commercial off-the-shelf product» and therefore very similar to a BI toolset, which is «off-the-shelf software». A common characteristic of both product types is the standardization of features, and therefore a limited set of features. On one hand, this might limit your flexibility; on the other hand, it simplifies the process of requirements’ definition drastically because you do not need to consider each and every detail to build a system.

We can distinguish two major scenarios where a business user community needs to specify requirements for BI front end tools: scenario A) is an organizational environment where the business intelligence software suite is already predefined. This means that for a regular project the project team is not free to choose from all available tools on the market, but only within the limited frame of what is usually called strategic vendors. In most organizations this means no choice at all. Typically, most organizations limit themselves to one or two strategic BI vendors, whereas every vendor provides a suite of tools and therefore provides a choice to project teams.

Scenario B) takes place when a company is about to choose their strategic BI vendors, or when it is about to define a front-end tool strategy based on a given toolset available. The difference to scenario A) is that there are no concrete requirements or previous use cases to do this. Decisions involving, for example, choosing strategic BI vendors, or building a front end tool strategy usually have to be derived from corporate requirements, which may mean some high-level requirements that are influenced by end users only in an indirect way.

In Scenario A, the main task is to map requirements to concrete features and specify detailed requirements (which take into consideration the chosen features). In scenario B, the main task is to get to know multiple tools and multiple tool suites of different BI vendors and make them comparable in an easy and quick way. For both cases, the authors suggest the visual approach of BI Picture Books as an analogy to a car catalog. In subsequent paragraphs, “end user” is used as a synonym for the party who is in charge of defining requirements for the BI front end tools.

Figure 1 Negotiation based on off-the-shelf softwareAs outlined in the introduction, working with business intelligence software is working with off-the-shelf software nowadays. This means that not all imaginable requirements are allowed anymore. In particular in scenario A) end users cannot have all they want, but their requirements need to be aligned with the available features of a given tool set. Still, the first step is collecting business requirements to compare with the technical features of the standard software. This process can be very frustrating for the business user after s/he has noted his requirements on a blank sheet of paper and tried to picture himself using a solution that fits his needs. The necessary negotiations regarding the technical feasibility are more likely a surrender of the business user’s initial requirements.

Therefore, the question that arises is, how could we show the end user in advance which options are available and therefore feasible as a solution to his requirements? To answer this question, we take a look at the automotive sector again.

Today, modern car manufacturers provide web-based car configurators, where customers can “build” their own car. The customers have to walk through several steps, e.g. choosing the color, the wheels, the engine and accessories. We can learn two things from such car configurators: First, guide the end user defining the necessary (and feasible) requirements. Second, provide visual support to the end user showing what different available options look like.

Structure BI front end requirements

To «build» a BI front end solution we identified seven crucial categories which need to be addressed during the requirements’ engineering process. This corresponds to scenario A above. For scenario B one can still use the same categories, but instead of defining requirements along the lines of these categories you can structure the available features and thus make the comparison of the different tools much easier. The following sections will outline the seven categories in more detail:

  1. Content options: In this first step, end users have to roughly define what information products they want to receive in the end, and the approximate content of these products. (The term information product is an umbrella term for all the various BI front end types such as report, statistics, cockpit, dashboard, analysis etc.). For scenario A end users are relatively free to note down everything they want, except for data content, which is a priori not available in the project time frame. For scenario B, the BI expert might list and compare all the available data connectivity options for a certain toolset.
  2. Navigation and selection options: In this second step, the end users need to think about how to navigate to or between the defined information products (e.g. using a folder structure in a given BI portal). Whereas navigation takes place outside information products, the selecting interactively data usually takes place inside an information product. In either case, the available options are limited by the software.
  3. Layout options: This third step is about collecting requirements regarding page layout, chart and table options. A common pitfall for end users is to assume that BI front ends are either like Microsoft Excel or Word. Trivial looking items such as a table of contents or some specific chart options which are available in Office products might not be available in the BI front end tools. In addition, if the end users’ organization adheres to notation standard rules such as the International Business Communication Standards (IBCS; http://www.ibcs-a.org/) this might further restrict the allowed layout options, in particular for charts and tables.
  4. Functional options: Whereas the third step addressed more of the static elements in a report, this fourth step is about defining requirements for the functions of a BI front end solution (in addition to the functions already defined in the navigation and selection category). Typical examples of functions are the usage of (interactive) alerts, export to various formats, printing, search, multi-language options, commentary features and so on. This category depends even more on the available features of a given BI front end tool than the previous ones.
  5. Delivery options: Step number five addresses how an information product is delivered to end users. Besides defining the delivery channel (e.g. by web browser, mobile, email) one must define how and when the report is refreshed. One possible option is viewing an information product on demand (the refresh is triggered directly by an end user). Scheduling the information product to be run at night is another option. Scheduling can be further divided into single information product scheduling and information product bursting where, based on one main product, a personalized instance of the information product is created and usually distributed to the specific recipient. Requirements for this category’s “delivery options” usually depend not only  on the front end tool itself, but also on the underlying BI platform system or available third party extensions, e.g. for bursting.
  6. Security options: Finally, end users have to think about security. In the context of BI front end solutions, there are two main security aspects to consider: Access restrictions on information product level, on one hand, and data level security, on the other hand. For the first aspect, an end user has to define who and in which role is allowed to see the report, and which features should be available, e.g. one user might access and refresh the report, but must not export the report. Similar to the previous category of delivery options, the access restrictions are highly dependent on the underlying BI platform and the available security options.
    The the second aspect of data level security is either addressed on database level or some kind of semantic layer of the BI front end tool. Again, the available technology decides upon available options.
  7. Qualitative options: Last but not least, this final category of options summarizes requirements of a qualitative nature. This includes elements such performance or usability requirements. For this category, it is more difficult to define requirements allowed. Nevertheless, one can guide the end user in defining realistic requirements, e.g. instead of asking an end user to define the maximum report refresh duration, provide predefined performance classes such as “< 30 sec”, “30 – 60 sec” and so on. This way an end user won’t define an unrealistic value like “every report must be refreshable below 3 seconds”.

Using these seven categories to either structure your end user requirements (scenario A) or structure and therefore compare the available features of multiple tools in an evaluation process (scenario B), you will be able to catch at least 80% of typical BI front end requirements. Depending on the concrete project, you will most probably have to extend the list with your own items. Still, the basic principle of guiding end users whilst defining requirements remains the same.

Another way of structuring the requirements using the seven categories is to outline dependencies. Similar to web based car configurators, there are certain requirements in a given category which have a direct impact on the allowed (or needed) requirements in another category, e.g. defining a delivery channel using mobile devices will most probably have an impact on the desired (or available) layout options, as well as certain security options. In such a case, one needs to cycle back or forwards in the categories and adjust previously defined requirements. In sum, the typical procedure will be to run through the seven categories in an iterative way starting with a rough idea of requirements in the first round and refining requirements (also considering newly discovered dependencies) in subsequent rounds.

However, there is one question left: What does a non-technical user understand by these categories? A simple feature list is usually not enough, in particular for people whose daily business is not building a BI front end solution. The authors suggest building and using a visual catalog of available options, just like the car-configurator. We call this a BI Picture Book. (More about this in part 2)

Issue with Null Filters prior to Webi XI 3.1 SP6.3

After some more “theoretical” blog posts back in 2013 I’d like to start the new year with a short technical contribution. As some of you may know I’m trying to upgrade the BO XI 3.1 SP2.7 environment of one of our major customers to XI 3.1 SP6. This is sort of a painful experience as we are working on it since more than 12 months now. Still, there is some light at the horizon as back in December Fixpack 6.3 was released which contains an important bug fix. Not to mention that the bug wasn’t yet there in SP2.7 but was introduced somewhen between SP3 and SP6. The issue is referenced in the SAP KB1897777 and it seems to be fixed now.

What is our situation? We have Webi reports containing containing multiple queries and merged dimensions. If we use dimensions from two different queries in the same table, variables as well as filters containing “IsNull” functions do not work properly.

Here we are with the report in XI 3.1 SP2.7:


Now the result in SP6 (prior to Fixpack 6.3):


… and finally how it looks like with Fixpack 6.3 applied:


The tricky part was to detect this error (the above screenshots are very simplified tables for debugging purposes). Obviously even our business users didn’t caught this at first sight. Therefore I’m glad if I can contribute that you double check this if you are on a lower version than Fixpack 6.3. On the other hand: Please let me know if you find other (newly introduced) bugs in FP6.3…

And by the way: Happy New Year and lot’s of fun in the Business Intelligence world ;-)


Get every new post delivered to your Inbox.

Join 575 other followers