Creating a data quality team requires gathering people with an unusual mix of business, technology and diplomatic skills. It's even difficult to agree on a job title. In Rybeck's department, they're called "data analysts", but titles at other companies include "data quality control supervisor", "data coordinator" or "data quality manager".

At Emerson, data analysts in each business unit review data and correct errors before it's put into the operational systems. They also research customer relationships, locations and corporate hierarchies; train overseas workers to fix data in their native languages; and serve as the main contact with the data administrator and database architect for new requirements and bug fixes.

The analysts have their work cut out for them. Bringing together customer records from the 75 business units yielded a 75 percent duplication rate, misspellings and fields with incorrect or missing data.

"Most of the divisions would have sworn they had great processes and standards and place," Rybeck says. "But when you show them they entered the customer name 17 different ways, or someone had entered, 'Loading dock open 8:00-4:00' into the address field, they realize it's not as clean as they thought."

Although the data steward may report to IT, it's not a job for someone steeped in technical knowledge. Yet it's not right for a businessperson who's a technophobe, either.

What you need is someone who's familiar with both disciplines. Data stewards should have business knowledge because they need to make frequent judgment calls. Indeed, judgment is a big part of the data steward's job - including the ability to determine where you don't need 100 percent perfection.

Data stewards also need to be politically astute, diplomatic and good at conflict resolution - in part because the environment isn't always friendly.

There are many political traps, as well. Take the issue of defining "customer address". If data comes from a variety of sources, you're likely to get different types of coding schemes, some of which overlap. "Everyone thinks theirs is the best approach, and you need someone to facilitate," says Robert Seiner, president and principal of KIK Consulting & Educational Services in Pittsburgh.

People may also argue about how data should be produced, he says. Should field representatives enter it from their laptops? Or should it first be independently checked for quality? Should it be uploaded hourly or weekly? If you have to deal with issues like that and "you're argumentative and confrontational, that would indicate you're not an appropriate steward", Seiner says.

Most of all, data stewards need to understand that data quality is a journey, not a destination. "It's not a one-shot deal - it's ongoing," Rybeck says. "You can't quit after the first task."

SIDEBAR: When Good Data Goes Bad

IT professionals are increasingly instituting processes and procedures to ease the task of maintaining high-quality data. Some of the most effective ideas include the following:

Build in change management rules. A centralized enterprise system allows all users to contribute to the database. However, not all enterprise data should be blindly updated, and not all users are careful about their changes. As a result, IT professionals should establish submission and review processes that let them filter which user changes are saved to the centralized repository.

Increasingly, "data stewards" - users tasked with maintaining data quality - are establishing change management rules by which they can discern good changes from bad ones. User changes to data are routed to the data steward in the form of a "ticket"; the data steward can then evaluate the ticket to determine whether to accept the modification. For instance, if a low-level CRM user changes the corporate name of the company's top customer, this should serve as a red flag to the data steward to double-check this edit prior to accepting the change.

Without a submittal and review process, the only way to prevent end users from directly updating the central database is to lock certain fields. Two significant problems can result. First, end users become frustrated when they aren't able to make changes that they need and that they know should be made to contact information. Second, those managing the central database miss out on getting update information from those end users in the best position to know that information has changed.

Establish workflow processes. If change management rules are instituted, workflow processes should also be thought through so as not to bog down the data steward with unimportant change requests. For instance, some changes are less prone to error and therefore less suspect - such as changes to e-mail address information. A data steward might establish a rule enabling such changes to be saved immediately to the centralized repository. Other changes, such as those to company names and titles, are critical and might be rejected pending verification of the change. The workflow process should empower the data steward to take appropriate action and move on to the next change ticket.

Categorize and prioritize data. The frequency and quantity of changes to data that occur within an enterprise system are staggering. Even with rules and processes in place to manage modifications, a data steward could still be easily overwhelmed with change tickets.

To prevent this, companies must have a system to categorize and prioritize which changes warrant the oversight of the data steward and which don't. Not all changes should be submitted to a data steward for processing. Depending on the importance of the data and the type of change, it's perfectly acceptable to allow certain changes to be completed and to perform the data quality review later and en masse.

For instance, in a CRM system, changes made to contacts at a company's top customers have much greater effect on the organization than changes to contacts of noncustomer vendors. Also, changes made by certain trusted users may not need to be reviewed by a data steward.