Better collaboration can occur when users stop blaming the IT guy

Jim Harris recently blogged about The Road of Collaboration, making a case for the business and technology sides of a company to come together and walk the middle road towards greater collaboration. Although this joining of forces would be an optimal scenario, overcoming the fundamental prejudices that some non-technical people have against their technical counterparts makes it difficult to walk hand-in-hand.

When things go wrong on a project, as they inevitably do during development, testing, or – spotting Murphy's Law here – at some point in production, the first place most business users look to troubleshoot is within the technology. This theme is lampooned in another of Harris’ articles, the Pirates of the Computer: The Curse of the Poor Data Quality in which bad data quality gets blamed on the system, the process, and seldom on the user.

And why should it?  After all, everything worked fine the day before and now it doesn't.  Something outside of human error must have failed and this "something" naturally relates back to the hardware, the software, or some inconsistent gremlin that slipped into the servers to wreak havoc. Trouble tickets are opened, the IT support staff is called, and the resource-intense analysis that lasts for hours (or maybe even days) commences.

We all logically know that the technology is sometimes the cause, and sometimes it's not. We know that problems can and do come from where we least expect it or – heaven forbid – may even be due to us and our own fat fingers.

But even when knowing this, the first person users blame is the IT guy, or, barring that, the software application, which is really the same thing. Remarkably, this scenario occurs even when IT has minimal input into a product other than hardware support, such as a “buy versus build” solution where the vendor’s product is the real culprit of data issue.

So we must ask: why does the IT guy get scapegoated for these errors, guilty until proven innocent?  Regardless of the real cause behind bad data, this process takes up time on both sides of the fence, causes frustration against "broken software" and "inept users," and leads to animosity that shoves collaboration out the window.

There are workarounds to this, but it's not easy. For starters, we probably need to understand why the IT guy gets the blame. Although there are many factors, two of the main sources seem to be Fear of the Unknown and Mistrust of Technology.

We talk about fear of computers (cyberphobia), which is really just fear of the unknown. Although not as common as in the past, it is particularly prevalent for those who are not familiar with computers and loathe the advancement of computers in society that shifts the way "things have always been done."

We all know someone who is reluctant to adopt new systems. New only complicates things, and people who are not comfortable with changing their old habits will reflexively jump at the first sign of trouble.  To them, the culprit must be the new technology.

Similar to a fear of the unknown is a Mistrust of Technology in general. With news about viruses, constant hotfixes, and the overall chaos surrounding rushed product rollouts, it's no wonder that computer systems get a bad rap.

This is not completely unjustified. In a 2008 article on IT systems failure , software failures were cited as the number one reliability issue in an organization, followed by network failures, performance degradation and the failure of physical components.

All systems have the potential to collapse, seemingly without warning, so it's no wonder that the first place people point their fingers is the IT department.

With these factors in mind, organizational teams may be able to take some action. For example, to mitigate the fear of the unknown, users should be encouraged to become familiar with their software of choice through training, tutoring, online forums, and even one-on-one mentoring.

Overcoming the prejudice of unreliable technology is a bit more difficult, especially when users believe they have the hard evidence to back up these prejudices. The goal is to prevent finger-pointing so communications channels between the users and the IT staff should be maintained before escalation truly begins.

Sometimes the problem is a quick fix and that having an on-site dialogue can save frustration well in advance.

By turning our focus against the task at hand rather than blaming the IT guy, we increase the level of patience, open-mindedness, problem-solving and flexibility within a team. This can go a long way towards walking the road of successful enterprise collaboration and ridding the IT department of the curse that haunts them at every network failure.

MDM and Data Governance can help a medical team collaborate

Lately, the concept of Collaborative Care is gaining a lot of attention and innovation. Collaborative Care means that providers, clinicians, counselors, payers, pharmacies, regulators, care-givers, state/federal agencies, employers and plans will work together for the benefit of patients.

This is a patient-centric model, not a provider-centric or a payer-centric model. No, all these entities will work together for better preventative care, being paid on performance of the prevention and treatment, not on the treatment(s).

