Skip navigation
All Places > Snow Product Hub > General Licensing Forums > Blog > 2017 > September

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.




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. 

To safeguard valuable information assets from unauthorized use, IT departments use methods like partitioning, authentication, and firewalling. To access these assets, the workforce of the 21st century use a range of techniques on devices such as laptops, desktops, tablets, phones, and watches. Many of these devices are mobile, facilitating access to valuable information from anywhere, at any time, over networks that may not be secure. And often, devices are being used to access information without being authorized to do so. Such behavior presents risk. IT departments however, need to shift from the position of restricting access for the sake of security, to providing access while maintaining security. SAM can provide the visibility required for the IT department to become the technology enabler and support the organization’s needs, without compromising security.

Getting the right balance between protection and availability is a classic security conundrum – a problem made more complex by technology, device proliferation, and tech-savvy users. To unravel some of that complexity, I believe that insight is critical. You can’t protect something if you don’t know it exists. Modern user behaviour undermines IT in their efforts to ensure that there are no blind spots in the network. So, let’s dig a little deeper into the behaviours and challenges that impact the ability to achieve full visibility of the IT estate.


Technology evolution has enabled information assets to be accessed, modified, shared, and deleted through any device, from anywhere. The mass adoption of mobile technology, cloud computing, and constant connectivity has effectively shifted the responsibility to protect assets from the IT department down to the individual user – each with their own experiences and level of security awareness.


Tech savvy employees don’t care to wait. Mobile devices have empowered people to download software as they need it, make use of it, and then forget about it. Waiting for approval, paying for licenses, and understanding the impact of licensing terms and conditions (T&Cs) tend to be low on the list of priorities when deadlines need to be met. People work from anywhere and use their own devices and applications (BYOD/BYOT) as well as those provided by their employers (Company Owned, Personally Enabled: COPE). In response to this shift, software publishers like Adobe and Microsoft have changed the way they license their products, providing users with greater flexibility.


Organizations that enforce tight security measures see their employees moving on, or circumventing set procedures in the name of digital expediency. The spread of the wannacry worm is just one example that highlights the risk faced by organizations using out of date technologies. With the GDPR coming into force, many companies are reviewing data security processes to ensure compliance, and are turning to technology to get the right balance between employee flexibility and overly-tight security.


I, for example, use a cloud-based app to share photos and files with my family and friends. The license terms state that the app is free for personal use. So, what happens when I share information from my private cloud space with one of my colleagues using a public Wi-Fi hotspot? Not only am I exposing my employer to the risk of data leaks by using an insecure network, I am breaching the T&Cs of the software agreement. A deeper investigation of the T&Cs reveals that if more than a dozen people within my organisation start using the app to share information, my employer is liable for a business license for each user. But neither my CFO, nor the IT department will be aware of this liability until an audit is a fact (read more in our blog on Managing mobile device usage agreements).


So, how is it possible to gain a 360-degree insight into the software estate when BYOD, new devices, technology evolution, user behaviour, and lack of awareness work to undermine IT and security teams and their efforts to keep a grip on the network estate? SAM managers have a key role to play because the solutions they rely on provide them with this insight. Gaining insight starts with Inventory of the software estate – ensuring that the blind spots are picked up, as they are often a source of risk. Enterprise mobility management (EMM) solutions, such as Snow Device Manager, inventory the mobile park, and deliver mobile SAM capabilities. They can, for example, provide a software store of approved applications, delivering sufficient freedom to users while at the same time ensuring license compliance. Security measures, such as remote wipe for lost devices, data encryption, and removal of blacklisted applications, will help organizations to protect information assets and personally identifiable information (PII). Automation tools like Snow Automation Platform enable the IT team to, for example, provision devices automatically with local network settings, improving security through generated passwords that are never shared with users. By controlling settings and automating common processes, human-error is reduced and the power of cloud computing can be unleashed securely into the organization.


