Databases Reference
In-Depth Information
address and contact information that may or may not be consistent. The same
data element name may be used by different applications to capture and
store different data. Perhaps each application uses a different business rule
to determine whether the customer qualifies as a ''premier customer.'' There
may also be duplicate customer data within and/or across applications. To
make matters even more complicated, each application may have a different
subset of customers.
This can create severe problems for an organization. From an operations
perspective, this can result in confusion and duplication of work. The sales
department may contact a customer to offer a product promotion and be told
not to call again until next summer. The next day, with no knowledge of the
previous call, a service representative may call the same person to offer a
discount on preventative maintenance services. Needless to say, that customer
is likely to be annoyed by your company's lack of coordination.
In addition to negatively affecting the company's image, there is a significant
cost associated with maintaining this data in so many places. There is the
base cost for each application to capture the data and store it, and there is
additional cost to get a consolidated view of your customers. Each time you
need a consolidated view of your customers, you need to pull the customer
lists from each system, combine them, eliminate duplicates, and clean them
before any real analysis can be done. Prior to the implementation of a data
warehouse, this is often done on a periodic — perhaps quarterly — basis, in
order to create reports.
The overall objective of master data management is to provide common
reference data to all applications across the enterprise. This means that each
application uses the core customer data as the source of customer information
for its processing and to, in turn, update the customer reference data with new
information learned from business transactions in that system. This provides
a single source for this core data. The business must decide which depart-
ments and/or application systems are allowed to change the master reference
data.
You need a high level of coordination to keep applications from corrupting
reference data needed for different purposes. For example, to support customer
mailings, the marketing department wants to store a preferred first name. This
may be a nickname. However, if that same field is used to validate credit
card information, this will create problems. Often the personal preferences
are different from the legal names used for financial transactions. The way to
address these challenges is to identify the different purposes and store both
versions: the legal first name and the preferred first name.
Figure 8-5 shows how the reference data is shared across applications, while
the transaction data used remains within that application's own database.
