Originally published 11 February 2010
Mention metrics – and you often hear people groan. Their eyes go glassy, and they sit there waiting for you to deliver the bad news. The problem is that people have a hard time agreeing on what metrics to use and what should go into making them. A metric is not a measurement. A measurement is easy, like the number of product units sold. A simple count on a single field and you are done – with little, at least we hope, quibbling over how the measure was derived.
Not so with a metric. A metric can be a weighted combination of any number of measures depending on what you want to manage. Because metrics can be complex and their formulation spans the interests of numerous corporate departments, your governance function can and should be the place to start. After all, it often falls on data governance to answer those gritty, data-oriented questions that everyone else has shirked.
Many firms are becoming metrics-driven; they want to manage their business and monitor their performance through the use of metrics. These metrics typically appear in scorecards. A firm will use a number of different scorecards – some published weekly, some monthly, and some quarterly or annually. Each scorecard illuminates a different segment of the business, such as sales renewals, marketing campaigns, or receivables. Universally, they will have some sort of summary page that abstracts the back-end details with red light/green light indicators – called metric traffic lights – that signify, at a glance, how that portion of the business is doing. Examples are customer renewal rate, new customer acquisition rate, and customer satisfaction. These specific metrics, to the casual reader, are obvious choices that a firm would want to use to gauge their performance. But the devil, as always, is in the details. What goes into those metrics? What measures are used? How do they fit into the equation that calculates the metric?
When it comes to answering data-centric questions where stakeholders span multiple departments, an overlying corporate function often proves beneficial. Data governance can arbitrate and host the data decision-making process and prevent it from becoming bogged down in interdepartmental haggling. In this role, data governance, through its data stewards, will collect the requirements of the business and (1) determine exactly what measurements are needed to create the metric and (2) determine what audience and constituencies the metric is designed to serve. Bear in mind, these data stewards, formal or informal, are the subject-matter experts of the data domain in question. They will have insight into the issue surrounding the data that comprises the metric. If the stewards are doing their jobs right, they will propose the formula for the metric to the larger stakeholder group, and gain their acceptance before its debut on a scorecard in the next department meeting.
So much for the easy and obvious metrics, like quarterly or monthly sales revenue. Most corporate managers understand the need for those. But what about the refrain, “We have too many metrics! They are confusing. I don’t know which ones to use.” Or better yet, “We can never agree on which metrics to track and publish.” In the vacuum of management decision making, these questions will fall on the broad shoulders of the data governance function. What entity is better suited to wade through these complex data-centric issues that span multiple departments and interests? Perhaps your firm has conquered the metrics octopus, and you did it without a formal data governance function. Good for you! What that means is data governance and its precepts are institutionalized in your organization. Just because you may not have an identified data governance initiative doesn’t mean you aren’t practicing it. Somehow, either efficiently or with great pain, your organization is governing its data and corresponding policies, maybe staggering along or nimbly stepping from decision to decision.
A trick I have learned that works well in answering the “What metrics should we use?” question is old-fashioned requirements collection. The data stewards interview a selection of managers and simply ask them: “What are the questions you ask of your data systems? What do you need to know?” Initially, through the first set of interviews, no clear pattern in their responses may emerge. The requests may be all over the map or, in this case, the business domain. But soon, once you interview enough managers, a common thread will emerge.
In working with an insurance client on a data warehousing project, we started to get common answers early on. In the project, we needed to identify all the necessary information to store in the data warehouse to answer key sets of questions. That’s when it became apparent that a commonly asked business question was synonymous to a key management metric – e.g., retention rate. The insurer – across all their lines of business (auto, property, life, etc.) – constantly asked these questions:
Comments
Want to post a comment? Login or become a member today!
Be the first to comment!