In my work helping clients create their BI application architecture, one area that creates a great deal of uncertainty and confusion is what applications and tools to use. Part of this confusion is brought on by an overwhelming array of choices. Even in the Microsoft “stack” where I specialize, there are many overlaps in BI function between applications.
When I first started with Microsoft BI, I compiled a list of ways to build a dashboard with Microsoft tools. I came up with around 10 different approaches! Should a dashboard be built with BSM? SharePoint KPI lists? Reporting Services? ProClarity Dashboard? In my work with clients I’ve seen many approaches—most creating functional dashboards (with varying levels of extensibility and usability).
An eye-opening analysis I work through with clients is to back up even further and “segment” the user population, then match “BI products” to each segment. It’s a lot like market segmentation in the marketing process, and if BI deliverables are treated like “products”, I’ve found it helps clear up confusion about what “tools” to use to deliver BI.
Different groups of users have different needs. Of course we all know this intuitively, but often with BI implementation it’s forgotten. Many implementations take a “one size fits all” approach. For example, rolling out Reporting Services reports to everyone (even though executives rarely have time to slog through conventional reports). Or, on the other hand, giving scorecards to field staff who really need account or order details at their fingertips to solve tactical problems minute-by-minute.
Most effective BI solutions use an array of products, just as most product and service companies have tiered offerings to meet their customers' varying needs and demands. The following diagram is a tool I use to segment users and target the right products to their needs. Are there other approaches you've found effective?
