You really shouldn't take anything that uses total numbers in the way this article does to seriously. If you really want to get to the meat of the matter, the correct way to view the data is "per 100,000" and/or "per x million traveled miles". Makes it much easier to control for other factors (e.g. urban vs rural, harsh anti-texting law areas vs. unrestricted, high fatality areas vs low, high DWI area vs low, etc.). Same is true with most of MADs DWI figures, gun control, pot based DUI, etc. Totals are not only misleading, but often inflammatory (37k sound like a big number...but what is it really in the context of 300 million people driving trillions of miles a year?).

Going about it the wrong way...what they should be doing is taking a page out of the Red Hat playbook and just protect the Google TM within Android. Then they could just set forth specific rules which must be strictly followed in order to say this is an Android device and to use any of Google's TM within.

For example:
    Create a directory structure for 3rd party (non-ASOP) drivers, libs, and config scripts which must be used and prevent manufacturers/providers from altering or removing other files/folders.
    Force manufacturers/providers to allow users to use default Android applications in place of 3rd party apps through some standard means.
    Weigh in with yes/no on things like encrypted boot loaders, rooting, preventing side loading of apps, etc.
    [Add whatever rules which are causing fragmentation problems or allowing such monstrosities as Viewsonic's Tap'nTap here!]

What this should do, is allow manufacturers/providers who do not care about being labled as Android to do as they please (the B&N NOOK, for example, may not care at all if they get to put a little robot sticker on the box or not since it is such a specific device). Manufacturers/Providers who DO care, would be forced to follow the rules if they want to take advantage of Google's advertising, marketing, and reputation.

As a side benefit of going this route, they could also do things like strike back at MS forcing Bing on everyone within WM7 by specifically banning it from Android(TM).

Not only is this not the "only" way, it not even a very good way in this situation. Metrics are great, don't get me wrong, but they are not very well suited to this task. Problem is, in a small IT shop, while it does show the break/fix and crisis support, it isn't very suited to project and routine maintenance work. There is no easy way to gather metrics in a small company for things like "99.8 uptime of email", "backups and disaster recovery", "keeping automated anti-virus updates working/current", "rebooting that flaky server in the corner every Monday", etc.

If you want to justify your existence, I'd suggest a project program (i.e. MS Project) with a nice Gantt Chart. Start by listing everything that you do routinely every week (e.g. check automated backups - 1 hour, check server logs for errors - 1 hour, weekly IT reporting - 2 hours, etc.) and then list the project you have planned (e.g. install and configure ticketing system - 20 hours, deploy client patches - 4 hours, train staff to use SUM in Excel instead of MS Calc while creating spreadsheets - 160 hours, etc.). Add on to that how much time you spend on client support and begin assigning yourself as a resource percentage to each task (a ticketing system can give you a good idea of how much you and where you spend your time on support).

Personally, I would avoid, at all costs, trying to assign a dollar amount to what I do. Instead, list out how your time is spent and what all you do, then let them decide if they can live without those things. If you really are a asset to the company, it should be obvious.