Self-Service Software Portals – what features are important?

08 August 2013
7 minute read
Best practice

Self-Service Software Portals – what features are important?

08 August 2013
7 minute read
Brett Husselbaugh

Brett Husselbaugh

The following comment piece is contributed by Brett Husselbaugh, CEO and founder of eTelligent Solutions, an IT Asset Management company.

Many organizations are evaluating or are in the process of creating a self-service software portal.

The driver is typically user demand and/or the desire to reduce ticket volume and the associated resources required to address that volume.
The requirements of the Software Asset Management (SAM) program are often not considered for this self-service portal.

There is 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.

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 was 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.

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.

Summary

A self-service software request portal is an essential element of the Software Asset Management solution to make sure software that is requested and deployed is captured and allows the associated purchase of licenses to be accurately recorded as well.

The four design criteria outlined are the most important considerations for the software request portal, along with creating the right financial behavior drivers.

This article was contributed by Brett Husselbaugh, CEO and founder of eTelligent Solutions, an IT Asset Management company.

 

Can’t find what you’re looking for?