Interactive Bubble Charts – a technical gimmick or an important reporting feature?

The market for business intelligence differentiates 5 styles of BI:
· Reporting
· Advanced Analysis & Ad hoc Reporting
· OLAP Analysis
· Scorecards & Dashboards
· Alerting & Proactive notification
While reporting, the classic discipline of BI, i.e. predefined operational reports with perfect layouts and ideal for printing, is widely used in financial services and also the ad hoc analysis, advanced analysis (including data mining) and OLAP reporting is getting more and more popular, dashboards still represent a relatively new discipline in financial services. This has partly to do with the fondness for Excel in the various departments, but is also contributed to the fact that users have not fully grasped the possibilities a dashboard can provide, which a standard report is not capable of.

However, the demand for dashboards is significantly picking up lately!

What are the reasons for this change in perception?

The idea of dashboards followed the study of decision support systems in the 1970s. With the propagation of the web in the late 1990s, the dashboards as we know them today began appearing.

In management information systems, a dashboard is an executive information system user interface that is designed to be easy to read. Dashboards may be laid out to track the flows inherent in the business processes that they monitor. Graphically, users may see the high-level processes and then drill down into lower level data. This level of detail is often buried deep within the corporate enterprise and otherwise unavailable to the senior executives. Dashboards are therefore business driven. Dashboards give a visual representation of performance measures. They give the ability to make more informed decisions based on collected business intelligence and align strategies and organizational goals (e.g. to visualize balanced scorecards).
These are all important factors and business users saw the value dashboards could add and really liked them. Nevertheless they often hesitated to implement them and stick to their two dimensional standard reports.

The financial crisis however made financial institutions rethink their current reporting strategy. Business as usual was just not good enough anymore. In the past the organizations invested heavily in risky financial instruments, always looking for the biggest return, regardless the inherent risk. Now, with the dramatic changes in the economy, financial services institutions are starting to think more strategically. They want to be cost efficient, want to streamline their business processes and are therefore willing to invest in best practices in order to be well positioned for the future.

That also includes dashboards because they come not only with the advantages mentioned above; they offer an additional important benefit: they save time over running multiple reports!

A standard report / grid can provide information in a two dimensional fashion. With OLAP reporting you have the ability to drill down by multiple dimensions but you can still see only a limit amount of information in one screen. With dashboards, this limitation is not longer a problem.

Let us assume a bank wants to get insight into their business segment performance. The key metrics they want to see over time for all their segments are:
· Operating Margin
· Return on Equity (ROE)
· Net Income
In a two-dimensional standard report we would build this as a grid, with periods in the column and the KPIs in the rows. We would then build a filter into this report so that we can select a segment. A comparison of all segments at the same time is not easily possible. We can also not easily identify trends over time, especially if we have more data (multiple segments with lots of periods) to analyze.

Of course we can improve this report by adding sums, variances, and even traffic lights to indicate trends but it is still not intuitive and takes time to consume.

Another option would be to build an OLAP report where the segment is a dimension that we can show on the report. With nesting, i.e. the visualization of multiple dimensions in the rows, we could get more information on the report. But it would be difficult for the business to digest the information and comparisons between segments over time.

Now, if we build the same scenario as an interactive bubble chart into a dashboard, we can easily incorporate all the desired functional at once.

Each bubble represents a different segment (differentiated by its color); its size outlines the net margin of the segment. The position of the bubble in the graph is determined by the x-axis (ROE in %) and the operating margin (in %) on the y-axis. This is easy to understand but it gets even better. With the interactivity of the bubble chart you can see how the size and position of each bubble is changing over time.

This resonates very well with the business users. They save a lot of time they had to spend on finding the information and can instead concentrate on their real job, analyzing the information and making informed decisions based on the findings.

Now, that the business has seen the potential and the wide range of use cases for dashboards they are asking for more. They would like to generate dashboards that incorporate all their relevant information they need to perform their daily business. With well defined dashboards that are concentrating on the information that is really relevant, the answer is simple.

MicroStrategy for example offers for this purpose a dashboard book, i.e. a set of dashboards that are contained in one file, available for distribution (via email or on a mobile devise). The business already loves it.

Release Management in Banking

Organizations buy software to help them solve their business problems. The software comes usually packaged with a maintenance contract which allows the companies to get support when needed and to update to the latest releases of the software.

In general companies are trying to be up to date with the software releases as much as possible in order to utilize new functionality and to get the latest bug fixes. This is especially true for business intelligence software that gives the organization a competitive advantage by delivering invaluable insight into the business. Those companies are therefore pretty open when it comes to install new service packs, hot fixes or patches.

This is different for most of the larger financial services organizations.

I am not talking about mayor releases here, i.e. a totally new version with new functionality, enhancements and maybe a better GUI (Graphical User interface). Those migrations usually need very extensive preparation time but for most software companies these mayor releases only occur every 2-3 years.

Larger banks require even for minor releases or service packs a long preparation phase and intensive testing before an upgrade can be implemented. This has to do with the restrict risk & compliance rules, the sensitivity of the data, the business model of financial institutions and with the fact that banks have often outsourced the IT service handling the migration.

They are installing the software typically in a sandbox environment; test the software thoroughly until the results for all their test scenarios are satisfactory and then they plan the technical steps for the upgrade. Part of the testing on the IT side includes carry out random installations in their machines and test for no compatibility issues with other standard applications at the bank.
This process usually takes 3-4 months.

The duration of the implementation – after the completion of the testing and planning mentioned before – is then dependent on the changes to the software and the internal process. The usual setup includes a development, a test and a production environment and proper procedures to move between those environments. As a rule of thumb such an implementation takes another 2 months. On average a migration to new software versions takes therefore in total ~ 6 months.

While there is software in the market that requires a much longer migration cycle, this is a pretty good estimate for most BI software migrations in financial services organizations.
However, some financial services institutions exceed this time by far and are looking for tools and external support to streamline their processes.

The procedures are especially inefficient when it comes to hotfixes and patches that are supposed to solve immediate issues. In case of a not foreseeable real issue that could be a threat for the daily business even banks are very open to implement patches quickly. This patch still needs to follow certain test procedures in the sandbox but this is much faster (can be done in two days till a week). Nevertheless, the companies try to avoid this as much as possible due to the extensive test scripts.

The required effort also depends on who owns the responsibility for the BI resources. As a rule of thumb, if the BI department is the owner of all the resources, it is usually less problematic and the processes are more promptly. Otherwise you could run into delays since you do not have all the resources at your disposal.

In summary, release management is becoming a very important topic for the financial services industry as it ties up budget, resources for a longer time period. As a consequence, those software vendors that offer a single, integrated tool based on a unified platform architecture – usually those that remained independent without the hassle of product integration issues due to newly acquired software – with a simple migration path for their customer base, will have a huge competitive advantage in the market space.