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
- To manage the request of software as quickly and efficiently as possible; whilst respecting the companies license position.
- No automated system is in place to manage the handling of software requests
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.
Other Process of the Month Articles:
- Software Re-harvesting Process
- Software Change Mangement Process
- Corporate Governance Process
- Maintain a Supported Software Catalogue
- Software Rationalisation Process
- Joiners, Movers and Leavers Process
- Scope Verification Process
- Named User Verification Process
- Platform Identity Process
Upcoming Process of the Month Articles:
- Software Removal Process
- Process Review Process
The process kit by Rory Canavan is available from SAMcharter.com
About Rory Canavan
With a technical background in business and systems analysis, Rory has a wide range of first-hand experience advising numerous companies and organisations on the best practices and principles pertaining to software asset management.
This experience has been gained in both military and civil organisations, including the Royal Navy, Compaq, HP, the Federation Against Software Theft (FAST) and several software vendors