If there’s one thing that’s paramount, it’s streamlining the process of acquiring software. Without an efficient procedure, the time it takes to process a user’s request may delay the software’s availability to that user or, even worse, encourage the use of shortcuts that will compromise the company’s IT security or software compliance (hence the wonderful job of a software asset manager).

I will therefore try to highlight the complexity and a fortiori the important time (from an end-user’s point of view) that this software acquisition process takes to answer a purchase request until the software is installed on the end-user’s machine. Therefore, we are not talking here about software engineering.

I will give in this article the list, which I hope will be exhaustive, of tasks/actions that result from a software acquisition process.

Finally, the purpose of this article, as I mentioned above, is to show that the software acquisition process is not always a long, quiet river!

Different types of software acquisition

A software acquisition process can be derived in several types, from the most complex to the least complex to manage:

1.      The acquisition request concerns the software of a new editor for the company.

2.      The acquisition request concerns the software of a publisher already existing in the company.

3.      The acquisition request concerns an additional license of an existing software already in the company.

4.      The acquisition request concerns the renewal of maintenance or subscription of existing licenses.

At this stage, it may be important to differentiate between software (simply, the application that is used by the end user) and a license (simply, the file that allows the end user to use an application). The software “sold off the shelf” (COTS: commercial off-the-shelf) remains the inalienable property of the publisher and the license is what the company pays for the right under certain conditions to use the software.

Renewal of maintenance or subscription of existing licenses (point 4 above) is an internal process within the IT department that is not normally triggered by a specific request from the software user department. In my school case, I chose to place the IT department under the responsibility of the CFO of my ideal company. It is therefore the IT operations department that manages the software purchase budget and centralizes all hardware purchase requests.

Actions in the process of acquiring additional licenses

I have chosen to illustrate my point by taking the case of the request to purchase additional licenses. The list of actions for the acquisition of an application (the executable part of the software) from a new software vendor or the acquisition of a new application from an existing software vendor is very similar to the case detailed below.

In this example, which is based on a real business case, the purchase of additional licenses is discussed in the following context:

1.      The end user needs the latest version of the software.

2.      The information (VAT, contact, address, … ) concerning the software publisher and/or reseller is not up to date in the company’s supplier management system.

3.      The license agreement has not been reviewed by the company’s legal department.

4.      Licenses should not be issued until the invoice is paid.

All actions resulting from the license acquisition process may involve a large number of stakeholders depending on the size of the company and many interactions between these stakeholders (which will be written in bold below) occurring during the acquisition process.

These are all blocking points that may hinder the delivery of the license in a time frame acceptable to the end user.

All of the actions in the acquisition process have been grouped below into several specific areas.

Qualification of the Demand

Depending on the size of the company, the qualification of the application will involve several stakeholders. Whether it comes from an end user or a project manager, the request must be approved by the engineering director after the engineering application support manager has ensured that the request is legitimate: is there a real need for additional licenses? Is the version change a project request? Doesn’t the new software duplicate software already used by the company?… This important work is carried out with the Software Asset Manager and, within a large structure, with the Engineering/Computer Interdepartment Interface Manager.

In the case of the acquisition of new software, a supplementary budget request will have to be approved by the CFO if the CAPEX budget is not sufficient. This article does not address the CFO’s involvement in the validation of Engineering requests, which results in longer approval times.

Once the application is qualified at the engineering department level, it is submitted to the company’s IT operations department. In our ideal case, our company uses ServiceNow, an IT Service Management (ITSM) tool.

The request, once logged into ServiceNow, will be processed several times before being definitively validated, triggering the release of the new version of the requested software and the update of the license server required by the acquisition of the additional licenses.

As we will see, the entire process of acquiring software (in our case additional licenses) takes time, which is not clearly understood and perceived by the end user.

This is all the more true when the request must be validated by the IT security department.

Indeed, the installation of a new software, a new version or a license file is not harmless in terms of IT security or infrastructure management. For example, a new version of software may require the installation of a new operating system, a new license management tool (License Manager) or the creation of a new license server when the publisher imposes a physical machine to host its licenses rather than a virtual machine, as is the case for Dassault Systèmes licenses for example.

This work is often assigned to enterprise architects who are able to assess the impact of change requests on the IT environment and its repercussions on the company’s activities.

Once the “innocuousness” of the software has been validated by the IT security engineer, and the request has been approved by the enterprise architect, the IT Asset administrator will contact the vendor to ask for a quote.
 
Request for quotation and SLA (Software License Agreement)

In the case of a renewal of the maintenance of permanent licenses, the quotation is usually sent automatically by the vendor between 30 and 90 days before the expiration of the licenses. It is important to ensure that the quote has been sent to avoid the risk that the license acquisition process will start too late and that licenses will not be received before their expiration date and that temporary licenses will have to be requested from the vendor, which will complicate the task of the IT department in charge of installing the license files (the temporary license file and then the permanent license file).

In our example, since additional licenses are to be acquired, the quotation must be requested from the vendor by the IT Asset administrator. The Software Asset Manager (SAM) will take care of this in a small structure and will ask the vendor to send him the quote and the software license agreement (SLA).

An important check must be made at this stage regarding the license agreement. The SAM must ensure that a previous version of the SLA exists and has been reviewed by the company’s Legal Department and that this previous version has been signed by an authorized person. If not, the SLA must be reviewed again by the Legal Department. The requirement for this review is detailed in the “Legal Review” section below.