In this Lightning Course, Chris Hayes, Manager of SAM Program Design, covers each phase of the Software Asset Lifecycle. Click on the links below to jump to each phase:
- Identify the Need for Software
- Submit a Software Request
- Procure the Software Licenses
- Assign & Distribute Software Licenses
- Deploy & Monitor Software Licenses
- Decommission Software Licenses
Feel free to reach out to us if you have any questions or would like more details about the phases of the software asset lifecycle.
Identify the Need For Software
This phase in the software asset lifecycle includes understanding why and how requests for software are generated in your organization.
You may be thinking—why do we have to identify need at all? If I request software, then I obviously need it, right? A mature SAM program always tries to optimize wherever possible—so while there may be a need for software, it is important that money is saved instead of automatically spent with each request.
It is important to understand WHY and HOW software requests are being generated. If I asked you to compare how many software requests in your organization follow a controlled and standard channel versus an ad-hoc process, would you know? Would you even know who you could ask to find out? What Software Asset Management should support in the Identifying Need phase is a controlled, gatekeeping function that ensures needs are supported by analysis, and that any non-standard requests are appropriately scrutinized. In this way, you will ensure that potentially risky, non-managed or non-controlled software will not be freely entering your organization without an approval or audit trail.
Each request for software should be justified with appropriate due diligence. The business area in your organization requiring software should perform an analysis versus their functional requirements, budget availability, and strategy so they are able to justify spending money on software. In some cases, this is as simple as an additional headcount needs to have Adobe Acrobat Professional to perform their job duties, in which case an operating budget would easily cover the proposed expense. In others, it could be a longer and more complex justification process to support a larger project or investment.
If a software request can NOT justify a need for spending money or is NOT accompanied by sufficient analysis, then it should be denied by the Software Asset Management team. This becomes less of a financial management function and more of a corporate governance function. It is recommended that you develop a policy to support adherence to this behavior, and support a culture of due diligence within your organization.
Best practice is to develop a Software Catalog which includes pre-approved items for end users to request. Each requestable item should include a cost. This will drive accountability of the business area requesting software since they will see the cost impact and need to be able to justify the expense.
Submit a Request for Software
Software Requests need to consider that the end-to-end process should be easy for end users and be automated where possible to shorten time to value. End users want their software ASAP—and if your process is overly engineered or overly complicated, it will not be followed. That creates risk because you will then have end users taking the path of least resistance—in other words, utilizing corporate credit cards or following up directly with their buddy in Procurement to circumvent the process.
Similar to the Identifying Need phase in the software asset lifecycle, we will utilize a Software Catalog in the Submit Request phase. This takes a lot of guesswork out of the equation. End users will be required to select from a standardized listing of software instead of coming up with their own ideas. This can also be a method to standardize and correct end-user behavior. If a non-standard request (i.e. not in the Software Catalog) is input into the process, this should trigger a review by an Asset Acquisition Committee. This is usually a group of cross functional participants who will help evaluate the request—IT Security, IT Infrastructure or Architecture Management, Service Desk or Helpdesk, and the software asset management Lead, among others. If the non-standard request does not pass evaluation from any of these groups, it is denied, and the end user is re-directed back to the Software Catalog to choose from one of the pre-approved options. Again- you want to ensure that the entire process is quick and easy for the end user, otherwise if their non-standard request is declined the will find an alternative method of procurement.
So to facilitate an effective Request process in the software asset lifecycle, you will need automation, cooperation from other areas of the business, and a Software Catalog that aids in categorizing end user requests. But how will you ensure that end users will utilize this option in the first place? Via Policy Management. As much as possible you should remove alternate options to your Software Request process—for example, shutting down an IT to IT request portal, not approving reimbursements for software purchases on corporate credit cards, blocking user access to software purchasing websites provided by the publishers. End users also need to be aware of what constitutes acceptable behavior when requesting software, why this is so important, and what the potential consequences are if they do not conform to the policy. In this way you will provide an efficient and smooth process, eliminate potentially risky alternatives, and support governance of acceptable behavior.
Procuring Licenses in The Software Asset Lifecycle
In the last phase of the software asset lifecycle, the Submit Request phase, we focused on a couple of concepts to take forward here. First was the Software Catalog. If you have a standardized catalog of products instead of a steady stream of free text request from end users, this helps Procurement do a few things. First, they are able to source a standardized group of items from a smaller set of VARs (Value Added Resellers). If the Procurement team knows what your product list is that end users will typically be purchasing, they can provide this to multiple VARs and get the best possible price.
We also discussed automation in the previous lifecycle phase. A final critical aspect of Submitting a Request should be the check if there is an actual need to proceed to the Procure License phase at all. At minimum, requests for software should be reviewed manually by the SAM Team to check if there are spare licenses to utilize. If there ARE spare licenses, the request should go directly into provisioning, or installing the software for the end user. What is the cheapest type of software for your organization? The kind where you don’t have to purchase a new license and can optimize your investment on already existing licenses. In an ideal scenario, this check for spare licenses should be automatically integrated between your Service Management/Request system and your ITAM repository.
Before a license is actually purchased, the budget responsible party will have to OK the costs. This is also best practice—included in the Software Catalog should be a cost for each software item that is requestable. This will drive correct behavior of end users and their managers since they will have to accept that requesting software will take money from their budget.
When Procurement is entering in a purchase in their ERP system, best practice is to capture Line Item level detail. For example, it would be very difficult for the SAM team to generate a license balance if the license entitlement information read ‘Microsoft Contract, year 2 of 3, $1 million’. Make sure each purchase includes the SKU or stock keeping unit, the product description from the VAR or software publisher, quantity purchased, and a cost per item. With these granular datapoints, there is a larger potential to automatically integrate the ERP system and your ITAM repository.
Software Catalog management and automation from the SAM function helps to make Procurement’s lives easier when purchasing software. And if Procurement capture detailed information about each software line item, they can repay the favor in supporting greater transparency for SAM as well as potential for integrations.
Assign & Distribute Software Licenses
This phase will cover the steps following Procurement, but before the actual installation and deployment of the license happens.
Best practice for this process area is to ensure your organization has clearly communicated, understood, and consistently applied procedures, as well as roles and responsibilities to ensure that the data points you will need to manage for successful software asset management are being captured as a result of the acquisition of software. This should be happening upfront, and as much as possible be automated. By that I mean that once a Purchase Order is made, the record will always be searchable in the ERP system and Procurement always follows the same procedure. Once an invoice is sent, it always is recorded in the financial management system the same way utilizing the same procedure. If everyone supporting SAM in other departments are consistently gathering the correct datapoints directly following the acquisition of software, this will save a LOT of time and energy should there ever be an issue or compliance challenge to your organization.
Continuing with this principle, let’s think about assigning and/or distributing a license. We are not installing software or sending actual bits to the end user just yet, that will happen in the Deployment and Monitoring phase. We do need to consider a couple of process steps before we can assign a license to an end user. First, we want to ensure that we have a valid purchase order, and a paid invoice. In other words, that the organization has multiple documents that can prove they legally acquired the right to install a software license (a license entitlement). Until this license entitlement can be proven by your organization, assigning or distributing a license to an end user could potentially put you out of compliance. Best practice here could include policy language to that effect—for example ‘License Assignments and Distribution can ONLY take place when accompanied by a Purchase Order and paid Invoice.’
If you are doing a preventative check to ensure you have license entitlement before you Assign or Distribute licenses to an end user that is only part of the puzzle. Best practice would recommend a check on the licensing Terms and Conditions to determine if you CAN allocate a license to the specific end user that is requesting it. For example, if you have a Site license for a particular software application, and the user is working at a different Site, assigning this license to that end user would create a potential compliance issue. So it is not only important to ensure you have a license entitlement before assigning or distributing a license to an end user, but it is critically important that your organization understand any other limitations based on the Contract or License Agreement. For this reason the SAM Team needs to review and approve license assignments and distributions.
Please note—the limitations and restrictions can go both ways. Sometimes this means that more process controls are required (for example not assigning licenses to users at a specific site). In other instances however a license may not need to be assigned to a specific user at all. It is the SAM Team’s responsibility to be expert with the terms and conditions affecting software contracts, and to facilitate effective governance of the Assignment and Distribution lifecycle phase to ensure that potential compliance risks are being mitigated.
Deploy & Monitor Software Licenses
This phase will cover the steps of installing the application and ensuring that it is being used in an optimized way.
I’d like to bring up a topic we covered in the Identify Need and Submit Request phases of the software asset lifecycle—the Software Catalog. It functioned there as a gatekeeper, helping to ensure that a pre-defined standard list of items would be selected and that the SAM Team could manage by exception. When deploying software, the best practice is to ensure that any item in the Software Catalog has been packaged by your application packaging team. This will facilitate automation if your ITAM repository is integrated with your ITSM system. For example—a user submits a software request from the Software Catalog. Their manager approves, and as soon as that approval is given via a ticket, a workflow could kick off that would automatically trigger SCCM to push the deployment package to the end user’s device—all without the involvement of the Service Desk or SAM teams.
When packaging software applications, you will want to take into account the ITAM Repository and your existing Discovery and Inventory capability. Ensure that you software install packages are unchanged from the software publisher and not re-named or overly customized by your application packaging team. If that happens, that could create challenges for your ITAM repository and you may not be able to automatically Discover the installation instance.
Monitoring the usage of software will require you to have a metering capability. Certain Discovery tools can also be used to meter or measure software usage, such as SCCM. There are some ITAM Repository solutions that have agent-based software metering capabilities as well. Why would you want to meter software usage? To ensure that you have installed only what you are truly using as a business. For example, you might have an installation base of 20 Microsoft Visio licenses. But if only 3 of the end users have launched the program in the last 90 days, you essentially have 17 instances of Visio not being used, but still consuming licenses. For the majority of software, the publisher bases license requirement not on the USE of the application, but on the POTENTIAL to use the application—in other words if it has been deployed in your environment. Automation is recommended here as well—if your Discovery capability can provide a report of applications that have been installed but not actively used in the last period of time, you can then take steps to de-install those instances. If you then build up an inventory of spare licenses, this can be leveraged to avoid further cost instead of purchasing new licenses, for example.
Decommission Software Licenses
This phase covers the steps of removing a software installation and ensuring that there is no remaining compliance risk.
Every item in the Software Catalog that has been packaged for deployment should also have a corresponding uninstallation package. This will facilitate the maximum potential for automation. Linking to the previous lifecycle phase of Deploying and Monitoring, if a metering report is run indicating a specific instance of software has not been actively used for a pre-determined time period, this could trigger an automated job in SCCM that would utilize the uninstallation package. Varying levels of automation could be built in here, from full end-to-end automation, to having the SAM Team first review the metering report and sending notifications before submitting a ticket for decommissioning.
It is important to remember that you should ALWAYS double check a potentially deinstalled or decommissioned application. Are there components that were not fully removed by your tool? Were elements changed in the registry? Are there third party components included with the installation that may have been missed? Best practice is to run Discovery and Inventory for the affected devices, then perform your de-installation, then run Discovery and Inventory AGAIN to ensure that all traces of the application have truly been removed from the machine. As mentioned in the Deploying and Monitoring lifecycle phase, the majority of software publishers will focus on whether there is a POTENTIAL to use software—in other words if any discoverable trace of the application can still be found in the IT environment.
When software is no longer being used, it should be re-harvested to build up a license inventory, thereby ensuring that the investment made by the organization is maximized. Only software that is actively being used should be installed and therefore consuming a license entitlement. There are a couple of other scenarios where we should be de-installing or decommissioning software. First, if the underlying hardware that the software is installed on has reached the end of its useful life or is being sent for IT Asset Disposal. Instead of utilizing our Discovery solution or ITAM Repository agents, typically what happens here is that the hard drive is wiped, and then shredded or degaussed to ensure it is unusable. Best practice is to ensure that the software installation records associated with this hardware are removed (usually this happens on the next Discovery scan). In this way you will build up a repository of spare licenses. As mentioned in the Assignment and Distribute License phase, before these spare licenses are re-assigned it is crucial to understand the terms and conditions involved with the specific license contract for that software publisher. Another scenario involves legacy or outdated software. The Information Security department, IT Architecture, as well as Application Owners should have a regular cadence of meetings established with the SAM Team to update them on applications that have reached the end of their support life. This means that their software publisher is no longer offering security patches and will not take support calls to fix the software if there are issues. In these instances, it is recommended that this software be removed from the end users devices so it does not pose a security threat to the organization. Removing this software will not be to re-harvest the license for further use, but rather to decommission it entirely during the software asset lifecycle process.