Let us be among the first to wish you a happy new year. Here's hoping it's productive and rewarding. As with many organizations, we are spending a little time, at the end of last year and the beginning of this one, reviewing the past year: what we accomplished, where we fell short, what we hope to do better this year, and so on.
Of course, in order for this exercise to be successful, you need to have a pretty accurate picture of what you did accomplish, where exactly (and how often) you fell short, what sets the baseline above which you want to improve. In short, you need a complete set of data for review and analysis. That's a tall order at any time, but at least for some organizations this time of the year probably presents additional wrinkles.
Maybe you're a company running a special year-end offer that results in extra orders. Many nonprofits, we know, see a surge in donations at the end of the year. At the same time, between vacations, seasonal illness, and of course exogenous factors such as supply chain dependencies or even competition to get products shipped and delivered, it can be an even greater challenge than usual to really understand what has just happened, and what effects those activities have had on your year-end situation.
We can easily imagine a situation where the sales department closed a bunch of deals in the final weeks of the year, but where some typical follow-up activities haven't been completed yet. Maybe not all payments have come in, maybe not all invoices have been sent out, maybe the fulfillment office hasn't been able to ship all of the ordered products, maybe the holiday rush has delayed delivery of shipped products, etc.
By the end of January, everything will probably have shaken out. Orders will have been paid for (or canceled), payment will have been received (or purchases will have been billed), product will have been shipped and delivered. But right now, and depending on who asks and who is asked, there could be great variation in our year-end data. If the boss asks whether we met our goals, or how much we exceeded them by, the sales database might present very promising results. But if the boss asks about profitability or cash flow, the finance team might not present quite as rosy a picture. Maybe they know that these year-end orders have a history of not being paid for, or for being so heavily discounted that they're not profitable, or for being returned. Maybe the boss asks an analyst they trust at the end of the day when sales and finance have gone home. The analyst thinks that the true picture of the number of products sold is the number of products sent out, and they get that figure from someone working late in fulfillment, or because they have access to fulfillment data, or whatever. (It's a thought experiment, we can be a little hazy on the details.).
Regardless, it ought to be clear that depending on who asks, who answers, and when, there could and probably will be discrepancies in the totals that get reported.
Our pragmatic approach to data governance grew out of situations very similar to the one described here. Not only can each office show its work, so to speak, for certain questions and at certain times, each office can reasonably claim to provide the canonical answer. One of the guiding principles in our Data Cookbook could be described as "call different things, different things." In this case, sales is counting agreements or commitments to purchase, and finance is tracking payments received or invoices generated, and fulfillment is counting units shipped (or units ready to ship). Calling these all something generic like "units sold" leads to confusion at the best of times.
Calling different things different things means defining data concepts and practices. But making sure that terminology sticks and is understood involves using it regularly and consistently. How to do that? Well, one way might be to ensure that requests for data involve clarifying the terminology used. Make this part of requirements gathering, testing, and user acceptance or approval. When the request is formal or might be repeated, document the work. Add this to your data catalog. (If you don't have a data catalog, start one. Or buy a tool to keep track of your data catalog--we know of a good one!)
Now, we suspect that this is another instance of the so-called 80/20 rule, and that around 80% of the time the sales numbers will be close enough to the fulfillment numbers not to matter, or that the question itself is not that time-sensitive and that the adjusted numbers come end of January will resolve. This, too, is something to make part of your pragmatic approach to data governance. One reason requests for data take so long to respond to is that analysts go to extreme lengths to clean data and to verify results, especially in places where a single source of data truth hasn't been created. If an approximate answer is sufficient, then maybe you need to build that option into your data delivery workstream.
Could this could be a low-pressure, high-return way to improve some of your organization's data literacy efforts? When these opportunities for data brawling present themselves, rather than retreat into a defensive shell or question another office's methods, step back and ask whether these differing figures are really important, and what might be at stake if one set can be shown to be definitive rather than another set. This conversation could lower the temperature, so to speak, and it might be a useful block as you build your culture of data. (This might be a topic we'll return to later in the year.)
We suggest that as you look back on last year's activities, you also assess the role data played in performing those activities. What did it help you accomplish? Where could it have helped you accomplish more, or done better? What about your use (or lack of use) of data helped or hindered? What pragmatic steps can you take this year to improve on last year's performance?
We've argued for years that better data governance ultimately saves time and money by reducing duplication of effort, and by producing more reliable data products that can be acted upon. And yet, as with any resource, you can only spend so much time, energy, and money governing your data. So maybe this year you can resolve to spend less time arguing about marginal differences that don't really matter, to spend less energy chasing data errors that ultimately have minimal impact, and to spend less money by seeking perfection when it isn't necessary.
Easier said than done, we realize, as is the case with all planning exercises and New Year's resolutions. Most of your pragmatic data governance work will be operational in nature, and limited in tactical scope. But thinking strategically about which of your data problems can be solved, and which of these actually ought to be solved, will help align and organize your limited data governance resources.
Additional data governance and data intelligence resources can be accessed from here.
IData has a solution, the Data Cookbook, that can aid the employees and the organization in its data governance and data intelligence efforts. IData also has experts that can assist with data governance, reporting, integration and other technology services on an as needed basis. Feel free to contact us and let us know how we can assist.
(Image Credit: StockSnap_XBL8EKLLAK_ManThinking_PragmaticDG_BP #1193)
