Process of the Month – Software Request Process

Best practice

Process of the Month – Software Request Process

01 September 2014

4 minute read

Try not to map the moon!

I suspect the reason many folks get in such a bind with designing a process to handle software requests is that they try and bundle no end of steps into the overall process, including procurement, testing, deployment etc. The trick with process engineering (like programming) is to focus on one element, get it working (and get it working well) and then consider pulling in other elements at a later stage – try not to map the moon!

You may have noticed that all of the steps modelled so far have been with rounded corners (i.e. manual steps) increasingly the SAM marketplace is looking to automate the request process with products such as Shopping by 1E or App Portal by Flexera. The advantage to this is that the rules and constraints around requesting software are quite binary in nature, and so from a programming perspective should not be that difficult to implement. Such decision-based software removes considerable load on the helpdesk, not least if the deployment can be automated also.

Software Request Process

Primary Objective

To manage the request of software as quickly and efficiently as possible; whilst respecting the companies license position.

Secondary Objective

Assumption

No automated system is in place to manage the handling of software requests

: Screenshot A

: Screenshot B

Function Step Overview

1.10	This process is initiated by one of three ways; either a request is raised by an end user in a standard fashion, or in performing due-diligence in checking for Named User Licenses the SAM Manager needs to go through the approval process to buy extra Named User Licenses, or finally because a Change Management Request has been made for which there are no licenses left.
1.20	At 1.20, the Line Manager to the Requestee is tasked with either approving or rejecting the request.
1.30	If the request is rejected, then the requestee is informed with the reason why. At this point, function step 1.30 could also be called into action as a result of a change management request being rejected over any number of issues other than whether a license is in place.
1.40	Subject to approval by Line Management, The Help Desk then validates that the software requested is on the Supported Software Catalogue (SSC); if the title is not on the SSC (it could be a new title that is being requested) then the request is routed to the Testing Process; if it is an Amber or Red title then the request can be rejected via 1.30. Finally, if the title is Green, then the request can proceed to the final step (1.50)
1.50	A licence validation check is performed here, to ensure that adequate license coverage is in place – if a license is in place, then the request can proceed to the Software Change Management Process; if no license exists, then the request is handed off to the Software Procurement Process.

Clearly this is a template, and is potentially one of the most contentious processes around. It might well be that you require extra steps for further validation, or equally, you could have a system in place that removes a lot of the pain in handling software requests. Either way, providing a license check takes place at some stage along the cycle is the most important point of this process.