supplement 1: salesforce platform managed service supplement 1... · web viewdemand data...

Supplement 1Ohio Department of Rehabilitation and Correction

Environmental Sustainability Tracking System

Table of Contents1.0 DRC Environmental Sustainability Tracking System..............................................................................................................................3

1.1. Background and Overview 31.2. General Scope and Objectives 31.3. Organization of Requirements and Scope of this Supplement 31.4. Environmental Sustainability Tracking System - General Objectives 41.5. Offeror Response: Functionality Delivered 41.6. Offeror Response: Comments and Narrative 4

2.0 System Functional Requirements.............................................................................................................................................................5Functional Requirements Matrix 5

3.0 System Technical Requirements.............................................................................................................................................................113.1. Current System Volumetric / Sizing Information 113.2. System Security Plan. 113.3. System Deployment Plan. 11

4.0 System Integration Requirements...........................................................................................................................................................124.1. Operational Documentation 12

5.0 System Data Conversion Requirements.................................................................................................................................................146.0 Ongoing Operations Requirements........................................................................................................................................................15

6.1. General Requirements: Hosted/Cloud Software Solution 156.2. System Environment Requirements 156.3. Production/Version Control and Release Management 166.4. Break/Fix Support 176.5. Application Licensing, Capacity Planning and Monitoring 176.6. Software Platform System Management and Administration 176.7. Major/Minor Upgrades (Ongoing) 186.8. Program Management & Master Release Calendar 196.9. Environment Backup and Restoration Services 206.10.Support of State Disaster Recovery 206.11.System Incidents and Resolution 216.12.Data Management Functions. 22

7.0 Project Training Requirements................................................................................................................................................................237.1. General Training Requirements 237.2. Training Planning and Execution Requirements 237.3. DRC and DYS Training Requirements 23

8.0 Operational Support / Help Desk Requirements....................................................................................................................................258.1. Customer Support Services 25

9.0 Service Levels...........................................................................................................................................................................................269.1. Service Level Framework 269.2. Service Level Specific Performance Credits 269.3. Monthly Service Level Report 269.4. Escalation for Repetitive Service Level Failures 279.5. Service Level Requirements (SLAs) 279.5.1 Project Implementation Service Levels 289.5.2. On-Going Operations/Maintenance Service Levels 31

10.0 Contractor Staffing and Personnel Requirements.................................................................................................................................3410.1.Contractor Staffing Plan, Time Commitment and Work Locations 3410.2.Contractor Personnel Requirements 34

State of Ohio Department of Administrative Services Supplement 1: DRC Environmental Sustainability Tracking System of 44

10.3.Criminal Background Check of Personnel 35

11.0 Contract Governance Processes and Requirements............................................................................................................................3611.1.Informal Dispute Resolution 3611.2.Internal Escalation Obligations and Requirements 3611.3.Escalation for Repetitive Service Level Failures 3711.4.No Termination or Suspension of Services or Payment. 3711.5.Back-Up Documentation 3711.6.Correction of Errors 37

12.0 Contract Conclusion Requirements: Transition to Successor Contractor or State at Contract Termination or Non-Renewal......3812.1.Overview 3812.2.Standards 3812.3.Termination Assistance Plan 3812.4.Ownership of State Data and Provision for Providing the State Data at Contract Conclusion 39

13.0 Offeror Assumptions, Support Requirements, Pre-Existing and Commercial Materials....................................................................4013.1.Assumptions 4013.2.Support Requirements 4013.3.Pre-Existing Materials 4013.4.Commercial Materials 40

14.0 Reference and Informational Data...........................................................................................................................................................41


1.0 DRC Environmental Sustainability Tracking System

1.1. Background and Overview

The Ohio Department of Rehabilitation and Correction (DRC) and the Ohio Department of Youth Services (DYS) began working together on strategic sustainability goals in an attempt to cut fuel and electricity costs, lower waste disposal fees and reduce water usage and sewer bills.

Based on 2012 goals, the agencies continue to be committed to enhancing ecological and economic sustainability by integrating environmentally sustainable practices into policy, procedure and operation. The agencies are also interested in future sustainability plan goals, which may potentially include greenhouse gas emissions, building energy intensity, and renewable energy sources.

The agencies wish to move away from dependence on applications, such as the U.S. Department of Energy’s online Energy Star Portfolio Manager and an internal Enterprise Information Management (EIM) tracking system to a more robust energy management software-as-a-service (SaaS) platform utility tracking and reporting tool. A system that will ultimately provide the tools needed to meet and surpass strategic sustainability goals set years ago.

1.2. General Scope and Objectives

The objective of this RFP is to procure cloud-based, software-as-a-service (SaaS) from a Contractor who can provide a proven solution that has utility tracking and reporting functionality that will significantly enhance transparency and increase the availability of energy, water, and other data to support decision-making and communication about the agency utility-related priorities, efforts, and results. DRC is seeking proposals for a SaaS solution that must interface with the U.S. Department of Energy’s online Energy Star Portfolio Manager and the various utilities, vendors and providers of services (Table 1 Section 14.0 Reference and Informational Data) to the DRC and DYS facilities (Table 2 Section 14.0 Reference and Informational Data).

This system must provide web-based interface for authorized agency users, providing role-based permissions access for data entry, editing, reporting, and viewing capabilities. The system must allow for an automated flow of billing data from utilities, vendors and providers of services to DRC and DYS facilities. The proposed system must also track utility data, such as monthly consumption by fuel type and by facility, provider account numbers by utility and by facility, rate class and tariff codes and more.

The information collected from the tracking system must be accessible from acentralized location for the purposes of review and flexible report access and creation by the authorized agency users. The data format should be organized in a hierarchical manner, using friendly data visualization tools, such as energy dashboards, informative displays, and easy to view and detailed graphs and tables for use by executive, management and public audiences. The format of the tracking system must also provide a drill-down capability to increase transparency and improve data communications to a wide range of agency audiences.

1.3. Organization of Requirements and Scope of this Supplement

The State has organized this Supplement and the requirements herein in the following general categories. Specific requirements are contained later in this Supplement.

System Functional Requirements

System Technical Requirements


System Integration Requirements

Current System Data Conversion Requirements

Ongoing Operations Requirements

1.4. Environmental Sustainability Tracking System - General Objectives

Via this Supplement, the State seeks to identify an Offeror to implement and thereafter manage a cloud-based SaaS solution for use by DRC and DYS:

This RFP is designed to receive responses for Services that must allow the State to implement the system, and drive efficiencies with respect to ongoing operations, continued extension of the system and its use, as well as drive higher levels of service for the users and beneficiaries of the system.

1.5. Offeror Response: Functionality Delivered

The State has provided functional requirements in categories (using a requirements matrix contained in Section 2.0 of this Supplement). The offeror’s response to the State must address all requirements in the matrix. The State’s evaluation of responses will include the potential of any solution to support the accomplishment of the State’s goals. Additionally, the offeror’s proposal response must include all requirements. From a design and implementation perspective, requirements not listed in the matrix are out of scope for the project but may be authorized by the State under a fully executed Amendment to this Contract at a later date pending the successful outcome of initial work and then current State preferences. No new or additional work shall be performed by the Contractor without the State’s written authorization to proceed under a change order and fully executed amendment to this Contract.

As part of their response to this Supplement, the offeror must place an “X” in the column that is most reflective of the method to deliver the State’s required functionality using the following nomenclature:

Matrix Column Offeror Response Considerations

Base Those items that can be delivered as part of a base solution without any configuration or customization.

Config(uration)Those items that can be delivered as part of the solution through configuration or administrator level graphical user interface driven configuration items, or other methods which do not require programming, scripting or development effort.

Not Supported or

Recommended

Those items that are not supported via the solution, or in the opinion of the offeror cannot be reasonably achieved over the time horizon of Initial Release or in a commercially reasonable or recommended manner (e.g., cost, time, platform, architecture, maintenance and other factors)

1.6. Offeror Response: Comments and Narrative

In addition, the State has provided as part of the Requirements Matrix a free form field labeled ‘Offeror Narrative’ that is designed to facilitate the offeror’s response to the requirements in such a manner as to convey any offeror considerations, showcase offeror capability to deliver or identify any offeror requirements on the State with regard to detailed requirements contained in the matrix. Offerors may include graphics, screen images or other text oriented verbiage in this column as they deem appropriate to offer the State a complete solution as required.


2.0 System Functional Requirements

Functional Requirements Matrix

Functionality Delivered Through: (indicate with 'X')

Req. # Implementation Area Requirement Description

Bas

e

Con

fig

Not

Su

ppor

ted

Offeror Narrative and Response

Platform

P1 PlatformA cloud-based solution, software-as-a-service option that will not require investments in hardware and maintenance by DRC or DYS.

Accessibility

A1 Accessibility A web-based interface for authorized users of DRC and DYS to access, providing role‐based permissions access to data entry, editing and reporting.

A2 Accessibility Minimum of 60 users with data entry capability; minimum of 2 users with full access; unlimited users with view-only access and/or ability to post real-time reports on agency intranets or public websites.

A3 Accessibility Interface must be simple to access remotely from any computer.Data Automation

DA1 Data AutomationAn automated flow of bill data from utility/provider to the centralized location with minimal or no manual input required from any DRC or DYS staff.

DA2 Data Automation

Data Manual Entry: Agency- or institution-specific portals for manual data entry, with a clear audit trail, for use when neither automation nor templates can be used.

Data Manual Entry is considered a last resort solution. Solutions where excessive manual entry is required will not be considered. Manual entry by vendor is preferred to DRC manual entry.

DA3 Data AutomationData Templates: Template spreadsheets that can easily be filled out and imported, for use when automation is not possible with existing systems.

Utility Data Tracking: The system must track the following utility items at a minimum:UDT 1 Utility Data Tracking Monthly energy consumption for each fuel typeUDT 2 Utility Data Tracking Account numbersUDT 3 Utility Data Tracking Rate class and tariff codes for each accountUDT 4 Utility Data Tracking Meter numbersUDT 5 Utility Data Tracking Meter read datesUDT 6 Utility Data Tracking Facility locations and service address




Bas

e

Con

fig

Not

Su

ppor

ted


UDT 7 Utility Data Tracking All costs including supplier costsUDT 8 Utility Data Tracking All other changes and credits specified on billsUDT 9 Utility Data Tracking Demand data including metered peak and billed peakUDT 10 Utility Data Tracking Power factor/reactive power and charges where applicable

UDT 11 Utility Data TrackingTotal amount, cost, and revenue (where applicable) of Waste and Recycling streams

UDT 12 Utility Data Tracking Water and sewer consumption and costs for each facilityHistorical Data Import

HDI 1 Historical Data ImportA minimum of three years of historical utility bill information captured and populated into the database by the Contractor

