Considerations of Framework Manager Packages: Key is know the end users

This article describes techniques and options to consider when designing Framework Manager packages, beyond the documented durable model best practices, for maximum usability and user adoption. Key to these techniques is to know the end users: how they approach getting the data and how they will use the data.

Dashboards should provide quick access to the relevant information that a User needs. We need to determine how to communicate the quantitative business data effectively in the form of graphs, consolidated and arranged on a single screen so that it can be monitored at a glance.

High level durable model best practice refresh – 3 Layer example:

1. Architecting the Data Layer (also called the Physical or Database Layer) is mostly determined by the underlying data warehouse structure, with occasional role playing dimensions.

2.   The Model Layer (also called Working or Business Layer) is mostly determined by the general business relationships between data warehouse tables. Adding the business rules that make sense for the query subject like combining data layer query subjects, adding filters, etc.

3.    The Business or Presentation layer is the final packaging of the model layer groupings into the namespaces and packages that the users use in the adhoc reporting.

The sweet spot to really achieve high user adoption is in the architecture of the model layer and business/presentation layer to the user’s techniques and usage of the data based on tools they use. For example, a user may be extremely comfortable with Excel. Creating reports using pivot tables when data out of Cognos may need to be merged with outside sources is not Excel process friendly: unmerge cells to fill in the empty cell values with the field. Can be time consuming for the end user and eventually may reject the solution. Suggestion: create the report using a List object so that the user comes to Cognos to get as much data as possible, but then has the flexibility to export to excel and merge with other critical non-data warehouse data. (At least until the critical non-data warehouse makes it into the data warehouse.)

Key questions to ask users with FM design options for maximum usability:

1.      What type of tools will be used?

There are specific features of each Studio tool that should be considered when designing a package/cube.

2.      How would you create a report using this package?

We use an iterative approach to delivering to the customer, which allows time to really study how users get data. One example, a package has a relative time dimension hierarchy (for cube). Built a report with the user, customer driving, and found that how they wanted to build the report with the package design didn’t fit their needs. Added two additional dimensions: one for year and one for month. This way the package had more options: both relative time in a hierarchy and the year/month separate dimensions.

3.      How and what tool do you use to build calculations?

Each Cognos Suite of tools works slightly differently when it comes to calculations; some are more flexible than others. Preference is to build repeatable calculations within the model and allow the measure items to still be available for future, adhoc calculations. One consideration is to role-play facts within the Data Layer and create different query subjects for each within the Model Layer and ultimately measure folder based on the subject area for the facts and calculations.

To achieve higher adoption, sit with the end users and study how they write reports, and then incorporate the feedback into the design of the package using the myriad of options available within Cognos Framework Manager. I always learn something new with how users think through to develop of reports.

- all the best