Continue in 2 seconds

Standardizing DSS

Published
  • September 01 1998, 1:00am EDT

Selecting a decision support tool that is appropriate for your company and users is never easy. The good news is that there is a plethora of powerful tools on the market. The bad news is that few of them do all the things that your users require. Case in point: a large regional retail bank with a 200+GB data warehouse is in the process of replacing an underpowered, overly complex query/reporting tool that has exasperated its base of 200 users, about half of which are power users. The bank, which has a centralized organizational structure and culture, would like to standardize on a single decision support tool so that individual departments are not tempted to purchase their own tools. The bank would like to select a tool that is powerful and flexible enough to satisfy all types of users in every department.

In going through the process of identifying and selecting an appropriate decision support tool, the bank has learned several lessons.

The first lesson is that it is impossible to standardize on a single decision support tool. Why?

A) The bank's business environment is too fluid, having acquired more than two dozen financial institutions in the past 15 years. The acquired companies are wedded to their existing decision support tools and reluctant to make changes, especially when the tools are delivering substantial business value.

B) Financial applications that provide the appropriate business functionality often embed decision support tools that can't easily be swapped out. Thus, when business users select a new application, the bank often inherits a new decision support platform. For example, various departments in the bank have already begun purchasing decision support tools to support applications such as budgeting, performance reporting, customer relationship management, etc.

Consequently, the bank has been encouraged to standardize on three types of tools:

* A relational OLAP (ROLAP) tool for queries that need to run directly against the data warehouse.

* A lightweight transformation and loading tool for departments that absolutely need to extract data from the warehouse and load it into a platform-specific data mart. Ideally, the tool should be able to load both relational and multidimensional databases.

* A data mart query/analysis tool. If the data mart uses a relational database, then the selected ROLAP tool (above) should suffice. The bank should also standardize on a single multidimensional product, such as Arbor Essbase or Oracle Express, since these tools often support specific application packages.

Other lessons the bank learned were:

1) Few tools provide robust reporting and analysis capabilities on an enterprise scale. Although there are desktop tools that offer query, reporting and analysis modules, the bank requires an industrial-strength tool. This tool needs to perform ad hoc queries (including drill down, "slice-and-dice" operations) against a large Oracle database, yet generate the sophisticated month-end management reports required by the bank. Most relational OLAP tools provide iterative analysis against large relational databases, but rely on Excel or a third-party tool for reporting. Conversely, most reporting tools do not have sophisticated enough ad hoc query capabilities to support iterative analysis.

2) Users do not want a suite of tools; they want an integrated tool that supports querying, reporting and OLAP. The bank's users do not want to learn two different tools--one for reporting and another for iterative analysis (or OLAP). They prefer a single toolset that lets them slice, dice, drill down, as well as create complex, formatted reports.

3) Few tools provide deep integration with Excel. Since most of the bank's users know how to use and prefer Excel, the bank would love to use Excel as its front end to the data warehouse. Most tools only export to Excel.

4) Few decision support tools, even OLAP tools, support basic financial calculations, such as weighted averages.

5) Most tools sacrifice performance for scalability. Only Herculean tuning and maintenance efforts can ensure decent response times to anticipated queries in an enterprise environment.

6) All tools look great in on-site demos! Only on-site prototyping can expose the strengths and weaknesses of prospective tools.

7) On a positive note, most tools support a report repository that shows users what reports are available to them (given security permissions). Most tools also let users schedule the execution of reports and distribute the reports through various channels (i.e., the Web, e-mail, etc.). Thus, a single tool can often support power users (who create the reports) and casual users (who consume the reports).

Fortunately, the bank has found a ROLAP tool from a start-up company with significant experience in the financial services that seems to meet most of its requirements. The bank is now putting the tool through its paces in an on-site prototyping session. The bank will ask the vendor to build its most complex reports using the bank's data warehouse, as well as let certain users build ad hoc reports through an Excel interface.

If all goes well, the bank will be at least one-third of its way toward "standardizing" on decision support products.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access