Professional Documents
Culture Documents
SR To Resolution
SR To Resolution
Anselmo, Justine
Bautista, Jonathan
Macaraeg, Justin
TI001
HP - Hewlett-Packard
Page 1 of 29
On October 6, 2014, Hewlett-Packard announced plans to split the PC and printers business
from its enterprise products and services business. The split closed on November 1, 2015, and
resulted in two publicly traded companies: HP Inc. and Hewlett Packard Enterprise.
Page 2 of 29
Version: v1.0
Flow of events:
Precondition/s:
1. The User or Requester should be logged in already to the HP Service Manager
Main Success Scenario:
1.
2.
3.
4.
5.
Summary: This use case describes the steps associated with validating the service request
filled/ submitted by the user or requester.
Actors:
1. Service Request Coordinator analyze the service request submitted/filled by the User
or Requester
Creation Date: June 16, 2016
Version: v1.0
Flow of events:
Precondition/s:
1. The Service Request Coordinator is identified by the System and is authorized to
perform the Service Request validation.
2. The user has already submitted service request.
Main Success Scenario:
1.
2.
3.
4.
5.
Alternative Sequences:
A4. Service request is invalid
1. Service Request Coordinator will email the user or requester about the invalidation of the
service request and request the user or requester to update the submitted service
request using the Service Request ID emailed by the Service Request Coordinator.
2. User or Requester receives the Service Request Invalidation email.
3. User or Requester click Service Request ID link.
4. User or Requester updated the submitted service request.
5. User or Requester click Save button to update the SR details.
6. Resumes the use case at Step 4 of the Main Success Scenario.
Post condition/s:
1. Service Request Coordinator already analyze and the service request is valid.
Page 5 of 29
Version: v1.0
Flow of events:
Precondition/s:
1. The Service Request is already validated by the Service Request Coordinator
Main Success Scenario:
1. Service Request Coordinator group service request by service request category/subcategory based on the type of request being fulfilled.
2. Service Request Coordinator records all relevant information of the request so that a full
historical record is maintained.
Page 6 of 29
3. Service Request Coordinator identify prioritization code/level by both the urgency of the
request (how quickly the business needs to have it fulfilled) and the level of impact it is
causing.
4. Service Request Coordinator assigns the recorded service request to the proper
team/group/person that will fulfill the service request.
5. Service Request Coordinator click Save button to keep the service request to catalog.
6. System will save the submitted SR to catalog.
Post condition/s:
1. Service Request Coordinator already recorded the service request and assigned to the
proper team.
Page 7 of 29
Version: v1.0
Flow of events:
Precondition/s:
1. The Service Request Approver is identified by the System and is authorized to perform
the Service Request authorization.
2. The Service Request recorded by the RS Coordinator
3. The Service Request assigned to the proper team by the RS Coordinator
Main Success Scenario:
1. System will display Service Request catalog of newly recorded requests.
2. Service Request Approver will click Service Request ID of newly recorded service
request on catalog.
3. System will display detailed information of service request selected.
4. Service Request Approver identify if the Service Request needs a more rigorous
authorization.
5. Service Request Approver reviews/authorize Service Request details.
6. Service Request Approver click Forward Service Request button to send the service
request to the assigned team/person for the execution.
7. System display a successful message of forwarding the service request.
Alternative Sequences:
A1. Service Request Approver identified that service request is a simple request
1. Resumes the use case at Step 6 of the Main Success Scenario.
Post condition/s:
1. Service Request Approver authorized the request
2. Service Request Approver passed request to the assigned team/person for the
execution.
Page 8 of 29
Version: v1.0
Flow of events:
Precondition/s:
Page 9 of 29
1. The Service Request Analyst is identified by the System and is authorized to perform the
Service Request fulfillment.
2. The Service Request has already authorized by the Service Request Approver
Main Success Scenario:
1. System will display list of authorized service request.
2. Service Request Analyst click the Service Request ID to see the detailed information of
service request.
3. System display a detailed information of authorized service request.
4. Service Request Analyst executed the request tasks defined in the request model.
5. Service Request Analyst Click Submit Fulfillment Result/Resolution button to send
Fulfillment Result/Resolution to the Service Request Coordinator.
6. System display a successful message of sending the Fulfillment Result and Resolution.
7. Service Request Coordinator click the Service Request ID to see the detailed
information of Fulfillment Result/Resolution.
8. Service Request Coordinator identified that request is fulfilled.
9. Service Request Coordinator submits the resolution to the Service Request Manager for
the request review.
10. System display a successful submission message.
Alternative Sequences:
A4. Service Request Analyst need additional information for request execution
1. Service Request Analyst email the user or requester for the additional information
needed in request execution
2. User or requester receive an email about request for Additional Information Needed.
3. User or requester replies to the email the additional information for request execution.
4. Resumes the use case at Step 4 of the Main Success Scenario.
A8. Service Request Coordinator identified that request is unfulfilled.
1. Resumes the use case at Step 4 of the Main Success Scenario.
Post condition/s:
1. Service Request Analyst fulfilled the request.
2. Service Request Coordinator submitted the request for review.
Page 10 of 29
Version: v1.0
Flow of events:
Precondition/s:
1. The Service Request has already identified finished by the Service Request Coordinator
Main Success Scenario:
1. Display submitted SR fulfillment result and resolution
2. Service Request Manager reviews the request fulfillment result, including the costs for
the fulfillment activities, whether Service Level Target has been achieved, and so on.
3. Service Request Manager decides fulfillment result is satisfying and click Reviewed
button
4. System displays successful message.
Alternative Sequences:
A6. Service Request Manager decides fulfillment result is not satisfying.
1. Service Request Manager submit the request go back to the Service Request Analyst to
re-fulfill the request.
Page 11 of 29
Post condition/s:
1. Service Request Manager reviewed and decided that the fulfillment result is satisfying.
Version: v1.0
Flow of events:
Precondition/s:
1. The Service Request has already reviewed by the Service Request Manager.
Main Success Scenario:
1. System display service resolution form.
Page 12 of 29
2. Service Request Coordinator update the request fulfillment result form, including the
costs for the fulfillment activities.
3. Service Request Coordinator Click Save button to update the request form.
4. System Displays Successful Message
5. Service Request Coordinator email the user or requester for the confirmation of the
request fulfillment result.
6. User or Requester receives an email of confirmation of request fulfillment result.
Post condition/s:
1. Service Request Coordinator delivered the fulfillment result and emailed the user or
requester the confirmation of fulfillment result.
Service Request Coordinator will close the user or requester completed service
request.
2. User or Requester confirms if the result fulfillment is satisfying or not and give a
feedback on the service request process.
Creation Date: June 16, 2016
Version: v1.0
Flow of events:
Precondition/s:
1. The User or Requester has already received confirmation email of SR fulfillment result.
Page 13 of 29
Page 14 of 29
Page 15 of 29
Date of Update:
Version: v1.0
Person in Charge:
Flow of events:
1. The user file his service contact.
2. The CSR receives the users service contact.
Post-condition: A help request with a unique number provided to the user that records basic
information about the request.
Page 16 of 29
Date of Update:
Person in Charge:
Flow of events:
1. The CSR validates the customer information.
2. Update the customers information on the system.
3. Display the users information.
Post-condition: The customers information is validated by the system.
Page 17 of 29
Date of Update:
Person in Charge:
Flow of events:
1. The CSR determines if the service request is being supported.
2. The CSR enters the service request.
3. Inform customer.
Page 18 of 29
Date of Update:
Person in Charge:
Flow of events:
1. The CSR search a knowledge base to resolve and expedite the service request.
2. The CSR determines the time frame for the solution.
Page 19 of 29
Date of Update:
Person in Charge:
Page 20 of 29
1.
2.
3.
4.
5.
Post- condition: The users service request is successfully resolved and fulfilled.
Date of Update:
Person in Charge:
Page 21 of 29
1.
2.
3.
4.
5.
Page 22 of 29
Page 23 of 29
Post-condition: A specific code is assigned per user that will record information about the user
Page 24 of 29
Page 25 of 29
Page 26 of 29
Page 28 of 29
Page 29 of 29