Data Export: Users with access to the solution must have a simple means of data export. DE 1 Data Export Data export must be available in CSV formatDE 2 Data Export Data export must be available in Excel formatDE 3 Data Export Graphs must be available for download in JPG and/or PNG

Data Ownership DO 1 Data Ownership DRC and DYS will own all data in this solution.

DO 2 Data OwnershipIf, at a future time, the relationship between DRC, DYS, and the solution provider is finished, DRC and DYS will be given a comprehensive system-wide data export.

DO 3 Data OwnershipIf, at a future time, the relationship between DRC, DYS, and the solution provider is finished the data stored by the solution provider will then be destroyed after it is provided to agency.

Data Review

DR 1 Data ReviewA utility bill audit or review process that automatically identifies and alerts users of utility usage and cost abnormalities/anomalies.

DR 2 Data ReviewThe proposed solution should be capable of identifying abnormal spikes in consumption and alerting users as necessary.

DR 3 Data ReviewThe proposed solution should be capable of reviewing utility costs and verifying that all utility rates and tariffs are being correctly applied by the utility and alert users in the event of a billing error.

Dashboards

D 1 DashboardsData visualization tools for executive/management, with drill down capability to increase transparency and improve data communications to a wide range of audiences.

D 2 DashboardsIt is preferred that data is organized in a hierarchical manner with regions being the highest level of view and each subsequent step below being obvious and necessary.

Reporting




Bas

e

Con

fig

Not

Su

ppor

ted


R 1 Reporting

Detailed and flexible reporting on utility by:1. Usage2. Costs3. Weather-normalized 4. Year-to-year comparison5. Cost avoidance6. Facility-to-Facility Comparison7. Greenhouse gases8. Progress towards goals identified in the agencies

Sustainability Plans, in all locations.

R 2 Reporting

All reports must be viewable via the web and compatible with downloading into appropriate software such as:

1. MS Excel2. MS Word3. PDF

R 3 Reporting

Reports must be generated for different levels by: Utility type Facility Population Region Agency-wide by month Agency-wide by fiscal year

R 4 Reporting

Reporting functionality should include the ability to create ad hoc reports. Data searches should at least be available by:

Cost Usage Use per square foot Other variables such as use by inmate population

R 5 Reporting

Reports should be available for each meter, each facility, and the entire portfolio which break out consumption, demand (if applicable), and costs.

Breakouts of total costs should be shown where possible (customer charges, generation/transmission charges, and other tariffs).

R 6 Reporting

Reports must have the ability to add costs from multiple suppliers for the same account and billing period. (i.e., AEP Ohio as utility and Champion Energy as supplier to get total electric costs for a billing period.)




Bas

e

Con

fig

Not

Su

ppor

ted


R 7 ReportingA monthly report of both paid late fees and potential late fees which would be incurred by DRC and DYS, if bills are not paid on time should be available.

R 8 ReportingReports which compare facilities should be normalized by billing period.

R 9 ReportingReporting should include the ability to present agency data in established formats used by the Global Reporting Initiative and others.

Energy Savings Measurement & Verification

ESMV 1Energy Savings Measurement & Verification

Ability to enter project milestones and track project success metrics, such as the ROI for retrofit lighting projects or the cost avoidance achieved by replacing obsolete chillers. This data should be able to support verification of savings achieved by energy performance contracts.

ESMV 2Energy Savings Measurement & Verification

Data must be able to be weather normalized on a monthly basis, based on degree day or temperature data derived from an authoritative source such as the National Weather Service or the Energy Information Administration appropriate for the location.

Greenhouse Gas Emission Tracking

GGET 1Greenhouse Gas Emission Tracking

Ability to establish an emissions baseline for the agencies, track reductions, and include automated calculation of conversion factors. Use generation profiles for actual utility bills to determine these appropriate conversions (lbs. CO2 per kWh, mmBTU etc.). These should be capable of being updated to reflect greenhouse gas emissions savings resulting from changes in energy procurement.

ENERGY STAR Tracking and Integration

ESTI 1ENERGY STAR Tracking and Integration

Direct connection to the ENERGY STAR Portfolio Manager system, to enable easier benchmarking and rating of buildings. (It should be noted, that DRC and DYS have utilized Portfolio Manager in the past, but this historical data contains significant gaps and errors. Therefore, a new Portfolio Manager account will need to be created.)




Bas

e

Con

fig

Not

Su

ppor

ted


ESTI 2ENERGY STAR Tracking and Integration

The following items must be tracked or input in portfolio manager:a. Facility name and addressb. Facility square footage and space use typesc. Meter read dates,d. Volume of energy consumed during the billing period for each

fuel type,e. Water/sewer consumption and costsf. All costs including supplier costs,g. Electric demandh. A minimum of two years of historical data must be input to

Portfolio Manager.

Utility Bill Storage

UBS 1 Utility Bill StorageThe proposed solution must be capable of storing .PDF copies of all utility bills for a minimum of three years, which can be easily viewed or downloaded as needed.

Security

S 1 SecurityThe solution will not reside on DYS or DRC servers, and will not require any connections to DYS or DRC networks or servers.

Growth and Flexibility

GF 1 Growth and Flexibility

The proposed solution must have the ability to include additional options in the future, such as installing meters, sensors, transmitters, receivers, and any other hardware necessary for increased, real-time tracking.

Sustainability-Related Program Tracking

SRPT 1Sustainability-Related Program Tracking