BYOD isn’t going away, smartwatches are the next device that corporations will need to address, and the complexity in achieving the balance between protection and ease of information access will continue to rise as technology evolves. Achieving this balance is a constant journey of reassessment that starts with getting to know your unknown unknowns. With a deeper understanding of what is going on in the network, SAM managers visibility provides the insight that is vital to build secure IT environments. Learn more about multiplatform inventory to gain complete visibility of your IT estate by having a read of our eBook: Remove Your IT Blind Spots.

While the road to good SAM has been given plenty of band-width, and numerous courses have sprung up on what to do with software assets, less attention has been given to what steps should be taken to ensure that the platforms that underpin our SAM efforts are given proper care and attention.


The following two blogs will highlight some of the pertinent aspects relating to Hardware Asset Management as they could impact Software Asset Management.


As ever, if we understand that our ELP is gradually being eroded by IT change, then it is our ability to react to change that seeks to mitigate quality erosion  Rather like our grandmothers keeping the plastic covering on newly-bought furniture, we are not able to shroud our IT estate in a protective layer so as to reinforce the quality of our SAM reports.


If we can't cure change then we should mitigate it.  How do we do that?  You guessed it, through processes!  Thankfully, the processes that are already well documented for SAM, are transposable to HAM also.


The following have been documented in no preferred order, but do offer pointers as to where the hardware element can influence SAM.


Joiners, Movers and Leavers Process:  Many reasons exist as to why we should ensure that our management of hardware assets follows the employee lifecycle.  As I have previously mentioned, no company pays its staff after they have left the company - so why should ex-employees reasonably expect to use company assets once they have left? That though, is the all-too common experience.  Mobile devices, phones and tablets have an uncanny knack of "going missing"  And so, while the individual value of such items doesn't warrant setting off corporate alarms (write-off values of £3,000 are not uncommon) the accumulative effect of such a policy could result in an ever-escalating insurance claim when such assets are declared as "lost".  An additional concern for corporations pertaining to the mismanagement of mobile devices is that of security.  Fines are ever-escalating for the loss of data (through misplaced accessible mobile devices) and regulation such as GDPR would look to impose eye-watering fines for breaches in respect of loss of personal data.


Suddenly, the use-case to track hardware assets in sync with an employee's lifecycle looks like common sense, not merely best-practice.


Asset Request & Deployment Process:  As with a software request process, this process would look to conduct the following checks:


Line Management Approval

IT Approval

Does the hardware asset currently reside in stock?


The added caveat to this would be that the device would then have its status amended from "in-stock" to "live".  With software, we leave such a distinction to be resolved through daily software inventory sweeps - for hardware, such status changes are made at the point of change.  The advantage to SAM in knowing that devices are live on the network is that IT operations/ Service Management will have vetted such devices and pre-qualified them as company assets; thereby assisting SAM in knowing that any software found on those devices will have to be accounted for.  This process also marries up with SAM from the point of view that a pre-requisite of any build scenario should include the installation of an inventory agent - without it, SAM can become an even bigger mountain to climb. 


Hardware Procurement Process:  What checks should we be conducting when the request for a new hardware asset is made?  Eerily enough, very similar checks to a Software Procurement Process:


Has the request come through official channels?

Does the requested hardware fall under a given contract?

Does the requested hardware require support & maintenance?

Does the total amount of the hardware order trigger an Invitation to Tender Process?

Is the requested Hardware on an approved list provided by IT?


One might argue that some of these checks should (rightly) take place at the request process; however, Procurement will have their own due-diligence to satisfy (checks and balances etc.).


Stock Management Process:  An all-too-common misconception within SAM, is that if a device is not live to the network, then the software that resides on that device does not have to be accounted for - e.g. loan equipment on standby, or decommissioned equipment in storage awaiting disposal.




Installation is the key word here.  And so, a ready means has to be in place to integrate such devices into SAM reports.  Of equal significance from the HAM side of life, is to ensure that the correct status for this asset is kept up to date, typically in either a Hardware Asset Register or even a CMDB.  That way, when a device is required to go live, it's location and even position in a store can be pin-pointed.  Greater accuracy equates to a faster roll-out - so customer satisfaction is a primary KPI here.


