This month we’re into the software request process!
The software request process is the public face of software asset management. It’s the process your end users and business teams use on a regular basis, and if it goes wrong it can be a right pain the proverbial. Here are 6 things to think about when improving this process.
1. You don’t own the Software Request Process:
Like many of the processes that sit in or about the IT estate, service management have raided the process cookie-jar and claimed this one for themselves. This process sits within the request fulfilment arena of service management. The good thing about this? There’s a fair chance you work with the stakeholders who oversee this important first step in “The Bermuda Triangle of SAM.” The bad thing about this? They might well believe what they have in place is already perfect (“Are you calling my baby ugly?!”) A degree of persuasion will be required to make changes that will serve SAM goals.
2. Your Software Request Process should guide behaviours:
The better Software Request processes will start with a software picking-list, aka a supported software catalogue, which steers end users towards picking accepted/ approved software titles the business is already happy with. Equally, the process shouldn’t prevent users from requesting a title of their choice not on the list, so model your workflow to accommodate such exceptions.
3. Project Integration:
Merely because projects are not considered business as usual, does not mean we shouldn’t hold them to the same high standards as end users. Design a workflow that works for these special little children too – if you get it right, it will give you a great head start when onboarding the new vendor or software that the project has introduced into the organisation.
4. Line Management Approval:
Think hard about when you really need this. Pre-approve as much software as possible and make sure your end users know which software they don’t need to jump through hoops to get. Line management approval is like grit in a gear… it adds friction, slows everything down, and generally makes everyone unhappy. Minimising the need for this step is key to automating this process through self-service portals and automated deployments.
5. Views:
Categorisation of user types can also help funnel the types of software being presented at the request portal. Do you really want typical end users requesting Oracle Databases? A simply-added value in our supported software catalogue can determine which titles are presented to which members of staff in your request portal. Expand this even further, and you can automate software delivery with role-based software profiles which reduce the number of requests to an absolute minimum because people have the tools they need without even asking for them!
6. Licence Pool Check:
The points above could be considered “nice to have” – but if you are going toe-to-toe with your service management colleagues, and only one change is going to be made this time round, then it is this one: DO NOT have your request process workflow make a software purchase without checking if you have a spare license. Having said that, don’t implement by assigning tickets to the SAM team… make the license pool information public to the service desk so they can check on the spot when they are processes the request. Even better, automate the workflow so that if a license is available the workflow goes straight to the Deployment process, but if no license is available, it is directed to the Software Purchasing process.
And finally… a word too, about automation: think hard about optimising the workflow between tools because poor integrations can kill your chance of implementing a smoothly flowing process. Have a documented process that works smoothly, and which works for all stakeholders, and then apply the tech. Your tools don’t have a cultural API, so you and the ITSM peeps need to make sure everyone is on board with any changes to ensure your improved process is a success.
