Process of the Month – Software Removal Process
I had some fun deciding on whether to call this a software retirement process, or whether it should be what I settled on (above). However, the decision to Retire software is taken in a different process (Maintain a Supported Software Catalogue), and so it felt more appropriate to refer to this process as I have done.
Clearly software removal is quite pivotal to SAM, and this can be highlighted perhaps by the number of processes that can instigate it (Four is the highest number of processes that has been modelled to kick-start another process). The removal of software provides many benefits, but the three main ones are:
- It aids your Help Desk in not having to support every release, version and edition of software your company might have used in the past.
- By staying on trend with product releases your company is better placed to avail of the improvements built-in to such products, rather than having your staff work in outmoded ways simply because prior versions don’t have function A, B or C….
- Removing software that is no longer of commercial benefit can offer a residual value through re-sale (See ITAM Review: “Recycling Hardware opens the door to recycling software”)
Although I would draw a distinction between removal and recycling at this point, as Recycling implies that the software may be deployed for re-use at a later stage (See the first process in this book).
Software Removal Process
Primary Objective
- To execute the removal of “Red” software
Secondary Objective
- To advise HR on any training requirements on software replacing those titles that have been removed
Assumptions
- N/A
Function Step Overview
1.10 | Any one of four other processes can cause this process to be initiated:
At this point, if multiple processes have coincided on calls for software to be removed, then perhaps a degree of scheduling might be required by the SAM Manager to coordinate these calls. |
1.20 | At 1.20, the SAM Manager is required to inform stakeholders (including end users) of the impending removal of any red titles. The product champions and service owners should already know, in that they were involved in the decision making processes prior to this function step, but it bodes well to keep them in the loop as most likely end users could see them as a first port of call for information on how the removal might affect them. |
1.30 | At function step 1.30, the SAM Manager is required to compare the red SSC titles to the Green SSC titles, so that alternative titles to those about to be deleted can be passed on to HR to aid them with any training guidance a company may want to offer. |
1.40 | At 1.40 the comparison that has taken place in the previous function step is summarised around the training requirements of typical end users and the potential business benefit of conducting such training and/or the consequences of not undertaking training. |
1.50 | Here we see the Apps Packaging Team come into their own and remove the red titles the SAM Manager has passed to them at 1.20 in accordance with the removal schedule |
1.60 | Next the Apps Packaging Team conducts an inventory sweep to ensure that all red titles have been removed. |
1.70 | This step requires The Apps Packaging Team to make that comparison between the red title list and the inventory data they captured at 1.60 – if instances of red titles still appear on the IT estate then the Apps Packaging Team are required to re-visit 1.50 to remove those instances. |
1.80 | Subject to the successful removal of all instances of those red titles, the Configuration Manager is required to update any build schemas so that they too do not refer to any red titles. |
1.90 | Finally the Configuration Manager is also required to archive red title Proof of Entitlement, so that it does not get in the way of any audit and reconciliation activity. Best practice would dictate that such material is archived rather than destroyed, but it should be provided with adequate security controls to prevent future re-deployment/misuse. |
As highlighted in the previous processes that call on this process, do consider the consequences of removing software in light of the business impact – do those software titles form part of a wider service offering/stack that the business still uses? Could there be some regulatory or legal requirement to offer access to data that has been stored in a format only read by seemingly non-used software? If so, you will have two option here: either retain a live instance of the software for accessing that data; or port/convert the data into a more readable/modern format.
Other Process of the Month Articles:
- Software Re-harvesting Process
- Software Change Mangement Process
- Corporate Governance Process
- Maintain a Supported Software Catalogue
- Software Rationalisation Process
- Joiners, Movers and Leavers Process
- Scope Verification Process
- Named User Verification Process
- Platform Identity Process
- Software Request Process
Upcoming Process of the Month Articles:
- Process Review Process
The process kit by Rory Canavan is available from SAMcharter.com
Related articles:
About Rory Canavan
With a technical background in business and systems analysis, Rory has a wide range of first-hand experience advising numerous companies and organisations on the best practices and principles pertaining to software asset management.
This experience has been gained in both military and civil organisations, including the Royal Navy, Compaq, HP, the Federation Against Software Theft (FAST) and several software vendors
Thanks Rory for addressing this topic. There is indeed a lot of potential in it. We as tool vendor with a proactive approach to Software Asset Management automate these processes as much as possible. We have customers metering software usage. If applications have not been used for a certain time period, we either flag this to spcific resonsibles or remove the software automatically (it’s up to the customer to decide – one does this just after 60 days). As our products always ship with a fully integrated Service Catalog and Selfservice, an enduser may not only request the software from the portal (which is than approved by e.g. the manager in charge) and checked against the compliance state of the software. If thatÄs fine the provisioning will happen automatically. If not, the License Manager (or who ever in charge) will be triggered to evaluate. But mz point is: endusers will receive a booking for the software service in the portal – and may have a button to Return the software. Quite a favourite with a customers. Nevertheless I’d also say a tool can’t solve all your problems, but it certainly helps to reduce manual efforts.
Hi Thorsten,
Many thanks for your observations; automation is the way forward wherever possible, not least as this lightens the load on SAM and the Service Desk. The booking fee you mention would fit in very nicely with the Software Request Process previously covered. The advantage of such charges is that it makes staff painfully aware that nothing is free, least of all software!