For the manufacturing devotees, we also have to doff our hat in the direction of JIT (Just in Time) and this is the principle that money in stock is dead money i.e. you can put your financial capital to better use around the company rather than having it sat on a shelf for when it might be needed.  Understanding your company's degree of IT churn will help set limits on what and isn't permissible to have sat on a shelf.  Such a concept cascades to Vendor Management, and how quickly and accurately (in terms of base-software build) a supplier can provide you with your hardware assets.  Setting Service Level Agreements should be in sync with the IT churn mentioned above.


Asset status is a further driver to compliance accuracy and value for money in SAM, as the status of certain assets could relax licence terms and conditions - an accurate understanding of the roles of your devices (particularly in the datacenter) is vital to make maximum use of your software contracts.  A word of warning though:  It may sound obvious, but just because one software vendor rules that development devices are exempt from a production licence of their software, does not mean that other software vendors view development arenas in the same way.  The same warning applies to clustering, failover, high-availability, and any other status of hardware device that crops up in your IT estate. 


A long-held practice within HAM that is skimmed in software asset management, would be the act of tagging.  Hardware tagging is a core component of HAM, and so such a pre-requisite might well be addressed as an SLA with the hardware provider, so that devices equating to specific classes will come with a unique bar-code or even RFiD code on them from the point of delivery.  Once more, a cost-benefit analysis needs to be undertaken to assess whether the hardware reselling company conducts this work for you, or you have spare pairs of hands within the IT team that can perform this duty.  The advantage of asking the hardware resellers to do this, is that the bar code can be used to distinguish a job-lot of hardware assets on the paperwork.  This makes the job of populating a CMDB far easier, and also of tracking hardware items from the goods-in bay through to the IT department, the stock cupboard, or indeed straight to production.


Those items (such as servers) which underpin business and mission critical services, might well benefit from RFiD tags.  Although largely static in nature, it's amazing how easy it can be to lose a server in a datacenter - the analogy of hiding trees in a forest is quite appropriate here.  The significance of getting hardware devices tagged and entered into your CMDB at source, is that devices can be aligned to services.  Between tagging hardware, and inventorying software on those hardware devices, the IT department stands a real chance of being able to offer value-chain analysis to the business of what IT costs, compared to the fiscal benefit a service might deliver.  This is high-end ITAM - but ever more difficult to achieve if such fundamental steps are not taken.


Another aspect that such tagging and identification of hardware assets assists with, is the role that such devices can or do serve.  If key devices have been identified as performing specific roles such as stand-by, back-up or failover, then licensing such devices will be made easier.  Equally, when such devices are called into action, then we will be fore-warned with the knowledge that the devices are properly licensed, and we will know how long we have to retain that configuration within our IT estate before the software can roll-back to the former/ live device - if such licensing restrictions apply.


Furthermore, if we are able to link the software and hardware that provides services to our company, then we can come to the benefit of our architecture and network colleagues also.  Getting a broadcast/ 60,000 ft view of our IT estate is all well and good, but being able to sub-divide that into an ITIL-based view of our IT estate is not as simple as merely installing an inventory agent.


More to follow in Part II....

I was recently asked to comment on a LinkedIn post asking whether Software Asset Management has any unique aspects to it that pertain to education. A fine question, and one that I thought was worthy of greater examination than in the relatively short space that LinkedIn offers for its replies.


First and foremost, education falls into the public-sector bracket, and so straight away any contracts to be negotiated should be actioned under such an umbrella.  It sounds obvious, and is where resellers should steer educational establishments for six and seven-figure contracts; but that's not to say that other (smaller) deals should not also be transacted in such a fashion.  The benefit of operating under an educational umbrella is that (typically) a vastly reduced price point compared to its commercial equivalent is measured against the FTE head-count for establishment-wide software.  In the UK, such a figure is required by the Department of Education (specifically HESA - Higher Education Statistics Agency) for numerous calculations and payments from central government.  So obtaining an up to date figure from which to use in contract pricing calculations may not be the Gordian knot it first appears to be.  It would be nice to colour all software in a higher educational establishment as academic, however, software vendors are increasingly coming to realise that several shades of grey exist:


