Rory Canavan

What does good HAM look like....? (Part II)

Blog Post created by Rory Canavan on Sep 24, 2017

Following on from What does good HAM look like....? (Part 1) we continue with the other key processes and benefits of engaging with this IT discipline.

 

Loan Equipment Process:  This is a refinement of the Stock Management process, insofar as devices will be kept at a medium specification and a minimum acceptable build, so that loanees don't become too attached to the temporary equipment placed before them while their regular IT devices are on order or going through repair.  Yet again, we should be keeping such devices at a base-build level while they are on the shelf, so that we don't bloat temporary hardware assets with expensive and unused software. 

 

Hardware Support & Maintenance Process:  Setting Hardware Asset Support & Maintenance is somewhat different from its software cousin, insofar as the business has to assess the role that the hardware assets will fulfil.  Accordingly, based on such a review, the level of cover can be determined and placed alongside the purchase price of the devices.  Another important step that differs from software support and maintenance is to which budget the coverage can be assigned to.  Hardware might be brought into an organisation as part of a programme or project, and so that programme or project bears the cost of the initial coverage sought.  However, once the assets attain BAU status, the support and maintenance will be subject to another (typically annual) review, at which point either the system or service owner will be asked to make a call on which budget the support and maintenance should come from.  Obviously, if devices are brought straight into BAU then this is a step that doesn't need to be taken.  The impact on SAM of this process is bordering on the minimal, but what can it can do for the business (and SAM) is to highlight those assets which are of particular importance to the business.  Therefore, if any SAM services revolve around such VIP devices, then an appropriate level of heightened response can be applied to any software asset queries.  A watch-word for our SAM colleagues here:  Project and Programme implementations of IT services invariably act as a back door to introducing new software - these are the deals I often hear about being made on the golf course or over lunch that has little to do with IT due diligence, but a whole heap to do with massive IT spend, major disruption to BAU operations and Shadow IT.  If you can't be on the golf course, try to make sure your CIO realises the consequences of IT governance by proxy.

 

Asset Repair Process:  The primary driver for this process is to ensure business continuity; either through the repair of a hardware asset, and/or in handing off to the Loan Equipment Process to ensure that employees are not prevented from carrying out their work.  This process won't impinge on SAM too highly; although your business might require some exception handling for those titles that are locked to devices, and need installing on loaned machines.  Where SAM might get involved, is if the device is declared beyond economic repair, and so hands off to the hardware disposal process.  Once such an activity has been completed, then a destruction certificate should act as a trigger to purge/archive this device from your inventory system (if that is used to gather installation data) and/or from your SAM suite, if SAM suite agents were used to provide installation data.  As previously mentioned, your SAM Suite and/or Inventory System will not know the difference between a missing machine and a scrapped version of same.

 

Lost & Stolen Devices Process: This process should operate hand in hand with your Joiners, Movers and Leavers Process, so that if it is discovered devices have "gone missing" then they company can take appropriate action to potentially recover the value of the lost/stolen device if it is determined that the liability for the loss/theft lies with the employee.  This should not be an IT-only driven initiative, it is an aspect of management which should have HR engagement, as without referencing the potential recovery of the cost of IT hardware assets from salaries, you could be exposing your company to increased HR strife and counter-claims of "I didn't know that was the routine, nor was it something I agreed to." Stolen devices will require a formal crime number to validate that a potential crime has taken place; lost and stolen devices will need to be updated in a hardware asset/CMDB and even a risk register with their updated status.

 

Risk register I hear you cry?  The risk in this instance will be access to data; clearly remote wiping routines will need to be enacted for such devices, (thereby reducing our software instance counts (small beer, I know).  But of greater significance will be the shutting down of access to corporate data, and also personal data.  GDPR is on everyone's radar, and having ready processes in place to mitigate data loss will be pivotal to demonstrating proactive personal data management.

 

Hardware Asset Disposal Process:  It's easy to see how the use-cases can call upon the numerous activities and processes that comprise a hardware asset management lifecycle.  The discussion around asset repair earlier in this article suggested linking with the Hardware Asset Disposal Process if a device is beyond economic repair.  We also have a couple of other use-cases that need addressing through this process, and that would BAU equipment that has reached end of life, and leased equipment is to be returned to the leasing company.  Again, we need to ensure that all devices follow appropriate data-wiping protocols (as governed by Info Sec and GDPR guidelines); but that as with loss and stolen devices, we purge/archive such records from our inventory and SAM suite software.  The issue of leased devices is worth qualifying, as typically such equipment has to be returned in the configuration in which it was supplied; so leased devices don't need wiping - more likely re-imaging should do the trick. 

 

You might also reach a point where the removal of a particular device removes the last instance of a software title.  This might then call for a refresh of your Supported Software Catalogue - so as to prevent future users from asking for it back.  It's a long-shot, I know, but worth watching out for; particularly in the server space.

 

Hardware Asset Verification Process: At SAM Charter, we have a similar process for the software side, where we look to verify the software boundary of our SAM scope by comparing Anti-Virus installation data against our software asset inventory data, based on the premise that every device should have both anti-virus and inventory agents installed on them.

 

The deltas between the comparison should highlight devices that aren't secure, and devices that are not being measured.

 

A slight tweak on this approach could also be used to compare entries in a CMDB (which, if you remember from our asset tagging process, are introduced encoded from the point of delivery).

 

A third mix of data from the CMDB could produce 3 delta reports:

 

  • Devices that are hardware tagged, with AV, but no SAM agent
  • Devices that are hardware tagged, with a SAM agent, but no AV
  • Devices with a SAM Agent and AV, but have no hardware tag/record

 

The periodic output of such a process should keep information stores refreshed, but also result in some root cause analysis as to why certain devices might have snuck into the company without going through accepted channels.

 

Physical Audit Process:  Not every company will have all of its hardware assets networked; and so a means of remotely assessing those devices for their existence (as well as the software contained on them) is worth embarking upon. Also, a physical audit process could be used to qualify the location of networked devices if it was important that such machines maintained a physical presence in a specific location.

 

Summary:

 

With licence management becoming ever-more hardware oriented, it would be naïve of anyone to think that software asset management is achievable without paying due regard to hardware assets - particularly in the server/ virtualised space.  However, a little bit of foresight in respect of more traditional hardware assets can also make life easier (and more accurate) for SAM.

 

Once your company starts aiming at this level of Asset Management, then the use-cases and reporting possibilities can also start to rise in terms of quality and complexity; offering greater benefits to IT and to the business at large.  Furthermore, the prospect of creating and maintaining a CMDB become more like an achievable goal rather than a salesman pitch of just how easy it all is.

 

Capacity Management and Configuration Management are now no longer theoretical exercises; core data required to plot upper and lower limits of acceptable IT provision to given services can be ramped up based on accurate information.  ITIL now seems plausible, as does value-chain analysis.  The principle and work applied to capacity management for on-prem and physical IT assets will then act as a valuable lesson in scoping capacity for as-a-service assets also.

 

As always, I would welcome your thoughts on HAM and the tales from the trenches you have experienced in its relations with SAM.  My personal experience has been that too many senior managers somehow expect HAM to follow as a natural extension of SAM - a bit like adding an extra software vendor onto your SAM portfolio. 

Outcomes