![]()
CHAPTER 1:
THE NEED FOR DATA GOVERNANCE
Today, most executives and business workers realize that their success is increasingly tied to the quality of their information. Companies rely on data to make significant decisions that can affect customer service, regulatory compliance, the supply chain and many other areas. As your company collects more and more data about customers, products, suppliers, transactions and billing, it becomes more difficult to accurately maintain that information without a centralized approach and a team devoted to the data management mission.
Companies usually find themselves in need of data governance as a remedy for growing pains. In fact, analysts like Gartner Research and Forrester agree that there is a data governance maturation process (maturity model) that describes a company’s evolutionary process with regard to data governance. A company can evolve though stages. The first stages starts with the wild, wild west of data management where everyone makes their own rules and owns their own data. In stage one there is no cohesive plan for data, nor is there anyone particularly responsible for managing data.
Eventually, the company runs into difficulties and this forces it to evolve through a maturation process, eventually finishing in a governed data management atmosphere where business users and technologists form a cross-functional team that collaborates on data management. At its height, the most evolved companies will have support from executive management and the entire company to define reusable processes for data governance and a center of excellence is formed around it.
But before a company can get to a more evolved data management strategy, it’s important to look at how most companies get into a data management crisis – what leads a company to need to consider data governance?
Sins of the past
To really understand why your company is in need of data governance, you have to go back to the beginning. You have to go back to the time when your company was just starting out. You have to remember when you, as a company, were full of hope and your new idea was just so innovative and needed in the marketplace. Your product was your main focus. Database systems and applications added certain efficiencies that fostered your growth.
Slowly, your company began to build customers. The customers may have been from your local area at first, but slowly the circle began to grow – first locally, then regionally, then nationwide, then worldwide. Life is good when your market share grows as the world opens up for business.
The challenges in growing so quickly never seemed to be with the IT system, but were more about how to meet demand of product, how to expand markets, and how to acquire companies to speed growth. Rarely does a small- to medium-sized company give thought about the day that they will become a Fortune 500 company, at least not from a systems perspective. It doesn’t often consider the data challenges of becoming a large company either; it’s usually cheaper and easier to fix an immediate problem with glue and duct tape than it is to think about it strategically. Management and employees alike encouraged technologists to implement the quick fixes that kept the wheels running and shied away from replacing the wheels while the vehicle was speeding down the motorway.
What may have started as a small regional manufacturing company expanded into a worldwide manufacturing company with sales offices all over North and South America, Europe, Asia, the Pacific Rim and the Middle East. For managing data, each of the divisions formulated processes that made sense for them and met their own needs. The data management needs of the corporation were not available and/or not communicated and therefore took a backseat to the immediate needs of the business unit. If your company was clairvoyant enough to have a data management vision, and almost no small- or medium-sized company does, the rate of expansion and divisional structure that your company set up made it difficult to meet those needs.
Data silos formed. Rather than a structure that talks to reuse of data across the company, each business unit developed their own strategies for managing data. Each business unit hired their own data management resources – some who preferred to use Microsoft® SQL Server®, some who were Oracle® proficient, and some who liked to manage data on the mainframe in DB2®, to name just a few. The processes for maintaining clean data were just as diverse; after all, the definition of “clean data” varied from business unit to business unit. Data from the European sales division could look quite different from the data from the North American manufacturing business unit.
As data anomalies arose, some business units decided to address issues by writing their own code to fix data management problems. Whether the ad hoc solution was code within a database application, within a unique data management tool or as a custom application, the chasm of incongruent data continued to widen. The ad hoc code was designed to fix the business unit’s problems, not address the needs of the enterprise.
As your company grew, there may have been acquisitions and mergers. These are good for growth, but bad for the complexity of enterprise systems and corporate processes. More and more incongruent data made its way into your systems with absolutely no foresight into the data needs of the enterprise.
This brings us to where most companies that are looking at data governance are today – silos of incongruent and disparate data with very little interaction between them.
Where are the metrics?
After this rapid growth and acquisition period, at some point someone important, usually an officer of the company, begins to ask some simple questions like:
• How many widgets did we sell last month worldwide?
• How many widgets are in inventory?
• Who is our best customer?
• Is all of our business profitable? What business/product is most profitable?
These are just the simple questions, all of them requiring clean, accurate data from across the entire company to answer accurately. However, with so much data in so many systems, it’s extremely difficult to find the answers. On top of the sheer number of data sources, this rapid data growth and natural complexity has led to vision-blocking factors that interfere with gaining intelligence about your company. These factors might include:
• Lack of standards – People may have the best intentions, but the organization has not set up worldwide standards for data. Instead, the divisions enter data in a self-serving manner, entering only what’s important to them.
• Typos and duplicates – As people enter data into your systems, they make mistakes. They transpose characters, type data into the wrong fields, and duplicate data, making it difficult to match up the same items from different systems.
• Platforms – Enterprise platforms may be diverse across your organization to include SAP®, Oracle/Siebel®, Tibco® or SalesForce®. When you grew, you acquired companies that used different enterprise applications and now those applications have to share data in order for you to get the information you need. The business units also made decisions on platforms that were inconsistent, making decisions solely about their own needs.
• Language – As you grew, the global divisions used their own languages in the systems. This is troublesome especially for manufacturing. What exists in one system as “carrot” exists in another as the Dutch “biet” or even the Chinese
making it very difficult to determine how many carrots you use worldwide.
• Competing information quality processes – Seeing the need for better data, individuals within divisions may choose to fix the data with their own data quality processes. However, the needs of the entire enterprise are rarely considered, and other divisions in the company may have their own ideas about what constitutes proper information quality.
• Code pages – Data may exist in different code pages. You may have heard of terms like ASCII, Unicode, and EBCDIC. Each of these code pages has a different way to represent the letter “a” for example. These are usually tied to the platforms like Windows®, Unix and mainframe platforms, or may be a factor of the region of the world in which the data originated. Reconciliation of the data in different code pages is necessary for database consolidation or even just getting metrics out of the systems.
• Data age and reliability – Data may be too old to be reliable, but it’s hard to know without a deep look. Unfortunately, the employee that understood COBOL copybooks retired long ago.
• Unknown data – No one knows what the data is, or if it’s relevant. The data may be an important customer list from an acquisition, but anyone who knows that left your company six months ago.
All of these factors block your company from knowing the very basics of your business. You can’t go to one source to find the information you need to know.
Unnecessary complexity
To solve this problem, a common practice for companies is to hire analysts to sort it all out. These analysts generally come from the finest business schools in the world, spending many years in school learning about business and earning an MBA degree, and they don’t come cheap.
The analysts will access the various systems, generate reports, and spend time trying to reconcile one system to the other. Given the complexity of the systems, the reports are never real-time – it takes time to pull reports and cross-check them over multiple systems.
Analysts may work to manually collect data and do primary analysis via Microsoft Excel® spreadsheets. However, maintaining a process so that results are consistent day to day and month to month is a challenge. If the analyst moves to another job, the new analyst may have different methods, and data consistency and process documentation are significant risk points to the company.
Even if the analyst has done their job, the reports may be fairly reliable, but conflicting data may force a judgment call – not a decision based on solid data. Finally, ...
