Some Hidden “Gotchas” of BI and Analytics

Featured Article by Bernard Wehbe, Managing Partner, StatSlice Systems (www.statslice.com)

“Why didn’t we think of that earlier…?” It can happen in anything you do.  If you’ve ever had a house built, it doesn’t take long to realize you would have done some things differently—especially after living in it a few years. There are probably endless important gotchas that if avoided, could help you reach the planned business objectives in your BI projects.  Here are just a few to think about.

Data Security Not Adequately Considered

Because the purpose of a data warehouse that feeds your BI platform is reporting, analysis and data integration, security is usually NOT a focus when systems are designed.  Data security gotchas are not always readily identifiable in an analytics project. Take privacy information for example, you may think that you do not have to worry about that for your analytics since most analytics are aggregate data; however, when you dig deeper you may discover that your analytics software capabilities allow users to drill down enough to glean private information from aggregate data.  The analytics system has to be properly secured from an access perspective but also from a functional perspective.  You have to make sure that sensitive data does not fall into the wrong hands.  This is not always an easy task and must be considered and designed properly up-front to insure that you are meeting security requirements.

Mobile BI Is Not In the Plan, but Everyone Wants It

This is really a subset of the overall data security issue.  But it is compounded by the fact that now your important dashboards and visualization of company-critical information are floating around anywhere—and can be viewed, stolen or lost.  Until a very solid data security, privacy, and ethics systems is in place—be careful.

Security concerns are still among the chief barriers to deploying BI and analytics on mobile devices.  Depending on your environment, this could be a big gotcha.

KPIs and Business Objectives Not Clearly Established

Today’s corporate culture is bombarded with conflicting goals and overwhelmed with meeting market challenges and demands.  This often reflects on analytics projects as poorly defined business objectives or worst a business that is not sure about its Key Performance Indicators (KPIs).  KPIs are at the heart of an analytics system because if management is not clear about what they are measuring it will lead to confusion and losses.  It is important to avoid this pitfall by having a champion on your team that is fighting to keep your KPIs clear and aligned with your business objectives.  Otherwise you end up with a failed analytics system. KPIs can also be helpful in avoiding another nasty gotcha—scope creep—that can easily happen when the end goals are not clearly defined.

Overly Aggressive Schedule Concerns

The project has been approved.  Everyone is excited. The world is about to become a better place.  All the right players are lined up.  The problem: someone, somehow, somewhere approved a project schedule that is really tight.  Overly ambitious target setting is one of the biggest reasons for projects failing.  If a project continues to miss key dates, funding can be at risk. Morale drops as overtime efforts build up and no end is in sight.  The reasons for schedule challenges can be hard to estimate, understand and anticipate.  If you are presented with a deadline that has you concerned, try to get everyone together and think things through a bit more in depth.  Everyone is anxious to get started—but sit back for a day or two and review the plan.  Look at key milestones that are dependent on other milestones that you can’t control.  It’s not fun going through objectives and milestones with a microscope, but it can avoid many problems down the line.  If you project is complicated, with a lot of dependencies, the possibility of a big gotcha is high.

No Real Prototyping

One thing that could also help the scheduling is the concept of prototyping.  BI designers and developers do not generally build prototypes, modify them as users review them, and then develop into the finish product. Many tend to create something rather blindly, hoping it is right based on what they knew at the time, and build in a big chunk of time at the end for re-work and re-design.  Obviously this can be problematic with budgets and tight deadlines.

This is BI remember, so everything is further complicated by the fact that there is often a communication breakdown between the business users wanting the solutions and the developers/designers who are delivering on their wants.  You hear gut-wrenching stories about projects going to the user for acceptance testing, and it’s then it’s found out what the real or desired objectives should have been all along.  If the “miss” is big enough, it affects everything—database design, data movement, data quality, reports, dashboards, costs and more.  Remove the gotcha here by doing some prototyping and user acceptance before you go too far down the road to production.  Bring in outside consultants to help if needed—they can help bridge the gaps in an objective manner.

Bernard Wehbe has over fourteen years of consulting experience focused exclusively on data warehousing and business intelligence. His experience includes data warehousing architecture, OLAP, data modeling, ETL, reporting, business analysis, team leadership, and project management. His business systems expertise is very broad-based and he is in high demand for his consulting expertise. Prior to founding StatSlice, Bernard served as a Technical Architect for Hitachi Consulting and The Sabre Group in the Dallas, TX area.  Mr. Wehbe received a Bachelor of Science as well as a Master of Science in Industrial Engineering & Management from Oklahoma State University.

For More Information

For more information about StatSlice Systems products and services, call (214) 206-9290 or email us at info@statslice.com.  Please visit us at http://www.statslice.com