This is a significant change, but not a radical change. If pressed, each participant will declare that they’re in this to help prevent disease and treat people.

So what’s different? Well, it’s not dissimilar to what we’ve seen in other industries – everyone is propelled by their own “profit” motives. Yes, even non-profit organizations need to operate efficiently and effectively, and achieve better outcomes. So they are all motivated to super-optimize for themselves and their own private ecosystems.

Now, we’re asking all of them to work together for a common goal, even when it means sub-optimizing from their own perspective. Not only will these disparate organizations have to work better together – “better” meaning in a more timely manner, using electronic data (not paper forms, folders and faxes), but they will have to work to achieve new standards of prevention and quality outcomes.

This means overcoming the fragmentation that exists within and across legal entities, and ensuring that the information needed is available when and where needed, with a level of quality and authority needed to complete the task at hand.

Regardless of whether this is fraud detection and prevention, treating a chronic condition exacerbated by multiple drug interactions, or trying to improve the living conditions of at-risk Medicaid or Medicare patients, MDM and data governance can make the job easier.

So, how do MDM and data governance apply to this kind of smarter planet application? Well, it should be obvious, but let me lay it out here.

MDM to the Rescue

MDM can help in areas where we need to uniquely identify a patient, a caregiver, the providers who have treated them in the past, their insurance plan(s), their employment status, their health history and other related questions. The situation may call for understanding their past prescriptions, looking for drug interactions and if patients have followed prescribed treatment regimens. You may even look for fraud and abuse if there are restricted drugs/narcotics involved.

In some cases where minors are involved you may need to understand their living situation (a child living in a rat-infested apartment will have a higher propensity for certain illnesses, conditions & diseases), their guardians, any involvement with social services, household members who have had troubles with drugs, law enforcement, etc.

You would need to know which providers have seen, diagnosed, advised, treated and/or cared for the patient. You may need, in some cases, to investigate their medical history. You might need to know which providers work within which Integrated Delivery Networks, or within which practices, or in association with which hospitals.

You may also need to check the providers’ own licensing and certifications within the jurisdictions in which they have practiced medicine. You might also want to know their “success rates” and “satisfaction ratings” given by patients (this is not done that much – yet).

It’s easy to see that MDM is critical in understanding who the patients are and the people they are associated with. It’s critical to understand the providers who have treated them. It’s critical to understand who their insurance carriers are.  The use cases go on and on and on, but hopefully these spark your thinking.

One thing I expect people to struggle with is in “crossing the privacy line,” which leads us to the role of Data Governance.

Data Governance to the Rescue

As you read through the types of data above, you might have had red flags going off left and right – well, I certainly did! What do you mean someone is going to ask about my driver’s license! Who gives someone the right to ask about what prescriptions I’ve filled? Isn’t this an invasion of privacy? How DARE you!

Well, these are all issues of policy, and when I say “policy” it immediately makes me think of Data Governance!

I’ll tackle this more in my next blog post. Should be juicy!

But in the meantime, a couple things to think about:

Is it okay to look into someone's living situation when a minor is involved?

Or to look into "sealed" parts of a patient's history when knowing their medical past could impact their necessary treatment?

The Andon Cord empowers employees to make meaningful changes in data quality process and practice

In my last post, I talked about applying principles of Kaizen or "continuous improvement" to the enterprise's practice of master data management. The post has elicited a number of insightful comments. I appreciate you who have taken time to read and respond, especially those of you with expertise in the science of quality assurance in manufacturing.

I did some additional research around the history of Kaizen and its applications in modern manufacturing. I also looked at Kaizen applications in software, a sector where quality assurance is, frankly, not as well developed as it should be (a subject for another post).

In my research, I ran across this March podcast from This American Life. The subject was NUMMI, or "New United Motor Manufacturing, Inc." a joint venture between General Motors and Toyota, based in Fremont, CA in the 80s. The goal was that GM would learn Toyota's production system, which yielded high quality, low cost cars, and pass it on to other GM manufacturing facilities.

