As a consultant with Cireson, I am often engaged with customers regarding SCSM Service Requests. The first things we discuss during these engagements are the most important factors to be successful. In this article we will talk in depth about the following factors:
- Not knowing where to start
- Trying to do too much
- Service Catalog navigation
Not Knowing Where to Start
Where do we start when it comes to SCSM Service Requests? Try starting out with a general request that can be used as a “catch all,” and then branch out. When using a general request, you need to establish a procedure to handle these process-less requests. This is often overlooked because the end goal is to surround each service request with process unique to that request type. Being more realistic, there will always be requests that don’t yet have this process established, and we don’t want them to fail because of a lack of procedure.
For example, if a request comes in for something less-than-common, does the Service Desk know how to classify, prioritize, and assign the request? Perhaps you can establish a process based on the category/area of the request, or a related configuration item. Lacking process here can lead to Analysts delaying the completion and/or a failed Service Request.
Another great place to start is Incident/Ticket Reporting to identify common End User Requests. These requests tend to be “I need something” such as an application installed, a second monitor, access to a network share, whatever…
Once you identify the most common requests, consider each one and determine if there’s value in adding this to your service catalog. When determining value analyze from both an End User and IT perspective. By now you should have a list of request offerings to build, great, now prioritize which ones to build now and which ones to build down the road. I say some now and some later because you need to document the current process for each, improve existing process or for some develop the process.
Trying to Do Too Much
When dealing with a first time Service Catalog, it is extremely important to keep it simple. Keep everything as a manual process and continue to fine tune until you have proven success. Once you are happy with the manual process, you can then start to introduce some automation. There is nothing worse than spending weeks automating a process, just to figure out that everyone doesn’t agree on that process.
After you have a process solidified, think about your ROI when determining if automation is worthwhile. For example, if you only spend 5 minutes on a task each month, it’s probably not worth spending 2 weeks to automate. If you spend 5 minutes a day on something, you will recoup your automation cost much more quickly. For example, let’s say you have a few Service Requests that require the Affected User’s manager to approve before they can proceed. Your current manual process is for the Service Desk to look up this manager in Active Directory and add that individual as an approver.
The entirety of this task could be automated via an Orchestrator runbook or Cireson PowerShell activity with relative ease. With analysts likely doing this look-up routinely, it wouldn’t take long to make this worthwhile. While its great to have everything automated, it’s always a measurement of cost versus value.
Service Catalog Navigation
Once again, the theme of today is to keep it simple! When determining the layout of your Service Catalog, you need to keep the end user experience in mind. If the end user can’t find it, then they definitely will not use it.
Try to keep navigation simple, and drill-down to requests with simplified categories. For example, don’t have 20+ choices to make right off the bat, and don’t have several choices that are similar, like “Desktop Request” and “Equipment Request.” Remember that Cireson Advanced Request Offerings offer conditional questions based on answers to previous questions. This means that you can cover several similar request types in a single form, such as “Laptop requests” and “Mobile Device requests.”
There are also scenarios where a general end user will not need access to a certain request offering. Fortunately, SCSM Service Requests can be scoped by Active Directory group using “Catalog Item Groups,” so you can hide offerings from some groups if not relevant. This is another method you can use to keep the choices relevant and focused.
Service Requests Summary
In order to be successful with SCSM Service Requests, try to keep the above in mind. Use analytics and reporting to prioritize the Service Requests to build. Do not overlook generic Service Requests and branch out from there. For each request you design, once you have proven success with the manual approach, you can then start to introduce some automation. Don’t try to automate broken processes! As you build out different service requests types, don’t forget to take a step back and look at the overall design of the Service Catalog. Keep it simple and remember to think about it from the end user’s perspective.
Have a thought to share? Please give us your feedback on the Cireson Community.
