Skip to content.

TalkBMC

Sections
You are here: Home » Blog Archive » Anne Gentle » Exploring Information Design and Development » Facing the Dell laptop with a Sony battery recall... can a CMDB help?

Facing the Dell laptop with a Sony battery recall... can a CMDB help? Facing the Dell laptop with a Sony battery recall... can a CMDB help?

Document Actions
Determining how a CMDB could help the business with a recall like the Dell laptop with a Sony battery fire hazard

So, was your laptop affected by the recent Sony battery recall? I have a Dell Latitude D600 and had to check the serial number but fortunately the battery number did not match those on the recall website that you check to see if you need to get a new one.

Now, if a CMDB had contained the serial number of my battery, could I have been saved that extra step? It's a question of granularity for the CMDB – when would you kick yourself for not going more granular on your CMDB? And is it possible to think of all scenarios such as this, especially for all hardware parts that go into laptops and servers and desktops? I sincerely doubt it's worth the trouble... until something like this recall comes up and then I wonder.

It seems like entering all that information into your CMDB is not worth it for these rare exceptions when you want the information. Until the information could be automatically discovered somehow, it's just as easy to have your end-users look it up for themselves. If the serial number information was available from the manufacturers or through discovery, it could be a federated attribute in an Asset Management database rather than stored in the CMDB. But, for a level of granularity that helps you pinpoint a subset of your entire collection of hardware, you could use the CMDB to help you determine who might be affected, based on who has laptops or who has Dell laptops with the exact model numbers that are affected. This sounds like a sensible and balanced approach.

How about you? Any ideas on the practicality of granularity for these recall situations? What is the next step -- Change Management for tracking all the replaced batteries?

Updated to add: Here's a link to a relevant podcast with Tom Bishop, where he talks about the relativity of data. Thanks to Ynema's comment I can get even more familiar with the best approaches to these types of CMDB design questions.


_____
tags:
Friday, August 25, 2006 in IT  |  Permalink |  Comments (4)

CMDB

Posted by Y. Mangum at 2006-08-27 18:42
I was talking to Tom Bishop about this in the last "In the Mind of a CTO" podcast series. Listen to Part 4. I asked him what would keep us from putting all business information in a CMDB, not just IT assets. Listen to his answer and I think it will help you understand a little more. Of course, you're talking about the point at which you consider IT items assets or inventory, but it's really almost the same question I think.

No, I think

Posted by Steve Carl at 2006-08-28 13:38
Every manufacturer who has these Sony sourced batteries from this time period will end up having this problem: The metal shavings did not just fall into the batteries of Dell's and Apples.
I admit I have not listened to the Podcast Ynema refers to, so this may be redundant to that, but...
I think the general answer to your question is no. It is a level of effort thing. How often do tiny parts like this get recalled such that it it worth IT's time to track everything at this level? However, if you can automate it, via auto-discovery then I change my answer to yes.
These days most batteries are 'intelligent': Lithium chemistry being what it is, there are usually micro-processors in the battery case next to the battery cells managing the batteries to keep bad things from happening to them. If your computer is designed to 'talk' to the battery, it can know all sorts of things about the battery: How many times is had been charged, it's original milliamp rating, what it's current max rating it, etc. This can include the serial number. My Apple battery was recalled, and I could go into system info and find out everything I needed to to know if I was affected by the recall. But that means my Apple has hardware and device drivers to talk to the batteries brain. Any autodiscovery I would create to support an Apple in a corporate world and auto-populate an asset management data base would be able to track that kind of detail at a very low cost.
I have no idea if Dells have this intelligence built in or not. Lets say for arguments sake they don't, and that it had to be manually collected and manually updated every time it changed. If you are a company the size of BMC, the costs are not inconsequential. And if you are a small shop, then it won't take any time to look at all the computers ad-hoc either. There is not real way to justify the cost until it is forced on you by circumstance.
Think about a scenario where you decide to inventory everything about a computer that might be recalled. A laptop for example: You don't just have a laptop with a serial number there. Take it apart: the LCD, hard drive, mother board, CD/DVD, battery, RAM chips and probably other things all have serial numbers. They do not match the external case S/N in any way, other than at the place that made them. And once it left there, they have no idea what happened next; I have a ton of FrankenComputers at my place that in no way match the serial number stack the manufacturer has for them. Can you imagine taking apart a laptop to record all that stuff every time you made a change or needed to verify your inventory? The technical term for that is : Yuck.
Running an IT shop is different from running a manufacturing plant. If you are Apple, Dell, General Motors, Ford, or whomever, you have to track every single thing that might ever be recalled, redesigned, or reused in any way. That is a cost of doing business. *not* doing this would add to your costs in so many ways. When I was at NASA, we had to track every single part of the space shuttle, and all the bits that flew for not totally dis-similar reasons.
Classic BSM: your business and therefore your business model dictates your actions here.
 

Powered by Plone

This site conforms to the following standards: