Problem solve Get help with specific problems with your technologies, process and projects.

How can we evaluate our methodology for measuring and managing business intelligence?

How can organizations evaluate methodology for measuring and managing business intelligence? Find out why business intelligence must meet these eight tests for a sound methodology.

How do I know if my company has a good methodology in place for measuring and managing business intelligence (BI)?
Any good methodology, whether it is for Business Intelligence, Change Management, Project Management or any other activity is simply a consistent set of standards that are understood by all stakeholders and users. These standards have to embrace both the users needs and the corporations' vision. If those two conditions are met, acceptance generally follows.

Therefore, if a methodology is a set of standards, Business Intelligence (which is a set of technology tools) must meet these eight (8) tests if it is to have a sound methodology.

1.Open standards
The ability of the tool to integrate with other tools and systems is critical. Proprietary systems don't allow for this flexibility. Additionally, what is state of the art today, might be outdated long before you recoup your investment, or in some cases become operational (in a production mode).
2.Mission-focused design
Technology is merely a facilitator for a business problem. Therefore, what business objective the BI tool(s) are addressing must be clearly defined and agreed upon before any selection process can begin.
3.Incremental build
An incremental deployment process to build or implement a system (tool) accomplishes two critical business concerns. First, it will limit the expenditure, and limit the loss of capital, if a modular/component fashion approach is used. Second, this will allow for future expandability and component swapping if a new better "thing" comes along that will address the business question better/faster/cheaper.
4.User Involvement
Build (or buy) it and they will come doesn't work. But how often do those who will be using the system get to make the decision, as opposed to the person who has the authority to spend it. Gathering user requirements, not only will this establish project success criteria, it may also influence what type of tool(s) is (are) selected based on what the user is planning to do with the information.
The system must be intuitive to use. The only way to gather these requirements is from the user community, which will be using the technology. The challenge here is not to "over engineer" the solution.
Anyone can build a "strong" bridge given enough tie and money, but the trick is can you build it "just" strong enough. Scalability and flexibility will equal balance performance. Remember that transaction-processing delays will grow exponential not geometrically as you begin to scale the system upward. In others words, processing delays will grow factor wise by 3,9,27,81, 243 (32,33,34,35) not linearly or 3,6,9,12,15 (3x2, 3x3, 3x4, 3x5). This relies heavily on #3 and 4 above.
Integrate old legacy systems if they contain valuable customer data. Again, this relies on #1 above and #4 for identification of what data is important.
Avoid the philosopher's trap of building an all-encompassing Business Intelligence infrastructure. Instead, use clear models of limited scope to focus and enable specific objectives, customer processes, actions and results to build momentum. Start with finding, summarizing, interpreting and analyzing customer information that will address the most pressing business problem the business is facing. Don't try and "boil the ocean." Start with a teapot first.


Dig Deeper on Business intelligence best practices

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.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.