Blog: Dan E. Linstedt

« Data to Information, Architectural Roles for Business | Main | Standards, Compliance, and Successes »

Information Valuation - Part 2

I've been asked if there was a way to quantify information as an asset on the books, and since then have been asked what % of companies may be doing this lately. It's hard to quantify something that companies have long considered an intangible asset. However in this blog we will explore the base possibilities and present a single scenario which may begin the process of accounting for data (quantifying data). This is an experimental topic, any thoughts or feedback is welcome.

What is data valuation as an asset?
To understand this, we have to first accept the fact that data in and of itself is valuable to the organization. Then we must take steps to measure parts of the value of the organization. In my mind there are two major methods by which valuation of the data set can begin.

The first method: Top down valuation
Top down valuation (from my perspective) means lumping the entire data set together as a single asset, or maybe each of the OLTP systems, and data integration (ok - data stores) as their own assets. The questions we have to ask with top down valuation might include the following:
1. Would I lose business if I lost this data store?
2. How much money per minute would I owe to partners/customers based on SLA's if this data set were UNAVAILABLE?
3. What tangible profits have been received partly as a result of this data set being built?

We've been doing this for years in quantifying the cost of hardware on which these data sets run, but we just haven't carried this into the data itself - some have assumed that the data is too intangible an element to be measured. Notice we didn't ask any questions about the quality or compliance of the data set... We only asked about tangible and measurable loss of the data set. One might say that Top Down measurement is akin to itemizing the entire set of data with the hardware for disaster recovery classification. True. Now would be a good time to insure against these failures and unavailability’s.

Well, a big part of that is getting insurance for the LOSS of an entire data store. Maybe rates for insurance of data are LOWER for those with a proven and tested (audited by the Insurance adjusters) disaster recovery program. Maybe the rates are lower for those businesses that have business definitions and attached understanding for the uses of their data - in relation to the actual SLA's signed by the business. Maybe the lower rates indicate a better handle on understanding and quantifiable results of the data and what it means to the business.

Once the data is insured - it should be attributed as an asset on the books for the amount it is insured for. Maybe insurance rates go up for those companies that DON'T meet their SLA's, and aren't accountable for failure recovery. Hmmm, talk about Information Quality Improvement efforts.

Ok - so we've quantified (somewhat) what the BLOB of data represents to the business, we can justify it's loss, and account for it's recovery. What about depreciation?

That's a VERY interesting question. Think of data in a Data Warehouse or Enterprise Data Integration store as different as that in an ODS, or OLTP system (which it is). Even an Active Data Warehouse falls into this category. Depreciation (hypothesis) can only be measured by the loss of historical data, and what that translates to in a quantifiable manner to the business.

In other words: does the SLA cover "old" data; if so, how old? Where is the cut-off point at which the "old" information is not valuable to the organization anymore? if the "old" data is always valuable, just less valuable, then ask this question: If my systems were to lose data that is X months/years old - what would it cost me to recover?

What SLA's are in place to force me to be back up and running? Are my data mining engines relying on the history to produce active responses today? If so, then the "old" data is just as valuable as the current or new data. If not, then the "old" data depreciates in value as it ages - it's up to you to negotiate that value point with the data insurance adjusters.

The Second Method: Bottom Up Valuation
What does this mean? Bottom up valuation (again my hypothesis) is the manner in which EACH data element is weighed in on the grand scale of value to the business. Here, data quality IS measured on a row by row, cell by cell level. It is tedious and much of the work can be done by utilizing a data profiling tool, or a data mining tool engaged to profile for trends of missing information or bad information.

Suppose you had a customer table, well - forgive me - but if you don't have customers, you don't have revenue, and if you don't have revenue, you aren't in business to make money. In this customer table you had 3 million customers. Each customer row has a specific value. Assuming you're a direct marketing firm, or even a banking firm - each customer has a specific investment or makes a specific amount of "money" for you by being in your customer table.

As a marketing firm, you want to offer free subscriptions - and the gender of the customer becomes important as ONE of 32 elements that make a difference in determining WHAT to offer them. If you send the wrong type of magazine to the wrong individual because you're missing the gender field, and they unsubscribe from ALL your services - you've just lost a good customer. What does that equate to in revenue dollars?

The bottom up method requires attaching a "row-score" to each row, weighting the importance of each row - of course this weighting or scoring mechanism must change every time the customer information changes (apply this concept to EVERY table within your data store). Then there is a general or average dollar amount, a mean, and median, max and min dollar amount for each row.

Some customers are outliers and we DON'T want to adjust their outlying investments to the average numbers. Now, based on the weighting and the statistical dollar amounts calculate an overall value for each table - please take into account the EMPTY fields and the importance of having GOOD data, this should affect the weighting factors. Finally, add up the weighted dollar amounts for each row, and ask yourself the business questions: is the value of this "data set" really the total value to the business? Add an overall adjustment factor to the final dollar amounts, and test it with top-down recovery costs for an approximate range.

Now you should have a fairly decent idea what your data sets are worth. Now it's up to you to negotiate with the data insurance investors for actual valuation.

Ok, there's a lot of talk here about valuation of data, and insuring the data - some of which we may already do. But what about listing it as an asset for tax purposes? Well - that requires a change in the laws around the world, unfortunately that's wide-open speculation that I do not engage in. If you can insure your data, maybe just maybe, you can convince your tax auditors and your local government to at least look at the issues seriously.

In regards to what I see in the field (purely speculation - not backed by any scientific studies of any kind): I see on average 10% of the fortune 500 engaging in these activities. However, I see 60% to 80% of the businesses today working hard to have fault-tolerance and disaster recovery programs in place. What I don't see is the follow through with tangible valuation of data as an asset.

Good luck, hope this helps – thoughts or comments? Love to hear from you.
Dan L

Share: