Streamlining the software request process

An ITAM Review reader writes:

Reader:

In my organization, I face a problem that may take sometime to solve, but something that you may have come across earlier. We have users who speak in ambiguous language yet the service desk forces us to understand requirements and provide something. It is my firm belief that the user should know exactly what he wants.

Another problem I have is with the users requesting software versions that they don’t require. E.g. Acrobat standard may suit their requirement, but since their colleagues use professional they too want the same.

How do tackle this?

ITAM Review:

Thanks for the email, a great question.

May I ask – if I am a user in your organization, how do I request a new piece of software? What is the typical process?

Reader:

If you are a user, for any software, there is a excel template which a user has to fill in. This then goes to his manager, who has to approve it after which it is sent to service desk for installation. I’m trying to work on a drop down list from which users can request for the software they want, but it may take sometime.

The problem with the excel file for the time being is that it’s a free text and users can type anything what they want. In my previous organization we faced this problem; we solved it by having a drop down list specific to the users account. For software that is not present in the list we had users putting a ticket to SAM or sent us an email.

Basically I’m trying to create a SAM process here and fix the gaps.

ITAM Review:

Restaurants are often used to explain Service Request scenarios and I think it works well for your situation.

In restaurant terms, by having a free text field you are effectively offering your users a chef who will cook anything they desire on demand. The drop down list is a great first step but I would take this a step further and offer your users a menu.

Your menu should include:

• These are the software applications we offer
• These are their typical uses

If possible you should also include:

• Price – to reinforce that this is costing the business money (even if they are not paying for it directly)
• Filter – some form of filters e.g. Software and service options customized for the end user – the receptionist should not have to wade through 17 different variants of a high end engineering application in order to choose the software required to open a PDF. See also: “Why You Should Consider a Software Web shop” from 2010.
• Versions that the company has standardised on

With regards to your second point when users want a Pro version because their friend has Pro – I would emphasize the price differential throughout the request and approval process and then back it up with a policy which states you reserve the right to swap version at a later date based on usage. I know this is easier said than done and will depend on your country and company culture, it is a particularly easy conversation in the UK at the moment when most companies are trying to save money on software and avoid new costs.

You want to be customer friendly and service centric – so I would also offer users bespoke choices outside the menu subject to business approval. You ought to be explicit in stating that software that is not on the menu can be researched and delivered to the user but with a longer SLA and only if approved by management.

E.g. Software on the menu with manager approval – 5 days, Software not on the list SLA – 14/21 days or whatever suits your company.

i.e. Chef can cook you something that isn’t on the menu but a) it will take a bit of time to prepare and b) you’ll have to pay for it.

Future steps to consider

All of this does not have to involve deployment of technology – it could simply be a brochure / webpage on your intranet. Applying triage and focussing requests makes management of software a lot easier down the line. Many service desk technologies offer service request portals, but not many also include software licensing approval and licensing savvy (e.g. This software request has management approval and we have spare licenses >=1 therefore I’ll route the ticket directly to the deployment team).

Depending on your company culture another consideration is to organize a software user group made up of the end users of software, which help you decide what is on the menu. This is a great way to listen and align closely to user requirements whilst also communicating your SAM messages.

Ultimately you can reach a level of standardization that says – for users who need PDF editing software:

• We have chosen this brand of PDF editing software, which is supported by the users
• We have standardised on this version, when we upgrade everyone will upgrade
• We know how to license it correctly in our environment
• We will review this situation at X point in the future

This level of standardisation also works well for Service Delivery and Security – they only have one version to support and secure.

I appreciate this is not something you can implement overnight but will take away some of the heavy lifting from day to day management.

Just my two pennies – I would be interested to hear what others have to say.

Photo Credit