But it didn't work out. Why not? The answer lies in two simple words: "The Cord."

In the podcast, one of the workers talks about how, in the training they received in Japan, they had a cord, the "Andon Cord," that ran along production line like the bell cord on a bus. Any worker who identified a quality issue could pull the cord, and the production line would stop until workers and managers identified the quality problem, and took steps to remediate not just the issue but also the source.

Later, when the production system was transplanted to GM manufacturing facilities, managers at these plants, afraid of upsetting production flow and quotas, would cut the cord, or disable the system that stopped the production line. Quality in these plants did not improve.

But in backing away from the production system they were supposed to be implementing, these plant managers did more than lose sight of their quality goals. Line workers came to feel personally disenfranchised by the way the system was being sabotaged. And, eventually, since they weren't given the tools needed to improve quality, they didn't feel any ownership over the quality of their results, either.

As I said in my last post, the biggest wins from adopting a Kaizen approach to MDM don’t come from improvements in data quality (although that's a big deal, and a big part of what you can measure, in undertaking a Kaizen approach.)

The win is the sense of empowerment and investment the business stakeholders feel around the quality of the data they're producing.

By enabling these stakeholders to act on the data quality issues they see in front of them, and encouraging them to do so, they may come to see themselves as part of the solution. When an auto worker in the podcast talks about how this enablement changed his life, he means it.

What is the analog of the "Andon Cord" in data management processes? I've found some examples in MDM technologies we're working on right now and will talk about some in my next post. Do you have any cases you can cite?

All these "Cords" have something in common. They're not some "extra thing" the business data steward must do above and beyond their job. To the degree it's possible, they're embedded in the operational processes (and even applications) that the business users are working with, day-in-and-day-out. (Oh, and did I mention they're easy to use?)

Finally, I want to emphasize a point made by John Owens. It's easy to poke fun at GM, and their management (especially given the bankruptcy and government bailouts). But in fairness, they were only responding to the incentives they were provided.

If those incentives emphasize quantity over quality, the managers, like anybody else, will focus their activities and resources accordingly. If you're going to incorporate business data stewardship as a component of your data management practice, you'll need to do more than provide better tools. (Take it from me: I make data stewardship tools for a living.) You'll need to provide the incentives to use those tools to improve data quality. More on that later, too.

Happy Blogiversary to Mastering Data Management!

Initiate’s blog, covering topics from Master Data Management and Data Governance to Entity Resolution and Interoperable Health has grown leaps and bounds since it was launched on August 25, 2009.

Thank you to everyone who has read or commented on one or many of the posts! We have grown from a small team of bloggers – some of whom were skeptical about the “blogging thing” – to a team of more than 20 from across the company.

Some of our most popular posts have been series, and anything related to MDM, data governance and data quality seems to pique your interest.

Our top 10 posts of our first year, by number of views:

Series: Building an MDM Roadmap – Larry Dubov’s recent series proved wildly popular, and addressed the components of a successful MDM strategy.

But before you can build a roadmap, you have to build the business case. Larry’s early 2010 series, Building a Business Case for MDM, discussed justifying the business case to secure crucial executive commitment and buy-in.

Series: Building an HIE Through International Standards – Bill Klaver’s spring 2010 series walked through all the pieces that work together in a health information exchange, from privacy and registries to repositories  and PIX/PDQ.

Are We There Yet? Results of the Data Governance Survey – Marty Moseley revealed the surprising results of a recent survey that assessed the data governance maturity of nearly 100 organizations.

The Value of Data – Marty mused on how organizations value data, and how these mindsets have evolved.

What ARE “Master Data?” – A third Marty post in the top 10, this popular post explained the differences between reference data, master data, transactional data and audit data, which kicked off a great conversation in the comments.

The Relationship Between MDM and Data Governance – This post stemmed from a Twitter conversation that @GarnieBolling started and Jim Harris of @OCDQBlog ran with. Marty pondered which came first, and how the two must coexist.

