Best Practice Common Practice?

A week or so ago the heat pump for my domestic water tank gave up. When I phoned to report the issue one of the first questions was whether there was stop cocks on the inlet and outlet pipes because this is best practice for installation, especially if they have to remove the unit for repairs. Imagine if the guys that installed this, failed to follow best practice.

So we recently had a debacle here at the office with regards to software solution that was implemented that we had some issues connecting to and integrating this with the de facto reporting system. Upon investigating the issue we found that the vendor did not follow Best Practice.

This started me thinking, what is BI best practice and how many BI professional are aware of best practices and do they actually follow these guidelines and/or rules?

So what is best practice? According to Wikipedia it is commercial or professional procedure that are accepted as being correct or the most effective. I noticed a researcher at an Oz university looking for research subjects on knowledge transfer when experienced IT professionals retire. One way to do this would be by defining best practices.

I can understand that people are in a rush to implement solutions and gone is the days where it took 2-3 years to implement a BI solution. Rushing to implement a solution and then not having the anticipated success doesn't improve business’ opinion of IT in general and more specifically BI.

Best practices will enable you to implement a robust solution that will stand the test of time. There may be reasons to NOT follow best practice but they’d better be VERY good reasons. Here are some best practices to think about for BI in general:

• Determine your reason for implementing BI and state the business need in no uncertain terms. Do not just get it because everyone’s got it, you’re afraid you’ll miss out on something or it’s the next big thing. (You will miss out in today’s competitive business world if you don’t have a BI solution that will answer your business problems and provide you with a competitive edgeJ.)
• First define BI and Data Architecture that fits into your organization and then get the BI and Data tool that fits into your BI and Data architecture.
• Design a robust scalable solution that will enable your BI environment to grow with the business and be adaptable to changes in the business environment.
• Adopt a lean approach to data integration and governance. Do not try to fix the data as part of the ETL. The ETL process can only fix a certain portion of the data quality, rather fix the problems where they occur and include some indicators specifically for data quality in your reporting.
• “Business”, the name says it all. Talk to business, hear what their needs and issues are, and get them involved in defining requirements. This is all about helping business solve their problems and making better business decisions. If users are involved in the design and specification, it is highly likely that they will also use the resulting information.
• Be agile. A BI project should be part of a bigger BI project and each BI project should be broken down into the smallest components possible and add additional components in an iterative process.
• Design a Data Model solution based on a business process, do not design for a specific report.
• Keep your Data Model designs as simplistic as possible, it makes it easier for the ETL and report design and for users to understand.

There’s a great story of a manager of a Coca-cola plant who’s numbers were far better than his peers. When asked what his “secret” was, he said simply that rather than take a best practice and modify it to meet what the plant did, he instead modified the plant to match the best practice. His secret was not trying to be too clever.

In a next post I will look at best practices for ETL, reports, dashboards and other BI components.