The Business Data Steward: A “Kaizen” Approach to MDM
Posted by 
Share this Post
A kaizen approach to MDM can help improve data quality by fostering collaboration
I've been very busy getting to know our new Big Blue colleagues, all 400,000 of them, especially those in IBM's Information Management division. Our new focus on Information OnDemand has me thinking about an IT director at a Midwest-based manufacturer who I talked to at the Gartner MDM Summit. He was responsible for the company's business intelligence initiative, but his program was plagued with discrepancies in reporting.
These issues emanated from data quality problems flowing into the data warehouse, resulting in reports listing customers in the wrong geographic and business categories, compromising financials and projections. The initiative was losing credibility with the executives and line-of-business managers it was meant to inform, and his credibility was going with it.
You may have experienced this, either as the business person who gets the dubious report, or the IT person who must answer for it. This illustrates how disconnected the business is from the IT practice of data management, and vice versa. This disconnect has two results:
1) Data often doesn't reflect the facts known by the people on the ground, eroding businesses faith in the data
2) Because business stakeholders can't directly correct data errors, and feel powerless to prevent them, their only recourse is to reject the whole outcome. This is an extreme choice, given the amount the enterprise invests in data management.
Enabling & Empowering
What if the business side of your organization was enabled to correct those pesky data discrepancies directly, rather than through a help desk request? For starters, it would probably make that help desk job a lot easier, removing a lot of the workload from the DBA responsible for making data changes in the warehouse.
But the real benefit lies in the empowerment and investment business stakeholders would feel around the data management initiative and its supported processes. From the line-of-business perspective, instead of it being "their problem," now it's "our solution."
You've heard the aphorism, "None of us is as smart as all of us." (There's a variation that goes, "None of us is as dumb as all of us", but that's a different blog post.)
It's actually a Japanese proverb, a tenet of "Kaizen," the quality assurance culture and methodology widely adopted in many Japanese manufacturers. Kaizen means "continuous improvement," which sounds desirable, especially when it comes to data quality. But an important aspect of Kaizen is de-centralization: because all stakeholders participate in the process, everyone has some valuable insight into improving the process.
The Role of a Business Data Steward
This is where the "business data steward" enters. From the standpoint of current data management practice in enterprises today, the term is practically an oxymoron. What business does business have in the business of data management, anyway?
Think about it less in terms of disciplines and roles, and more about empowerment and investment. In short, when you think in terms of Kaizen, the idea of business data stewardship starts making sense.
In my next couple posts, I’ll discuss how to apply principles of Kaizen to the process of managing data, and how this approach can make the case for business data stewardship. I'll also lay out some of the challenges to enabling businesses to participate, Kaizen-style, in managing the organization's data assets.
Differing Perspectives
In the meantime, if you're sitting on the business side of your organization, and depend on high-quality data for decision making, think about this:
You can't have it both ways. You can't rail at the factual inaccuracies compromising your sales report, or lament the duplication of records in Salesforce.com, and then refuse to allow the people most knowledgeable and invested in the data feeding those systems to ensure it's accurate and correct. If you're not part of the solution, ensuring the reliability and effectiveness of your organization's data, you're part of the problem.
And if you're an IT guy, think about this:
It's not your day job to know your organization's customers by territory, or revenue. You don't have the visibility into the market, the customer or the products to make those calls. But, people sitting on the other side of your organization do. If you can engage them in the data management process, the net gain will be immense, while reducing costs to you. But you'll have to surrender some control. More importantly, stop thinking of the business side of your organization as a constituency to be served; rather, they’re an asset that can be leveraged to meet broader goals.
What do you think?
Ian's next post, Empowering the Business Data Steward: Don't Cut the Cord!, covers this in more detail.
7 Responses »
Trackbacks
- Tweets that mention The Business Data Steward: A “Kaizen” Approach to MDM | Mastering Data Management -- Topsy.com
- Tweets that mention The Business Data Steward: A “Kaizen” Approach to MDM | Mastering Data Management -- Topsy.com
Leave a Response
Entries(RSS)
Interesting post Ian, keen to say where you take this series.
One of the interesting comments I often get when discussing stewardship surrounds funding and reporting. Most stewardship roles generally sit across natural divisions of departments, information chains, business departments etc. and I think this is why a lot of companies struggle with setting up stewardship frameworks - Who do they report to? How should they be incentivised? What responsibilities will they have?
Really keen to see where you go with this as you're hitting on a lot of topic areas here that come up a lot from our members.
Excellent article, Ian.
It is good to see the concept of Quality Assurance at last being talked about when addressing data quality. The Japanese have become masters of Quality Assurance and their example should be followed by all.
Quality Assurance is all about getting things, right first time, every time, i.e. zero defects!
The paradox contained in your article is that, if you are practicing Quality Assurance then you would never need a Data Steward. The need for this role has arisen because businesses are NOT getting it right first time, every time - many are not getting not right first time anytime! - and are creating huge volumes of defective data. They now need someone to lead the fight to find these errors and put them right across the business - a Data Steward!
Bad data quality is not a problem it is a symptom! The real problem lies in the execution of the Business Functions and in the design of the automated systems built to execute these Functions. It is in executing Business Functions that all data is created or transformed. It is here that all data errors are created.
The real question is, do businesses want to:
a) Continue creating data errors but become really good at finding and rectifying them?
b) Stop creating data errors?
Are they into Quality Control (finding and rectifying defects) or Quality Assurance (creating Zero defects)?
Many businesses confuse "continuous improvement" with "continuous defect rectification". In Japanese companies it means removing the cause of defects at source across an ever larger part of the business and then outside of the business, upstream to customers and suppliers.
Japanese companies can be sure that all products they receive from their suppliers are defect free and that all information/data that they receive from them is 100% fit for purpose.
Data Stewards will have a role to play while enterprises move to Data Quality Assurance but, if they are to be successful, there objective must be to make their role redundant.
Again, great article. Look forward to seeing the next installment.
Regards
John
I have listed the Five Fundamental Rules of Data Quality Assurance here.
Ian,
Interesting concepts. I am a big fan of Demming and TQM. I see a lot of potential for "Eastern approaches" to help improve Data Governance practices. Like Dylan, I will be watching with interest where you go with this.
John added excellent comments, with which I agree.
Looking forward to remainder of series,
Ken
Hey Dylan. I think your point is well-taken. Moreover, given that the day-to-day operational control of data management and data quality has traditionally been centralized in IT, where it's costs can be contained and accounted, how are you supposed to account for participation by different lines-of-business?
Of course, it's difficult to overcome the inertia represented by the "traditional" way of doing things. But maybe a first step in getting to this Kaizen approach is a recognition on the part of line-of-business stakeholders that, when it comes to the quality of their organization's data, they're as much a part of the solution as part of the problem (or is it the other way around). They are the subject-matter-experts, after all, right.
So if, rather than being just a passive observer (or victim) of the issues manifest in their operational data, if business users could do something about those issues, maybe in real-time, while doing their day jobs, would they? This is a question the folks here at Initiate will be wrestling with over the next couple of months. More on that in my next post...
Ian,
Excellent post and comments - I fully agree with the 'right first time' ethos. I also agree that people need to mentally separate the system that automates a process from the data used by the system. It is still too easy for disgruntled employees to blame others (e.g. IT) for not sorting out data problems during a system upgrade/implementation. There is not enough awareness that, in many cases, data will long outlast the system that stores it.
One suggestion you make in your post is to allow users to correct data errors, however this needs to be handled with caution. I have come across situations where well intentioned users have corrupted data structures due to incorrect understanding. I have also come across 'flip-flop' data - which is typically subjective data where two users cannot agree what the correct value is and it keeps getting changed between two values. This could be the classification of a customer by market sector where two different territories are reflecting different capabilities in their territories. Flip-flop data can be an indication that standards for classification may need to be updated.
For the reasons above, I would generally prefer there to be an easy help desk type approach to correcting data errors, unless suitable safeguards can be built in to user created changes.
Julian