Estimating the Benefits of MDM – As part of his Business Case series, Larry’s post on how to estimate the actual benefits of MDM drew a lot of traffic.

Traditional Methods for Estimating Business Benefits of MDM – The very next week, Larry’s post on the traditional “bottom-up” approach to estimating MDM’s benefits to business again proved popular.

Data Governance Policies and Metrics for Data Quality – Larry’s January post discussed the importance of defining data quality metrics while starting a data governance program.

What has your favorite post or topic been? What do you hope to see more of in the next year? We always appreciate your feedback! Thanks for your support and continued readership!

Marty came away from the MMIS Conference with lots of questions about how HIEs are moving forward

Well, I just got back from the Medicaid MMIS conference (Medicaid Management Information Systems) and have some thoughts rolling around in my head.

As providers, payers and federal & state agencies grapple with the Affordable Care Act, Meaningful Use, Collaborative Care, Patient 360 and the Medical Home, conferences like this are quite valuable. It seems that everyone is very interested in health information exchanges (HIEs).

There’s a ton of discussion on legislation such as the 2009 American Recovery & Redevelopment Act (ARRA), and the related Health Information Technology for Economic and Clinical Health (HITECH) act. (These are only two of about 750,000 TLAs (three-letter acronymns) and ETLAs (extended TLAs) and LETLAs (longer ETLAs) I heard during this conference. There are more than you can count!)

I was encouraged to hear the driving passion behind improving healthcare and preventing disease. But right behind those driving passions are a slew of questions I mention below.

The content at the conference was good, with many presentations made by Centers for Medicare and Medicaid Services (CMS) staff directly, and the audiences seemed quite dialed in. However the content was mostly “status reports.” Presenters explained, “This is where we are today, this is how this legislation is progressing and this is how this TLA impacts this ETLA,” etc.

I’d hoped to see more reports of, “This is what we’ve done to implement that standard, and here’s what we learned along the way.” This is understandable, because state representatives and big payers at the show are all wrestling with similar questions (see below) and there just aren’t that many answers yet.

See, the dust is just now settling on the CMS Medicaid Information Technology Architecture (MITA) and how it relates to myriad other government standards/regulations.

So, the questions I heard (in no particular order of frequency or priority):

• How do we (state agencies) get started with MITA?
• How do we learn from early adopters, and have any other states actually succeeded at this yet?
• What do we do first, second, third, etc.?
• What is mandatory that we do now, vs later?
• Collaborative Care sounds great, and moving to better forms of prevention, care-giving and payments sounds like utopia, but how in the world will we ever get our providers to change, when they’re already under pressure to deliver better outcomes with less risk and lower costs?
• How will Accountable Care Organizations (ACOs) and The Medical Home change how our providers and payers work? Are they ready? Who goes first?
• As a payer, how will we survive and continue to add value while driving down costs and increasing efficiencies and quality?
• How will providers really comprehend, much less conform to, HIT’s Meaningful Use policy, and how can we ensure we’re implementing technologies and practices to avoid penalties and benefit from incentives?
• When will we be held accountable for which parts of HITECH, MITA, <add in a list of others here>?
• What will the penalties really be for non-compliance?
• I like the idea of a state-wide HIE and a National Health Information Network (NHIN), but how do we get funding to start our journey?

Well, where there’s chaos, there’s profit, and I expect us to see individual citizens, providers, payers, government agencies, and others benefit as we work through this massive move towards better care for our most vulnerable citizens. Stay tuned…

Did you attend MMIS? What was your perception? Are there other questions you would ask?

Determining how to weigh and measure each of these data quality metrics is important to building a successful data governance program

In the past couple weeks, we’ve examined the importance of establishing data quality metrics for your MDM program and dug into the details of Uniqueness, Completeness, Latency and Consistency. Now, let’s review the remaining categories.

Standardization and Validation

A number of attributes can be considered to define standardization and validation rules. These attributes include address, phone, email, SSN, driver's license number, passport number, etc. Standardization refers to the proper format of an attribute, while validation focuses on verifying that the given value points to an existing address, phone, etc.

