Service Level Definitions.docx

Exhibit 3.2 (Service Level Definitions) Solicitation No. 5400028075

Managed Cloud Services

Exhibit 3.2 Service Level Definitions

Solicitation No. 5400028075

Table of Contents

Offeror GuidelinesThis Exhibit 3.2 (Service Level Definitions) contains specific functional requirements that the Offeror must meet in order to successfully perform the requested Services. The response must address all requirements contained in this Exhibit according to the instructions below and be in the prescribed format.

Offeror Instructions1. The Offeror’s response to the RFP shall reflect and comply with the information contained in this Exhibit 3.2 (Service Level Definitions).

2. If the Offeror wishes to suggest changes to the content or requirements contained in this Exhibit 3.2 (Service Level Definitions), these suggestions shall be summarized and submitted separately as detailed in RFP Exhibit J.2.1 (Exceptions). Any notation of objections or issues associated with this Exhibit 3.2 (Service Level Definitions) content does not eliminate or modify the requirements herein or of this RFP, and the Offeror’s Proposal must not assume any incorporation of the Offeror’s suggested changes.

3. The Offeror should not view the possibility of requesting changes as an opportunity to rewrite the entire RFP. The State expects the Offeror to comply with the requirements as written, and changes should only be made for minor clarifications or if an Offeror will not comply with the requirement as written.

4. The Offeror will complete the highlighted sections Service Provider to Complete in each of the Critical Services Levels and Key Measurements by the following methods:

a. Metric Exclusions: Offeror to include in RFP Exhibit J.2.1 (Exceptions).

b. Collection Process: Not required for initial RFP response; this will be completed at a later stage in the procurement.

c. Reporting Tools: Offeror to include reporting tools in Section 4.20 Service Level Management of Exhibit 2.2 (MCS Solution).

Critical Service Levels This Section sets forth qualitative descriptions of the Critical Service Levels. The numerical Minimum Service Levels, Expected Service Levels, and commencement of obligations associated with such Critical Service Levels are set forth in Exhibit 3.1 (Service Level and Deliverable Matrix). Where reporting tools are identified below, State Agency Customers are tracked in the State of South Carolina, Department of Administration’s (Admin’s) IT Service Management (ITSM) system, and Service Level management Reporting system, while Other Government Entity Customers are tracked in Service Provider systems, and reported to Customers by the Service Provider. Comment by George Assenheimer: Added to call out the State Agency customer activity is tracked in the Admin ServiceNow, and Other Gov Entity activity is tracked in the Service Provider ITSM.

Service Provider Services Availability

SERVICE LEVEL NAME

Service Provider Services Availability

If downtime occurs for a Service, the Outage is counted against the Service, and the Service is considered unavailable for purposes of this Service Level.

Failures that do not result in any Outage.

Available minutes = the total number of minutes in a month (60 minutes x 24 hours x number of days in the month) for the service.

Unscheduled Downtime = the total number of available minutes in which a service is not available for reasons outside of metric exclusions and solely due to the fault of the Service Provider.

Service Level Management Reporting System

|_| Quarterly |_| Semi Annual

Incident Resolution Time - Priority 1 and Priority 2 Incidents

SERVICE LEVEL NAME

Incident Resolution Time –Priority 1 and Priority 2 Incidents

The applicable resolution timeframes are listed below.

Priority 1 Incidents: < 2 hours Priority 2 Incidents: < 4 hours

For purposes of clarity, note the following:

If an Incident is opened within the current Measurement Window, but its relevant resolution timeframe extends beyond the end of the current Measurement Window, then it is excluded from the current Measurement Window’s calculation (unless such Incident is actually Resolved in the current Measurement Window, in which case it is included in the current Measurement Window’s calculation).

Incident data will be loaded to Service Level Management Reporting system on a daily basis, where the Service Level result will be calculated and reported based on appropriate measurement criteria.

Service Level Management Reporting system

Service Request Fulfillment

Service Request Fulfillment

Specific target timeframes are maintained in the SMM.

For purposes of clarity, note the following:

If a Service Request is opened within the current Measurement Window, but its relevant committed timeframe extends beyond the end of the current Measurement Window, then it is excluded from the current Measurement Window’s calculation (unless such Service Request is actually resolved in the current Measurement Window, in which case it is included in the current Measurement Window’s calculation).

Service Request data will be uploaded to Service Level Management Reporting system on a daily basis; this tool will filter service request tickets based on appropriate measurement criteria.

Service Level Management Reporting System

Root Cause Analysis (RCA) Delivery

Root Cause Analysis Delivery

Service Provider will provide Root Cause Analyses on the most business-critical events, as maintained in the SMM, and as requested by the State for all other Incidents.

Problem data will be loaded to Service Level Management Reporting System on a daily basis, where the Service Level result will be calculated and reported based on appropriate measurement criteria.

Service Level Management Reporting System

RCA Corrective Action Implementation

RCA Corrective Action Implementation

Information Technology Service Management (ITSM) System

Corrective actions will be logged and tracked in the ITSM system. Corrective actions will be assigned to teams who will implement the corrective actions. The corrective actions will be progressed through the Problem Management lifecycle.

Problem data will be loaded to the Service Level management Reporting system on a daily basis, where the Service Level result will be calculated and reported based on appropriate measurement criteria.

Service Level Management Reporting System

Solution Proposal Delivery

Solution Proposal Delivery

Following validation of requirements by Service Provider, the Service Provider shall deliver a proposal for each request within the process defined in the SMM and in accordance with the following solution proposal targets:

· Simple - 10 business days

· Medium - 15 business days

· High - 20 business days

· Custom - 30 business days Definitions for simple, medium, high, and custom solution complexities to be defined in the Request Management SMM.

When a proposal is delivered, it must include a committed timeframe for project implementation specified as Business Days from the time the project is assigned to the Service Provider to the implementation completion, including Deliverable(s) as agreed by the State. These defined Deliverable due dates will be used in the “Project Deliverable Completion” Service Level.

For purposes of clarity, note the following:

If a solution proposal request is opened within the current Measurement Window, but its relevant committed timeframe extends beyond the end of the current Measurement Window, then it is excluded from the current Measurement Window’s calculation (unless such request is actually delivered in the current Measurement Window, in which case it is included in the current Measurement Window’s calculation).

Solution proposal data will be uploaded to Service Level Management Reporting System on a daily basis, where the Service Level result will be calculated and reported based on appropriate measurement criteria.

Service Level Management Reporting System

Solution Implementation

Solution Implementation

Projects will be reported in the Measurement Window in which the associated Project (PPM) ticket is closed, allowing sufficient time to determine if the project was successful.

For purposes of clarity, note the following:

1. if a Project is assigned within the current Measurement Window, but its relevant committed timeframe extends beyond the end of the current Measurement Window, then it is excluded from the current Measurement Window’s calculation (unless such project is actually implemented in the current Measurement Window, in which case it is included in the current Measurement Window’s calculation)

2. an uncompleted project is also carried forward into subsequent Measurement Windows as a breach until implemented; if it is implemented within twenty-eight (28) days following its relevant committed timeframe, it is excluded from the subsequent Measurement Window; otherwise, it is counted as failed to meet the committed timeframes in each subsequent Measurement Window’s calculation until implemented.

Solution implementation Data will be loaded to the Service Level Management Reporting System on a daily basis, where the Service Level result will be calculated and reported based on appropriate measurement criteria.

Service Level management Reporting system

Data Recovery Request

Data Recovery Request

For purposes of clarity, note the following:

a. if a service request is opened within the current Measurement Window, but its relevant committed timeframe extends beyond the end of the current Measurement Window, then it is excluded from the current Measurement Window’s calculation (unless the data recovery for a service request is actually initiated in the current Measurement Window, in which case it is included in the current Measurement Window’s calculation).

b. an open service request that has exceeded the committed timeframe is also carried forward into subsequent Measurement Windows as a breach until the data recovery is initiated; if it is resolved within twenty-eight (28) days following its relevant committed timeframe, it is excluded from the subsequent Measurement Window; otherwise, it is counted as failed to meet the committed timeframes in each subsequent Measurement Window’s calculation until initiated.

Data recovery requests are handled as service requests in the ITSM. Service requests will be categorized and assigned to resolver teams who will work to fulfill the service request and progress the ticket through the service request management lifecycle.

