Drive Organizational Behavior for Successful ITAM – Impact Behavior with a Self-Service Software Portal

By Brett Husselbaugh

Many clients have, or are in the process of implementing, some form of self-service request system, with one of the items that can be requested being software. The genesis is usually in response to user demand, and/or the desire to reduce ticket volume and the resources required to address that volume. What is often not considered are the requirements of the Software Asset Management (SAM) practice. This is generally due to the SAM practice not realizing there are SAM-specific requirements that should be driven into the design of the self-service request system for software.

A self-service software request portal is an essential element of the Software Asset Management solution to make sure that software requests are matched in real time with current entitlements, and, when deployed, that all key information is captured so that the purchase of licenses is accurately recorded (when required) along with creating the right financial behavior drivers.

There are important SAM specific design criteria for a self-service software portal. This article takes a look at what these are in order of importance.

Design Criteria 1: Speed

The software request portal must be as fast as or faster than any other conceivable way of acquiring software, as measured from the time the request is made until the time the software is installed and ready to use.

One of the largest threats to establishing and holding software license compliance is what is known as “back channel acquisition,” defined as finding a way to acquire and install software through any means other than the one(s) officially prescribed by the organization and, yes, this also happens in organizations that consider themselves to be completely “locked down,” that is, where the general user does not have privileges to install software on their workstation or laptop. What happens over time is that an appreciable quantity of deployed software will be found and counted, but it will have no corresponding purchasing information, and therefore no way of proving a licensed position.

In order to combat “back channel acquisition,” the prescribed means of acquiring software must, among other things, be the fastest and easiest possible. It is therefore important when designing the self-service channel for acquiring software that it is as fast as, or faster than, any other way of acquiring software – and that includes downloading and installing directly from the internet.

It is not good enough if the web-based front-end is fast, but continues to feed a clumsy and/or otherwise time consuming process on the back-end.

Users consider the entire cycle time – from the time they request the software until it is installed and ready for their use – not just the time it takes to fill out the initial request. In many cases, the back-end process needs to be changed to meet this requirement for software.

In addition to addressing speed for reasons of enticing people to use the prescribed ordering channel, speed is also important to encourage department/project managers to give up software licenses they are not using, so that they can be harvested and used elsewhere in the organization. One of the common complaints of employees is how long it takes to go through the software request process, and that the cycle time is a deterrent to giving up unused software (as managers do not want to have to endure the request cycle again – so they decide to continue to hold on to unused software).

Design Criteria 2: Accuracy

The software request portal must be accurate, ensuring that the title that was ordered is the title that is installed, correct both in edition and version. As with speed, accuracy is also measured across the entire request/install cycle. Accurate ordering is of no value if some title, other than what was requested, is installed.

So, how often does this happen?

A very common occurrence is where “Standard” is requested (or assumed) and “Pro” was installed. This common theme consistently results in an out-of-compliance condition.

In another example, one SAM program had created an internal “push” console, integrated with Microsoft’s SCCM product, to allow the help desk to schedule requested software to be automatically pushed and installed on the requestor’s machine. However, the wrong package was pushed on occasion because the process relied on a human being selecting the proper software package from a list of similar-looking titles, resulting in an ongoing and measurable error rate in the process.

Often, the user won’t complain, especially in the case where a different edition and/or version of the intended software were installed. So, the installation will not be corrected and an out-of-compliance condition ensues and worsens over time.

Design Criteria 3: Demand Control

The software request portal must include a built-in throttle for demand, to deter “runs” on available licenses and to maximize the probability that the software being requested will actually be put to use.

If the SAM practice is going to create value by harvesting and re-using software, the last thing needed is to make it too easy to request and consume licenses that were freed up and made available to be used again.

If not careful, creating a speedy process without a proper demand throttle can backfire, resulting in simply moving licenses from one place where they were not being used, to another place where they will also end up not being used. A simple solution to create that demand throttle is to charge for the software request, whether a license existed or not.

Design Criteria 4: Detection

The software request portal must have a reliable means to detect when the prescribed channel for requesting software has been circumvented. There must be a reliable means to audit compliance with the prescribed channel for requesting software. Circumvention must be easily detected so that proper behavior drivers can be used to continue to encourage desired behavior and/or discourage undesired behavior.

Driving Behavior

The software request portal is essentially a centerpiece of an overall behavior driver designed to influence organizational behavior to both the benefit of the organization and the practice of SAM. If done right, it acts as an incentive due to its speed and accuracy. It does however, require additional assistance as a behavior driver and that assistance is best met by implementing an internal software market with true financial incentives and disincentives.

Using a Self-Service Software Request Portal, the end-user can still be charged the same amount for the transaction as would have been the case previously, except now the charge is an intra-company transaction with the IT Asset Management (ITAM) function. What the end-user is buying from the Software Request Portal is an “authorization,” not a license. The concept is that the ITAM function takes on compliance responsibility for Managed Software List (MSL) which are titles that are controlled and managed for software compliance and are normally either ubiquitous or of high value. End-users are relieved of that responsibility. ITAM uses the automated allocation engine to optimize the coverage of authorizations with licenses.

The money from the purchase of authorizations through the software request portal is accrued in an IT accrual account. This enables taking full advantage of the true-up terms of the license.

We also have self-service harvesting (users can voluntarily harvest their software and get monetary credit) as well as auto-harvesting. Over time, many of the software portal requests can be covered via harvested licenses. So, the net result is that there is no need to go to the street to purchase licenses and, when there is a need to purchase, it is done in volume with typically another 20-30 points volume discount.

The delta in the accrual account is a growing hedge against audits settlements and to do the initial true-up when each new MSL item is added – we have found that by far the most enthusiastic and supportive organization for this point is finance, consequently we recommend that they are included in this discussion as early as possible in the project.

The user doesn’t care – as far as they know they’re covered. They purchased an authorization and are basically indemnified by the ITAM function – so they’re fine.

If the internal market is done correctly, there is financial incentive to harvest unused licensing (a much better and more positive approach than monitoring for usage); a financial disincentive to acquire software through the back channel (discovered “rogue” installs are simply charged full license price); and a financial throttle on unused license demand (license requests are simply charged whether a license exists or not).

While it may sound complicated, it generally is not, and has been done for years in practice in several more advanced SAM organizations, and is typically embraced by IT finance.

About the Author

Brett Husselbaugh

Brett Husselbaugh is the President of ETelligent Solutions, Inc.