Tracking additional goals and data from other ODRC Sustainability Initiatives (http://www.drc.ohio.gov/web/sustainability_plan.pdf), such as youth/offender participation sustainability-related programs.

SRPT 2Sustainability-Related Program Tracking

The system must either include this tracking capability from the start, or have the ability for the Contractor or the full-access users to add simple, additional categories for tracking count data at each institution. For example:




Bas

e

Con

fig

Not

Su

ppor

ted


Category Data FieldsEnvironmental Literacy Program

Institution Graduation Date Number of Graduates

Community Gardening

Institution Type of produce grown (corn, lettuce, etc.) Pounds of produce grown Donation date Donation recipient Number of offenders/youth involved

Animal Rehabilitation

Institution Type of animal (squirrels, dogs, etc.) Number of animals served Number of offenders/youth involved Community partner name

Each institutional user should have the ability to enter this information manually through a portal or spreadsheet template.

Additional Features: Offerors are NOT required to address these Additional Features. It should also be noted that this list is not exhaustive and offerors may include other Additional Features deemed appropriate to achieve DRC and DYS objectives.

AF 1 Usage Splits

Proposed solution provides formulas and automation to calculate and split billing and usage information for institutions that have certain utilities metered together. (For example, Lebanon and Warren Correctional Institutions share one electric meter and currently split the bill based on inmate population ratios. The agencies are open to new methods that would increase the accuracy of this data, including the installation of sub-meters.)

AF 2 Mobile Access Interface is simple to access remotely from any mobile device.

AF 3 Potential Late FeesProposed solution provides notification to specific users when bills are due and what late fees will be incurred if bills are not paid on time.

Additional Features, if any, Provided by Proposed Solution


3.0 System Technical Requirements

3.1. Current System Volumetric / Sizing Information

DRC owns and operates twenty-five (25) prisons totaling 12,000,000 square feet across 527 buildings. The current inmate population is approximately 50,000 men and women with a turnover rate of around 45% per year. DRC employs over 12,000 staff and operates 32 Ohio Penal Industries (OPI) shops. OPI is an inmate work program and a division of DRC. OPI manufactures goods and services for DRC and other state agencies using inmate labor under close staff supervision. Collectively, the institutions use over 183 million kWh of electricity, 1.9 million mcf of natural gas, and 2 billion gallons of water per year; while spending roughly $1.7 million on waste disposal services annually. The square footage and building counts listed, include all buildings inside facility perimeter fences, which may include small storage buildings and sheds. The figures do not include the water treatment facilities, farm operation facilities, OPI facilities outside of the fence, the agency Central Office location, or the Community-Based Correctional Facilities.

DYS owns and operates three (3) correctional facilities, totaling 496,084 square feet across the buildings. The facilities house over 400 youth and employ 1,200 staff. In addition, DYS supports four (4) Community-Based Correctional Facilities and five (5) Regional Parole Offices. Collectively, these locations use over 8.1 million kWh of electricity, 35,000 kcf of natural gas and 3,500 gallons of water per year.

See list of facilities in Table 2 Section 14.0 Reference and Informational Data.

It is the intention of DRC and DYS that the procured solution comprehensively tracks all utility data for the DRC’s entire portfolio, including facilities not included in these figures.

3.2. System Security Plan.

The Contractor must develop a Security Plan. This plan must detail all methods of security, including all protocols and technologies used by the System based on the NIST 800-53 revision 4 security controls framework for a FIPS 199 System Security Category of Moderate. Transmitted data must be protected by FIPS 140-2 compliant modules and algorithms.

This plan must include, among other things, details describing the system’s adherence to and compliance with the State’s security regulations, policies, and procedures, security aspects of the system’s physical architecture, detailed descriptions of all user access roles and their corresponding security levels. This plan must include a diagram(s) and explanation of the System security architecture. If the plan is changed, it must be resubmitted to the State. All updates and revisions to the plan must be approved by the State.

The plan must also conform to Supplement 2, the State Security, Privacy and Data Handling Requirements where applicable.

Deliverable 001. System Security Plan

3.3. System Deployment Plan.

The Contractor must develop a Deployment Plan that details how the Tracking System will be deployed to the agency users. It must detail how the System interfaces will be implemented, identify user documentation and its deployment, weekly progress meetings, and identify system configuration requirements for interface data file transfers.

Deliverable 002. System Deployment Plan


4.0 System Integration RequirementsThe Contractor must develop and maintain a Detailed Data Interface Document. The Detailed Data Interface Document (DID) must be available in hardcopy and electronic media, in a format approved by DRC and DYS that must include:

An identification of system files and processing architecture to support data interfaces;

A general narrative of the flow of data interfaces to and from the system;

A detailed description and diagram of the interfaces system architecture identifying how components are integrated to meet RFP requirements;

A listing and brief description of each file;

Final layouts for all interface files to include, at a minimum, file names, data element names, comprehensive data element dictionary with valid values, record length, record names and types, data validation rules for file data content and related processing to insure data integrity and quality;

Application Programming Interfaces (APIs) used within the application to communicate with DRC and DYS for data interfaces or with external systems must also be defined; and

Security controls and protocols used to ensure Confidentiality, Integrity and Availability of the Interfaces (i.e., Encryption, Authentication, etc.).

Deliverable 003. Detailed Data Interface Document.

The Contractor must conduct walkthroughs of the Data Interface Document with the DRC and DYS Project Representative and technical resources during the development of the design specifications for the data interfaces to enable the State’s understanding of the system data file interface and processing.

4.1. Operational Documentation

The Contractor must prepare and maintain documentation for all functionality. The Contractor will be responsible for the production and distribution of all systems documentation upon implementation, and provide updates, as completed, in a timely manner.

The following are minimum requirements for the Tracking System electronic documentation:

Must include on-line, context-sensitive help screens for all the System functions;

Must be written and organized in a manner that users can learn from reading the documentation how to operate the time and attendance system and perform all related functions;

Must be written in a procedural, step-by-step format;

User manuals must contain a table of contents and an index;

Descriptions of all error messages and the steps to correct such errors must be provided;

Abbreviations and acronyms must be consistent throughout the documentation and defined in a glossary;

Must contain a list of valid values and descriptions for all data fields;

Each user manual must contain illustrations depicting how to use the system;

Use version control numbering with detailed history to reflect amendments and additions;

Maintain dating history (i.e. date of issue, date of approval and/or date of implementation).

Update documentation within 30 days of processes, procedures and system functionality changes

Secure access to workflow documentation to prevent unauthorized changes.


Communicate proposed policy/procedure changes to State prior to implementation for State approval

Each user manual must contain a section describing all reports generated within system, which includes: The purpose of the report; definition of all fields in the report, including detailed explanations of calculations used to create all data and explanations of all subtotals and totals; and Illustrations of reports.

Instructions for creating, accessing, or requesting reports;

The Contractor must provide and maintain a Tracking System Administration Manual detailing the business and technical functions and use of administration modules by State staff.

The manual may be broken into smaller functional manuals for distribution to the appropriate roles that individuals may have.

Deliverable 004. Operational Documentation


5.0 System Data Conversion RequirementsAt the time of implementation, the Contractor must be able to accept a number of files sent from DRC and DYS containing a minimum of three (3) years of historical utility bill (over 340 utility bills/invoices monthly) information.

This information, files and all conversion data must be captured and populated into the database by the Contractor.


6.0 Ongoing Operations Requirements

6.1. General Requirements: Hosted/Cloud Software Solution

The Hosted/Cloud Software Solution must be hosted, operated and maintained by the Contractor as to adhere to the following Requirements and Service Level Agreements:

All data and access to the system must strictly adhere to Ohio Executive Order 2011-12K, which is a prohibition on offshoring any State data or processes.

All State data must reside on a Federal Risk and Management Program (FEDRAMP) certified platforms that are FEDRAMP IAAS/SAAS Authorized with FEDRAMP Impact Level: Moderate or Higher.

All data access, security, privacy and data handling requirements must be adhered to as contained in this Supplement and as applicable, the requirements of Supplement 2, the State Security, Privacy and Data Handling Requirements.

6.2. System Environment Requirements

Based on the State’s typical systems development lifecycle, inclusive of ongoing operations and maintenance activities, the State has developed a set of Systems Environments that are required to support the initial implementation of the system and its ongoing use.

Offerors are encouraged to consider the merits of these Systems Environments and propose (if feasible and advisable) managing these environments to drive availability, releases, efficiency, cost, State licenses and other consolidation/optimizations. Should the State agree with such approaches, the Offeror, as Contractor must perform the consolidation/optimizations as contracted.

As part of the end-to-end project and ongoing service, the Contractor must include the management and maintenance, encompassing deployment/management, testing and training environments for the instances of the State Applications and supporting evolutions as required to support the State in the context of operating the system and comply with State laws and Federal guidelines.

The table below reflects the State’s requirements in terms of environments. To the extent the Offeror wishes to suggest alternatives based upon Contractor and Industry best-practices, the Offeror may do so in their response to this section.

Environment Solution

Demo / Sandbox / Proof of Concept / Training ü

Development & Configuration ü

Acceptance Testing ü

Production ü

Descriptions of the instances are as follows:

Demo/Sandbox/PoC/Training: This is the instance delivered by the Contractor for diagnostic purposes. All patches and bundles must be applied to this instance. No customizations, modifications or configurations must be made to this instance. This instance is used for classroom and web-based training.

Development & Configuration: All development activity including customizations, modifications or configurations must be made in this instance as needed.


Acceptance Testing: This instance allows State testers and pilot users to assess production acceptance issues and for performance testing.

Production: This is the main transactional instance for the State Application.

Other replicas of these environments to support SDLC activities and other efforts upon the request of the State.

6.3. Production/Version Control and Release Management

The Contractor will be responsible for working with the State and executing the production deployment and roll-out of any Release Package or Application to the State’s software environment. Releases must include (at a minimum): new application(s) inclusive of Contractor developed applications; 3rd party developed or licensed software extensions; State integrations (ESB or File-Based); production batch or scheduled job streams; and related software reports, interfaces, conversions, forms, workflows or extensions (RICEFW).

Production deployment includes software deployment to the production instance of software and (if applicable) interfaces to production tools and systems that orchestrate, manage, report or control those devices and services managed by the Service, identification of interfaces and any required conversions/migrations, installation of server software, and any required testing to achieve the proper roll-out of the Release Package software.

As part of this Service, the Contractor must:

Establish for the State and thereafter comply with and enforce a repeatable State software implementation and deployment procedure. This may include laboratory testing, migration procedures, the use of any pre-production or pseudo-production environment prior to production migration;

For each release, submit to the State, for the State’s approval, a written deployment plan describing Contractor’s plan to manage each such implementation. The tasks and activities to be performed by Contractor as part of software production deployment services;

Establish and follow procedures and automated software versioning mechanism(s) to ensure that the entire contents of a release, following State acceptance or authorization to implement to a production environment, are complete and maintain all elements that comprise the defined Release Package and the then current production version of the software prior to deployment of the Release Package;

Develop, prepare and test emergency back out or roll back procedures to return the production system to its pre-deployment State as it pertains to correcting an errant, erroneous or defective deployment of a Release Package to the production environment inclusive of all code, data, middleware, infrastructure, tables and parameters;

If, in the mutual opinion of the State and Contractor, the deployment of a Release package to the production environment is errant, erroneous or otherwise defective, implement back-out or rollback procedures in their entirety upon the written authorization or direction of the State.

If required, convert electronic data into a format to be used by the new solution using a data conversion program;

Conduct production pilot(s) (including “day in the life” simulations) and fine tune solution as mutually agreed with the State as appropriate;

Compile and maintain solution issue lists;

Conduct post Production Deployment quality and progress reviews with appropriate State personnel, and (if requested by the State) State Systems Integrator/Contractor;

Develop, and thereafter maintain and make available to the State, a knowledge base of documentation gathered throughout the Release Package’s life and allow for re-use of such documentation for future Projects; and


Establish a performance baseline for the impacted business systems, and where appropriate document requirements for future enhancement of the business systems implemented as part of a future Project or Authorized Work.

6.4. Break/Fix Support

The Contractor must:

Track, monitor and provide remediation for solution defects and incidents requiring system configuration or in-scope environment code or configuration changes arising from the application of any of software, State Contracted RICEFW enhancements to the State’s software platform and Agency integrations;

Address any incompatibilities, inconsistencies or erroneous processing introduced to the State’s software platform and Agency applications that arise from any production release, patch, update, upgrade or change in code or configuration values;

Identify and implement required system or configuration changes to address solution defects;

Test configuration changes to confirm resolution of defects;

Support the State in performing applicable acceptance testing or review of any changes arising as a result of break/fix or patch/release Contractor responsibilities; and

Ensure compliance with any State Security/Privacy requirements or software mandated patches or system levels to the extent and system enhancement turnaround time required given the nature of the security mandate and report to the State in writing any risks or issues that the Contractor becomes aware of in providing Service to the State. For example: patches designed to address immediate or active Security issues may be scheduled for a near-real-time release, where other less pressing releases may be implemented during a scheduled maintenance or outage period.

Maintain solution documentation (technical specifications and testing documentation) as well as a compendium of common problems, root causes and remedy to aid in the identification and remediation of underlying system incidents.

6.5. Application Licensing, Capacity Planning and Monitoring


Review the State growth plans during quarterly service review meetings, and if requested due to an unforeseen requirement, participate in the required number of ad-hoc reviews coincident with these new requirements and software application needs to correctly plan for licensing and capacity – periodic capacity increases as well as burst requirements.

Monitor software and State application usage and capacity, forecast capacity and review with the State Infrastructure Management on a quarterly basis.

The State will:

Project future software based trends and capacity requirements in conjunction with receipt of Contractor provided capacity usage reports, and in consultation with the Contractor, for new Projects and provide such information to the Contractor as it pertains to the Services;

Review software system performance, licensing and capacity and throughput for new applications before promotion into the production environment to resolve any overcapacity situations.


6.6. Software Platform System Management and Administration


Software platform-level administration, reporting, and support. software platform support does not include Level 1 and Business Level 2 help desk functions (i.e., end-user facing), but only those Level 2 and 3 items (i.e., technical, integration and application/code based functions) that are specific to software and Agency integrations within the Contracted scope of Services;

Coordinate the installation, testing, operation, troubleshooting and maintaining of the software.

Identify and test packaging patches and other updates associated with supported software, as well as supporting additional security-related fixes associated with the Systems software.

Manage the security functions related to the software including administrative access and passwords (i.e., users with root, admin, administrator, DBA or low-level read/write access) and the related security controls to maintain the integrity of the software, based on the State’s security standards.

Configure and maintain systems managed by the Contractor for network and remote access.

Provide advisory services to support the software administration and developer access services and roles.

Review supported software administration, set-up and configuration

Support performance tuning of State application elements and perform performance tuning on software elements

The State will:

Assist the Contractor in developing procedures for handling all planned and unplanned outages affecting the software Platform and State Applications including review, approval, communication and proper documentation; and

Notify the Contractor of any planned or emergency changes to the State’s environment affecting the Contractor's delivery of the Services.

6.7. Major/Minor Upgrades (Ongoing)

Release upgrades for packaged software are initiated through periodic releases by software as Major or Minor releases. The State requires that the Contractor lead and coordinate efforts to analyze, install/apply, test/verify and utilize State specified RICEFW objects to these releases in the Contractor provided environment. As the State is dependent on software and is responsible for State infrastructure operations, this coordination and leadership must be well defined and executed so that the State can realize the benefits of a release while not introducing any service impacting or application or integration related issues.

Further, the State understands the importance of software major and minor upgrades to its overall capabilities in support of the State’s mission and in particular over the life a multi-year Contract and is committed to maintaining the Services to the State via the Contractor software platform and related service at the most current proven release at all times, unless the State provides a written exception. The Contractor must maintain ongoing compliance with software requirements, standards and conventions for maintenance of the software platform and Agency applications and Contractor-provided elements that comprise these Agency or Enterprise software-based systems.

The Contractor is to comply with the following requirements:

The State’s requirement is to always operate on a set of Application and Technical Infrastructure components that are on the current software release and support model and terms as provided by software;

As part of annual planning and coincident with monthly project review meetings, the Contractor is to inform the State in writing of any components that are moving beyond a current support model or would rendered unusable as


a result of an upcoming release and present a plan to implement the required updates in a controlled manner to the applicable State environment(s) to maintain compliance software support models;

Based on review of any upgrade or update plan (inclusive of all elements required to effectively manage, resource, test, validate and implement the change as outlined elsewhere in this statement of work, the State and the Contractor will schedule a mutually agreeable upgrade / update effort and authorize the Contractor to perform these upgrade services to maintain the required support model;

Upgrade and update efforts must factor any regularly scheduled batch processing or system availability as well as any seasonal processing requirements and should be scheduled to maintain compliance with system availability in consideration of then prevailing development release or production schedule;

The Contractor will be responsible for the design, development, and implementation of the Minor/Major enhancements in the State environments including requirements/design discussions, applicable conference room pilots, design review/signoff, document design specification, document and execute unit and integration/interface tests, support of the State in executing UAT;

The Contractor must support the State in the planning and deployment of periodic releases of non-emergency patches and enhancements (e.g., test new functionality, regression test entire application, document release notes, coordinate with the State for end user change management/communication) as well as perform these responsibilities for all Contractor developed elements for the State;

The Contractor must be capable of verifying and accepting enhancements not developed by the Contractor (e.g., review designs, execute tests, migration to production);

All System Enhancements must be performed in accordance with the appropriate software development lifecycle procedures in this Supplement; and

For any applicable code based deliverables that are accepted by the State or otherwise placed in commercial use, the Contractor must provide an electronic copy of all source and executable code elements to the State as part of the deployment of the element’s introduction to production or commercial use.

Notwithstanding Major and Minor Upgrade enhancement requirements as outlined above, the Contractor has an obligation to maintain all software elements in keeping with a current support and in accordance with agreed procedures associated with the minimization of exposure to viruses, malicious software (malware), security holes or flaws, incompatibility issues, software patch currency, technical updates, corrections and other elements that directly influence the warrantee, support, performance and ongoing upgradeability of underlying software and State specified RICEFW objects of the software platform service.

Upgrades and updates must be scheduled in such a manner as to minimize disruption, capital requirements and risk to the State while balancing Contractor staffing availability and synergies as to affect to the extent possible a seamless and overall consistent upgrade approach and staffing and leverage pricing, staffing, personnel and overall management synergies to the extent possible. The Contractor must propose fixed pricing for performance of these upgrades, based on the project resource or run resource rate cards and in keeping with the timing considerations outlined herein that is applicable to the overall term of the agreement.

6.8. Program Management & Master Release Calendar

The Contractor must develop and thereafter publish and follow a Master Release Plan and support the State in the development, maintenance and publication of a Master Release Calendar that includes a schedule (with dates) including:

Major/Minor and Scheduled Releases, Upgrades, Updates and Enhancements;

Implementation of Projects, Minor Enhancements or Discretionary Work;


Scheduled Maintenance Windows and Planned Outages;

Major and Minor Project Key Dates (i.e., Start, SDLC Gate Completion, Production Release, Completion) whether Contractor delivered or otherwise; and

Other pertinent dates that require end-user notification or coordination.

6.9. Environment Backup and Restoration Services

For each software environment within the scope of the Contractor’s Service, the Contractor must perform backup processes as follows:

Type Description Scheduled Timing

Baseline Pre-production image and data Once

Daily Incremental Files Data changes during the period Daily

Full Data Files All resident data files Weekly (weekend)

Full Back-up CopyAt request of State when a change is made to a State system a copy must be made before the change.

As needed

The Contractor must maintain backup retention periods as follows

Description Retention PeriodBaseline Until first annual + 1 month

Daily 6 Days

Weekly 4 Weeks

Monthly 12 Months

Annual 7 Years

Upon any return of Contractor created backup images or machine-readable media of State data, Contractor must provide any encryption keys, passwords, hardware decryption keys (e.g., dongles) as necessary to decrypt the data and restore the data.

6.10. Support of State Disaster Recovery

The Contractor must work with the State, and be responsible for the development, maintenance and testing of Disaster Recovery Plan for its software platform and to the extent practicable under the capabilities and conventions of software as a platform/cloud service.

The Disaster Recovery Plan must document the sequence of events to follow in the circumstance that an internal or external interruption impacts Services provided to the State software user community that may arise as a result of failure of one of more elements that comprise the State’s software environment including, but not limited to: infrastructure, hardware, software, interfaces, networks, software provided elements, and the like.

The Disaster Recovery Plan must be developed in consultation with the State and in adherence to the State IT policies provided herein.

The activities of the Disaster Recovery Plan are intended to reduced or minimize downtime of the platform, interruption of employee work schedules, and financial exposures for the State and Contractor.


The Disaster Recovery Plan documents a sequence of communication events to follow during an internal or external infrastructure failure or natural disaster (act of nature).

In order to minimize downtime, once notification is received from an external utility that disruption is imminent, the Disaster Recovery Plan must be activated.

Disaster Recovery Planning

To the extent agreed appropriate, participating in planning sessions, testing review sessions and other meeting activities during the term of the Contract.

Support implementation of disaster recovery plans as agreed based upon the following principles:

Utilize the software provided alternate disaster recovery capabilities which are adequate to process the State’s transactions and to provide systems access to end-user personnel during an outage period;

Transfer of operations to this alternate site to occur within 2 weeks of failure of primary location;

Transfer of the State data, configuration and user access to this site is to occur within 2 weeks of failure;

Restoration of primary operations site operations (once available) within 2 weeks; and

Notification of the State regarding primary site failure within 24 hours, and intent to migrate to alternate site within 72 hours of failure.

Service Restoration Following Disasters

Following any disaster, in consultation with the State, the Contractor must:

Reinstall any in-scope Applications affected by such disaster in accordance with the process for such re-installation set forth in the mutually agreed disaster recovery plan and business continuity plan.

Conduct a post-disaster meeting with the State for the purpose of developing plans to mitigate the adverse impact of future occurrences.

To the extent applicable to the in-scope Applications, maintaining compliance with the disaster recovery policies, standards, and procedures contained in the mutually agreed disaster recovery and business continuity plan.

6.11. System Incidents and Resolution

The Contractor must provide all technical support. Incident notification and resolution must be within the timeframes identified in the RFP, unless otherwise agreed upon by the State. The Contractor must provide the State with documentation of all incidents and resolutions implemented within five (5) business days or agreed upon time.

The Contractor must use the following definitions of resolution priority for application defects discovered during production:

Urgent: issue/problem has caused, or has potential to cause, the entire system to go down or to become unavailable; reported via e-mail and phone or pager immediately on a 24 hour per day schedule;

High: issue/problem directly affects the public, or a large number of stakeholders are prevented from using the system. High-priority problems include those that render a site unable to function, make key functions of the system inoperable, significantly slow processing of data, severely impact multiple stakeholders, lead to federal penalties, misdirect transactions, or severely corrupt data; reported via e-mail and phone or pager immediately on a 24 hour per day schedule;


Medium: Medium-priority problems include those errors that render minor and non- critical functions of the system inoperable or unstable, and other problems that prevent stakeholders or administrators from performing some of their tasks; reported via e-mail within two business hours;

Low: all service requests and other problems that prevent a stakeholder from performing some tasks, but in situations where a workaround is available; reported via e-mail within two business hours.

The Contractor must review and diagnose all urgent and high-priority problems within two hours of receipt of the problem report. The Contractor must review and diagnose all medium- and low-priority problems within four hours of receipt of the problem report.

The Contractor must provide an analysis utilizing the approved change management process of the diagnosis, solution, and the anticipated completion date/time. The State will provide approval for the Contractor to begin work on the defined solution for all urgent and high- priority problems.

The Contractor must correct system fatal errors and abnormal ends, and software defects causing such problems. On-line fatal errors and abnormal ends must be corrected within 24 hours from the time that the problem occurs unless the State Project Representative has approved additional time for corrective action. Processes that end abnormally and negatively impact on-line availability and transaction processing must be fixed immediately.

The Contractor must fix all application defects unless the Contractor is not authorized to fix the defect. All defect resolution will have to be approved by the State.

Whenever an operational problem results in inaccuracy, data corruption, delay or interruption of online availability, or delays in transaction processing, reports or other output, the Contractor must immediately notify the State Project Representative or his/her designee. This notification must include distributing information to the Tracking Call center, subject-matter experts, and to State staff via a daily production status report. The notification must include a description of the problem, the expected impact on operational functions, a corrective action plan, and expected time of problem resolution;

Upon correction of the problem, notify the State Project Representative or designee that the problem is resolved.

6.12. Data Management Functions.

The Contractor must establish policies and procedures, to process and manage all data files generated, transmitted and received by the Contractor. Scheduled times for file transmissions will be agreed upon between Contractor and DRC and DYS and will be subject to the terms of the Service Level Agreement as shown in Section 11.0 of this document.


Develop Interface Control Documents (ICD) for all interface data files.

Provide recoverability of all data files, if they are accidentally deleted, corrupted, or a file is incorrectly transmitted or received, by performing backups. The time frames for recoverability will be determined by the State.

Ensure security and data integrity of all data files during a transfer, by using a version of Connect Direct that is compatible with the State.

Ensure security and data integrity of all data files during a file transfer through approved state encryption methods.

Ensure security of all data files, by keeping the files safe from corruption, providing controlled access to data files and using encryption whenever appropriate.

Ensure timely processing, by providing updates to State interfaces with new and changed information within required timeframes to be determined by the State.


Ensure timely processing, by implementing automated quality assurance standards, to validate data and discover inconsistencies and other anomalies of the data files.

Retain all data files according to the agreed upon standards and schedules.

Define a communication plan to establish corrective actions and resolution of data transfer errors. The plan must include:

o Names and contact information for production control personnel;o Notification of a systems administrator when a predetermined threshold of errors has occurred during a batch

or real-time data transfer;o Documentation defining the file transfer procedure and indicating actions to be taken when errors are found;

ando The file transfer schedule.


7.0 Project Training Requirements

7.1. General Training Requirements

The Contractor will be responsible for developing training materials for system users. The Contractor must develop a training curriculum for each user role. The Contractor must develop and complete the training in a manner that ensures training occurs prior to implementation.

The Contractor will be responsible for the development and delivery of various methods of training such as but not limited to, Job Aids, Power Point presentations, Web based online tutorials, electronic documentation (e- documentation), and distributed brochures and pamphlets.

Training must be provided utilizing the following methods with no impact to production system performance. Each method may be utilized for different audiences based on need:

Web-based Tutorial. The Contactor must provide a web-based tutorial to assist users to learn the major functions of the Tracking System. The tutorial content must be specialized for each user audience specific needs.

E-Documentation. The Contractor must provide e-documentation on its website, accessible to all users. The content must include, at a minimum, a glossary of terms, step by step instructions for use of the mobile applications, password/PIN set-up requirements and resets, retroactive adjustments, and administrative functions.

7.2. Training Planning and Execution Requirements

Training Plans. The Contractor must create, maintain, and update, as required, an approved training plan for all levels of users. The training plans must include at least the following:

Provide an overview of each training methodology identified above for all levels of users;

Identify the number of role based web-tutorials required to meet the training requirements identified above;

Describe the content of the web-based tutorials, e-documentation, brochures and pamphlets;

Describe a process for user evaluation of training for feedback to DRC and DYS.

Develop, Provide and Maintain Training Documentation. The Contractor must develop and update, as required, all training e-documentation, manuals, materials, and training guides (including training objectives and outcomes). The Contractor must develop a document version control plan for the maintenance of training documentation. The Contractor also must incorporate on-line help, on-line policy and procedure manuals and hard copy user manuals for the delivery of training. All training materials must be reviewed and approved by the State before the start of the training. The Contractor must provide all electronic source documents and graphics used in the development and presentation of all aspects of training.

Contractor Deliverables. Deliverables to be produced by the Contractor include the following:

Deliverable 005. Training Plan/Schedule;Deliverable 006. Training Documentation; andDeliverable 007. Conduct Training for DRC and DYS Employees.

7.3. DRC and DYS Training Requirements


The Contractor must provide training for a large group of State (approximately 100) users of the Tracking System. The Contractor must provide both on-site classroom training, videoconference or web-based training on all aspects relating to functions to be performed by a state user of the system. The State will provide classrooms at a designated State training site. Before the initiation of training, the Contractor is responsible for site preparation. The State has network connections necessary for Internet-access. The State may, at its sole discretion, record any training sessions and use any training materials for future training. The Contractor will be responsible for identifying and providing at least two (2) half-day training sessions. Training methods may include on-site classroom training, online tutorials, web-based training and e-documentation.

The Contractor must provide training to personnel who have varying computer skills and who perform different functions within the organizations. Training must be role-based, structured to support all security levels utilized in the system. Business processes include, but are not limited to:

System Features and System Interoperability;

Process and Operations;

Reporting;

Security; and

System Tutorials/System Navigation.


8.0 Operational Support / Help Desk Requirements

8.1. Customer Support Services

The Contractor will also be responsible for the following:

Customer Support Services. Customer inquiries must be handled in a professional manner with timely, accurate and comprehensive resolutions. Customer support services must be provided within the Continental United States and the customer support services must respond to all related inquiries.

The Contractor must employ equipment to ensure that customer service functions are performed efficiently and effectively while adhering to the required SLA performance standards and reports.

The Contractor must provide customer support to assist state staff with system functions and inquiries.


Provide customer support via telephone and email.

Provide toll free telephone number(s) for direct customer service access.

Receive and respond to calls on all normal business days, between the hours of 8:00 A.M. to 5:00 P.M. Eastern Time Monday through Friday. Normal business days will exclude State Holidays.

Research, resolve and respond to inquiries and requests for assistance within 48 hours or in accordance with the SLA.

Notify the State immediately of a call center outage.


9.0 Service Levels

9.1. Service Level Framework

This section sets forth the performance specifications for the Service Level Agreements (SLA) to be established between the Contractor and the State that are applicable to the Solution and Managed Services elements. It contains the tables and descriptions that provide the State’s framework, requirements relating to service level commitments, and the implications of meeting versus failing to meet the requirements and objectives, as applicable.

The mechanism set out herein will be implemented to manage the Contractor’s performance against each Service Level, to monitor the overall performance of the Contractor in delivery of the Service.

The Contractor will be required to comply with the following performance management and reporting mechanisms for all Services within the scope of this RFP and must provide these reports to the State no less frequently than monthly basis:

Service Level Specific Performance – Agreed upon specific Service Levels to measure the performance of specific Services or Service Elements. Most individual Service Levels are linked to financial credits due to the State (“Performance Credits”) to incent Contractor performance.

9.2. Service Level Specific Performance Credits

Each Service Level (SL) will be measured using a “Green-Yellow-Red” (GYR) traffic light mechanism (the “Individual SL GYR State”), with “Green” representing the highest level of performance and “Red” representing the lowest level of performance.

A financial credit will be due to the State (a “Performance Credit”) in the event a specific Individual SL GYR State falls in the “Yellow “or “Red” State. The amount of the Performance Credit for each SLA will be based on the Individual SL GYR State. Further, the amounts of the Performance Credits will, in certain cases, increase where they are imposed in consecutive months. Each Service Level (SL) in “Yellow” GYR State will result in a 1% credit. Each Service Level (SL) in “Red” GYR State will result in a 2% credit.

The State requires the Contractor to promptly address and resolve Service impacting issues and to not have the same problem, or a similar problem reoccur in a subsequent month, therefore credit amounts shall escalate based on the credits described above.

The Performance Credits available to the State under the terms of this document will not constitute the State’s exclusive remedy to resolving issues related to Contractor’s performance.

On a quarterly basis, there will be a “true-up” at which time the total amount of the Performance Credits will be calculated (the “Net Amount”), and such Net Amount will be set off against any fees owed by the State to the Contractor. Moreover, in the event of consecutive failures to meet the Service Levels, the Contractor will be required to credit the State the maximum Performance Credit under the terms of the Contract.

The Contractor will not be liable for any failed Service Level caused by circumstances beyond its control, and that could not be avoided or mitigated through the exercise of prudence and ordinary care, provided that the Contractor immediately notifies the State in writing and takes all steps necessary to minimize the effect of such circumstances and resumes its performance of the Services in accordance with the SLAs as soon as possible.

9.3. Monthly Service Level Report


On a State monthly basis, the Contractor will provide a written report (the “Monthly Service Level Report”) to the State which includes the following information: (i) the Contractor’s quantitative performance for each Service Level; (ii) each Individual SL GYR State and the Overall SL Score; (iii) the amount of any monthly Performance Credit for each Service Level (iv) the year-to-date total Performance Credit balance for each Service Level and all the Service Levels; (v) a “Root-Cause Analysis” and corrective action plan with respect to any Service Levels where the Individual SL GYR State was not “Green” during the preceding month; and (vi) trend or statistical analysis with respect to each Service Level as requested by the State . The Monthly Service Level Report will be due no later than the tenth (10th) business day of the following month.

Failure to report any SLA, SLA performance in a given month, or for any non-Green (i.e., performing to Standard) SLA a detailed root cause analysis that substantiates cause will result in the State considering the performance of the Contractor for that period as performing in a Red State.

Prior to the Commencement Date, the Contractor will provide to the State proposed report formats, for State approval. In addition, from time to time, the State may identify a number of additional reports to be generated by the Contractor and delivered to the State on an ad hoc or periodic basis. Generally, the Contractor tools provide a number of standard reports and the capability to provide real-time ad hoc queries by the State. A number of additional or other periodic reports (i.e., those other than the standard ones included in the tools) mean a number that can be provided incidentally without major commitment of resources or disruption of the efficient performance of the services. Such additional reports will be electronically generated by the Contractor, provided as part of the Services and at no additional charge to the State. To the extent possible, all reports will be provided to the State on-line in web-enabled format and the information contained therein will be capable of being displayed graphically.

At a minimum, the reports to be provided by the Contractor must include: Monthly Service Level report(s) documenting the Contractor's performance with respect to Service Level

Agreements; and A number of other periodic reports requested by the State which the State reasonably determines are

necessary and related to its use and understanding of the Services.

9.4. Escalation for Repetitive Service Level Failures

The State may escalate repetitive service level failure to the Contractor’s executive sponsor, the Contractor’s Managing Director / Lead Public Sector Partner for Public Sector, or the equivalent position.

9.5. Service Level Requirements (SLAs)

The following service levels are required for the duration of the Contract period. Contractor must consistently meet or exceed the following SLAs. The percentage calculation of performance measures must be rounded to two decimal points using the standard rounding method. All times referenced are in Eastern Time.


9.5.1 Project Implementation Service Levels

Project Implementation and Managed Services Service Level

Service Level Standard

Performing Under-Performing

Not Achieving

Deliverable Acceptance: The deliverables and work plan established, submitted, and tracked to achieve implementation of the solution. >85% >80% and

<=85% <=80%

Milestone Delivery Due Dates: The Milestones as scheduled in Contractor’s Work Plan, Deliverable 1 <5 days >5 days >14 days

UAT Severity 1 Outages Resolution – Mean Time to Repair: Resolution of Severity 1 issues during UAT <= 3 days > 3 days and <= 5 days > 5 days

UAT Severity 2 Outages Resolution – Mean Time to Repair: Resolution of Severity 2 issues during UAT <= 5 days > 5 daysand <= 7 days > 7 days

UAT Severity 3 Outages Resolution – Mean Time to Repair: Resolution of Severity 3 issues during UAT <= 8 days > 8 days <=10 days > 10 days

Project Implementation Service Level Agreement: Deliverable Acceptance

Definition: The State’s ability to accept Contractor deliverables based on submitted quality and in keeping with initially defined standards and content for Contractor deliverables.

The Contractor must provide deliverables to the State in keeping with agreed levels of completeness, content quality, content topic coverage and otherwise achieve the agreed purpose of the deliverable between the State and the Contractor. For the avoidance of doubt, the deliverables contained in this RFP as they pertain to the system.

Project and general Ongoing Project Services delivery will represent the minimum set of expected deliverables.

Notwithstanding the State review and approval cycles, this SL will commence upon the delivery of a final deliverable for acceptance to the State, and any work/re-work to the final deliverable as a result of any State questions, required clarifications/amplifications, and conclude upon due completion of the required amendments.

This SL will commence upon Project initiation and will prevail until Project completion.

Measurement Period Data Source Collection

Frequency SL Formula SL Measure GYR State

Monthly, During Project

Weekly Project Report

Weekly% Deliverable Acceptance (Expressed as %) = # Deliverables

Accepted During Period ÷ # Deliverables Presented during Period

>85%>80% and

<=85%<=80%


Project Implementation Service Level Agreement: Milestone Delivery Due Dates

Definition: Milestones means the milestone for the provision of deliverables specified in the Work Plan Contractor shall submit in Deliverable 1. The timely delivery of services and achievement of milestones is essential to the Project objective. The Contractor must provide deliverables to the State in keeping with scheduled milestones that shall be outlined in Contractor’s Work Plan under Deliverable 1. For the avoidance of doubt, the deliverables contained in this RFP as they pertain to the system Project and general Ongoing Project Services delivery will represent the minimum set of expected deliverables.

Notwithstanding the State review and approval cycles, this SL will commence upon the delivery of its Work Plan in Deliverable 1 or current Work Plan as mutually agreed upon.

Milestone Delivery Due Dates: The Milestones as outlined in Contractor’s Work Plan, Deliverable 1, are deliverable based and in the event the Milestones are not being met the purpose of the Contract and usefulness to the users. Contractor shall use all reasonable endeavors to provide the relevant Deliverable to the State within 5 business days of the relevant Milestone; Contractor shall at no additional cost to the State, allocate additional or re-allocate existing resources and personnel in order to provide the relevant Deliverable within such five day period; State may without liability withhold payment in respect of any invoice issued in respect of Services relating to a Deliverable if such deliverable is not provided within the period referred to in the Work Plan; and the State may terminate this Contract by written notice to Contractor if Contractor does not provide the Deliverable for a Milestone within fourteen (14) days of such Milestone. In the event the Contractor does not meet a Milestone due to an act or omission of the State, the Contractor shall use reasonable endeavors to provide the relevant Deliverable to the State within five days of the relevant Milestone and in any event will collaborate with the State to deliver the Deliverable within such other reasonable time as the State may request. This clause will not affect the Contractor’s obligations to meet Milestones other than the particular Milestone at issue.



Monthly, During Project

Weekly Project Report

Weekly100% Y ( # Milestones Missed During Period) + 100% X (#

Milestones Missed During Period) <5 days >5 days >14 days

Project Implementation Service Level Agreement: UAT Severity 1 Outages Resolution – Mean Time to Repair

Prompt resolution of system issues identified as part of Contractor System/Unit Testing and/or User Acceptance Testing (UAT).

This Service Level begins upon first migration of Solution functionality into the User Acceptance environment.

The State shall, in consultation with the Contractor, determine the Severity of each issue identified during UAT. Formal declaration of the Severity of each UAT issue to the Contractor will be made by the State Project Manager.

Prioritization: An Issue shall be categorized as "Severity 1" if the issue will prevent the State from authorizing Production migration of the associated functionality or module. Typical characteristics of Severity 1 issues are situations that would prohibit the execution of productive work for a group(s) or individual performing a critical business function. Examples include, but are not limited to:

- DRC users are unable to securely interact with the system

Measurement: Issue "Time to Repair" will be measured from the time the State reports the issue as Severity 1 to the point in time the Contractor provides either a resolution or workaround to the State for verification and acceptance. In the case where the resolution or workaround is determined by the State to be unacceptable the tracking of the "Time to Repair" will recommence at the time the State reports the unacceptability. In the case of a workaround, the State may accept the workaround as a short-term solution, allowing the functionality to move to Production, but still need the issue resolved at a lower Severity. In these circumstances the State will consider the associated Severity 1 issue resolved and the Contractor will establish a new issue at the State determined Severity for management and tracking.

The "Mean Time to Repair" for the reporting month will be measured by assessing the elapsed time in business days (expressed as a decimal number, to two positions after the decimal point, that reflects the hours and minutes) of all resolved Severity 1 UAT issues to determine the statistical mean.



Reporting MonthMonthly Service

ReportPer Issue

Mean Time to Repair (Severity 1 Issues) = (Total elapsed business days for all resolved Severity 1 Issues) ÷ (Total

number of all resolved Severity 1 Issues)

<=3 days

>3 days and <=5

days>5 days






Prioritization: An issue shall be categorized as "Severity 2" if the issue will prevent the State from authorizing Production access to the associated functionality beyond customer support team members. Typical characteristics of Severity 2 issues are situations that require restricted functionality access in a tightly controlled user environment to limit the risk of prohibited execution of productive work for a group(s) or individual performing a critical business function. Examples include, but are not limited to:

Complicated workarounds are required to use the functionality, increasing the likelihood of user error and/or confusion. DRC-specific configuration cannot be sufficiently completed to permit deployment.

Measurement: Issue "Time to Repair" will be measured from the time the State reports the issue as Severity 2 to the point in time the Contractor provides either a resolution or workaround to the State for verification and acceptance. In the case where the resolution or workaround is determined by the State to be unacceptable the tracking of the "Time to Repair" will recommence at the time the State reports the unacceptability. In the case of a workaround, the State may accept the workaround as a short-term solution, allowing the functionality to move to Production, but still need the issue resolved at a lower Severity. In these circumstances the State will consider the associated Severity 2 issue resolved and the Contractor will establish a new issue at the State determined Severity for management and tracking.





ReportPer Issue



<=5 days

>5 days and <=7

days>7 days





Prioritization: An Issue shall be categorized as "Severity 3" if the issue will result in the State limiting DRC web customer use of or access to components/features of the associated functionality. Typical characteristics of Severity 3 issues are situations that would have adverse effect on the rollout, adoption and training of the functionality. Examples include, but are not limited to:

DRC web customer use will result in significant number of support calls.

Measurement: Issue "Time to Repair" will be measured from the time the State reports the issue as Severity 3 to the point in time the Contractor provides either a resolution or workaround to the State for verification and acceptance. In the case where the resolution or workaround is determined by the State to be unacceptable the tracking of the "Time to Repair" will recommence at the time the State reports the unacceptability.

In the case of a workaround, the State may accept the workaround as a short-term solution, allowing the functionality to move to Production, but still need the issue resolved at a lower Severity. In these circumstances the State will consider the associated Severity 3 issue resolved and the Contractor will establish a new issue at the State determined Severity for management and tracking.





ReportPer Issue



<=8 days

>8 days and <=10 days

>10 days


9.5.2. On-Going Operations/Maintenance Service Levels

Solution and Managed ServicesService Level SLA or SLO Coverage

1 Incident Resolution – Mean Time to Repair (Severity 1 Outages) SLA 24/7/365

2 Incident Resolution – Mean Time to Repair (Severity 2 Outages) SLA 24/7/365

3 Incident Resolution – Mean Time to Repair (Severity 3 Outages) SLA Business Hours

4 Service Availability – Application Availability SLA 24/7/365

5 Service Timeliness – System Changes SLA Scheduled Maintenance

Managed Services Service Levels: Issue Resolution – Mean Time to Repair (Severity 1 Issues)

Prompt resolution of system Solution Severity 1 issues that impact State processing and processes.

This Service Level begins upon completion of agreed production acceptance criteria and a measurement period as documented in the transition to production plan.

The State shall, in consultation with the Contractor, determine the Severity of each issue. Formal declaration of the Severity of each issue to the Contractor will be made by the State Project Manager.

Prioritization: An Issue shall be categorized as a “Severity 1 Issue” if the issue is characterized by the following attributes. The Issue:

renders a business-critical System, Service, Software, Equipment or network component unavailable, substantially unavailable or seriously impacts normal business operations, in each case prohibiting the execution of productive work, or

affects either a group or groups of people, or a single individual performing a critical business function, or causes violation of policy, regulation or law thereby placing the action at risk of audit and/or legal action.

Measurement: Issue "Time to Repair" will be measured from the time the State reports the issue as Severity 1 to the point in time the Contractor provides either a resolution or workaround to the State for verification and acceptance. In the case where the resolution or workaround is determined by the State to be unacceptable the tracking of the "Time to Repair" will recommence at the time the State reports the unacceptability. In the case of a workaround, the State may accept the workaround as a short-term solution, allowing the resolution to move to Production, but still need the issue resolved at a lower Severity. In these circumstances the State will consider the associated Severity 1 issue resolved and the Contractor will establish a new issue at the State determined Severity for management and tracking.

The "Mean Time to Repair" for the reporting month will be measured by assessing the elapsed time (expressed as a decimal number, to two positions after the decimal point, that reflects the hours and minutes) of all resolved Severity 1 UAT issues to determine the statistical mean.




ReportPer Issue

Mean Time to Repair (Severity 1 Issues) = Expressed in Hours (Total elapsed time for all resolved Severity 1 Issues) ÷

(Total number of all resolved Severity 1 Issues)

<=24 hours

>24 and <=48 hours

>48 hours



Prompt resolution of system Severity 2 issues that impact State processing and processes.


The State will, in consultation with the Contractor, determine the Severity of each issue. Formal declaration of the Severity of each issue to the Contractor will be made by the State Project Manager.


does not render a business-critical System, Service, Software, Equipment or network component unavailable, substantially unavailable but a function or functions are not available, substantially unavailable or functioning as it/they should, and

affects either a group or groups of people, or a single individual performing a critical business function.

Measurement: In the case of a workaround, the State may accept the workaround as a short-term solution, allowing the resolution to move to Production, but still need the issue resolved at a lower Severity. In these circumstances the State will consider the associated Severity 1 issue resolved and the Contractor will establish a new issue at the State determined Severity for management and tracking.

The "Mean Time to Repair" for the reporting month will be measured by assessing the elapsed time (expressed as a decimal number, to two positions after the decimal point, that reflects the hours and minutes) of all resolved Severity 2 UAT issues to determine the statistical mean.




ReportPer Issue

Mean Time to Repair (Severity 2 Issues) = Expressed in Hours (Total elapsed time for all resolved Severity 2 Issues) ÷

(Total number of all resolved Severity 2 Issues)

<=48 hours

>48 and <=72 hours

>72 hours


Prompt resolution of system Severity 3 issues that impact State processing and processes.


The State will, in consultation with the Contractor, determine the Severity of each issue. Formal declaration of the Severity of each issue to the Contractor will be made by the State Project Manager.


causes a group of people or single individual to be unable to access or use a System, Service, Software, Equipment or network component or a key feature thereof, and

a reasonable workaround is not available, but does not prohibit the execution of productive work.

Measurement: Issue "Time to Repair" will be measured from the time the State reports the issue as Severity 3 to the point in time the Contractor provides either a resolution or workaround to the State for verification and acceptance. In the case where the resolution or workaround is determined by the State to be unacceptable the tracking of the "Time to Repair" will recommence at the time the State reports the unacceptability.

In the case of a workaround, the State may accept the workaround as a short-term solution, allowing the resolution to move to Production, but still need the issue resolved at a lower Severity. In these circumstances the State will consider the associated Severity 1 issue resolved and the Contractor will establish a new issue at the State determined Severity for management and tracking.





ReportPer Issue

Mean Time to Repair (Severity 3 Issues) = Expressed in Business Days (Total elapsed business days for all resolved Severity 3 Issues) ÷ (Total number of all resolved Severity 3

Issues)

<=5 days

>5 days and <=10 days

>10 days


Managed Services Service Levels: Service Availability – Solution Component/Application Availability

All system components are Available to All State Users for All Business Functions to Support Critical Processes.


Definition: Solution Component/Application Availability means access to each Solution component in the production system is enabled such that users can log-in and business transactions can be executed. The Contractor must implement operational processes, instrumentation, monitoring and controls that validate availability of system components to the State end-users and web users.

This SLA will be calculated for those Solution Components/Applications and Service Elements that are directly in the Contractor’s scope and will be measured from the end-user community desktop to the ability to process transactions in the system. If, in determination of the root cause of an “unavailable” condition is due to the State LAN, WAN and Data Center outages, or the outage of State provided Infrastructure, the Contractor shall be excused from those outages that arise from such a condition, unless the outage is a direct result of a Contractor created situation.




ReportContinuous, 24

hours a day

Application Availability (Expressed as a percentage) = (Total

Component/Application Scheduled Uptime – Total Application Unscheduled Outages) ÷ (Total Application Scheduled

Uptime)

Production EnvironmentGreater than or equal to

99.0%

Production Environment

Between 98% and

99%

Production Environment

Less than 98%

Managed Services Service Levels: Service Request Responsiveness

Prompt response to Service Requests for adds, modifications and deletions within specified timeframe according to urgency or critical nature of the request.


Formal submission of Service Requests will be made by the State Project Manager or designee.

Tier 1: Adds, modifications or deletions that are critical to the operation and decision-making elements of the solution. Tier 2: Adds, modifications or deletions that are semi-critical to the operation and decision-making elements of the solution.Tier 3: Adds, modifications or deletions that are not critical to the operation of the solution to the operation and decision-making elements of the solution.

Measurement: Service Request Elapsed Time will be will be measured from the time the State submits a Service Request to the point in time the Contractor demonstrates completion of the request. This elapsed time will be expressed in business days as a decimal number, to two positions after the decimal point, that reflects the hours and minutes expended to meet the request.



Daily Accounting Month

Monthly Service Report

Per Issue

Mean Time to Complete Response (Expressed in Business Days) = (Total elapsed time for all completed Tier X

requests) ÷ (Total Number of completed Tier X Requests)

Tier 1: <=2 days

Tier 2: <=4 days

Tier 3: <=6 days

Tier 1: >2 days and <=3 days



Tier 1: >3 days

Tier 2: >6 days

Tier 3: >8 days


10.0 Contractor Staffing and Personnel Requirements

10.1. Contractor Staffing Plan, Time Commitment and Work Locations

Offerors proposing responses to this Supplement must provide a Staffing plan to align with and support all requirements and Service levels contained within this Supplement. In addition, for each Contractor resource performing work under this Supplement, the Offeror must indicate where the work will be performed (e.g., “State Location” or “Contractor Location”) and the degree of involvement (e.g., “Full-Time”, “Part-Time” or “Situational / Limited”).

The offeror’s response must contain the following information:

An organizational chart including any sub-Contractors and key management and administrative personnel assigned to this project.

A contingency plan that shows the ability to add more staff if needed to ensure meeting the Project’s due date(s).

The number of people onsite at State location(s) at any given time to allow the State to plan for the appropriate workspace.

A statement and a chart that clearly indicates the time commitment of the proposed Project Manager and the offeror’s Key Project Personnel, inclusive of the Project Manager and the offeror’s proposed team members for this Work during each phase of the Project.

The offeror also must include a statement indicating to what extent, if any, project team members may work on other projects or assignments that are not State-related during the term of the Contract. The State may reject any Proposal that commits the proposed Project Manager or any proposed Key Project Personnel to other projects during the term of the Project, if the State believes that any such commitment may be detrimental to the offeror’s performance.

In addition, the Offeror’s proposal must identify all Key Project Personnel who will provide services as part of the resulting Contract. The State expects that the proposed named Key Project Personnel will be available as proposed to work on the Project and during design, development, system test and user testing, key staff may be physically located at the State identified location.

10.2. Contractor Personnel Requirements

The Contractor must comply in all respects with Ohio statutes, regulations, and administrative requirements, and Executive Order 2011-12K (prohibition of offshore services) and other conventions as described and required in Supplement 2.

The Contractor will provide resources for the work described herein with natural persons who are lawful permanent residents as defined in 8 U.S.C. 1101 (a)(20) or who are protected individuals as defined by 8 U.S.C. 1324b(a)(3). It also means any corporation, business association, partnership, society, trust, or any other entity, organization or group that is incorporated to do business in the U.S. It also includes any governmental (federal, state, local) entity.

The State specifically excludes sending, taking or making available remotely (directly or indirectly), any State information including data, software, code, intellectual property, designs and specifications, system logs, system data, personal or identifying information and related materials out of the United States in any manner, except by mere travel outside of the U.S. by a person whose personal knowledge includes technical data; or transferring registration, control, or ownership to a foreign person, whether in the U.S. or abroad, or disclosing (including oral or visual disclosure) or transferring in the United States any State article to an embassy, any agency or subdivision of a foreign government (e.g., diplomatic missions); or disclosing (including oral or visual disclosure) or transferring data to a foreign person, whether in the U.S. or abroad.


It is the responsibility of all individuals working at the State to understand and comply with the policy set forth in this document as it pertains to end-use export controls regarding State restricted information.

It is the responsibility of all Contractor individuals working at the State to understand and comply with the policy set forth in this document as it pertains to end-use export controls regarding State restricted information.

10.3. Criminal Background Check of Personnel

Contractor agrees that (1) it will conduct 3rd party criminal background checks on Contractor personnel who will perform Sensitive Services (as defined below), and (2) no Ineligible Personnel will perform Sensitive Services under this Agreement. “Ineligible Personnel” means any person who (a) has been convicted at any time of any criminal offense involving dishonesty, a breach of trust, or money laundering, or who has entered into a pre-trial diversion or similar program in connection with a prosecution for such offense, (b) is named by the Office of Foreign Asset Control (OFAC) as a Specially Designated National, or (b) has been convicted of a felony.

“Sensitive Services” means those services that (i) require access to customer / consumer Information, (ii) relate to the State’s computer networks, information systems, databases or secure facilities under circumstances that would permit modifications to such systems, or (iii) involve unsupervised access to secure facilities.

Upon request, Contractor will provide written evidence that all of Contractor’s personnel providing Sensitive Services have undergone a criminal background check and are eligible to provide Sensitive Services. In the event that Contractor does not comply with the terms of this section, the State may, in its sole and absolute discretion, terminate this Contract immediately without further liability.


11.0 Contract Governance Processes and Requirements

11.1. Informal Dispute Resolution

Prior to the initiation of formal dispute resolution procedures as to any dispute (other than those arising out of the breach of a Party’s obligations), the Parties will first attempt to resolve each dispute informally, as follows:

If the Parties are unable to resolve a dispute in an amount of time that either Party deems required under the circumstances, such Party may refer the dispute to the Ohio Department of Administrative Services, General Services Division, Office of Procurement Services, Enterprise IT Contracting area procurement representative (DAS) or designee when deemed necessary by delivering written notice of such referral to the other Party.

Within five (5) Business Days of the delivery of a notice referring a dispute to DAS, each Party will prepare and submit to DAS a detailed summary of the dispute, the underlying facts and their respective positions, together with any supporting documentation.

DAS will address the dispute or, at the request of either Party, will conduct a special meeting within ten (10) Business Days to address such dispute. DAS will address the dispute in an effort to resolve such dispute without the necessity of any formal proceeding.

The specific format for the discussions will be left to the discretion of the chairperson of such group. If DAS is unable to resolve a dispute within thirty (30) days of the first meeting addressing such dispute (or such longer period of time as the Parties may agree upon), either Party may refer the dispute to the DAS General Services Deputy Director or designee by delivering written notice of such referral to the other Party.

Within five (5) Business Days of the delivery of a notice referring a dispute to the DAS General Services Deputy Director or designee, the State Service owner and Contractor Account Executive will each prepare and submit a detailed summary of the dispute, the underlying facts and their respective positions, together with any supporting documentation.

If the DAS General Services Deputy Director or designee are unable to resolve a dispute within thirty (30) days of the first meeting addressing such dispute (or such longer period of time as the Parties may agree upon), either Party may refer the dispute to internal escalation by delivering written notice of such referral to the other Party.

11.2. Internal Escalation Obligations and Requirements

If for whatever reason the Contractor and the State cannot resolve a dispute via the above escalation processes and procedures, Contractor and the State agree to choose a mutually agreeable third-party neutral who shall mediate the dispute between the Parties. The mediator chosen shall be an experienced mediator and shall not be: (i) a current or former employee of either Party or associated with any aspect of the Government of the State of Ohio; (ii) associated with any equipment or software supplier; or (iii) associated with Contractor or the State. As to each prohibition, this means either directly or indirectly or by virtue of any material financial interests, directly or indirectly, or by virtue of any family members, close friendships or in any way that would have the reasonable appearance of either conflict of interest or potential for bias. If the Parties are unable to agree on a qualified person, the mediator shall be appointed by the American Arbitration Association.

The mediation must be non-binding and must be confidential to the extent permitted by law. Each party must be represented in the mediation by a person with authority to settle the dispute. The parties must participate in good faith in accordance with the recommendations of the mediator and must follow procedures for mediation as suggested by the mediator. All mediation expenses, except expenses of the individual parties, must be shared equally by the parties. The parties must refrain from court proceedings during the mediation process insofar as they can do so without prejudicing their legal rights.


If the disputed matter has not been resolved within thirty (30) days thereafter, or such longer period as agreed to in writing by the Parties, each Party will have the right to commence any legal proceeding as permitted by law.

11.3. Escalation for Repetitive Service Level Failures

The State may escalate repetitive service level failures to the Contractor’s executive sponsor, the Contractor’s Managing Director, or the equivalent position.

11.4. No Termination or Suspension of Services or Payment.

While any dispute is pending, the Contractor must continue its obligations under the Contract and not take any action that intentionally obstructs, delays, or reduces in any way the performance of such obligations. While any dispute is pending, the State will not interrupt or delay the payment for Services in whole or in part, other than Services that are the subject of the dispute.

11.5. Back-Up Documentation

As part of the Services, the Contractor will provide the State with such documentation and other information available to the Contractor as may be reasonably requested by the State from time to time in order to verify the accuracy of the reports provided by the Contractor. In addition, the Contractor will provide the State with all documentation and other information reasonably requested by the State from time to time to verify that the Contractor's performance of the Services is in compliance with the Service Levels and this Scope of Work.

11.6. Correction of Errors

As part of the Services and at no additional charge to the State, the Contractor will promptly correct any errors or inaccuracies in or with respect to the reports, the system or other Deliverables caused by the Contractor or its agents, subcontractors or 3rd Party product or service providers.


12.0 Contract Conclusion Requirements: Transition to Successor Contractor or State at Contract Termination or Non-Renewal

12.1. Overview

Contractor must provide to the State the Termination Assistance Services set forth herein in connection with the termination or expiration of the Contract.

To the extent the Termination Assistance Services include any tasks which Contractor is not otherwise obligated to perform under the Contract, the charges must be based on then-current rates for Services as proposed by Contractor in this RFP or prevailing rates at the time of termination, whichever is lower.

“Termination Assistance Services” will mean (a) to the extent requested by the State, the continued performance by Contractor of its obligations under the Contract (including providing the Services which are subject to termination or expiration), and (b) the provisioning of such assistance, cooperation and information as is reasonably necessary to help enable a smooth transition of the applicable Services to the State or its designated 3 rd Party provider (“Successor”). As part of Termination Assistance Services, Contractor must provide such information as the State may reasonably request relating to the number and function of each of the Contractor personnel performing the Services, and Contractor must make such information available to the Successor designated by the State.

Contractor must cooperate with the State in its attempts at transferring the services responsibilities to another provider so as to not adversely affect the provision of ongoing services.

12.2. Standards

The terminated or expired Services shall be transferred to the State or its successor(s) in an efficient and orderly manner.

The impact on the State’s business (including its personnel and customers) and the internal and 3 rd Party IT-related costs incurred by the State in transferring the Terminated Services shall be acceptable to the State under the circumstances.

The Terminated Services shall continue to be performed by Contractor without disruption or deterioration until the transfer has occurred: (i) consistent with the terms and conditions of the Contract, or (ii) except as approved by the State.

There will be no disruption or deterioration of the remaining Services during the transfer to the State or a State Contracted successor (except as approved by the State or included in the Termination Assistance Plan) to the extent the same is within the control of Contractor and as agreed with the State.

In an effort to facilitate transition of responsibilities, the Key Management Position obligations this Supplement must continue to apply during the agreed Termination Assistance Period.

12.3. Termination Assistance Plan

The contents of Termination Assistance Plan must include, unless otherwise agreed, the services, functions, and activities as defined below:

Documentation of existing and planned Projects and support activities.

Description of actions to be taken by Contractor in performing Termination Assistance.


Description of how the transfer of (i) relevant information regarding the Services, (ii) resources (if any), (iii) operations and (iv) Contracts (if any) will be achieved.

Inventory of documentation and work products required to facilitate the transition of responsibilities.

Assist the State in the identification of significant potential risk factors relating to the transition and in designing plans and contingencies to help mitigate the risk.

Set out the timeline for the transfer of each component of the terminated Services (including key milestones to track the progress of the transfer).

Define a schedule and plan for Contractor’s return to the State of (i) the State Service locations then occupied by Contractor (if any), and (ii) the State Confidential Information, the State Data, documents, records, files, tapes and disks in Contractor’s possession.

12.4. Ownership of State Data and Provision for Providing the State Data at Contract Conclusion

All State data contained in the system is the property of and exclusively owned by the State. At the conclusion of the Contract, the Contractor shall provide all State data in a machine readable, non-proprietary form (e.g., Comma-Separated Values, XML or database backup format). Following the State’s review and written acceptance of such data, and confirmation that it is in a machine-readable form, the Contractor must delete and destroy all State data maintained in the system.


13.0 Offeror Assumptions, Support Requirements, Pre-Existing and Commercial Materials

13.1. Assumptions

The offeror must list all the assumptions the offeror made in preparing the Proposal. If any assumption is unacceptable to the State, the State may at its sole discretion request that the offeror remove the assumption or choose to reject the Proposal. No assumptions may be included regarding the outcomes of negotiation, terms and conditions, or requirements. Assumptions should be provided as part of the offeror response as a stand-alone response section that is inclusive of all assumptions with reference(s) to the section(s) of the RFP that the assumption is applicable to. Offerors should not include assumptions elsewhere in their response.

13.2. Support Requirements

The offeror must describe the support it wants from the State other than what the State has offered in this RFP. Specifically, the offeror must address the following:

Nature and extent of State support required in terms of staff roles, percentage of time available, and so on;

Assistance from State staff and the experience and qualification levels required; and

Other support requirements.

The State may not be able or willing to provide the additional support the offeror lists in this part of its Proposal. The offeror therefore must indicate whether its request for additional support is a requirement for its performance. If any part of the list is a requirement, the State may reject the offeror's Proposal, if the State is unable or unwilling to meet the requirements.

13.3. Pre-Existing Materials

The offeror must list any Pre-Existing Materials it owns that will be included in a Deliverable if the offeror wants a proprietary notice on copies that the State distributes. For example, the offeror may have standard user interfaces or standard shells that it incorporates in what is otherwise custom software. (See the Ownership of Deliverables section of the General Terms and Conditions.) The State may reject any Proposal that includes existing materials for a custom solution, if the State believes that such is not appropriate or desirable for the Project.

13.4. Commercial Materials

The offeror must list any commercial and proprietary materials that the offeror will deliver that are easily copied, such as Commercial Software, and in which the State will have less than full ownership (“Commercial Materials”). Generally, these will be from third parties and readily available in the open market. The offeror need not list patented parts of equipment, since they are not readily copied. If the offeror expects the State to sign a license for the Commercial Material, the offeror must include the license agreement as an attachment. If the State finds any provisions of the license agreement objectionable and cannot or does not negotiate an acceptable solution with the licensor, regardless of the reason and in the State's sole discretion, then the offeror's Proposal may be rejected. If the State is not going to sign a license, but there will be limits on the State's use of the Commercial Materials different from the standard license in the General Terms and Conditions, then the offeror must detail the unique scope of license here. Unless otherwise provided in this RFP, proposing to use Commercial Materials in a custom solution may be a basis for rejection of the offeror’s Proposal, if the State, in its sole discretion, believes that such is not appropriate or desirable for the Project. Any deviation from the standard license, warranty, and other terms in Attachment Four also may result in a rejection of the offeror’s Proposal.


14.0 Reference and Informational DataThe State provides the following tables for Offeror consideration in developing proposals to this RFP. Offerors are to review and consider these tables for reference and information purposes only.

Table 1Electricity Utility and Vendors

Utility Vendor # of Accounts

Electricity

American Electric Power (AEP) 38City of Columbus 1Dayton Power and Light 6Duke Ohio 1Village of Grafton 1Ohio Edison 26South Central Power 11The Illuminating Company 2Toledo Edison 1

Natural Gas

Columbia Gas 33Dominion East Ohio 7Knox Energy Cooperative 1Vectren Energy Delivery 2KIDN Marketing LTD 1

Water/Sewer

*Water / Sewer number of

accounts indicate number of

institutions served by utility, not

actual number of accounts.

Allen County 1Aqua Ohio Inc 2Belmont County 1Butler County 2Village of Caldwell 1City of Cleveland 1City of Columbus 2City of Dayton 1Village of Grafton 2City of Lima 1City of London 2City of Mansfield 2City of Marion 1City of Marysville 1Northeast Ohio Regional Sewer District 2City of Portsmouth 1Rural Lorain County Water Authority 2Scioto County Regional Water 1Scioto County 1City of Toledo 1City of Warren 1City of Youngstown 1Institutions served by on-site water treatment plant 7Institutions served by on-site wastewater treatment plant 4

Waste Hauling and Disposal Elytus (Third-Party Administrator, State Contract) 77


Table 2 Institution list and building counts

Agency Region Institution Address Building Count

DRC Northwest Region Allen/Oakwood Correctional Institution (AOCI) 2338 North West StreetLima, OH 45802 25

DRC Southeast Region Belmont Correctional Institution (BeCI)68518 Bannock RoadSR 331St. Clairsville, OH 43905

25

DRC Southwest Region Chillicothe Correctional Institution (CCI) 15802 SR 104 NorthChillicothe, OH 45601 49

DRC Southeast Region Correctional Reception Center (CRC) 11271 SR 762Orient, OH 43146 18

DRC Southwest Region Dayton Correctional Institution (DCI) 4104 Germantown StreetDayton, OH 45417 11

DRC Franklin Medical Center (FMC) 1990 Harmon AvenueColumbus, OH 43223 15

DRC Northeast Region Grafton Correctional Institution (GCI) 2500 South Avon Beldon RdGrafton, OH 44044 18

DRC Southwest Region Lebanon Correctional Institution (LeCI) 3791 State Route 63Lebanon, Ohio 45036 10

DRC Southwest Region London Correctional Institution (LoCI) 1580 State Route 56, SWLondon, Ohio 43140 19

DRC Northeast Region Lorain Correctional Institution (LorCI) 2075 South Avon-Belden RdGrafton, Ohio 44044 21

DRC Southwest Region Madison Correctional Institution (MaCI) 1851 State Route 56London, Ohio 43140 17

DRC Northwest Region Mansfield Correctional Institution (ManCI) 1150 North Main StreetMansfield, Ohio 44901 19

DRC Northwest Region Marion Correctional Institution (MCI) 940 Marion-Williamsport RoadMarion, Ohio 43302 27

DRC Southeast Region Noble Correctional Institution (NCI) 15708 McConnelsville RoadCaldwell, Ohio 43724 20

DRC Northeast Region Northeast Reintegration Center (NERC) 2675 East 30th StreetCleveland, Ohio 44115 14

DRC Northwest Region Ohio Reformatory for Women (ORW) 1479 Collins AvenueMarysville, Ohio 43040 32

DRC Northeast Region Ohio State Penitentiary (OSP) 878 Coitsville-Hubbard RoadYoungstown, Ohio 44505 4

DRC Southeast Region Pickaway Correctional Institution (PCI) 11781 St. Route 762Orient, Ohio 43146 50

DRC Northwest Region Richland Correctional Institution (RiCI) 1001 Olivesburg RoadMansfield, Ohio 44905 22

DRC Southwest Region Ross Correctional Institution (RCI) 16149 State Rt. 104Chillicothe, Ohio 45601 21

DRC Southeast Region Southeastern Correctional Complex (SCC - L) 5900 B.I.S. RoadLancaster, Ohio 43130 47

DRC Southeast Region Southeastern Correctional Complex (SCC - H) 16759 Snake Hollow Rd, Nelsonville, OH 45764 12

DRC Southeast Region Southern Ohio Correctional Facility (SOCF) 1724 St. Rt. 728Lucasville, Ohio 45699 35

DRC Northwest Region Toledo Correctional Institution (ToCI) 2001 East Central AvenueToledo, Ohio 43608 17

DRC Northeast Region Trumbull Correctional Institution (TCI) 5701 Burnett RoadLeavittsburg, Ohio 44430 16

DRC Southwest Region Warren Correctional Institution (WCI) 5787 State Route 63Lebanon, Ohio 45036 10

DYS Circleville Juvenile Correctional Facility 640 Island Rd./P. O. Box 598 Circleville, OH 43113

DYS Cuyahoga Hills Juvenile Correctional Facility 4321 Green Road Highland Hills, OH 44128

DYS Indian River Juvenile Correctional Facility 2775 Indian River Rd, S.W. Massillon, OH 44646

In Table 2 above, the Building Counts for DRC were obtained during a 2015 Master Plan Structural Assessment. The assessors looked at all buildings within the fence unless specifically instructed otherwise, and may have split a building


into multiples based on additions or functions. There are buildings that have been closed/abandoned that are included in the assessment count, as well as guard towers, water towers, and staff residences in various occupancies. One assessment team may have split a cell block wing into a building, another may have kept the entire facility as one building. Therefore, these counts are estimates and will need additional time and analysis to confirm exact numbers.

/* Document Ends */
