Q
Manage Learn to apply best practices and optimize your operations.

Design a business intelligence system properly -- for business users

Rick Sherman explains how to avoid common mistakes when planning and designing BI systems, saying that the varying needs of different business users must be front and center.

What are some common mistakes that business intelligence managers and architects make when planning and designing...

a business intelligence system?

BI managers and architects generally do a very good job at the technical aspects of deployments, putting much energy into selecting BI tools and getting the right expertise on their team to build BI applications. But they often make one or more of the following mistakes when they plan and design BI systems:

Talking only to business power users. Every business group has its go-to person when someone needs data for analysis. That person, typically labeled a business power user, knows where the data is, how to get it and how to analyze it. Although such workers are a terrific resource and should be consulted when developing a business intelligence system, the mistake is assuming that they're representative of the rest of the business group.

Most business people don't have the time or inclination to develop dashboards and reports, no matter how easy they are to create. Too often, BI and IT teams concentrate their efforts on the power users, only to get frustrated because so few people actively use the BI system after it's deployed. While power users enjoy using the latest BI tools, the rest of the business community may not be so enamored of them.

Using the waterfall approach to design BI systems. IT and BI managers complain frequently that business users are asking for more than what they requested or forgot to mention something important during the requirements-gathering phase of a BI project. The reality is that BI system design is an iterative and incremental process. Many of the changes that so frustrate the BI team are, ironically, the result of the success they've had in obtaining the right data to be analyzed.

During the requirements phase, business users often ask for a little bit more functionality than what they currently have; then when they see the capabilities of the BI system that is being created, they start to have bigger dreams. But, if you follow a waterfall methodology, you gather the requirements up front and freeze them. The better course is to adopt an Agile development process, using storyboarding and prototyping to actively get the business people involved in the design process. That empowers project teams to develop much more robust and expansive business intelligence systems.

Not profiling new data sources to be used in a BI system. Too many BI teams have been burned when they trusted that the data from a new source system was complete, current, clean and consistent with other data sets. Data silos -- and you have to assume every new data source is a silo -- likely include data anomalies or problems. The best practice is to run data profiling tools on all new source systems to check for data quality issues. "Trust, but verify" should be the operating norm.

Believing self-service BI hype. Product vendors and pundits have been proclaiming for more than a decade that the latest BI tools are so easy to use that business people can develop their own BI applications without any IT involvement. Certainly, each new incarnation of BI technology has made it easier for business users to perform business intelligence functions without relying on IT or BI professionals to laboriously design every query and report they require. However, the disclaimer that should always accompany self-service BI is that business users typically need ongoing support and that the data they work with must be clean and consistent. Those are no small feats, and certainly require IT involvement.

Treating all business users the same. BI managers sometimes assume that one tool will fit all BI uses, and that business people all have the same level of analytical skill and data knowledge. They don't. BI designers and architects need to create a BI portfolio that supports a variety of analytical tools, such as dashboards, reports, OLAP analysis, data discovery, data visualization and, of course, spreadsheets. A single BI suite may provide all the tools your business users need, but in some cases, more than one product may be necessary to gain the best desired ROI.

Treating spreadsheets as the enemy. Spreadsheets remain the number-one BI product on the planet and the only true pervasive BI tool. I'm not suggesting that Excel data shadow systems should be encouraged, but rather. that spreadsheets should be embraced as a valid BI tool. Integrating spreadsheets into your BI portfolio is the best way to expand BI usage throughout an enterprise.

This was last published in June 2014

Dig Deeper on Business intelligence best practices

PRO+

Content

Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Join the conversation

2 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

I would agree that a big issue is the idea that making a big up front investment in data intelligence tools and customizations will be a windfall. In many cases, it's an example of raising a big ladder and climbing it only to realize too late it's standing against the wrong wall. Taking an iterative and moderately adjusting approach would be better overall, but it tends to freak out traditional business people who want to know up front what they are committing to. Additionally, in an iterative and accreting model, more people can get the hang of a system and use it, rather than just the "knighted few" who have been part of the entire long process. 
Cancel
Rick you make some really valid points but the thing that is missing is the people element. Your assumption here is the wider business have the time, want to and have the expertise to contribute to a system design.

For the most part business users are hard to get to usually because of the bad experiences of IT projects in the past.
Cancel

-ADS BY GOOGLE

SearchDataManagement

SearchAWS

SearchContentManagement

SearchCRM

SearchOracle

SearchSAP

SearchSQLServer

SearchSalesforce

Close