Data Quality is a Business Issue: Getting Back to Basics, Part 2

Originally published July 22, 2010

In Part 1 of this article, we identified a prevalent problem among many of today’s top businesses – IT’s inability to correct data or prevent data quality issues at their source; and we addressed some common data quality issues and how to correct them. In this conclusion of the two-part series, we will look at another set of at-risk organizations and how business leadership awareness can correct and stop the problems at their source.

Procurement / Buyers

Similar to the sales organization, the procurement organization is another business department responsible for introducing and perpetuating data quality issues. In working with vendors, it is very common to find multiple descriptions for a single part, product, customer or item within their respective vendor, item and/or master lists. One A&D customer had identified 15 different descriptions for the product “Oxygen Generator.” The primary risk was that only a few of the product descriptions properly identified this product as a hazardous material.

Root causes for procurement data quality issues typically include, but are not limited to:
  • Lack of policies or standards on how procurement personnel enter vendor and product information
  • Unlimited access by all procurement personnel to add or change information
  • Lack of quality assurance processes and policies in place to audit the consistency and accuracy of information before being committed to enterprise systems
  • Lack of system restrictions on what information may be entered into procurement systems
  • Lack of policies or practices to consistently correct data
For leadership, most front-office data quality issues introduced by procurement or a buyer’s organization can be resolved by focusing on revising how people work and the processes they need to follow in doing their work. Specific improvement opportunities areas may include:
  • Establishing a core set of policies and practices related to how vendor product information is entered, audited and corrected within business systems
  • Creating a procurement specialist role that is responsible for managing and maintaining the integrity of vendor information within the procurement system(s)
  • Aligning procurement roles and responsibilities with their ability to enter or update information
  • Revising ERP/SCM procurement screen fields to better align with how information is captured (e.g., if part numbers can only be numeric, do not offer the end-user the ability to enter alpha characters)
  • Extending quality assurance to monitor and support the entry of new/revised vendor information for consistency and quality
  • Consolidating multiple procurement systems and business processes that were introduced by silo business units or were obtained through business acquisitions

Engineering / Product Development

The primary source for internally originated data quality issues can be found within your engineering or product development organizations. Data quality issues are usually the root cause for leadership frustrations when businesses are unable to shorten time to market, manage to increasingly stringent regulatory controls, or manage products over long periods of time (e.g., aircraft, heavy machinery, etc). The sources for leadership frustrations around data quality include:
  • Separate or new relationships with vendors from the sales and procurement organizations
  • Inconsistent change management processes for modifying or developing new products
  • Same component used across multiple products, but each product line has a unique identifier or specification for that component
In addition to leadership’s day-to-day operational frustrations, there is also a continuous frustration from executives that the same challenges are perpetuated in every new product development lifecycle. As businesses move to address this frustration through product development lifecycle (PDL) initiatives, data quality and integrity issues become quickly apparent. It is common for very large organizations to have hundreds, if not thousands of tools that are used to design and maintain their products.

The primary challenge is that these tools were not designed to interoperate or share information with each other or with enterprise applications (e.g., ERP, SCM). Therefore, leadership is reliant on manual processes and controls to transfer product information from development to manufacturing, and dependent on their quality control groups to provide the feedback where data, processes and controls fail to meet business needs.

Since this problem is significantly more complicated, businesses need to create an interim and long-term strategy to address these challenges. Interim solutions will start to refine business processes; update organizational roles, responsibilities and communication; and document how information flows through the various product development applications.

In contrast, long-term solutions may introduce PLM concepts like product data management (PDM). In some instances, PDM represents an overall consolidation, streamlining and automation of the product development application landscape. The level of impact, organizational change and capital investment varies but can be the equivalent to those experienced during the initial deployments of enterprise ERP and SCM applications.

Quality / Risk Assurance

Depending upon your industry and size, you may have a quality or risk assurance (QA) organization. This organization is typically responsible for making sure your company delivers high quality products and works across the enterprise to resolve the issues and address the risks associated with poor quality or services. The QA team is typically a small group of corporate veterans who have experience working across all of the organizations of your business and have trusted relationships with the organizational leadership and subject-matter experts (SMEs).

This type of organization is the cornerstone for the business to address enterprise data quality and integrity issues, and can be the primary business partner to the IT organization. IT cannot be successful in addressing data quality by itself over the long term. However, the QA organization can assist IT by guiding business leadership to:
  • Establish data quality priorities
  • Define data quality/integrity key performance indicators (KPIs) that measure and define success
  • Recommend business owners and stewards (i.e., day-to-day operations) of key data sets
  • Identify data subject-matter experts (i.e., business analyst) who can identify data quality issues as well define data correction requirements
  • Evaluate business operational processes and procedures
  • Assist IT in analyzing data for defects and issues across the enterprise
  • Define business rules for the routing, management, correction and cleansing of master data
  • Implement the automated processes and controls to manage and monitor data quality compliance
  • Advocate for organizational change management, business process re-engineering and technology investments

Summary

Business leadership can leverage or create a business QA organization to act on their behalf to identify, document and recommend changes to the business to eliminate data quality issues at their source. Likewise, the QA group can be the business partner to the IT organization to address data quality priorities, issues, ownership and investments since IT can only facilitate the introduction or refinement of technologies to support data quality standards. IT cannot directly correct “bad” data nor can IT prevent poor business data from entering into the various enterprise systems.

  • Craig IzydorCraig Izydor
    Craig is a director within the Aerospace & Defense industry group at Hitachi Consulting and has over 20 years of information technology experience. His consulting and advisory experiences span BearingPoint, KPMG Consulting and the Aerospace Corporation. Craig assists clients to rationalize, develop and execute information architecture strategies to support business transformation initiatives by defining and implementing the team organization, governance, processes, architectures and technologies. He holds a master’s of science in computer from California State University and a bachelor’s degree in computer science and engineering from Milwaukee School of Engineering. He can be reached at cizydor@hitachiconsulting.com.

Recent articles by Craig Izydor



 

Comments

Want to post a comment? Login or become a member today!

Be the first to comment!