Data definitions are about a business creating a common vocabulary in a common language. They’re about how the organization thinks about itself. Take product data: The business needs to know what products it sells, how they can be categorized, what needs to be understood about that, who has financial responsibility for them, and why it should care about the whole definition in the first place, too.

“What we are really talking about is the reality of the business — how to do you make it so that the computers can interact with that reality?” That was the question posed to the audience at the DATAVERSITY® Enterprise Data World Conference by Gretchen Burnham, a Certified Data Management Professional and Data Governance Business Analyst who works with San Francisco Partners, during her presentation titled Resolving Data Definition Conflicts: A Practical Guide.

It starts with getting users to interact with each other’s own data realities — realities that were born in functional silos where data was defined to reflect their own perspective. Data diversity back in the day was manageable, as there were controlled processes for that data to interoperate with data from other functions, such as through batch processes and ETLs with thousands of lines of code. “If there were different definitions, you could handle those in very defined hand-off points,” Burnham said. But today, expectations are that data will be interoperable seamlessly across the organizations. There’s no time to waste.

For seamless interoperability, data definition conflicts must be resolved. Along the way to trying to do that, issues obviously will emerge from parties invested in the meanings of the data they own. Maybe resolution is going along smoothly — the data owner from one unit seems to be in agreement with everything — up until it gets to the last line of the proposed definition. 

Or things can be off to a rocky start if one department uses the same name for something that another department uses for something completely different. Or things get sidetracked by data owners overloading meanings, focusing on the specific details rather than a high-level conceptual conversation.

These dust-ups and distractions aren’t just about data dictionaries and business glossaries.

“It is actually is about different perspectives for the data,” Burnham said. “It’s about an actual conflict that’s happening in the organization.”

Data Governance is in a unique position to help the business resolve these conflicts. “Because we think about data and we understand how data flows, we in the governance space can work across functional silos,” she said. “We’re neutral third parties that can help organizations get through this process.”

Follow the Data Road

Burnham shared guiding principles that Data Governance pros can encourage for managing the process:

• Avoid Judgment: Data doesn’t have emotions — but people have emotions about their data, and conflicts ensue from there. “Data literally is part of how people do their business processes, which makes it part of their professional self-identity,” Burnham said. They’re trying to do the best job they can every single day, not coming in with the intent to screw up data that day.

“I hear data people going all the time, ‘garbage in, garbage out.’ Well, true but garbage — really? That’s somebody’s work,” she said. Judgmental terms like ‘junk,’ ‘garbage,’ ‘trash,’ and ‘crap’ should be prohibited among those involved in data definition discussions, she said. When you say that there’s a whole bunch of junk data, “you’re actually saying to somebody in the room, ‘you are junk, and you did bad work.’”

• Delve Deep: Data Quality problems certainly do exist, but the big question is “Why?” She shared an example about how what seemed to be a disregard for process was something else entirely. The reporting group at one client she worked with blamed its customer Data Quality problem on the customer service reps. They were entering the PO number for an order into the first name field of the customer—but it turned out to be for good reason. CSRs can only reconcile the data that is entered with the shipping label constraints by using the customer first name field for the PO number so that the number actually showed up on the labels. That’s a very legitimate business decision: “If the orders don’t go through and the product doesn’t ship, the revenue stream for that company stops cold,” Burnham said.
• Question the Status Quo: Legacy definitions for historical data — maybe created a decade or maybe even a quarter of a century ago — can live on for a long time. The business may still use them even though no one really knows what they mean anymore.

“Always be willing to question, is this still a legit thing that we need? Is this still the best way of expressing what we need to express?” Burnham said. “You can question that in a way that honors what was done in the past, but then say, ‘What do we need to move on into the future?’”

• Don’t Let Analytics Teams Drive the Process: In many organizations the analytics people are the data people, and they tend to dictate the process from the point of view of data definitions that fit to their reports requirements. They aren’t necessarily thinking about what is best for the people who are in operations, which is critical. “Everybody else is a process person, and the processes generate data and consume data.” That can’t be taken out of the equation.

Think about it this way, she said. The process is the pipe and data is the water flowing through it. “All of these perspectives are valid.”

Bring in the Right Stakeholders

Facilitating data definition conflicts requires knowledge of how decisions about data, processes, and technology are made in the organization. “You need to understand how much consensus is required,” she said. That influences which business stakeholders will be brought into resolution discussions. In a more autocratic organization, for example, forming a small working group may work.

But when many people have a say, “You’re going to need to bring in more people right from the get-go in order to make sure that they’re all brought along for the ride and invested in the solution.” Up-chain buy-in matters too, to stop any end runs by data owners around the process.

“The conflicts that exist are not theoretical, therefore the solutions that exist are not theoretical either,” Burnham said. “This is not just about wordsmithing your glossary. This is actually bringing people to consensus.”

Make Sure the Business Sees the Value of Data Governance

Leading the drive to resolve data definition conflicts across cross-functional teams leads to the next step: determining who will be in charge of spearheading implementations. “This is really critical, and Data Governance should be tracking that to make sure the implementation happens, and whether or not that resolution did what we hoped it would do,” she said.

That’s the way Data Governance teams prove the value of their programs to the organization. “You’ve just facilitated a cross-functional group of people to solve a real problem for your organization and, by the way, we can see that we’ve had this benefit from getting that problem resolved,” she said. “So maybe fund us for another year, because we’re really good, and we’re providing value to the organization, and here are some numbers to prove it.”

Check out Enterprise Data World at www.enterprisedataworld.com

Here is the video of the Enterprise Data World Presentation:

Image used under license from Shutterstock.com