How To Track your Assets - Part 2

A few months ago I wrote a guide on tracking assets -- from the point of view accounting. I received some interesting feedback on that -- and one that deserves some followup.

In my original article, I said,

Asset Tracking, from an accounting and accountability standpoint, requires:

1. Who is responsible for It?


2. When did we buy it?


3. What did it cost?


4. Does it have a depreciation classification? If so, let some poor accountant figure out what to depreciate it for.


5. Is it still here?

Don't get too excited about excessive features in an asset
management software program. In the end, those are the only five
answers you'll actually care about.

OK, so, from a literal standpoint, you have to have a 6th thing: Define what 'it' is. So, I confess, there are six things you need about -- starting at zero as all programmers do...  ;)

       0. What is It?

1. Who is responsible for It?


2. When did we buy it?


3. What did it cost?


4. Does it have a depreciation classification? If so, let some poor accountant figure out what to depreciate it for.


5. Is it still here?

I don't like to write wishy-washy. I could have used a bunch of words and said, "5 things you definitely want to know about assets so you can depreciate them but you might want to know more depending on your personal needs and responsibilities for full product life cycle management." Aha! Yes. I remember once working on a spreadsheet to track physical fitness thinking, "Who is ever going to fill this thing in?" Sure enough - some people that is what drives and motivates them.

So... Mea culpa #2: Never use absolutes. ;) One book I love is 'The only investment guide you'll ever need' by Andrew Tobias. It's awesome in it's simplicity and anecdotes and ability to say things without being absolute. In the first chapter: "This isn't the only investment guide you'll ever want -- but, it is the only one you'll need." Or, close to that. In that, it describes how you'll want lots of things but will you ever truely need them?

Now... There are a lot of things you may want to know about an asset and it was pointed out to me that you could track it's maintenance history, hazmat requirements, disposal properties, manufacturer and lot #, ownership history, ad infinitum. Some people will surely want to know those things. But, will they need to know them? Maybe?

Switching modes for a minute... In programmer terms, this is what makes XML incredibly great. XML and hash-tables allow us to extend anything -- assets included -- to contain an infinite amount of data and manipulate that data in so many useful -- yet, time-sucking ways.

So... I can now say, "The only thing you care about an asset is what you actually document about it, standardize that documenting about it, and continuing to be vigilant in updating to the extent you can trust that documentation."

What do you want to know about an asset and how much of your time will you spend keeping it accurate and enforcing that accuracy?