Or you could perhaps, think of what knowledge you desire, what data you need to gain it, and then match to what your systems provide, understanding the gap between what exists already and matches expectations, what doesn’t, and what needs to be created.
That’s why we recommend to start every project with a solid Business Glossary; for the same reason that we like to start with motivations provided by business and thinking and designing metrics with them: because technical teams (Data and IT) are enablers for business drives and not the other way around.
A Business Glossary is basically a collection of business terms the way business thinks of them, and that will in many cases be already present as a data entity in any of the Data Sources your organization has. Yawning already? Granted, it’s arguably not the most interesting topic you’ll hear about when building your data strategy. We believe this topic just hasn’t had a good publicist (yes, I’ve just paraphrased Al Pacino in Devil’s Advocate).
Now that we have your attention back, we hope to bring it further to what are typical signs you might already be experiencing that are related to the lack a of business glossary. Here are some tips we can provide from our experience on guiding this important step in the roadmap to becoming a data-centered business.
Get agreement on business understanding
Not all areas will think of certain terms the same way. Sometimes, at a very high level, it might seem obvious to define what a “Client” is for your company. But when you consider how differently marketing, sales and operations departments interact with a client (as their relation is fundamentally different), it starts making sense. Add an apparently innocent qualifier such as “active client”, and you are most likely to get a different figure per person in each department you ask for this combination of “self-evident” terms. We’ve seen our share of puzzled executives at all levels who confess they don’t know for sure how many clients they have. Oh, by the way, is the guy who wrote the piece of code years ago containing the metric most of the company agrees on, still around? Does anybody know what the numbers they’re getting really mean?
Getting accurate definitions is only half way. When building a solution that you expect your whole company can benefit from, you have to get agreements that key stakeholders are onboard with the details of what is needed to measure. Without accurate definitions, your project will most certainly face a long phase of user acceptance testing that will delay your go live, with an extra cost for changing code late in the process.
Map your systems
With a business definition clearly articulated and validated across the different departments, starts the technical part of connecting the dots. How is that business term represented across our systems? Does it exist? Does it reflect what business execs think it is (or it used to)? Is it designed in a way that satisfies data consumers? Are all the components needed for a data solution present? Is business discussing terms that have no place in any of the existing systems? And equally important, who is making sure that changes in business definitions are updated over time?
There’s a lot of room to get technical here: there’s a lot of valuable information one can use this task to gather. Technologies involved in the source systems, responsiveness, ideal time for extractions. The more information one adds at this point, the less re-work will be done in the future.
Depending on how the last step went, there’s likely some information that will need to be created or tailored. Like we said in our previous article, these are valid data projects in their own, beyond the initial scope of building a metric. The criticality of having that information will help prioritize them, because some of them will be expensive and time consuming, so we better be sure that they are at least necessary.
Define standards
Finally, let’s take a look at the information that, at first glance, seems good enough to start working with. This is the best time to work out the rules that define its quality and whether a decision based on that data can be taken with confidence: What makes each value unique? Which critical values can’t be missing? Which are the acceptable value thresholds in that set size variation? Which values can be one within a limited set? Which combination of values would be illogical or break inner consistency?
With business understanding, information mapping and standards defined, you pretty much have as solid a foundation as you might desire, not only for moving the project forward, but also for any newcomers that can easily read and get up to speed with less time and money spent expanding the oral tradition in a data environment, which only leads to slow and inaccurate responses. As a bonus, you have a nice backlog of missing data and some projects waiting to be planned and presented, with the business demand tracked from step 1.
We find this way of working the best, in opposition to finding that some concept was not satisfied from the start and thus rendering all the information built upon it useless. Saving time in this step is like trying to save money when building the foundations of a house.
We also find out often that this step’s value is difficult to grasp at first. And let’s face it, this step can be overwhelming. Getting business users to agree on business definitions is a serious endeavor in itself. Unfortunately, companies want to cut the chase here with the conception that to get results fast, we need to be more expedite and start building right away.
“Build it and they will come”, seems to be an (often unspoken) moto to skip this step. Spoiler alert: Nope, they don’t just go. It requires business savvy people, committed to the success of your project, with an itch to ask smart business questions from a tech realization perspective.
Connecting the dots from business to IT is key to move any data project from vision to success, and to achieve the full potential of all the investment you’re putting into your data project. We can’t stress this enough: Whatever challenges come up at this phase, are something that must be encouraged. Or else, sooner rather than later, your efforts will have fallen short.
See you next week with step 4!