Recently minted corporate fraud legislation requiring CEOs and CFOs to sign off on the veracity of the numbers contained in their corporate financials has just upped the ante exponentially on the value and accuracy of organizational information. Enterprise business intelligence (BI) initiatives are an ideal way to get a handle on the accuracy and completeness of corporate information – financial and otherwise. However, many of the folks I talk with don't yet have a concrete plan in place for their BI project beyond the "pilot" or proof-of-concept stage. That's a disaster waiting (impatiently) to happen.

Building a pilot BI project is technologically and logistically challenging enough in itself. Rolling the BI system out to the entire organization is a mammoth undertaking, and there are a couple of planning and technological pitfalls that can put any enterprise-wide BI project into a corporate quagmire. However, if you know about – and make plans to avoid – them up front, you can avoid the quagmire and the possible unpleasant consequences that have recently come with it.

Any solid BI project is founded upon well-defined, meaningful key performance indicators (KPIs). These KPIs are the measuring stick of organizational progress toward meeting defined goals and objectives. I might be stating the obvious, but the first step in rolling out a BI system to the entire organization is to make sure that all similar business units are using the same KPIs for performance management. Really, you say? You think?

Like I said, it may sound overly clear, but you'd be surprised at how much miscommunication can occur between similar business units in different locations. For example, the finance unit in the South American group may not – for a variety of very legitimate reasons – use the same calculations as the finance unit of the North American group in compiling financial performance indicators such as EBITDA (earnings before interest, taxes, depreciation and amortization).

It's critical that you know this up-front before the system is built and rolled out to both groups. Accommodations can be made either by adjusting the calculations to a corporate standard or by noting the differences and making the appropriate modifications after the information is calculated.

Either way is up to you, but the old cliché is true: You must compare apples to apples. Otherwise, the term "benchmarking" has no meaning because there is no commonality between KPIs and, thus, no way to adequately compare the performance of different groups. The result is a virtually useless system.

The second major pitfall that I see many organizations barreling toward is the lack of a common BI technical architecture across the organization. I'm not saying that you have to contract with one hardware vendor to provide the same equipment to every intended location for the BI system. However, compatibility of different equipment, platforms and software is a critical issue that must be resolved early in the project in order to ensure a smooth and well-timed system rollout.

Analysis needs and rollout locations will influence much of the technical architecture planning. For example, if your organization wants to coalesce and examine information on a weekly basis, ETL software and technology would be fine. However, if you need daily information, it's important to start defining a comprehensive EAI strategy early to ensure that information can be collected as quickly as daily analysis needs dictate.

Location is also a critical technical architecture determinant. If you have a truly international rollout plan for system use in diverse locations such as New York, Beijing, London, Moscow and Sydney, you'll want to consider a decentralized architecture because your maintenance and extract windows will differ in each of these locations. The middle of the night in New York could be middle of the day in Sydney. The Sydney system can't be bogged down with ill-timed maintenance and extracts. However, as with any decentralized architecture, you must ensure that the information is always synchronized across the locations.

On the other hand, sometimes a centralized technical architecture is more appropriate. If all of your locations are within two or three time zones, or if you plan to utilize shared services for accounting, human resources, etc., a centralized architecture is the better option because there are fewer interfaces to be dealt with, there is less equipment to buy and install, and maintenance costs would be substantially reduced.

Obviously, building an enterprise BI system consists of much more than defining KPIs and building the technical architecture. However, the KPIs and the technical architecture are probably the two most fundamental pieces of any BI system. Resolving any issues with these two critical components up front during the planning stage will go a long way toward ensuring that the information contained in your BI system is timely and – most importantly these days – accurate!

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access