TRILLIUM SOFTWARE INSIGHTS

Data Quality Check ups - Treating Data Quality like your Health

By Bernie LeCuyer, Sr. Vice President, Global Services, Harte-Hanks Trillium Software

It occurred to me the other day, when I was eating a slice of my daughter’s birthday cake, that I have an appointment next month for my annual check-up with my doctor. “Better lay off the sweets” was my next thought, followed by, “I better spend an extra 30 minutes on the bike tomorrow.”

The next day, as I was cranking down an imaginary road on the stationary bike, I thought about the effort many people put into ensuring we maintain good health, and how we work to improve it. However the same is not true as often in the business world with respect to ‘data health’ and the attention it receives from those responsible.

Maintaining the health of your data is akin to oral health. Your dentist provides a check of your oral health and fixes any problems (hopefully…ouch!) before they become serious.  The same must be done to a company’s data. Regular check-ups ensure data quality issues don’t become the norm, and also provide the organization with assurance the data remains fit for purpose. In an ideal world, monitoring data quality and providing regular data quality reports help with this process, but in my experience, few companies are achieving this today on any reasonable scale.

Therefore it is a must to have the discipline to perform a data quality audit at least twice annually on any operational data that is providing significant financial leverage to your company. Utilizing a good data discovery tool makes this process painless (no pun intended…well, maybe a little). More importantly though, make sure you take action on the findings of the audit in accordance of your corporate data management policies, and actually review the data on the back end to ensure the data meets corporate goals for being ‘fit for the business’ task at hand.

I spoke with an IT manager at a prospect company just the other day who told me his business stakeholders couldn’t understand why they had so many data quality issues, especially since IT had implemented a data quality process years ago. This manager indicated they had a mature process for correcting the exceptions from the data quality tool and wanted to know what else they (meaning IT or the business) should do. Now I didn’t have enough information to answer this question, so I asked if they had audited the data recently and mapped the results to the business use of the data.  I assumed the audit report would provide some insight into where to begin looking for trouble.

After the initial finger pointing stopped, it was clear no one knew who should have been responsible for the data review. And, it was also clear that nobody had ever actually looked at the data, only the exceptions report from the data quality process. Ah, now we know the cause of the health problems, not just the symptoms.  A regular in-depth data quality checkup would have greatly benefited this organization just like it benefits our health.

No data management review policies in place? Well I’m afraid that’s a discussion topic for another time, kind of like why it’s important to eat your vegetables or else risk health problems later. For now, begin by evaluating the quality of your most important data several times a year, and fix as much as you can, as well as the source of the problem, so the issue doesn’t continue to manifest itself. Just like a dentist, fill the cavity, but then tell the patient to brush all the way in the back, and of course, lay off the sweets.

When worlds collide – Business Process Management meets Data Quality Management

By Ed Wrazen, Vice President, Product Marketing, Harte-Hanks Trillium Software

I’m intrigued to see increasing discussions in media forums and blogs on the role of data in a business process and visa-versa.  It seems obvious to me that if you feed bad data into a business process, than that process could fail or at least be impacted in some way. Conversely, a poorly-defined business process could result in poor quality data. 

For instance, take a customer order submitted to a company via a call center purchasing system.  What happens if the operator has been poorly trained, and the order is completed incorrectly, resulting in omission of some vital data?  As a result, the order cannot be processed and the customer has to be contacted so that accurate information can be re-entered correctly. Here we have a poor process resulting in poor data quality. The net impact includes shipping delays, collection delays, customer dissatisfaction, poor productivity, additional time and people cost.

If, on the other hand, the operator correctly entered all the customer and product data required for the purchase, but the item code was incorrect in the corresponding supplier catalogue, then obviously, the wrong item would be dispatched to the customer.  That’s an example of poor data quality impacting a business process. So the Net impact is shipment return handling, increased shipping costs, billing and collection delays, items cannot be resold, and ultimately, customer dissatisfaction. 

And you know what, in thinking about it further, remember, the item information was originally entered incorrectly in the catalogue, so here we have a poor process again. So, a poor process results in poor data which results in a poor process and so on. It’s the chicken and egg syndrome!

These are fairly crude examples but when an organization has thousands of processes and millions of data records, you can quickly visualize the potential impact across an organization in terms of lost revenue, additional cost, wasted resources and customer dissatisfaction. 

Business processes are related activities and tasks that produce a specific service and product or serve a particular goal. When we think of an operational process such as an order or a shipment, these are composed of a series of sub-processes and granular activities that have their own characteristics and functions. Processes, sub-processes and activities may have different levels of sophistication within an organization, from well-defined and automated to loosely-coupled and manual, depending on the maturity of the overall process and how it is implemented. 

Business process modeling tools provide business users with the ability to model their business processes, and implement and execute those models. However, without due care and attention to the data, its quality, completeness and consistency across all related processes, sub-processes and activities, the resulting overall process will be far from optimal.

Given the above, why are the functions of business process modeling and data quality management so distinct in organizations?  I think it’s still the separation between Business and IT, and that data quality management is still considered within the domain of the IT organization, with business process management within the actual business.  But, you need to stop thinking about this “separation of power” and instead, look for ways to get these different domains to collaborate and work together.

In addition, look at Data Governance.  While offering an approach to start bringing these different domains together, Data Governance is more often associated with the data (hence “Data Governance”), rather than the business processes reliant upon the data or creating or transforming the data.  Wrong approach though, and companies should move away from this perception.

Governance of data only succeeds when those that have a vested interest in business models and processes, incorporate data strategies into their optimization strategies.   Data governance and stewardship activities need to be integrated into business process design and management. In fact, a lot of the principles for data governance are the same as for BPM, a subject I’ll discuss further in a future blog.

But, unless we have business and data professionals working collaboratively across lines of business functions to manage and optimize data quality and business processes in unison, than data governance ambitions may well be thwarted.  Maybe we should call it “Business Process and Data Governance?”  Hey, now there’s a thought……

What do you think?  Should we be calling Data Governance “Business Process and Data Governance” instead?