Data Quality Management Systems: Putting Someone in Charge is the Very First Step
Google the phrase, "Data is the new oil," and it returns more than a half a billion responses! In the last decade, data has received increasing attention and with the advent of non-Von Neumann computing architectures (what are often irresponsibly labeled "big data technologies,") organizational data processing capabilities have increased by amazing amounts. Commensurately, the amounts of data that organizations have attempted to manage have also increased rapidly and resulted in the need for quality management systems focused on data.
The Wikipedia entry for "quality management systems" (QMS) describes them as collections of processes focused on achieving quality policies and objectives. With origins at the start of the industrial revolution, QMS focused on delivering predictable outcome from industrial production processes. As the human costs of production increased, QMS broadened to include team focused dynamics such as quality circles. Today, the well-known ISO-9000 standards are the most widely implemented QMS.
Data has always played an integral role in QMS—most aptly summarized in Drucker's widely quoted phase; "you can't manage what you can't measure." While measurement is most correctly described as a "reduction of uncertainty"—it all comes down to data. Data is what is needed to first understands and then improves the quality of organizational processes and management of that data is one of the most important aspects of any QMS.
Unfortunately our educational systems have failed to understand and therefore educate our knowledge workers, managers, and leaders about the key role that is played by organizational data. This has two specific implications. First, data systems need to be considered a part of the engineering discipline and very few IT and organizational managers have (or are given) any background in the engineering concepts required to successfully implement data quality engineering systems. Secondly, data is a unique organizational asset type in that it is our:
• Strategic asset.
No other organizational assets possess these qualities; yet data is far too often treated as a production system. This leads us back to the phrase googled at the top of this piece. Conceptualizing data as oil leads it to be treated as a production function using traditional QMS approaches.
“Data developed as part of an IT project results in increasing numbers of disparate data collections that can be reused only with costly, post-project integration efforts.”
Data does indeed have some production line functional similarities. As shown below, data is captured from various sources. In order to be available for downstream processes, data must be engineered, stored and delivered. These three functions must be governed, especially considering woefully inadequate educational preparation that has left the data storage function the only one that receives any level of professional treatment and is considered to be largely an IT specific responsibility.
The real disconnect for the reality of data in most QMS (and indeed most systems) is the neglect of the reuse application on the far right of the diagram. Unlike most production functions, data is not cultivated for a single use, as it would be inserted into the final product on an assembly line. Instead, to take advantage of data's unique properties, organizational must design data assets to be reused countless times (leveraging) and in an unforeseen variety of combinations in order to deliver business value.
So our organizations are faced with the challenge of employing their data assets as integrated QMS components but they lack the knowledge, skills, and abilities to successfully accomplish this required data leveraging. Further, most data management capabilities are assumed to reside with organizational IT departments, whose backgrounds are also unfortunately deficient in these areas.
IT is additionally hampered by a project mentality. IT enhancements are appropriately managed using project management techniques. Organizational desire to leverage data conflicts with IT projects. Data evolution is separate from, external to, and precedes system development life cycle activities! Simply, data evolves at a different cadence than IT projects. Data developed as part of an IT project results in increasing numbers of disparate data collections that can be reused only with costly, post-project integration efforts.
Organizations wishing to correct this mess must begin at the top and appoint s o m e o n e to managed organizational data assets. While most organizations are calling this function the Chief Data Officer, I prefer to call it the Top Data Job (I've also seen it called the enterprise data executive). There are three characteristics necessary for the success of these individuals. They must:
1. Be dedicated solely to data asset leveraging, focusing on activities that are outside of (and more importantly) upstream from any system development lifecycle activities (SDLC)
2. Report to the business, to the same organizational structure that the CFO and other "top" jobs report into and not to IT; and
3. Not be constrained by an IT project mindset;
The point is—organizations have one individual possessing the knowledge, skills, and abilities to manage various types of resources: chief financial officers, chief medical officers, chief security officers, etc. By the end of this year, Gartner predicts that 25 Percent of Large Global Organizations Will Have Appointed Chief Data Officers. Unless and until organizations appoint someone in charge of their data assets, we cannot hope for improvements in the way we utilize data in our QMS (or any other systems app.