If a data recovery is required during the course of Incident resolution, a Recoveries service request must be submitted and related to the associated Incident ticket.

Service Provider will update service request to designate when the data recovery has been initiated. The service request is updated with success or failure once the data recovery request has been fulfilled and approved for closure.

Priority 3 Incidents are created for backups that are not successfully completed the first time. Subsequent backup failures generate additional incidents with escalating priority.

Service Level management Reporting system

Change Management Effectiveness

Change Management Effectiveness

Changes are not successfully implemented if they: (i) do not comply with the Change Management procedures (including the Change Control Process), the SMM, and except as specified in clause (iii) to this sentence, any associated project plan; (ii) cause either a Priority 1 Incident or Priority 2 Incident; (iii) exceeded the change window; (iv) are backed out; or (v) partial success of change is backed out or unsuccessful.

Change data will be loaded to Service Level Management Reporting System on a daily basis, where the Service Level result will be calculated and reported based on appropriate measurement criteria.

Service Level Management Reporting System

Vulnerability Management

Vulnerability Management

Excused events approved by the State through the SLA Exception procedure documented in the SMM.

The Change Management record will document, categorize, and be assigned to implementer teams who will work to plan, review, obtain approvals, and progress the ticket through the change management lifecycle. If the patch is approved by the Customer and CAB (Change Advisory Board), Service Provider will follow the Change Management Process to schedule the patch installation. If the change is rejected by Customer, it will not be measured in the SLA.

SLA is measured from the date the vulnerability is identified and categorized \ Vulnerability resolved date (change closed as successful).

Service Level Management Reporting System

Key Service Levels This Article sets forth qualitative descriptions of the Key Service Levels. The numerical Minimum Service Levels, Expected Service Levels, and commencement of obligations associated with such Key Service Levels are set forth in Exhibit 3.1 (Service Level and Deliverable Matrix). Where reporting tools are identified below, State Agency Customers are tracked in the State of South Carolina, Department of Administration’s (Admin’s) IT Service Management (ITSM) system, and Service Level management Reporting system, while Other Government Entity Customers are tracked in Service Provider systems, and reported to Customers by the Service Provider.

Invoice Dispute Resolution

Invoice Dispute Resolution

For purposes of clarity, note the following:

If an invoice dispute is initiated within the current Measurement Window, but the twenty Business Days extends beyond the end of the current Measurement Window, then it is excluded from the current Measurement Window’s calculation (unless such dispute is actually resolved in the current Measurement Window, in which case it is included in the current Measurement Window’s calculation).

Invoice Dispute data will be loaded to Service Level Management Reporting System on a daily basis, where the Service Level result will be calculated and reported based on appropriate measurement criteria.

Service Level Management Reporting System

ROM Proposal Delivery

ROM Proposal Delivery

Data will be loaded to Service Level management Reporting system on a daily basis, where the Service Level result will be calculated and reported based on appropriate measurement criteria.

Service Level management Reporting system

Incident Resolution Time - Priority 3 and Priority 4 Incidents

Incident Resolution Time – Priority 3 and 4 Incidents

The applicable resolution timeframes are listed below.

Priority 3 Incidents:

The Incident shall be Resolved within 1320 minutes (i.e., 22 Business Hours) where such minutes shall be measured only between 7:00 AM and 6:00 PM inclusive on Business Days.

Priority 4 Incidents:

The Incident shall be Resolved within 1980 minutes (i.e., 33 Business Hours) where such minutes shall be measured only between 7:00 AM and 6:00 PM inclusive on Business Days.

For purposes of clarity, note the following:

if an Incident is opened within the current Measurement Window, but its relevant resolution timeframe extends beyond the end of the current Measurement Window, then it is excluded from the current Measurement Window’s calculation (unless such Incident is actually Resolved in the current Measurement Window, in which case it is included in the current Measurement Window’s calculation)

Incident data will be loaded to Service Level Management Reporting System on a daily basis, where the Service Level result will be calculated and reported based on appropriate measurement criteria.

Service Level Management Reporting System

State Fiscal Accountability Authority Page 1 image1.png