Imagine calling the service desk to order that new software you urgently need. You describe what you want, are asked about where in the organization you are and a lot more details. You feel like you should just hang up and simply go buy it yourself and then treat the bureaucracy afterwards, because right now you know for certain this will take some time. On the other side, the service desk agent feels the panic arriving, because there is nothing that supports the work effort included in this. The service desk agent just knows that this will take some time.
Informal fulfillment of order-to-fulfilled (OTF) of IS/IT services, such as standard software, is a source of heated argumentation, myriads of e-mails, frustration and bad blood between the business and IT.
This is why it is a really good idea to make an effort, structure your fulfillment of IS/IT services, especially those who requires external fulfillment, such as standard software. You will gain a lot of goodwill, both outside and inside the IT service provider, save a lot of time and actually money. It will also enable you to get better control of licenses, suppliers and other important factors to stay on top of things that really matters to your success. In short, creating a set of request models to support your OTF is a no-brainer.
I now assume that you already have a service desk, or something similar, a function that manages the main user interactions, such as support and orders for your services. This should also include that you have some form of ticketing tool to manage the individual calls/contacts, what we in ITSM call Incidents. You probably have another ticket type, requests, to manage user orders for services. However, since you are still reading I am guessing that you do not have any real back office support for managing requests.
Request models are the specific routines for manage a certain type of request, from order to fulfillment, including activities, tasks and other information relevant to perform fulfillment of this specific request.
Ideally, these request models are also connected to your service catalogue, but that is another topic.
Now, establishing request models works like a catalyst, you will have to set up the different mechanisms that are needed to execute this model, such as the administration, the approval flow and the actual fulfillment, especially important when doing external procurement/purchasing. Basically, the request model is the backbone of your OTF. Just consider for a moment how much you will gain by “industrializing” all this instead of destroying the day for at least two people, the user and the service desk agent.
Here are the really good news. Establishing request models is extremely easy. In addition, the gain is great. In other words, a quick win that is easy to achieve.
You simply do this particular request once, make sure to document what is done and keep in mind that you are creating the routine, thus thinking about “the next time” when doing things. Afterwards you create the model. Now, this might involve setting up an approval flow, if such no exists (it really should) or other “related” tasks that are not really part of the request model. But normally not, in my experience the first few request models you create will be just a bit more complicated but the all the coming ones will benefit from these. In addition, suddenly there is request fulfillment automation on the horizon, now this is feasible, but let us walk before running.
Ok, let us do the same example again.
Imagine calling the service desk to order that new software you urgently need. You tell the service desk agent, which is the service you want, your organizational ID and get a request ID back together with the estimated delivery time. Your expectations are in line with what the IS/IT provider knows this will take to fulfill. The service desk agent follows the procedure; the approval is made with the manager responsible for your team following an established approval flow. The software is installed on your computer within defined timeframe and you do not even know about the administration, including license management, that has happened within the IS/IT supplier organization.
See, no stress, no arguments, everyone knows what will happen, how much time is needed, everything is suddenly predictable, no surprises, just routine.
You think this is simple, baby stuff, but I promise, set a few KPIs, then establish request models for your top 10 services (preferably externally procured) and see the results. In addition, do a client satisfaction survey before and after. This is one of the easiest ways to quickly improve the relationship between the IS/IT service provider and the business, but keep the casual Friday and the after works anyway.