Service Management Help
| Scroll ignore | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||
The Service Request Management module enables the End Users to create Service Requests (SRs) related to their requirements. It also helps the Workgroups to handle the SRs in a more efficient way.
A Service Request (SR) is a formal request, submitted by the User or an Analyst on behalf of the User for any type of service, information, hardware, or software requirement.
Figure: Service Request Management Overview
The following diagram explains the Service Request Management Life cycle:
Figure: Service Request Management Life cycle
This section explains the various phases of the Service Request Management Life Cycle:
Creation
A Service Request (SR) can be created by an End User, or an Analyst on behalf of the User. While creating the SR, the End User or the Analyst should select a Service Catalog relevant to the requirement. The status of the SR at this phase is New.
Approval
After the SR is created, the SR needs to be approved by the User who is configured as an Approver for the selected Service Catalog. The Approver is selected while configuring the Workflow for Service catalog. The SR may require multiple approvals based on the configuration. After the SR is approved, the status of the SR changes to Assigned.
Request Fulfillment
| Excerpt |
|---|
The Approved SR is assigned to the appropriate Workgroup based on the selected Tenant and Service Catalog. The Workgroup Owner then assigns the SR to the Analyst. Once the SR is assigned to the Analyst, the status of the SR changes to In Progress. The Analyst fulfills the User requirement and resolves the SR within the Service window, selected by the Workgroup Owner for the Service Request. The Analyst can also create work orders and assign it to different department if part of the User request requires assistance from the other department. If the Analyst is not able to continue working on the SR due to pending User information, or dependency on any other activity, the Analyst can change the status to Pending. Once the Pending Reason is met and the Analyst can resume his work on the SR, the status of the SR changes back to In Progress. When the SR is in Pending state, the SLA clock pauses and hence, the time is not considered to be within the SLA Service Window. For Example: A User created an SR for the installation of ABC software on 3rd April 2017, the SLA Service Window for the SR is four days. So, the SR should be resolved by 6th April 2017. But the SR was in pending state for one day, because the License for the tool was not available. Since the SLA clock is paused during the pending state, the new due date for the SR resolution will move to 7th April 2017. After resolving the SR, the status of the SR changes to Resolved. |
Closure
After the Service Request is resolved, the End User or the Analyst can close the SR. The SR may also be closed automatically, if auto closure is configured. The End User can reopen the SR if the resolution is not satisfactory.
The End User can provide feedback for the Resolved/Closed SR from the application or from the Feedback notification mail.
| Scroll ignore | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||
|