Retire state

[Nancy Schilli]

For SAM, the best practice is to retire the asset when it is no longer useful, reached EOL, etc.  in order for the software installations to be removed and not counted in reconciliation.  It would also be best if this is the time to actually wipe the device, knowing that the HAM side may wipe the device in the disposal process

For HAM, the disposal workflow requires the device to be in stock, pending disposal.   And the end state of this workflow is to mark the device as retired, disposed.

What I’ve been advising clients is to initially mark the device as retired, so the software installations get removed. The device typically is no longer on the network at this time. Then move the device to in stock, pending disposal at the time you ‘move’ the device to a location where you’ve wiped the device and it’s ready to be disposed.

The client doesn’t agree that the device should be marked retired 2x, once when it comes into the stockroom and then when the disposal process is complete. They mark the device as in stock, pending disposal, since that is the state the disposal workflow looks at to move the device thru the disposal process.

This seems very disjointed and confusing.

Please advise  as to the reasoning and best practice here

[p_tishberg]

Hi Nancy,

From common sense, non-ITAM perspective, it would seem counterintuitive to have multiple substates of a state that is "Retired".  But when you break down the Disposal process into multiple workflows that are not necessarily in a logical order, the substate themselves become very important to track the final disposal of an asset from when you are first removing it from being "In Use".

One such example, you have provided, is the harvesting of software licenses from machines that are going into Retired and are not going back out to being re-"In Use" because either their lifecycle has ended from a manufacturer perspective (EOL/EOS) or the firm has decided not to use that make/model any longer.  In this example, you want the software harvested off the drive before destruction. 

You can go with Retired-Pending Disposal or create a specific substate (always create substates {within reason}, never states - that will keep workflow, business rules and sanity to the instance).  So the In Use device can state change to Retired-Pending SW Harvest (the new substate) and then a team could remove the software licenses based on a whitelist of costly or any cost software determined by the SAM Manager.  The final task would be to change the state-substate from Retired-Pending SW Harvest to Pending Disposal.  Then once the disposal company disposed of the systems and sends the updated file with the certificate, you can import those records which can change the state to Retired-Disposed. 

So, in that example, 3 Retired substates track 3 different workflow tasks/activities while maintaining overall governance of the drive, specifically, the drive's data, which is why all this matters in the end.