So that means that a access request to a application that a consumer wants is a service request?
This is very common and it does not take to much surfing to find examples of request catalogs filled with this kind of requests. How they are fulfilled is just a matter of automation and that is something i will leave for another topic. So the question here is if a request for application access is a service request? I think it is according to definition but i get sad if i think that is how far the evolution of request have taken us.
I am pursuing completely different content for a request catalog. when my consumer steps in to my service area aka request catalog i want to know the full picture. If she wants access to a specific application thats fine but i want to know WHY she needs it. You see, i know stuff about that application that she does not know and therefor i can deliver parts that will be completely transparent for her to fulfill her wishes in the best way possible without her knowing all the details.
Lets compare two scenarios and you pick the one you would like to interact with as a consumer. The first part is general and applies to both following scenarios.
General situation. For some reason you need access to a application that you do not already have access to. It might be due to that you will stand in for someone during a time period or that your work description has changed a bit. Either way you are in the works of requesting access to application A. Prior to this you received a quick "demo" of your new work assignment and instructions of how to do perform "order processing" but you still feel a bit unsure about it, but hey, who would not.
Scenario one. After a search in the request catalog for application A you have found a service request for access to application A. You request it according to instructions. After a while you get a notification saying that your request has been carried out and you received some credentials to access the application. When performing the "order processing" there is a verification step that actually requires access to a web portal (via url link) but when trying to access it you are denied. There is no obvious name of the portal and after a new quick search in the request catalog resulted in to many hits on the words "web" and "portal" and a additional search on application A only resulted in the request you earlier requested. so a call to the ServiceDesk solves the situation and you can continue with your work after listening to an agent explaining that you need access to something you have never heard of.
Scenario two. After a search in the request catalog for application A you have found three service requests that contains application A. It is a "order processing", "complaints" and "packaging". You choose the "order processing" and request it according to instructions. After some while you get a notification saying that your request has been carried out and you have received some credentials to access the application. A this point the rest of the scenario is a user performing the work without any more disturbances.
Difference in scenarios. In scenario one the request is isolated and access to that specific application is carried out. The ServiceDesk does not know what the consumer needs the access for so we fulfill the application A access "by the book" according to access instructions. Case statistics are great and the number off processed requests are rocketing.
In scenario two we took some time when defining and creating the service request by identifying three possible situations where access to application A is relevant. The reason for this is that each situation needs additional fulfillment steps and access granted. This way the request can contain far more bits and bites which is irrelevant from a consumer perspective but crucial from a successful fulfillment perspective.