In this category, you can track the percent of non-standard or invalid attribute values.

Availability

Availability can be expressed in terms of the number of business users of the MDM hub and the number of applications from which the data in the MDM hub can be accessed. Another aspect of availability can be measured in terms of the hub’s downtime.

User Adoption

The number of search API or web service calls from business applications to the data hub and the number of users that initiated these calls can be used to measure user adoption of the data hub.

Reference Data, Code Semantics Reconciliation and Relationships

Reference data, referential integrity and code semantics reconciliation are important from two perspectives:

• To infer relationships between master entities. For example, if a relationship between individual entity and organization entity defines employment relationships, the quality of employment attributes can be critical to determine the relationship.
• Distinct value lists, codes and their cross-system translations are critical to support the integrity of transactions and correctness of analytical queries

The number of violations in these two categories is an important metric that can be defined by data governance.

Other Considerations

The metrics I’ve discussed are a good starting point for a data governance organization that is looking to establish data quality policies for master data and better define their policies and controls. Both of these tasks are critical to begin data governance operations as an LOB.

At the same time, you should also consider building a data governance dashboard. A dashboard is a critical tool that can slice and dice your data quality metrics (by system, time, department, etc). The dashboard should also be able to perform a "what if" analysis to estimate the impact of planned data quality improvement efforts.

For example, the dashboard should be able to estimate how an improvement in data completeness on a certain attribute will impact your metrics. This will help the data governance organization streamline data quality improvement activities, optimize resources and maximize the ROI.

For more tips on the role of data quality metrics in MDM and data governance, read my recent series, How MDM Helps Data Quality and Governance, or two posts from my colleague Marty Moseley, Measuring What Matters and Measuring What Makes the Business Tick.

Listen to the webinar recording and hear a real-world example of how an HIE is using a provider registry

Our July 28 webinar, The Value of a Provider Registry in Health Information Exchange, was a great success. Pat Pope, Provider Relations Coordinator with Carespark, teamed up with our Lorraine Fernandes, VP and Healthcare Industry Ambassador, to discuss how provider registries can make a difference in a real-world HIE.

A provider registry creates a unified view of a clinician across disparate sources to enable effective information sharing including results routing, secure messaging (such as referrals), user authentication, public health alerts, billing, fraud detection and meaningful use payments. (For more on provider registries, see our Intro to Provider Management page.)

Pat and Lorraine discussed:

• What the diverse market demands for a provider registry mean for an HIE
• How a “hub” of clinician information provides value for licensing and interstate exchange
• The importance of supporting evolving information sharing needs including clinical, reimbursements, fraud detection, authentication and credentialing
• How a provider registry can help meet meaningful use requirements and promote sustainability for the HIE
• Why a flexible, scalable HIE architecture is required to support evolving NHIN requirements

After the presentation, Lorraine and Pat fielded several questions submitted via the webinar chat. The questions were excellent and helped bring up several new points and examples, including:

• Classifying case managers as providers in accountable care organizations
• Leveraging a provider registry to detect and prevent fraud
• The financial impact of a provider registry, including the role of delivery fees and costs per enrollee – Pat shared some great numbers
• Integrating a provider registry with outside organizations and national databases through HL7 queries, provider calls and other methods
• Working with regional extension centers and Medicare and Medicaid databases
• Coordinating data between state and local /regional HIEs, and how to avoid duplicating efforts
• Maintaining the quality of care across facilities

This webinar is less than an hour and definitely worth your time. Watch the replay now, on demand, and leave any additional questions below.

Demand for provider registries grows as organizations promote data sharing initiatives

I’m packing my bags for Melbourne to attend HIC2010, Australia’s biggest health informatics conference, which will take place August 24-26. This will be my third time speaking at HIC. It’s one of my favorites, as it always delivers great networking, timely topics, and of course, a good glass of shiraz.

This year’s theme, Informing the Business of Healthcare, is especially timely as organizations around the world are working to improve healthcare while operating as a business. Provider registries can help deliver the metrics that power informatics initiatives.

