Part 3: Determining Your Usage Profile

Previously, we talked about how to determine your user personas.

Once you understand why your organization needs a business intelligence solution and who your primary personas are, the next step is understanding how your users will need to access and use data to meet the goals of the use case.

Here are the critical assessment factors for determining the usage methods:

Ad-hoc vs Static Reports

In order to determine whether you need ad-hoc or static reports, ask yourself or your team, “How often will report needs change?” or “How well-defined are my use cases?” If the scope of the use case is very limited or very well-defined, and the expectation is that the scope of the use case will change very rarely, your usage profile requires static reports.

For example, a financial statement is a static report. A balance sheet and income statement are well-defined reports, backed up by Generally Acceptable Accounting Principles (GAAP). The format is not going to change very often and the corporate values that contribute to the report are pretty static.

However, most use cases are not as well-defined. In many cases, users don’t know what they need. (And why would they? They’ve never used a BI tool.) Generally, what users think they need initially will be different from what they need once the user better understands what data is available from the BI solution. This results in a change of needs on a case-by-case basis. This type of usage would be helpful for helpdesk users, who need to pull user tickets and gather data on a case-by-case basis.

It’s impossible to write all of your usage cases down up front, before you have used a BI tool. Therefore, you need an agile solution for this use case that provides ad-hoc report building. We’ll cover this in greater detail in part 2 of this guide, but categorize your use case into either an ad-hoc or static report requirement for now.

Time Sensitivity

How time sensitive is the data you will be pulling? In order for the data to meet the needs of the use case, does it need to be pulled in real-time or near real-time (i.e. not more than 24 hours old)? Or is the use case need for historical data? The answer could be all three. This is an important factor because many BI solutions do not provide real-time data, but rather report on an archived or cached set of data.

In our helpdesk example above, it would not be helpful for the sales team to have a report of tickets by potential customers if the report is one week, or even one day, old. The team would be calling customers today and would need to know if a ticket was opened today.

There are also cases where real-time data is not needed. For example, examining the number of fulfilled sales orders per territory during the past two years wouldn’t require real-time data. In fact, including the real-time information in this report could weaken the data quality of the report by including recent sales order that could potentially be cancelled and not fulfilled in the report results.

Security

Security needs are also important to consider. While it could be very useful to give a use case stakeholder access to data, you must consider potential security threats. These threats can range from no security impact to imagining the bad PR you’ll get when all your customer credit card and PIN information is leaked. Compliance and industry regulatory standards also fall under security concerns. You wouldn’t want to expose any data that would violate governmental regulations. For all other situations, generally limiting users to only what they need to know would be a smart idea.

Report Formatting

This may not be the first factor you consider, but how important are the formats in which your reports are delivered? Formatting becomes important if data is going out to customers or the public, or if the reports need to be formatted according to your company’s brand guidelines. Additionally, if reports will be given to company executives, the reports should be well-polished. If any of these are likely, report formatting should be something you consider.
On the other hand, if the reports will primarily be used internally, the formality of the report appearance is not as important. You will see later, in part 2 of this guide, that this impacts price and vendor selection, so it’s important to know this information now.

Access

How will users access the report? Will it be only in the office on their desktop or will mobile access be needed? Do they need offline access with the ability to review cached data even when not connected to the network? While it’s easy to say “we want to be able to access reports from any device and anywhere,” taking this approach may cause you to buy software that costs too much and requires more complexity than you need. If mobile access is not needed, set it as a “nice to have” feature but for the specific use case you’re solving indicate that it does not need it.

Outputs

What type of outputs are needed? This section would be the most similar to the traditional RFP process. Based on the use cases above there are specific outputs and technical things needed. Try to be as specific as possible and as mentioned above keep it to exactly what the use case needs (not what you may need in the future for a different use case). In part 2 of this guide we provide a list of functional requirements to help guide your thinking in this area but here are some major categories of outputs to consider now:

• Dashboards
• Charts and Graphs
• Spreadsheets
• Web Accessible
• Embedded Reports
• Printed Forms
• Scheduled Attachments (note which formats are needed)
• Program integration formats (XML, JSON)

In the next chapter, we will talk about determining your data profile.