TRILLIUM SOFTWARE INSIGHTS

We’re Not Even Speaking the Same Language Yet!

By Jim Orr, Director, Enterprise Data Strategy, Harte-Hanks Trillium Software

I’ve been traveling a lot lately and have had a number of really interesting and engaging conversations about data governance.  And you know what?  I’m not convinced that we all are even talking the same language yet.  That is to say, organizations continue to have vastly different perspectives on what data governance is, and equally diverse ways on how to approach it.  My notion is supported by the types of data governance RFPs that are being written.

Like anything else, it’s always good to carve things up into smaller, manageable pieces (read Jon Asprey’s blog). With this in mind I propose that you think of data governance in terms of 3 distinctly different yet fundamental categories:

1)    Administrative data governance
2)    Technical data governance
3)    Business data governance

Administrative data governance focuses on things like direction, prioritization, scope, structure, organizational alignment, business case, and funding.  It also includes other administrative issues like policy, procedure, roles and accountability.  This parcel of data governance requires executive and business leader support and participation. It also requires a distinct set of business leadership skills to formulate and implement.

Technical data governance relates to activities around technologies and systems that facilitate data management such as data models, metadata management, workflow management, data quality tools, CRM, and BI.  As you might expect, this segment of data governance should be IT-led

Business data governance pertains to business centric activities that influence data outcomes such as business process, business rules, data standards, stewardship, reporting, metrics, and other associated activities. All of which should be business led.

Now, am I advocating 3 separate data governance programs? Absolutely not! In fact one is dependent on the other with administrative governance serving as the overarching authority over the entire program. What I am saying is that by dividing these things up, organizations can better clarify their business requirements, develop better strategies and plans to solving their challenges, and ensure that the right skills, people, and groups are involved in the right activities at the right time and for the right reasons.

Does this ring true with you and your experiences?  Tell us how you’re dividing and conquering data governance.

Eating the Elephant One Bite at a Time - MDM and Data Quality

By Jon Asprey, Director, Strategic Consulting EMEA, Harte-Hanks Trillium Software

How do you eat an elephant? One bite at a time of course. It’s a well known phrase and a philosophy often cited in management. Defining and implementing an MDM solution can be a risky and complex programme which is only partly dependent on technology to be successful.

From my experiences of engaging with our customers, those implementing MDM one bite at a time are riding the smoother path to success. Now this may sound an obvious way to proceed but some organisations are suffering by failing to adhere to the basic principle of understanding and meeting the (data) users’ needs.

I have seen many cases where a data “master” has been defined with little consideration for the quality of data held or the intended downstream uses of that data. To create a true “master” source that can serve a multitude of business needs and stakeholders, business analysis must be done first. This requires focusing on a defined set (or subset) of master data for the initial project and includes making a clear business case based on the improvements to be realised. By targeting efforts in this way, uncovering the true needs of the business becomes more manageable and a robust business case can be built.

Initially the focus of MDM is defined by data domain, with many organisations targeting customer data in their first project, although supplier, asset and product are also common. At this point it is often sensible to sub-divide data into smaller data sets. For example “customer” may be broken down into residential and commercial customers with one sub-set “mastered” in a pilot MDM project. The rationale for the break can vary, relating to a number of points that favour one sub-set over another:
•    Higher business priority/value
•    Smaller data volume (more manageable)
•    Less complex business process, therefore less stakeholders and less complex requirements

One point to note here is that residential customer data may have very different standards, matching (duplication) rules and business processes compared to a commercial customer. Therefore “customer” data must be subdivided to enable the business to have a sensible discussion on what standards and requirements the customer master must satisfy.

Geography can also prove to be an effective way to sub-divide data for a pilot, for example a business in the United Kingdom may have a customer base in the Republic of Ireland which is representative but much more manageable (in size) as a proof point. Of course there may be some regional differences in the customer data but the high level principles remain the same.

Breaking up the MDM elephant into manageable bites allows the implementation to gain momentum. A success in one domain, proven with return on investment figures and managerial commendations, does a great deal to win interest from leaders of other domains.

Of course, there’s no one route to success. It depends on your company and your people and culture. Perhaps you’d like to share what you’ve experienced? Have you already embarked on and MDM project? How did you approach it and what worked/didn’t work?

How Do New Federal Standards Measure DQ’s Impact on Risk Calculations?

By Richard Wilson, Vice President, Product Strategy, Harte-Hanks Trillium Software

The May 24th announcement by the Federal Housing Finance Agency (FHFA) of a common framework of standards for data collection and management is welcome news for a lot of reasons.  This framework will be used by all US banks, Fannie Mae and Freddie Mac, and will operate across the US Mortgage industry to facilitate information exchange, data collection, reporting, problem tracking, etc.

However, the following statement within the framework particularly stands out:

(The) common data standards framework will increase efficiency for lenders while enabling the Enterprises to manage risk more effectively.

In light of this, there is now recognition of the direct link connecting data quality and risk calculation in a specific line of business, and this is important for several reasons – most significant is that banks will soon have the tools to measure (and peer review) exactly how much poor data quality adds in costs to their mortgage risk operations. 

Everyone has seen examples and ‘use cases’ measured in billions of dollars, but the idiosyncrasies of each bank’s operations have masked the overall costs to the industry (and its customers)- which are staggering.

It’s tempting to go back and ‘game out’ the scenarios of what might have happened had Fannie Mae and Freddie Mac had ‘the right tools at the right time’ to detect the poor quality of the data that was being used in the essentially corrupt mortgage book they were being fed a couple of years ago.  One imagines that even the most rudimentary data quality metrics tracking the input from NINO (No Income No Asset) loans would have operated as ‘a canary in the mineshaft’ and provided early warning of the home loan market collapse.

Data is a shared resource of a bank’s operations and risk functions – but data coming from multiple ‘downstream’ systems needs common standards and metrics to be ‘fit for purpose’ in establishing accurate risk exposures. The metrics and governance processes s being put in place by the FHFA measure data are designed to lay bare the critical link between problems in data and erroneous risk calculations. 

This new ‘direct connect’ between data accuracy and risk management should function like the “Rosetta Stone” and enable shared understanding of critical data assets at certain key junctures – and establish a much closer alignment between the ‘facts on the ground’ an d the true nature of the bank’s risk exposures.