Academic:  For students to learn and study with

Commercial:  For the university to transact the educational lifecycle

The grey bit:  Senior (Masters & PhD-level) students who might be in business incubators who take academic software and start to use it for commercial purposes.


How software vendors view education:  Generally, education establishments are not given as a hard a time when conducting software audits - although certain software vendors are starting to buck that trend.  I know of one 20,000+ seat organisation in the UK that took exception to their treatment by a global database provider, and subsequent to a protracted settlement have made it their life's mission to remove all of that vendor's software from their IT estate.


Educational Rock-stars:  Where education suffers more than most with SAM is that as well as providing a springboard for our youth into commerce, many educational establishments are still not clear on the boundaries between academic and commercial use of software.  It's not necessarily the full-time IT staff that are the worst offenders; universities do their best to attract the best and the brightest students and tutors and look to furnish them with whatever resources they need to drive progress in their respective fields of study.  In return for pledging academic allegiance to a university, the university grants such stars financial "elbow-room" to spend grants and academic funds as they see fit.  Accordingly, purchases are most likely not centralized, which leads to pockets of shadow IT springing up like whack-a-moles on speed.  This situation is made yet more complicated if such funding is provided through joint-ventures, either with other universities or commercial organisations.  Another educational establishment I was at had an Educational Agreement in place with Microsoft, and so (at the time - circa 2012) could have purchased an instance of Visio 2010 professional for approximately £39.  However, due to the commercial liberty granted to budget holders, numerous receipts were being presented to the university for the full-blown retail instance costing in excess of £390.  I'm sure the licensing gurus could wax-lyrical about the limitations of the retail instance, but the economic drawback is eye-watering.


Licence Pools:  If your educational establishment is comprised of multiple colleges or faculties, then such sub-units can get very attached to the software they buy.  If the university then embarks upon a software recycling exercise, it will most likely find that it has to maintain multiple licence pools - one large one for software that has been bought centrally and can be deployed anywhere in its domain, and smaller pools that hold software the colleges or faculties bought, but can only be re-deployed back to that college or faculty.  This is no small feat.


Risk vs. Reward:  In a previous blog we touched on the merits of creating a Supported Software Catalogue; it establishes a boundary for the SAM/ITAM team to say: "This is the software we are offering management overhead to - and no more".  However, as we alluded to earlier, the academic liberty granted to budget holders to spend their funds in whatever manner they like, means that the management overhead in seeking to maintain a Supported Software Catalogue could be greater than the time and resources the university has to oversee SAM as a whole.  If ever an institution could demonstrate a risk vs. reward approach to SAM, then a university is surely the place to see this put into practice.  If a bell-curve was created of software installations in a typical university, then the respective tails at either side of the volume installations would struggle to fit on an A1 sheet of paper.


Choice of Software:  In letting academics choose the titles they wish to instruct in, the educational establishment is trusting that they will pick the latest release of that software to demonstrate the educational point trying to be conveyed.  However, tutors are indeed human, and are prone to habit and routine.  Again, circa 2012, we conducted an inventory sweep of a university's IT estate and found that Adobe CS2 was actively being used as part of a lesson plan.  Had I been a student on that course, I might well have raised hell about this:  I could have finished a 3-year course and been adjudged a professional user of 10-year old software, and largely unemployable because my learning curve hadn't kept up with the versions deployed in business.


This is a problem not just for the students, but also for the university:  tertiary education is a hot-bed of competition and increasingly establishments are not merely competing with their geographic neighbours, but with the rest of the world (due in large part to on line study).  If a university is not able to offer industry-standard software in its courses, then it is losing ground to its competitors.


Conclusion:  Software vendors may not feel as rapacious when it comes to launching audits in education as they might in commerce, due in large part to the fact that their future fan-base is being shaped in this section of the public-sector.  Additionally, if discounted pricing is already being offered to education, then the pickings resulting from non-compliance are not going to be as great as if full commercial pricing was being applied to an audit scenario.


Interestingly though, the drivers for education remain the same as the public sector - value for money, and profits through the attraction of students in using the most appealing/employable software they can get their hands on.