Data governance and business process management initiatives are usually kicked off independent of each other, with different objectives, project owners, project teams, and project calendars. The result can be (and often is) a deep, inexplicable, disconnect between your business process and business data.

Reasons for this disconnect are myriad but no mystery.

For one, the genesis of these types of initiatives is often very different. BPM is undertaken when organizations find themselves beset with process shortcomings, and with the primary purpose of better understanding, improving and integrating business processes. Data governance initiatives, on the other hand, are usually justified by shortcomings in data quality, consistency and integrity.

Then, data governance is often closely intertwined with master data management, and thus organized alongside important "master" business data entities -- customer, product, organization and such. (Is this the right approach for data governance? That's a topic for another day.)

A recent report from Forrester Research entitled "Avoid Process Data Headaches" points out that companies are often oblivious to the connection between data quality and process improvement. As a result, most MDM and BPM efforts remain siloed, with limited (if any) collaboration or coordination across the two teams. Also, data strategies sometimes focus much further downstream, around data warehousing and business intelligence, oblivious to the origin of the data -- operational processes like order management, customer service, and procurement that capture all the raw data in the first place.

Most of all, there is often confusion around a key central tenet for data quality: Whose problem is it, anyway? Business, suggests Forrester's report, often believes data quality is an IT issue. This, unfortunately, is true to a good extent: poor data models, application design and development practices (compounded by inadequate testing) are indeed a prime culprit in poor data quality.

That said, Rob Karel, Forrester analyst and lead author of the report, suggests that IT must learn how to better educate and evangelize data issues in a language and a context that matters to the business -- a responsibility that Karel puts squarely on IT, "because IT often has a more cross-enterprise view than siloed business units and functions."

If I ever write a column on "Why IT?" I'd probably put that little nugget right up at the top of the list: "1. Because IT stands at a vantage point with an unparalleled view across the entire enterprise."

However, though IT is certainly better positioned to articulate the data quality issue, some of that onus, I believe, lies on business. Sponsors and beneficiaries of any software application -- which is where data mostly comes into being -- must demand a "quality in, quality out" approach… and then support it.

A trite but very frequent, and no less important, example is, say, the use of free-form fields to enter important qualifying attributes, leading to gaping holes in downstream reporting and analytics -- and subsequently to additional expense and (re)work toward data quality remediation and reference data management. Business users must learn to forgo the short-term convenience (and lower cost) of entering free-form text in favor of, say, selecting from a list or waiting for a value to be validated in real-time -- a responsibility that, to Karel's point, lies on IT to emphasize. Looking at information quality as a service, IT must take on the role of not just service provider but also educator.

Data quality, in fact, lies smack at the intersection of BPM and data governance-- the cross-hairs, if you will, of what Forrester calls "process data governance." The challenge, then, is for us to identify and investigate all such points of intersection. Here's another example: Business subject-area-centric (or entity-centric) process/data flows -- such as customer data flows -- across horizontal and vertical business segments, and through myriad systems dotted across these segments and processes.

For data governance and process governance efforts to be successful, they both must frame their priorities and business value in the context of which business processes they are aiming to improve, transform and optimize, says Karel. Co-author of the report Clay Richardson challenges business process professionals to take more upfront responsibility for understanding and modeling process data relationships -- a "sea change in the BPM world" that requires the BPM team to shift their mindset towards process modeling. Unfortunately, says Richardson, most BPM methodologies out there do not overtly call out data modeling and analyzing the relationship between data and process.

The question to ask is: are your BPM or DG programs looking closely enough at data provisioning and consumption for effective business processes? Just as business process optimization fundamentally depends on sound data (in the right form, time and place), data governance is a non-starter without identifying and analyzing such business processes.