Application Service Request Process
OSF Service Support
Application Service
Request Process
[Version 1.2]
ApplicationServiceRequestProcess.docPage 1 of 17
Application Service Request Process
Table of Contents
About this document......
Who should use this document?......
Summary of changes......
Chapter 1. Application Service Request Process......
1.1 Objectives......
1.2 Definitions......
1.3 Application Service Request Scope......
1.4 Inputs and Outputs......
1.5 Metrics......
Chapter 2. Roles and Responsibilities......
2.1 OSF ISD Service Desk......
2.2 OSF ISD CORE Functional Manager......
2.3 Functional Delivery Team......
2.4 Application Development Team......
2.5 Advisory Board......
Chapter 3. RACI Chart......
Chapter 4. Process Flow......
Chapter 5. Work List......
5.1 Content......
5.2 Updating......
5.3 Stage Codes......
Chapter 6 Reports and Meetings......
6.1 Reports & Notices......
6.2 Meetings......
Chapter 7. Application Service Request Policy......
About this document
This document describes theApplicationService Request(SR) Process. The Process provides a consistent method for everyone to follow whenAgencies submit requests forstandard support services from the Office of State Finance Information Services Division (OSF ISD).
This process should be used for requests for support of services that are considered to be a part of standard OSF services or are a service covered by an existing Service Agreement for no additional cost.
Who should use this document?
This document should be used by:
OSF ISD personnel responsible for the fulfillment of standard services
OSF ISD personnel involved in the operation and management of Application Service Request Process
Summary of changes
This section records the history of significant changes to this document. Only the most significant changes are described here.
Version / Date / Author / Description of change1.0 / Initial version
1.1 / 12-9-2010 / OW Thomasson / Revised to correspond to changes in CRM and to be in sync with other process documentation.
1.2 / 4-11-2011 / OW Thomasson / Clarification of terms
1.3 / 9-30-2011 / OW Thomasson / Clarification of terms – use of term Request for Change to correspond with CRM
Where significant changes are made to this document, the version number will be incremented by 1.0.
Where changes are made for clarity and reading ease only and no change is made to the meaning or intention of this document, the version number will be increased by 0.1.
Chapter 1. Application Service RequestProcess
The Application Service RequestProcessmanages submission and processingof the following types of requests generally referred to as requests for service:
- Standard services provided by OSF ISD to itscustomer base.
- Application Development Services under the $15K project threshold.
- Services provided by OSF ISD functional staff, ex., CORE.
1.1 Objectives
Provide a consistent process for Agencies to submit requests for services that ensures:
- Servicerequests are properly logged
- Service requests are properly routed
- Service request status is accurately reported
- Service requests are accurately sized with regard to effort and cost
- Queue of unfulfilled requests is visible and reported
- Service requests are properly prioritized
- Solution provided meets the requirements specified by the customer
- Effort is not wasted on unapproved requests
1.2 Definitions
A complete set of definitions may be found in the document Service Request Process Overview. The definitions listed here are specific to this process.
1.2.1 Service Request
A request initiated by a customer for OSF ISD services. It is often referred to as an SR. The request is for a specific service considered to be part of OSF’s customer support for the larger services provided, ex., email, network, or PC support.
To be considered a service request and not a Request for Change (see below), the request should be for routine ongoing support to customer to keep production operating efficiently and effectively. For a request to be considered routine, it must have the following characteristics:
- The same request is performed over and over with only minor differences based upon who the customer is.
- Known requirements
- Known solution
- Known cost (approximate)
- Known risk
- No impact to the Customer’s SLA
- Preapproved by Service Provider Group Manager
- Predefined Service Level Target
1.2.2 Request for Change
The Request for Change (also known as an Enhancement Service Request) is a request for a modification or enhancement of specific service considered to be part of OSF’s customer support for the larger services provided, ex., email, network, or PC support. A Request for Change is often referred to as an RFC.
Requests for Change go beyond the service request by requesting a modification of existing services in some method. The modification may be by configuration, change to software or hardware. Requests for Change have the following characteristics:
- Analysis of request is required to determine appropriateness
- The request may be similar to others but is not routinely performed.
- Not preapproved by Service Provider Manager
- No predefined Service Level Target.
1.2.3 Work List
Excel spreadsheet used to log Request for Change and their status.
1.3 Application Service RequestScope
The Application Service Request process applies to all specific requests in support of larger services already provided by OSF.
1.3.1 Exclusions
Service Catalog Requests, i.e., services advertised on our Service Catalog, not currently utilized by this customer, are not handled by this process.
Incidents (break/fix) are not handled by this process. By definition incidents are a break in normal service and therefore receive high priority to restore service to the customer within the timeframes designated in the Service Level Targets.
System modifications resulting from the Problem Management process are not handled by this process. Problem Management also deals with break/fix. Problem Management searches for a permanent, not temporary, fix for the customer. A Problem Management case in CRM might trigger a DR to be developed, but no SR case would be recorded in CRM for the resolution of a problem.
Non Application related Service Requests. Those will be handled under other processes.
1.4 Inputs and Outputs
Input / FromApplication Service Request (verbal or written) / Customer
Specifications / Customer / Business Analyst / SME
Work List / Application Development Lead / Business Analyst / SME
Output / To
Standard notification to the customer when Application Service Request is scheduled to be worked. / Customer.
Solution meeting requirements of customer / Customer
SR/DR List Spreadsheet / Advisory Board / CORE Web page
1.5 Metrics
Metric / PurposeProcess tracking metrics
# of requests by type (Assistance vs. Enhancement), status, and agency / To determine if requests are being processed in reasonable time frame, frequency of specific types of requests, and determine where bottlenecks exist.
A method to combine information from the worklist and CRM cases will need to be developed to perform comprehensive reporting.
Chapter 2. Roles and Responsibilities
Roles and Responsibilities listed here are specific to this process. A complete list of Roles and Responsibilities that are common to all Service Requests, including those addressed here, can be found in the document Service Request Process Overview.
Responsibilities may be delegated, but delegation does not remove responsibility from the individual accountable for a specific action.
2.1 OSF ISDService Desk
Ensure that allApplication Service Requests received by the Service Deskare recorded in CRM and routed to the appropriate group.
Identify whether the request is an Assistance Service Request or an Enhancement Change Request.
Prepare reports showing statistics of Application Service Requests fulfilled / unfulfilled.
2.2 OSF ISD CORE Functional Manager
Chair the Advisory Board Meeting and make certain minutes are taken and distributed
Present proposed 60 day schedules
Make final decision on priority of items in the request queue
Make certain the decisions made duringthe Advisory Board Meeting are reflected in new 60 day schedules
Determine final 60 day schedule with input from Advisory Board, Functional Team, and Application Development Team.
2.3 Functional Delivery Team
Composed of OSF ISD CORE Functional Manager and functional groups involved in supporting services
Develop solutions based on best practices and in conformancewith OSF ISD standards and policies
Create service design in alignment with existing architecture
Estimate one time and recurring functional costs for proposed service design
Prepare recommended selection of ECR’s/DR’s to work for Advisory Boards
Set final priority, order, and work schedule for ECR’s/DR’s to work
Assess proposed solution for any vulnerabilities or risks and recommend actions for mitigation
Perform work outlined in request once the request is properly prioritized and scheduled
Perform pre-implementation review to ensure all elements of proposal are met
Perform post-implementation review to ensure that all work services are functioning properly and all documentation is complete
2.4 Application Development Team
Composed of Application Development Manager, database, and application software development staff
Develop technical estimates for requests based on best practices and in conformance with OSF ISD standards and policies
Create service design in alignment with existing architecture
Estimate one time and recurring technical costs for proposed service design
Assess proposal for any technical vulnerabilities or risks and recommends actions for mitigation
Provide input to Functional Delivery Team and OSF ISD CORE Functional Manager regarding Application Service Request priorities
Perform work outlined in request once the request is properly prioritized and scheduled
Perform pre-implementation review to ensure all elements of proposal are met
Perform post-implementation review to ensure that all work services are functioning properly and all documentation is complete
2.5 Advisory Board
Membership includes:
Key representatives from multiple agencies including OSF
Function:
Review Requests for Change
Recommend priority of Requests for Change based on need and resources required
Offer insight regarding need and priority of request as well as alternative solutions
ApplicationServiceRequestProcess.docPage 1 of 17
Application Service Request Process
Chapter 3. RACI Chart
Obligation / Role DescriptionResponsible / Responsible to perform the assigned task
Accountable (only 1 person) / Accountable to make certain work is assigned and performed
Consulted / Consulted about how to perform the task appropriately
Informed / Informed about key events regarding the task
Activity / Functional Mgr(s) of Service / Functional SME's / Functional Team / App Dev Mgr / Lead / App Dev Team / Service Desk / OSF Service Desk Mgr / Advisory Board
Determine whether this request is routine high priority which does not require prior approval to proceed. / A/R / R / C / R
Develop high level +/- 50% estimate of functional work / A/R / R / C / I / I
Develop high level +/- 50% estimate of technical work / C / C / C / A/R / C
Add new SRs to work list / A/R / R
Prioritize ECR’s in the queue / A/R / C / I / C / I / I / I / C
Update 60 day Work Calendar / A/R / R / R
Select next SR to be worked / I / A/R / I
Draft DR / A/R / R / I / I
Develop technical specifications / I / C / C / A / R
Develop +/- 15% estimate of functional work / A/R / R
Develop +/- 15% estimate of technical work / C / C / A/R / R
Update work list with estimates & status / A/R / R / R / R / R
Perform functional tasks associated with request / A / R / R
Perform application development / C / C / C / A / R
Implement application development solution / A / R / R / R / R
ApplicationServiceRequestProcess.docPage 1 of 17
Service Request Governance Process
Chapter 4. Process Flow
ApplicationServiceRequestProcess.docPage 1 of 17
Application Service Request Process
Role / Step / DescriptionFunctional Delivery Team and/or Application Development Team / 1 / The Functional Delivery Team should perform the initial evaluation of Shared Services Application Service Requests. This may include additional conversations with the person making the request
Note: Occasionally the Functional Delivery Team will reroute these immediately to the Application Development Team if it is an Assistance Service Request that is technical in nature.
2 / Determine if this is a routine request for which there is already a solution available to the customer that does not require an application or configuration change.
3 / Perform assistance requested by customer.
4 / Notify customer that work is complete and ask them to verify solution meets their requirement.
5 / Update the CRM case with the proper case resolution.
6 / If solution does not already exist, perform “best guess” estimate of effort required to fulfill the request believed to be within +/- 50% of the actual effort required. As a rule, a room full of subject matter experts should spend less than 5 minutes creating this estimate. If there is considerable uncertainty about the accuracy of the estimate, increase the estimate sufficiently to meet the +/- 50% guideline. Estimates should include every aspect of the work including testing, implementation, discussions with the requestor, training, instructions on its use, documentation, etc.
Functional Delivery Team / 7 / Determine if Application Development hours will be required to properly fulfill the request.
8 / If Application Development hours are also needed, the Application Development group should also perform “best guess” estimate of effort required to fulfill the request believed to be within +/- 50% of the actual effort required. Same guidelines apply as in step 13.
Application Development Team / 9 / Update the work list with the estimates. Update the case, if necessary to show this is an Enhancement Change Request. Close the case using the standard solution for Requests for Change, “Case has been added to APPLICATION Work List as an Enhancement Change Request.” This will send a notice to the requestor that their Service Request is being considered and how to check the status.
Functional and Application Development Team / 10 / Is this a rush request? If so, expedite the request so that it is handled immediately but indicate in the work list it is being expedited.
Functional Delivery Team / 11 / If this is an expedited request, attempt to verify the need with the CORE Functional Manager. At a minimum, send email to CORE Functional Manager explaining reasons for expediting the request. The CORE Functional Manager has final authority over expediting a request.
12 / SR Review Meeting: Build proposed 60 day schedule. Utilize information gathered in meetings between the Core Functional and Application Development staff to discern need and best utilization of resources.
Functional and Application Development Team / 13 / Advisory Board Meeting: Review & Prioritize Requests in light of need and the current 60 day schedule for the Core Functional and Application Development staff. Identify the top 20-25 items in the request queue.
Advisory Board with Functional and Application Development Team / 14 / Update work schedules for the next 60 days. This effectively ends the process of handling the Service Request being prioritized and added to the work schedule. There is no guarantee that the Service Request will ever make it beyond being on the list.
15 / Update the case target dates for all Enhancement Change Requests added to the schedule and inform customer of target date.
Functional Delivery Team / 16 / This is the effective beginning of the Service Request fulfillment forRequests for Change. The functional area lead selects the next SR from schedule pertaining to their functional area and assigns it to be worked.
17 / Develop a detailed work plan with steps to address the functional requirements of the request. The work plan should include work schedules with milestones, issues & risks, test plans if appropriate, changes to processes & procedures, documentation, training materials, etc., and detailed estimates of the number of hours of effort required to accomplish the work.
18 / Determine if a DR is required. Even though DR requirements were not identified when first reviewed, it may be that some application development needs have been identified through the detailed analysis.
19 / If a DR is required, draft the DR from the functional specifications perspective. Provide as much detail as possible regarding tables and data items to be used, specific logic required, report or screen formats if applicable, and any other items that may assist the Application Development group to create an accurate estimate of the work.
20 / Perform review of draft DR to determine if everything sufficient information is present to create the technical specifications.
Application Development Team / 21 / Create the technical specifications and detailed estimate and obtain approval from functional group.
22 / Update the APPLICATION SR/DR spreadsheet with estimates, projected work schedule, and status.
Functional and Application Development Team / 23 / Compare the total estimate for the work (both functional and technical) to 150% of the original total estimate (the original worst case =/-50% estimate). If the new estimate is greater, the Service Request must be reprioritized.
Functional Delivery Team / 24 / Was there a DR involved in this estimate? If not proceed to functional tasks for testing solution.
25 / Perform application development as defined in the DR.
Application Development Team / 26 / Create testing and implementation plans to be utilized when application development is complete.
Functional Delivery Team / 27 / Test new development and make corrections as necessary.
Functional and Application Development Team / 28 / Implement new software and any configuration, procedural, or documentation changes that are related.
29 / Update work list to show that work is complete.
30 / Notify customer of work completion.
Chapter 5. Work List
5.1 Content
The Work List is an Excel spreadsheet that lists all (scheduled and non-scheduled) Enhancement Change Requests for both Functional and Application Development Service Requests.
The columns are:
Column / DescriptionAdvisory Board / The Advisory Boards responsible for the particular area of CORE Services impacted by the service request will be indicated.
Business Service / The Shared Service will be listed, i.e., Payroll, Billing, etc.
Status / Current status indicating whether it has been scheduled, and if so, what stage of fulfilment it is in. A complete list of status codes is shown below.
60 Day Target Date / The target date for the completion of work will be updated once the service request has been scheduled.
Complete Date / The date the work was actually completed.
Priority / The priority of the request listed as Low, Medium, High
Rank / Priority as compared to all other requests, and the sequence in which the request will be fulfilled.
Request Title & Summary / General title and description of the request for reference in discussion.
Requestor / The name of the person initiating the request.
Project / Lists whether this is actually part of a project, the correction of a problem, or a new request from the customer.
Stage / Indicates the stage of fulfilment. The possible stages are listed below.
App / The general Service Category for which the request applies, ex., Financial, HCM.
5.2 Updating
AppDev Admin (additions, updates & deletions )