We’ve all experienced some version of this problem: Ask “how many customers do we have?” and the marketing team provides one answer, sales a second, and accounting a third. Each department trusts its own system, but when the task at hand requires that data be shared across silos, the company’s various systems simply do not talk to one and other.
The problem arises because different systems employ different definitions of key terms. Thus, the term “customer” can mean a potential buyer to the marketing department, the person who signed the purchase order to sales, and the legal entity that it bills to accounting. Then people misunderstand the data and make mistakes. These issues grow more important as companies try to pull more and more disparate data together — to develop predictive models using machine learning, for example.
Specialized vocabularies develop in the business world every day to support new or specialized disciplines, departments, problems, and innovative opportunities. The term “customer” means different things to different departments because, at some point, each required the term to mean something specific to them. Language constantly grows and divides, becoming increasingly subtle and nuanced. But over time, systems don’t agree, which can cause tension and conflict in organizations.
To see this, consider two departments of a consumer package goods company. Day-in and day-out, the marketing department is responsible for promotional activities and rates its effectiveness on whether a particular promotion produces the desired results. Similarly, the logistics department is responsible for getting raw materials to factories and delivering finished goods to public warehouses and onto retail outlets. Neither viewed market share as its top priority, but both kept it current in their databases to be ready for the occasional question from senior management.
Which is exactly what happened. An important issue arose and management asked the two departments to determine whether the company had been losing market share. Each arrived at its own answer, and tempers flared as each vigorously defended its system. Eventually a relative newcomer discovered the problem. The respective systems measured market share at different places in the overall supply chain — marketing at the retail outlet and logistics at the public warehouse. Each approach has merits, but the two are fundamentally irresolvable. The two departments finally agreed on an answer for senior management, but the ill will prevented them from working together for months.
In the face of such discrepancies, companies usually seek technological solutions, including data integration, enterprise data architecture, and master data management, since the issue presents itself as a tech problem. But such solutions face long odds, because they do not address the problem at its root.
Instead, companies must thread the needle, following two rules: First, do all you can to encourage innovation and the growth of specialized language that comes with it. Second, provide the skinniest possible common vocabulary (i.e., standards) to facilitate company-wide communication.
Encourage the development of new language. Since developing new language is part and parcel to innovation, you must not interfere with the process. In fact, you should view the development of new language as a sign that people are solving problems in new and creative ways.
Half the battle in encouraging innovation involves removing barriers. Too many people accept the limitations imposed by existing systems and don’t even try. You should advise everyone that computer systems exist to support them and their work, not the other way around.
More proactively, you’ll almost always need new terms when you change the focus of the business. Thus, moving from a sales focus to a customer focus will require you to carefully define and introduce “shopper,” “cook,” “guest,” or some other term that best describes the relationship you hope to create into the lexicon. You should also probe people aggressively on the need for new and more precise words that better capture their work. One good cue to do so is when members of your team include caveats in describing results. For instance, if someone reports that “sales are down 3% this quarter, but the pipeline is full,” ask them to define a new term that succinctly captures the state of the sales pipe. Finally, you should treat the need for new language as you would any other data quality improvement opportunity and address it via the quality improvement cycle or Six Sigma.
Create a common language. You should also follow a structured approach to develop and promulgate the common vocabulary across your company. First, establish the required team. You will need a process owner, often called the Chief Data Architect (CDA), and a network of responsible coordinators (RCs), often called embedded data managers or stewards. It may also be helpful to employ a conceptual data modeler, since they have special skills at capturing common language. Since language is the province of the business, the CDA should not report into IT, but rather to the Chief Data Officer, data quality team lead, or other business-aligned group. Similarly, RCs should report into business units and divisions that create and use data, since the RC’s job is to ensure that his or her unit does its share of the work.
Next, you’ll need to define and manage an end-to-end process. A good way to start is by copying processes followed by national and international standards organizations and adapting them to your specific circumstances. Build the following features into your process.
Allow anyone to request that a standard definition be developed. For each request, form a sub-team to draft the standard. Your process should allow plenty of time to solicit feedback from all interested parties and to revise the standard as often as needed. This is a consensus process, so implement a formal voting procedure and require a large majority to adopt the standard definition. Like most things in the data space, it is best so start with relatively easier terms. An international company, for instance, may start with units of measure: English or metric? Keep in mind, even the most complex company probably needs only 100 or so terms in its common vocabulary. Aera, a California-based energy company, does just fine with 53.
Another important feature of your process involves publishing and promulgating the common vocabulary. Many companies use data dictionaries or business data glossaries, hosted on the company intranet, linked to major systems, and easily accessed by all. It is especially important that CDAs get involved early to include the common vocabulary into the specifications for new systems.
I find that the biggest mistake companies make is being too rigid, or expecting the common vocabulary to apply at all times. But the common vocabulary exists to promote company-wide communication, not dictate how individual departments do their work. Allow individual departments to use terms that best suit their work, reserving the common vocabulary when working with others.
Sound like a lot of work? It is! But unleashing the people’s creativity to invent new language, built on a foundation of a few well-chosen and well-supported data definitions, pays dividends in a myriad of small ways every day. It is much easier for people to find answers to important questions and work across departments.
from HBR.org https://ift.tt/2M2OosR
