Supplement 1: Salesforce Platform Managed Service



Supplement 1Ohio Department of Rehabilitation and CorrectionEnvironmental Sustainability Tracking SystemTable of Contents TOC \o "1-3" \h \z \u 1.0DRC Environmental Sustainability Tracking System31.1.Background and Overview PAGEREF _Toc517770186 \h 31.2.General Scope and Objectives PAGEREF _Toc517770187 \h 31.anization of Requirements and Scope of this Supplement PAGEREF _Toc517770188 \h 31.4.Environmental Sustainability Tracking System - General Objectives PAGEREF _Toc517770189 \h 41.5.Offeror Response: Functionality Delivered PAGEREF _Toc517770190 \h 41.6.Offeror Response: Comments and Narrative PAGEREF _Toc517770191 \h 42.0System Functional Requirements PAGEREF _Toc517770192 \h 5Functional Requirements Matrix PAGEREF _Toc517770193 \h 53.0System Technical Requirements PAGEREF _Toc517770194 \h 113.1.Current System Volumetric / Sizing Information PAGEREF _Toc517770195 \h 113.2.System Security Plan. PAGEREF _Toc517770196 \h 113.3.System Deployment Plan. PAGEREF _Toc517770197 \h 114.0System Integration Requirements PAGEREF _Toc517770198 \h 124.1.Operational Documentation PAGEREF _Toc517770199 \h 125.0System Data Conversion Requirements PAGEREF _Toc517770200 \h 146.0Ongoing Operations Requirements PAGEREF _Toc517770201 \h 156.1.General Requirements: Hosted/Cloud Software Solution PAGEREF _Toc517770202 \h 156.2.System Environment Requirements PAGEREF _Toc517770203 \h 156.3.Production/Version Control and Release Management PAGEREF _Toc517770204 \h 166.4.Break/Fix Support PAGEREF _Toc517770205 \h 176.5.Application Licensing, Capacity Planning and Monitoring PAGEREF _Toc517770206 \h 176.6.Software Platform System Management and Administration PAGEREF _Toc517770207 \h 176.7.Major/Minor Upgrades (Ongoing) PAGEREF _Toc517770208 \h 186.8.Program Management & Master Release Calendar PAGEREF _Toc517770209 \h 196.9.Environment Backup and Restoration Services PAGEREF _Toc517770210 \h 206.10.Support of State Disaster Recovery PAGEREF _Toc517770211 \h 206.11.System Incidents and Resolution PAGEREF _Toc517770212 \h 216.12.Data Management Functions. PAGEREF _Toc517770213 \h 227.0Project Training Requirements PAGEREF _Toc517770214 \h 237.1.General Training Requirements PAGEREF _Toc517770215 \h 237.2.Training Planning and Execution Requirements PAGEREF _Toc517770216 \h 237.3.DRC and DYS Training Requirements PAGEREF _Toc517770217 \h 238.0Operational Support / Help Desk Requirements PAGEREF _Toc517770218 \h 258.1.Customer Support Services PAGEREF _Toc517770219 \h 259.0Service Levels PAGEREF _Toc517770220 \h 269.1.Service Level Framework PAGEREF _Toc517770221 \h 269.2.Service Level Specific Performance Credits PAGEREF _Toc517770222 \h 269.3.Monthly Service Level Report PAGEREF _Toc517770223 \h 269.4.Escalation for Repetitive Service Level Failures PAGEREF _Toc517770224 \h 279.5.Service Level Requirements (SLAs) PAGEREF _Toc517770225 \h 279.5.1 Project Implementation Service Levels PAGEREF _Toc517770226 \h 289.5.2.On-Going Operations/Maintenance Service Levels PAGEREF _Toc517770227 \h 3110.0Contractor Staffing and Personnel Requirements PAGEREF _Toc517770228 \h 3410.1.Contractor Staffing Plan, Time Commitment and Work Locations PAGEREF _Toc517770229 \h 3410.2.Contractor Personnel Requirements PAGEREF _Toc517770230 \h 3410.3.Criminal Background Check of Personnel PAGEREF _Toc517770231 \h 3511.0Contract Governance Processes and Requirements PAGEREF _Toc517770232 \h 3611.rmal Dispute Resolution PAGEREF _Toc517770233 \h 3611.2.Internal Escalation Obligations and Requirements PAGEREF _Toc517770234 \h 3611.3.Escalation for Repetitive Service Level Failures PAGEREF _Toc517770235 \h 3711.4.No Termination or Suspension of Services or Payment. PAGEREF _Toc517770236 \h 3711.5.Back-Up Documentation PAGEREF _Toc517770237 \h 3711.6.Correction of Errors PAGEREF _Toc517770238 \h 3712.0Contract Conclusion Requirements: Transition to Successor Contractor or State at Contract Termination or Non-Renewal PAGEREF _Toc517770239 \h 3812.1.Overview PAGEREF _Toc517770240 \h 3812.2.Standards PAGEREF _Toc517770241 \h 3812.3.Termination Assistance Plan PAGEREF _Toc517770242 \h 3812.4.Ownership of State Data and Provision for Providing the State Data at Contract Conclusion PAGEREF _Toc517770243 \h 3913.0Offeror Assumptions, Support Requirements, Pre-Existing and Commercial Materials PAGEREF _Toc517770244 \h 4013.1.Assumptions PAGEREF _Toc517770245 \h 4013.2.Support Requirements PAGEREF _Toc517770246 \h 4013.3.Pre-Existing Materials PAGEREF _Toc517770247 \h 4013.mercial Materials PAGEREF _Toc517770248 \h 4014.0Reference and Informational Data PAGEREF _Toc517770249 \h 41DRC Environmental Sustainability Tracking SystemBackground and OverviewThe 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. General Scope and ObjectivesThe 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 anization of Requirements and Scope of this SupplementThe State has organized this Supplement and the requirements herein in the following general categories. Specific requirements are contained later in this Supplement.System Functional RequirementsSystem Technical RequirementsSystem Integration RequirementsCurrent System Data Conversion RequirementsOngoing Operations RequirementsEnvironmental Sustainability Tracking System - General ObjectivesVia 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.Offeror Response: Functionality DeliveredThe 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 ColumnOfferor Response ConsiderationsBaseThose 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 RecommendedThose 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) 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. System Functional RequirementsFunctional Requirements MatrixFunctionality Delivered Through: (indicate with 'X')Req. #Implementation AreaRequirement DescriptionBaseConfigNot SupportedOfferor Narrative and ResponsePlatformP1PlatformA cloud-based solution, software-as-a-service option that will not require investments in hardware and maintenance by DRC or DYS.AccessibilityA1Accessibility A web-based interface for authorized users of DRC and DYS to access, providing role‐based permissions access to data entry, editing and reporting.A2Accessibility 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.A3AccessibilityInterface must be simple to access remotely from any computer.Data AutomationDA1Data 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.DA2Data AutomationData 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.DA3Data 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 1Utility Data TrackingMonthly energy consumption for each fuel typeUDT 2Utility Data TrackingAccount numbersUDT 3Utility Data TrackingRate class and tariff codes for each accountUDT 4Utility Data TrackingMeter numbersUDT 5Utility Data TrackingMeter read datesUDT 6Utility Data TrackingFacility locations and service addressUDT 7Utility Data TrackingAll costs including supplier costsUDT 8Utility Data TrackingAll other changes and credits specified on billsUDT 9Utility Data TrackingDemand data including metered peak and billed peakUDT 10Utility Data TrackingPower factor/reactive power and charges where applicableUDT 11Utility Data TrackingTotal amount, cost, and revenue (where applicable) of Waste and Recycling streamsUDT 12Utility Data TrackingWater and sewer consumption and costs for each facilityHistorical Data ImportHDI 1Historical Data ImportA minimum of three years of historical utility bill information captured and populated into the database by the ContractorData Export: Users with access to the solution must have a simple means of data export. DE 1Data ExportData export must be available in CSV formatDE 2Data ExportData export must be available in Excel formatDE 3Data ExportGraphs must be available for download in JPG and/or PNGData Ownership DO 1Data OwnershipDRC and DYS will own all data in this solution. DO 2Data 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 3Data 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 ReviewDR 1Data ReviewA utility bill audit or review process that automatically identifies and alerts users of utility usage and cost abnormalities/anomalies.DR 2Data ReviewThe proposed solution should be capable of identifying abnormal spikes in consumption and alerting users as necessary.DR 3Data 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 1DashboardsData visualization tools for executive/management, with drill down capability to increase transparency and improve data communications to a wide range of audiences. D 2DashboardsIt 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 R 1ReportingDetailed and flexible reporting on utility by:UsageCostsWeather-normalized Year-to-year comparisonCost avoidanceFacility-to-Facility ComparisonGreenhouse gasesProgress towards goals identified in the agencies Sustainability Plans, in all locations.R 2ReportingAll reports must be viewable via the web and compatible with downloading into appropriate software such as:MS ExcelMS WordPDFR 3ReportingReports must be generated for different levels by:Utility typeFacilityPopulationRegionAgency-wide by month Agency-wide by fiscal yearR 4ReportingReporting functionality should include the ability to create ad hoc reports. Data searches should at least be available by:Cost UsageUse per square foot Other variables such as use by inmate populationR 5ReportingReports 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 6ReportingReports 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.)R 7ReportingA 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 8ReportingReports which compare facilities should be normalized by billing period.R 9ReportingReporting should include the ability to present agency data in established formats used by the Global Reporting Initiative and others.Energy Savings Measurement & VerificationESMV 1Energy Savings Measurement & VerificationAbility 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 & VerificationData 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 TrackingGGET 1Greenhouse Gas Emission TrackingAbility 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 IntegrationESTI 1ENERGY STAR Tracking and IntegrationDirect 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.)ESTI 2ENERGY STAR Tracking and IntegrationThe following items must be tracked or input in portfolio manager:Facility name and addressFacility square footage and space use typesMeter read dates,Volume of energy consumed during the billing period for each fuel type,Water/sewer consumption and costsAll costs including supplier costs,Electric demandA minimum of two years of historical data must be input to Portfolio Manager.Utility Bill StorageUBS 1Utility 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.SecurityS 1SecurityThe solution will not reside on DYS or DRC servers, and will not require any connections to DYS or DRC networks or servers.Growth and FlexibilityGF 1Growth and FlexibilityThe 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 TrackingSRPT 1Sustainability-Related Program TrackingTracking additional goals and data from other ODRC Sustainability Initiatives (), such as youth/offender participation sustainability-related programs.SRPT 2Sustainability-Related Program TrackingThe 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: CategoryData FieldsEnvironmental Literacy ProgramInstitutionGraduation DateNumber of GraduatesCommunity GardeningInstitutionType of produce grown (corn, lettuce, etc.)Pounds of produce grownDonation dateDonation recipientNumber of offenders/youth involvedAnimal RehabilitationInstitutionType of animal (squirrels, dogs, etc.)Number of animals servedNumber of offenders/youth involvedCommunity partner nameEach 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 1Usage SplitsProposed 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 2Mobile AccessInterface is simple to access remotely from any mobile device.AF 3Potential 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 SolutionSystem Technical RequirementsCurrent System Volumetric / Sizing InformationDRC 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.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.System Security PlanSystem 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.System Deployment PlanSystem 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; andSecurity controls and protocols used to ensure Confidentiality, Integrity and Availability of the Interfaces (i.e., Encryption, Authentication, etc.).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.Operational DocumentationThe 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 changesSecure access to workflow documentation to prevent unauthorized municate proposed policy/procedure changes to State prior to implementation for State approvalEach 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.Operational DocumentationSystem 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. Ongoing Operations RequirementsGeneral Requirements: Hosted/Cloud Software SolutionThe 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.System Environment RequirementsBased 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.EnvironmentSolutionDemo / Sandbox / Proof of Concept / TrainingDevelopment & ConfigurationAcceptance TestingProductionDescriptions 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.Production/Version Control and Release ManagementThe 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; andEstablish 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.Break/Fix SupportThe 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; andEnsure 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.Application Licensing, Capacity Planning and MonitoringThe Contractor must: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.Software Platform System Management and AdministrationThe Contractor must: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 configurationSupport performance tuning of State application elements and perform performance tuning on software elementsThe 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; andNotify the Contractor of any planned or emergency changes to the State’s environment affecting the Contractor's delivery of the Services.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; andFor 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.Program Management & Master Release CalendarThe 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; andOther pertinent dates that require end-user notification or coordination.Environment Backup and Restoration ServicesFor each software environment within the scope of the Contractor’s Service, the Contractor must perform backup processes as follows:TypeDescriptionScheduled TimingBaselinePre-production image and dataOnceDaily Incremental FilesData changes during the periodDailyFull Data FilesAll resident data filesWeekly (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 neededThe Contractor must maintain backup retention periods as followsDescriptionRetention PeriodBaselineUntil first annual + 1 monthDaily6 DaysWeekly4 WeeksMonthly12 MonthsAnnual7 YearsUpon 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.Support of State Disaster RecoveryThe 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 PlanningTo 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; andNotification 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 DisastersFollowing 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.System Incidents and ResolutionThe 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.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.The Contractor must: 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:Names and contact information for production control personnel;Notification of a systems administrator when a predetermined threshold of errors has occurred during a batch or real-time data transfer;Documentation defining the file transfer procedure and indicating actions to be taken when errors are found; andThe file transfer schedule.Project Training RequirementsGeneral Training RequirementsThe 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.Training Planning and Execution RequirementsTraining 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:Training Plan/Schedule;Training Documentation; andConduct Training for DRC and DYS Employees. DRC and DYS Training RequirementsThe 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; andSystem Tutorials/System Navigation.Operational Support / Help Desk RequirementsCustomer Support ServicesThe 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.The Contractor must: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.Service Levels Service Level FrameworkThis 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.Service Level Specific Performance CreditsEach 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.Monthly Service Level ReportOn 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; andA 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.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. 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.1Project Implementation Service Levels Project Implementation and Managed Services Service LevelService Level StandardPerformingUnder-PerformingNot AchievingDeliverable 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 daysUAT Severity 1 Outages Resolution – Mean Time to Repair: Resolution of Severity 1 issues during UAT<= 3 days> 3 days and <= 5 days> 5 daysUAT Severity 2 Outages Resolution – Mean Time to Repair: Resolution of Severity 2 issues during UAT<= 5 days> 5 daysand <= 7 days> 7 daysUAT Severity 3 Outages Resolution – Mean Time to Repair: Resolution of Severity 3 issues during UAT<= 8 days> 8 days <=10 days> 10 daysProject Implementation Service Level Agreement: Deliverable AcceptanceDefinition: 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 PeriodData SourceCollection FrequencySL FormulaSL Measure GYR State Monthly, During ProjectWeekly Project ReportWeekly% 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 DatesDefinition: 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.Measurement PeriodData SourceCollection FrequencySL FormulaSL Measure GYR State Monthly, During ProjectWeekly Project ReportWeekly100% Y ( # Milestones Missed During Period) + 100% X (# Milestones Missed During Period)<5 days>5 days>14 daysProject Implementation Service Level Agreement: UAT Severity 1 Outages Resolution – Mean Time to RepairPrompt 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.Measurement PeriodData SourceCollection FrequencySL FormulaSL Measure GYR StateReporting MonthMonthly Service ReportPer IssueMean 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 daysProject Implementation Service Level Agreement: UAT Severity 2 Outages Resolution – Mean Time to RepairPrompt 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 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.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 2 UAT issues to determine the statistical mean.Measurement PeriodData SourceCollection FrequencySL FormulaSL Measure GYR StateReporting MonthMonthly Service ReportPer IssueMean Time to Repair (Severity 2 Issues) = (Total elapsed business days for all resolved Severity 2 Issues) ÷ (Total number of all resolved Severity 2 Issues)<=5 days>5 days and <=7 days>7 daysProject Implementation Service Level Agreement: UAT Severity 3 Outages Resolution – Mean Time to RepairPrompt 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 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.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 3 UAT issues to determine the statistical mean.Measurement PeriodData SourceCollection FrequencySL FormulaSL Measure GYR StateReporting MonthMonthly Service ReportPer IssueMean Time to Repair (Severity 3 Issues) = (Total elapsed business days for all resolved Severity 3 Issues) ÷ (Total number of all resolved Severity 3 Issues)<=8 days>8 days and <=10 days>10 days9.5.2.On-Going Operations/Maintenance Service Levels Solution and Managed ServicesService LevelSLA or SLOCoverage1Incident Resolution – Mean Time to Repair (Severity 1 Outages) SLA24/7/3652Incident Resolution – Mean Time to Repair (Severity 2 Outages)SLA24/7/3653Incident Resolution – Mean Time to Repair (Severity 3 Outages)SLABusiness Hours4Service Availability – Application AvailabilitySLA24/7/3655Service Timeliness – System ChangesSLAScheduled MaintenanceManaged 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, orcauses 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.Measurement PeriodData SourceCollection FrequencySL FormulaSL Measure GYR StateReporting MonthMonthly Service ReportPer IssueMean 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 hoursManaged Services Service Levels: Issue Resolution – Mean Time to Repair (Severity 2 Issues)Prompt resolution of system Severity 2 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 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.Prioritization: An Issue shall be categorized as a “Severity 2 Issue” if the issue is characterized by the following attributes. The Issue: 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, andaffects 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.Measurement PeriodData SourceCollection FrequencySL FormulaSL Measure GYR StateReporting MonthMonthly Service ReportPer IssueMean 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 hoursManaged Services Service Levels: Issue Resolution – Mean Time to Repair (Severity 3 Issues)Prompt resolution of system Severity 3 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 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.Prioritization: An Issue shall be categorized as a “Severity 3 Issue” if the issue is characterized by the following attributes. The Issue: 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.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 3 UAT issues to determine the statistical mean.Measurement PeriodData SourceCollection FrequencySL FormulaSL Measure GYR StateReporting MonthMonthly Service ReportPer IssueMean 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 daysManaged Services Service Levels: Service Availability – Solution Component/Application AvailabilityAll system components are Available to All State Users for All Business Functions to Support Critical Processes.This Service Level begins upon completion of agreed production acceptance criteria and a measurement period as documented in the transition to production plan.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.Measurement PeriodData SourceCollection FrequencySL FormulaSL Measure GYR StateReporting MonthMonthly Service ReportContinuous, 24 hours a dayApplication 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 EnvironmentBetween 98% and 99%Production EnvironmentLess 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.This Service Level begins upon completion of agreed production acceptance criteria and a measurement period as documented in the transition to production plan.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.Measurement PeriodData SourceCollection FrequencySL FormulaSL Measure GYR StateDaily Accounting MonthMonthly Service ReportPer IssueMean 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 daysTier 2: <=4 daysTier 3: <=6 daysTier 1: >2 days and <=3 daysTier 2: >4 days and <=6 daysTier 3: >6 days and <=8 daysTier 1: >3 daysTier 2: >6 daysTier 3: >8 daysContractor Staffing and Personnel RequirementsContractor Staffing Plan, Time Commitment and Work LocationsOfferors 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. Contractor Personnel RequirementsThe 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.Criminal Background Check of PersonnelContractor 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.Contract Governance Processes and RequirementsInformal Dispute ResolutionPrior 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.Internal Escalation Obligations and RequirementsIf 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.Escalation for Repetitive Service Level FailuresThe State may escalate repetitive service level failures to the Contractor’s executive sponsor, the Contractor’s Managing Director, or the equivalent position.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.Back-Up DocumentationAs 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.Correction of ErrorsAs 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.Contract Conclusion Requirements: Transition to Successor Contractor or State at Contract Termination or Non-RenewalOverviewContractor 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 3rd 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.StandardsThe 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 3rd 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.Termination Assistance PlanThe 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.Ownership of State Data and Provision for Providing the State Data at Contract ConclusionAll 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.Offeror Assumptions, Support Requirements, Pre-Existing and Commercial MaterialsAssumptionsThe 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.Support RequirementsThe 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; andOther 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.Pre-Existing MaterialsThe 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 mercial MaterialsThe 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.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 VendorsUtilityVendor# of AccountsElectricityAmerican Electric Power (AEP)38City of Columbus1Dayton Power and Light6Duke Ohio1Village of Grafton1Ohio Edison26South Central Power11The Illuminating Company2Toledo Edison1Natural GasColumbia Gas33Dominion East Ohio7Knox Energy Cooperative1Vectren Energy Delivery2KIDN Marketing LTD1Water/Sewer*Water / Sewer number of accounts indicate number of institutions served by utility, not actual number of accounts.Allen County1Aqua Ohio Inc2Belmont County1Butler County2Village of Caldwell1City of Cleveland1City of Columbus2City of Dayton1Village of Grafton2City of Lima1City of London2City of Mansfield2City of Marion1City of Marysville1Northeast Ohio Regional Sewer District2City of Portsmouth1Rural Lorain County Water Authority2Scioto County Regional Water1Scioto County1City of Toledo1City of Warren1City of Youngstown1Institutions served by on-site water treatment plant7Institutions served by on-site wastewater treatment plant4Waste Hauling and DisposalElytus (Third-Party Administrator, State Contract)77Table 2 Institution list and building countsAgencyRegionInstitutionAddressBuilding CountDRCNorthwest RegionAllen/Oakwood Correctional Institution (AOCI)2338 North West StreetLima, OH 4580225DRCSoutheast RegionBelmont Correctional Institution (BeCI)68518 Bannock RoadSR 331St. Clairsville, OH 4390525DRCSouthwest?RegionChillicothe Correctional Institution (CCI)15802 SR 104 NorthChillicothe, OH 4560149DRCSoutheast RegionCorrectional Reception Center (CRC)11271 SR 762Orient, OH 4314618DRCSouthwest RegionDayton Correctional Institution (DCI)4104 Germantown StreetDayton, OH 4541711DRCFranklin Medical Center (FMC)1990 Harmon AvenueColumbus, OH 4322315DRCNortheast RegionGrafton Correctional Institution (GCI)2500 South Avon Beldon RdGrafton, OH 4404418DRCSouthwest RegionLebanon Correctional Institution (LeCI)3791 State Route 63Lebanon, Ohio 4503610DRCSouthwest RegionLondon Correctional Institution (LoCI)1580 State Route 56, SWLondon, Ohio 4314019DRCNortheast RegionLorain Correctional Institution (LorCI)2075 South Avon-Belden RdGrafton, Ohio 4404421DRCSouthwest RegionMadison Correctional Institution (MaCI)1851 State Route 56London, Ohio 4314017DRCNorthwest RegionMansfield Correctional Institution (ManCI)1150 North Main StreetMansfield, Ohio 4490119DRCNorthwest RegionMarion Correctional Institution (MCI)940 Marion-Williamsport RoadMarion, Ohio 4330227DRCSoutheast RegionNoble Correctional Institution (NCI)15708 McConnelsville RoadCaldwell, Ohio 4372420DRCNortheast RegionNortheast Reintegration?Center (NERC)2675 East 30th StreetCleveland, Ohio 4411514DRCNorthwest RegionOhio Reformatory for Women (ORW)1479 Collins AvenueMarysville, Ohio 4304032DRCNortheast RegionOhio State Penitentiary (OSP)?878 Coitsville-Hubbard RoadYoungstown, Ohio 445054DRCSoutheast RegionPickaway Correctional Institution (PCI)11781 St. Route 762Orient, Ohio 4314650DRCNorthwest RegionRichland Correctional Institution (RiCI)1001 Olivesburg RoadMansfield, Ohio 4490522DRCSouthwest RegionRoss Correctional Institution (RCI)16149 State Rt. 104Chillicothe, Ohio 4560121DRCSoutheast RegionSoutheastern Correctional Complex (SCC - L)5900 B.I.S. RoadLancaster, Ohio 4313047DRCSoutheast RegionSoutheastern Correctional?Complex (SCC - H)16759 Snake Hollow Rd, Nelsonville, OH 4576412DRCSoutheast RegionSouthern Ohio Correctional Facility (SOCF)1724 St. Rt. 728Lucasville, Ohio 4569935DRCNorthwest RegionToledo Correctional Institution (ToCI)2001 East Central AvenueToledo, Ohio 4360817DRCNortheast RegionTrumbull Correctional Institution (TCI)?5701 Burnett RoadLeavittsburg, Ohio 4443016DRCSouthwest RegionWarren Correctional Institution (WCI)?5787 State Route 63Lebanon, Ohio 4503610DYSCircleville Juvenile Correctional Facility640 Island Rd./P. O. Box 598 Circleville, OH 43113DYSCuyahoga Hills Juvenile Correctional Facility4321 Green Road Highland Hills, OH 44128DYSIndian River Juvenile Correctional Facility2775 Indian River Rd, S.W. Massillon, OH 44646In 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 */ ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download