Provider registries help uniquely and consistently identify care providers, including physicians, nurses, pharmacists and others in the care delivery team, and can be deployed on a local, regional or state/provincial basis. Global data sharing initiatives demand accurate provider identification, as accurate data can help find inefficiencies and improve care.

Provider data today tends to sit in silos without a single “source of truth,” resulting in poor data quality and tremendous inefficiencies. Duplicate work processes not only create inefficiencies, they also create inconsistent and time delayed provider data.

Accurate identification of the provider is important to coordinating care, sharing clinical results with appropriate and authorized providers, quality reporting, and payment. Accurate provider identification at the point of origin helps improve data quality in all downstream systems, helping deliver accurate data for disease surveillance, health planning, research and analytics.

Deploying a provider registry solution requires considerable flexibility due to the rigidity of legacy provider data sources. Credentialing and licensing files can be particularly vexing when exporting, even in a batch mode.

However, the end goal of a single “point of truth” for provider data and populating downstream systems with accurate data for analytics, research, and payment makes the effort worthwhile.  Additionally, clinical data can be routed almost instantaneously to the appropriate parties based on accurate and real-time provider identification.

Global efforts advancing data sharing will drive even greater adoption of provider registry solutions, and organizations will reap the rewards in terms of improve efficiencies and better patient care.

Join me next week at HIC2010 to hear more. I’ll be speaking on Thursday, August 26 at 1:45 PM in Concurrent Session 15. You can also stop by the IBM Smarter Healthcare Booth #29 during exhibit hours to see a demo and speak with us about your goals.

Establish data quality metrics that measure uniqueness, completeness, latency and consistency

Last week, I discussed some of the requirements for establishing data quality metrics for your MDM program. Now, let’s define each of the most common categories.

Uniqueness

Two types of uniqueness metrics should be considered for MDM projects.

Uniqueness in the source systems can be defined as the ratio of the number of “golden records” to the number of records in the source linked to the corresponding "golden records."

Uniqueness in the data hub is measured in terms of the level of confidence (tolerance) expressed through the probabilities of false positive and false negative matches. These characteristics can be evaluated based on the ROC (Receiver Operating Characteristics) curve techniques that can help evaluate the confidence level for false positives (e.g. 0.01%, false negatives, e.g. 3%). These methods can also be used to quantify the impacts of issues and specific data quality improvements

An additional metric associated with the level of tolerance to false negatives and false positives is the width of the clerical review area, expressed in terms of the number data stewardship tasks. Lower rates for false positive and false negative matches may require a higher number of data stewardship tasks that are to be resolved manually.

Completeness

MDM data hub matching engines can score two records to measure their similarity. The same mechanism can be used when a record is self-scored. In this case, the score characterizes record completeness from the entity resolution and matching perspectives.

Average self-score and 10% quintile can be used as the default measures of data completeness and utilized by the data governance organization to monitor record completeness of large data sets. The data governance organization can establish a policy threshold for record completeness. Then the number of records below the completeness threshold becomes a completeness metrics.

Latency

MDM data hubs typically store the timestamps of changes in the source systems and the time when each of the changes hit the data hub.

You can use several metrics, including average delay, 5% quintile, or the number or percent of records with latency above a threshold set by your policy.

The latency thresholds may depend on the source system. For instance, it is expected that latency for new systems can be near real time while the latency thresholds for legacy systems can be minutes, hours or even days.

Cross-source Consistency with the Data Hub

Typically an MDM program establishes a data hub as the enterprise benchmark for the enterprise client/party data, product data, other master entities and relationships between master entities. Therefore it is critical to develop a set of metrics that characterize to what extent the source systems are consistent with the data hub. Cross-source consistency metrics are discussed in a couple recent blog posts:

A New Approach: Information Theory Applied to Data Quality for MDM

Quantifying Data Quality with Information Theory

Do you agree with these assertions, or do you define things differently? Next week, we’ll dig into the remaining categories of data quality metrics, including the differences between standardization and validation, availability, user adoption and reference data.

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.