Once the metadata starts flowing from the analysis, it can be gathered and stored in a metadata repository purpose-built to capture and reuse such information. Neilson says valid values analysis will also harvest more metadata. The CIO can then analyze the valid data by dividing it into two categories: right values and wrong values. This encourages the organization to formulate further business rules delineating which values are right and wrong, which in turn creates even more highly useful metadata.

"But it's all very well focusing on the data; the data is innocent," Neilson points out. "It's the process that causes the problem. Data is just a number that someone has keyed in. It's the processes that surround that that count. Some of the data quality exercises that we have done have revealed errors where people have gone in and fixed the data. You know: their IT people say: 'There's a problem here, we'll write a program to fix the data', and of course they really fix it - well and truly fix it. So that's one source of errors. Now the obvious other source of errors is just plain keying errors - you know, key in someone's birth date: there's almost no check you can do on that except reasonableness checks - it doesn't know whether it's accurate or not."

Neilson offers an example on the important of process. Take a situation where the organization collects data at the beginning of the process where a 10 percent error rate is deemed perfectly acceptable, yet by the time that data progresses through to organization and ends up on a Balanced Scorecard, the manager considers a 10 percent error rate atrocious. What is good enough for the start of the process might not be good enough for the end of the process, Neilson points out.

When yields of processes vary day to day, introducing potential inventory inaccuracies; or when measurements of product attributes, like thicknesses or weights, vary within a normal distribution, and techniques like statistical process control (SPC) are required to determine whether the process is shifting out of control; or when "nervous" schedules - a classic problem in supply chain planning, where small variations in timing or yield create large changes in the proposed schedule - cause uncertainty; when any of these outcomes are possible, Swanton says treating the numbers as fixed constants that can be used in calculations is dangerous, unless the nature of the variability is understood and accounted for.

"Resilient, self-correcting algorithms are necessary to handle noisy data smoothly," Swanton writes. "All data isn't created equally, and can't be simply dumped in a data warehouse and used without understanding its characteristics."

According to Swanton some approaches that will help include the following:

• measure the quality of your data sources to understand the accuracy, coverage and normal variation to be expected

• for factual transaction data, use performance management techniques to improve processes and personnel to raise quality to a very high level; this is the minimum to meet customer satisfaction goals and statutory obligations

• find and characterize other useful data sources; understand that these are different from transactional data and must always be used understanding how the variations from different sources interact to amplify or average out the variations

• investigate the use of simple, self-correcting algorithms for most planning activities; calculating an optimum based on noisy, incomplete data is foolhardy.